Flux analysis is the part of the close where a controller explains why balances moved: month over month, quarter over quarter, year over year, or against budget. It is also one of the least automated parts, in most organisations still done by pulling a comparison in Excel, eyeballing the big movements, and writing commentary from memory and a few drill-downs, two days before sign-off.
The work has an awkward shape. Detection is mechanical: compare two columns, flag what crossed a threshold. Explanation is investigative: find the transactions behind the movement, decide which of them constitute the driver, and quantify it. Writing is editorial: turn the finding into two clear sentences a CFO and an auditor will both accept. Most teams pay senior accountants to do all three, and the mechanical share crowds out the investigative share exactly when scrutiny is highest.
The 2026 generation of flux tools splits the shape properly. The software detects variances against thresholds, investigates likely causes by scanning GL and subledger detail and historical patterns, drafts a plain-language explanation, and attaches the evidence it used. The accountant’s role moves from investigation to review, challenge, edit, and approve. The distinction from the previous decade of BI dashboards matters: those tools showed variance and stopped. The current ones connect the change to specific transactions and produce commentary that can be edited into the close package.
Threshold design is control design
Materiality thresholds decide what the process even looks at, which makes them a control decision rather than a settings page. Three patterns dominate: an absolute amount threshold, a percentage threshold, or the two combined. The combination exists for a reason. A pure percentage rule buries reviewers in noise from small-base accounts where a modest entry doubles the balance. A pure absolute rule misses large relative moves in accounts that are small today and will not be next quarter.
Thresholds can be set at GL account, entity, or reporting level, and the layering deserves thought. Grouping by department or entity keeps a small subsidiary from being held to group-scale cutoffs, and account-level sensitivity lets you tighten scrutiny where risk concentrates. A workable policy has three tiers: below-threshold items need no written commentary, threshold-crossing items require an explanation, and high-risk or judgmental accounts get reviewed even below threshold. Reserves, estimates, and accounts with a history of surprises belong in the third tier regardless of how quiet the current period looks.
The failure mode to govern against is aggressive suppression. A threshold set to make the review list short also makes it blind, and the movement that mattered was two entries below the cutoff. Threshold changes should be versioned and approved like any other control change, with someone accountable for reviewing what the current settings are filtering out.
The draft is only as good as its evidence
An AI-drafted explanation earns its place in the close package through what it can point to, not how it reads. Auditors have never accepted “higher volume” or “timing difference” as an explanation from a human, and they will not accept it from a model. The bar is specific, quantified, and supported: which driver, how much of the movement it accounts for, and which entries evidence it.
That bar translates into pipeline requirements:
- Per-account templates. Each account gets a defined structure: which fields the draft must reference, what the output layout is, what counts as a complete explanation. Templates make recurring explanations consistent across periods and make gaps visible when a draft cannot fill a required field.
- Transaction-level citations. Every quantified claim in the draft should reference the source entries behind it, with drill-down to GL or subledger detail. An uncited claim is a hypothesis and should be labelled as one.
- Driver quantification. A movement of a given size explained by named drivers should approximately reconcile. If the cited drivers cover only part of the variance, the draft should say so rather than rounding the story up to complete.
- A visible review layer. The tool proposes; the accountant disposes. The workflow needs an explicit approve step, an edit history, and a record of what the reviewer changed, because “the AI wrote it and nobody checked” is the finding you least want in an audit.
Draft quality is downstream of the data model. If ERP mappings are inconsistent, account definitions are vague, or transaction metadata is thin, the narratives will be thin too, and no prompt fixes that. Teams disappointed by generated commentary usually have a data problem wearing an AI costume.
Where it sits in the close, and when it should run
Close platforms typically place flux work in the final review stage, after ERP data has synced and before sign-off. That placement is right for the control but late for the discovery. The more useful pattern emerging in 2026 is continuous monitoring: variance detection running during the month, so a movement that will need explaining surfaces while the transactions are recent and the people who booked them remember why.
Continuous detection changes the close-week experience materially. Instead of opening a blank comparison on day three, the controller opens a queue of already-investigated items, most with drafts attached, and spends the time on the ones that need judgment. The judgment cases are predictable: one-time events, estimates and reserves, intercompany and consolidation effects, and separating management actions from underlying operating drivers. These stay human because the cost of a confident wrong explanation is highest exactly there, and because a model reasoning over GL data cannot know that a driver was a decision made in a meeting.
The workpaper is the product
The operational test of a flux automation programme is what lands in front of the auditor. The evidence package should contain the final edited commentary, the source transaction references behind each claim, the drill-down path to detail, the account-level context, and the review trail showing who approved what and what changed between draft and final. Vendors now market this as audit-ready workpapers, and the realistic version of that claim is worth having: not automated audit, but faster auditor review and fewer follow-up requests because the support is already attached to the explanation.
Cost the programme honestly. Threshold governance needs an owner. Templates need maintenance as the chart of accounts evolves. Reviewers need calibration so approval does not decay into clicking through, and a periodic spot-check that cited evidence actually supports the narrative belongs in the control. Measure the result in reviewer hours on material items versus mechanical items, auditor follow-up volume, and how often a published explanation later proved wrong. A close package that reads beautifully and attributes a movement to the wrong driver has automated the writing and skipped the accounting.
FAQ
How do we stop the AI from writing plausible but wrong driver explanations?
Constrain it to evidence it can cite. The draft should only be allowed to name a driver if it can reference the specific transactions or subledger entries that quantify it, and the review screen should show those references next to the claim. Explanations that cannot be tied to source entries get flagged as hypotheses, not findings. Reviewers should spot-check the citations on material items, because a narrative that reads well and points at the wrong entries is worse than no narrative.
Where should thresholds sit: account level, entity level, or group level?
Usually all three, with different sensitivity. Account-level thresholds catch movements that matter for that account's risk profile; entity thresholds keep small subsidiaries from drowning in commentary requirements sized for the group; group thresholds protect the consolidated review. High-risk and judgmental accounts, such as reserves and estimates, should carry review requirements even below threshold, because the risk in those accounts is rarely proportional to the size of the movement.
Does automated flux analysis change what auditors ask for?
It changes the shape of the questions rather than removing them. When the workpaper already links each explanation to source transactions, auditors spend less time requesting support and more time on the judgmental items, which is where their attention belongs. Expect new questions instead about the process: how drafts are generated, what the reviewer actually checks, and how you prevent unreviewed AI text from reaching the close package. Have the review log ready.