Period lock — close the books

The bookkeeper who back-dated his own lunches

A director we worked with discovered, two years into running the business, that her bookkeeper had been quietly back-dating personal expense claims into the prior accounting year. Not many — three or four a quarter, all under £100, all things that looked plausibly business-related. A lunch here, a tank of fuel there, a "courier" charge that was actually a parcel he'd sent to his mother. By the time it surfaced, two corporation tax computations had been filed using numbers that included his personal spending.

The bookkeeper's motivation, when she finally confronted him, was unimpressive — he was trying to reduce his year-end balance with the company so his next salary review would look better. The mechanism, however, was perfectly available to him. The previous year was "closed" in the sense that the accountant had signed off the statutory accounts and they'd been filed at Companies House. But nothing in the accounting software prevented a new journal being posted with a date six months before. The trial balance for the prior year, queried any time after the supposed close, looked different to the trial balance the accountant had used.

The Period Lock would have made that impossible.

What "period lock" means

A configurable date threshold. Once a period is locked, the engine refuses any write that affects that period:

• A new transaction cannot be created with a date ≤ the lock date.
• A bill cannot be back-dated into a locked period.
• A GRN (goods received note) cannot be posted with a received-date inside a locked period.
• A bank-rec adjustment cannot touch a transaction in a locked period.
• A manual journal cannot be posted with a journal date inside a locked period.

The lock is a hard refusal at the database layer. There's no "are you sure?" warning that you might miss — the API returns 400 with a clear "this date falls in a locked period" error. The UI surfaces the same error and prevents you submitting the form.

The lock is set at the entity level. If you have multiple companies (entities) inside the same tenant, each one has its own lock date — useful when their year-ends fall in different months.

Why it matters

Integrity. Once your accountant signs off the year, those numbers are gospel. If they can be edited after the fact, every audit becomes "but what was it on the day it was signed?" Every CT600 filed becomes provisional — could be amended next week if someone slips a journal in. Every dividend declared becomes uncertain — was there really sufficient distributable profit at the point of declaration?

A locked period is the accounting-software equivalent of a signed minute. It says: these numbers are what they were on this date. Anything that needs to change after the lock must do so visibly, through an audit-trailed unlock and re-lock event, not silently through a back-dated journal.

How to set it

Settings → Accounting Policies → Period Lock.

Enter the lock date (typically the year-end date itself — 31 March, 31 December, whatever your accounting period closes on). Confirm. The engine immediately starts refusing any write with a date ≤ that. You don't lose existing data; the lock is forward-only, prospective. Whatever was posted before the lock fires remains queryable, but nothing new can land in that range.

You can lock multiple times. Each lock has to be ≥ the previous lock date — you can advance the lock month by month if you want monthly closes — but you can't retreat the lock except via the explicit Unlock flow.

What gets locked

• GL transactions — manual journals, bill posts, payment posts, receipt posts, anything that hits the general ledger.
• GRNs — can't receive goods back-dated into the locked period.
• Bank reconciliation — can't unmatch a locked-period transaction, can't add a reconciled-balance override that affects a locked period, can't post a bank adjustment dated inside a locked period.
• Bad-debt provisions — can't raise a specific provision back-dated into a locked period. (You'd raise it in the current period using the as-at date for general.)
• Fixed Asset disposals — can't dispose an asset with a disposal date in a locked period. (Depreciation that was already posted by the cron before the lock is fine; new disposal journals can't go in.)
• VAT corrections — can't post a corrective VAT journal into a locked VAT period. Corrections go in the current open period (see chapter 6).
• Expense claims — can't approve an expense with an expense date inside a locked period.

What doesn't get locked

• Current-period writes. Obviously. You're not closing the business, you're closing the prior period.
• Reports and queries. Read-only views work fine across locked periods — you'd never lock yourself out of seeing your own data.
• New bills with current-period dates. A supplier invoice arrives in May referring to work done in March (the locked period) — you post the bill with a May date and reference the original work in the description. The cash hits where it should; the period boundary stays clean.
• New invoices. Same logic. You raise May invoices for work delivered in May.
• Bank transactions ingested from feed. Open Banking and Plaid push transactions in with their actual transaction date. If a transaction is back-dated by the bank (rare, but possible — pending FX settlements, batched card transactions), the engine creates the transaction in unreconciled status outside the locked period. You then manually post it to the current period.

Unlock

A privileged operation. Audited. Settings → Accounting Policies → Unlock period:

• Confirm.
• Enter a reason (free text, mandatory, minimum 20 characters). "Accountant found a missed accrual, need to correct" is a reason. "x" is not.
• The unlock event is logged with timestamp, user ID, reason. Searchable in the audit log under event type period_unlock.
• The lock date snaps back to the previous lock date (or to "never locked" if it was the first lock).

You can then post your correction. Once posted, re-lock to the original date. The re-lock is a separate audited event.

