The SoD Translation Matrix — Mapping D365 F&O Duties to BC Permission Sets

Hybrid F&O and BC deployments are the architectural standard across GCC and UK enterprises. The security architectures of the two ERPs are fundamentally incompatible. A corporate SoD policy is useless if it gets lost in translation between headquarters and subsidiaries.

In hybrid Microsoft Dynamics 365 deployments, corporate headquarters operates on D365 F&O while regional subsidiaries or acquired entities run Business Central. This two-tier strategy optimizes licensing and implementation speed — but creates a massive dual governance challenge. You cannot export an SoD framework from F&O and import it into BC. The technical languages of access control are completely different.

The Fundamental Difference Between F&O and BC Security

D365 Finance & Operations

Hierarchical SoD Engine

Role → Duty → Privilege → Entry Point. Native SoD rules engine that explicitly defines conflicting duties and blocks or flags assignments at the Duty level. Compliance batch job scans SecurityUserRole table.

Business Central

Object-Based Permission Sets

Permission Sets → RIMDE object permissions (Read, Insert, Modify, Delete, Execute). No native SoD engine. No conflict matrix. Governance must be enforced entirely through manual permission set design.

The consequence: the same business risk exists in both systems but surfaces completely differently. In F&O, a violation is flagged by the system. In BC, no alarm sounds — the risk is silently present unless the administrator manually engineers exclusive permission sets.

The Translation Matrix — F&O Duties to BC Permission Set Objects

To enforce corporate compliance across a hybrid landscape, Security Architects must map high-level F&O duties to granular BC object permissions. The matrix must operate at the lowest object level — TableData and RIMDE — not at the permission set name level, which is often misleadingly broad.

Business Risk	F&O Conflict (Duty Level)	BC Equivalent (Object Level)	Risk
Ghost Vendor Fraud	`VendVendorMasterMaintain` + `VendPaymApprove`	Insert/Modify on TableData 23 (Vendor) + Execute on Payment Journal objects	Critical
Fraudulent GL Postings	`LedgerJournalTableMaintain` + `LedgerJournalTableApprove`	Insert/Modify on General Journal Line + Execute on Post General Journal codeunit	Critical
Unauthorized POs	`PurchOrderMaintain` + `PurchTableApprove`	Insert/Modify on Purchase Header + Execute on Purchase Order approval objects	High
Fictitious Revenue	`CustCustomerMasterMaintain` + `CustInvoiceMaintain`	Insert/Modify on Customer (TableData 18) + Insert on Sales Invoice Header	High
AP Disbursement Fraud	`VendInvoiceMaintain` + `VendPaymApprove`	Insert/Modify on Vendor Ledger Entry + Execute on Payment Export codeunit	Critical

Note on BC TableData 23: Table ID 23 is the verified internal identifier for the Vendor table in the latest Business Central Cloud version. Security architects must map to this granular object level — not to permission set names, which are often over-provisioned.

Why the Same Risk Is Harder to Catch in BC

In F&O, if an administrator attempts to assign a user a combination of roles containing VendVendorMasterMaintain and VendPaymApprove, the F&O kernel actively blocks or flags the assignment — provided SoD rules are configured.

In Business Central, if a user holds a Permission Set granting Insert/Modify rights on TableData 23 (Vendor) and simultaneously holds a Permission Set granting Execute rights on the Payment Journal objects — the system raises no alarm. The ghost vendor fraud risk is mathematically higher in the BC subsidiary environment because BC will never natively flag this combination.

How to Build a Unified Governance Framework

Abandon OOTB BC Permission Sets for financial rolesStandard BC Permission Sets are notoriously over-provisioned. They must be replaced with custom, task-specific Permission Sets engineered to mirror the F&O SoD Duty definitions.

Build the Translation Matrix at the object levelMap every critical F&O SoD conflict pair to its equivalent BC TableData and page object permissions. Standard permission set names are insufficient — go to RIMDE level.

Apply the same SoD analysis process to BCAny cross-functional access request in the BC subsidiary must undergo the same rigorous conflict analysis that the F&O system natively enforces at headquarters. Manual process — quarterly minimum.

Include BC in the ITGC audit evidence packageAuditors extract RIMDE permission assignments from BC and map them against the global SoD policy. If BC allows what F&O forbids, the entire enterprise framework is deemed ineffective — impacting SOX 404 or regional regulatory compliance status.

⚠️ Auditors do not accept that a subsidiary should have weaker controls because it runs on a smaller ERP platform. If BC object permissions allow a business process that the F&O SoD engine explicitly forbids, the enterprise governance framework is deemed ineffective.

A unified SoD governance framework covering both D365 F&O and Business Central — the only specialist in the market who covers both ERPs simultaneously. Translation matrix, permission set engineering, and audit evidence package delivered within 5 days remotely.