Flux & Variance
What flux review doesn't catch
Flux review is one of a handful of controls routinely offered as the mitigating layer when a finding surfaces. Its detection mechanism is movement — and a narrow class of errors doesn't move anything.
When a control finding surfaces, attention turns quickly to what else in the process might have caught the issue. A small number of controls get reached for repeatedly in that conversation — flux review, account reconciliations, journal entry review. They share a useful property: they operate broadly and recur every period, so it's plausible to argue that any given error would have passed through one of them.
That reliance is mostly reasonable. It's worth being precise about where it isn't — specifically for flux review, whose detection mechanism is narrower than its coverage suggests.
Start with what the design actually does
Two things are true and often skipped when this topic comes up.
Thresholds aren't an oversight. A variance control is deliberately scoped to movements above a stated threshold, so review effort lands where it's proportionate. An account below that line isn't being ignored — it's outside the designed population, on purpose. That scoping is normally established during risk assessment, not at close.
Recurring entries are usually covered elsewhere. In most environments, standing entries sit on a close checklist requiring completion and sign-off before the period closes, often with a control over the checklist itself. The failure mode where a recurring amortization entry simply never posts is one the process is already built to prevent. Less mature environments vary, but that's the guiding design.
So the naive version of this concern — what if a recurring entry doesn't post and no variance flags it — is largely addressed before flux review is ever reached.
Where the residual actually sits
Misclassification between similar accounts
An entry coded to the wrong account within the same family — one contra-revenue bucket instead of another, one expense category instead of its neighbor. The aggregate is right. Both accounts may sit within threshold, so neither flags. Nothing in a variance review asks the question.
This is the most realistic of the three, because it doesn't require anything to fail. The entry was prepared, reviewed, and posted. It just landed one row over.
Entries outside the recurring population
The close checklist covers what's expected every month. One-off entries — a correction, an adjustment arising from a specific event, something that only happens under a particular condition — carry no standing expectation.
No line goes unsigned when a one-off entry isn't made, because nobody was waiting for it. If its absence also produces no variance, nothing surfaces it.
The information gap between preparer and reviewer
This one is structural rather than procedural, and it's the least discussed.
The person writing flux commentary is frequently not the person who prepared the underlying entry. They can see what posted. They generally cannot see what should have posted — what went into the accrual calculation, what was left out, what judgment was applied.
A completeness question therefore sits outside what the flux preparer can reasonably answer from the schedule in front of them. They are reviewing output with no visibility into input.
What to actually do with this
Not much, most months. This is a low-frequency residual, not a daily risk, and treating it as one would cost more time than it saves.
What it's worth is a short pass on the accounts where the conditions overlap:
| Where to look | Why |
|---|---|
| Families of similar accounts | Where several accounts serve related purposes, a coding error between them nets to nil at the family level and may clear no threshold individually |
| Accounts moved mainly by judgment entries | Reserves and estimates where the balance depends on a calculation not visible from the ledger. The number posted may be incomplete and the schedule cannot tell you |
| Accruals that reverse and re-book | A reversal plus a similar new accrual nets close to flat. The account looks stable while its composition changed entirely |
| Anything you know had activity | If you're aware something happened in the business and the related account didn't respond, that gap is worth a question regardless of what the report flagged |
The last row is the general form of all of this. The variance report answers what changed. Anything you know independently of the report is information the report doesn't have.
A note on honesty
This is a reasoned risk rather than a war story. In practice these are rarely caught by flux review — which is partly the point. The design mitigates most of it upstream, and what remains is genuinely hard to see from a variance schedule.
It's worth understanding mainly because of how flux review gets characterized when it's offered as a mitigating control. Breadth invites the assumption that it would catch most things. It catches most things that move. That distinction is worth holding onto when someone reaches for it as the compensating layer.
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. Also the same blind spot, one layer earlier — when the source report never had the full population to begin with. Also a recurring entry's design going stale, and why flux commentary gets sent back.
Found something wrong or missing? Tell me here — anonymous, thirty seconds.