Segregation of duties in accounting when automation posts the entries
Segregation of duties in accounting when a workflow posts the entry: who is the preparer, which identity posts, and who must approve.
Part of the month-end close guide.
Segregation of duties in accounting means no single person or system identity can authorize a transaction, record it, hold custody of the asset and reconcile the result. When automation posts the entries, the rule still holds: the workflow gets its own identity as preparer, a named human approves, and nobody who can change the workflow's rules approves its output. Loopfour, the deterministic finance workflow automation platform, is built around that split. This post explains the classic incompatible duties, then applies them to automated journal entries, payments and vendor master changes, so you can answer the auditor's first question: who is the preparer here?
Key takeaways
- Segregation of duties splits four duties: authorization, recording, custody and reconciliation. One identity holding two of them on the same process is a conflict.
- Automation does not remove the preparer. It changes who the preparer is. The workflow's own identity prepares and posts, and that identity should be visible on every entry.
- Never let automation act under a person's login. An entry posted under the controller's user ID shows the controller as preparer of work they never saw.
- The approver must be a named person who cannot change the rules being approved. COSO's 2026 generative AI guidance says to separate the ability to configure AI settings from the authority to approve or review outputs.
- Build one SoD matrix that lists people and non-human identities together, process by process: journal entries, vendor payments and vendor master changes.
What is segregation of duties in accounting?
Segregation of duties is the control that splits a transaction's lifecycle across different people, so no one can both create an error and conceal it. Auditors and controllers usually describe it as four incompatible duties.
| Duty | What it means | Example in accounts payable |
|---|---|---|
| Authorization | Approving that the transaction should happen | Approving a vendor invoice for payment |
| Recording | Entering the transaction in the books | Posting the bill and the payment in the ERP |
| Custody | Control over the asset itself | Releasing the payment from the bank portal |
| Reconciliation | Checking that records match reality | Reconciling the bank account to the general ledger |
The rule of thumb is simple. If one person holds two of these duties on the same process, that person can make a mistake, or commit a fraud, and also be the one positioned to notice it. A clerk who records vendor bills and also reconciles the bank account can hide a duplicate payment. An approver who can also release the payment can approve and send money in one step, which is why the person approving a vendor payment should never release it.
Segregation of duties in accounting was designed for people. The question now is what happens when a workflow performs one or more of these duties.
Why automation strains the preparer and approver model
Automation strains segregation of duties when it performs a duty under someone else's identity, because the audit trail then names the wrong person. The control still looks intact on paper, but it no longer describes what happened.
A September 2026 CIO.com column describes the failure in a month-end close. An agent posted the recurring accruals and worked the intercompany exception queue, and "every journal entry carried the controller's user ID." The author's conclusion: "The agent did both, under one identity: it prepared the entries and it disposed of the exceptions." The records looked clean. The control had stopped working.
Three patterns cause most of these problems:
- Borrowed credentials. A script or bot logs in as a staff accountant or the controller, so its work shows up as theirs.
- One shared integration user. Every automated process posts as the same "integration" or "API" user, so nobody can tell which workflow prepared which entry.
- Approval outside the record. Someone approves in an email or chat thread, and the entry itself carries no trace of who approved it or when.
Each pattern breaks the same thing: the ability to look at one entry and name its preparer and its approver.
Who is the preparer when a workflow posts the entry?
The workflow's own system identity is the preparer of record. The people who approved its rules own the logic, and a separate named person approves the output. That gives the auditor three answers instead of one ambiguous user ID.
| Role | Who holds it | Evidence on the entry |
|---|---|---|
| Preparer of record | The workflow's own system identity | The posting user is that identity, not a person |
| Logic owner | The people who approved the workflow's rules | The rule version that produced the entry |
| Approver | A named person with delegated authority | Approver name and timestamp linked to the entry |
| Reviewer or reconciler | A different person from the approver | Reconciliation sign-off for the period |
This split answers the question "who is the preparer here?" directly. The preparer is a known, single-purpose identity whose behavior is fixed by approved rules. The approver is a person. The two never collapse into one login.
Five rules for segregation of duties in automated workflows
Five rules keep segregation of duties intact once automation posts entries. They apply whether the automation is a script, an ERP feature, a vendor tool or a managed workflow.
1. Give every workflow its own identity
Each automated workflow should post under its own named system identity. "AP bill posting" and "month-end accruals" should not share a user. A separate identity per workflow means every entry in the ledger traces back to one process, and access for that process can be removed without touching the others.
2. Never let automation act under a person's login
No workflow should hold a human's credentials. If an entry shows a person as the preparer, that person should have prepared it. This rule also protects the people: a controller whose user ID is on automated entries is accountable for work they never reviewed.
3. Keep the approver separate from the rule owner
The person who can change a workflow's rules should not approve that workflow's output. COSO's Achieving Effective Internal Control Over Generative AI (February 2026) lists this as a common control activity: "Separate the ability to configure AI settings from the authority to approve or review outputs." Its appendix on automated transaction processing adds "Separate configuration permissions from review responsibilities" and "Document SoD matrices." The same logic applies to rule-based workflows. Our post on SOX-ready AI workflows covers the build, change, approve and view rights in detail.
4. Log the approval against the entry
An approval that lives only in a chat thread is hard to evidence. The approver's name, the decision and the timestamp should be attached to the entry or its run record. Slack is a good place to ask for an approval. It is a poor place to store the only proof of it. Our guide to human-in-the-loop finance approvals covers where to place approval steps.
5. Scope each identity to one job
A workflow identity should hold only the permissions its job needs. A bill-posting workflow can create bills. It should not edit vendor bank details, release payments or reopen closed periods. Narrow permissions keep a configuration error from turning into an incompatible duty.
Loopfour builds finance workflows with the approval step written into the workflow, and every run records the approver and the logic version in its execution tree. If you want to see that on one of your processes, book a demo.
How to apply segregation of duties to three finance processes
The same four duties map onto every process, but the conflicts differ. Here is how they look for journal entries, vendor payments and vendor master changes when automation does part of the work.
| Process | Prepares or records | Approves | Releases or changes the asset | Reconciles or reviews |
|---|---|---|---|---|
| Recurring journal entries | Workflow identity, from approved rules | Controller or delegate, per entry or per batch | Not applicable | Accountant who did not approve, at close |
| Vendor payments | Workflow identity builds the payment batch | AP manager or budget owner | Treasury or a second person, never the approver | Accountant reconciling the bank account |
| Vendor master changes | Workflow identity logs the requested change | A person who did not take the request | Change applied only after approval | Periodic review of all changes by someone else |
Journal entries
For journal entries, the main risk is one identity that both prepares entries and clears its own exceptions. That is exactly the CIO.com example. Route exceptions to a person, and keep posting rules under change control. Our post on journal entry automation and the audit covers the evidence an auditor expects for each entry.
Vendor payments
For vendor payments, the main risk is approval and release held by the same identity. A workflow can prepare the payment batch, but approval and release belong to two different people. Our Answer Library page on segregation of duties in an automated AP approval workflow walks through the AP version in more detail.
Vendor master changes
For vendor master data, the main risk is one person who can change bank details and also approve payments to that vendor. Bank-detail changes deserve their own control, with verification through a channel the requester does not control and a second approver before the change takes effect.
What SOX requires, and what it leaves to your framework
Section 404 of the Sarbanes-Oxley Act requires an internal control report, not a specific list of incompatible duties. The statute (15 U.S.C. 7262(a)) requires each annual report to "state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting" and to contain an assessment "of the effectiveness of the internal control structure and procedures of the issuer for financial reporting."
The detail on which duties to separate comes from the control framework a company uses and from its auditor. That is why the same automated workflow can pass at one company and draw a comment at another. Confirm with your auditor how they want non-human identities shown in your SoD matrix before fieldwork, not during it.
How to test your own segregation of duties design
You can test your design in an afternoon by pulling the entries and checking who prepared them. Run these five checks on last month's activity:
- Export every journal entry and list the distinct posting users. Flag any user that is a shared or generic account.
- Find entries posted by automation under a person's user ID. Each one is a design fix.
- For each workflow, name the people who can change its rules. Confirm none of them approves its output.
- Pick ten automated entries at random. For each one, find the approver and the timestamp without asking anyone.
- Check that every non-human identity appears as a row in your SoD matrix, with its permissions listed.
A failed check is a design task. Fix it in the workflow and the access setup, not with a memo.
Where Loopfour fits
An AI agent decides what to do at runtime. Loopfour does only what was approved. That difference matters for segregation of duties, because a fixed workflow has a fixed job, and a fixed job is easy to place in an SoD matrix.
Loopfour builds, runs and maintains the workflow as a managed service, and your team holds approval authority over exceptions, mapped to your existing delegations. Approvals happen in Slack, and every run records the approver, the decision and the logic version that produced the entry. Where AI is used, it does a scoped task, such as extracting fields from an invoice under a confidence threshold, and a named person reviews anything below that threshold. Loopfour is SOC 2 Type II certified and SOC 1 Type I certified.
Frequently asked questions
What is segregation of duties in accounting?
Segregation of duties in accounting means no single person or system identity can authorize a transaction, record it, hold custody of the asset and reconcile the result. Splitting those duties means one error or one bad actor cannot both create a problem and hide it.
Who is the preparer when automation posts a journal entry?
The workflow's own system identity is the preparer of record, and the people who approved its rules own the logic. A named human approver, who did not write or change those rules, approves the entry or the exception. All three should be visible on the entry's audit trail.
Can a bot or workflow post entries under a controller's user ID?
It should not. When automation acts under a person's login, the ledger shows that person as preparer for entries they never saw, and the preparer and approver can collapse into one identity. Give every workflow its own identity with only the permissions its job needs.
Does SOX require segregation of duties?
Section 404 of the Sarbanes-Oxley Act requires management to report on and assess the effectiveness of internal control over financial reporting. It does not list specific incompatible duties. Those come from the control framework a company uses and from its auditor's expectations, and segregation of duties is a standard control in both.
How do small finance teams keep segregation of duties with automation?
Small teams often cannot staff four separate people per process. Automation helps, because a workflow identity can prepare and post while the people review and approve. Where one person must still hold two duties, add a compensating control such as a monthly review of that person's activity by someone else.
What should an SoD matrix include for automated workflows?
List every person and every non-human identity in rows, and the duties for each process in columns. Mark which identity prepares, approves, releases or posts, and reconciles. Any row with two incompatible duties on the same process needs a fix or a documented compensating control.
Conclusion
Segregation of duties in accounting survives automation when every entry can still answer three questions: which identity prepared it, which rules produced it and which person approved it. Give each workflow its own identity, keep automation off human logins, separate the rule owners from the approvers and log every approval against the entry. Then the answer to "who is the preparer here?" is one line in the audit trail.
Tell us the one workflow your team dreads. We will show it running. Book a demo.