Month·End·Close
← Month-End Close

Flux & Variance

Month-end flux, start to finish

This period against last period. Four of the five tests that decide whether commentary survives review are arithmetic. One still needs a person.

Month-end flux analysis compares each account's current-period balance against a prior actual period — last month, the same month last year, or year to date — and explains what the movement says about the business. It is actual against actual, which is what separates it from a budget comparison.

The package lands. You open the flux tab, read down the commentary column, and send three accounts back. The note you write is some version of needs more detail.

That hour gets filed under judgment — the part of review that takes experience, the part that supposedly can't be handed to anyone else. Most of it isn't. Most of what sends a note back is arithmetic that nobody wrote down, done in your head, at speed, on a paragraph that was never built to be checked.

I've written up the full version of that hour separately: what a reviewer is actually doing when they read flux commentary. This page is the shorter answer, plus where to go for each piece.

What month-end flux is, and what it isn't

The term gets used for several different comparisons and they aren't interchangeable.

The one this site is built around is this period against the last actual period. Current month versus prior month, on the balance sheet and the income statement, using posted balances on both sides. It's the most common starting point, and it's the comparison the rest of this cluster is written against.

It isn't the only comparison in real use, and which ones a given company runs varies. Same-month year-over-year is standard practice almost everywhere — most businesses want to know this August against last August, not just against July, because MoM alone can't separate a real change from normal seasonal movement. Income statement accounts often get a year-to-date view alongside the monthly one. Balance sheet accounts are frequently compared against the prior fiscal year-end rather than, or in addition to, last month. Each of those asks a genuinely different question, and the mechanics of explaining a YoY or YTD variance aren't identical to a MoM one.

Budget versus actual is a different question again — it tests a forecast, and the answer often lives with the budget owner rather than in the ledger. Plenty of close packages include it; the point is that it answers a different question from the ledger comparisons above, and the two get conflated more often than they should.

Everything on this site is written against MoM specifically, since it's the one every close runs regardless of what else gets layered on top. The reasoning mostly transfers — a driver still has to be named, sourced, and add up to the movement, whatever the movement is measured against — but the specific mechanics of YoY and YTD comparisons aren't covered here yet.

Five properties, four of them computable

Commentary that survives review has five properties. It is quantified, directional, sourced, specific, and causal.

Four of those five are arithmetic or string matching. Only the last one needs a person.

The reason review doesn't feel that way is the container. A paragraph has no addends. You can't sum a sentence, so you sum it in your head and file the result as an impression. Change the container — driver lines with what happened, how much, and where to look — and four of the five stop being opinions and start being formulas.

There's a version you can run in the browser: enter your driver lines and see which tests they pass.

Why commentary gets sent back

Almost always one of three, and almost never because the numbers are wrong.

It restates the number. Saying an account increased by the amount it increased is the variance, not the explanation of it.

It doesn't distinguish timing from a real change, where that distinction matters. Not every movement is one or the other — accounts move for plenty of reasons that are neither. But when a movement will reverse next month and the commentary reads as though it's the new baseline, the reader draws the wrong conclusion about what to expect.

It isn't complete. The drivers named cover part of the movement and the rest is unexplained. Not wrong, just short — and short in a way that's invisible until someone adds it up.

More on each of those, with examples: why flux commentary gets rejected.

What the control actually tests

Worth being honest about this, because it explains why the bar never transfers between reviewers.

Most flux controls test two things: that an explanation is present, and that a second person signed off. Neither of those tests whether the explanation is any good. Quality stays unwritten, which is why commentary gets rewritten by whoever reviews it rather than corrected, and why a new preparer learns the standard by having work returned rather than by reading it.

More on the gap between testing that commentary exists and testing whether it's any good.

What movement-based review doesn't see

Flux looks at accounts that moved. That's the design, and it's also the gap.

An account that should have moved and didn't produces no variance, so it never reaches the queue. A reclass inside the same account family nets to nothing at the level you're reviewing. An accrual that reversed and re-booked flat leaves no trace at all.

What flux review doesn't catch.

There's a related scale problem. A percentage-only threshold flags a small account that swung a lot in proportional terms and nothing in dollar terms, while a large-dollar move sitting inside an already-large account clears the percentage test and never surfaces. The mechanic that works is a dollar floor and a percentage together, as an AND gate, with a per-item floor underneath it.

More on small charges in large accounts, and the thresholds are in the tools.

Two systems that were never built to agree

The operational report says one thing and the ledger says another, and both are internally correct. Different cut dates, different inclusion rules, different definitions of the same word.

You're explaining the ledger movement. Source the driver from operations, name the source, and move on — don't spend close reconciling two systems that were never designed to tie.

Two sources, one number.

Some accounts can be explained from the detail. Some can't.

This is the practical constraint on automating any of it.

Some accounts carry the reason in the transaction detail, already labeled — the description field says what happened and you just read it. Some require compiling the detail first and then interpreting it, which is slower but still possible from what's in the system. And some accounts have no reason in the ledger at all: the driver is a decision somebody made, recorded nowhere, and the only way to get it is to ask.

Knowing which of the three you're looking at, before you start, is most of the time savings.

Why some accounts can be explained from the detail and others can't.

Everything on this site, in order

The pieces below go deeper on each part of the above. Read in any order — each stands alone.

Getting the population right

Writing commentary that holds up

Timing and sequencing

The entries underneath

Agents in the close

Where to start

CloseOps is productivity software and a documented working method. It is not an audit, a review, a compilation, or any other assurance service, and nothing it produces is accounting advice or an opinion on your financial statements. It helps you run a repeatable close and evidence that you ran it. You remain responsible for your accounting, your judgments, and your numbers.

Related: four of the five tests are arithmetic, and a live grader. Found something wrong or missing? Tell me here — anonymous, thirty seconds.