Period locking
Close the books through a date so nothing changes after taxes are filed or statements are issued.
Once a fiscal period is finalized — you filed taxes, issued audited statements, or signed off the month — you don't want anyone (including yourself, at 11pm, with bad context) creating, editing, or deleting transactions inside that period.
That's what period locking is for.
Locking a period
Settings → Period lock:
- Pick a Lock through date.
- Click Lock period.
From then on, any attempt to create, edit, or delete a transaction with a date on or before that lock date is rejected at the database transaction layer. You'll see a clear error:
Period is locked through 2026-03-31. Unlock it first to post or change transactions on or before that date.
It applies equally to the UI, the REST API, and any other write path. The lock is the rule.
Who can lock and unlock
- Owners and admins can lock or move the lock forward.
- Only the owner can unlock or move the lock backward.
This asymmetry is on purpose: finalizing books is a routine operation, unfinalizing them is a serious one.
Editing inside a locked period
You can't. If you need to correct something dated inside a locked period, the standard accounting answer is a reversing entry — post a new transaction in the current open period that mirrors the mistake, then post the corrected version. This leaves your locked period intact and the correction visible to auditors.
(Reversing entries are on the roadmap as a one-click action. For now, post them by hand.)
Why it lives at the DB level
If the lock were just a UI hint, anyone with API access (or just devtools
open) could bypass it. The check is implemented as a
assertPeriodNotLocked() call inside every journal mutation's database
transaction. There is no path that skips it. This is the same principle
that makes the audit log trustworthy: enforcement has to live in the
kernel, not the chrome.