Expense Controls

An expense control is a rule evaluated against a record after the transaction has settled. It can flag, block posting, demand documentation, route to an approver or write to an audit log — but it cannot stop the payment, because the payment already happened. It sits at the review stage of the expense management pipeline.

That limitation defines the discipline. Card-level controls have one lever: approve or decline, in milliseconds, from the few data elements the network carries. Expense controls have a far richer data set — receipts, purpose, attendees, project codes, cardholder history — and a much weaker lever: withholding a sign-off rather than withholding money.

Knowing which lever you hold matters, because frameworks fail when a requirement is put in the wrong layer. A policy of "no purchases above a certain value without approval" is only a real control if enforced at authorisation; as an expense rule it merely reports that the purchase already happened. Conversely, a rule about who attended a meal cannot be evaluated at authorisation at all.

Policy rule

A condition evaluated against a record, producing a pass, a flag or a hard stop on posting.

Threshold

A value above which a requirement changes — documentation, approval level, or number of reviewers.

Delegation of authority

The written scheme setting out who may approve what, up to which value, and who acts in their absence.

Segregation of duties

The principle that no one person controls every stage: initiating, approving, recording and reviewing.

Exception

An item that failed a rule and needs a documented human decision rather than automatic processing.

Audit trail

The immutable record of what was done to an expense, by whom, when and on what basis.

Internal control theory sorts controls into three families by when they act. The vocabulary is dry but useful here, because it explains why expense controls behave as they do.

Almost everything the expense layer does is detective or corrective. Its one genuinely preventive move is refusing to post — holding an item out of the ledger until it is complete. That prevents a bad record, not bad spending. To prevent the spending itself, the requirement has to move upstream into card limits and category rules.

These rules only make sense once the whole record is visible. A payment network cannot tell you how many people attended a dinner, whether a flight was in a permitted class, or whether a gift went to a client or a colleague. An expense system can, because a human supplied that context.

• Per-head and per-occasion caps — the per-diem style rule, applied to meals, accommodation or hospitality against the number of people involved.
• Class-of-travel rules — conditions on fare class, often varying with journey length, seniority or whether the trip is client-facing.
• Alcohol rules — treated separately from food, because many companies and jurisdictions handle it differently for policy and accounting.
• Gift and hospitality limits — usually tied to anti-bribery policy, with recipient and value recorded rather than merely capped.
• Advance-booking conditions — late bookings treated as exceptions needing an explanation, since lateness is a planning failure rather than a cost failure.
• Personal-element rules — how a transaction with both business and private components is split, and who verifies the split.

Two design notes matter more than the rules themselves. Every rule needs a defined consequence — flag, escalate, block posting, or reject and recover — because a rule with no consequence is a suggestion, and staff calibrate to that quickly. And this site publishes no values for any of them: appropriate levels depend on jurisdiction, sector, entity and tax treatment. The structure generalises; the numbers do not.

A receipt threshold is the value above which documentary evidence becomes mandatory. Every company argues about where to set it, usually framing the argument wrongly — as rigour versus convenience, when it is really a question about what the evidence is for.

The resolution is to separate the two requirements. Require business purpose on everything, because it costs seconds and carries most of the information. Require documentary evidence above a threshold set deliberately and reviewed occasionally. What makes a threshold work is consistency, not its value: a rule applied unevenly teaches people that rules are negotiable. Business expenses covers why purpose outranks the receipt.

A delegation of authority scheme answers one question in writing: who may commit the company, to what extent, and who approves it afterwards. In a card program part of that authority is delegated in advance through the limit on the card; the rest is exercised at review. Routes are usually built on one or more of four dimensions, and most dysfunction comes from stacking too many at once.

Delegation also has to cover absence. A scheme with no named deputy stalls the moment someone takes leave, and the usual workaround — sharing credentials or approving informally on someone’s behalf — destroys the audit trail the scheme existed to create. Delegation should be explicit, time-bounded and logged as delegation.

• Every approval level has a named holder and a named deputy
• Approvers can see the business purpose and evidence, not just the amount
• Nobody approves their own expense at any level, including the most senior
• Delegated approvals are recorded as delegated, with the period stated
• The scheme is reviewed when the organisation structure changes, not annually by default

