Four-eyes principle and segregation of duties

What is the four-eyes principle and segregation of duties?

The four-eyes principle means an action does not take effect until a second person has looked at it and said yes. One prepares, another releases. Segregation of duties means the same person may not carry out two steps that, held together, let an error or a fraud pass unnoticed. Whoever may create a supplier record may not also release the payments to that supplier.

Both come from the same worry: that one person can start something, finish it, and be the only one who ever sees it. Auditors ask about them because it is the cheapest question that shows how a company really works. Neither control assumes your people are dishonest. What they mostly catch is an ordinary mistake, a digit dropped from an account number or a credit note for the whole invoice instead of one line. Fraud is why the control ends up in the audit file. Errors are why it pays for itself.

Four eyes versus segregation of duties

The two get used as synonyms, and that costs companies real protection.

Four eyes is a second check on one action. One person prepares the payment run, a second releases it. Both look at the same thing at the same moment, and the control lives in that moment.

Segregation of duties is a split between two actions. Someone changes a supplier's bank details in March, someone pays that supplier in April. There is no shared moment, so the control has to live in the permission model.

That difference decides which failures you catch. Four eyes on the payment run does not stop an account number that was quietly changed a month earlier, because by then the payment looks correct: real supplier, real invoice, real delivery. Only the split catches that one. A company with a second signature on payments and no rule about who may touch supplier master data has bought the wrong control for its biggest risk.

The pairs one person should not hold

Audit practice sorts duties into four kinds: authorising a transaction, having the money or the goods under your control, recording it in the books, and checking it against reality. ISACA's implementation guidance works from those four, and the pairs that matter are the ones where one person covers two of them for the same asset. In a Belgian SME the list is short.

• Creating or changing a supplier, and releasing payments. Fix this one first. It is the pair invoice fraud runs on.

• Entering a purchase order, and confirming the goods receipt. Whoever orders and also confirms delivery can pay for something that never arrived.

• Raising the invoice, and matching the payment against it. One person on both sides of the customer ledger can settle an invoice with money that went elsewhere.

• Changing a price or a discount, and approving the order that uses it. Without the split, margin you cannot explain afterwards has no owner.

Microsoft's Dynamics 365 documentation uses the first case as its standard illustration: you might not want the same person to maintain vendor information, acknowledge the receipt of goods and process payment to the vendor.

A payment that four eyes would have stopped

An installation company, forty staff. One person in the purchase ledger keeps the supplier records and prepares the weekly payment file. A mail arrives from what looks like the regular cable supplier: an invoice for 18,400 euro for material that really was delivered two weeks earlier, plus a line saying the company has changed banks. She matches the invoice to a real delivery note, updates the account number because that is her work, and puts the invoice in Friday's file. The manager signs that file off on the total and the number of lines, the way he always does. Three weeks later the real supplier calls about an unpaid invoice.

The invoice check worked, so a second person approving that invoice would have approved it too. The step nobody checked was the account number, and the person who changed it was the person who prepared the payment. That is a duty pair, not a lapse of attention. The control that stops it takes two minutes: every change to a supplier's bank details goes to a second person, who rings the supplier on the number already in your own records rather than the one on the invoice, which is what Febelfin advises companies about invoice fraud. At a dozen changes a year, the whole control costs you half an hour.

What to do when finance is five people

Here is the part most control advice skips. With five people in finance and one of them part time, you cannot separate everything. Somebody has to run the payments when the other two are away in July, and hiring a sixth person to satisfy a matrix is not an option.

The frameworks say so themselves. The COSO internal control framework, which most auditors have in the back of their head, puts it in one line: where segregation of duties is not practical, management selects and develops alternative control activities. Microsoft writes the same into its Dynamics guidance for smaller legal entities. Keep the roles modular, allow the conflict, document the override.

What replaces the split is detection. You accept that one person can do both halves, and you make sure someone else sees it afterwards, soon enough to matter.

