An approval is worth exactly what the signature on it is worth, and that is a fact about a person. A file that records an approval has recorded that somebody with the authority to commit the money decided to commit it, on evidence they had seen, on a date. Where the same person who created the commitment can also release it, the signature stops being a control and becomes a formality performed over their own work — and the file, which looks identical either way, can no longer distinguish a decision from a routine.
That is the whole of segregation of duties, and it is a narrower idea than the phrase usually carries. It is not about hierarchy, seniority or departments. It is about one specific question asked of each pair of steps in a purchase: can one person hold both, and if they can, what does the second step still prove? Where the answer is nothing, the control is nominal, and the organisation is relying on a document that cannot do the job it appears to do.
This piece sets out the six duties a purchase cycle contains, the pairs that must not sit with one person, the limits that decide who may sign, a worked example of a $34,000 order that passed every check it was actually subjected to, the limit that separation cannot reach, and the one instruction that makes an agent usable in this work at all: it prepares and routes the case, and it never approves it.
What separation actually separates
The useful division is not between departments. It is between the step that creates a commitment and the step that releases value: raising the order and paying the invoice, approving the spend and issuing the order, adding a supplier and paying that supplier’s bank details. Each pair has the same structure — one act proposes, another disposes — and each collapses if one person can perform both.
Four pairs carry almost all of the risk in a purchase cycle.
Originate and approve. The person who wants the thing should not be the person who authorises buying it. This is not a statement about their honesty. It is a statement about what an approval evidences: where the requester signs their own request, the file records that somebody wanted the purchase, which was never in doubt.
Approve and release. The person who authorised the commitment should not be the person who clears the payment. Every fraud that runs through a purchase file passes through this pair, because an approval is only tested when the money moves, and the person testing it is the last control in the chain.
Buy and maintain the supplier master. Bank details are the point at which a legitimate purchase becomes an illegitimate payment. Where the buyer can add or amend a supplier’s account, every other control in the file is upstream of the fraud, and the paperwork will be impeccable.
Receive and clear. The person who signed for the goods should not be the person who reconciles the invoice against the receipt. This is the pair most often held by one person in a small organisation, usually because a warehouse manager also runs the paperwork, and it converts the receipt from evidence into a formality.
The remaining two duties — comparing quotes and issuing the order — sit inside the buy side, and they may sit with one person provided that person is not the approver. That is the point of a matrix rather than a rule: it locates the pairs that must be split, and leaves the rest to be organised around whoever does the work.
The six duties
Table 1. The six duties of a purchase cycle, the pair each must be separated from, and what an agent may do at that step. Source: the studio’s purchase manager specification, whose approval record carries a person’s named decision and whose order cannot be issued where nothing has been approved.
| Duty | Held by | Must not be held with | What the agent may do |
|---|---|---|---|
| Raise the requirement | The person who needs the goods | Approving the commitment | Draft the request from a message or a document |
| Compare the quotes | A buyer or a desk, on a stated basis | Maintaining the supplier master | Read the quotes, normalise them, build the comparison |
| Approve the commitment | A person, by name, inside a stated limit | Releasing the payment | Assemble the case for the decision; never take it |
| Issue the order | The buyer, once approval exists | Approving the same order | Render the order, restate the approved terms, send it from the client’s mailbox |
| Receive the goods | Stores, a carrier, a person at the door | Clearing the invoice | Nothing: a receipt is somebody’s evidence of an event |
| Clear the invoice and release payment | Accounts, inside their own limits | Approving the order and receiving the goods | Run the three-way match and report the variances line by line |
The table is short because the work is. What makes it a control is not the length but the direction of the arrows: the agent appears in five of the six rows, is given nothing at all in the receipt, and is excluded from the decision in the approval row. That is the design constraint, and it is a property of the workspace rather than a promise in a manual — there is no payment rail in the assembly that reaches a supplier, so release is not a step the agent declines to take; it is a step that does not exist for it.
The fifth row deserves the emphasis. An agent cannot certify that a delivery happened, because evidence of receipt is a document produced by somebody who was there, and no reading of an invoice or a delivery note creates one. Where the receipt is missing, the correct state of the match is held, not cleared, and an agent that inferred a receipt from an invoice would have destroyed the only independent document in the set.
Limits, and what they decide
An approval limit is a delegation: a named person may commit the organisation’s money up to a figure, and beyond that figure the authority belongs to somebody else. The figures are a matter of policy and differ between organisations by orders of magnitude, which is why the numbers below are labelled as one illustrative organisation’s stated policy rather than offered as a norm. What does not differ is the structure: a band, a signature count, and evidence that ties the signature to the order.
Table 2. Four approval bands as stated policy of the illustrative organisation in this piece, with the evidence each band leaves. Illustrative policy, not a norm.
| Band | Value | Signatures required | Evidence in the file |
|---|---|---|---|
| Desk | up to $2,500.00 | One, the desk holder | Named approver, date, the comparison the decision rests on |
| Functional head | $2,500.00 to $25,000.00 | One, the functional head | As above, plus the limit the signature relied on |
| Two signatures | $25,000.00 to $100,000.00 | Two: functional head and finance director | As above, plus both signatures dated after the comparison |
| Board | above $100,000.00 | Two directors and a minute | As above, plus the resolution |
The last column of Table 2 is where these schemes fail in practice, and it fails quietly. A second signature dated before the comparison it rests on is not an approval; it is a signature in anticipation. A signature dated after the order left is not an authorisation, it is a ratification, and a file full of ratifications is a file that documents the absence of the control it claims to operate.
The structure of a band scheme also creates its own failure mode, which no individual approval can detect. A person whose limit is $2,500.00 can commit $2,500.00 ten times in a month and remain inside their authority every time. Splitting is invisible per transaction and visible only in aggregate, which is why the second control on a limit is not another limit but a review: a monthly total by approver, by supplier and by item, read against the register. An agent that prepares approval cases will produce those rows as a by-product, and it is one of the few controls in this work that gets cheaper as the volume rises rather than more expensive.
Worked example: a $34,000 order that passed
The order is illustrative: 1,700 units at $20.00, $34,000.00, raised on 9 March by the operations manager and issued on 12 March. The functional head’s approval limit is $25,000.00, so the order falls in the two-signature band and requires the functional head and the finance director. Both signatures appear on the order, both dated 12 March.
Table 3. What the record for the order showed, and what each figure means. Constructed for this piece.
| Element | Amount | What it shows |
|---|---|---|
| Order value | $34,000.00 | Committed against the supplier |
| The first signatory’s stated limit | $25,000.00 | The authority that person actually held |
| Above that authority | $9,000.00 | Size of the authority breach, if the second signature is void |
| Invoice variance cleared by rule | $408.00 | 1.2 per cent of the order, inside the stated two per cent band, cleared with no name attached |
| Exposure | $34,408.00 | The whole transaction, not the excess |
Four checks would have caught it, and the file answered all four in a way that looked satisfactory.
The first check is the approval itself. Two signatures were present, dated 12 March. The comparison that the approval record rests on — the one that shows what was compared and on what basis — is dated 13 March. The signatures therefore precede their own evidence by a day, which means either the dates were recorded wrong, or the case was approved before it existed. A record that can be read both ways is a record that evidences neither.
The second is the receipt. The delivery note for the 1,700 units was signed by a member of the operations manager’s own team, which is not a separation failure in itself, since the team were the people at the door. It matters because of the third check.
The third is the match. The invoice came in at 1,700 × $20.24 = $34,408.00, a variance of $408.00, or 1.2 per cent, inside the organisation’s stated two per cent band, and inside the $500.00 absolute limit that applies whichever is lower. So the variance cleared by rule, as it was designed to, and the person who recorded that clearance was the operations manager — the same person who had raised the requirement, and whose team had signed for the goods.
Put the two failures side by side and the approval is worth nothing. The functional head’s signature is a person committing $34,000.00 against a limit of $25,000.00, which is $9,000.00 beyond the authority they held. The finance director’s signature is dated 12 March, one day before the comparison it rests on. So the order left on one signature that was outside its limit and one that was inside its date but ahead of its evidence, and the release was then held by the originator — which is the pair that the second section of this piece says must never sit together.
The fourth is the aggregate. Twenty orders from the same desk in the month, each inside a limit, none examined, is the pattern that splitting produces, and it appears in a report that nobody ran.
The arithmetic that matters is not the $9,000. The excess above the first signatory’s authority is the size of the authority breach, and it is the number an investigation would begin with. The exposure is $34,408.00, because both controls failed: the second signature evidences nothing about a decision taken before its evidence existed, and the release was held by the originator. Where two controls fail together, the loss is the transaction, not the difference between them. An organisation that reasons only about the $9,000 has measured the wrong quantity and will size its remediation to a tenth of the problem.
What separation cannot do
Segregation of duties is a design over permissions, and its first limit is that it inherits them. The agent can only separate duties the client’s own identity model separates. Where one login serves a whole office, every check in Table 1 is performed by the same account, and the file will record approvals that no person made, because no person was distinguishable. Configuring the workspace is therefore part of the control: a mailbox per role, a named approver per case, and an approval step that a person completes rather than one the agent fills in.
The second limit is the one that makes the rule absolute. An agent may prepare an approval case and may route it, and it may never approve it, because the value of the record is that the decision was made by somebody who could be asked about it afterwards. An approval taken by an agent is indistinguishable, in a file, from an approval taken by nobody — and worse, it is indistinguishable from one taken by somebody, which is the failure that no audit will find. This is not caution about model capability. It is what the artefact is for: the approval record exists so that a person can be identified later, and an agent that signs it has produced a document that cannot do that.
The third limit is collusion, which no separation of duties has ever prevented. Two people who agree to defraud an organisation can divide the duties between them and satisfy every rule in Table 1. Separation makes fraud require a second participant, which raises its cost and improves the odds of detection; it does not make fraud impossible, and a control framework sold on the claim that it does is being sold dishonestly.
The fourth limit is that a limit is a policy and not a measurement. The figures in Table 2 are one organisation’s judgement about how much money a role should be able to commit without a second opinion. Another organisation would choose different bands for the same roles, and both could be right. What is not a matter of judgement is that the limit is written down, that the approver is named, and that the record shows which band the decision fell in — because without those three, the limit exists only in the head of the person applying it.
The fifth is quieter. Separation of duties governs the purchase cycle and says nothing about the person who writes the specification, chooses the three suppliers or sets the tolerance. The controls in this piece all operate downstream of decisions that can determine the outcome on their own, and a well-separated cycle running against a specification written around one supplier’s product is a control that works perfectly and protects nothing.
The cost of routing
Approval routing is cheap, and it should be, because the control is only useful if it is cheap enough to operate on every order rather than on the ones that seem important.
Drafting the approval case is one call. Routing it to a signature is one call a signature, because a routed request is a document with the case attached and a named recipient. Recording the decision is one call. Rendering the order is one, and the match is one. A single-signature order is therefore five calls and a two-signature order is six, at the measured Base rate of $0.00700: $0.03500 and $0.04200 respectively.
A month of twenty orders, two of them in the two-signature band, is 18 × 5 + 2 × 6 = 102 calls, $0.71400. Adding the aggregate review — one call a working day to list the day’s approvals against the register, twenty calls — takes it to 122 calls and $0.85400. At the metered ceiling of $0.00955 a call the same 122 calls cost $1.16510, which is $0.31110, or 36 per cent, more, because a ceiling is what an agent authorises rather than what it spends.
The figure to hold beside that one is the exposure in Table 3. One order with two failed controls is $34,408.00, which is more than forty thousand times the monthly cost of routing every order properly and running the daily check. The arithmetic is not close, and it is not the reason organisations skip the check. They skip it because the failure is invisible until it is expensive, and because the person who would notice is the person the check would examine.
The decision
Name the approver and the limit in writing before the order exists, and put the band on the order itself, so that the file shows which authority was relied on rather than which authority was available. An approval whose band is not recorded cannot be tested later, and the test is the only use the record has.
Then give the agent the duty it may never hold, and write it on the role rather than in a policy that nobody reads: it prepares and it routes, and a person decides. Where the workspace cannot enforce that — where one login serves the desk — the separation is nominal whatever the documentation says.
And reconcile once a day. One call lists the approvals recorded against the register, twenty calls a month cost $0.14000, and it is the only control in this piece that catches the failure the individual approvals cannot see: a desk that never exceeds its limit and commits five times what it should.
Where this goes
- The pillar: x402.review/2026/10/31/commercial-operations/ — one record, two readers, and the approvals between them
- The role and its refusals: studio.x402.press/roles/purchase_manager — the approval record, the order and the match it cannot clear
- The other end of the same control: studio.x402.press/roles/sales — the proposal that commits terms, and the figures it may not invent
- The service it buys: x402.press/services/deepseek/ — the canonical price, seven chains
- The review: x402.review/2026/10/31/deepseek-review/ — the measured handshake and what it does not promise
Method note
The price was read from the live 402 challenge on Base on 31 October 2026, outside DeepSeek’s weekday peak windows of 01:00–04:00 and 06:00–10:00 UTC: 7000 atomic units under exact, which is $0.00700, and 9550 under upto at the max_tokens tested. Call counts are planning assumptions, stated in the cost section: five calls for a single-signature order, six where two signatures are routed, and twenty for a month of daily reconciliation.
The order, the people, the dates and the four bands are constructed for this piece and labelled as illustrative policy; they are not a norm, and no organisation, approver or payment is described. The point of the example is structural rather than numeric: two controls failed on the same transaction, and the exposure is the transaction rather than the excess over the first signatory’s limit. Where a real file is being examined, the same four checks apply in the same order — the approval against its evidence, the receipt against its signatory, the variance against the band, and the month against the register.
x402.review is written and edited by N.P. Vincent. The publication is connected to x402.press, which sells the services reviewed here; that interest is disclosed on every piece that touches a service, and it is stated here rather than left to inference.
Filed under Jobs · Tags: approvals, segregation-of-duties, controls, procurement
