Flux analysis is the comparison of account balances across accounting periods to identify movement and explain what caused it. "Flux" is short for fluctuation. Teams run it during close, most often comparing the current month to the prior month, and again at quarter end for external reporting.

The calculation is subtraction. The work is resolving a single number on a GL line into the specific activity that moved it. This guide covers what flux analysis is, how to perform it, and how to decompose a movement to its drivers, with two worked examples.

What flux analysis means

Three characteristics define it.

• It compares actuals to actuals. Current period against a prior period. That distinguishes it from budget comparison, which measures performance against plan rather than validating that the numbers are right.

• It applies to both financial statements, but the mechanics differ. Income statement flux compares period activity: what was spent or earned this month versus last. Balance sheet flux compares a point-in-time position: what the account held on the closing date versus the prior closing date. The distinction matters because a balance sheet account can be wrong in the same way for many consecutive periods and show no movement at all, while an income statement error usually announces itself as a spike.

• It produces a retained explanation. The deliverable is documentation, not a conclusion someone reached and moved on from.

What is a flux on an income statement?

An income statement flux compares revenue and expense activity between two periods and explains the movement in each line above your review threshold. Because income statement accounts reset each period, the comparison is between two independent sets of activity, which makes anomalies relatively visible: a line that ran at $54,000 last month and $1.1M this month is obviously worth investigating.

Which balance sheet accounts need flux

Balance sheet flux is the harder discipline and the one more often skipped. Prioritize accounts that carry estimates or roll forward:

• Accruals and accrued liabilities

• Prepaid expenses and amortization schedules

• Deferred revenue

• Intercompany balances

• Reserves and allowances

• Any account where a schedule sits behind the balance

The reason these need attention is mechanical. A balance that carries forward incorrectly produces no period-over-period movement, so a threshold based on change will never surface it. Catching those requires comparing the balance against the schedule that supports it, not just against last month's balance.

This is why balance-level flux and transaction-level flux are different capabilities rather than two views of the same thing. Balance-level comparison tells you the position moved. Transaction-level detail tells you which activity moved it, and whether the activity that should have appeared actually did. Tools that only do one of the two leave half the balance sheet unexamined.

Flux analysis vs variance analysis

Strictly, flux analysis compares actuals across periods and variance analysis compares actuals to budget or forecast. In practice most controllers use "flux" for the entire period-end explanation exercise and run both. The distinction matters most for audit. Analytical procedures test fluctuations against prior periods, not against your plan, so a budget-to-actual explanation does not answer what an auditor is asking.

What is a flux in auditing?

In an audit context, flux refers to the fluctuations an audit team examines during analytical procedures. Auditors compare current-period balances to prior periods, form an expectation of what the balance should be, and investigate differences beyond a threshold they set independently of yours.

Your internal flux process determines whether that goes quickly or painfully. Where flux serves as a documented internal control, auditors will test three things: that the review actually happened, that it happened consistently across periods, and that a reviewer independent of the preparer approved the conclusion.

The common failure is not weak analysis. It is sound analysis that cannot be evidenced, because it happened in a spreadsheet, a conversation, and someone's judgment, none of which were retained.

Two failure paths make this worth getting right. An unexplained or wrongly explained variance is a missed misstatement, and missed misstatements become material weaknesses that follow the company into the next audit cycle. Separately, a movement discovered after books close means reopening the period and revising figures that were already distributed.

Choosing the comparison period

Most teams default to month over month and stop. The comparison you choose determines what you can see.

Month over month during close is right for error detection, because it catches problems while there is still time to correct them. Year over year works better for accounts with known seasonality, where a monthly comparison generates the same false positive every cycle.

One pattern worth building in: an account that moved materially last period deserves a look this period even if it now appears flat. A spike that fully reverses the following month is a different finding than a spike that persists.

How to perform flux analysis: step by step

1. Pull the comparison at the level you report. Structure it by financial statement line item rather than raw GL export order, so the output matches how the numbers will be reviewed. Reporting that mirrors your FSLI structure removes a mapping step that otherwise gets repeated every month.