Two roles can unlock: Owner and Accountant. The Admin role can lock but not unlock — deliberate separation to make casual unlocks harder. Other roles see the Period Lock setting as read-only with no edit affordance at all.

When to lock

• Monthly close. Lock the prior month once you've reconciled and posted month-end journals. Catches stale adjustments and discourages bookkeepers from drifting into "I'll just back-date that to keep my reconciliation clean".
• Quarter-end. Lock the prior quarter once you've submitted the VAT return for that quarter. Prevents an inadvertent journal from changing the underlying boxes 1-9 after submission.
• Year-end. Lock the whole prior year once year-end accountant sign-off is done. The most important lock — the one that protects the numbers your statutory accounts are built on.

Order of operations at year-end

The full year-end sequence, with the period lock in the right spot:

1. Finish bookkeeping for the year — all bills entered, sales invoiced, expenses approved.
2. Bank reconciliation done for every account up to year-end date.
3. Specific bad-debt provisions raised (chapter 2).
4. General bad-debt provision computed and posted (chapter 2).
5. VAT bad-debt relief eligibility reviewed — most of it auto-flows (chapter 3).
6. Fixed Asset Register reviewed; depreciation cron has run for every month of the year (chapter 4).
7. Year-end adjustment journals posted — accruals (utility bills you've used the service for but not yet been billed), prepayments (rent paid in advance), deferred revenue (cash received for work not yet done), corporation tax provision.
8. Run the trial balance. Send to your accountant for review.
9. Accountant signs off — confirms the numbers are good for statutory accounts.
10. Lock the period.
11. Submit MTD VAT for the closing quarter (chapter 6).
12. Hand the trial balance + Fixed Asset PDF + bad-debt schedule to the accountant for statutory accounts preparation.

Locking before step 9 (accountant sign-off) is fine if you trust your books — but if the accountant comes back with "you've missed an accrual for that legal bill", you have to unlock to post it. Locking after step 9 means the unlock-relock dance is avoided.

What if you missed something post-lock

It happens. The accountant queries an invoice three months after sign-off. A supplier sends a credit note dated in the locked year. A bank transaction your feed missed turns up on a paper statement.

• Unlock. Settings → Accounting Policies → Unlock, with a reason ("Accountant query — missing supplier credit on bill BIL-1142").
• Post the correction. Single journal or single bill, dated correctly.
• Re-lock. Same lock date as before.
• Tell your accountant. They need to know the trial balance they used has shifted, even slightly. If statutory accounts have already been filed, the accountant decides whether the change is material enough to file an amendment. Usually under £1,000 net, it's not. Above that, it might be.

The unlock-correct-relock pattern is fine and well-trodden. What's NOT fine is unlock-edit-edit-edit-edit-relock without telling anyone. The audit log will show the unlock and the date; if anyone (HMRC, a future investor, your accountant) digs in, the gap between unlock and relock is the window of suspicion. Make the gap small.

Audit trail

Every transaction in a locked period carries a flag — posted_before_lock true/false — that the audit log uses. Queries like "show me all transactions posted to the period 2025-04-01 to 2026-03-31 after the lock fired" become trivial. A useful sanity-check before a CT600 is filed: "anything posted to last year after the lock? Tell me what."

The audit log lives in Settings → Audit log. Filter by event type period_lock and period_unlock to see the lock history; filter by journal_posted with the posted_after_lock flag to see writes that happened in an unlock window.

RBAC

Role	Lock	Unlock	View lock status
Owner	Yes	Yes	Yes
Admin	Yes	No	Yes
Accountant	Yes	Yes	Yes
Bookkeeper	No	No	Yes
Approver	No	No	Yes
Viewer	No	No	Yes

The split exists deliberately: Bookkeeper has the most surface area for accidental or deliberate edits, so they get no lock control at all. The accountant role exists for external advisors invited as users — they can lock and unlock because that's the workflow.

Common mistakes

• Locking before reconciling. You lock in unmatched bank lines. Reconcile first, lock second.
• Locking before the depreciation cron has run. If the cron fires on the 1st of the next month, lock on the 2nd or later. Locking on the last day of the month leaves the year's final depreciation charge in the new month — not what you want for year-end.
• Locking without telling the team. Bookkeeper tries to post a back-dated correction, gets a confusing error. Lead with a calendar note: "Locking March on 12 April after I've finished bank-rec."
• Forgetting to lock at all. Six months later you don't remember what was original vs. what was a tweak. The trial balance handed to the accountant is one version; the trial balance you'd see today is another.
• Aggressive monthly locks for current-month transactions. A few teams lock so eagerly that current-month bills arriving in the post can't be back-dated to their bill date. Don't do this — locks are for closed periods, not for fortifying yourself against your own postman.

Up next

Chapter 6 closes the series. Submit MTD VAT — the last VAT return that closes inside your accounting year — and your year-end is done.