The four duties in an expense
Every expense passes through four distinct kinds of authority. Naming them separately is most of the work, because in practice they get bundled into job titles that obscure the split.
Incurring. Committing the company to the cost. Usually the employee, sometimes a budget owner booking on someone's behalf.
Authorising. Deciding the cost is legitimate and within policy. The approver.
Recording. Entering the expense into the books: category, entity, cost center, period.
Custody and disbursement. Controlling the money and releasing the payment.
A fifth function sits across all four: reviewing, meaning the after-the-fact check that the other four behaved. Reviewing is not a duty in the same sense — it is the control that detects when the separation failed — but it needs its own independence, which is why an approver auditing their own approvals is not a review.
The rule of thumb is that the first four should be spread across at least two people for a routine claim, and across at least three where the amount or the risk is material.
The conflict matrix
Read this as: if one person holds both duties in a row, this is what becomes possible and this is what to do about it.
| Combined duties | What it enables | Practical control |
|---|---|---|
| Incur + Authorise | Self-approval. Any personal or out-of-policy spend passes because the only reviewer is the beneficiary. | Reassign by rule when the approver appears in the expense; route to the approver's own approver. |
| Incur + Record | The person who spent chooses the category, entity and period the cost lands in. Misclassification becomes invisible. | Categories driven by rules or by a finance-owned mapping, not free choice at submission. |
| Authorise + Disburse | An approved payment can be released with no second look at whether it matches the approval. | Payment executed by someone who did not approve; match the payment file against the approved set. |
| Record + Disburse | The classic cash-misappropriation combination: the record can be adjusted to fit what was paid. | Independent reconciliation of the payment run against recorded liabilities. |
| Authorise + Configure the rules | An approver can widen a threshold, approve, and narrow it again. Nothing in the expense record shows it. | Rule changes are audit-logged, versioned, and reviewed by someone who is not an approver. |
| Any duty + Review | The check is performed by a participant. It will not find anything. | Review assigned to someone outside the chain, or to an external party. |
The last two rows are the ones most often missing from SoD checklists. Configuration authority is a real duty — someone who can edit the approval thresholds has effective authority over every expense those thresholds govern — and it usually sits with whoever administers the system, which is frequently also a senior approver. Worth checking explicitly, because no expense record will ever reveal it.
Self-approval: the one everybody has
Self-approval is the most common overlap and the easiest to reason about, which makes it a good place to start.
The obvious form — an employee approving their own claim — is usually blocked by construction. The forms that survive are subtler:
- The manager attended the team dinner the employee submitted. The approver is a beneficiary even though they are not the submitter.
- A founder or country lead submits an expense and the only person senior enough to approve it reports to them.
- An approver is temporarily covering for their own manager and approves an expense they themselves would otherwise have submitted upward.
- Two peers approve each other's claims reciprocally. Formally separated, practically not.
The first is fixable by rule: when the approver appears in the expense — as an attendee, a beneficiary, or the requester — reassign it. The second is not fixable by rule and needs a named exception route, typically to the board, an audit committee, or an external reviewer, with the exception itself recorded. The third and fourth are detection problems: they are visible in the approval history and invisible in any single claim, which means the control is a periodic report, not a check at submission time.
Do not attempt to solve the second case by adding a fictional approver. An approval chain that routes to someone with no real authority to refuse is worse than an acknowledged exception, because it looks like a control in the audit file.
When the team is too small to separate
Below a certain size the four duties genuinely cannot be spread across four people, and pretending otherwise produces paper controls. The accepted answer is compensating controls: accept the overlap, document it, and add detection that a small team can actually sustain.
What works in practice:
Move the review outside the process
The person who cannot be separated from the transaction should not be the one reviewing it. An owner, a board member, or an external accountant reviewing a monthly report is a real control even when they touch nothing daily.
Make the exception explicit and dated
"Finance manager both records and pays, reviewed monthly by the CFO against the bank statement" is a defensible position. The same arrangement undocumented is a finding.
Use thresholds to buy separation where it matters
Full separation on everything is unaffordable; separation above a threshold is not. Concentrate the second pair of eyes where the amount justifies it.
Log configuration changes
This is cheap and it covers the duty most likely to be concentrated in a small team, where one person usually administers everything.
Rotate what you can
Even irregular rotation of who performs the monthly reconciliation breaks the assumption that the same person's work is never seen by anyone else.
The framing that helps here comes from the internal-control literature: control activities are one component among several, and they depend on information and monitoring to function. A small team that cannot separate duties can still monitor, and monitoring is what turns an acknowledged overlap into a managed risk rather than an unexamined one.
Delegation without breaking segregation
Delegation is where a well-designed separation quietly collapses, because the delegate inherits authority without inheriting the constraints that justified it.
Three rules keep it intact:
Delegation is a recorded state, not a favour. It has a delegate, a start, an end, and a reason. An approval that appears under someone’s name because a colleague had their laptop is not a delegation; it is an unlogged authority transfer, and it is indistinguishable from the real thing in the record.
A delegate inherits the delegator's conflicts. If the delegator could not approve a given expense, neither can the delegate acting in their place. This is easy to state and easy to omit from a system that treats delegation as a simple reassignment.
Delegation does not stack. A delegate should not be able to delegate onward. Two hops is enough to make the chain unreconstructable, and the audit question is always "who actually decided this?"
A delegation of authority matrix builder, in preparation, will produce the role and threshold grid this rests on; automated expense approvals covers the routing mechanics.
Checking your own setup in an afternoon
This is a review any finance team can run without a project.
- List who can do each of the five things. Incur, authorise, record, disburse, configure. Names, not roles — job titles hide overlaps.
- Cross the list with itself. Anyone appearing in two columns of the matrix above is a finding. Do not skip the configure column.
- Pull the last quarter's approvals and look for reciprocity. Pairs who approve each other repeatedly are a pattern, not a coincidence.
- Find the expenses where the approver appears in the expense itself. Attendee lists, "team lunch", travel booked for a group. This is where self-approval hides.
- Check what happened during leave. Every delegation in the period should have a record with a start and an end. Approvals during someone’s absence with no matching delegation record are the finding.
- Check whether approval rules changed. If you cannot answer "who changed a threshold and when", that is the first gap to close, regardless of what else the review found.
- Write down the overlaps you are choosing to keep, with the compensating control for each. This is the output. A review that produces only findings and no accepted-risk list will be repeated identically next year.
How Clara supports separation of duties
Clara Global routes each expense to the right person based on the approval rules the finance team defines, rather than relying on the submitter to forward it to an appropriate reviewer. Because the routing is rule-based, the conditions that enforce separation — amount bands, entity ownership, who the approver is — are configuration rather than convention, and the record shows which rule sent the expense where it went.
The rules are configured per company and evaluated on the expense itself, so the same separation holds for an employee in any country submitting in any currency.
Two limits are worth stating plainly. Software cannot separate duties that a company has assigned to one person — if the same individual approves, records and pays, no configuration changes that, and the honest control is the documented compensating one. And the routing enforces the rules it was given: a threshold set too high or an exception route pointing at a beneficiary will be applied faithfully and repeatedly. The separation is a design decision; the system's contribution is making it consistent and visible.
For the evidence side — what the record has to contain for any of this to be checkable later — see expense audit trails.