Spending Controls

Companies routinely describe their spending policy as their controls. A policy is a statement of intent addressed to people; a control is a configured rule addressed to a system. The gap between the two is where most card programs quietly fail.

The test is mechanical. If a sentence in your policy corresponds to a setting somewhere — a ceiling, a permitted category list, a documentation threshold, a routing rule — it is a control. If it does not, it is guidance, enforced only insofar as people read it, remember it and follow it under time pressure. Confusing the two means believing you have prevented something you have only requested.

Control

A configured rule that changes the outcome or handling of a transaction, rather than a statement of what people should do.

Preventive control

Evaluated at authorisation. Its only outputs are approve and decline.

Detective control

Evaluated after posting. It flags, routes, escalates or demands evidence, but cannot reverse the purchase.

Exception

A legitimate purchase that a control blocks or flags, and the route by which it is resolved.

Every control belongs to one of two classes, and the class determines what it can honestly promise. Preventive controls are evaluated during authorisation, before funds move. Detective controls are evaluated after posting, when the money is committed and the available remedies are documentation, escalation and, at worst, a conversation.

One asymmetry is worth stating. Preventive controls act on very little information — an amount, a merchant descriptor, a timestamp and a classification code, and nothing about business purpose. Detective controls act on a richer record but too late to matter. Good design accepts the trade: prevent broadly on what you can see, detect precisely on what you cannot. Expense controls covers the second half.

Category rules are the most powerful preventive control after limits, and the most frequently misunderstood. They read the classification code accompanying an authorisation request and compare it against a permitted or blocked set configured on the card.

The critical fact is who assigns that code: it is set through the merchant’s acquiring relationship, not by you and not by the card platform. A business is classified once, according to what it primarily sells, and that classification accompanies every transaction it processes — including ones that do not resemble its main line.

Where category control works well

• Blocking classes of spend clearly outside any employee’s remit, where a decline is unambiguously correct
• Permitting a narrow set of categories on a card issued for one obvious purpose
• Enforcing a policy line that is genuinely categorical rather than situational
• Reducing the blast radius of a compromised credential to one class of merchant

Where it is imprecise, and why

Classification is coarse. A single code can cover businesses that feel unrelated, and businesses that feel identical can carry different codes depending on how each was set up. A large retailer selling office supplies, electronics and groceries presents under one classification for all of it. A software company billing through a payment intermediary may present under the intermediary’s classification. Marketplaces are worse still, because the code describes the platform rather than what was bought on it.

The consequence is direct: category rules are a blunt instrument aimed at a fuzzy target. A rule written to prevent one behaviour will also block legitimate purchases sharing the classification, which the employee experiences as an unexplained decline in front of a supplier — while the behaviour you meant to prevent may present under a different code and pass straight through.

Three limits follow from this. A category rule cannot describe what was bought, only where; it cannot target one named merchant, only a class; and it explains nothing to the holder at the terminal. Where the requirement is really about one vendor, the correct instrument is a scoped credential rather than a rule — virtual cards explains vendor locking, and the virtual card guide covers the lifecycle.

Limits are the other genuinely preventive mechanism, and unlike category rules they are precise: the authorisation message contains an amount, and comparing an amount to a ceiling involves no ambiguity. That precision is why limits carry most of the preventive load in a well-designed program.

• Per transaction — bounds the size of any single purchase. Good at capping the largest possible single mistake; blind to many small purchases adding up.
• Per period — bounds cumulative spend in a window. Good at bounding total exposure on one card; blind to a single large purchase inside the window.
• Lifetime or total — bounds everything the card will ever authorise. The natural fit for single-purpose, project and contractor cards.
• Per category — bounds spend within one merchant classification, and inherits all the imprecision of classification described above.
• Per merchant scope — bounds where the credential works at all, which is how subscription and supplier cards are constrained.

Multiple scopes stack, and the tightest applicable one wins. A card can sit far below its monthly ceiling and still decline because one purchase exceeds the per-transaction cap — intended behaviour, and the most common source of confused support requests. Card limits covers evaluation order, pending holds and sizing.

Two philosophies exist for category permissions, and the choice has more practical consequence than almost any other control decision.

Match the philosophy to the instrument rather than to the company. Narrow-purpose cards get allow lists; broad-purpose employee cards get block lists. Applying an allow list across a general employee estate reliably generates an exception queue that consumes more finance time than the spending it governs, and teaches people the card is unreliable. See employee cards.

Approvals assign a decision to a named person. They do not, by themselves, prevent anything — which is why a program built primarily on approvals is slower than one built on limits, and no safer.