• A monthly list of new and changed suppliers, with who changed them. One page to the owner, not to the finance team, bank details at the top. Most months it is four lines and two minutes of reading.

• An alert outside finance on every bank account change. To one person who does not work in the ledger. It does not need approval rights to be useful, it needs to arrive.

• The owner opening the bank statement first. Whoever reconciles the accounts should not be the only person who ever reads them.

• A second signature above an amount in the banking tool. Business banking software and bank portals let you require a second signer, and the signing authority itself comes from the mandate your bank holds. Put the threshold where it costs you a minute a week.

Write the compensating control next to the pair it compensates for. An auditor reading "conflict accepted, monthly supplier review by the managing director, dated" is reading a decision. A blank there usually means nobody thought about it.

How the split gets enforced in the system

Role design. In Dynamics 365 finance and operations apps, permissions sit in privileges, privileges group into duties, and duties go into roles. A segregation of duties rule names two duties that may not meet, with a severity and a written description of the risk and of how you mitigate it if you allow it anyway. Give a user a role that combines them and the system refuses; an administrator who overrides it has to type a reason that lands on a conflicts page. That typed reason is worth more than the block itself, because it is the part an auditor can read. Watch one thing: a new rule is not checked against what already exists, so run the validation per rule after adding it, or it only applies to people hired after the day you wrote it.

Approval limits. An amount decides who signs. Nothing under 500 euro, the budget holder up to 5,000, the managing director above that. Set the thresholds from your own invoice distribution rather than a round number: if eight in ten purchase invoices are under 1,000 euro, a threshold at 250 buys you a queue, not a control.

A system that will not let the requester approve. This is the rule missing most often, and it breaks the same way every time. The approver is configured as the requester's manager, the requester is the manager, and the flow hands the task back to whoever raised it. Test it: raise a request as yourself and see whether you can approve it.

What happens to the split when an agent does the work

An agent that reads incoming invoices, creates a supplier record when it cannot find one, and puts the payment in the file holds a segregated pair. Nobody set out to do that. The permissions were granted one integration at a time and nobody added them up into duties. So add them up: write out what the agent may do as a list of duties, and run the same conflict rules over it that you run over a person.

Then there is identity. A four-eyes check only means something between two parties that can genuinely disagree. If the requester is a person and the approver is that person's own agent, running under a token they created, the log shows two actors and the room contains one. That is why an agent needs an identity of its own, separate from whoever built it, which the agent identity and non-human identity entries go into.

The sharpest problem comes last. A second check that always agrees is not a check. An agent in the approver seat that has approved everything it saw for six months gives you no assurance, and the tidy log makes it worse, because the log looks like evidence. This is automation bias in the shape of a control, and the measurement is simple. Count how often the second pair of eyes disagreed. Zero over months is a finding, whether the reviewer is a model or a person who has stopped reading.

The EU AI Act reaches for the same old control at the point where it matters most. Article 14(5) says that for remote biometric identification, no action or decision may be taken on the basis of an identification unless it has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority. Natural persons: two humans, not a human and a model. There is an exception for law enforcement, migration, border control and asylum where Union or national law finds it disproportionate, and almost no Belgian SME runs such a system anyway. What matters for the rest of us is which control the legislator picked where a mistake is hardest to undo, and it was not a better algorithm.

Start with the four riskiest actions

You do not need a matrix of every process. You need four lines.

1. Name the actions where one wrong move costs real money or real trust. Usually: releasing a payment, changing who gets paid, issuing a credit note or a discount, granting access to customer data.

2. Write the two halves of each, with names. Who prepares, who releases, and the holiday stand-in. Names rather than job titles, because a role nobody currently holds is how a split quietly disappears.

3. Try to break it. Log in as the preparer and attempt to release your own item. Half the splits people believe they have do not exist in the system.

4. For a pair you cannot split, write down the detective control and who runs it. Then pull the access list once a quarter and compare it against all of the above, because people change jobs and keep their old permissions.