AI for Financial Reporting: Preparing the Close Without Posting a Single Entry

The month end close is not a thinking problem for most of its duration. It is a fetching, matching, chasing and formatting problem, with a thin layer of genuine accounting judgement on top. Someone opens twelve subledger reconciliations and works out why three have a difference. A controller writes the same variance sentence about freight costs for the fourth quarter running.

That is where AI agents earn their place in finance. Not in deciding the number, which is your accountants' job, but in the preparation around it, so qualified people spend their days on decisions rather than assembly.

One rule governs everything below. An agent built properly for financial reporting never posts a journal entry, never approves a reconciliation and never signs a number. It prepares, explains and evidences. A named human with the right authority approves. If a vendor tells you otherwise, they have not sat through a SOX walkthrough.

Reconciliation preparation and break investigation

The problem: reconciliations are prepared at the moment everyone is busiest. The clean ones still consume hours of pulling balances and formatting schedules. The unclean ones get a one line comment because there is no time to investigate, and the difference rolls forward for months.

How it works: an agent pulls the general ledger balance and supporting detail from the subledger, bank feed, treasury system or fixed asset register, and builds the reconciliation in your standard template. It matches items, ages the open ones, and marks the reconciliation supported or not. For a break it traces the difference back through transaction history and tests the common explanations in order, timing differences, unposted items, foreign exchange revaluation, a payment applied to the wrong invoice, then writes what it found with the records it relied on.

The trail: each reconciliation carries the source system, query, timestamp and record identifiers behind every matched and unmatched item. The handoff: the preparer reviews and the reviewer approves, exactly as now. What changes is that the preparer opens a schedule with the break already investigated.

Flux and variance analysis with a drafted explanation

The problem: flux analysis is where the close reveals whether anyone understands the business. In practice it is often written at eleven at night by whoever is left, and the explanation restates the number rather than giving a cause.

How it works: an agent computes variances against prior period, budget and forecast at the level your policy requires, then looks for the cause before writing anything. It decomposes the movement into drivers, volume against rate, one off items, accrual releases, new contracts, a supplier price change, and identifies the transactions responsible. Then it drafts the explanation in your house style, with drivers quantified and underlying entries cited.

What the controller receives is a draft to edit, not a blank box. The edit is usually tone, materiality framing, or business context the agent could not know, such as the marketing overspend being a deliberate decision taken in a meeting that produced no document. That is a better use of a controller's evening than reconstructing arithmetic.

Journal entry support and documentation

The problem: manual journals are the highest risk area of the close and often the worst documented. Support lives in someone's downloads folder, and the narrative says "accrual per schedule" when the schedule has moved.

How it works: an agent assembles the support for recurring and standard journals. For an accrual it pulls the underlying activity, applies your stated methodology, shows its workings, and drafts the entry with account codes, cost centres and a narrative stating the basis and period. It flags where its calculation departs from last month's by more than a threshold, and says why.

The line that does not move: the agent produces a proposed entry in the ledger's staging area or as a file. It does not post. A human with posting rights reviews the support, agrees the methodology holds, and posts under their own credentials. The agent's identity has read access and no posting permission, a configured fact your access reviews can test rather than a policy claim.

Consolidation checks

The problem: consolidation errors are found late and cost a full cycle to correct. Intercompany does not eliminate cleanly, an entity is missing from a hierarchy, translation runs at the wrong rate for one account, a local adjustment never reached group.

How it works: an agent runs the checks a thorough group accountant would run if they had the hours. It reconciles intercompany balances by pair and reports which side is out and by how much, tests that entity mappings match the prior period plus approved changes, checks translation rates against the approved rate table account by account, and confirms local adjustments have flowed through. It runs these while the submission window is open, so exceptions reach the local team on day two rather than day six. Group still makes the call on treatment.

The management commentary and disclosure checklist

The commentary draft

An agent drafts the narrative sections of the pack from the numbers actually reported, following the structure and tone of your prior packs. Revenue movements, margin, headcount, cash, segment performance. Every figure quoted is pulled from the ledger rather than retyped, which removes a common and embarrassing category of error. The finance director rewrites the judgement and the forward view, the part only they can do.

