Run a user access review on an ERP where AI has been on for a few months and a new kind of line appears. It is not a person, it has no job description, it was set up by IT or the implementation partner, and it can create and update records in Accounting. Nobody put it in the segregation of duties matrix, because the matrix was written for people.
The basics of conflicting duties in Odoo are in our guide to segregation of duties in Odoo. This article asks what changes when some hands in a process are agents, and how the same technology can test segregation on every transaction. It is part of our series on AI in accounting in 2026.
What is segregation of duties when AI is part of the process?
Segregation of duties is the design rule that no single user, human or automated, can authorize, record, hold custody of and reconcile the same transaction. The four functions have not changed; the list of users has. COSO’s Internal Control, Integrated Framework (2013) has a place for this: Principle 10 covers control activities such as segregation, and Principle 11 covers general controls over technology, which is where the configuration of an AI agent belongs. ISA 315 (Revised 2019) requires the external auditor to understand the IT environment and general IT controls, so an agent with write access will be in scope at your next audit whether you mapped it or not.
Is an AI agent a "user" for segregation of duties?
For control purposes, yes: the test is whether the actor can change the books. According to Odoo’s 20 release notes, AI agents can create records (including from an uploaded instruction file such as a PDF), update records, and be triggered by automated actions and scheduled actions. Anything that can create or update an accounting record performs the recording function and must sit in the matrix with a role, an owner and limits.
Before designing anything, confirm in your own Odoo 20 database under whose access rights an agent’s actions run and how its changes are attributed in the record history; that decides whether a conflict sits with the agent, the person who triggered it, or both. Also confirm which AI features your edition and plan include. Every AI request consumes IAP credits, billed per request and not included in any plan.
Decision rule: which of the four functions may an agent hold?
| Function | May an AI agent hold it? | Condition |
|---|---|---|
| Authorize | No | Approval is a judgment that carries accountability, so it stays with a named, registered person. An agent may prepare the approval file. |
| Record | Draft only | The agent drafts entries or records; a person who did not configure the agent reviews and posts them. |
| Custody | No | No agent should initiate payments. If you pay bills from Odoo through payment initiation (PISP), keep the release with a person. |
| Reconcile | Propose only | The agent proposes matches and flags suspected errors; a person validates the reconciliation. |
| Monitor | Yes | Reading the full population for exceptions is where AI adds most and conflicts least, provided findings go to someone independent. |
Which conflicts does AI introduce that a classic SoD matrix misses?
AI adds conflicting pairs that sit in configuration, not in transactions, so a classic matrix misses them:
- Agent configurer and approver. Whoever writes an agent’s instructions and skills shapes every entry it drafts. In Odoo 20, "topics" are renamed "skills" and default prompts accept context and dynamic values, so a one-line change can alter a month of drafts. That person should not approve them.
- Requester and approver of the same run. The person who asks an agent to prepare a correcting entry should not be the one who approves it.
- Trigger owner and process owner. Agents can be fired by automated and scheduled actions, and Studio automation rules can now trigger activity plans. Changing a trigger is changing a control, so it needs change management.
- Button clicker and authority holder. Odoo 20 agents ask questions, request permission and make suggestions answered by buttons, and they ask before exceeding their tool call limit. Each click is an approval, so define who may click.
- Connection owner and data owner. The release notes describe connecting to the database via MCP. An external connection is a user with rights; it belongs in the matrix and in your design for connecting AI to Odoo.
How do you design internal controls for AI agents in Odoo?
Treat each agent like a new team member who works fast, never tires and has no judgment. Our procedure:
- Inventory every agent, every automated or scheduled action that calls AI, and every API or MCP connection. Record its owner, its trigger and the models it can create or update.
- Map each one to the four functions and add it to the SoD matrix as its own row, next to the people.
- Set its access rights to the minimum. Odoo’s 20 release notes say record rules are removed and the domain is set directly on the access right, so any restriction you relied on before an upgrade must be re-checked, not assumed.
- Keep agent output in draft. A named person who did not configure the agent posts it. Confirm in your database that the agent’s rights do not allow posting or confirming.
- Tier approvals by materiality: above your ISA 320 materiality threshold, require a second approver.
- Correct by reversal, never by deletion, and protect closed periods with lock dates (long-standing in recent Odoo versions; confirm in your 20 database who can change them).
- Retain evidence outside the chat. Stored AI conversations are kept up to 30 days after the last message, so anything you need as audit evidence must be captured in the record or a working paper before then.
- Review agent rights and configuration every quarter, using the user group change log that Odoo 20 keeps in each user’s chatter.
The governance of the agents themselves is covered in Odoo 20 AI agents under finance controls, and the principle behind step 4 is set out in agents draft, people approve.
An agent that can write to the ledger is a user. Give it a role, an owner, and a person who signs for its work.
How can AI test segregation of duties instead of threatening it?
A manual access review checks who could act. A data test checks who did act, on every transaction. The difference matters: the ACFE’s Occupational Fraud 2026 report found that more than half of cases involved a lack of internal controls or an override of existing ones, and that proactive data monitoring is associated with lower losses and faster detection.
| Risk | Preventive control | Detective test on the full population | Evidence to retain |
|---|---|---|---|
| Fictitious vendor paid | Vendor maintenance and payment release in different roles | Same user changed a vendor’s bank details and released a payment to that vendor | Vendor change log, payment record, user ids |
| Self-approved journal entry | Posting and approval in different roles | Same user created and posted a manual entry, especially late in the month and in round amounts | Entry history with creator and poster |
| Approval bypass | Purchase Order Approval above a set amount (recent Odoo versions; confirm in 20) | Orders confirmed outside the approval matrix, or split to fall just below the threshold | Order approval history, version of the approval matrix |
| Duplicate payment | Duplicate detection warnings on bills | Duplicate and near-duplicate payments, near-duplicate vendors | Bill ids, payment ids, warning status |
| Agent drift | Draft-only rights; approval by someone other than the configurer | Drafts approved by the person who configured or triggered the agent | Agent configuration history, approver id |
Running these tests on every record is the subject of full-population testing with AI. A hit is a lead, not a finding: two conflicting roles held by one user is a design weakness, and whether it was exploited is a question for evidence, as explained in AI-based fraud detection.
What if the team is too small to separate duties?
A two-person team cannot split seven conflicting pairs, and agents do not change that, because an agent cannot carry accountability. The answer is still compensating controls, now cheaper to run. An owner or general manager outside the transaction reviews a short monthly exception list produced by AI: users who both created and approved, vendor bank changes followed by payments, manual entries after the close. The review is quick because the list is short, and documented because the list is a record. That is COSO Principle 16 (ongoing and separate evaluations) in a form a small team can sustain.
Where to start on Monday
- List every AI agent, automation and external connection in your ERP, with one named owner for each.
- Add them as rows in your SoD matrix and mark the function each one performs.
- Remove posting, confirming and payment rights from agents; keep them on draft.
- Run one detective test on the last quarter: users who both created and approved the same journal entry or vendor payment.
- Agree who reviews the exceptions, and how evidence is kept beyond the 30-day conversation window.
This is how we built MFT Intelligence, twelve finance agents written by MFT’s accountants: agents draft correcting entries and adjustments, a named, registered person approves, a second approver is required above the client’s ISA 320 materiality threshold, corrections are made by reversal, and nothing is auto-posted. The Auditor agent is available now as a managed service, and our internal audit team can bring your agents into a segregation of duties review alongside your people. See also the AI audit trail and continuous auditing with AI.