What segregation of duties means in Business Central
Segregation of duties is the principle that no single person should control every step of a sensitive process. You split a transaction across at least two people, so the person who starts it is not the person who approves or completes it. That second pair of eyes catches honest mistakes and makes fraud much harder to pull off.
In Business Central this comes down to who can do what across four types of action:
- Creating or changing master data (vendors, customers, bank accounts, items)
- Entering transactions (purchase invoices, journals, sales orders)
- Approving transactions (releasing documents, approving payments)
- Posting transactions (writing them to the ledger)
The basic rule: the same user should not both initiate and complete a financially sensitive action. Someone who can set up a vendor should not also be able to post the payment to that vendor. Business Central has the building blocks to enforce that. Using them correctly is up to you.
Why segregation of duties matters
Audit readiness and financial control
When an auditor reviews your Business Central environment, access to the system is part of what gets tested. If the SoD setup is weak, the auditor cannot rely on the system to prevent errors, and has to compensate with more testing of the transactions themselves.
Beyond the audit, SoD is how you catch errors and deter fraud before money leaves the building. A duplicate payment, a fake vendor, a manual journal that hides a shortfall: these are the scenarios SoD is built to prevent.
The compliance frameworks that ask for it
Segregation of duties appears in most of the control frameworks organizations are measured against:
- SOX (ICFR): Public companies must show effective internal control over financial reporting under Section 404. SoD in the ERP is part of the application controls that get tested.
- ISAE 3402 / SOC 1: If you run processes on behalf of clients, your service auditor looks at whether users can bypass controls through combined access.
- COSO: The 2013 framework names segregation of duties under the control activities component, as a way to reduce the risk of error and fraud.
- ISO 27001: Annex A control 5.3 requires conflicting duties and areas of responsibility to be segregated.
What these frameworks share is a demand for evidence. You have to show that conflicting access is either prevented or monitored.
How Business Central handles permissions
Before you can design SoD, you need to know what each native feature does and what it does not do. If you want the wider picture first, our overview of Business Central security sets the scene.
Permission sets
Permission sets are the security layer in Business Central. Each permission in a set grants Read, Insert, Modify, Delete or Execute rights on a specific object, such as a table, page or report. You assign sets to users directly or through security groups. Sets can also exclude permissions, so a user's final access is not always a simple sum of everything they hold. If you are still shaping your role model, start with the fundamentals of Business Central permissions and how permission sets are built.
Permission sets work at the object level. A set can say "this user may insert records in the Payment Journal," but it has no concept of "this user should not also be able to create vendors." Business Central will let you assign two sets that together create a conflict, and it will not warn you.
User profiles (roles)
Profiles, shown as Roles in the client, control the Role Center a user lands on and how the interface is arranged. They shape what someone sees and where. They do not enforce security. A user with a limited Role Center can still hold broad permission sets underneath, so a tidy home screen says nothing about what that user is allowed to do.
Effective Permissions
The Effective Permissions page, opened from the user card, shows the access a user actually ends up with after all their permission sets are combined, and through which set each permission is granted. You need the SECURITY or SUPER permission set to view it for other users. This is where hidden conflicts surface: two harmless looking sets can combine into a user who can both enter and post the same journal.
Approval workflows
Business Central includes approval workflows that hold a document until a designated approver releases it. Set up well, an approval on purchase invoices or payment journals is a real compensating control. Even if one person enters the transaction, a second has to approve it before it moves on.
Approvals only cover the documents you configure them for, and a user with the right permissions can change or switch off a workflow. They work best on top of a clean permission design.
The SUPER problem
Every Business Central environment has the SUPER permission set, which grants unrestricted access. It is meant for administrators, but it tends to spread to people who once needed it for a project and never gave it back. Any user with SUPER sidesteps every SoD control at once. Track who holds it, document why, and keep the list short. We wrote about why SUPER is the permission set to watch in more detail.
Where native Business Central falls short for segregation of duties
Native Business Central gives you the levers to separate duties. It gives you very little to check whether you have actually done it:
- Permission sets grant rights on tables and pages, not on processes. They have no idea that "create vendor" and "post payment" are a conflicting pair. You have to keep that knowledge in your head or in a spreadsheet.
- Business Central does not tell you that a user's combined permissions create an SoD violation. Effective Permissions shows the access, but it does not compare that access against a set of conflict rules.
- Field monitoring can email you when someone changes a sensitive field, such as a bank account number. But when a user gains a conflicting combination of permissions, nothing flags it as a conflict. You find out at the next manual review.
- The change log records changes to the tables you choose to track. It does not give you a view of who could do what on a given date. Answering "did this person have posting rights in March" means piecing it together from log entries, provided logging was set up in advance.
SoD is a governance question, and permissions only answer part of it. You close the gap with a conflict matrix, a review routine and, as the number of users grows, tooling that checks the conflicts for you.
The Business Central segregation of duties conflict matrix
A conflict matrix lists the function pairs that should never sit with the same person. It turns a vague principle into a checklist you can test against. Use the table below as a starting point and adjust it to your own processes.
| Function A | Conflicting function B | Why it is a risk | Where it lives in Business Central |
|---|---|---|---|
| Create or edit vendors | Post vendor payments | A fake or altered vendor can be paid without review | Vendor card + Payment Journal / Payment Registration |
| Create purchase invoices | Post purchase invoices | One person can enter and book a cost with no second check | Purchase Invoice entry + Post rights |
| Create or edit customers | Set or change credit limits | Credit exposure can be raised to push through a sale | Customer card + Credit Limit (LCY) field |
| Enter general journals | Post general journals | Manual entries can hide shortfalls or move balances | General Journal + Post |
| Create purchase orders | Post goods receipts | Ordered and received by the same hand invites phantom receipts | Purchase Order + Warehouse Receipt / receipt posting |
| Set up bank accounts | Execute payment runs | Payments can be routed to an account the same person controls | Bank Account card + Payment Journal |
| Manage users and permissions | Post financial transactions | An admin can grant themselves access, then act on it | User and permission management + any posting right |
| Edit item costs or prices | Post inventory adjustments | Value can be shifted and then written to the ledger unnoticed | Item card + Item Journal post |
| Release sales documents | Post shipments and invoices | Revenue can be recognized without independent approval | Sales approval + Post shipment/invoice |
| Change vendor bank details | Approve payments | Redirected payments slip past a lone approver | Vendor bank accounts + Approval workflow |
Read the table as a set of rules: for each row, the two functions belong to different people, or the combination needs a compensating control. The next sections go through the conflicts you will run into most.
The most common SoD conflicts, explained
Procure to pay
This conflict runs from master data all the way to cash. One person creating the vendor, entering the invoice and releasing the payment can pay an invoice that never should have existed. Split it into at least two roles: one owns vendor setup and invoice entry, another owns payment approval and posting. An approval workflow on the payment journal adds a hard stop, even in a small team.
Record creation versus posting
The broadest conflict. It shows up across journals, purchase documents and sales documents. Whoever creates a transaction should not be the one who posts it to the ledger, because a posted entry can only be corrected with a new entry. In Business Central you enforce this by putting entry rights and posting rights in separate permission sets and giving posting to a smaller group of finance staff.
Master data versus transactions
Changes to master data draw less attention than postings. Someone who can edit a customer's credit limit and also enter their sales orders can push a sale past a limit that exists for a reason. The same goes for vendor bank details, price lists and payment terms. Keep master data maintenance away from the people who transact against it, and protect the most sensitive fields directly with Field Security and Field Validation.
Bank setup versus payment runs
A person who can add or edit bank accounts and also run payments can direct money to an account they control. This pair should always sit with different people, and payment runs deserve an approval step on top.
User administration versus posting
A user who manages permissions can grant themselves any access they want. Combining permission management with posting rights gives one person the keys to everything, and it undoes every other rule in the matrix. Keep security administration separate from day to day financial work, and keep an eye on changes to permission assignments.
How auditors test segregation of duties in Business Central
Knowing what your auditor will ask for lets you prepare the evidence before they request it.
- Who can do what? The auditor wants an overview of users and their effective permissions, compared against a conflict matrix like the one above. A user who shows up on both sides of a conflicting pair is a finding.
- Is the conflict prevented or compensated? Where full separation is not possible, they want a documented compensating control, usually an approval workflow, plus evidence that it is switched on and used.
- Can you show it over time? A snapshot of today says little about the rest of the year. Expect questions about who granted what, when, and who approved it. Business Central only answers those if the change log was set up for it beforehand, which is why a solid Dynamics 365 audit trail matters.
If you can hand over a permissions overview, a conflict matrix mapped against it, proof that approvals are live and a record of changes, most of the audit questions on access are covered before they are asked.
How to build an SoD-safe permission model, step by step
- Map your conflicting function pairs. Start from the matrix above and adapt it to your own processes and modules. This is your rulebook.
- Translate each function to Business Central objects. For every function, note the permission sets, tables and pages that grant it. That makes the rules testable.
- Design roles around jobs, not people. Build permission sets that match real job functions, and keep them small so you can combine them cleanly instead of editing broad defaults.
- Assign by role and check the combination. After assigning, open Effective Permissions and confirm no user ends up on both sides of a conflict.
- Add approval workflows where separation is thin. Small teams cannot always split every duty. An approval on payments, journals and purchase invoices covers part of the gap.
- Remove SUPER from anyone who does not administer the system. Then document who keeps it and why.
- Set a review rhythm. Review at least quarterly, and in between keep track of changes to permissions so drift does not wait for the next review.
What to do when you find a conflict
Finding a conflict is normal. You can resolve it in four ways:
- Eliminate it. Split the two functions across different people. The cleanest answer when team size allows.
- Mitigate with an approval. Keep the functions together but require a second person to approve before anything commits. A preventive compensating control.
- Mitigate with monitoring. Keep the functions together and check the use of the risky combination through notifications or a periodic conflict report. A detective compensating control, and often the realistic choice for small teams.
- Accept and document. When the risk is low and separation is impractical, record the decision, the reasoning and who signed off. An accepted risk without documentation looks like an oversight to an auditor.
Finding a conflict and doing nothing is the one option that does not hold up. Every conflict on your matrix needs one of these four outcomes next to it, with a name attached.
Keeping segregation of duties intact over time
A clean SoD design decays. This is authorization creep, and it is why last year's audit result does not guarantee this year's.
It happens quietly. People get promoted and keep their old access alongside the new. Someone covers a colleague's leave and the temporary rights never come off. A project needs broad access for a month and holds it for a year. Each of these adds a permission on top of an existing one, until two of them combine into a conflict nobody chose.
Part of the defense is routine. Review effective permissions on a fixed schedule, at least quarterly, and always after turnover, promotions and upgrades. Remove access the moment a role ends rather than at the next review. The other part is tooling: as your number of users grows, manual reviews fall behind how often access changes.
Segregation of duties for Agents, Copilot and MCP
Business Central is opening up to AI. There are agents such as the Sales Order Agent, Copilot features, and an MCP server that lets agents built in Copilot Studio read and write Business Central data through API pages, including actions like posting documents. Each of these works inside your environment with permissions, and those permissions deserve the same SoD scrutiny as a human user's.
An agent that can both create a purchase order and post its receipt is the same conflict as a person who can. The difference is that an agent works faster and at a larger volume. As you let AI take on real work in Business Central, the question shifts from "which employee holds this access" to "which employee or agent holds this access," and your conflict matrix has to cover both.
Native tools, spreadsheets or dedicated software: what fits
There are three common ways to manage SoD in Business Central. Which one fits depends mainly on your size and how heavy your audit pressure is.
| Approach | Strengths | Limits | Fits |
|---|---|---|---|
| Native BC only | No extra cost, already in the system | No conflict detection, conflict checks are manual | Small teams, light audit pressure |
| Native BC plus a spreadsheet matrix | Cheap, makes conflicts explicit and testable | Manual, out of date fast, error prone at scale | Mid-size teams doing periodic reviews |
| Dedicated SoD software | Automated conflict analysis, change log, review history, reporting | Investment in a tool | Growing user base, real audit pressure, regulated sectors |
The bigger and more regulated you are, the harder it is for a manual approach to keep up. Beyond roughly 25 to 50 Business Central users, maintaining security by hand becomes difficult.
How 2-Controlware helps you stay in control
2-Controlware's Authorization Box is built for the gaps native Business Central leaves open. With Authorization Monitoring you define critical permissions and the combinations that conflict once. The analysis then runs them against your current setup and shows which users, organization roles and permission sets hold a conflicting combination. You can review each result, and the results can be exported to Excel for compliance documentation.
Authorization Box also keeps a change log of who assigned which authorizations, and a review history of who assessed each result and when. With the Continuous Monitoring module you get a notification in your dashboard or by email when access to a critical permission changes: immediately, daily, weekly or monthly. The monitoring also shows Business Central AI agents, separated from human users by license type, so their permissions are part of the risk analysis.
For the most sensitive master data, Field Security adds a layer at field level. You can make fields such as vendor bank account numbers and customer credit limits non-editable for users who should not change them. Field Validation checks that the values entered meet your business rules.