Disclosure checklist support

An agent works your disclosure checklist against the period's data and documents and answers each item as satisfied, not applicable, or requiring attention, with a pointer to the note or source behind the answer. It flags newly relevant items, a lease modification, a related party transaction, an impairment indicator that appeared in the numbers this period. The technical accounting call stays with your people. They simply arrive at it knowing which items need one.

Audit requests and the PBC list

The problem: the prepared by client list is a grind. Requests arrive in inconsistent formats, spread across mailboxes, and the same schedule gets produced three times in three shapes. Follow up questions get answered from memory.

How it works: an agent parses the PBC list into discrete items, maps each to the system and report that satisfies it, and produces the schedules in the requested format with a cover note stating source, extraction date and population. It tracks status by item and owner, and when a follow up question arrives it locates the transactions and drafts a response with the supporting detail attached.

The handoff: nothing goes to the auditor without review by your team, but review starts from a complete, sourced package, and the relationship improves when the population you gave in March is reproducible in June from the same query.

The controls story

This is what decides whether any of the above survives contact with your auditors, so build it first rather than last.

Segregation of duties has to be real in configuration, not in a policy document. The agent's service identity holds read access to source systems and write access only to a staging area or document repository. It cannot post, approve, release a payment or change master data. Whoever approves the agent's output must not be whoever configured or changed it, and both actions need separate logs.

Change management applies to the agent as to any financially relevant system. Prompt, rule, mapping and model version changes go through your normal process with a ticket, a tester and an approver. An undocumented change to how an accrual is calculated is a control failure whoever made it.

Completeness and accuracy of the data the agent uses is the control your auditors press hardest on, particularly for anything feeding a management review control. Record what was extracted, when and with what query, reconcile the population back to the source system total, and retain the extract, not only the conclusion.

Evidence of review is where most implementations get lazy. If the control is that a controller reviews the flux explanation, the evidence must show what they reviewed, what they changed and why, not simply that they clicked approve. Design the review so it produces that artefact naturally.

How you evaluate accuracy before trusting it

Do not go live on a demo. Demos use clean months.

Run the agent in parallel against closed periods you have already signed. Six to twelve months, including a quarter end and one messy month with a restatement or system change. Compare its reconciliations, flux explanations and proposed entries with what your team concluded, and score three things separately: did it get the number right, did it get the explanation right, and did it refuse to conclude where a human escalated.

That third measure matters more than it looks. An agent that produces a confident, well written and wrong explanation is worse than one that says it cannot determine the cause. Set thresholds so low confidence work is labelled as such and lands with a person by design.

Then keep measuring. Have a reviewer independently rework a fixed sample of the output each month, blind, and track the difference over time. Rerun the parallel test whenever the chart of accounts changes, a source system is upgraded or the model version moves.

Where AI fails here

These systems fail when the underlying data is wrong. An agent will reconcile bad data neatly and explain a variance that exists only because someone coded an invoice to the wrong cost centre. It is no substitute for master data hygiene.

They fail on genuine accounting judgement. Revenue recognition on a novel contract, whether an impairment indicator has been triggered, the treatment of a restructuring. Agents can retrieve the guidance and lay out the considerations, but should not be allowed to conclude, and a well built one refers rather than improvises.

They fail on context that exists nowhere in your systems. The reason behind a commercial decision, the conversation with the auditor that settled a treatment last year, the customer disputing an invoice. If it was never written down, the explanation drafted will be plausible and incomplete.

And they cannot carry accountability. The signature on the accounts belongs to named people, and no deployment worth building changes that. What changes is that those people reach the point of signing with the preparation done, the breaks investigated, the variances explained and the evidence assembled.

Done properly this is not automation of the close. It is a shorter close with a better trail, produced at the moment of the work rather than reconstructed under audit pressure. If you want a plain view of which parts of your close would hold up, describe your current process to Adopt AI Partners and we will tell you honestly.