How the period data arrives
This system will only ever be as good as what it is fed, and there is one input decision that determines whether it is useful or merely arithmetic: whether you give it a trial balance or the transactions behind it.
Key takeaways
- A trial balance gives you the variance; only transactions give you the reason.
- The minimum row is code, date, amount, description and source document.
- Periods get restated after they close, and the system has to absorb that.
- A restated period is re-imported whole, never patched, and the report is regenerable.
- The import is idempotent, so a re-sent export changes nothing.
Transactions, not balances
A trial balance tells you repairs was £2,400 over budget. The transactions tell you £2,150 of that was one compressor. Those two facts lead to entirely different conversations, and only the second one is worth having.
code 6210 the nominal account
date 2026-07-11 the posting date
amount 2150.00 signed
description Compressor repair — unit 2
source PINV-4471 the purchase invoice reference
supplier Ashford Plant where available
period 2026-07 which period it was posted into
The period field being separate from the date is not pedantry. A transaction dated 28 June and posted into July is exactly the kind of thing that produces a false variance in both months, and having both fields is what lets the timing filter recognise it.
The import
- Storage
- Database
- App integration
- Machine learning
- Management
- People
Restatements
Periods are reopened. An accrual is corrected, a misposting is fixed, a late invoice is dated back. In a small business this happens to roughly one period in three, and it usually happens after a report has already gone out.
So a re-import of a period already imported is a restatement, not an error. The whole period is replaced — every transaction, not a diff — and both versions are kept. The report for that period is regenerated, and it says at the top that it is a restatement with the date of the original. That last sentence is what stops two different versions of July circulating with no way to tell them apart.
Why replace whole
Patching an import — applying only the rows that changed — requires knowing which rows changed, and accounting exports rarely carry stable row identifiers. Two imports of the same period with a corrected misposting will differ in ways that are hard to diff correctly, and a wrong diff produces a ledger that is subtly wrong in a way nobody will find. Replacing whole is boring, obviously correct, and costs nothing at these volumes.
Idempotency
- Machine learning
- Management
- Analytics
Next: how a budget gets shaped so that it does not manufacture variances all by itself.
All posts