SOX-ready AI: what auditors want to see in an automated workflow
Control documentation, evidence retention, and segregation of duties when the party performing the control is a workflow, not a person.
By Zuny
When the party performing a control is a workflow rather than a person, the control objective does not change. The evidence format does, and it usually improves. An auditor still asks what the control prevents, who owns it, how consistently it was applied, and what proves it ran. A person answers with checklists and email threads. A workflow answers with a run population, timestamped inputs and outputs, a logic version, and a named approver on every exception. This post covers control design and testing: what the narrative must say, what evidence the control emits, and how an auditor tests it.
Key takeaways
• The control objective stays the same when a workflow performs the control. The narrative describes logic, not habits, and the evidence is a run population, not a sample of signatures.
• Retention shorter than your audit cycle is a common, avoidable failure. A tool that purges run logs at 90 days cannot support a full-year population.
• Segregation of duties applies to builders, not just approvers. One person building, editing, and approving a workflow's output is a finding.
• Deterministic controls can sometimes be tested on smaller samples, because consistency of application is demonstrable rather than assumed. Confirm sampling with your auditor.
• AI reads and classifies. Deterministic code computes and posts. A human approves. That split makes an AI step testable inside a SOX-scoped control.
| Control element | What an auditor asks for | Manual process evidence | Deterministic workflow evidence |
|---|---|---|---|
| Performance | Who ran it, and when | Signed checklist or dated email | Run record with timestamp and workflow version |
| Consistency | Proof the same logic applied all period | Inferred from a sample and interviews | Full run population, one versioned definition |
| Completeness | Proof the list of instances is whole | A manually maintained log | Every trigger creates a run record, failures included |
| Exception handling | What happened on edge cases | Email threads, undocumented judgement | Exception queue with approver, decision, timestamp |
| Reperformance | Redo the control and compare | Someone repeats the work by hand | Replay the logic version against recorded inputs |
| Change control | What changed mid-period, and who approved | Document version history, if kept | Version diff linked to each affected run |
Why automated control design is now a scoping question
Finance teams are automating controls faster than they document them. That gap is where findings come from. The Protiviti 2025 SOX survey reports that nearly 70% of respondents have implemented automated compliance tools, 68% are prioritising additional technology and automation, and 57% are critically re-evaluating risk assessment and scoping. Automation is already inside the control environment, and scope is being rewritten at the same time. Design decisions made this quarter get tested next year.
The operational pressure is real. APQC, drawing on data from more than 10,000 organizations, reports that top performers close in five days or less, the median is six days, and bottom performers take 10 or more calendar days. Teams compress the close by automating reconciliations, accruals, and revenue schedules, which are often the processes carrying key controls.
Loopfour, the deterministic finance workflow automation platform, was built for that overlap. Loopfour Studio is a visual canvas workflow builder that runs on your existing stack: QuickBooks, NetSuite, Xero, Sage Intacct, Rillet, Stripe, Salesforce, HubSpot, Attio, Slack, Gmail, Outlook, DocuSign, PandaDoc, Dropbox Sign, and Workday. We build, monitor, and maintain the workflows. Your team approves only the exceptions.
Control documentation for an automated control
An automated control narrative describes logic, not habits. It states the trigger, the predefined logic, the tolerance thresholds, the exception path, the approver, and the systems touched. Anything a reader cannot map to a step does not belong in it.
A narrative written around a person reads like this: "The senior accountant reviews the aged AR report monthly and follows up on balances over 60 days." An auditor reads that and asks what follow-up means. A workflow narrative instead names the trigger (the third business day after close), the source (the AR ledger in NetSuite), the logic (flag balances aged over 60 days above a stated threshold), the tolerance, the exception path (flagged items route to a Slack approval queue), the approver by role, and every system touched.
| Narrative element | What it must state | Common gap | ||||
|---|---|---|---|---|---|---|
| Trigger | The event or schedule that starts the run | "Monthly" with no defined day | ||||
| Predefined logic | The rules applied, in order | Prose that no longer matches the build | Tolerance thresholds | The limits separating pass from exception | Set in the tool, absent from the narrative | |
| Exception path | Where flagged items go, and what if nobody acts | No escalation or timeout behaviour | ||||
| Approver | The role authorised to clear an exception | A shared mailbox or generic admin account | ||||
| Systems touched | Every source read and system written to | Downstream writes omitted as incidental |
In Loopfour Studio, the trigger is a block, thresholds are block configuration, and approval is a human-in-the-loop block with a named role. The narrative can be generated from the build, which removes the most common documentation defect: a description that drifted from what the workflow does.
Evidence retention for automated controls
An automated control produces four artefacts: the run population for the period, the inputs and outputs for any sampled run, the logic version that executed it, and proof the first three survive to fieldwork. Miss the fourth and the rest are unusable.
This is the failure we see most often. A tool retains logs for 90 days, fieldwork happens eight months later, and the evidence has expired. The outcome matches a control that never ran. Set retention longer than your audit cycle, not longer than your comfort. A fiscal year plus fieldwork plus remediation is the practical floor.
The second trap is partial capture. A log line reading "run completed successfully" proves nothing. Evidence must show inputs read, transformations applied, outputs written, and the decision at every branch.
Loopfour emits an execution tree on every run: each block that executed, the data in and out, the branch taken, the approval captured, and the workflow version in force. An auditor who samples run #4,182 gets that run's inputs, outputs, logic version, and approver without anyone reconstructing anything.
What population completeness means here
Population completeness means you can prove the list of runs you handed the auditor is the whole list. Manual processes struggle at volume: Ardent Partners reports that over 60% of invoices still require some human interaction. A workflow answers structurally, because every trigger creates a run record and failed runs are still runs.
Segregation of duties when a workflow acts
Segregation of duties for an automated control covers four rights: who builds a workflow, who changes it, who approves its output, and who sees the logs. One person holding all four is the finding, regardless of how well the workflow performs. Applying SoD only to approval misses the exposure: someone who can edit the logic changes what the control does, and someone who can do both can pass anything.
| Right | Who typically holds it | Why it must be separate |
|---|---|---|
| Build a workflow | Loopfour, or a designated internal builder | Build access is authorship of the control |
| Change a live workflow | A restricted role, with change logging | Mid-period edits change the control being tested |
| Approve exceptions | A finance role with delegated authority | Approval is the judgement step the control rests on |
| View run evidence | Broad read access, including internal audit | Evidence should not depend on the builder |
Change management is the part teams underestimate
An unlogged mid-period edit to a workflow is the automated equivalent of an unauthorised journal entry. It changes the accounting outcome, and nothing in the record says who did it or why.
Consider a threshold change. On March 3rd, the variance tolerance on a bank reconciliation workflow moves from $500 to $5,000. Every later run clears items the earlier logic would have flagged. Unlogged, an auditor testing a March run and a January run is testing two different controls without knowing it.
Testable change management needs four things: what changed, who changed it, when, and what approved it. Loopfour versions every workflow, and each run's execution tree points at the version that produced it. A mid-period change appears in the evidence rather than hiding behind it.
How auditors test an automated control
Auditors test in two passes: design effectiveness, then operating effectiveness. Design asks whether the control as built would prevent or detect the risk. Operating asks whether it did, across the period.
Design is where automated controls are strong, because the logic is inspectable. An auditor reads the workflow definition, checks the thresholds, and traces the exception path without interviewing anyone about habits. Operating effectiveness needs the run population, a sample, and evidence for each sampled item.
Why deterministic controls can sometimes be tested on smaller samples
Sample sizes exist because consistency of application is uncertain. A person applying a control 400 times may apply it differently on attempt 300 than on attempt one. The sample estimates that variability.
Deterministic execution removes the variability at its source. The same logic version, given the same inputs, produces the same output on run #1 and run #1,000,000. When an auditor can inspect the logic, confirm the version held all period, and reperform a run, the evidentiary value of each tested item rises.
Two cautions. Sampling is your auditor's call, so confirm scope and sample sizes with your own audit team. And determinism only helps if the surrounding IT general controls hold. Access, change management, and source-system data integrity sit underneath the application control.
What reproducibility means at the sampling stage
Reproducibility means an auditor can take a selected run and get the same result again from the recorded inputs. Reperforming a manual reconciliation means someone redoes the work and compares. Reperforming a deterministic run means executing the recorded logic version against those inputs and confirming the output matches the execution tree. The comparison is exact, not approximate. IOFM puts the manual invoice error rate at roughly 2% against below 0.8% automated, and Levvel Research puts manual cost per invoice at $10 to $15 versus $2 to $3 automated.
Where AI sits inside a SOX-scoped workflow
AI belongs at the reading and classifying step, under a confidence threshold, with deterministic code for computation and a human for approval. AI should not compute balances, post entries, or decide whether a control passed.
The reason is measurable. The FinanceReasoning benchmark published at ACL 2025 (arXiv:2506.05828) evaluated models across 2,238 finance problems. The strongest reasoning model reached 89.1% on the hard subset, and numerical calculation errors were roughly 37.5% of failures. One in nine hard problems wrong, with calculation the largest failure mode, is not a profile to place inside a revenue calculation.
So Loopfour splits the work. AI extracts a vendor name from an invoice PDF, classifies a contract clause, or matches a remittance description to an open invoice. Deterministic code applies the ASC 606 (FASB) five-step model, computes the schedule, and writes to the ledger. A human approves anything flagged below threshold. Loopfour is not an AI agent with a wrapper. AI is called surgically, with a stated confidence threshold and a human fallback on every call.
| AI use inside a control | Acceptable | What must be documented |
|---|---|---|
| Extract fields from an invoice or contract PDF | Yes, above a stated confidence threshold | Threshold value, fallback path, model version |
| Classify a transaction or clause type | Yes, with human review below threshold | Categories, threshold, exception queue owner |
| Draft a variance explanation for review | Yes, as a draft only | That the output is a draft, and who reviews it |
| Compute a revenue schedule or accrual | No, use deterministic logic | The deterministic rule set and its version |
| Post a journal entry | No, use deterministic logic with approval | Posting rules, approval role, system of record |
| Decide whether a control passed | No, this is the human or rule-based step | The pass criteria and the approver |
Documenting a probabilistic step inside a deterministic control
A probabilistic step needs three documented attributes: its confidence threshold, its fallback path, and the model version that ran. Without those three, the step is untestable.
The threshold is the boundary between accepted machine output and human takeover. The fallback must lead to a named owner, not a queue nobody watches. The model version matters for the same reason the workflow version does: an auditor comparing a January run and a September run needs to know the same thing ran both times. Treat the confidence threshold as a control parameter, subject to the same change management as a dollar tolerance.
Loopfour is SOC 2 Type II certified with a SOC 1 audit underway, maintains HIPAA controls, encrypts data with AES-256 at rest and TLS 1.3 in transit, and never uses customer data to train models.
A decision framework for scoping your first automated control
Start with a control that is high volume, rules-based, and already causing evidence pain. Controls whose core step is unstructured judgement come last, not first.
| Factor | Automate now | Automate later | Keep manual |
|---|---|---|---|
| Volume | High, repetitive | Moderate | A few instances a year |
| Logic | Clear rules and thresholds | Rules with frequent exceptions | Judgement-led throughout |
| Data quality | Structured, from a system of record | Semi-structured, needs extraction | Unstructured and inconsistent |
| Evidence today | Scattered across email and spreadsheets | Partly systematic | Already clean and small |
Readiness checklist before fieldwork
Run this before your auditor arrives. Each item is answerable in a morning if the design is sound.
• Can you produce the full run population for the period, including failures and exceptions?
• For a random run, can you show inputs, outputs, branch decisions, and approver in a day?
• Does the narrative name the trigger, logic, thresholds, exception path, approver, and systems touched, and match the current build?
• Is retention set beyond your fiscal year plus fieldwork plus remediation?
• Are build, change, approve, and view rights held by different people or parties?
• For any AI step, are the threshold, fallback path, and model version documented?
• Have you confirmed scope, sampling, and evidence format with your own auditor?
Any "no" is a design task, not a fieldwork task. Fix it before testing starts.
Frequently asked questions
What documentation do auditors want for an automated control?
Auditors consistently ask for six elements: the trigger, the predefined logic, the tolerance thresholds, the exception path, the approver, and the systems touched. The narrative must match the build as it ran during the period, not as designed. Expectations vary by firm, so confirm format with your own audit team.
How long should we retain automated workflow evidence?
Longer than your audit cycle. A practical floor is your fiscal year plus fieldwork plus a remediation period, and many teams hold longer because prior-period questions surface during scoping. The common failure is a tool that purges execution logs at 90 days while fieldwork happens eight months after the runs.
Can a deterministic workflow reduce audit sample sizes?
Sometimes, and it is your auditor's decision. Sample sizes estimate variability in how consistently a control is applied. Deterministic execution removes that variability: the same logic version and inputs produce the same output every time. When an auditor can inspect the logic, confirm it held all period, and reperform a run, each tested item carries more weight.
Is it acceptable to use AI inside a SOX-scoped control?
It is acceptable when the AI step is scoped, thresholded, and documented. AI reads and classifies, deterministic code computes and posts, and a human approves exceptions. Three things must be documented: the confidence threshold, the fallback path below it, and the model version in force. AI should not compute balances, post entries, or decide whether a control passed.
How does Loopfour handle segregation of duties?
We hold the build and maintenance role under our managed service, and your team holds approval authority over exceptions, mapped to your existing delegations. Change rights are restricted and every change is versioned, so each run's execution tree points at the logic version that produced it.
Building controls that test well the first time
The control objective does not change when a workflow performs the control. Your evidence does, and handled well it improves: a complete run population instead of a sample of signatures, a versioned logic definition instead of a stale narrative, and reperformance that is exact rather than approximate.
The work is front-loaded. Document the six narrative elements. Set retention past your audit cycle. Separate build, change, approve, and view. Put AI only where it reads and classifies, under a threshold, with a human behind it. Confirm scope and sampling with your own auditor before fieldwork, not during it.
Loopfour builds, monitors, and maintains deterministic finance workflows on the stack you already run, and every run leaves an execution tree behind it. Book a workflow review and we will walk one of your SOX-scoped processes with you, block by block.