The textbook split assumes four people you do not have
Segregation of duties in an ERP is written for a team of four. One person creates the vendor, a second approves it, a third enters the invoice, a fourth releases the payment run. If you own finance systems at a company with two hundred staff, you probably have three people in accounts payable and one of them covers treasury on Fridays.
The honest starting position is that some of these conflicts cannot be removed with the headcount you have, and whoever is selling you a role redesign knows that. What you can do is decide which conflicts would cost you real money, put a named control on those, and write down the rest so nobody is surprised in March.
I work on automation and controls projects in SAP and Oracle shops, mostly in the two hundred to two thousand employee range. The teams that come out of an audit cleanly are rarely the ones with the tidiest role matrix. They are the ones who can name their conflicts and show what they did about each one.
Two combinations carry most of the money risk
Not every conflict on the matrix deserves the same attention. The one that matters most is the ability to create or change a payee and then release money to it. In SAP S/4HANA that means vendor master maintenance sitting in the same composite role as the payment proposal and the payment run. In Oracle ERP it is supplier site and bank account maintenance alongside submitting a payment process request.
The second combination is the ability to change a price or a contract term and then approve the transaction that uses it. Someone who can edit a purchasing info record or a blanket agreement price, and who also sits in the release strategy for the resulting order, can move margin without ever touching an invoice. That one gets missed because it lives across purchasing and finance rather than inside a single module.
Everything else is real but smaller. Posting a journal and approving it matters less than it sounds when the journal hits a balance sheet account somebody independent reconciles at close. Rank your conflicts by what a determined person could take out of the business, and by whether the transaction already leaves a trail that someone outside the function reads. Vendor master sits at the centre of the first pair, which is why master data ownership and duty conflicts keep landing in the same meeting.
Compensating controls that someone actually performs
The weakest response to a conflict you cannot remove is a monthly sample review of everything. Twenty payments pulled at random from a population of four thousand will miss the one that matters, and it still costs a manager three hours. The review has to be aimed at the person who holds the conflict.
Pull every vendor master change made by that user in the period, join it to payments issued to those vendors within thirty days, and read that list in full. Change documents give you this in S/4HANA and the supplier audit history gives you it in Oracle. The population is almost always small enough to review line by line, which is the whole argument for narrowing it.
Then send the output to someone outside the function. A payables review performed by the payables manager who also approves the exceptions proves very little. A financial controller, an operations director or the chair of the audit committee all work, provided the report arrives on a fixed date and the reviewer signs that they read it. Add dual approval only on the combination you named, meaning a second release on payments to vendors created or changed in the last thirty days, rather than a second approval on everything above a threshold that slows the whole run down.
Roles drift the moment somebody goes on leave
The role design you signed off at go live is not the one running today. Someone went on parental leave, a colleague covered, a transaction got added to a derived role at four in the afternoon, and the ticket said temporary. Nobody closed it, because the conflict only exists while both grants are live and no report was watching that pair.
Put an expiry on every grant issued for cover. Validity dates on role assignment do this in SAP, role end dates do it in Oracle, and both get ignored unless somebody runs the report that lists what is expiring. Emergency access is the other half. Firefighter and break glass sessions produce a log worth reading, and most teams generate it and never open it. The method here is the one you would use for a permission audit on any other platform, which is to export the assignments and argue from the export.
Run the conflict report against production quarterly rather than against the design document, and compare it to last quarter. A new conflict that appeared with no change record behind it is the finding. The discipline that keeps security group sprawl under control in HCM does the same job in finance, and it fails the same way when nobody owns the review.
The vendor that existed for eleven days
At a manufacturer with about nine hundred staff, one person in accounts payable held vendor master maintenance and could release the payment proposal, because the second clerk left in January and the replacement started in June. We knew about the conflict. It sat on the risk register with a note saying the finance manager reviewed payments weekly.
That weekly review covered the run total and the ten largest payments. In March a vendor was created on a Tuesday, paid four thousand two hundred pounds on the Thursday, and blocked the following week. Nothing about it came near the top ten. It surfaced in September during an unrelated bank detail cleanup, when an analyst noticed a vendor with one payment and no purchase order history behind it.
The payment turned out to be a genuine emergency purchase entered badly, which is the usual ending. The control was still useless. We replaced the weekly total review with a report of every payment to a vendor created or changed in the previous thirty days, addressed to the financial controller, and the first run returned nine items across two months. Six were fine, three needed a conversation, and one of those conversations changed how the site raised urgent orders.
What the auditor wants to find in the file
External auditors rarely expect a mid-size finance team to have full segregation. What they react badly to is a control matrix claiming the conflict does not exist while the role assignment in production says otherwise. A risk that was identified, accepted at a named level and mitigated by a specific control is a much shorter conversation than one you are caught denying.
Keep the file plain. One register entry per conflict, naming the users who hold it, the reason removal is not possible this year, the compensating control, who performs it, and the evidence that it ran. Dates on all of it. None of this is legal or audit advice, and your external auditor decides what is acceptable in your reporting environment. Their view governs over anything written here.
Before your next close, pull the list of people who can both create a payee and release a payment in production today, not the list your design document predicts. If there are names on it, you already know which review you are building this quarter and who outside finance should be signing it.
