Using AI for the month-end close: what works, what to control, and what your auditor will ask
By Alon Zieve FCA · Last reviewed
AI for the month-end close is good at the mechanical half of the work: proposing matches, drafting accruals and prepayments schedules from documents, and drafting the commentary on what moved. It should not set estimates, post judgemental journals or sign anything off. If a UK company uses it, its auditor will ask where the tool sits in its systems, who reviewed what it produced, and whether the journals it prepared or posted are in the population the auditor tests. This guide is part of the series on AI in audit and finance and takes each close step in turn.
What can AI do for the month-end close?
AI can draft, match and flag: it proposes reconciliation matches, drafts month-end schedules and variance commentary, and prepares journals with their support. A person decides, posts and signs off. Can AI do accounting, then? It can do much of the preparation, but not the judgements and not the responsibility. Every company must keep accounting records "sufficient to show and explain the company's transactions" (Companies Act 2006, s386), and if it does not, the offence is committed by the officers in default (s387). No tool takes that duty off the company, or the liability off its officers.
An ICAEW Insights article on AI agents in finance (July 2026) says AI agents can be used to manage month-end reporting "with assigned humans-in-the-loop". In the same article Ciaran Cosgrave of Nearform describes an agent that matches invoices and "isolates only the breaks" for the accountant to clear.
Table 1. The close, step by step
| Close step | What AI can draft well | What a person must own | What to keep for the auditor |
|---|---|---|---|
| Bank and balance sheet reconciliations | Proposed matches; a list of unmatched items; a first explanation of each break | Clearing every break; signing and dating the reconciliation as preparer and reviewer | The reconciliation, its source statements, who prepared and reviewed it and when |
| Accruals and prepayments | A schedule built from invoices, purchase orders, contracts and last month's schedule | Whether to accrue at all, and how much where the amount is an estimate | The schedule, its support, and the reviewer's sign-off and changes |
| Variance commentary | The figures (computed by code), the ranking against the threshold, a draft sentence per flagged line | The threshold; the cause; the final wording | The draft, the reviewed version and who changed it |
| Journals | A proposed journal with its support and narrative | Approval and posting, by a named person under their own user ID | The approval, the posting user and the support |
| Intercompany | Matching of balances and flags where the two sides disagree | Resolving each mismatch with the other entity | The agreed balances and how differences were cleared |
| Management accounts narrative | A first draft of the monthly story from the reviewed commentary | What the board is told | The version the board received (see the guide to the management accounts pack) |
| Close timetable and chasing | Reminders when an expected invoice or schedule is missing | Who owns each task and deadline | The timetable and sign-offs |
AI tools for month-end close: the three kinds
The AI tools for month-end close fall into three kinds, separated not by how clever the model is but by what the tool can see and whether it can write to your ledger.
- Features inside your accounting system or ERP. They see what the system already holds, they work under the system's own user and permission model, and the system's audit trail may record what they did.
- Close and automation layers connected to the ledger. These read from the ledger and sometimes write back to it. Read-only and write access are different risks: once a tool can post, it is a user of your accounting system and needs controlling like one.
- General-purpose assistants used on exported data. They have no ledger access at all. Someone exports a file, pastes or uploads it, and copies the answer back. Nothing is posted by the tool, but nothing is logged in your systems either, and the data has left them.
Table 2. Three kinds of tool
| Kind | What it sees | Can it post? | Does it leave a log? | Watch for |
|---|---|---|---|---|
| Feature in the accounting system | Your ledger, within its permissions | Sometimes, if enabled | Often, in the system's audit trail; check | Posting rights switched on by default |
| Connected close layer | What its connection allows | Only with write access | In its own logs; check they are kept | Write access granted "to save a step"; changes to its rules nobody approved |
| General-purpose assistant on exports | Only the file you give it | No | Not in your systems | Personal data leaving the business; answers nobody can trace to a version of the data |
Exports often carry personal data, such as payroll and customer records. Sending them to an outside AI service is processing under UK GDPR: it needs a lawful basis (Article 6), and where the provider processes the data on your behalf, a contract that meets Article 28(3). If the data goes outside the UK, the transfer must also meet Chapter V (Article 44A): a destination approved by UK regulations, appropriate safeguards, or a specific derogation. The data rules for the whole finance function are covered in using AI in a finance department.
Automating the month-end close with AI: where to start
How do you use AI for the month-end close without making the close harder to audit? Start small, keep the arithmetic in code, and decide the review before the first run. The guides to month-end, year-end and audit readiness cover the close itself.
Fix the close before automating it
A tool cannot make sense of a chart of accounts that nobody maintains or a close with no owner for each task. Settle the timetable, the owners and the monthly reconciliations first; automating a muddled close produces a faster muddle.
Pick one step with a clear right answer
Matching, and recurring schedules such as prepayment releases, have answers a reviewer can check. Estimates do not. Start with one step and prove it end to end; as Cosgrave puts it in the same article, "The most successful firms go deep on one high-value process and prove impact end-to-end, rather than running dozens of shallow pilots."
Let code compute and the model explain
Figures, thresholds and tie-outs should be calculated deterministically, by the ledger, a spreadsheet or code, and the model should draft words around them. A commentary that gets the variance wrong is worse than no commentary.
Run it alongside the old way
For a set number of closes, run the tool and the existing process side by side and compare the results. Keep the comparison; it is the first evidence that the tool works.
Decide the review before the first run
Write down who reviews each output, what they sign, and what is kept. A review that leaves no trace is, for audit purposes, a review that did not happen.
AI variance analysis: the draft, not the cause
Can AI do variance analysis? It can compute and rank variances, draft a sentence for each flagged line, and point to drivers the data shows. It cannot know a cause that is not in the data: a one-off, a timing difference or a decision taken in a meeting. Using AI for variance analysis works when code does the figures and a person supplies the cause.
Worked example. The company, the figures and the threshold below are invented for illustration. The finance director has set the threshold: a line is flagged when it is at least £10,000 and at least 10% away from budget. That is the FD's choice for this company, not a rule or a materiality figure. Variance is actual minus budget, so a minus is adverse for revenue and profit and favourable for a cost.
| Line | Budget | Actual | Variance | % of budget | Flagged? |
|---|---|---|---|---|---|
| Revenue | £1,250,000 | £1,231,000 | -£19,000 | -1.5% | No |
| Cost of sales | £700,000 | £712,000 | £12,000 | +1.7% | No |
| Staff costs | £260,000 | £262,400 | £2,400 | +0.9% | No |
| Marketing | £45,000 | £58,500 | £13,500 | +30.0% | Yes |
| Professional fees | £18,000 | £31,200 | £13,200 | +73.3% | Yes |
| Premises | £40,000 | £40,000 | £0 | +0.0% | No |
| IT and software | £22,000 | £19,800 | -£2,200 | -10.0% | No |
| Operating profit (revenue less the six costs) | £165,000 | £107,100 | -£57,900 | -35.1% | n/a (total) |
Code flags two lines. The model's drafts, and what the reviewer made of them:
- Marketing. Draft: "Marketing was £13,500 (30.0%) over budget, mainly due to higher spend with events suppliers." Reviewed: the overspend is a deposit for a trade show next spring, paid this month. The cost belongs to a later period, so it is a prepayment, not this month's expense; the reviewer has it reclassified, and the line comes back towards budget. The draft described the variance correctly and missed the point.
- Professional fees. Draft: "Professional fees were £13,200 (73.3%) over budget, driven by legal invoices." Reviewed: one-off advice on a dispute with a customer, not expected to recur. The reviewer also has to decide whether the dispute needs a provision or a disclosure, which is a judgement no draft can make.
The threshold also shows what a per-line rule misses. Revenue is £19,000 adverse and cost of sales £12,000 adverse; neither crosses 10%, so neither is flagged. Together they take £31,000 off gross profit, more than half of the £57,900 operating profit shortfall, before any of the reviewer's adjustments. Whoever reviews the commentary should read the totals as well as the flagged lines. The reviewed commentary, not the draft, is what goes in the pack.
Reconciliations, month-end schedules and intercompany: what to match and what to judge
On reconciliations, a tool can propose matches and list what it could not match. A person clears each break, and the reconciliation is signed and dated by whoever prepared it and whoever reviewed it. The proposed matches are a draft; the signed reconciliation is the control.
For accruals and prepayments, a model can draft the schedule from invoices, purchase orders, contracts and last month's schedule. The estimate is a different matter: whether to accrue at all for a service received but not invoiced, and how much, is a judgement. A person makes it and records the basis.
For intercompany, matching balances and flagging where the two sides disagree is a natural task for a tool; agreeing the difference with the other company is not.
Can AI do journal entries?
AI can prepare a journal with its support and narrative. Whether it may post one is a control decision, and for any non-routine or judgemental journal the answer should be no.
Where a tool has write access to the ledger, treat it as a system user:
- Its own user ID. Never a shared login, and never a person's credentials. ISA (UK) 315's examples of general IT controls include authentication: controls that ensure each user is using their own log-in credentials, not another user's.
- Only the permissions it needs. Posting rights off by default; switched on for named journal types only.
- An approver who did not set its rules. The person who approves what the tool posts should not be the person who configured it. Where the team is too small for that, ISA (UK) 315 recognises that in a less complex entity an owner-manager's direct involvement may compensate for limited segregation of duties, but warns that domination of management by one person can itself be a control deficiency, because it allows management override (para A157). The auditor judges which applies.
- Routine journals only. Recurring journals with a fixed basis, such as depreciation or a prepayment release, can be posted by rule under an approval a person gave. Manual adjustments, top-side entries and anything involving an estimate stay with people.
Why the auditor cares: testing journals is one of the procedures the auditor must perform on every audit to respond to the risk of management override of controls. The current ISA (UK) 240 (Revised May 2021) already requires tests of "manual or automated journal entries" (para 33(a)). The revised standard, for periods beginning on or after 15 December 2026, adds an express requirement to obtain audit evidence about the completeness of the population of journals (para 49(b)); the practitioner note on ISA (UK) 240 revised sets out the changes. A journal posted by a tool is still a journal, and it needs a user ID the auditor can identify.
What your auditor will ask about AI in the close
The FRC has published two pieces of guidance on AI in audit: AI in audit (June 2025) and Generative and Agentic AI Guidance (March 2026). The 2026 guidance says it is "aimed at the central technical teams within audit firms", and the 2025 guidance's worked example is an audit firm's tool for testing a client's journals. Neither is about a company's use of AI in its own close. For that, the auditor works from the ISAs (UK); the practitioner summary of the FRC AI audit guidance covers what the guidance does say.
Where the tool sits in your IT
ISA (UK) 315 requires the auditor to understand the information system, including how transactions are "initiated" and "incorporated in the general ledger", and the IT environment that supports it (para 25). Controls over journal entries are among the controls the auditor must identify (para 26(a)(ii)), and the standard expects them to be identified on every audit (para A160). From the controls identified, the auditor identifies the IT applications subject to risks arising from the use of IT, which may include the tool, and for each the risks and the general IT controls that address them (para 26(b) to (c)). In practice the questions are who can access the tool, who can change its rules, prompts or mappings, and how those changes are approved.
Whether its output can be relied on
A reconciliation or schedule the tool produced is information produced by the entity. Before relying on it, the auditor must evaluate whether it is "sufficiently reliable", including its accuracy and completeness (ISA (UK) 500, para 9). The auditor may obtain that evidence as part of its own procedure on the information, or by testing the controls over how the information is prepared and maintained (para A61). For a system-generated report, ISA (UK) 315 adds that the auditor may test the report's inputs and outputs substantively, or test the controls over it, including general IT controls over changes to the program or the data behind it (Appendix 5, para 10). Records that show the inputs, the output and the review make either route quicker.
The journal population
The auditor will want every journal for the period, with who or what posted it. A tool posting under a shared login, or a person posting the tool's journals under their own name without saying so, makes that population hard to read.
What happens if a control is weak
The auditor does not give an opinion on your internal control (ISA (UK) 265, para 2), but it must report significant deficiencies in writing to those charged with governance (para 9) and, unless that would be inappropriate in the circumstances, to management; other deficiencies that merit management's attention go to management too, not necessarily in writing (para 10). In practice a weak control adds substantive testing at year end, and your team's time, mainly where the auditor planned to rely on it; in ISA (UK) 315's less complex entity example, where the auditor may rely on none (para A160), it is more likely to be reported than to change the testing.
Table 3. The monthly evidence pack
| Keep each month | Why the auditor wants it | Where to keep it |
|---|---|---|
| The inputs the tool used, and their versions | To test the output's completeness and accuracy (ISA (UK) 500, para 9) | With the close file for the month |
| The tool's output, as produced | To compare the draft with what was finally used | Same place, unedited |
| The reviewer's name, the date and the edits | Evidence that a person reviewed it, not just ticked it | On the reconciliation, schedule or commentary itself |
| The user ID that posted each journal | The journal population and who posted what (ISA (UK) 240) | In the ledger's audit trail; check it is retained |
| Changes to the tool's rules, prompts or mappings that month | Change controls over the IT application (ISA (UK) 315, para 26) | A simple change log, approved by someone other than the person who made the change |
The questions an auditor asks about its own tools are different; see how auditors use AI. For the wider year-end list, see the year-end audit checklist.
If you would rather spend year end on the accounts than on chasing documents, Innate offers statutory audits signed by an ICAEW-registered partner firm, which your company appoints as its auditor, while our platform finds the documents and reconciles the numbers: see how it works.
Controls to put around AI before you rely on it
A short control set covers most of the risk. None of it is specific to AI.
Table 4. Controls around an AI tool in the close
| Area | Control | Evidence it ran |
|---|---|---|
| Access | Named users and a separate user ID for the tool; least privilege; no posting rights by default | The user list, reviewed periodically |
| Change | Rules, prompts and mappings versioned; changes approved before use | The change log |
| Review | A person reviews each output against source; the thresholds are set by a person | Reviewer's name, date and edits on the output |
| Logging and retention | The tool's logs and outputs kept with the accounting records | Retained at least as long as the records themselves |
| Data | A rule on what may leave your systems, and a processor contract where personal data does | The rule, and the contract |
On retention, company law requires a private company's accounting records to be preserved for three years from the date they are made, and a public company's for six (Companies Act 2006, s388(4)). GOV.UK's company-records guidance says to keep records for six years from the end of the last company financial year they relate to, or longer in some cases, such as where HMRC has started a compliance check into the Company Tax Return. Keep the AI evidence with the records it supports, for the longer period that applies. The wider policy, including what staff may put into a general-purpose assistant, belongs in your policy on using AI in a finance department.