Flux analysis with AI: explaining variances without inventing them

Flux analysis with AI works when the model is never asked to do the analysis. The pipeline computes the variance. The model drafts the explanation. Every sentence in that explanation must cite specific transactions. A human approves before it reaches anyone. Inside those four constraints, variance commentary is one of the strongest legitimate language-model use cases in the close, because the work is summarizing retrieved facts rather than reasoning about numbers. Outside them, you get fluent commentary naming causes nobody can trace, attached to a close package the board will read. This post covers the failure mode and the constraints that remove it.

Key takeaways

• The variance is computed by code, never by a model. Deterministic math against dollar and percentage thresholds produces the delta; the model only writes prose about it.

• Retrieval is the whole design. A model given a summary line has the delta but not the drivers, so it supplies generic business reasons that read as fact.

• Every generated sentence must cite a transaction, vendor, or contract. Commentary that cannot cite is deleted, not edited.

• A controller approves before anything reaches the CFO or the board. Approval is a workflow step, not a courtesy.

• The FinanceReasoning benchmark (ACL 2025, arXiv:2506.05828) found numerical calculation errors made up roughly 37.5% of failures even in strong reasoning models, which is why the arithmetic stays in code.

• APQC finds top performers close in five days or less while bottom performers take 10 or more calendar days. Flux commentary is where day two goes.

| Question a controller asks | Naive chat-window approach | Constrained workflow approach | | --- | --- | --- | | Who computes the variance? | The model, from pasted figures | Deterministic code against fixed thresholds | | What does the model see? | A summary P&L line | The underlying entries for that account and period | | What backs each sentence? | Plausible business reasoning | A named transaction, vendor, or contract | | Who signs off? | Nobody | The controller, in Slack, before distribution | | What survives an audit request? | A chat transcript | An execution tree of every step and approval |

What flux analysis is and why it eats day two of the close

Flux analysis, short for fluctuation analysis, is the month-end review that compares each general ledger account against a prior period or budget, flags accounts whose movement exceeds a set threshold, and documents a written explanation for each one. It is variance analysis applied account by account across the P&L and balance sheet. Auditors expect it. Boards read it.

It consumes a day for a structural reason. The comparison is trivial arithmetic. The explanation is not. For each flagged account, someone opens NetSuite or Sage Intacct, pulls transaction detail, identifies the entries behind the movement, and reconstructs why they happened — a contract that started, an invoice booked in the wrong period, an accrual that reversed. That is retrieval work plus writing work, repeated 30 or 40 times, usually by the most experienced person on the team.

Why pasting the P&L into a chat window produces invented explanations

Pasting a P&L into a chat window fails because the model receives the delta and none of the drivers. Ask why marketing is up 18% and you receive a confident, well-written, entirely invented explanation. It will mention campaign spend, seasonal timing, a hiring ramp. None of it is retrieved. All of it is plausible.

This is not a defect in the model. It describes the task you gave it. The summary line holds one number, so the system returns the most ordinary explanation for a marketing increase at a mid-market company. That is a generalization about businesses, not a fact about yours. It reads identically whether the driver was an annual renewal or a duplicate payment.

The damage is specific. Invented commentary enters the close package, reaches the audit committee, and becomes the record of what happened. When an auditor asks for support six months later, there is none. The problem is not that the model wrote something wrong. The problem is that nothing in the process ever required it to be right.

Why the variance arithmetic itself never goes to a model

The computation stays in code because measured error rates on financial arithmetic remain material even for the strongest reasoning models. The FinanceReasoning benchmark (ACL 2025, arXiv:2506.05828), a set of 2,238 finance problems, is the clearest evidence available. OpenAI o1 with Program-of-Thought prompting, the strongest configuration tested, reached 89.1% on the hard subset — capable performance on difficult problems.

The error analysis matters more than the headline. Numerical calculation errors accounted for roughly 37.5% of failures, and formula-application errors for about 35% on hard problems. Those categories describe exactly what flux analysis requires: subtracting one period from another, dividing to get a percentage, and applying one threshold rule to every account.

A close cannot absorb that failure rate, and it cannot absorb variability — the same numbers producing a different answer on a rerun. So the arithmetic goes where arithmetic belongs. We do not replace the model's intelligence. We put it inside guardrails. Language models are capable assistants for summarizing retrieved evidence. They are not a system of record for the numbers that evidence supports.

The retrieval requirement: give the model the entries, not the summary line

The model must receive the underlying journal entries for the flagged account and period, ranked by contribution to the variance. Nothing else changes the output as much. A model holding the 12 transactions behind an 18% marketing increase writes about those transactions. A model holding only the 18% writes about marketing in general.

Here is the step-flow as it runs in Loopfour Studio:

Period close in NetSuite or Sage Intacct → variance computed deterministically against dollar and percentage thresholds → flagged accounts retrieved with their largest contributing transactions → model drafts commentary citing those transactions → controller edits and approves in Slack → commentary attached to the close package and logged in the execution tree.

