AI in the month-end close: the SOX controls to set before agents run

Section 404 of the Sarbanes-Oxley Act requires each annual report a company files with the SEC to include management's assessment of its internal control over financial reporting, and the company's auditor attests to that assessment [1]. The auditor's attestation does not apply to an emerging growth company, or to a company that is neither an accelerated filer nor a large accelerated filer [1, 4]. A newly public company's first annual report needs neither report [4].

SEC rules define that internal control as a process designed by, or under the supervision of, the chief executive and chief financial officers to give reasonable assurance about the reliability of financial reporting. It includes keeping records that accurately and fairly reflect transactions, and making receipts and expenditures only as management and directors authorise [2]. The same two officers sign a certification with every quarterly and annual report [3]. Nothing in the definition asks whether a person, a spreadsheet or a model prepared an entry. If an AI step prepares reconciliations, accruals or journal entries that reach the financial statements, it is part of the system being assessed.

SOX 404 itself reaches only companies that report to the SEC. A private company meets it when it lists, or when its close becomes part of a listed company's, and a control is cheaper to design in than to retrofit onto a close that already depends on it.

Internal control has long been built from two kinds of control: manual ones, such as approvals, reviews and reconciliations, and automated ones inside the systems that record and process transactions [7]. Auditors treat an automated control as lower risk when the IT general controls around it work [6]. PCAOB standards even let an auditor carry forward last year's test of an entirely automated control, a strategy they call benchmarking, because such controls are generally not subject to breakdowns due to human failure and the auditor can verify the program has not changed [6].

A model step fits neither box cleanly. It can produce different output for the same input, and a hosted model can change when its vendor updates it unless you pin a specific version. So I would not treat an AI step as an automated control that is tested once and relied on. Treat it as a preparer: something that produces work which a control then checks. The same concern came up in outreach that PCAOB staff reported in July 2024. Preparers pointed to the black-box nature of some generative AI tools and the lack of consistent output as raising questions about whether that output can be audited, and some audit firms said its use by preparers could amplify existing IT risks, such as those around segregation of duties [9].

That one distinction decides almost everything below. The model can draft the reconciliation. The control is the automatic tie-out to the subledger and the reviewer who signs it.

The table maps the usual control objectives in the close to what can go wrong when a model prepares the work, the control that answers each risk, and what an auditor can inspect. The risks come from the IT risks PCAOB standards tell auditors to understand, applied to an AI step [7].

Two rows carry most of the weight. The agent never holds posting rights, and every proposed entry passes automatic checks before a person sees it, so the reviewer spends their time on exceptions rather than re-reading a queue that is mostly right. That is the pattern we call agent proposes, verifier gates, and it is the one I would start from in any close.

SEC guidance for management names the IT general control areas that may matter to the assessment: program development, program changes, computer operations, and access to programs and data [5]. For an AI step, the program is more than code. It is the model and its version, the prompt, the tool definitions, the mapping tables and thresholds, and any documents the step retrieves. PCAOB standards already make the point for ordinary software: an automated calculation can depend on the files, tables, data and parameters around it, such as the rate table behind an interest calculation [6]. A prompt or a mapping table is exactly that kind of parameter.

So every one of those components goes through the same change process as a change to the ERP. It is written, tested against a fixed set of past cases with known right answers, approved by someone other than its author, and deployed by the pipeline rather than by hand. Pin the model version where the vendor lets you, and treat a vendor's version change as a change you test before it reaches a live close.

Then there is the quarterly question. SEC rules require management to evaluate, each quarter, any change in internal control over financial reporting that has materially affected or is reasonably likely to materially affect it, and the company's periodic reports disclose such a change [2, 4]. Whether moving part of the close onto an AI step meets that bar is a judgement for management and its auditor. Make it deliberately before go-live, rather than discovering it at year-end.

The IT risks PCAOB standards ask auditors to understand include unauthorised access to data that leads to recording unauthorised or non-existent transactions, IT staff gaining access beyond their duties and so breaking down segregation of duties, unauthorised changes to master files, and inappropriate manual intervention [7]. An agent running on broad credentials puts all four in one place.

Give the agent its own identity: never a person's login, and never a service account other jobs share. Scope it to the entities, accounts and periods its task needs, read-only by default, with write access only to a draft or staging area that the ledger's approval workflow controls. Grant and remove its access the way you do a person's, from a source of truth, and include it in the quarterly access review. The identity provisioning system we built for a client runs on that rule: access follows the HR record, not someone's memory.

The separation that matters most is between the people who can change the AI step and the people who approve what it produces. If one engineer can edit the prompt and also approve the journal, the control has a hole, however good the model is.

Management must keep evidential matter, including documentation, that gives reasonable support for its assessment [4], and SEC guidance says documentation of how the controls are designed is an integral part of that support [5]. Auditors test a control through inquiry, observation, inspection of documents and re-performance, and a walkthrough follows a transaction from origination through the company's systems until it is reflected in the financial records [6]. When an auditor relies on information the company produced, such as a reconciliation or a schedule, the standard has them test its accuracy and completeness, or the controls over it [8].

For an AI step, that means a record of every run: which inputs it read, the model and prompt versions, what it proposed, which checks passed or failed, who reviewed it, what they changed, and when. Keep it append-only, for as long as your records policy requires. Some audit firms told PCAOB staff they design their own generative AI tools to document the source data used [9], and a finance team's tools should meet at least that bar. An auditor should be able to pick any line in a close schedule and trace it to its source documents without asking the model to explain itself.

A control is only as good as the person operating it. PCAOB standards test whether a control operates as designed and whether the person performing it has the authority and competence to do so, and a compensating control only counts if it works at a precision that would catch a material misstatement [6].

Two failure modes worry me more than a wrong model output. The first is a reviewer who approves a queue because it is usually right, until the review is a signature and nothing more. The second is a review of the output alone, with none of the evidence behind it. Design the review so the reviewer sees exceptions first, sees the source behind each proposed entry, and records what they checked. Some audit firms told PCAOB staff that supervisors reviewing work done with generative AI are expected to apply the same diligence as for any other work, and preparers said human supervision of the tools and review of their output remain important [9].

Where the AI step calls a model hosted by a vendor, PCAOB standards treat a service organisation whose services form part of a company's information system as part of that company's internal control. They describe routes to evidence that its controls work, including a service auditor's report that tests those controls over the right period, and tests of the company's own controls over what the vendor does, such as re-performing selected items or reconciling output reports with source documents [6].

Check what a vendor's assurance report covers before you count on it for the close. Where it does not reach what you need, the evidence has to come from your side: the automatic checks against your ledger and the reviewer's sign-off. That is one more reason to build the controls around the model rather than hoping for them inside it.

The order matters more than the choice of model. This is the sequence I would follow, one process at a time.

1AYM works in financial services, and we build agentic workflows on the rule this guide argues for: the agent proposes, deterministic checks decide what proceeds, and anything that fails goes to a person with the reason attached. Our documented finance systems work at a large international marketing agency covers reconciliation, management-accounts and trial-balance checks across Xero, NetSuite, Zoho and QuickBooks, alongside managed-agent workflows for finance-critical tasks. We do not audit controls or sign them off; that stays with management and your external auditor. What we do is design and build the AI step so that the change records, the access model and the run evidence in this guide exist from its first live close.

For one process, that is a fixed-scope architecture and production build. If you already have a scoped job and need people to deliver it, we can resource it on contract from the collective of associates who work with 1AYM, held to the same standard. If you are weighing AI in your close, a 30-minute call is enough to test whether the first process you have in mind is the right place to start.