Flux & Variance
When the operational report and the GL don't agree
Two systems compute what is nominally the same figure. Both are internally correct. They do not tie, and the difference is not an error — which makes explaining the variance harder, not easier.
There is a particular kind of stuck that happens on accounts backed by an operational system.
You pull the report the business actually runs on — the one operations quotes in meetings, with its own view of volume, mix, rate or margin. You pull the general ledger. You put them side by side expecting to source your explanation from the operational detail, and the two figures disagree by an amount large enough that you cannot ignore it and small enough that nothing is obviously broken.
Nobody made a mistake. That is the part that makes it hard.
Where the difference comes from
Systems that were built for different purposes measure different things, even when the field names match. The usual sources of divergence:
| Cause | What it looks like |
|---|---|
| Different cutoffs | The operational system closes on activity date, the ledger on posting date. The same transaction lands in different periods depending on which you ask |
| Different classification | An item the business groups one way is mapped to a different account for reporting. Neither mapping is wrong; they answer different questions |
| Adjustments that exist only in the ledger | Reserves, accruals, allocations and reclasses that have no operational counterpart because they aren't operational events |
| Adjustments that exist only operationally | Estimates, allocations or normalizations the business applies for its own management view, never posted anywhere |
| Different populations | One source includes something the other excludes — intercompany, a discontinued segment, a category handled outside the main flow |
This shows up anywhere an operational system computes something the ledger also computes. A payroll system against payroll accounts, with different pay-period boundaries. A warehouse system against inventory, with different receipt-timing conventions. A billing system against revenue, with different cutoff rules. A cost or margin report against cost of sales. The specifics vary; the shape doesn't.
The mistake worth avoiding
The instinct is to reconcile the two sources fully before writing anything. Occasionally that's the right call. Usually it isn't, and it's how an hour becomes an afternoon.
A full reconciliation between two systems that were never designed to agree is a project, not a close task. If the difference is structural and recurring, you will rediscover the same bridge every month, and the bridge will not change what you write in the commentary field.
Those are different questions and only the second one has to be answered tonight.
Working the account instead
Establish the difference once, not monthly. If you can characterize why the two sources diverge — cutoff, classification, ledger-only adjustments — you generally don't need to requantify it each period. What you need to know is whether the difference is stable. A structural gap that sits in roughly the same place every month is background. A gap that moved is the finding.
Explain the ledger movement, source from the operational detail. The variance you are explaining is the one in the financial statements. The operational report is where you go to find out what happened, not what you are reporting on. Keeping that straight resolves most of the confusion, because it stops you trying to make the two numbers agree in a commentary field.
Take the drivers that survive the difference. If the operational data shows a genuine shift — volume, mix, rate, whatever the business actually moved — that shift is real regardless of whether the two totals tie. It caused part of the ledger movement even if it doesn't account for all of it. Use it, and size it against the ledger number rather than the operational one.
Say which source you're describing. If a figure in your commentary came from the operational report, name it as such. A reader who later pulls the ledger and gets a different number needs to know the difference was intentional, not an error you failed to catch.
What not to do
Do not quietly use whichever number makes the commentary work. It's tempting when one source produces a clean story and the other doesn't, and it produces commentary that reads well and cannot be reperformed — which is the failure the sourcing test exists to catch.
Do not present an operational figure as though it were the ledger's. Same problem, one step worse, because now the reviewer has no signal that two sources were even involved.
Do not treat the residual difference as your unexplained remainder. If part of the gap is structural and known, it isn't unexplained — it's characterized. What's left after removing it is the real residual, and that's the number worth chasing.
Why this stays manual
Elsewhere on this site there's an argument that most of the difficulty in a flux account is retrievability — whether the reason for the movement is identifiable in the detail or has to be chased somewhere else. Accounts like this are a distinct case, and a harder one.
The data is retrievable. Both sources are sitting right there. What can't be automated is the arbitration: knowing which of two correct numbers to describe, and which movements in one are visible in the other. That requires knowing why the systems differ, which is institutional knowledge rather than data.
A tool given both sources will confidently reconcile them, because reconciling is what it looks like the task is. It has no way to know that the difference was designed in.
The thing that would actually help
Write down, once, why the two sources differ.
Not a monthly bridge — a short standing note: these are the structural reasons this report and this account don't tie, this is roughly how large each one is, this is what would make it change. A page, maintained about once a year.
Almost nobody has this. It gets re-derived every month by whoever is preparing the account, and lost again when they move on. It is the same pattern as commentary that gets rewritten by a reviewer and never recorded: an organization paying repeatedly for knowledge it already produced.
If you work this in Excel: the free flux template flags what needs explaining and shows the residual your drivers don't cover. The CloseOps Flux & Variance System ($79) starts from your trial balance instead: confirm each account's classification and it builds the income statement and balance sheet flux statements, then ranks what to investigate.
Related: where this sits in month-end flux, start to finish. Also when the general ledger doesn't match the trial balance, why some accounts can be explained from the detail and others can't, and four of the five tests your flux commentary fails are arithmetic.
This describes a working method, not accounting advice, and nothing here is an assurance service. No company data appears in this piece.
Found something wrong or missing? Tell me here — anonymous, thirty seconds.