Fuel card spend controls that actually work

Fuel card controls only work when they are set from your own operating data. Provider defaults are deliberately loose, because a card that declines legitimate transactions generates support calls. The result is that most fleets run controls calibrated for the provider's convenience rather than the operation's risk.

Controls also cannot do the whole job. They prevent transactions that break a rule. They cannot detect a transaction that follows every rule and still puts fuel in the wrong vehicle. Controls and detection are complements, and a programme with only one of them has a predictable gap.

Controls worth setting, and how to set them

Product restriction. Lock each card to the fuel types the vehicle can physically take, plus AdBlue where relevant. Exclude shop goods entirely unless there is a documented business reason. This is the highest value, lowest friction control available and it is frequently left open.

Single transaction volume cap. Set at tank capacity plus roughly 10 percent, per vehicle. Fleet wide caps are wrong for every vehicle: too loose for the vans, too tight for the tractor units.

Transactions per day. Most vehicles need one, some need two. A cap of two catches container filling while leaving genuine long distance days intact. Set it per vehicle class, not fleet wide.

Time and day windows. Only where the operation genuinely does not run. If you run six days, do not set a five day window and then spend your week authorising exceptions. An exception process that runs constantly is a control that has already failed.

Site or network restriction. Useful where routes are stable and the network is dense enough. Counterproductive for ad hoc or long distance work, where it pushes drivers to pay personally and claim, which is worse for both cost and visibility.

PIN plus odometer prompt. Keep both. The PIN limits casual card sharing. The odometer prompt is often dismissed as unreliable, but its real value is not accuracy: it is that comparing the entered figure to the telematics odometer identifies deliberate misreporting.

Controls that mostly create friction

• Monthly spend caps per card. Fuel price moves, so a monetary cap that was right in January declines legitimate fills in June. Cap volume, not value.
• Hard geofencing on long distance work. Generates declines at the worst possible moment and drives spend off card.
• Requiring pre-authorisation per fill. The admin cost exceeds any plausible saving outside very small fleets.

Per driver versus per vehicle

Assign the card to the vehicle where you can, because vehicle attributes are what make a control testable: tank capacity, fuel type, and expected consumption are properties of the asset, not the person. Driver cards are appropriate for pool arrangements and grey fleet, but accept that they weaken every capacity based control, since the system no longer knows what it is filling.

Where driver cards are unavoidable, compensate with tighter product restriction and per day transaction caps, and rely more heavily on detection.

Reviewing controls

Review quarterly against two lists: transactions that were declined, and exceptions that were authorised. A long decline list means controls are too tight and you are creating workarounds. A long authorisation list means the controls exist on paper only. Both are actionable, and neither shows up in spend reporting.

Setting Controls From Your Own Data With Fleevo

Fleevo holds tank capacity, fuel type and consumption history per vehicle, so it can tell you what each card's limits should be rather than leaving you to guess, and it flags the transactions that pass your controls but fail against vehicle activity. That is the gap controls alone cannot close. To review your current limits against your operating data, contact Fleevo or book a demo. See also fuel and EV charge management, the fuel fraud patterns we see most often, how to write a fuel card policy, and cutting fuel card costs and misuse.

Fuel Card Control FAQs

What per driver spend controls should a fleet operations lead configure?

Product restriction matched to the vehicle, volume cap at tank capacity plus a small margin, a per day transaction cap, PIN and odometer prompts, and time windows only where the operation genuinely does not run. Set volume rather than value limits so fuel price movement does not break them.

Do real time spend controls reduce payment leakage?

They reduce the leakage that involves breaking a rule: wrong product, excessive volume, out of hours use. They do not address transactions that comply with every control while still diverting fuel, which is why detection has to sit alongside them.

Should fuel cards be assigned to drivers or vehicles?

Vehicles, wherever the operation allows it, because tank capacity and fuel type are what make volume and product controls meaningful. Driver cards are a reasonable answer for pool and grey fleet, at the cost of weaker automated checking.

How often should fuel card limits be reviewed?

Quarterly, against the decline log and the exception authorisation log. Reviewing spend totals tells you nothing about whether the controls are correctly calibrated.

Why cap volume rather than spend?

Because fuel price moves. A monetary cap set at one price level starts declining legitimate fills as prices rise, while a volume cap tied to tank capacity stays correct.