Flux Analysis: The Complete Guide for Accounting Teams

Deepak Anchala
Co-Founder and CEO, Adopt AIOct 6, 2026
Every close has a moment where the preliminary trial balance exists and the question changes from "is it recorded" to "is it plausible." That moment is flux analysis: the account-by-account comparison of this period against the last one, with an explanation required for every line that moved more than it should have. The comparison itself takes seconds. Writing explanations a reviewer can actually check against source is what eats the rest of the week.
This guide covers what flux analysis actually is, how it differs from the two terms it gets confused with constantly, variance analysis and budget-to-actual, the process and the thresholds that make it a real control instead of a spreadsheet of excuses, how to write an explanation that survives review and holds up to an auditor, a worked example, and where the hours concentrate once you time the work instead of guessing. It is written for the controller or FP&A preparer who owns the flux review and the CFO who reads what comes out of it.
Scope note: this guide treats flux analysis as the period-over-period detective control performed during the close. The broader technique of explaining a result against any benchmark, including a budget or a forecast, is variance analysis, covered in full at that link and distinguished from flux analysis in the next section. For how flux fits inside the full close calendar, see The Month-End Close: The Complete Guide.
What flux analysis is
Flux analysis is the period-over-period review of every material general ledger account, performed during the close, with a sourced explanation required for every movement that clears a set threshold. "Flux" is short for fluctuation. The benchmark is always the prior period, usually last month, sometimes the same period last year, and the question is narrow and specific: did this account move more than it should have, and if so, why.
It exists to catch errors before the financial statements go out, not to evaluate performance or explain a budget miss. A double-posted invoice, a missed accrual, an allocation that ran twice, a journal entry booked to the wrong account: these show up as an unexplained movement in flux long before they show up anywhere else, which is why flux sits late in the close calendar, after the trial balance is preliminary but before the statements lock. It is a detective control, run every close cycle, not a planning exercise.
What makes an explanation real rather than decorative is the same standard a reviewer applies to a reconciling item: specific, quantified, and sourced to something a second person can check without calling the preparer. "Professional fees increased $180,000 because the ERP implementation began in March, per the signed statement of work" survives review. "Expenses increased" restates the number and proves nothing.
Flux vs. variance analysis vs. budget-to-actual: the family nobody separates cleanly
Three terms get used as though they were interchangeable, and treating them that way is what produces a flux review that nobody trusts and a variance review that nobody acts on. All three compare an actual result against something. What changes is the benchmark, the cadence, and the question being asked.
| Flux analysis | Variance analysis | Budget vs. actual | |
|---|---|---|---|
| Benchmark | The prior period (usually last month) | Any benchmark: budget, forecast, standard cost, prior year | The approved budget or plan |
| Cadence | Every close, without exception | As needed: management reporting, audit support, operational review | Monthly or quarterly, tied to the planning cycle |
| Question it answers | Did this account move more than expected, and is the ledger right? | Why did the actual differ from the benchmark, by how much, and what drove it? | Are we tracking to the plan the business committed to? |
| Primary audience | The reviewer signing off on the close | FP&A, operations, anyone explaining a result | The CFO, the board, budget owners |
| What triggers investigation | A dollar-and-percent threshold on the account's own movement | Materiality against whichever benchmark was chosen | A variance to plan beyond a tolerance the business set |
Variance analysis is the broader discipline: comparing an actual to any benchmark and decomposing the gap into named, quantified drivers. Flux analysis is the specific, close-time member of that family, always period-over-period, always run as a control rather than a management exercise.
A close process typically needs all three, performed by different people on different cadences, and a single workpaper trying to serve all three purposes at once is usually why none of them land well. Flux clears the close. Variance analysis explains the close's results to whoever asks. Budget-to-actual tells the business whether it is tracking to plan. Keep the three separate and each one gets sharper.
Setting thresholds: the two-dimension test
A threshold decided after looking at the results is not a threshold. It is a description of whatever someone already found interesting, and it is the single most common way a flux review loses credibility with a reviewer or an auditor.
A workable threshold has two dimensions, and both have to clear before a line gets pulled into the review. A percentage threshold alone flags every small account that moved from $100 to $300, a 200% swing that means nothing. A dollar threshold alone misses a 90% collapse in an account too small to clear a flat dollar bar but too meaningful to walk past, a reserve account that tripled, a vendor accrual that disappeared. Requiring both to be exceeded, not either one, is what turns the population into something a reviewer can actually work through in an afternoon instead of a week.
Set the thresholds once, per account class, before the period closes, not while staring at this month's numbers. Revenue and COGS-adjacent accounts generally warrant a tighter threshold than low-movement balance sheet accounts, which is the same risk-rating logic applied to reconciliation: the accounts where an error does the most damage get the closest look, and the ones that rarely move get a lighter, documented pass instead of the same scrutiny by default.
The flux process, step by step
The mechanics are the same at a five-person company and a five-hundred-account multi-entity close. What changes is volume.
| Step | What happens | Where it usually goes wrong |
|---|---|---|
| 1. Pull two clean periods | Current and prior trial balance, closed and final, not a preliminary export that will still move | Comparing a closed prior period against a current one that is still being adjusted, which creates phantom movement |
| 2. Compute the movement | Dollar and percent change, every account, both directions | Netting hides the real picture: a large favorable swing sitting on top of a large unfavorable one inside the same account reports as "roughly flat" |
| 3. Apply the dual threshold | Only lines clearing both the dollar and percent bar move forward | A threshold set after seeing the results, or one dimension applied alone |
| 4. Investigate the flagged lines | Pull the underlying detail: subledger, journal entries, the rollforward that drives the account | Investigating from memory instead of the actual source that produced the number |
| 5. Draft the explanation | Specific, quantified, sourced, and checkable without calling the preparer | "Expenses increased." Restating the number instead of explaining it |
| 6. Carry forward what recurs | A driver that repeats month after month gets recognized as recurring, not re-investigated from scratch | Every month treated as a first investigation, burning hours on the same answer repeatedly |
| 7. Flag what can't be explained | An unexplained line stays unexplained and visible, not quietly closed with a plausible guess | A placeholder explanation written to clear the review, which is worse than leaving the line open |
| 8. Review and sign off | A second person checks each explanation against its source before the period locks | Review that only checks whether a cell has text in it, not whether the text is true |
Two rules carry the whole process. An explanation has to be checkable without rebuilding it. If a reviewer has to re-derive the number to trust the sentence next to it, flux has not done its job. And an unexplained line is a finding, not a failure. The point of flux is to surface what does not add up before the statements ship, and a flagged, unresolved item that gets escalated is the control working exactly as intended.
Writing explanations an auditor will actually accept
Most flux explanations fail the same test: they restate the number instead of explaining it. "Travel expense increased due to higher travel" says nothing a reader did not already know from the number itself. A reviewer who accepts that sentence is not reviewing, they are rubber-stamping, and an auditor sampling the workpaper later will ask the question the sentence should have already answered.
A causal explanation names the driver, quantifies its contribution, and points at the support: "Professional fees increased $180,000 because the ERP implementation began in March, per the signed statement of work." A reader can verify every clause in that sentence without finding the preparer. Where more than one driver contributes, list each with an amount, and make sure the amounts sum to the total movement rather than gesturing at several causes collectively. Where the movement is one-time, say so explicitly, since a reviewer's next question is always whether it recurs.
A flux worksheet, start to finish
A short worked example. Real worksheets run to dozens or hundreds of accounts; this is the shape of four representative lines.
| Account | Prior period | Current period | $ change | % change | Clears threshold? | Explanation |
|---|---|---|---|---|---|---|
| Professional fees | $420,000 | $600,000 | +$180,000 | +43% | Yes | ERP implementation kickoff in March, per the signed SOW. One-time, not expected to recur. |
| Travel & entertainment | $38,000 | $41,000 | +$3,000 | +8% | No | Below the dollar threshold; not investigated |
| Rent expense | $95,000 | $95,000 | $0 | 0% | No | No movement |
| Bad debt reserve | $12,000 | $64,000 | +$52,000 | +333% | Yes | Single customer balance reserved following a Chapter 11 filing; see the collections memo for the balance and the basis |
Notice what the table does not do: it does not require an explanation for every account, only the ones that clear both parts of the threshold, and it states a one-time driver as one-time rather than leaving a reader to guess whether it recurs next month.
Where flux time actually goes
Time a flux cycle instead of assuming it is slow because the team is slow, and the hours land in a predictable, lopsided order.
1. Getting two clean periods of data. The prior period has to actually be closed, and the current period's preliminary trial balance has to actually be final enough to compare. Pulling the comparison before both sides are stable produces phantom movement that gets investigated and then dismissed, which is wasted effort before the real work starts.
2. Computing the movement itself. Mechanical, and the fastest step by far. This is the part that looks like "the whole job" to anyone who has not timed a flux cycle.
3. Investigating genuine drivers. Pulling the subledger detail, the journal entry, the rollforward, or the invoice that actually explains a flagged line. This is where judgment lives, and it does not compress no matter how efficient the rest of the process becomes.
4. Writing the explanation itself. Composing a sentence that is specific, quantified, and sourced takes longer than finding the underlying fact, especially across dozens of flagged lines in the same sitting.
5. Chasing an answer that lives outside finance. The reason professional fees moved is in a statement of work sitting in legal's inbox. The reason a vendor accrual disappeared is a conversation operations had with a supplier. Flux routinely needs an answer from someone who does not know a close is running.
6. Review and rework. A reviewer who cannot verify an explanation from what is written has to go find the source themselves, which is preparation wearing a review's clothes, and it shows up as a review bottleneck when the real cause was an unsourced sentence two steps earlier.
Notice what is nearly absent from that list: the comparison itself. Almost everything above is either pulling clean data, investigating, or writing, not the arithmetic that produces the variance column.
From flux to the board package
Flux is not the end of the line. A clean flux review feeds directly into the next thing the business actually reads: the management reporting package and, on a slower cadence, the board deck. An explanation drafted once for the close, specific, quantified, sourced, is the same explanation a CFO wants in front of the board instead of a second rewrite from scratch.
What AI agents change about flux analysis
Full disclosure: Adopt AI builds an agent that does this work, so read this section as the informed but interested party's view. It comes after everything above deliberately, because the process and the threshold discipline hold whether or not any of it is automated.
Recall where the hours actually go: pulling clean comparison data, investigating genuine drivers, and writing an explanation specific enough to survive review. The reason software historically helped with the first of these and almost none of the rest is that computing a variance column is trivial and writing a defensible sentence about it is not. A rules engine can flag a threshold breach. It cannot go find the statement of work that explains it.
An agent that can operate the systems where the evidence lives, the subledger, the contract repository, prior journal entries, changes what is reachable. Given two periods of trial balance data and a threshold, it computes every account's movement, applies the dual threshold, and drafts a causal explanation for each line that clears it, sourced to whatever record it pulled the cause from. What matters for the reviewer who signs the result:
- Every draft is sourced, not asserted. A drafted explanation links to the subledger entry, the contract, or the journal entry it was built from, so a reviewer checks the citation rather than re-deriving the number from nothing.
- What it cannot explain, it says so. A line without a clear, sourced driver is flagged as unexplained rather than filled with a plausible-sounding guess, which is the difference between a tool that helps a reviewer and one that creates new review work.
- Recurring drivers are recognized, not re-investigated. The same cause behind the same account's movement month over month gets proposed again rather than treated as a fresh mystery each cycle.
- The arithmetic runs in code, not in a model's head. The variance column is computed, not estimated by a language model reading two numbers; the model's job is the explanation, sourced to something a person can check.
- Nothing is final until a reviewer approves it. Every drafted line is a draft. The reviewer edits, rejects, or accepts, and the sign-off stays exactly where it already was.
For the specifics of how this runs against your own close, see Financial Reporting, or book a pilot and run it against the flux review you just finished, which is the only benchmark that matters.
How Adopt's Reporting Agent actually drafts a flux explanation
The claim above is only useful if the mechanism behind it holds up, so here is what actually happens, stated concretely.
It reads two periods of trial balance and computes the movement in code. The comparison runs as code your team can read, not as a model freehanding an estimate of what changed. The arithmetic is deterministic and auditable the same way a formula in a spreadsheet is.
It applies your thresholds, not a generic default. The dollar and percent cutoffs are configured per account class, matching the risk-rating logic this guide covers above, so the population that reaches a person is the one your own policy defines.
It investigates before it writes. For each flagged line, the agent pulls the underlying detail inside the systems you already use, the subledger, the contract, the prior period's journal entries, and drafts an explanation from what it actually found there rather than from a pattern match on the account name.
It cites what it used. Every drafted explanation links back to the source it pulled from, so a reviewer verifies the citation instead of rebuilding the investigation from scratch.
It remembers what recurs. A driver that explained the same account's movement last month and the month before is recognized and proposed again, with the autonomy for each recurring pattern set by your team, so a one-off explanation does not silently become an assumption nobody checks.
It runs where your data already is. Cloud on an isolated tenant, your own private cloud or VPC, or fully on-prem, on your choice of model. Deployment location is a configuration decision, not a reason to delay evaluating it.
Book a Pilot to run this against the close you just finished, or start free to try it against one account class first.
AI tools for flux and variance analysis, compared honestly
Flux is usually a feature bolted onto a broader close platform rather than a product's own focus, which is why coverage here is genuinely thin compared to reconciliation or AP. A short, honest list; category exemplars, not an exhaustive market scan, and verify current scope against your own workflow before evaluating any of them, including Adopt.
| Tool | Approach to flux specifically | Where it is strongest | Where the gap tends to be |
|---|---|---|---|
| Adopt AI | A dedicated Reporting Agent computes period-over-period movement, applies dual thresholds, and drafts sourced explanations from the underlying subledger and contract detail, flagging what it cannot explain rather than guessing. | Explanations sourced to evidence rather than pattern-matched from the account name; deployment in your own cloud or on-prem; one platform spanning flux, reconciliation, and the rest of the close. | Newer entrant to this specific capability; the strongest evidence today is per-engagement, not yet a large set of published, third-party-verified benchmarks. |
| Numeric | Flux and variance commentary as part of a broader close-and-reporting platform, with published customer proof on first-draft automation rates at specific accounts. | Modern-stack, high-growth and public companies already running a clean, API-accessible ERP and general ledger. | Same modern-stack orientation as its reconciliation and close capability; not built around legacy systems or accounts whose evidence sits in a no-API portal. |
| Maximor | Close automation including reconciliation and accrual work, with flux and variance treated as part of the broader close-execution claim rather than a named, separate capability. | Modern, API-accessible ERPs such as NetSuite and SAP. | No flux-specific published proof point found on public materials as of this guide's research; verify current scope directly. |
| FloQast / BlackLine | Close-management platforms: track whether the flux review happened, enforce the checklist, and increasingly layer AI on top. | Visibility into whether flux is on schedule and who signed off. | The explanation itself is still typically a person's work on these platforms; verify what is actually drafted versus only tracked. |
The build-it-yourself alternative, a direct model API key wired into a prompt against an exported trial balance, is a real and common first attempt at this specific workflow, because the inputs are structured and the output is prose. What it does not include out of the box is sourcing the explanation to an actual record rather than a plausible guess, flagging what it cannot explain instead of filling the cell anyway, and a review workflow more than one person can work in, which is what tends to get rebuilt by hand once the easy accounts are done.
The condensed flux checklist
Setup (once, then reviewed periodically)
- Dollar and percent thresholds set per account class, documented, not decided after seeing results
- Account risk tiers mapped to review rigor, tightest on revenue and COGS-adjacent accounts
- Worksheet format standardized: account, prior period, current period, change, threshold flag, explanation
Per cycle
- Both periods confirmed closed and final before the comparison runs
- Movement computed for every account, netted totals decomposed rather than reported flat
- Dual threshold applied; only lines clearing both dimensions investigated
- Every flagged line's explanation specific, quantified, and sourced to something checkable
- Recurring drivers carried forward rather than re-investigated from zero
- Unexplained lines flagged and visible, not closed with a plausible guess
Review
- A second person checks each explanation against its cited source
- Explanations sum to the account's total movement where more than one driver contributes
- Period does not lock until every line above threshold is explained or formally escalated
Related reading
Related workflows
Glossary
Related guides
This guide describes flux analysis as it runs inside an in-house finance team's own close. Cadence, thresholds, and format vary by company; the two-dimension threshold test and the sourced-explanation standard are the constants.