Flux & Variance
Explaining a line that isn't an account
You finish your own flux, then the reporting package asks you to explain lines that don't exist in your ledger — each made of several accounts, and sometimes measured against a different comparison than the one you just ran.
Where a reporting package is built on financial statement lines rather than accounts, one line on the package maps to several accounts in your trial balance, and the movement you have to explain is the sum of what those accounts did.
Which sounds like a formatting problem and isn't. It changes what a driver is, and it can change what the comparison measures — which together determine how much of any commentary you've already written is usable.
Your drivers stop being transactions
At the account level, a driver is a business event: a shipment, a renewal, an accrual release. At the rolled-up level there's a step in front of that.
First you need to know which of the constituent accounts actually moved. That part is arithmetic — filter the trial balance to the accounts mapped to that line and compare them on whatever basis the package uses. It tells you whether one account drove nearly all of the line or whether three contributed, which determines how much work is left. One dominant account is a much shorter job than three partial ones.
Then, for the accounts that moved materially, you still have to find out why — and that means going into the detail. Pivoting that detail is a way to see the movement by category, vendor, or whatever dimension the account is organized around, rather than reading down the lines one at a time looking for something large enough to matter.
The events still matter and you end up naming them. You just reach them through the account layer instead of starting there, and for a line made of several accounts that detour is most of the time cost.
The comparison basis may change too
This is the part worth checking before you start, because it determines how much of your existing commentary is usable.
The comparison your internal review runs and the comparison the group package runs are not necessarily the same one. Month over month, year-to-date against prior year-to-date, and actual against budget all appear at both levels depending on the company. Plenty of places run more than one at each level.
Where they line up, your commentary largely transfers and the rolled-up version is a summarizing exercise. Where they don't — where you've just finished explaining this month against last month and the package asks for the year against last year — you're answering a different question, and that's the case worth planning around.
Sometimes a single large current-month movement is big enough to drive the full-year variance, and then the work does transfer anyway. Often it doesn't: the year-to-date movement is the accumulation of things that were individually unremarkable month to month, and none of the monthly commentary addresses it.
When that's the situation, the year-to-date explanation is new work — done by going back into the larger constituent accounts and finding what moved across the whole period rather than in the current one.
Accounts that never needed commentary suddenly do
A materiality threshold applies at the level it's set. An account can sit below yours all year, generate no commentary, and attract no attention — entirely correctly.
Roll it up with its siblings and the combined line clears a threshold. Now there's a variance to explain, and part of it comes from an account nobody has written a sentence about, because at its own level it never warranted one.
This is the same shape as a threshold missing something by design, moved one level up. The threshold worked. It just wasn't measuring the population that ends up being reported.
Partial offsets are the awkward case
Two accounts in a line move substantially in one direction. One or two others move against them, not enough to cancel out.
If they offset cleanly, the line wouldn't flag at all and the question wouldn't arise — which is its own gap, and a quieter one. The awkward case is the partial version: the line still flags, but the net number you're explaining is smaller than any of the individual movements behind it.
So the honest explanation has more moving parts than the number suggests, and you have to decide how many of them to name.
How much to explain
There's no rule that survives contact with a close calendar here, and it's worth being direct about why.
Explaining every movement inside every rolled-up line is not a bar most closes clear. The lines that flagged have to be addressed, and under a normal close calendar there is little capacity left over. A package that asks for an explanation per line is asking what moved the line — a narrower question than a complete decomposition of everything inside it.
What seems to work in practice: name what accounts for most of the movement, name a counter-movement when leaving it out would make the explanation misleading, and stop. If a reader would draw the wrong conclusion without knowing something, it belongs in. If it only adds precision, it usually doesn't.
That's a judgment, not a formula, and it's the same judgment nobody writes down anywhere.
Depth is a property of the audience
The commentary that satisfies an internal reviewer and the commentary that goes to a parent are often not the same commentary, and not just in length.
Where the two differ, the difference is often in what counts as enough. A reviewer close to the accounts may want the specific event, the amount, and where to verify it. A reader several levels up may want the shape of the movement — what direction, roughly why, whether it continues. Sending the detailed version upward isn't more rigorous when that's the case; it's harder to read and answers questions nobody asked.
Writing at the wrong depth is its own failure mode in both directions. Too little internally gets the schedule returned. Too much at the group level buries the point.
On budget commentary specifically
"Coming in above budget" restates the variance rather than explaining it, the same way restating the movement does at the account level.
A budget variance is the gap between an assumption and what happened, so the explanation that carries information names which assumption didn't hold — volume, rate, timing, or something that was never in the budget at all. That isn't always knowable from the ledger, and when the assumption genuinely sits with whoever built the budget, saying so is more useful than guessing at it.
Where commentary does carry
Worth ending on the part that works, because it's most of the package.
Commentary written at the line level can be more stable month to month than account-level commentary, because it describes shape rather than individual events. Where a line is driven by a continuing trend, the prior explanation updates rather than gets rewritten.
The new work concentrates in a few places: lines that flagged for the first time, lines where the driver changed rather than continued, and the accounts that only became material through aggregation. Those are worth identifying first, because everything else is an update pass and goes quickly.
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: the full process in month-end flux, start to finish, flux flags what moved — the exceptions are structural, why restating the number isn't explaining it, and why your commentary keeps getting rewritten.
Found something wrong or missing? Tell me here — anonymous, thirty seconds.