The Month That Needed a Second Key
Closing a month is easy to do and easy to undo, and the undo is the part an auditor asks about. A closed month now reopens only on a request with a reason that somebody else approves, every posting made while it is open again is written down, and each close stores a copy of the books that nobody can change.
The accountant at a Mombasa freight forwarder closed September on the 9th of October. On the 22nd a clearing agent’s invoice for September turned up, KES 412,000, and she reopened the month, posted it and closed it again before lunch. Nothing she did was wrong. But when the auditor asked in February why September’s cost of sales moved after it was reported, the only person who could explain it was the person who had moved it.
That is the problem with a reopen that one person can do alone. It is not that anyone is dishonest. It is that the explanation lives in a head, and the record shows a month that was closed, open and closed again with nothing in between. Three changes made on 29 October fill in the middle.
A reopen is a request, and somebody else says yes
On Accounting → Month-end Close, a closed month shows Ask to reopen where the Close button was. The request needs a reason, and the reason is stored with it. The month stays closed while the request waits: nothing can be posted into it yet.
-
Ask, with a reason
“Clearing agent’s September invoice arrived late.” Only one request per month can wait at a time, so two people cannot open the same month for two different reasons.
-
Somebody else decides
Approving needs the reopen-approval permission, and the person who asked cannot approve their own request while anyone else in the workspace could. The approver can add a note, or decline. The person who asked can also withdraw it.
-
The approvers are reminded
Everyone who may approve, except the person who asked, gets a daily reminder by email and in the bell with the month and the reason, until the request is decided.
-
The month opens
Approval opens the month for posting, and the request, the reason, who asked, who approved and when are written to the audit log.
A workspace with one accountant
Some organizations have exactly one person who can approve a reopen. Making them wait for a second person who does not exist would only teach them to keep months open. So when the person asking is the only one holding the permission, the request is approved at once — and the record says so in words: approved by the requester, because nobody else in the workspace can approve a reopen. An auditor reads that line and knows which control was in force.
Everything posted while the month is open again is written down
Once a reopen is approved, every posting dated inside that month goes on the audit log as it lands: which posting, what kind, which module it came from, its total, and the reason the month was reopened. It does not matter whether a person posted a manual journal or a late supplier bill posted itself. The rule sits on the posting, not on a screen.
The close page then lists them under Posted after the first close: each posting’s number, its date, its total and when it was made. That is the fifteen-minute review a finance lead should do before closing the month a second time, and it is on the same page as the Close button.
A reopen that needs a second person is a conversation. A reopen that leaves a list behind is a conversation somebody can read later.
A copy of the books at every close
Every time a month is closed, AWRA stores an evidence pack for it. Nobody can change a pack once it is stored. Closing the same month again stores the next version beside it, so September closed twice has version 1 and version 2.
| What the pack holds | Why an auditor wants it |
|---|---|
| The month’s trial balance, income statement, balance sheet and cash-flow totals | What the books said at the moment of the close |
| The balance sheet to the end of the month | The position you reported, not a re-run |
| The ledger integrity checks as they stood | Whether anything was out of balance when the month was signed off |
| The checklist: each check, each step, its owner, done or skipped, by whom and when | Who did the close work, not just who pressed the button |
| Every approved reopen, with its reason, who asked and who approved | Why the month was opened again |
| Postings made after the first close | What moved while it was open |
| The previous version’s number and checksum, and what changed since it | How version 2 differs from version 1, line by line |
Each pack carries a SHA-256 checksum, shown on the close page next to its version and date, and written to the audit log when the month closes. Download a pack and you get the stored data file (JSON) exactly as it was captured, with the checksum in the download, so anyone can check that the copy they hold is the copy that was stored.
September, closed twice
Illustrative. Version 2 does not replace version 1; both are kept.
The checklist now has owners and a calendar
The steps on the close checklist can each have an owner, a due day counted from the end of the month, and a step they depend on. A step that depends on another cannot be ticked until that one is ticked or skipped, so the VAT review cannot be marked done before the bank reconciliation it relies on. When a step passes its due day unticked, its owner is reminded weekly, by email and in the bell, about their own steps only.
By default the checklist still informs the close rather than blocking it. The person allowed to close may know something the list does not. What has changed is that the pack records what they closed over, by name: a month closed with two steps open says which two, and whose they were.
A workspace whose policy is that the list decides can now switch on a close block in Accounting Defaults. With it on, an unticked step or a failing high-severity ledger check (or, if you choose, any failing check) refuses the close. Someone holding the override permission can still close, with a written reason that goes on the audit log and into the evidence pack beside what was open.
The full close routine is in the Month-End Close guide and on the month-end close page. How closing locks the ledger in the first place is in The Close That Is a Lock as Well as a Note, and the wider set of rules is on the accounting controls page.
Four questions about your own close
Who can reopen a closed month on their own?
A good answer sounds like
Nobody, unless they are the only person who could approve it, and then the record says so.
What it tells you
A reopen one person can do alone is a reopen nobody else hears about.
What was posted into last quarter after it was closed?
A good answer sounds like
A list, per month, from the close page or the audit log.
What it tells you
If the answer is a search through journals, the review is not happening.
What did the books say at the moment you closed June?
A good answer sounds like
The June evidence pack, with its checksum.
What it tells you
A re-run of June today answers a different question.
Whose close steps were late last month?
A good answer sounds like
Named owners, each told about their own.
What it tells you
A checklist with no owners is everybody’s, which is nobody’s.
What AWRA OpsHub does today
- Reopening as a request with a reason, one waiting per month, that somebody other than the requester approves or declines, with an optional note.
- A recorded fallback for a one-approver workspace: the request is approved at once and the record says why.
- A daily reminder to every possible approver except the requester while a request waits.
- Every posting dated in a reopened month written to the audit log, and listed on the close page as posted after the first close.
- An evidence pack at every close, versioned, checksummed with SHA-256, unchangeable once stored, and downloadable as captured, as a JSON data file.
- Close steps with owners, due days and dependencies, and a weekly reminder to each owner about their own late steps.
- The same rules through the API, so a reopen requested from any connected tool needs the same reason and the same second person.
- Reopen requests in the AWRA mobile app: ask to reopen a month, or approve or decline someone else’s request, with a connection.
- A close block you can switch on, off by default: open steps and failing high-severity checks, or every failing check, refuse the close, and an override needs its own permission and a written reason, kept in the audit log and the evidence pack.
More we can add to your workspace
- The close evidence pack in the mobile app, beside the reopen requests already there.
- An evidence pack rendered as a formatted PDF, for a reader who wants a document rather than a data file.
- A reopen window that ends on its own, closing the month again after a set number of days unless somebody extends it.
- A close-progress view across several months, so a finance lead sees every open step for the quarter on one page.
Where we point you to a specialist
- The close block stays off until you switch it on. That is a position, not an oversight: a checklist that forbids is easily satisfied by ticking boxes, and the person allowed to close is the one accountable for closing over an open step. Where your policy says otherwise, the block is there and every override is written down.
- Whether a late invoice belongs in the closed month or the current one is your policy and your auditor’s. The system records the request, the approval and what moved; it does not make that call.
The PDF evidence pack and a self-closing reopen window are each small pieces of work on records the workspace already keeps.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsMonth-end close in AWRA
The close checklist with owners and due days, the period lock, reopen requests and the evidence pack stored at every close.
Read the feature pageFrequently asked questions
Can one person reopen a closed accounting month in AWRA OpsHub?
Not on their own when anyone else could approve it. Reopening is a request with a reason, and somebody other than the person who asked has to approve it. If the person asking is the only one in the workspace who holds the reopen approval permission, the request is approved at once and the record says that is why.
Is posting into a reopened month recorded?
Yes. Every posting dated inside a month while it is reopened is written to the audit log with the reason the month was reopened, and the close page lists those postings as posted after the first close.
What is a close evidence pack?
A stored copy of the month taken at the moment it is closed: the trial balance, statements, integrity checks, the checklist with owners and who ticked each step, any approved reopens and what was posted after the first close. It carries a SHA-256 checksum and cannot be changed. Closing the month again stores a new version beside it.
Does the close checklist stop a month being closed?
Only if you switch that on. By default it informs the close, and the person allowed to close the month decides. Turn on the close block in Accounting Defaults and an unticked step or a failing high-severity check (or any failing check) refuses the close; someone holding the override permission can still close with a written reason, recorded in the audit log and the evidence pack.
