An external auditor asks a routine question during fieldwork: can any single user create a new vendor and also approve or post a payment to that same vendor? At a lot of companies running Business Central, the honest answer requires someone to go check, because nobody's actually verified it — and there's a real chance the answer is yes for at least one person on staff.
This isn't a Business Central flaw exactly. It's a specific, documented gap in how the platform's native security model works, and it's worth understanding clearly before an auditor finds it for you.
Permission Sets Control What, Not Who Should Do What Together
Permission sets are the core mechanism in Business Central's security model — named bundles of table and object-level permissions defining whether a user can Read, Insert, Modify, Delete, or Execute against specific data and processes. A user can be assigned multiple permission sets simultaneously, which is exactly where the risk starts: each individual permission set might be entirely reasonable on its own, but the combination can quietly grant one person end-to-end control over an entire process.
This is the distinction worth being precise about: Business Central can express a segregation of duties design through careful permission set assignment, but it has no native engine that analyzes combined permissions, flags conflicts, or blocks an assignment that would grant one person control over an entire transaction lifecycle. The system does not scan for these combinations during setup. That responsibility sits entirely with whoever is designing and assigning the permission sets.
Security Groups Are Not the Same Thing as Permissions
Since Business Central's 2024 release wave 2, the old User Groups feature has been fully retired in favor of Security Groups managed in Microsoft Entra ID. This created a clearer, genuinely useful distinction: Security Groups control access — who can sign into Business Central at all — while permission sets control actions — what a signed-in user is actually allowed to do once inside. It's entirely possible for someone to be correctly restricted from certain areas by Security Group membership while still holding a dangerous combination of permission sets underneath that access layer. Confusing these two controls, or assuming one covers the other, is a common and specific mistake.
The Classic Conflict Pairs Worth Checking Directly
A handful of specific permission combinations show up repeatedly in audit findings and internal control reviews: a user who can both create a vendor record and approve or post payments to vendors; a user who can enter a purchase invoice and also release it for payment without a second set of eyes; a user who can create a sales order and also ship and invoice it without any independent review. None of these combinations are unusual to find in a Business Central environment that's grown organically since implementation, without anyone specifically auditing for them.
The fix isn't necessarily removing capability from anyone — it's making a deliberate decision about which duties genuinely need to stay separated, and then verifying, specifically, that no single permission set combination currently held by any one user crosses that line.
Approval Workflows Are a Complement, Not a Substitute
Approval workflows — covered in more depth elsewhere on this site — add a genuine layer of protection by requiring a second person to review specific transactions before they post. But it's worth being clear that workflows and permissions are different controls solving different problems. A workflow can require a second approver for a transaction; it does nothing to prevent the underlying permission structure from allowing one person to bypass that requirement if their permission set doesn't actually route through the workflow correctly. Both controls need to be right, independently, for the combination to actually hold.
What a Real Review Looks Like
A genuine segregation of duties review starts with a written conflict matrix — a specific list of duty combinations that should never sit with one person, decided deliberately rather than assumed. From there, every current user's combined permission set assignments need to be checked against that matrix directly, not against how the system was originally intended to be configured at implementation. Because permission sets can be layered custom-on-standard and assigned individually or through Security Groups, this check genuinely requires someone to sit down and trace actual combined access — it isn't something Business Central will flag on its own.
Where to Start
Before your next audit surfaces this as a finding, it's worth checking directly whether any user currently holds both sides of the classic conflict pairs — vendor creation and payment approval, invoice entry and payment release, order creation and shipment/invoicing. Most companies find at least one gap once they actually look, simply because nobody had checked since the original implementation.