Each arrow is a block on the canvas. The retrieval block does the real work: it queries the general ledger for the flagged account, ranks entries by contribution, and attaches vendor names, contract references, and dates. The model block receives that evidence and one instruction — explain this movement using only what is in front of you.

| Flux workflow step | Deterministic or model | What it produces | Human control point | | --- | --- | --- | --- | | Trial balance pull from NetSuite or Sage Intacct | Deterministic | Current and comparative period balances | None required | | Variance computation against dollar and percentage thresholds | Deterministic | Flagged account list with deltas | Threshold policy set by the controller | | Transaction retrieval for flagged accounts | Deterministic | Ranked contributing entries with vendor and date | None required | | Contract lookup in DocuSign or Dropbox Sign | Deterministic | Supporting agreement references | None required | | Commentary drafting | Model, with confidence threshold | Draft explanation citing named transactions | Low-confidence drafts route to a person | | Citation check on every generated sentence | Deterministic | Pass or delete decision per sentence | Deleted sentences surface as exceptions | | Controller review | Human | Edited, approved commentary | Approval in Slack before distribution | | Close package assembly and logging | Deterministic | Final flux report and execution tree entry | Audit review on demand |

One row out of eight involves a model, scoped to writing sentences about evidence already retrieved and verified.

The citation requirement: commentary that cannot cite is deleted

Every claim in generated commentary must reference a specific transaction, vendor, or contract present in the retrieved evidence. Code enforces this after drafting, not instructions before it. A sentence naming no identifiable source fails the check and is removed.

Deletion rather than editing is deliberate. An unsupported sentence is not a rough draft of a supported one. It states a cause never found in the data, and softening it preserves the claim while hiding its origin. Removing it leaves an honest gap: part of the variance has no identified driver yet. That is a real finding. "Seasonal factors" is not.

The check runs as a deterministic block, matching each sentence against transaction identifiers, vendor names, and contract references in the retrieved set. Stripped sentences surface as an exception; a rising count means retrieval needs widening.

The review step before commentary reaches the CFO or the board

No generated commentary reaches a CFO, an audit committee, or a board without a named human approving it first. Approval is a blocking step, not a notification. The run does not advance until someone acts.

The controller receives drafted commentary in Slack, account by account, with each cited transaction linked back to NetSuite or Sage Intacct. Three actions are available: approve, edit and approve, or reject with a reason. Rejections are logged and drive retrieval improvements next month. Approvals are recorded against a named person and timestamp in the execution tree.

This is what separates a drafting assistant from a system of record. The model never publishes. It proposes, and a person disposes. Protiviti's 2025 SOX survey found nearly 70% of organizations have implemented automated compliance tools. Automation is already in the close, so the evidence trail has to be explicit.

Before and after: two versions of the same commentary

The gap between unusable and audit-ready commentary fits in one paragraph. Both versions below describe the same 18% increase in marketing expense. Figures are illustrative.

Unusable, generated from the summary line alone:

> Marketing expenses increased due to higher campaign spend and seasonal factors, consistent with expected growth in demand generation activity for the period. >

Audit-ready, generated from retrieved transaction detail:

> Marketing expense increased $184,000, or 18%, against prior month. Two entries account for $171,000 of the movement. The annual marketing analytics platform renewal of $126,000 posted in full on the 14th under a contract executed in DocuSign on the 9th, against a prior-month run rate of $10,500. Trade show deposits of $45,000 for the September event posted early after the vendor advanced the payment schedule. The remaining $13,000 is spread across nine vendors, none above $3,000. >

The second version cites amounts, vendors, contract execution, and timing. A reviewer can verify every clause in the general ledger in under two minutes. It also separates the one-time renewal from the run rate, which is the question the CFO asks next.

Note what the model contributed. It did not compute $184,000 or 18%; the pipeline did. It did not find the DocuSign contract; the retrieval block did. It arranged verified facts into readable sentences and flagged the variance still unattributed. That is a scoped writing task with a human check at the end.

How Loopfour runs this in production

Loopfour, the deterministic finance workflow automation platform, builds this workflow on your existing stack and runs it every close. Loopfour Studio is a visual canvas where each step is a block — 30 blocks across seven categories covering retrieval, computation, model calls, approvals, and system writes. Flux analysis is one workflow with a sub-workflow per account category.

Execution is programmatic and deterministic. The same trial balance produces the same flagged accounts on run #1 and run #1,000,000. Every action writes to an execution tree: what was retrieved, what the model received, which sentences failed the citation check, who approved, and when. When an auditor asks how a line of commentary was produced, the answer is a record, not a reconstruction.

The AI Copilot in Studio — Ask, Build, Debug — helps your team build and debug workflows on the canvas. It is separate from the model call inside the flux workflow, which is scoped to drafting commentary from retrieved entries under a confidence threshold, with low-confidence drafts routed to a person. Loopfour is not an AI agent with a wrapper.

