Corporate Cards: The Controls That Replace an Approval Step

Company cards are not inherently uncontrolled. They are uncontrolled in most companies this size for a specific and boring reason: issuing a card removes the approval that used to sit in front of the spend, and nothing was built to replace it. The trade itself is fine. You give up prevention and you buy speed, and for a company where three people need to buy things on a Thursday afternoon, speed is worth having.

The failure is taking the trade and not paying for it. Every preventive control you gave up has a detective equivalent, they are cheap, and almost none of them are in place in the companies where I first see a card statement.

There is a second reason, and it is worth saying rather than implying. The person best placed to build these controls is usually the person holding the largest card and the least reviewed one. That is not an accusation. It is just the reason this particular gap survives longer than the others.

What you gave up, and what replaces it

The preventive control a card removes	What has to replace it
Approval of the commitment before the money moves	The limit, set at issuance, which is the only prevention left
An invoice describing what was bought	The itemised receipt, captured by the cardholder at the time
Coding by somebody looking at a document	Coding by the cardholder, at the transaction, while they remember
Segregation between the person spending and the person recording	Review of the statement by somebody who does not hold a card
The payment run’s check on who is being paid	A first-appearance merchant flag on the monthly review

Read the last row twice. A card is a channel to a payee who was never onboarded, never verified and never entered on the vendor list. Everything in the vendor onboarding file is bypassed by a card, permanently and by design, and no amount of statement reconciliation puts it back. Which is why the merchant flag on the monthly review exists, and why pulling the cards is the wrong response to noticing.

The control matrix

Control area	The control	Performed by	Evidence	Cadence
Issuance	A card is issued against a stated need: what will be bought on it and why the purchase route does not fit. Approved by the owner or finance lead, not by the requester’s manager.	Owner or finance lead	The issuance request and approval, filed	Per card
Cardholder agreement	One page, signed before the card is handed over: the limit, the receipt deadline, the coding obligation, the prohibited categories, the escalation ladder	Cardholder signs, finance files	Signed agreement	Per card, re-signed on any limit change
Per-transaction limit	Set at the largest single purchase the cardholder genuinely needs to make, not at a round number that feels appropriate to their seniority	Finance lead	The limit schedule	Set at issuance, reviewed annually
Monthly limit	Set against the category the card exists for, with headroom for one unusual month and no more	Finance lead	The limit schedule	Set at issuance, reviewed annually
Category and merchant restrictions	Block the categories the card has no business in. Most issuers support this and most companies never turn it on.	Finance lead	The restriction settings, exported	Set at issuance, checked annually
Limit changes	Requested in writing, approved by the person who approved issuance, permanent or temporary stated explicitly, temporary ones reversed on a date	Owner or finance lead	The request and the reversal confirmation	Per change
Coding at source	The cardholder assigns the account and the dimension at the time of the transaction, not from the statement at month end	Cardholder	The coded transaction	Per transaction
Receipt capture	Itemised receipt attached by the cardholder, at the transaction or the same day	Cardholder	The attached image	Per transaction
Receipt deadline	A stated number of days after the statement period closes, ahead of the close cut-off	Finance	The outstanding receipts report	Monthly
Statement reconciliation	Every line agreed to a coded, receipted transaction. Unmatched lines listed with an owner.	Preparer	The reconciliation, filed with the close	Monthly
Review	A non-cardholder reads the full month for at least one card, and the exception report for all of them	Finance lead or reviewer	The review note, signed	Monthly
First-appearance merchants	A list of merchants that did not appear in the prior twelve months, read by the reviewer	Reviewer	The list, with any queries noted	Monthly
The owner’s card	Reviewed by a named second person, on the same basis as everyone else	Finance lead, or the board where there is one	The review note	Monthly
Departure and role change	Card cancelled with the issuer on the last working day, and any stored copy in a phone wallet accounted for	Finance, on the offboarding checklist	Cancellation confirmation from the issuer	Per event
Loss or compromise	Reported to the issuer immediately, and the transactions since the last clean statement reviewed line by line before the replacement is activated	Cardholder, then finance	The incident note	Per event
Programme review	The whole card list read once a year: who holds one, whether they still need it, whether the limits still fit	Owner and finance lead	The reviewed list	Annually

The two controls that carry most of the weight

Everything in that matrix is worth doing. Two of the rows are worth more than the rest put together, and if a company is going to implement three things, these are two of them.

Coding at source. The default in most companies is that the bookkeeper codes card transactions at month end from a statement. That statement is a list of merchant names and amounts. The person coding it was not there, does not know what was bought, and is producing a ledger by inference. This is where the catch-all expense account comes from, and it is why card spend is so often unanalysable: not because it was hidden, but because it was coded by somebody guessing in good faith three weeks later.

