Segregation of Duties in Dynamics 365 F&O: Why It Gets Designed After Go-Live, Not Before
A finance director at a mid-market manufacturer we spoke with recently put it plainly: her Dynamics 365 Finance & Operations go-live was six weeks out, the integration testing backlog was still red, and the security team had told her that role design was “basically done” because they had copied the standard Microsoft role templates and removed a few menu items nobody used. Nine months later, the statutory auditor’s segregation-of-duties (SoD) testing found that the same three accounts payable clerks who could create a vendor could also approve that vendor’s invoice and release the payment run. Nothing had gone wrong yet. But the finding went into the management letter, the board asked why internal financial controls hadn’t caught it, and the fix required a role redesign, a re-test cycle, and a change-management push against users who had spent nine months building muscle memory around access they were about to lose.
This is not a rare story. It is close to the default outcome when security design is treated as a configuration task subordinate to the go-live date, rather than as a control design exercise that happens to be implemented in configuration.
Dynamics 365 F&O’s security model is built in four layers: permissions attach to individual objects such as menu items, fields, or service operations; privileges group permissions into a meaningful unit of access; duties group privileges into something resembling a job function; and roles, the layer assigned to users, group duties. Microsoft’s own architecture documentation describes this hierarchy and includes a built-in segregation-of-duties violation report, reachable under System Administration, Security, Security Governance, where roles are checked against configured SoD rules and flagged when a single role combines duties that shouldn’t sit together. The capability exists inside the platform. What is not built in, and what Microsoft’s documentation does not prescribe for you, is which duty combinations actually constitute a conflict for your organization, and when in the implementation timeline that decision gets made.
Why the Sequencing Goes Wrong
The practical reason SoD design slips is that it depends on business process design being finished, and business process design is almost always the thing running behind schedule in an F&O program. Security teams under deadline pressure default to standard Microsoft role templates, lightly trimmed, because building roles from actual job functions and then testing every duty combination against a conflict matrix is slower and less visible than integration or data migration work, which have their own hard deadlines and their own visible failure modes when they slip. Security does not fail visibly in UAT the way a broken integration does. It fails quietly, eighteen months later, in an audit finding.
The conflicts that show up are rarely exotic. A single accounts payable role that can create a vendor, approve that vendor’s invoice, and release the payment run breaks the three-way logic that vendor controls exist to enforce, because the same person can originate a payee and authorize payment to it without independent review. A procurement role that combines purchase order creation, goods receipt confirmation, and invoice approval collapses the three-way match between order, receipt, and invoice into a single point of trust, which is precisely the control that three-way matching was designed to remove. And a role that combines general ledger journal posting with security administration privileges means the same person who can alter a financial record can also alter who is allowed to review it. None of these require malicious intent to become a problem; they are audit findings because the absence of independent verification is the risk, not any specific act.
The cost of catching these late is not primarily the hours to redesign the roles, though that is real. It is that role redesign after go-live is a change-management problem layered on top of a technical one. Users have already built habits around what their screen lets them do. Removing access reads, to them, as a demotion or an accusation, even when it is neither. Re-testing has to happen against a live system with live transaction volume rather than a UAT sandbox, which raises the bar for how carefully it has to be sequenced. And because the fix usually surfaces from an external audit rather than an internal review, it arrives with a deadline and an audience: the same board or audit committee that will ask why the design gap existed in the first place.
The India Dimension Makes the Timing Worse
Under Section 134(5)(e) of the Companies Act, 2013, company directors must state in the Board’s Report that internal financial controls are adequate and were operating effectively during the year. Under Section 143(3)(i), the statutory auditor has a corresponding obligation to evaluate and report on the adequacy of internal financial controls, applying auditing standards such as SA 315 and SA 330 to test whether controls, including access and segregation-of-duties controls inside core financial systems, actually operated as designed rather than merely existing on paper. This is not a checkbox exercise; it is an independent opinion that sits alongside the financial statements.
What makes the timing particularly awkward for a segment of Routeget’s own client base is a regulatory shift that took effect on December 1, 2025: the “small company” exemption thresholds under the Companies Act rose substantially, with the paid-up capital ceiling moving from ₹4 crore to ₹10 crore and the turnover ceiling from ₹40 crore to ₹100 crore. That change pulled a meaningful number of previously exempt private companies out of small-company status and, depending on their specific structure, closer to or inside ICFR reporting scope for the first time, often the same companies that are scaling past their legacy accounting system and implementing Dynamics 365 F&O or Business Central for the first time. A company that never had to think about segregation-of-duties testing under its old system is now doing an ERP implementation and stepping into ICFR obligations in roughly the same window, with no institutional memory of what auditors will actually test for.
There is a genuine trade-off here, not just a lesson in discipline. Locking SoD rules and role assignments before go-live, and holding the line on them, adds real time to a program that is usually already fighting the calendar, and over-restrictive early roles can create their own productivity problem if users legitimately need broader access during stabilization. Running in a more permissive mode during early stabilization and tightening roles after the system is live and stable is operationally easier in the short term, but it is exactly the sequencing that produces the audit finding described above, and it bets that nobody exploits the gap and that the remediation work actually gets prioritized once go-live pressure has passed, which is not always what happens once attention moves to the next fire.
Building the Control Matrix Before the Role Matrix
Routeget’s implementation teams have increasingly built what we internally refer to as a duty-conflict matrix as a deliverable that comes before role design is signed off, not after. The idea is straightforward even if the execution is not: before roles are built in the system, the target duty combinations that would constitute an SoD conflict are documented against the organization’s actual financial control objectives, drawing on the same categories statutory auditors test under SA 315, vendor-to-payment, procure-to-pay three-way match, and journal-to-approval separation among them, and that matrix is then used to configure and test Dynamics 365 F&O’s built-in SoD ruleset before the first UAT cycle for financial processes even begins, rather than treating the platform’s SoD violation report as something to run diagnostically after the fact.
This does not eliminate the trade-off described above; a program still has to decide how strict to be during stabilization, and that is ultimately a business decision, not a technical one. What it changes is where the conflict gets surfaced. Instead of a statutory auditor finding a vendor-and-payment conflict during year-one testing and turning it into a management letter item with board visibility, the same conflict gets identified during role design, while it is still a configuration decision rather than a remediation project competing for attention against whatever is on fire that quarter. For organizations newly in scope for ICFR reporting because of the December 2025 threshold changes, and for any F&O or Business Central program where the go-live date and the audit calendar are going to collide within the first year regardless, that sequencing difference is the entire point.
#DynamicsFinanceOps #SegregationOfDuties #ERPSecurity #InternalFinancialControls #ERPGovernance #AuditReadiness
Amarnath Gupta is a visionary digital transformation leader with over two decades of experience guiding Fortune 500 organizations through enterprise-wide innovation. He has built and scaled Microsoft Dynamics 365 practices into $7.5 million revenue engines, rescued high-risk global implementations, and delivered 35 percent operational efficiency gains, 40 percent faster go-lives, and 30 percent cost optimizations across industries from manufacturing to healthcare and construction.
His passion for marrying deep technical command in Dynamics 365, Azure AI/ML, and Power Platform with strategic P&L governance has spawned proprietary IP solutions like JewelPro™ and OmniClaim Sentinel™. A catalyst for modern AMS frameworks, he leverages predictive KQL analytics and intelligent support automation to slash incident resolution times by 30 percent and cut costs by up to 30 percent.
Amarnath writes about practical strategies for data-driven decision making, end-to-end ERP/CRM implementation best practices, and the future of cloud-native architectures. His work empowers readers to transform underperforming units into high-growth engines while embedding Agile/DevOps and Zero Trust security into every layer.
- Microsoft Dynamics 365 F&O, CE, Commerce, Field Services
- Azure AI/ML integration and predictive analytics
- Enterprise Application Maintenance & Support (AMS)
- Agile/DevOps delivery and operational excellence
- Data modernization and cloud transformation
Amarnath Gupta is a visionary digital transformation leader with over two decades of experience guiding Fortune 500 organizations through enterprise-wide innovation. He has built and scaled Microsoft Dynamics 365 practices into $7.5 million revenue engines, rescued high-risk global implementations, and delivered 35 percent operational efficiency gains, 40 percent faster go-lives, and 30 percent cost optimizations across industries from manufacturing to healthcare and construction.
His passion for marrying deep technical command in Dynamics 365, Azure AI/ML, and Power Platform with strategic P&L governance has spawned proprietary IP solutions like JewelPro™ and OmniClaim Sentinel™. A catalyst for modern AMS frameworks, he leverages predictive KQL analytics and intelligent support automation to slash incident resolution times by 30 percent and cut costs by up to 30 percent.
Amarnath writes about practical strategies for data-driven decision making, end-to-end ERP/CRM implementation best practices, and the future of cloud-native architectures. His work empowers readers to transform underperforming units into high-growth engines while embedding Agile/DevOps and Zero Trust security into every layer.
- Microsoft Dynamics 365 F&O, CE, Commerce, Field Services
- Azure AI/ML integration and predictive analytics
- Enterprise Application Maintenance & Support (AMS)
- Agile/DevOps delivery and operational excellence
- Data modernization and cloud transformation
