What a spend control actually is
A spend control has three parts. Drop any one of them and it stops being a control.
- A condition. Something the system can evaluate without a human reading the claim: an amount above a threshold, a restricted category, a missing receipt, an expense dated outside the reporting period, a currency that is not the entity’s functional currency.
- A response. What happens when the condition is true: auto-approve, route to a specific approver, escalate to finance, request additional evidence, or reject. “Flag for review” is only a response if someone is accountable for the queue.
- A record. Which rule fired, on which claim, what the reviewer decided, and what evidence was attached at the time. Without the record you have an enforcement action you cannot explain later, which is the same as no control from an auditor’s point of view.
The distinction that matters most is between the policy and the control. A policy says “meals over 50 require a receipt.” A control is the mechanism that refuses to accept the claim without one. Companies rarely have a policy problem; they have an enforcement gap between what the document says and what the workflow permits.
Internal control frameworks frame this as a system rather than a list of rules. COSO’s Internal Control — Integrated Framework organizes effective internal control into five interdependent components, and the framework’s own guidance is explicit that internal control has value beyond compliance and external financial reporting. The practical reading for a finance team: a control that fires but produces no information anyone monitors is not doing the job the framework describes.
Define controls by risk, not by department habit
The common failure mode is a rule set that grew by accretion — a threshold added after one bad quarter, a category restriction added after one complaint, none of it revisited. The result is a rule set nobody can explain and approvers learn to click through.
A more durable model starts from the risk and maps each one to a workflow response and the evidence that makes the decision defensible.
| Risk signal | Typical response | Evidence to capture |
|---|---|---|
| Amount above a category threshold | Route to a higher approval level | Threshold in force at submission, approver identity, decision timestamp |
| Restricted or non-reimbursable category | Reject, or require a documented exception | Category selected, exception justification, who granted it |
| Missing, unreadable, or duplicate receipt | Block submission or request re-upload | Attachment history, file hash or identifier, re-upload timestamps |
| Expense in a foreign currency | Apply the rate rule and route by converted amount | Original amount and currency, rate applied, rate source, conversion timestamp |
| Expense charged to the wrong entity | Return to submitter with the entity correction | Entity selected, corrected entity, who reassigned it |
| Claim dated outside the reporting period | Route to finance rather than the line manager | Expense date, submission date, period boundary applied |
| Repeated near-duplicate amounts and merchants | Flag for finance review | The matched claims, matching criteria, reviewer conclusion |
| Requested policy exception | Escalate to a named exception approver | The rule waived, the reason, the approval, the expiry |
Two things make this table usable rather than decorative. The first is that every row names the evidence, not just the response — the evidence column is what turns an enforcement decision into something you can defend. The second is that the responses are deliberately varied. A rule set where every risk resolves to “flag for review” concentrates all the work on one person, and a queue that long gets skimmed.
Clara Global evaluates conditions like these against the approval rules your finance team defines — amount bands, categories, currencies, entities, requesters, expense dates, cumulative spend over a period — and routes the expense accordingly, so the decision about who reviews what is made by the rule rather than by whoever happens to open the queue first.
The rules are configured per company and evaluated on the expense itself, so they apply to an employee in any country submitting in any currency. There is no separate market rollout to wait for.
Where the control sits in the workflow
The same rule produces very different outcomes depending on where it runs. Placing every control at the approval step is the most common design mistake, because by then the employee has already spent the money and the only remaining options are approve, reject, or negotiate.
- At submission — preventive. The strongest position. A required receipt, a mandatory category, a blocked merchant, a field that will not accept an out-of-range date. The employee gets the feedback while the claim is still theirs to fix, which is also when fixing it is cheapest.
- At approval — directive. Routing by amount, by category, by entity, or by exception status. This is where judgment belongs: the rule decides who looks, the human decides whether it is reasonable.
- At payment preparation — detective. Duplicate detection across the batch, entity and bank-account consistency, currency grouping. Claims that individually look fine can be wrong as a set, and this is the only stage that sees the set.
- After payment — corrective. Sampling, trend review, threshold recalibration. This stage does not stop anything; its job is to tell you which of the earlier three needs adjusting.
The point of the split is that each stage catches something the others structurally cannot. A control set that lives entirely at approval has no preventive layer at all, which is why so much of the work ends up as post-hoc cleanup.
Make enforcement visible
An enforced rule that nobody can see reads as an arbitrary decision, and arbitrary decisions generate exactly the back-and-forth the control was supposed to remove.
- The employee should see why. Not “claim rejected” but which rule applied, what the threshold was, and what would make the claim acceptable. This is not a courtesy — a submitter who understands the rule fixes the claim themselves instead of messaging finance, and stops triggering it on the next one.
- The reviewer should see what fired. Which rules evaluated true, what evidence was attached at the moment of the decision, and what the submitter was told. A reviewer approving without that context is not exercising judgment, they are guessing.
- The auditor should see the sequence. The rule in force at the time, the decision, the identity of the decider, and the evidence as it existed then — not as it looks after later edits. Rules change; an audit trail that shows today’s rule set against last year’s decision invites a finding that never happened.
This visibility requirement is why enforcement and audit trail are the same project rather than two. For what an expense audit trail must capture field by field, see expense audit trails. For how the routing itself gets decided, see automated expense approvals. And because the person who sets a rule should not be the only person who can approve an exception to it, the duty split behind all of this is covered in segregation of duties in expenses.
Controls across entities and currencies
A single global rule is usually too loose in one market and too strict in another. A threshold that is a reasonable manager-approval line in one country is a rounding error in another and a month of discretionary budget in a third. Applying it uniformly does not produce consistency, it produces a control that is ignored in one place and resented in the other.
Three decisions make multi-market controls behave.
Decide which currency the threshold is denominated in
A threshold in the entity’s functional currency and a threshold in a group reporting currency produce different outcomes for the same claim, and the difference moves with the exchange rate. Pick one deliberately and write it down, because a threshold whose denomination is ambiguous is a threshold that will be argued about.
Fix the rate at a defined moment
If the routing depends on a converted amount, the conversion has to happen at a point everyone can name. In Clara the rate applied is the one for the date of the transaction, fixed onto the claim at submission, so the converted amount that determined the routing is the same amount visible on the claim afterwards, rather than a figure that drifts between submission and review. The mechanics of choosing and documenting a rate are covered in foreign currency expenses and in multi-currency expense management.
Let entities override, within a group-level floor
Local finance knows what a reasonable meal costs in their market. Group finance needs to know that no entity has quietly set every threshold to infinity. An override model with a documented floor gives you both; a single global rule gives you neither.
The output of the whole chain is a reimbursement report grouped by currency and account that a finance team executes through its own bank — Clara produces the payment-ready report and does not execute the transfers itself, which means the controls have to be correct before the report is generated rather than after.
Rolling out controls without stalling the team
Control sets fail more often from over-specification at launch than from being too permissive. A rule set nobody can navigate produces rubber-stamping, and a rubber-stamped approval is a worse audit position than no approval step, because it documents a review that did not really happen.
Baseline from your own data first
Pull the last two quarters of claims and look at the actual distribution by amount, category, and entity. Thresholds set from the distribution land in a defensible place; thresholds set from intuition land at round numbers that either catch everything or nothing.
Start with three to five rules
Cover the risks that actually cost you money — usually amount, missing evidence, and restricted categories. Resist encoding every paragraph of the policy document.
Set thresholds at a percentile, not at a round number
If a threshold routes most claims to a senior approver, it is not a control, it is a bottleneck that will be worked around.
Tell people the rules before they fire
A control that surprises the person it affects generates a support ticket, not compliance.
Measure the exception rate per rule
A rule with a very high exception rate is mis-calibrated; a rule that never fires is either unnecessary or being bypassed upstream. Both need investigating, for opposite reasons.
Re-check thresholds on a schedule
Prices move, headcount moves, and a threshold set two years ago is now enforcing a policy nobody chose. Put the review on the calendar rather than waiting for a bad quarter to trigger it.
Where spend controls break
- Too many rules. Approvers stop reading and start clicking. Fewer, better-calibrated rules enforce more than a comprehensive set that is skimmed.
- Thresholds nobody revisits. The most common form of silent policy drift. The rule still fires, the number is just wrong.
- Rules encoded but never explained. Enforcement without explanation reads as arbitrary and gets escalated around rather than complied with.
- Controls with no evidence capture. The decision happened, the reasoning is gone. This failure surfaces during an audit rather than during operations, which is what makes it expensive.
- No named owner. A rule set with no owner is a rule set nobody is allowed to change, so people route around it instead. Every rule should have someone who can defend it and someone who can retire it.