Move the coding to the cardholder, at the transaction. It takes them fifteen seconds and they are the only person in the company who actually knows the answer.

Review by a non-cardholder. The reviewer must not hold a card, because a reviewer with a card is reviewing a process they are subject to, and everybody involved knows it. In a small company that usually means the reviewer is the finance lead, an office manager who does not hold a card, or whoever runs the control set from outside. What they read is the full month for one card, rotating, plus the exception reports for all of them. Reading one card properly finds more than skimming six.

The receipt deadline and the ladder

Set the deadline in days after the statement period closes, and set it before the close cut-off, so an outstanding receipt is a problem for the cardholder rather than for the close. That sequencing is the whole design. A deadline that falls after the close makes missing receipts the preparer’s problem, and the preparer has no way to insist.

Then the ladder, which lives in the cardholder agreement so nobody is surprised by it.

1. At the deadline: an automated reminder listing the specific transactions. Not a general note to everyone. The list, with dates and merchants.
2. Three days later: the cardholder’s manager is copied. This step does most of the work and it costs nothing.
3. At the next statement, if the earlier items are still outstanding: the card is suspended. Not cancelled. Suspended, until the receipts are provided. Suspension is reversible, immediate, and it does not require a conversation about somebody’s character.
4. Repeated suspension: the card is withdrawn, and the person goes back to raising purchases through the normal route.

Two boundaries on that ladder. Do not build a step that touches somebody’s pay: recovering an unsupported expense from wages is an employment law question, it varies, and it is not something to design into a control document without advice. And do not write a step you will not perform. A ladder that has never reached step three is a ladder everybody has correctly identified as decorative.

The one exception worth writing in: a transaction with no receipt is still a transaction, and it gets coded and recorded on time regardless. The close does not wait for documentation. The consequence lands on the cardholder, not on the ledger.

Limits, and how to set them without a benchmark

There is no correct limit and no figure worth copying from another company. Two questions set it.

What is the largest single thing this person legitimately buys on this card? Set the per-transaction limit near that, not above it. A limit set with generous headroom is not a control, and headroom is exactly what people ask for when they are asked what limit they want.

What does the category this card exists for cost in a normal month? Set the monthly limit at that, plus one unusual month’s worth of room. If the card is genuinely for travel, the limit is a travel limit, and a request to raise it for something else is a signal that the card is being used outside its stated purpose, which is information you want.

Then treat temporary increases as temporary. Approved in writing, with a reversal date, and reversed on that date by somebody whose job it is. Temporary increases that were never reversed are the most common finding in an annual programme review, and they are usually years old.

Three numbers to watch monthly

Not a scorecard. Three counts, on the close file, taking about ten minutes to produce.

Receipts outstanding past the deadline, by cardholder. A rising number in one person is a conversation. A rising number across everybody is a deadline that does not fit the way the company works, and the deadline should move rather than the people.

Transactions coded to a catch-all account. This number should be close to nothing once coding at source is in place. If it is not, coding at source is not actually happening and the ledger is being produced by the month-end guess described above.

First-appearance merchants. Count them and read them. Most will be ordinary. The value is that somebody looked, and the month where it matters looks exactly like the eleven months where it does not.

What a card programme is not

It is not a substitute for purchase order coverage. If a category exists on a card because raising a purchase order for it is slow, the problem is the purchase order design and the card is the workaround. Workarounds are diagnostic. When a card is issued to route around a process, the honest fix is to change the process and the dishonest one is to issue the card and stop talking about it.

It is not a way to pay suppliers. A card used to pay recurring supplier invoices moves spend out of accounts payable, out of the payment run, out of the approval grid and out of the aging, all at once. Recurring suppliers belong on the vendor list with terms, not on somebody’s card because it was faster the first time.

And it is not a personal risk to the cardholder that the company should ignore. The cardholder agreement should say plainly what happens to the card when they leave, that the company will cancel it on their last day, and that a copy stored in a personal phone wallet is covered by the same cancellation. People generally have no idea that the wallet copy exists separately in their mind from the plastic they handed back.

The programme review nobody runs

Once a year, read the card list with the owner. Three questions per card: does this person still need one, is the limit still the right size, and has the stated purpose from the issuance request drifted.

Expect to withdraw one or two. That is the point of the review, and the reason it feels awkward is that a card is read as a marker of trust rather than as a tool with a stated purpose. Which is precisely why the issuance request states the purpose in writing on day one. Withdrawing a card from someone whose role changed is a straightforward administrative act when there is a written purpose to point at, and an uncomfortable personal conversation when there is not.