Information only. This site is a reference project. We do not provide account access, financial services, card applications, payments, credit decisions or official support, and we never ask for account or financial credentials.
Policy comes before configuration
A spending control is a written rule about company money, expressed in a form a machine can evaluate. If the rule was never written, the configuration is a guess.
This sounds pedantic and it is the difference between a program people accept and one they route around. When a card declines and the cardholder asks why, there are two possible answers. "Because policy says purchases of this kind need approval, and here is how to get it" is a control. "I don’t know, someone set that up" is friction with no legitimacy, and it will be dismantled at the first inconvenience.
So the first artefact is not a settings screen. It is one page of plain language: what people may buy without asking, what needs approval, what needs documentation, and who decides exceptions. The employee spending page covers how that page is communicated; this guide covers what happens once it exists.
How Corporate Spending Controls Work
Controls act at different moments, and the vocabulary is used so loosely that people frequently believe they have prevention when they have only a record. Being precise about timing is the single most useful thing in this subject.
| Control | Acts | Prevents spend? |
|---|---|---|
| Per-transaction limit | During authorisation | Yes — the transaction is declined |
| Per-period limit | During authorisation | Yes, once the period total is reached |
| Merchant category rule | During authorisation | Yes, for categories not permitted |
| Merchant lock | During authorisation | Yes, for any other merchant |
| Budget ceiling | Continuously, across a card group | Sometimes — depends whether it is enforcing or reporting |
| Pre-approval workflow | Before the purchase | Only if the person waits for the answer |
| Receipt requirement | After the transaction | No — it produces evidence |
| Policy flag or review queue | After the transaction | No — it produces a conversation |
A structural framework used across this site. Which of these exist, and what they are named, varies by provider.
Read that table once and the most common design flaw becomes obvious. A control framework built entirely from approvals, receipts and review queues is retrospective: by the time it acts, the money has moved. It may still be valuable — evidence and accountability matter — but it is not prevention, and calling it prevention leads companies to believe they are covered when they are not.
The authorisation-time controls are the ones with teeth, and they are also the ones with a cost: every one of them can decline a legitimate purchase at an inconvenient moment. That trade-off is the real subject of control design. The spending controls and card limits pages cover the mechanics in more depth than a guide should, and the corporate card guide covers the program these rules attach to.
Designing a control set from scratch
Starting from a blank configuration is easier than starting from someone else’s template, because a template imports assumptions about a company you do not run. This sequence produces a defensible set in an afternoon.
-
Name the three things you actually fear
Usually: a compromised card, a purchase nobody authorised, and quiet recurring spend nobody owns. Three is enough to start.
-
Assign each fear to an authorisation-time control
Compromise maps to per-transaction ceilings. Unauthorised purchases map to category rules. Quiet recurring spend maps to merchant-locked virtual cards.
-
Set ceilings from observed behaviour
Use the normal, not the maximum. A ceiling set at the historical peak is not a control.
-
Add documentation thresholds last
Decide the level above which a receipt is mandatory, and apply it identically to every instrument type.
-
Write the exception route before you need it
Who to ask, expected response time, and whether the increase is temporary. Undocumented exception routes become permanent increases.
-
Publish the whole thing to cardholders
A control nobody knows about is experienced as a malfunction.
Notice that budgets and approvals appear nowhere in the first pass. They are excellent tools for accountability and forecasting — see budgets — but they do not answer the three fears, and adding them early creates the illusion that the fears have been handled.
How Finance Teams Control Spending
From a finance team’s perspective, controls are not a security feature. They are a data quality mechanism. A well-controlled program produces transactions that arrive pre-attributed, pre-categorised and documented, which is the difference between a close that takes days and one that takes weeks.
That reframing changes what a finance team optimises for. The goal is not the tightest possible ruleset; it is the smallest ruleset that makes the incoming data self-describing. Every control that improves attribution pays for itself monthly. Every control that only creates friction costs goodwill and buys nothing.
Relative spend by period — shape only, no real figures.
Prevention at the edge
Authorisation-time rules so that out-of-policy spend mostly does not happen, rather than being caught later.
Attribution by construction
Purpose-scoped and person-scoped cards — see the virtual card guide — so the instrument answers "what was this for".
Exception handling with a clock
A defined route and response time, so people do not treat the policy as a suggestion.
Evidence for audit
Consistent documentation thresholds, so the evidence trail does not depend on who was diligent.
The organisational half of this — who owns limits, who signs off, how it scales as headcount grows — is covered on finance teams, and the downstream reconciliation work is the subject of the corporate finance guide.
When controls misfire
Every control set is wrong on the first pass, because it was built from assumptions rather than observations. The useful skill is diagnosing which layer misfired and adjusting deliberately rather than loosening everything.
| Symptom | Likely cause | Adjustment |
|---|---|---|
| Frequent declines on routine purchases | Per-period ceiling set below normal behaviour | Raise that ceiling; leave per-transaction alone |
| Employees paying personally and claiming back | Cards too few, or issuance too slow | Issue more narrow cards rather than raising limits |
| A stream of exception requests from one role | Category rules copied from a different role | Build a role-specific template |
| Failed subscription renewals | Vendor price rose past a recurring ceiling | Review and re-set the ceiling deliberately |
| Nobody can say who owns a charge | General-purpose card doing a purpose-scoped job | Split into merchant-locked cards, or issue employee cards |
| Controls quietly disabled over time | No written policy behind them | Return to the one-page policy first |
Diagnostic patterns described structurally. They are not claims about any specific product or company.
The last row is the important one. Controls without a stated purpose get removed under pressure, and the pressure always arrives. A control that can be defended in one sentence survives; one that cannot, will not. The expense controls page covers the equivalent problem on the documentation side.
This site is an independent reference project. It configures nothing, holds no accounts and provides no financial services — the frameworks here are editorial, not operational advice about a specific product.
FAQ
Frequently asked questions
What is the difference between a control that prevents and one that records?
Timing. Limits, merchant locks and category rules are evaluated during authorisation, so an out-of-policy transaction does not complete. Receipt requirements, review queues and most approval flows act before or after the fact and produce evidence or accountability rather than prevention. Both are useful; conflating them is how companies end up over-confident.
Are tight controls bad for morale?
Unexplained controls are. What people resent is not being constrained, it is being made to fund work expenses personally, or being declined with no reason and no route to a fix. A published policy, realistic ceilings and a documented exception path remove almost all of that friction.
Should approvals happen before or after the purchase?
Pre-approval only prevents spend if the person waits for the answer, which makes response time part of the control. Post-transaction review never prevents anything but is cheap and catches patterns. Many programs use pre-approval for a small number of high-consequence categories and review for everything else.
How often should limits and rules be reviewed?
On a fixed cadence rather than when something breaks, because the drift is one-directional: exceptions get granted and rarely revoked. A recurring review of dormant cards, unused limits and role changes is the cheapest control in the whole set.
Do budgets count as spending controls?
They act at the group level and their enforcement varies — some track and report, some genuinely cap. Treat a budget as accountability and visibility unless you have confirmed it blocks authorisations. See budgets for the distinction.
Can you tell me what limits my company should set?
No, and any source that offers a number without knowing your business is guessing. The right ceiling depends on your spending patterns, cash position and roles. What generalises is the method: observe normal behaviour, set near it, publish it, and review after a full cycle.
Sources and reference basis
- Reference General payment-network reference material on authorisation checks and merchant category classification.
- Practice Commonly documented control configurations in corporate card administration: layered ceilings, category permissions and merchant locking.
- Framework Standard internal-control literature on preventive versus detective controls and delegated authority.
- Method Our methodology explains how these guides are researched and our fact-checking policy how claims are verified and corrected.