Company cards and policy: controlling spend at the point of payment

Most expense policy is enforced after the fact. Someone spends, someone claims, and an approver decides whether it should have happened. By that point the money has gone. The only questions left are whether to reimburse and how awkward the conversation is going to be.

It is worth being clear about what that is. Reviewing spend after it happens is reporting. It is useful, and you should do it. But it is not control, and treating it as though it were is how organisations end up with a policy everyone has read, an approval workflow everyone follows, and a spend profile nobody is happy with.

Where the control actually sits

The moment of payment is the only point where a rule can genuinely prevent something. Everything after it is remediation. Smart company cards move the rules to that moment: a card can be restricted by merchant category, by transaction value, by daily or monthly limit, by currency, and in some programmes by date range for a specific trip or project.

A card issued to a project team can be set to work with airlines, hotels and rail operators and nowhere else. A card issued for a single conference can be capped and expire when the conference does. The employee does not have to remember the policy, and the approver does not have to enforce it, because the transaction that breaks it does not complete.

This changes the character of the conversation between finance and the business. Instead of declining claims after the event – which is unpleasant for everyone and rarely changes behaviour – the constraint is visible at the moment it applies.

Why the card alone is not enough

A card programme that does not reach your expense system creates a different problem. Transactions land on a statement, someone reconciles them by hand, and receipts arrive by email or not at all. You have replaced an approval problem with a matching problem.

The value comes from the pairing. The card enforces the rule; SAP Concur receives the transaction, matches it to a receipt, applies the accounting treatment and carries it through to the ledger. Concur is where the policy is defined, where the cost centre and tax treatment are decided, and where the audit trail lives. The card is where the policy is applied.

Set up properly, an employee taps a card, the transaction appears in their Concur expense list with the merchant and amount already populated, they attach a receipt from their phone, and the claim is largely complete before they have thought about it. The finance team sees committed spend within a day or two rather than at month end when the claims arrive.

What to settle before you start

• Feed quality, not just feed existence. A card feed that arrives without merchant detail or in an inconsistent format will not match cleanly, and unmatched transactions are worse than no automation at all.
• Who sets the limits, and how quickly they can change. If raising a limit takes three days and an email chain, people will find another way to pay and you are back to claims.
• What happens to personal spend. It will occur. Decide how it is identified and recovered before it does, rather than inventing a process the first time.
• Whether cards replace claims or sit alongside them. Most organisations run both. Both routes need to reach the same policy and the same accounting treatment, or you have two standards.

The point

Policy that is enforced when the money moves is a control. Policy that is checked when the claim arrives is a report. Both have a place, but they are not the same thing, and a great deal of frustration in expense management comes from expecting the second to do the job of the first.