In almost every finance automation conversation at a SOX-scoped company, there's a moment when someone says: "We'd love to automate this, but it's a key control." The room goes quiet, the project gets parked "until after the audit," and the team goes back to doing the work by hand.
Sometimes that caution is warranted. Usually it isn't. SOX doesn't prohibit automation — and the auditing standards actually provide specific, often lighter, testing approaches for automated controls than for manual ones. What SOX compliance does require is that you can show the control is designed properly, that the system around it is governed, and that the evidence exists. That's a far more tractable problem than "SOX won't let us."
This applies to US public companies under Section 404, to subsidiaries of US-listed groups (including many LATAM operations that roll up into a parent's control environment), and to companies preparing for an IPO. Smaller reporting companies may be exempt from the external auditor's attestation under 404(b), but management still has to assess internal controls under 404(a) — so the same logic holds.
First, a Reframe: SOX Tests Controls, Not Tools
There is no such thing as "SOX-compliant software." SOX compliance is a property of your internal control over financial reporting (ICFR), typically assessed against the COSO framework. A tool can make a control easier or harder to evidence, but the auditor is evaluating your control: the risk it addresses, how precisely it addresses it, and whether it operated throughout the period.
That changes the question. Instead of "Is this automation allowed?", the right question is "What control is this process performing, and how will we prove it works?"
What Auditors Actually Test in an Automated Control
Under PCAOB AS 2201 — the standard that governs ICFR audits of public companies — testing an automated control generally comes down to five things.
1. A clear control design tied to a specific risk
The auditor wants to know what can go wrong (for example, paying a vendor invoice that doesn't match an approved purchase order), which financial statement assertion that affects, what the control does about it, and at what precision — the dollar or percentage tolerance beyond which an item gets flagged. Many manual controls are documented vaguely ("AP reviews invoices"). Automation forces you to define the rule explicitly, which auditors tend to welcome.
2. IT general controls (ITGCs) around the system
This is where most of the real work lives. ITGCs usually cover three areas:
- Access: Who can change the logic, the thresholds, or the reference data — and who can approve exceptions. Service accounts used by the automation should have only the permissions they need.
- Change management: Changes to rules, scripts, or configuration are requested, tested, approved, and deployed by someone other than the person who wrote them — with a record of each step.
- Operations: Scheduled runs are monitored. When a run fails, someone finds out and resolves it; nothing gets silently skipped.
If ITGCs are effective, the auditor can rely on the automated control continuing to behave the way it did when they tested it. If they aren't, every other test becomes much harder.
3. A "test of one" on the logic
For a manual control performed daily, an auditor will typically pull a sizable sample of instances across the year. For an automated control backed by effective ITGCs, the auditor can generally test each relevant scenario once — a clean match, a mismatch, an out-of-tolerance item, a duplicate — and conclude the logic works. AS 2201 also describes "benchmarking": if the logic hasn't changed and ITGCs remain effective, prior testing can carry forward with reduced work in later years.
This is the part teams underestimate most. A well-governed automated control is frequently cheaper to audit than the manual process it replaces.
4. Completeness and accuracy of the data going in and coming out
Auditors call the reports and data used in a control information produced by the entity (IPE). If your automation reconciles a bank file against an ERP extract, the auditor will want comfort that the extract is complete (every transaction made it in) and accurate (nothing was altered in transit). The practical answer: record counts and control totals captured automatically at every handoff.
5. Evidence of how exceptions were handled
For anything the automation routes to a person, the auditor evaluates the human step like any review control: who reviewed it, when, what information they had, what they decided, and whether follow-up happened. A review with no trace of what was actually reviewed is a weak control — whether the item came from a bot or a spreadsheet.
The auditor isn't asking whether a machine did the work. They're asking whether you can prove the work was done correctly, by an authorized process, every time it mattered.
What SOX Doesn't Require: The Assumptions That Stall Projects
"A human has to re-check every automated transaction."
No. Blanket re-review of automated output adds cost without adding precision — and a reviewer rubber-stamping hundreds of items a day may not constitute a meaningful control at all. What's required is a designed control. Often that means automated logic handles items within defined tolerances, and exceptions go to a person. Where you set that threshold is itself the key control decision, as we explored in our analysis of AI agent accountability.
"Automated processes can't have any errors."
Controls are evaluated on whether they're designed and operating effectively, and deficiencies are graded by severity — deficiency, significant deficiency, or material weakness. When the automation flags something it can't resolve and a person resolves it, that's the control working. What auditors penalize is errors that go undetected.
"AI can't be part of a SOX-relevant process."
Nothing prohibits it. But a model's output isn't always identical for the same input, which doesn't fit neatly into a test-of-one approach. The cleanest design in practice: let the model propose, and let configured rules plus human approval decide. The model extracts fields, suggests matches, or classifies documents; deterministic thresholds and routing rules determine what gets posted automatically and what goes to review. Those rules are testable. The model's suggestion becomes an input to the control, not the control itself. We walked through this pattern in our bank reconciliation deep-dive.
"We can't change a control mid-year."
Replacing a manual control with an automated one during the year is common. Your auditor needs to see the new control operating for a sufficient period before the assessment date — how long depends on how often it runs — along with documentation of when the change happened and how the transition was handled. That's a planning exercise, not a reason to wait a full audit cycle.
"Our auditors have to approve the automation before we build it."
External auditors can't design your controls; independence rules prevent it. But you can — and should — walk them through the intended design and ask how they'd plan to test it. Held early, that conversation removes most of the uncertainty that otherwise surfaces during fieldwork.
A Pre-Audit Checklist for Any Automated Process
If you can answer each of these with evidence rather than intention, you're in good shape:
- Risk and precision: Which risk and assertion does this control address, and at what tolerance does it flag an item?
- Access: Who can change the logic, thresholds, or reference data — and is that access reviewed periodically?
- Change records: How are changes requested, tested, approved, and deployed, and can you produce the trail?
- Run monitoring: How do you know every scheduled run executed, and what happens when one fails?
- Data integrity: How do you prove the inputs were complete and accurate?
- Exception evidence: For every routed exception, can you show who reviewed it, when, and what they decided?
- Documentation: Could someone new to the process walk an auditor through the narrative and configuration without the original builder in the room?
One more consideration: if an outside provider hosts or operates part of the process, ask your auditor early how they'll get comfort over that provider's controls — typically through a SOC 1 report or direct testing. This is one reason some finance teams prefer to run automation inside their own environment.
These are design decisions, not afterthoughts. When we scope an automation, we treat them as part of the build: an audit dashboard that records each decision and approver, team-based access, human-in-the-loop routing for exceptions, cloud or on-premise hosting depending on what your IT and audit teams prefer, and documentation delivered alongside the system.
The Bottom Line
SOX doesn't ask whether a process is manual or automated. It asks whether the control is designed to catch what matters, whether the system around it is governed, and whether you can prove both. A well-built automated control often answers those questions more cleanly than the manual process it replaces — a log is a better witness than a memory.
Projects that stall usually stall on assumptions nobody tested. Take the checklist above to your controller and your audit lead, walk through one candidate process together, and you'll find out quickly whether the obstacle is real. If you're still choosing that candidate, our guide to picking a representative first project pairs well with this one.
This article is general guidance, not audit or legal advice. Your external auditor's methodology governs how your specific controls will be tested.