Business software can make work faster while quietly allowing one user to create, approve and complete a transaction without independent review. The difficulty is rarely a lack of software. It is the absence of a clear operating design that tells people what the system should do, what evidence it should preserve and where human judgment still belongs.
The objective is a practical segregation-of-duties design that separates incompatible authority and detects conflicts that cannot be prevented. This guide explains the decisions, controls and measures needed to achieve that outcome. It is written for business owners, finance leaders, auditors and system administrators, with an emphasis on implementation rather than product promotion.
Define the result before selecting the tool
Write one sentence describing the result: the objective is a practical segregation-of-duties design that separates incompatible authority and detects conflicts that cannot be prevented. Name the business owner, the primary user and the system of record. Then define what a successful case looks like, what an unacceptable case looks like and which decisions require human authority. This short definition prevents the project from becoming a feature comparison without an operating purpose.
The scope should also state what is excluded. A first release may handle the common path while sending unusual, high-value or sensitive cases to a person. That is not a weakness. A bounded workflow is easier to test, measure and improve than a broad promise that quietly fails at the edges.
Identify the critical transaction stages
Conflicts can be found only after the full transaction is mapped from master-data creation to final accounting and cash movement. This establishes the boundary of the problem and prevents the team from optimizing an activity that does not improve the final result.
Take this operating step: list initiation, data maintenance, approval, execution, custody and reconciliation activities. Use this case as a test: supplier invoice and payment transaction. Record what enters the step, what changes and what leaves it. Reviewing job titles instead of actual permissions misses conflicts created by system access. The review measure is critical stages mapped to named roles and applications.
Preserve evidence that a reviewer can inspect later: the originating request, the rule applied, the responsible identity and the resulting change. Relate that record to critical stages mapped to named roles and applications without copying unrelated sensitive data into the audit trail.
Build a conflict matrix
The matrix should describe combinations of permissions that create unacceptable control concentration. Treat this as an operating rule, not a suggestion that people remember only when convenient.
Put the idea into practice as follows: pair incompatible activities such as supplier creation with payment release or journal entry with reconciliation. Test the rule against the expected path and a difficult variation of this case: supplier invoice and payment transaction. A generic template may overlook industry, system and process-specific conflicts. Monitor defined conflict rules with an accountable control owner so the owner can see whether the design works outside a demonstration.
The owner should be able to reproduce the decision from stored facts rather than memory. Keep the relevant input, approval or source version and outcome, then use defined conflict rules with an accountable control owner to identify cases that deserve investigation.
Review roles and direct permissions
A clean role design can be undermined by direct grants, inherited groups and temporary access. The value becomes visible when the rule is applied consistently across normal cases and exceptions.
A practical implementation is clear: extract effective access across ERP, banking, identity and supporting applications. Document the decision in language that business and technical owners can both verify. Reviewing only the role name provides false assurance about what the user can actually do. Use users with direct, inherited or unexplained critical permissions as an early warning that the process is drifting.
Make the control visible in the normal workflow. A timestamp, source reference, status change and named owner provide stronger evidence than a private message. Periodic review of users with direct, inherited or unexplained critical permissions shows whether the rule is operating consistently.
Prevent conflicts at provisioning
It is cheaper to stop incompatible access before assignment than to investigate it later. This is where many otherwise sensible implementations become unreliable: the concept is discussed, but it is not translated into fields, states and ownership.
The operating instruction is: check requested roles against the conflict matrix during approval and identity provisioning. Do not rely on a meeting or informal message as the permanent control. Manager approval alone may not identify a technical combination across several systems. Review conflicting access requests blocked or redesigned before activation at an interval proportionate to the impact of failure.
Documentation should be proportionate to consequence. Preserve the fields and events needed to explain the result, restrict access to that evidence and delete it according to policy. The operating report should surface conflicting access requests blocked or redesigned before activation.
Use compensating controls for small teams
A small company may be unable to separate every task but can add independent evidence and review. A strong design makes this requirement observable so that a reviewer can distinguish compliance from assumption.
Translate the principle into a visible control: limit value and scope, require secondary approval and perform timely transaction review. Apply it first to this case: supplier invoice and payment transaction. Gaps will be easier to observe within a defined example. Calling a control compensating does not make it effective unless it addresses the same risk. The owner should track exceptions with documented, performed and evidenced compensating reviews and investigate material changes.
Test this element with a small sample of completed and failed cases. The reviewer should trace the request through the decision and confirm the expected control occurred. Use exceptions with documented, performed and evidenced compensating reviews to distinguish an isolated error from a recurring weakness.
Control privileged and emergency access
Administrator and emergency roles can override normal application restrictions. The goal is not additional administration; it is to remove ambiguity before ambiguity turns into rework.
Implementation should begin with a small sample. make access time-bound, purpose-specific, logged and reviewed after use. Compare the result with the existing method before expanding the scope. Permanent emergency rights become an invisible alternative operating model. Evidence should include privileged sessions, overdue access and unreviewed emergency activity.
Assign responsibility for both the action and its evidence. If the workflow cannot show who changed what, under which authority and with which result, the control is not dependable. Review privileged sessions, overdue access and unreviewed emergency activity with the process owner.
Monitor transactions for realized conflicts
Access analysis shows potential risk while transaction analysis shows whether conflicting actions occurred. When this element is explicit, software and people can make compatible decisions instead of interpreting the workflow differently.
Choose an owner and make the requirement operational: link user and transaction logs to detect creation, approval and execution by the same identity or related accounts. The owner should be able to explain the rule without referring to hidden configuration. Shared accounts and weak logs can prevent reliable attribution. A useful control indicator is realized conflicts, duplicate payments and unsupported master-data changes.
Keep operational records separate from unrestricted content capture. Store identifiers, material inputs, control results and exceptions while minimizing personal or confidential detail. This gives the team enough context to interpret realized conflicts, duplicate payments and unsupported master-data changes.
Recertify after people and systems change
Transfers, new integrations and role updates can reintroduce conflicts after an initial cleanup. This keeps the system understandable after the original implementer, tool or business condition changes.
Use a controlled rollout and run periodic owner certification and trigger reviews after role or system changes. Review this defined case with users: supplier invoice and payment transaction. Ask whether the design removes uncertainty or merely moves it. Managers may approve long access lists without understanding individual permissions. Track removed access, unresolved conflicts and certification completion quality until the outcome is stable.
Close the loop by linking the metric to a decision. When removed access, unresolved conflicts and certification completion quality moves outside the accepted range, define who investigates, how quickly they respond and what can be paused until the cause is understood.
Implementation checklist
- List initiation, data maintenance, approval, execution, custody and reconciliation activities.
- Pair incompatible activities such as supplier creation with payment release or journal entry with reconciliation.
- Extract effective access across ERP, banking, identity and supporting applications.
- Check requested roles against the conflict matrix during approval and identity provisioning.
- Limit value and scope, require secondary approval and perform timely transaction review.
- Make access time-bound, purpose-specific, logged and reviewed after use.
- Link user and transaction logs to detect creation, approval and execution by the same identity or related accounts.
- Run periodic owner certification and trigger reviews after role or system changes.
- Assign one accountable owner for the complete outcome, not only the software.
- Test normal cases, missing information, duplicates, rejection, timeout and recovery.
- Record baseline performance before claiming an improvement.
A 30-day rollout
During the first week, document the current supplier invoice and payment transaction workflow and collect a small set of real examples. Confirm definitions, ownership and the system of record. Do not automate yet; use this stage to find conflicting assumptions and missing data.
In the second week, configure or prototype only the common path. Run the same cases through the old and proposed methods, compare outcomes and record exceptions. Keep write access limited and require review for consequential actions.
In the third week, add controls, failure handling and reporting. Test permissions, duplicate prevention, unavailable services, incorrect inputs and manual recovery. Train the people who will operate the workflow, including how to challenge or reverse a result.
In the final week, review critical stages mapped to named roles and applications, defined conflict rules with an accountable control owner, users with direct, inherited or unexplained critical permissions. Decide whether to expand, revise or stop. Capture unresolved risks and assign due dates. A controlled pause is better than scaling a workflow whose apparent speed depends on hidden manual repair.
Questions to ask before rollout
- Which result is the system accountable for, and who owns it?
- Which source is authoritative when two records disagree?
- What action can happen automatically, and what requires approval?
- How will a user understand, challenge or correct an outcome?
- What happens when required data or a connected service is unavailable?
- Which measures show genuine improvement rather than additional activity?
- How can the business migrate its data and rules if the chosen tool changes?
Final perspective
The objective is a practical segregation-of-duties design that separates incompatible authority and detects conflicts that cannot be prevented. Achieving it depends less on chasing the newest feature and more on clear definitions, narrow permissions, useful evidence and an owner who reviews real outcomes. Start with one bounded supplier invoice and payment transaction workflow, learn from exceptions and expand only when the result is dependable. That approach creates a system people can trust and improve.
Sources and further reading
- COSO internal control framework
- NIST role based access control project
- U.S. GAO Standards for Internal Control
