Ask most small companies what their revenue was last March and you will get an answer. Ask again three months later and you may get a different one, from the same system, with nobody having done anything wrong.
That happens when the ledger accepts postings into months that have already been reported. A period lock is the mechanism that stops it, and it is the difference between books that are a record and books that are a running estimate.
What an accounting period lock does
An accounting period lock makes a closed period refuse new postings. An entry dated inside that period is rejected at the point of posting, with a reason, rather than accepted and quietly folded into a figure that was already published.
The control is unglamorous and its value is entirely retrospective. It does not make this month’s numbers more accurate. It makes last month’s numbers permanent, which is what turns a report into something a bank, an investor, an auditor or your own comparative analysis can rely on. A statement produced from an unlocked period has an implicit footnote: correct as of the moment you pressed the button.
Locking is also what gives a correction somewhere to go. If March cannot accept a posting, a March error found in June has exactly one legitimate destination: June, visibly, with a reference back. That constraint is the whole design.
Backdating is the failure the lock prevents
Backdating means posting an entry with a date inside a period that is already closed. The transaction itself is usually perfectly legitimate: an invoice that was genuinely issued in March, a bill that genuinely related to March, a reclassification the accountant genuinely wants in the right month.
The damage comes from timing, not intent.
- Every report already produced from that period is now wrong, and nothing marks it as superseded.
- Two people running the same report on different dates get different numbers and both are reading the live system correctly.
- A tax return or bank covenant calculation derived from the old figures no longer reconciles to the ledger it came from.
- Year-on-year comparatives shift underneath you, so a trend can appear or disappear without any business event causing it.
An auditor confronted with a ledger that permits backdating does not usually accuse anyone of anything. They widen their testing, because a system where entries can move is a system where they have to check whether entries did. The cost arrives as extra fees and a slower close, not as an allegation.
Soft close and hard close
Most finance teams need two stages, because the days immediately after month end are exactly when late adjustments legitimately appear.
| Soft close | Hard close | |
|---|---|---|
| When | Day one after month end | After review and reporting |
| Routine postings | Blocked | Blocked |
| Adjustments by finance staff | Allowed, during the review window | Not allowed |
| Who can change the state | Finance team | Owners and finance administrators only |
| Numbers considered | Provisional | Reported and fixed |
| Correcting an error found later | Adjust in place | Post a correction into the current period |
The sequence is: soft close to stop the ordinary flow of transactions, complete reconciliations and accruals, publish, then hard close so the published figures stop moving. Teams that skip the second stage keep the review window open indefinitely, which is the same as having no lock at all with more ceremony.
The prior-period entry that arrived after filing
A distribution business closes March, files its quarterly return from those numbers, and sends the quarter’s figures to its lender under a covenant that tests gross margin.
In July, a bookkeeper finds that a $38,000 supplier bill for March freight was never entered. It is real, it is March’s cost, and the accounting software happily accepts it dated 31 March, because no period lock exists.
Three things break at once. March’s gross margin drops below the covenant threshold, retroactively, so the figure the lender holds no longer matches the ledger. The filed return no longer agrees with the books that support it, which is the specific condition that makes a routine inspection expensive. And Q1 in every dashboard changes in July without a single event in the business having changed, so the sales team spends a week trying to explain a margin drop that has nothing to do with sales.
With a period lock the same discovery produces a different sequence. March refuses the posting. The bill posts in July with a reference to the original invoice, the prior-period effect is disclosed explicitly in the July close notes, and the lender is told once, deliberately, about a correction rather than discovering that a number they were given has changed. The money is the same. The control converted a silent restatement into a managed disclosure.
Unlock authority is the real control
A lock that anyone can lift is a suggestion. The important design decisions are not about locking but about reopening.
Unlock authority should sit with a small named group, and unlocking should be an event: recorded, attributable, and awkward enough that nobody does it to save ten minutes before a deadline. The most common way period locks fail in practice is not that they are absent. It is that everyone who posts can also unlock, so the lock is lifted, the entry goes in, and the period is closed again, leaving no trace in the figures themselves.
Two further details decide whether the lock actually holds. A date with no period defined for it must be refused rather than treated as open, or the calendar’s gaps become an unguarded back door. And where two period definitions overlap, the more restrictive one has to win, or an overlapping open period silently overrides a locked one.
How Oneop implements period locks
Oneop’s finance module resolves the period for every posting before it writes. A new workspace is seeded with a fiscal year and twelve monthly periods, all open, so nobody posts into an undefined calendar on day one.
A posting dated in an open period posts. A posting into a closed period is refused and named as closed. A posting into a locked period is refused and named as locked. A date with no period at all is refused and reported distinctly from a locked period, because “you have not set up that month” and “that month is shut” need different responses from the person holding the entry. Where two periods overlap, the least permissive one decides, so a locked period covering the same date wins over an open one. Locking and unlocking a period is restricted to owners and admins.
The rule that makes the lock load-bearing is the one about corrections. A posted entry is never edited in Oneop; corrections post as linked reversals, and the reversal itself has to land in an open period. A closed month cannot be quietly reopened by reversing into it. That mechanism has its own article: reversals vs editing transactions covers why history is appended to rather than changed, and double-entry accounting for founders covers the balancing rules underneath both.
Year-end close, when enabled, posts a single entry dated the fiscal year’s last day that clears profit-and-loss accounts to retained earnings, where retained earnings is the difference of the accumulated sides, so it ties by construction. It stays inactive for a workspace until someone deliberately turns it on.
What to check in any accounting system
Four questions, all answerable in a demo.
- Does closing a period actually refuse a posting, or does it only change a label in the interface?
- Can I post to a date that has no period defined for it?
- Who can unlock, and where is the unlock recorded?
- When I correct a closed month, where does the correction land, and can I see both the original and the fix?
A system that answers all four crisply is one where your reported numbers stay reported. One that hesitates on any of them will produce a March figure that depends on when you ask, which is the problem financial reporting is supposed to have removed. Period locks are available in the ledger on every plan, including the free one, with statement depth varying by plan as set out on pricing.