2. Apply your review thresholds. See the variance analysis guide for how to set them by account and entity. Thresholds and groupings should reflect how your team defines the work, not how the ERP models it.

3. Decompose each flagged item to the transaction. Group by vendor, department, or account depending on what drives that line. Vendor grouping is usually fastest on expense accounts, because expense movements almost always trace to a small number of counterparties.

4. Identify drivers that sum to the movement. Name them, quantify them, and account for the residual rather than leaving it implied.

5. Check what should be there and is not. A period missing an expected entry can show no movement at all. Threshold breaches are only one signal; duplicate journals, oversized transactions, and reversals with no matching re-accrual are others, and none of them are reliably caught by looking at percentage change.

6. Write the explanation with support attached. The reviewer should not have to rebuild the investigation to verify it.

7. Route for review with a named preparer and reviewer. Separation is what makes the control testable.

8. Refresh after late entries. If a balance changes after the explanation was written, the explanation reopens.

The step most teams compress under time pressure is step three, and it is the one that determines whether the explanation is real.

Worked example: decomposing a movement to its drivers

A flagged account is the start of the work. The explanation has to resolve the total into components that sum back to it.

Trade show expense moves from $54,509 to $1,104,133, a change of $1,049,624 or roughly 1,926%.

Grouped by vendor:

Three things make this complete rather than partial. The components sum to the total. Each names a counterparty and the underlying activity. The residual is accounted for.

Compare that to "trade show expense increased due to higher marketing spend," which is true, unfalsifiable, and useless to a reviewer.

Adding trend context

A single-period explanation answers what happened. The reviewer's next question is whether it recurs. A short trend note pre-empts it:

Three-month trend: September showed a low baseline with limited trade show activity. October ran at $54,500, primarily routine and preparatory expense. November spiked to $1.10M on large one-time sponsorships and event commitments. The pattern indicates seasonal, event-timed spend concentration. December should be monitored for normalization against recurring run-rate.

That note also carries forward. Next month's preparer inherits the context rather than researching the same account again, which is how recurring explanations stop being rewritten from scratch every cycle. Whether that happens depends on where explanations live: commentary written into a spreadsheet that gets archived each month cannot compound, while commentary retained against the account can.

Worked example: why small net movements still need decomposition

This is the failure mode thresholds create.

Legal expense shows a $53,000 variance. It barely clears a typical review threshold, and a reviewer under time pressure accepts a one-line explanation.

Decomposed, it is a $79,000 accrual reversal offset by a $140,000 re-accrual, netting to roughly $38,000 of genuine change after other activity. Two six-figure entries sit underneath a five-figure net.

The reviewer who sees only the net cannot confirm the re-accrual was supported, cannot assess whether the reversal was correct, and has no basis to judge whether the estimate changed for a defensible reason. The threshold worked by surfacing the account. Only decomposition explains it.

Netting is common in accrual-heavy accounts, intercompany, and anywhere reversals and re-accruals run through the same line. Where a small net appears in an account that normally carries large gross activity, decompose before accepting it.

Where flux analysis gets expensive

Three mechanics drive the cost, and all of them scale with entity count.

• The investigation runs backward. You start from a number and search outward for its cause, so every account is a fresh search with no guarantee the answer sits in a system you can query. Two accounts moving by the same amount can take five minutes and three hours, and you cannot tell which before you start.

• The answer often is not in the ledger. The GL records that headcount cost rose. It does not record the two mid-month departures that explain it. Contract amendments, usage changes, project activity, and pricing decisions all drive GL movement from outside the GL, which means the explanation depends on data the accounting system never held.

• Explanations do not compound. Last month's investigation into the same account sits in an archived file, so a recurring driver gets researched from scratch. A vendor accrual that behaves the same way every quarter can be explained twelve times a year by four different preparers.

Teams running flux manually across a multi-entity close commonly spend 15 to 30 hours per person per cycle, most of it in assembly rather than analysis.

Automating the preparation

The practical test of whether automation would help: on day one of close, does someone open a blank workbook, or a populated comparison with items already flagged and drivers already identified?

