A month-end close that takes eight days is not a diligence problem. It is a design problem, and it is nearly always one of four things. In the order we find them:
1. The system reports on transactions instead of posting entries
Most booking and order systems produce financial reports by summing their own transaction tables. Revenue is calculated at the moment somebody asks for it, rather than posted at the moment it is earned. That works until two things happen: a figure is questioned, and nobody can show how it was arrived at.
The test is simple. Pick a revenue number from last month and ask for the individual entries behind it. If the answer involves opening a report and re-running a filter rather than pointing at journal lines, you have a reporting layer, not a ledger. Everything downstream of that is reconstruction, and reconstruction is what takes the week.
2. The same figure is entered more than once
Operations records a booking. Finance records an invoice. Somebody records a payment against a bank statement. If those are three separate acts of typing rather than one event with three consequences, they will disagree, and the close becomes the process of finding out where.
Count the handover points. Every place a number is retyped rather than derived is a place the close will stall.
3. Multi-currency is being handled in a spreadsheet column
A business earning in one currency and paying in another needs exchange differences posted, not calculated. If your currency handling lives in a column somewhere, the trial balance will not agree with the bank, and the difference will be explained rather than eliminated.
We re-based an entire travel ERP general ledger from GBP to SAR without losing historical journals. The hard part was not the conversion. It was that the original design treated currency as a display preference rather than a property of the transaction.
4. There is no audit trail on the writes that matter
When a figure changes and nobody can say who changed it or when, the close absorbs the time it takes to establish that. An audit trail on financial and permission writes is cheap to build in and expensive to retrofit, and its absence shows up as an eight-day close long before it shows up as an audit finding.
What to do about it
In order of return:
- Establish whether you have a ledger or a report. This determines whether the fix is configuration or architecture, and it is a twenty-minute conversation with whoever built the system.
- Map the handover points where a figure is retyped. Each one is a candidate for elimination and most are cheaper to fix than they look.
- Do not start with reporting. Building better reports over unreliable records produces confident wrong answers faster, which is worse than slow uncertain ones.
And an honest caveat: if your process is genuinely standard, an off-the-shelf accounting package with a proper ledger may solve this for a fraction of what a custom build costs. We say so when it is true, because a custom build that should not have happened is the most expensive outcome in this category.