Route approvals to budget owners rather than up a management chain. The person accountable for a budget has the context to judge a request and an incentive to answer quickly; a senior manager two levels removed has neither and approves on trust, which is not a control. Budgets covers how that ownership is established.

Treat response time as a control parameter, not an administrative detail. An escalation route that takes two days is functionally a block, and people route around blocks — usually onto a personal card. Every hour of approval latency converts a share of your visible spend into invisible spend.

Evidence requirements are detective by construction: the receipt arrives after the purchase. Their value is interpretability — they make a posted transaction mean something to anyone who was not there.

1. Set exactly one threshold

   A single amount above which documentation is mandatory, applied regardless of seniority. Multiple thresholds create ambiguity, and ambiguity is negotiated by whoever is most senior.

2. Require capture on the day

   Evidence is easiest to obtain in the minutes after a purchase and hardest three weeks later. Same-day capture is most of the battle.

3. Ask for a memo only where it adds information

   Universal memo requirements train people to type "business expense" into every field.

4. Enforce systematically

   Missing documentation should trigger a consistent automated reminder and a defined consequence — not an individual chase from whoever noticed.

Evidence rules interlock with reconciliation rather than with authorisation. A transaction with no receipt is not blocked; it is unreconcilable, which surfaces as a stuck line at close rather than a decline at a terminal. Business expenses and expense automation cover what happens downstream.

Documentation requirements and tax treatment vary by jurisdiction and company. This page describes general practice, not a compliance standard.

Most spending authority is granted permanently because that is the default, not because permanence was intended. A conference card, a contractor engagement and a seasonal campaign all have natural end dates, and a control that expires on its own is worth more than one relying on someone remembering to remove it.

• Expiry as a control — a credential with an end date requires no cleanup and cannot become dormant standing authority.
• Total-spend ceilings — a lifetime cap means a project card closes itself once the work is funded, whatever the calendar says.
• Purpose recorded at issuance — a card with a written purpose can be reviewed by asking one question; a card without one requires an investigation, which is why nobody performs it.

The accumulated alternative is familiar: an estate of live cards issued for reasons that ended months ago, each individually harmless and collectively a meaningful amount of unowned spending authority. Employee spending treats that drift as the central long-run risk in card administration.

Policies and controls diverge because the policy was written in a register that cannot be configured. "Spend company money as if it were your own" is a sentiment; "travel bookings above a defined threshold require budget-owner approval" is a specification. Write each line as a triple — the condition, the mechanism and the moment. If you cannot fill in all three, it belongs in the culture section of the handbook rather than in the policy that drives configuration.

Publish the resulting rules to the people they apply to. An unexplained decline is experienced as a system failure; an explained one is experienced as policy working. The spending controls guide works through the drafting process end to end, and the corporate card guide places it inside overall program design.

Control frameworks fail in two opposite directions. Neither is a discipline problem; both are design problems that produce behaviour people then mistake for indiscipline.

The over-tight failure is the more expensive and the less obvious, because it produces no alerts. Spending that has migrated to personal cards is invisible to every dashboard you own: it arrives weeks later as a reimbursement claim with worse evidence and worse timing, and it disproportionately burdens junior staff who cannot comfortably float the cost. A program that has quietly recreated the reimbursement problem it was bought to solve will still report excellent compliance.

The over-loose failure is easier to spot and harder to admit, because the framework exists and someone built it. The diagnostic question is simple: in the last quarter, did any control actually change an outcome? If no limit ever bound and no rule ever declined, the controls are documentation rather than governance.

Controls decay. Roles, vendors and spending patterns change, and a rule set that fitted the company two years ago fits an organisation that no longer exists. Tuning is a scheduled activity, not an incident response.

The most valuable input is the decline log, which almost no company reads. Every declined authorisation is evidence about the fit between your rules and your operations: a cluster of legitimate declines in one category means a miscalibrated rule, and a total absence of declines means nothing binds. Change one thing at a time, or the resulting complaints cannot be attributed.

• Review declines quarterly and classify each as correct, miscalibrated or a communication failure
• Retire block-list entries for categories that no longer describe anything relevant
• Confirm every card still has a purpose that exists and an owner who is still employed
• Measure approval latency, and treat a slow route as a broken control rather than a busy approver
• Record what changed and why, so the next review starts from a known position

For adjacent topics: budgets covers aggregate ceilings and ownership, card limits covers preventive mechanics in depth, employee spending covers the behavioural side, and corporate card vs credit card explains why card structure changes which controls exist at all.