Segregation of duties is the requirement that no single person controls a transaction end to end. Four roles should not collapse into one: whoever initiates the spend, approves it, records it in the ledger, and reviews the result.

The obvious difficulty is small companies, where one person may plausibly hold three of those roles and pretending otherwise produces a control document describing a fiction. The honest response is a compensating control: someone outside the process — a director, a founder, an external accountant — reviews the whole population periodically instead of approving each item. Writing down that this is weaker than true segregation is worth more than claiming a separation that does not exist. Small business and finance teams discuss how this shifts with headcount.

Two detective controls earn their place in almost every expense process, because both catch things that are usually mistakes and occasionally are not.

Duplicate detection looks for the same cost entering twice. The common causes are innocent: a pending authorisation and its settlement both kept as records, a receipt submitted twice, two people expensing the same shared meal, a card feed reprocessed after an integration error. It matches on amount, date proximity, merchant and cardholder, and should surface candidates for a human rather than deleting anything — two identical charges at one merchant on one day are entirely possible.

Split-transaction detection looks for one purchase deliberately broken into pieces that each sit below a threshold. It is looking for intent rather than error. The signal is a cluster of transactions at the same merchant, close in time, each just under a boundary that matters.

The last row is the important one. Repeated split patterns more often signal an unrealistic threshold than bad faith, and treating every instance as misconduct is how a finance team loses the goodwill it needs. Where a limit is genuinely too low for the work, the fix is upstream in card limits.

A framework is judged by what it does with the items that fail, not the ones that pass. Most expense processes are reasonable at flagging and poor at resolving, which produces the characteristic symptom: a growing queue of flagged items everybody has learned to ignore.

1. Flag with a reason

   State which rule failed and why, in language the cardholder understands without an interpreter.

2. Route to someone who can decide

   An exception needs an owner able to approve it, reject it or change the rule. A queue with no owner is the same as ignoring it.

3. Ask before concluding

   Most exceptions have an ordinary explanation, and asking first is both fairer and faster.

4. Record the decision and the reason

   The value of the log is the reasoning. "Approved" tells a future reviewer nothing.

5. Review the pattern, not the item

   A rule that generates constant exceptions is the wrong rule. Volume is feedback about policy design.

That last step separates a framework that improves from one that ossifies. Exceptions carry information: they show where policy has drifted from how the business actually operates. Read the log as a design input and you end up with fewer, better rules; read it as a list of transgressions and you keep the same rules with less cooperation.

An audit trail answers a question asked long after the fact by someone who was not there: what happened to this item, who touched it, and on what basis was it accepted? A good trail can be read without anyone explaining it.

• Every state change is recorded with an actor, a timestamp and a reason where judgement was involved
• Records are append-only: corrections appear as new entries rather than overwriting history
• Attached evidence is stored with the record, not linked to a location that may disappear
• Approvals identify a person, not a shared account or a generic role mailbox
• Delegated actions are visible as delegation, with the delegating party named
• Retention is defined by policy, applied consistently, and reviewed against local requirements

Retention periods, acceptable formats and the status of a digital copy versus an original are jurisdiction-specific and change over time. The structure generalises; the parameters do not. Build the trail so it can satisfy whatever requirement applies, and confirm the requirement with a qualified adviser.

This is the distinction most worth getting right, and the reason both clusters exist on this site. Spending controls operate at authorisation, on payment-network data, with a binary outcome. Expense controls operate on the record, on human-supplied context, with a graded outcome. They are not duplicates: each enforces things the other structurally cannot.

The design rule follows directly: push a requirement as far upstream as it can actually be enforced, and no further. If a rule can be expressed in the data available at authorisation, put it there and it becomes preventive. If it needs human context, accept it as a review-time control and make the review fast rather than pretending it is prevention. The spending controls guide covers that translation and employee spending the policy language behind it. Where liability sits also shapes how strict review needs to be, which is the subject of corporate card vs business card and the corporate card guide.

This site is an independent reference project — not Brex, an issuer or a software provider. Nothing here describes a specific product’s features, and no rule or retention period should be adopted without professional advice.