Locking accounting periods
Close a month so nothing back-dated can change it.
When you've finished a month — reviewed everything, filed your SST, reported the numbers — you want that month to stay finished. Locking an accounting period seals it: once a month is locked, Kiravy refuses to let anything new land inside it, so the figures you reported can't quietly change underneath you.
Find it under Settings → Accounting periods.
Closing the books for a month
The Accounting periods screen lists your recent months, each with a lock toggle. Flip the toggle on a month to lock it; flip it back to reopen it.
Only an owner or admin can lock or unlock a period. Other roles can see the status but not change it — closing the books is a deliberate, accountable action, so it's held to the people responsible for the numbers.
What a locked month rejects
Once a month is locked, Kiravy rejects anything dated inside it — whether you're creating it now or back-dating it:
- a new or back-dated journal entry
- a new or back-dated invoice or bill
- a payment dated in that month
The rule is about the date on the document, not when you do it. Try to post a back-dated invoice into a locked month and Kiravy stops you with a message naming the locked period. Anything dated in a month that's still open posts as normal.
Locking is per month. A 17 May entry belongs to the May period — lock May and that date is closed, while June stays open for everyday work.
Correcting something in a locked month
Locking a month doesn't trap you. You can still void a document that's dated in a locked period — cancel an invoice, refund a paid bill — because the correction doesn't touch the locked month at all.
Instead of editing inside the sealed period, Kiravy books the reversal in the current, open period. The original document stays where it was (in the locked month, untouched), and a mirror entry in today's books cancels out its effect. The two net to zero across the books without ever reopening what you closed. This is the only kind of entry allowed to reference a locked month, and it's exactly the behaviour an auditor expects: you don't rewrite history, you correct it forward.
If you genuinely need to change something inside a locked month — not just unwind it — you have to unlock the period first, make the change, then lock it again. Unlocking reopens the month for all the usual postings.
Every lock and unlock is recorded
Each time a period is locked or unlocked, Kiravy writes it to the activity log — who did it, which month, and when. Closing and reopening the books is a controlled action, and the log is the record that it happened.
This isn't the month-end review
It's worth separating two things that both happen around month-end:
| Period lock | Month-end close |
|---|---|
| A ledger control — it physically blocks postings into a closed month. | A review workflow — working through transactions, checking categorisation, signing off. |
| Owner / admin only; one toggle per month. | The systematic review pass a team does before they consider a period done. |
| Enforced by the books. | A process you follow. |
You typically run the month-end close review first, and once you're satisfied the period is right, you lock it here to keep it that way.
What's next
- Month-end close — the review workflow you complete before locking
- Journal entries — how a reversal corrects a locked period from the current month
- Payments & refunds — voiding a paid document dated in a closed month