We run this as a managed service: we build, monitor and maintain the workflow, and your team approves only the exceptions. Loopfour connects to QuickBooks, NetSuite, Xero, Sage Intacct, Rillet, Stripe, Salesforce, HubSpot, Attio, Slack, Gmail, Outlook, DocuSign, PandaDoc, Dropbox Sign, and Workday. We are SOC 2 Type II certified with a SOC 1 audit underway, maintain HIPAA controls, encrypt data with AES-256 at rest and TLS 1.3 in transit, and never use customer data to train models.

A modeled scenario

The figures here are illustrative and projected, not measured results from a customer. Consider a modeled mid-market company where thresholds flag 40 accounts a month and a senior accountant spends about 20 minutes on each — roughly 13 hours, concentrated on day two. In the modeled scenario, retrieval and drafting replace most of it with review time on 40 drafts, plus manual work on the few accounts failing the citation check.

The benchmark worth watching is not hours saved. APQC, drawing on more than 10,000 organizations, finds top performers close in five days or less, the median at six days, and bottom performers at 10 or more calendar days. Gains come from removing variable manual steps.

Decision framework: is your flux process ready to automate

Automate flux commentary once your variance thresholds are written down and your general ledger detail is reachable through an API. Fix those two first, because neither a person nor a workflow can explain a variance without them.

| Condition in your close today | What to do first | Why | | --- | --- | --- | | Thresholds vary by reviewer or month | Write dollar and percentage thresholds into policy | Deterministic flagging requires a fixed rule | | Explanations live in email and spreadsheets | Move commentary into one reviewed artifact | You cannot audit what has no home | | Account detail is exported by hand | Connect NetSuite, Sage Intacct, QuickBooks, or Rillet directly | Retrieval quality sets commentary quality | | Contracts are scattered across drives | Index DocuSign, PandaDoc, or Dropbox Sign references | Timing explanations depend on contract dates | | Nobody formally approves commentary | Name the approver and the approval point | Approval is the control that makes drafting safe | | Revenue accounts drive most variances | Map your ASC 606 five-step treatment explicitly | ASC 606 governs recognition under US GAAP, and commentary must match policy |

If four or more rows describe your close, start with threshold and retrieval work. Drafting is the easiest part to add once the evidence is reachable.

Frequently asked questions

Can AI do flux analysis?

A language model should not perform flux analysis end to end. It should draft the written explanation after a deterministic pipeline has computed the variance and retrieved the supporting transactions. Calculation errors remain a leading failure mode: in the FinanceReasoning benchmark (ACL 2025), they made up roughly 37.5% of failures. Code computes, the model writes, a controller approves.

What is flux analysis in a month-end close?

Flux analysis is the account-by-account comparison of general ledger balances against a prior period or budget, with a written explanation documented for every account whose movement exceeds a defined threshold. It is standard audit support and board reporting. Writing the explanations takes far longer than running the comparison.

Why does ChatGPT invent explanations for variances?

Because a summary P&L line contains the delta and none of the drivers. Asked to explain a number with no transaction detail in context, a model returns the most ordinary explanation for that movement: campaign spend, seasonality, headcount timing. Fluent and unsupported. Supplying the underlying entries changes the task from producing a guess to summarizing evidence.

How do you stop generated variance commentary from being wrong?

Enforce citation in code. Every generated sentence must reference a transaction, vendor, or contract present in the retrieved evidence, and sentences that fail are deleted rather than softened. Deletion leaves a visible gap, telling the reviewer that part of the variance has no identified driver. A controller then edits and approves before distribution.

Does automated flux commentary satisfy auditors?

Auditors evaluate the evidence and the control, not the drafting tool. A workflow that records source balances, the threshold rule, retrieved transactions, drafted text, deleted sentences, and the named approver with a timestamp gives stronger support than a hand-written explanation with no trail. Loopfour logs all of it in an execution tree on every run.

Where else does deterministic automation pay off in the close?

Anywhere volume meets a fixed rule. Ardent Partners reports that over 60% of invoices still require some human interaction, and Levvel Research puts manual cost per invoice at $10 to $15 against $2 to $3 when automated. IOFM puts the manual error rate near 2% against below 0.8% automated. The Invoice Agent, Receipt Agent, and Contract Agent apply the same pattern: deterministic matching, models called only for scoped tasks, people handling exceptions.

The rule worth keeping

Flux analysis suits language models precisely because it can be constrained so tightly. The pipeline computes the variance. The model drafts the explanation. Every sentence cites a specific transaction. A human approves before anyone else reads it. Hold those four rules and the commentary survives an audit request. Drop one and you get prose that sounds like analysis.

To see this mapped against your own close calendar, thresholds, and general ledger, book a workflow review with our team.