Why your systems disagree at month-end, and how to make them tie out
Theoretical Enterprises · September 23, 2026 · 7 min read
If closing the month takes a week, the cause is rarely the accounting software. It is that three systems each hold a version of the truth, and someone has to find out why they differ. The reasons are predictable, and a system designed with the books in mind avoids most of them.
Where the differences come from
When the order system says one number and the ledger says another, it is almost always one of these.
- Timing. The order system counts a sale when the order is placed. The ledger counts it when it is invoiced, or shipped, or paid. Each is defensible; disagreeing about which is the problem.
- Edits after the fact. An order changed after it was posted to the ledger, with nothing flowing back. The systems agreed on the day, and drifted after.
- Missing dimensions. Revenue by branch in one system, by salesperson in another, with no shared key, so the totals match and every breakdown does not.
- Rounding and tax. Two systems computing tax or discounts slightly differently, producing pennies of variance on every line and real money across a month.
- Manual entries. Anything typed in by hand is an entry that exists in one system only.
The double-entry idea, applied to systems
Double-entry bookkeeping has survived for five centuries because it makes errors visible: every movement of value is recorded twice, and if the two sides do not balance, something is wrong. The same discipline works for connected systems. Every transaction that crosses from one system to another should carry an identifier that both sides keep, so that for any entry in the ledger you can point to the order, shipment or payment that produced it, and for any order you can point to its entries.
With that link in place, reconciliation stops being a search. It becomes a report: here are the orders with no ledger entry, here are the entries with no order, here are the pairs whose amounts differ. Those lists are usually short, and each line tells you exactly what to fix.
Design rules that make systems agree
Whether you are building an integration or choosing software, these are the rules that matter.
- One system owns each fact. Customers live in one place, prices in one place, the chart of accounts in one place. Everything else references them.
- Post events, not snapshots. Send "order 2291 shipped" rather than "today's totals". Events can be replayed, audited and reversed; totals cannot.
- Carry the reference. Every posting includes the source system and record identifier, stored in a field the ledger keeps.
- Agree on the recognition date. Decide, once, which event drives the period an entry lands in, and apply it everywhere.
- Lock closed periods. A late edit creates a new entry in the current period, never a change to a closed one.
- Never post twice. Integrations retry when something fails; the ledger must recognize a repeated posting and ignore it.
What a fast close looks like
When systems are built this way, month-end becomes a review rather than an investigation. The exceptions report is run, the handful of mismatches are explained or fixed, and the books close in days rather than weeks. The numbers an owner sees mid-month are the same numbers the accountant signs off on at the end, because they come from the same entries.
None of this requires replacing everything. Often it starts with one integration, built with these rules, between the system that generates the most entries and the ledger. The difference at the next close is usually enough to justify the rest.