Home · Solutions · Finance & accounting · Fleet cards reconciled, anomalies visible at once
Solution · Finance & accountingA fill-up 300 km off route stops waiting for month-end for someone to notice
Fleet cards reconciled, anomalies visible at once
Every day a robot consolidates card transactions from all sources, matches them to vehicles, drivers and routes, assembles the sets for consolidated invoices, and raises pattern-breaking transactions to people for a decision the same day.
Executive summary
Card transactions arrive from several sources in different formats, and settlement means matching thousands of lines to vehicles and limits. Abuse surfaces in a customer complaint, or never.
Consolidation, assignment and rule checks happen daily. Consolidated invoicing receives ready sets, not raw files.
A transaction that breaks the pattern, location, frequency, volume above tank size, is a case the same day, with a human decision: block, ask the driver, accept.
card operators’ files and APIs; the vehicle and limit register; telematics where present; cases and invoicing in the ERP and Microsoft Teams
Business problem
Thousands of lines, zero questions
Fuel cards simplify a driver’s life and complicate finance’s. Transactions arrive from an own card system and from external operators, every source in its own format and rhythm. Before a consolidated invoice or a fleet settlement can exist, someone must glue those streams together, assign them to vehicles and drivers, and resolve the lines that match nothing.
At tens of thousands of lines a month, real control turns statistical: what gets checked is what screams by itself. A fill-up off route, two fill-ups an hour apart, a volume larger than the tank, a card used on a vehicle’s idle day, all of these are patterns visible in data, but only when someone looks daily rather than at month-end close.
The monthly rhythm has one more flaw: disputes. A fleet customer questions a line on a consolidated invoice three weeks after the event, when the driver no longer remembers and the telematics record has to be dug out. Every dispute costs more than the disputed amount, so it is more often conceded than explained.
As a result nobody can say what abuse and errors cost, because the system is designed not to see them. What is visible is the invoice total, and a total asks no questions.
How it works today
Below is what the work looks like before anything is automated.
- PersonSomeone downloads transaction files from operators and the own system, each in a different format
- PersonLines are glued in a spreadsheet and assigned to vehicles from a register that is not always current
- Risk of errorControl covers the lines that catch the eye; time and route patterns slip through
- WaitingConsolidated invoicing waits for the full set, and the set waits for the last file
- Risk of errorA customer dispute arrives weeks after the event, when the evidence must be reconstructed
- Risk of errorA lost or abused card keeps working until cycle end, because nobody looks in between
Why the current process costs more than it appears
The bill that never shows up in a budget.
- Undetected abuse appears nowhere: the cost is real but dissolved into the “fuel” line, so formally it does not exist.
- Disputes settled by concession because explaining costs more than the amount; at scale that is a systematic rebate nobody approved.
- Hours of file-gluing and line-assigning every month, at the worst moment: at close.
- Card limits and rules set years ago and never reviewed, because nobody has the data to improve them.
Cost of inaction
The middle row is by nature an estimate: the value of abuse is seen only after controls exist, and that is precisely the problem. 0.4% is a cautious model value for a fleet without daily rule checks; industry ranges run wider in both directions.
An honest caveat: some anomalies turn out innocent. An off-route fill-up may be a detour, a double fill-up a pump fault. That is why a rule’s output is a question to a person, not a verdict; the value is that the question is asked the same day.
A model organisation with realistic proportions – the numbers exist so you can run the same maths on your own data; they are not a client result.
A fleet card operator attached to a station network, also serving customer fleets: an own card system, third-party transactions from two operators, SAP for invoicing, telematics at some fleet customers, Microsoft 365.
38,000 transactions a month, 4,200 active cards, consolidated invoices for 130 fleet customers in three cycles.
Consolidation in spreadsheets, manual assignments when the register drifts, sampled control, disputes handled by email with history reconstructed backwards.
Three people lose most of the month to gluing and assigning; anomalies surface from customers, not from own control; nobody knows the cost of abuse.
The robot pulls transactions from all sources daily, normalises them, assigns to vehicles and drivers, checks the rule catalogue (limits, geography, time, tank capacity, vehicle status, telematics where present) and builds the invoice sets; anomalies go out as same-day cases for decision.
In the modelled case consolidated invoicing stops waiting for the gluing, and the first real abuse number in the company’s history emerges after a quarter of daily control. Model numbers, not anyone’s ledgers.
Proposed solution
We start with the register and the rules: vehicles, cards, drivers, limits, and a catalogue of control rules with thresholds, written down with finance and the fleet. Rules are versioned configuration, not code: a new rule is a table row, not a project.
Daily, the robot pulls transactions from every source, brings them to one format and assigns them to vehicles and drivers, with an explicit list of unassignable lines instead of a silent “it matched somehow”. Every transaction passes the rule catalogue; where a customer has telematics, lines are additionally checked against vehicle location and status.
Clean transactions build the consolidated invoice sets in the ERP exactly on the customers’ cycles. Anomalies become Microsoft Teams cases with full context: the card, its history, the pattern, a map where telematics exists. A person decides: block the card, ask the driver or the customer, accept with a note. Customer disputes get a transaction dossier in one click, while the evidence is fresh.
UiPath Orchestrator: daily runs, per-source queues, retries and an audit trail; UiPath Document Understanding for dispute attachments; UiPath Integration Service connectors for Microsoft Teams and Outlook 365; UiPath Action Center cases
Source normalisation, the card-vehicle-driver register, the versioned rule catalogue, assignments with explicit exceptions, invoice sets, anomaly cases with context and dispute dossiers
Card operators’ files and APIs, the own card system, SAP invoicing via documented interfaces, fleet customers’ telematics where available
How the automated process works
- AutomationDaily, the robot pulls and normalises transactions from all card sources
- AutomationLines are assigned to vehicles and drivers; unassignable ones land on an explicit list
- AutomationEvery transaction passes the rule catalogue; with telematics, also a check against route and vehicle status
- SystemClean transactions build the consolidated invoice sets on the customers’ cycles
- PersonAn anomaly is a same-day case: block, question, accept, always a human decision
- PersonA customer dispute receives a transaction dossier with history and map while the event is fresh
Human-in-the-loop model
Automation handles
- Daily consolidation and normalisation of all transaction sources
- Assignments, the rule catalogue and invoice set building on cycle rhythms
- Anomaly cases with context and dispute dossiers on demand
People decide
- The rule catalogue, thresholds and limits, and every change to them
- The decision in every anomaly: block, question, accept
- Dispute resolutions and conversations with fleet customers
Before and after
Systems and integrations
The stack is short on purpose: one engine, one execution layer, one place where a person decides.
Inputs
- transactions from the own system and operators
- the card, vehicle, driver and limit register
- the control rule catalogue
- telematics data where available
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- consolidated invoice sets in the ERP
- anomaly cases in Microsoft Teams
- dispute dossiers and rule statistics
Human touchpoints: UiPath Action Center cases in Microsoft Teams; a weekly rule effectiveness review with finance and the fleet
Technologies used
daily per-source runs, queues, retries, credential store, audit
Aanomaly cases, dispute dossiers and customer correspondence
Ablock and acceptance decisions where fleet finance already works
Areading dispute attachments and confirmations when they arrive as PDFs and scans
Ainvoice sets and settlements via documented interfaces; the robot prepares, posting follows your rules
AHow we deliver this
From this description to a running process
We deliver this solution through our process automation service: first we measure the process on company data, then we build, test and maintain the robots. SAP integration is handled by our SAP team.
Industries
Case studies
Delivered client work is described under Case studies.
Illustrative economic model
Numbers you can check against your own data.
The abuse percentage is by definition unknown before controls exist, and it is the model’s biggest unknown; 0.4% is cautious and “half detectability” deliberately modest. The real number will emerge after the first quarter of daily rules, and it will be the first such number in the company’s history.
Run the numbers on your data
An illustrative estimate based on your inputs. It models freed capacity, not promised savings.
Business benefits
- Consolidated invoicing leaves the critical path, because the sets are ready daily
- Anomalies get their question the same day, and an abused card does not work until cycle end
- Disputes are explained with a dossier instead of conceded, while the driver remembers and telematics has the record
- Limits and rules are reviewed on effectiveness statistics, not on hunches
- The cost of abuse becomes a manageable number instead of dissolving into the “fuel” line
The management view
- Control stops being statistical: every transaction passes the same rules, daily
- Every decision, a block, an acceptance, a dispute resolution, has a record with a name and context
- Fleet customer conversations run on dossiers, not on apologies
Board-level KPIs
anomalies per thousand transactions and their outcomes · time from transaction to anomaly decision · disputes conceded without explanation · invoice set timeliness · value of detected abuse per quarter
Security and governance
The automation has exactly the permissions it needs. Not one more.
- Card and transaction data is processed to the minimum the rules require; per-source access, technical accounts, full audit
- A card block is never automatic: the robot prepares, a person decides, the record remains
- The rule catalogue and limits are versioned; every case records the rule and version that raised it
- Driver data is limited to business assignments; cases deal in card and vehicle numbers, dossiers reveal personal data only to the authorised
- Cases and registers stay in your Microsoft 365 tenant, and the robots run in the EU region of UiPath Automation Cloud
Why now
Fuel prices made fleet cards a significant customer cost line: fleets ask about controls and reports, and the operator who has them wins tenders.
Telematics has become ordinary: the data to check transactions against routes already sits with customers, waiting only for a process that uses it.
Scale grows faster than teams: every new fleet customer is thousands of lines, and a spreadsheet does not hire itself.
Relevant executive roles
The cost of abuse and errors becomes measurable and falls; consolidated invoicing stops depending on file-gluing
Controls and dispute dossiers become a sales argument towards fleets, not a service cost
Limits and rules rest on statistics, and questions reach drivers while the event is fresh
Common questions and objections
They do, and rightly: they catch patterns visible in their network. They do not see your context: routes, vehicle statuses, idle days, the driver register. Most anomalies surface exactly at the seam of those two worlds, and that seam is yours, not the operator’s.
Thresholds exist so the noise stays in statistics: you start with sharp rules (volume above tank, a card on an idle day) and widen by effectiveness. The weekly rule review is part of the process; a rule that produces noise is tuned or switched off, with a change history.
The card system authorises and charges; the overlay settles and controls. Different jobs: authorisation looks at the card at transaction time, control at the pattern over time and across the fleet. The overlay does not replace the system, it consumes its data along with the other sources.
When this is not the right solution
- A fleet under ~20 vehicles with one transaction source: the operator’s report and a glance will do
- No electronic transaction sources: daily control cannot be built out of paper receipts
- The expectation of automatic blocks without a person: we deliberately do not do that, because the cost of a false block is borne by a driver on the road
A question for the next management meeting
What did fleet card abuse and errors cost us last year, and where does that number come from, given that control runs once per cycle?
Implementation approach
Scope without ambiguity, before anything is signed.
We deliver
- The card-vehicle-driver register and the rule catalogue with thresholds, written down with finance and the fleet
- Daily consolidation of all sources with an explicit assignment exception list
- Consolidated invoice sets on the customers’ cycle rhythms
- Anomaly cases with context and one-click dispute dossiers
- Rule effectiveness statistics, and a parallel run through one full invoicing cycle
We need from you
- Three months of transactions from all sources plus the card and vehicle register
- A rule catalogue owner in finance and a contact on the fleet side
- Access to operators’ files or APIs and to ERP invoicing
Stages
Discovery
A month of transactions run through preliminary rules: the source map, register drifts, the first anomalies
Rules
The rule catalogue with thresholds and decision paths approved by finance and the fleet
Build
Normalisation, assignments, rules, invoice sets, cases and dossiers
Parallel run
One full cycle: the robot settles in parallel, differences against the current process explained to the line
Go-live
Switch to the robot’s sets, rule review after the first month
A quick win. Effort depends on the number of sources and the quality of the vehicle register; telematics is an option, not a precondition.
Card 2417 had been filling up on Saturdays, a hundred kilometres from base, since March. The consolidated invoices went out monthly, on time.
Send us a month of transactions from all sources and the vehicle register. We return an analysis: the lines our rules would have flagged for decision, the assignment drifts, and an estimate of the time invoicing would recover.
Send a month of transactions for analysisThe neighbouring process usually has the same problem
Tills, terminals, cash and the courier line up by themselves; people see only the exceptions.
See the solution Sales & marketingThe new wholesale price list in the ERP before stations openA producer’s 6 a.m. price change no longer means a day on yesterday’s margins.
See the solution Operations & productionNo driver dispatched on an expired documentDriver and vehicle documents expire in fourteen calendars.
See the solution