Closing the books with agents

Every finance team knows the shape of the close. The first days are reconciliations and accruals. The middle is intercompany, allocations, and the journal entries that follow. The end is variance analysis, flux commentary, and the package that goes to the controller, the CFO, and eventually the auditors. It takes a week or two, it consumes the same people every month, and most of the hours go to assembling evidence rather than exercising judgment.

That is exactly the shape of work agents are good at, and exactly the kind of work where a mistake is expensive and discoverable. The vendors selling close automation this year report reconciliation steps dropping from hours to minutes and categorization rates in the high nineties. Those numbers are plausible and they are the wrong place to start. The right place to start is the control question: what can an agent be allowed to do in a process that ends in an attestation, and what has to be true before a controller signs.

This piece walks the close step by step. For each step: what the agent does, what a person still decides, and the control that makes the first safe. Then the audit trail, and then how to begin.

The principle: agents prepare, people post

One rule organizes everything below. An agent may read from the systems of record, prepare a proposal with its evidence attached, and route it. It may not post to the ledger, and it may not send anything outside the boundary. Every step where the books change hands has a person in it, and the approval is bound to the exact entry.

This is not caution for its own sake. Under Sarbanes-Oxley section 404 the internal controls requirement covers any process that touches financial reporting, including an AI-assisted step, and the auditor's standard for information produced by the entity is that it be complete, accurate, and appropriate for its purpose. A reviewer who rubber-stamps an agent's output has not met that standard. A reviewer who sees the proposal and the source evidence side by side, resamples, works the exceptions, and signs has.

Reconciliations: match, flag, explain

Bank, sub-ledger, and balance sheet reconciliations are matching problems with exceptions. The agent pulls the statements and the ledger, matches what matches on the rules the team already uses, and produces the exception list with a proposed explanation for each item drawn from prior periods and the underlying documents. The accountant works the exceptions, not the list.

The useful metric here is not match rate. It is the exception list's precision: how many items the agent flags that a person then clears as fine, and how many it clears that a person would have flagged. Run the agent alongside the manual reconciliation for a cycle and compare the two lists before trusting either number.

Person decides: every exception that is written off or reclassified. Control: the agent has read access to the systems of record and no write access to the ledger.

Accruals: propose from evidence

Accruals are estimates with a paper trail. The agent reads open purchase orders, vendor contracts, recurring invoices, and last period's accruals, then proposes this period's entries with the evidence attached to each line and the prior-period precedent alongside. The reviewer sees the proposal and the source side by side and changes what needs changing.

Person decides: every accrual above a threshold the controller sets, and any accrual without a prior-period precedent. Control: proposals are staged in a review queue; nothing is posted from the queue without approval.

Intercompany and allocations: reconcile the disagreements

Intercompany imbalances are usually timing or coding, and the evidence sits in two entities' systems. An agent with read access to both compares the pairs, identifies the mismatches, and drafts the correcting entries with the reason. Allocations run the same way: the agent applies the approved methodology, shows the drivers, and flags any driver that moved more than a tolerance the team sets.

Person decides: the correcting entries and any exception to methodology. Control: the methodology is an approved document the agent applies. It cannot change it, and a proposal that departs from it is flagged as such.

Journal entries: approval before posting

This is the step where the action boundary matters most, and where an agent deployment either earns the controller's trust or loses it. The agent prepares the entry, attaches support to every line, records the queries it ran, and routes it. It does not post.

Three things distinguish a real approval from a formality. The approver sees the lines and the support together, not a summary. The approval is bound to that entry, so approving one does not approve the next one the agent prepares. And the posting step rechecks, at the moment it executes, that the approver still holds the authority and that the period is still open. Segregation of duties survives the introduction of an agent only if the agent counts as a preparer and never as an approver.

Person decides: every entry. Control: policy check before approval (threshold, account class, period status, segregation of duties), approval bound to the operation, authority rechecked at execution.

Variance analysis and flux: draft the story, keep the numbers

Flux commentary is where the close turns into narrative, and it is the step finance leaders most want help with. The agent computes the variances, applies the materiality threshold, pulls the drivers from the ledger and the operational systems, and drafts the explanation for each line above threshold, citing the transactions behind it. The finance partner edits the story. They do not rebuild the numbers.

Person decides: the final commentary and anything that goes to the board. Control: every figure in the draft traces to a query that can be rerun, and the draft is versioned so the reviewer's edits are visible.

The close package: assembled, not compiled

The package that goes to leadership and auditors is the evidence of everything above. The agent assembles it from the staged entries, the reconciliations, the exception logs, and the commentary, in the format the auditors expect, with the trail from each number back to its source. What used to be a week of compiling becomes a review.

The audit trail is the product

If an agent touches the close, the audit trail is not a feature of the deployment. It is the deployment. Five things have to be captured for every agent action, and they have to be captured as the work happens rather than reconstructed afterward.

1. Inputs and source references, at transaction level, traced to the ERP and the sub-ledgers, not summaries.
2. The instruction, the model, and its version, so the result can be reproduced.
3. The output and any uncertainty the agent flagged.
4. Human review, overrides, and approvals: who reviewed, what they checked, what they changed, and their sign-off.
5. Immutable timestamps and change history. Versioned edits, never overwrites.

Retention follows the workpapers, which for SOX-affected companies generally means seven years. Access to the trail is role-based, it exports to the audit team's own tools, and it has a single owner, usually the controller.

What the controller needs to see

Finance leaders are right to be the hardest audience for this. Four things should be true before any of the above runs on real books, and they are the same custody, agency, continuity, and exit tests our research team lays out in the sovereign AI playbook. Bringing an agent like this through a security review is covered in Getting the CISO to yes.

• The agent's access mirrors the accountant's. Permissions follow the source systems, and the agent sees nothing the person operating it could not see.
• Nothing posts without a person. Approval before every entry, bound to the exact operation, with the support in front of the approver and authority rechecked at execution.
• Every action is on the record. The five elements above, append-only, exportable, retained with the workpapers.
• The financial data stays where it belongs. Residency, retention, and the model provider's terms are known and enforceable, and the close can be rerun in a second environment if the first one is lost.

Where to start

Do not start with the whole close. Start with one reconciliation that is late every month. Write down what the agent may read and what a person must approve. Run it alongside the manual process for one cycle and compare the exception lists. Then move to accruals. The calendar shortens one step at a time, and the controls come with it, because the evidence that each control operated is produced by the work itself.

Key takeaways

• Agents prepare, people post. Every step where the books change hands has a person in it, and approval is bound to the exact entry.
• Measure exception-list precision against a parallel manual cycle before trusting any match-rate claim.
• The audit trail is the deployment: inputs, model and version, output, human review, immutable history, retained with the workpapers.
• Start with one late reconciliation, then accruals. The calendar shortens one step at a time and the controls come with it.

Fig connects to the ledger, the sub-ledgers, the banks, and the documents your team already uses, with the approvals and the audit trail built in. Talk to us about running the first reconciliation. See also Fig for finance teams.

Sources: PCAOB and SOX section 404 guidance on information produced by the entity; Numeric, "AI audit trail for accounting," 2026; vendor-reported close metrics from Puzzle and others, 2026; Fig Research, Sovereign AI: the operating playbook, September 2026.