Most tools marketed for flux draft commentary on an analysis a human already built. That compresses the last mile and leaves the assembly work untouched. The distinction worth testing is whether the product prepares the analysis or writes about it, and the questions that separate the two map to the problems above:

• Does the comparison arrive already decomposed? Drilling from a flagged line into vendor and transaction detail without leaving the tool to pull ERP reports is the difference between a five-minute investigation and a three-hour one.

• Does it cover balance-level and transaction-level flux? Balance sheet accounts need both, and products built for income statement commentary generally do only the first.

• Does it reach data outside the GL? Explanations depend on operational and plan data the ledger never held. Triangulating GL, non-GL, and plan sources is what turns a delta into a cause.

• Is the feed live? Export-based tools analyze a snapshot. A late entry after the pull means the explanation is wrong and nothing flags it. A live connection plus threshold-based alerts surfaces movement when it happens rather than on day three.

• Does it detect what thresholds miss? Duplicate journals, oversized transactions, and reversals without matching re-accruals are anomalies, not percentage breaches.

• Does the evidence stay attached? Preparer and reviewer roles with a retained audit trail are what make the analysis re-performable rather than an assertion.

Maxima was built around that preparation layer: agents work from a live ERP feed, decompose flagged movements to vendor and transaction level, incorporate non-GL and plan data, and draft explanations with the supporting detail attached, structured to your FSLIs and your thresholds rather than the ERP's defaults. Accountants review and approve, and nothing reaches the GL without sign-off.

Teams working this way typically move from 15 to 30 hours per person per cycle to 1 to 2 hours, with the remaining time spent on exceptions rather than assembly. The downstream effect is fewer post-close adjustments, cleaner audit fieldwork, and fewer follow-up questions from executives who can already see the driver behind the number. For a comparison of tools, see variance analysis software for accounting teams.

Frequently asked questions

What is flux analysis in accounting?

Flux analysis is the comparison of account balances between accounting periods to identify material movement and explain what caused it. "Flux" is short for fluctuation. It applies to both the income statement and the balance sheet, compares actual results to prior actual results rather than to budget, and produces a documented explanation tied to the underlying transactions.

What is a flux in auditing?

In audit, flux refers to the fluctuations an audit team examines during analytical procedures. Auditors compare current-period balances to prior periods, form an independent expectation of what the balance should be, and investigate differences beyond their own threshold. A documented internal flux process supports that work; auditors will test whether the review happened, whether it was consistent across periods, and whether a reviewer independent of the preparer approved it.

What is the difference between flux analysis and variance analysis?

Strictly, flux compares actuals across periods and variance analysis compares actuals to budget or forecast. In practice most controllers use "flux" for the whole period-end explanation exercise. The distinction matters most for audit, because analytical procedures test fluctuations against prior periods rather than against your plan.

Should flux analysis be month over month or year over year?

Month over month during close is the default, because it surfaces timing differences, posting errors, and missing accruals while there is still time to correct them. Year over year suits accounts with known seasonality, where a monthly comparison produces the same false positive every cycle. Many teams run month over month across the board and apply year over year selectively.

Which balance sheet accounts should be included in flux analysis?

Prioritize accounts carrying estimates or schedules that roll forward: accruals, prepaids, deferred revenue, intercompany, and reserves. The mechanical reason is that a balance carried forward incorrectly produces no period-over-period movement, so a change-based threshold will not surface it. Those accounts need the balance compared against the supporting schedule, not just against the prior period.

Why does a small net variance still need investigation?

Net movements can conceal much larger offsetting entries. A $53,000 net change might be a $79,000 accrual reversal offset by a $140,000 re-accrual, leaving neither component verified. In accounts that normally carry large gross activity, decompose to the transaction level before accepting a small net.

How long should flux analysis take?

It varies more than most close tasks, because the effort depends on where the driver lives rather than on the size of the movement. Teams running it manually across a multi-entity close commonly report 15 to 30 hours per person per cycle, with the majority spent locating and assembling the supporting detail rather than analyzing it.