The default way most Indian businesses handle team spending is reimbursement: the employee pays, keeps the receipt, submits a claim, and waits. It works, in the sense that the money eventually reaches the right place. It also pushes the cost onto the person with the least capacity to absorb it and concentrates all the administrative work at month end.
What reimbursement actually costs
- Employees fund company spending from personal accounts, sometimes for weeks.
- Finance discovers what was spent after it was spent, which makes budget control retrospective.
- Receipts are collected at the end, when the context for an unusual line has faded.
- Policy is enforced by rejecting claims — the most adversarial possible point of control.
- The junior staff least able to carry the float are often the ones travelling most.
The hidden cost nobody measures
The obvious costs are the float and the admin. The one that rarely appears in a business case is the spending that does not happen: a salesperson who skips a client dinner, or an engineer who does not buy the tool that would have saved a day, because they do not want to carry it personally and argue about it later.
That is impossible to quantify and entirely real. It is also the reason the conversation about expense cards should not be framed purely as a control project — the point is as much about removing friction from spending that should happen as about preventing spending that should not.
What a card changes
An expense card moves the control forward: limits and categories are set before the transaction, so spending outside policy does not happen rather than being disputed later.
- Company funds are used directly, so nobody is out of pocket.
- Spend is visible as it happens rather than at the end of the month.
- Limits are enforced by the card rather than by a reviewer.
- The receipt can be captured at the moment of purchase, when the context is still fresh.
- A declined transaction is a clear, immediate answer rather than a rejected claim three weeks later.
Setting limits that work
A single company-wide limit is either too tight for the people who need to spend or too loose for everyone else. Useful configurations vary along a few independent axes.
| Control | Example | Stops |
|---|---|---|
| Per-transaction cap | ₹10,000 per purchase | Large unplanned purchases on a routine card |
| Periodic cap | Monthly budget per holder | Drift, where many small items add up unnoticed |
| Category restriction | Fuel and travel only | Spending outside the card's purpose |
| Merchant restriction | A named supplier | Useful for cards issued for one recurring arrangement |
| Time window | Active during a project | Dormant cards retaining live limits |
| Geography | Domestic only unless travelling | A common first signal of a compromised card |
The combination matters more than any single setting. A fuel card with a category restriction and a monthly cap is tightly controlled without anybody needing to approve each fill.
Worked examples
- Field salesTravel and dining categories, a moderate per-transaction cap, a monthly cap matched to the territory, geography limited to the region they cover.
- Fleet fuelFuel category only, a per-transaction cap set just above a full tank, a monthly cap from the route plan. No approval needed for any ordinary fill.
- Software and subscriptionsOnline category, a tight per-transaction cap, a specific merchant list, and a named holder in engineering rather than a shared card.
- Project or eventA time window matching the project, a total cap rather than a monthly one, and automatic deactivation at the end date.
Note what none of these need: an approval step for routine spending. The limits do the work, and attention is reserved for the exceptions.
Receipts, and why timing decides everything
Receipt capture is where expense programmes quietly fail. The transaction data tells you an amount and a merchant; it does not tell you what the spending was for, which is what an auditor and a budget holder both need.
- Prompt at the transaction, not at month end. A notification while the person is still at the counter gets a photo; a reminder three weeks later gets an estimate.
- Accept a photograph rather than demanding a formatted upload. The friction of a process is what produces the backlog.
- Match automatically where you can — amount, merchant and time are usually enough to attach a receipt to a transaction without anyone selecting from a list.
- Set a threshold below which a receipt is not required, and be honest about it. Chasing a ₹40 receipt costs more than the ₹40.
- Escalate on the exceptions rather than the volume: a missing receipt on a large or unusual transaction matters; one on a routine small purchase mostly does not.
Where cards fit, and where they do not
Cards suit recurring, categorisable, moderate-value spending by a known holder. They are a poor fit for large one-off purchases that should go through procurement, and they do not remove the need for a policy — they enforce one you have already written.
- Write the policy firstCard limits encode a policy. If it has not been decided, the limits will encode whatever seemed reasonable on the day.
- Issue narrowly, then widenStart with the roles that spend regularly. Extending access later is easy; reclaiming it is not.
- Capture receipts at the point of spendA prompt at the transaction gets a photo. A reminder three weeks later gets an estimate.
- Review the outliers, not every lineAttention belongs on declines, unusual categories and anything near a cap — not on a list of ordinary purchases.
- Close the loop on leaversCard deactivation belongs in the offboarding checklist alongside system access. It is a step that gets missed precisely because it sits with finance rather than IT.
The approval thinking here is the same as for payment initiation in connected banking: decide the controls while the system is new, because tightening them later is a conversation nobody wants to have.
Getting the accounting right
Cards change where expense data enters the books. Done well the transaction arrives already coded and the month-end work largely disappears; done carelessly you have swapped a claims backlog for an uncategorised-transaction backlog.
- Map categories to your chart of accounts up frontThe card scheme's merchant categories are not your expense codes. Decide the mapping once, in finance, rather than letting each cardholder guess.
- Default the coding, then allow correctionA fuel transaction on a fuel card codes itself. Ask the cardholder only where the default is genuinely ambiguous, which is a small minority of lines.
- Attach the receipt to the transaction, not to a claimThe transaction is the record. A claim form wrapping it is the thing you were trying to remove.
- Reconcile the card account dailyCard transactions settle on their own schedule, and a pending authorisation is not a posted transaction. Treat it the same way you would any other reconciliation.
- Close the period on exceptions onlyIf closing requires reviewing every line, the programme has not saved anybody time. It should require reviewing the uncoded and the unreceipted.
Fraud, misuse and the difference between them
Two different problems get discussed as one. External fraud is somebody else using the card. Internal misuse is the cardholder spending outside policy. They need different controls, and conflating them produces a programme that treats employees as suspects while leaving the actual risk open.
| External fraud | Internal misuse | |
|---|---|---|
| Who | A third party with the card details | The legitimate cardholder |
| Looks like | Unusual geography, merchant, hour | Ordinary merchants, borderline categories |
| Best control | Geography and category limits, instant freeze | Clear policy, visible spend, periodic review |
| Detected by | Automated rules, usually within minutes | A person looking at a pattern over weeks |
| Response | Freeze, dispute, reissue | A conversation, not a system change |
The practical implication is that automated controls should be tuned for the first column, where they genuinely work, and the second should be handled by making spending visible rather than by tightening limits until the card stops being useful.
- Give every cardholder a view of their own spend. Most borderline spending stops when the person knows it is visible.
- Review outliers monthly, not every line — a card near its cap, an unusual category, a run of round-sum transactions.
- Make the freeze control instant and available to the cardholder themselves. A lost card at nine in the evening should not wait for finance.
- Keep a written policy people have actually read, because 'outside policy' is only meaningful if the policy was communicated.
Frequently asked questions
Do expense cards replace an expense policy?
No — they enforce one. The limits and categories you configure are the policy expressed in a form the card can apply, so the policy has to exist first.
What limits should a new card start with?
Tighter than you think, and combined rather than single: a per-transaction cap plus a periodic cap plus a category restriction. Raising a limit on request is a short conversation; recovering money spent outside policy is not.
How do receipts get collected?
At the point of spend. A prompt tied to the transaction, while the person is still at the counter, produces far better capture than a month-end reminder — and it is the single highest-leverage change in most expense programmes.
Should every transaction need a receipt?
Set a threshold and be honest about it. Chasing a ₹40 receipt costs more than the ₹40. Escalate on large or unusual transactions instead of on volume.
Are cards suitable for all business spending?
No. They suit recurring, categorisable, moderate-value purchases. Large or strategic purchases still belong in a procurement process with proper approval.
What is the most commonly missed step?
Deactivating cards when someone leaves. It belongs in the offboarding checklist, and it gets missed because it sits with finance rather than with IT.
