Every company that has outgrown two cards has the same artefact: a spreadsheet with a row per cardholder, a monthly cap, and a column nobody has updated since March. It is not a control. It is a record of what somebody once intended.
The limit is not the problem
Most teams set caps that are roughly right. What goes wrong is that the cap and the card are two different objects, kept in sync by attention. The card does not know what the spreadsheet says, so the spreadsheet is only consulted after the money has moved — which is to say, during the close, which is the most expensive hour of the month to discover anything.
What “in policy” actually means
A policy that lives on the card is four decisions made once, at issue:
- Which merchant categories the card works in at all.
- The per-transaction ceiling, which is the one that catches mistakes.
- The monthly ceiling, which is the one that catches drift.
- The account and cost centre the spend posts to.
The fourth is the one people leave out, and it is the one that pays for the other three. A card that knows its account produces a transaction that arrives already coded — see what a three-day close actually requires for what that is worth downstream.
The objection, and the answer
The objection is always the same: rules this tight will block someone mid-quarter and I will spend my week granting exceptions. In practice the opposite happens, because a request to raise a cap is a thirty-second decision with the context attached, while a surprise in the close is a forty-minute reconstruction without it.
Set the caps slightly generous for a month and read the distribution before you tighten them. You are not trying to catch fraud. You are trying to make the ordinary case need no attention at all.
Where to start
Take the ten cards with the most transactions, not the largest ones. High-frequency cards are where miscoding compounds, and they are the ones whose owners will tell you within a week whether the policy is wrong.
