Reference · built on requestOperator by FibricFleet, routes & field

Fuel Anomaly

Reconciles fuel card purchases with telematics fuel level, odometer, and location and proposes a card hold or driver query on mismatches.

Request accessPricing ↗

About

Fuel Anomaly is an operator job for the fuel card transaction that does not match the truck. It reads each purchase: card, site, time, volume, cost, and the odometer the driver keyed at the pump. It reads what the vehicle itself reported around that time: fuel level before and after, odometer, and where it was.

A purchase with no matching rise in the tank, a volume larger than the tank holds, an odometer far from the vehicle's own, or a site the truck was never near is flagged. For each flag it proposes a driver query, an issue on the vehicle, or a hold request for the card. The fleet manager decides in chat. The transaction, the telematics readings, and the decision are kept together, so a dispute later starts from evidence.

This is a reference listing. It documents what Fibric would read from Fuel Anomaly and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Fuel card transactions imported into Geotab as FuelTransaction records: cardNumber, provider, siteName, dateTime, volume, cost, odometer, and location
  • Fuel entries in Fleetio through GET /v1/fuel_entries, paged 100 at a time, as fuel card programs and drivers record them
  • Fuel card program export files dropped on SFTP, found by comparing directory listings and modification times between polls
  • Samsara fuelPercents, obdOdometerMeters, fuelConsumedMilliliters, and gps from the vehicle stats feed, cursored so nothing around a purchase is missed
  • Azuga Fuel Increase, Fuel Decrease, and Low Fuel webhook events, with Trip Start and Trip End to bracket where the vehicle was
  • Purchase and Bill records in QuickBooks Online, so a flagged transaction is tied to the expense it became

Proposed actions

  • Target capability: propose a driver query: the purchase, the vehicle's readings beside it, and the question, for the driver's manager in Slack or Microsoft Teams
  • Target capability: propose an issue on the vehicle in Fleetio, with the transaction and the readings attached
  • Target capability: propose a card hold request to the fuel program administrator, with the transactions that justify it, to place with the card provider
  • Target capability: propose re-associating a Geotab FuelTransaction with the right device, where description or licencePlate matched the wrong vehicle
  • Target capability: propose a weekly list of unmatched transactions by driver and card, ordered by the size of the mismatch

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Match Geotab fuel card imports to the vehicle's own odometer

    Each FuelTransaction carries the odometer the driver keyed and the location of the site. The operator sets it beside the device's odometer and position and proposes a driver query where they disagree.

    With Geotab, Slack

  • Check Fleetio fuel entries against Samsara fuel level

    A fuel entry with no rise in fuelPercents around its time, or a volume above what the tank can take, is proposed as a Fleetio issue on the vehicle with both records attached.

    With Fleetio, Samsara

  • Reconcile a card program export file

    Transactions arrive as a file on SFTP. Each is matched to Azuga Fuel Increase events by vehicle and time; a purchase with no event is listed for the fleet manager in Microsoft Teams.

    With SFTP, Azuga, Microsoft Teams

  • Tie a flagged purchase to the expense in QuickBooks Online

    A transaction the manager confirms as personal or fraudulent is proposed for an update to the Purchase it was booked to, carrying the finding, so accounting sees it where the cost sits.

    With QuickBooks Online, Fleetio

Requirements

  • Fuel card transactions in a system this listing reads: Geotab FuelTransaction imports, Fleetio fuel entries, or program export files on SFTP
  • A telematics connector with fuel level, odometer, and position for the same vehicles: Samsara, Geotab, or Azuga
  • A vehicle identifier shared by both sides: VIN, licence plate, or unit number keyed on the card
  • Slack or Microsoft Teams for the fleet manager's decision
Authentication
Card transactions, telematics readings, and expense records are read through the connectors you bind, under the access each grants; the operator holds no card program credential.

Limits

  • It reads card transactions from the systems they are imported into; it has no direct connection to WEX, Comdata, or any card issuer
  • A card hold is proposed to the person who administers the program; the operator cannot place, lift, or change a hold itself
  • Fuel level arrives as a share of the tank, so a mismatch in litres needs the tank capacity on the vehicle record
  • Where the telematics platform reports no reading near the purchase time, the transaction is listed as unmatched, not suspicious

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Fuel Anomaly ↗

Questions and answers

What does the fleet manager see and decide?
One item per flagged transaction: the purchase with card, site, time, and volume; the vehicle's fuel level, odometer, and position around that time; the mismatch found; and the proposed step, a driver query, a vehicle issue, or a hold request. The manager approves, reassigns, or dismisses.
What record is left?
The transaction as imported, the telematics readings it was compared with and their times, the rule that flagged it, the proposal, the decision with name and time, and any issue or update the connected systems accepted.
Can it block a card or charge a driver on its own?
No. It cannot reach the card provider, and it never marks a driver at fault. A hold is a request to the program administrator; a query is a question. Both wait for a person.
Ask about Fuel Anomaly

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy