Fuel and Fuel-Card Accounting: Entities and Anomaly Control

Why fleets need strict fuel accounting and what counts as a problem

Fragmented fuel and fuel-card accounting almost always ends the same way: fuel "disappears" in small ways. Sometimes a receipt wasn't attached, sometimes consumption was recorded "by eye," sometimes a card ended up with another driver. The result is rising costs, disputed transactions and missed month-end closings.

Good fleet fuel accounting answers simple questions without guesswork or manual follow-ups: who refuelled, in which vehicle, exactly where, how many liters and for what amount, which card and under which limit. And most importantly — why that was allowed and what supports it. If you can't quickly build a clear picture for any transaction, the process isn't under control.

The problem isn't only obvious overspend. Often signals are quiet: frequent small refuels, refuelling in an inconvenient place relative to the route, a sudden rise in average consumption, repeated operations at the same time, mismatch with tank capacity, missing documents or discrepancies between the receipt and the provider report.

Responsibilities must also be clear. Typically accounting is responsible for correct postings and closing documents, logistics for routes, mileage and planned needs, and security (or internal control) for investigating suspicious cases and enforcing card discipline. When roles are not separated, everyone does "temporary" manual fixes and in the end nobody is accountable for the result.

At the start you need basics: unified entities (card, limit, refuel, mileage, document), validation rules and a list of typical violations. Advanced elements (anomaly scoring, comparison with seasonal norms, automatic requests for explanations) are better added later, once data become stable and complete.

Data and sources: what to collect first

To avoid a dispute about "who to believe," agree in advance which data are primary and which are supporting. Usually the primary fact is the fuel-card provider transaction, and confirmations are documents and mileage.

Sources are almost always the same. From the card provider you get date and time, gas station, fuel type, liters, amount, card number and sometimes a driver identifier. From waybills you get route, driver, assignment, signatures and release/return marks. The odometer (photo or entered) provides mileage control. GPS is useful to verify actual routes and stops, but it shouldn't be the only source.

You also need mandatory reference data so records can be linked: vehicles, drivers, counterparties (providers, gas stations, services), and a gas station/point directory. Decide early what you mean by “gas station”: the legal entity, a brand or a specific station with address and coordinates.

From day one set unified rules: dates and timezone (important if refuels occur across regions), currency and VAT, units (liters and kilometers), plate and personnel number formats. Small inconsistencies later create false deviations.

To start without overload, a minimal set is enough:

• vehicle, driver, card (linked at least to a vehicle or driver)
• refuel transactions (date/time, gas station, fuel, liters, amount)
• odometer readings at shift start and end (or per trip)
• waybill as work evidence (number, dates, signatures/statuses)
• a reference of consumption norms at least by vehicle and fuel type

A practical approach: start with one division for 2–3 weeks, check data quality (gaps, duplicates, mismatched liters and amounts) and only then expand coverage.

Entity: Fuel Card — fields and relations

A fuel card is the "key" to any fuel posting. If the card is poorly described you won't confidently answer basic questions: who refuelled, in which vehicle, under which budget, and whether the card is valid.

Store identification and lifecycle info in the card record. Avoid saving the full card number in plain text: keep a mask (for example, last 4 digits) and a separate internal identifier to safely match provider transactions with your system.

Main card fields

Usually a set that helps control usage rules and quickly block "hanging" cards is sufficient:

• provider (issuer/operator) and external identifier in their system
• allowed fuel type(s) and any additional restrictions
• status: active, suspended, blocked, lost, closed
• issuance date, activation date, block/closure date and reason (who initiated)
• masked card number (e.g. **** **** **** 1234) and a "replacement/reissue" flag

Relations and responsibilities

A card usually "lives" in the context of people, equipment and budget, so explicit links help: to a driver (primary holder), to a vehicle (primary vehicle), to a division and to a cost center. Also include a responsible person (dispatcher/mechanic/financial control) so it’s clear who should react to incidents.

A practice that saves headaches: maintain a history of replacements and reissues as separate records. A driver loses a card, receives a new one, while the old one remains active at the provider. Without history you'll see two cards “for one person” and won't know which should be used. In the history record the event date, reason, initiator and the relation "old card -> new card". This helps investigations when refuels appear on the "old" card after its block date.

Entity: Limit — structure and application rules

Make limits a separate entity rather than a field on the fuel card. This lets you change rules without reissuing a card, store history, assign different restrictions to the same card under different conditions and quickly explain why an operation was allowed or denied.

A limit must have a scope: what it is bound to. It can be a specific card, driver, vehicle, division or even a route (e.g. a business trip or fixed delivery route). The system should understand overlaps: one limit may apply to a card, another to a driver, and both must be considered.

Common limit types

A few combinable types usually suffice:

• by amount (KZT) per period
• by liters per period
• by number of operations per period
• by time: days of week and hours (e.g. ban on night refuels)
• by products/categories: diesel only, ban on ancillary goods

Fields and application

Minimum fields: period (day/week/month), thresholds (hard deny and soft warning), start/end dates, priority, status (active/draft/archived), reason (why it's introduced), approver and approval date.

Application rules must be unambiguous: when checking an operation, pick the highest-priority limit in its scope, then apply more general ones (for example, division-level), and enforce the strictest restriction. That makes results easier to explain.

Handle exceptions not by editing limits but as separate entities: a one-off allowance (for one operation or a day) or a temporary increase (with end date and approval). For example, increase liters for a vehicle for a week for a long trip; after the end date the limit returns automatically.

Entity: Refuel — transactions and attributes

A refuel in the accounting system is a transaction: a money posting from a fuel card with specific parameters (when, where, how many liters and what amount). A gas station receipt or a provider report are documents that confirm the transaction. Don’t mix them: one transaction can have multiple supporting documents, and some transactions may arrive without receipts and require review.

The basic refuel record usually includes:

• operation date/time (and posting date if the provider sends both)
• gas station: chain, point, address (or station code)
• fuel type, liters, price per liter
• amount, currency, VAT (if applicable)
• identifiers: card number, provider transaction ID, internal operation ID

To investigate disputes add context: vehicle, driver, odometer at refuel time, and geolocation (if provided by terminal or app). Store odometer in two forms: entered value and confirmed value (after reconciliation with the waybill).

Statuses help separate routine operations from those needing control: success, reversal, refund, adjustment, disputed. For example, if a refund arrives for the same card and station, link it to the original transaction rather than treating it as a separate expense.

A practical rule: keep the raw provider response (original JSON/XML or export line) and the receipt time. When amounts or times differ, these data help quickly determine whether the operation was reprocessed, adjusted or duplicated.

Entity: Document — receipt control and amount reconciliation

A document in fuel accounting is needed not just for archive, but so each refuel has confirmation and matches by amount and liters. Sources vary: fiscal receipt from the station, invoice or period act, and the provider's registry.

Minimum document fields: number and date, amount, currency, buyer ID (if shown), gas station BIN/ID (and RNN if needed), fiscal markers (FD/FP) and QR data (raw string or parsed fields). Also store document type and reception channel (driver photo, export, paper).

Link documents to refuels flexibly. Most often it's 1:1 (receipt for one transaction), but 1:many occurs when an act or invoice covers a batch of refuels for a week or month. Then the document links to a set of transactions and stores the period.

Use short statuses for control:

• received
• checked
• mismatch
• missing
• rejected

A working practice: store the scan/photo, record who checked it and when, and what fields were compared. If the provider ledger shows KZT 12,300 and 35.0 L, but the receipt shows KZT 12,800, set status to "mismatch" and create a clarification task (price error, wrong station, wrong card or manual adjustment).

Entity: Mileage — how to record and confirm

Store mileage as a separate entity because norms are calculated from kilometers. A refuel alone says little: 60 liters can be normal on a highway and anomalous if the vehicle barely moved.

Mileage sources differ and don’t always match: odometer (panel photo), waybill, GPS tracks, service records. Better to store each value "as is" and mark its trust level.

Minimum mileage fields:

• date/shift
• vehicle (vehicle_id) and optionally driver (driver_id)
• start and end odometer
• km for the period (calculated)
• source (odometer, waybill, GPS, service)
• trust/confirmation status (draft, confirmed, disputed)

Validations should be strict. Odometer cannot decrease, and jumps should be flagged: sudden large daily increase not supported by GPS or route. Also check difference between odometer and GPS distance: it’s not always fraud, but it usually warrants confirmation.

Link mileage to vehicle as the primary object and driver as an attribute of the period. This makes it easier to compute vehicle-level norms and investigate deviations by shifts and personnel.

Entity: Consumption Norm — structure and versioning

A consumption norm is needed to compare "what should be" with actual refuels and mileage. Store a norm as a base rate (L/100 km) and a set of condition coefficients. This avoids dozens of nearly identical norms and provides transparent calculations.

Structure by levels from general to specific. The system should find the most specific norm available and fall back to a more general one if needed.

Norm levels (priority)

Usually 3–4 levels suffice: by model, by specific vehicle (if special), by route type (city, highway, mixed), and by season. The same vehicle in January in the city will have a different norm than in summer on the highway.

In the norm record keep: base rate L/100 km, coefficients (city/highway, winter/summer, load, air conditioning or special equipment), units and rounding rules. Store not just numbers but also how to apply them: multiply, add to L/100 km, or an absolute surcharge.

Versioning and approval

Norms change, so require validity dates: start date, end date (or active flag). Do not overwrite old norms or you'll lose the correct deviation history.

Add control fields: who approved, approval date, basis (order or regulation), status (draft, under review, approved, archived). This helps in disputes: why last month’s "overconsumption" was normal but this month it isn't.

Entity: Deviation — calculation and root-cause analysis

A deviation links refuels and mileage to expected consumption. This is where fuel and card accounting becomes manageable: instead of arguing "more or less," you get a clear calculation and a list of reasons.

Expected consumption is usually: confirmed mileage for the period multiplied by the consumption norm (L/100 km) divided by 100. Then apply coefficients if available: season (winter), urban conditions, cargo load, air conditioning, terrain. Coefficients must be formalized and tied to rules or deviations become subjective.

A deviation record should hold:

• period (start/end date) and division
• vehicle, driver (or crew), route/object (if applicable)
• actual: liters (sum of refuels) and confirmed mileage if needed
• expected: liters by calculation and applied coefficients
• result: deviation in liters and percent, and a comment

Manage root causes via a reason reference list and a short explanation. Common reasons: long idling with engine on, winter warm-ups, traffic jams, special equipment (e.g. lift), unrecorded trips or route changes.

To keep the process moving, assign statuses and owners. A practical set: under review, confirmed, data error (rejected), written off with reason (with reference and document).

Example: in a week a vehicle covered 620 km, the norm is 12 L/100 km. Expected 74.4 L. Receipts show 92 L. Deviation +17.6 L. Investigation finds 2 hours of hydraulic lift operation and morning warm-ups. If supported by waybills and a work order, the deviation is written off to that reason.

For reporting build a view: deviation (L and %), share of write-offs by reason, number of cases "under review." Drill down by division, vehicle and driver to quickly see where the issue is discipline, norms or data quality.

Detecting anomalous refuels: rules and scoring

An anomalous refuel is an operation that looks plausible by amount but doesn't match real operation. It's better to collect several simple signals and assign a risk score than to look for a single "perfect" indicator.

Quick detectors that catch most cases

Start with rules that don't require complex data and are easy to explain to drivers and accounting:

• two or more refuels in short succession (e.g. within 1–2 hours)
• night, weekend or holiday refuels when the vehicle isn’t scheduled to work
• "physics mismatch": liters exceed tank capacity or calculated L/km is 2–3x the norm
• geography: refuel far from the usual area or off the expected route
• price significantly higher than regional/period average (adjusted by fuel type)

Scoring: prioritizing checks

Assign weights (e.g. 1–5) to each indicator. Final risk = weighted sum. Example: night refuel (2) + off-area (3) + abnormally high consumption (4) = 9 points -> high priority.

Store the triggered reasons: not just "red operation" but a list of flags. That speeds dispute resolution.

Then follow a short check procedure: request receipt/photo, verify date/time, station, liters, price; compare with waybill, mileage and route; ask the driver for explanation (detour, downtime, traffic, task change). If repeated, check limits, card access and card assignment. Record the outcome: confirmed, data error, violation, and measures taken.

This reduces manual work: most operations pass automatically and suspicious ones rise to the top of the queue.

Example scenario: a week of accounting and investigating disputed operations

A fleet has 12 vehicles and 20 fuel cards. Drivers switch between vehicles so "card tied to vehicle" doesn’t work. In practice it's easier to treat a card as tied to a contract and limits, and always record usage as the tuple: card + driver + vehicle + time.

During a week data comes from three sources: card transactions, odometer readings (or waybills), and station documents (receipts, invoices). To process disputes quickly each refuel should store at least: card_id, driver_id, vehicle_id, ts, azs_id, city/coordinates, fuel_type, liters, amount, currency, authorization_code, and control fields: current limit at operation time and vehicle tank capacity.

Three disputed operations

First: two refuels 30 minutes apart. Investigate times and locations, pump/station identifier (if available), and the shift context: who was the driver, which vehicle and odometer before the first refuel. Then check physical feasibility: can that much fuel be used in 30 minutes and does the sum of the two transactions exceed tank capacity?

Second: daily mileage 40 km but 60 L were posted. Expected consumption: take the vehicle norm (e.g. 12 L/100 km). Expected: 40 * 12 / 100 = 4.8 L. Deviation: 60 - 4.8 = 55.2 L. Next record a cause: theft/drainage, wrong odometer, idling, or an unrecorded trip.

Third: a receipt was uploaded but the amount doesn't match the transaction. In the Document entity keep statuses: "received", "under review", "mismatch", "clarification requested", "closed", and store both amounts, the discrepancy and a comment.

To close such cases in 15 minutes use clear reports and queues: alerts for rapid repeat refuels, a liters vs mileage daily report by driver, a list of documents with status "mismatch" and deadline, top operations by limit exceedance and tank capacity, and a dispute card with a timeline (transaction, mileage, document, decision).

Common accounting mistakes and how to avoid them

The most costly problems are usually about data and discipline, not formulas. A small mistake grows into a month-long dispute with drivers, accounting or the provider.

One common trap is mixing entities. For example, writing a limit directly in the fuel card and overwriting the old value removes history: you can't tell when and who changed the limit and why a week’s overspend was considered normal. Solution: store limits as a separate entity with validity dates and reasons; cards reference the active limit.

Second problem: inconsistent times. Provider transactions may be in local time, UTC or with day boundaries at shift changes. This causes duplicates and date mismatches, especially with night refuels. Use a single rule: keep the provider’s original time, a normalized system time and the timezone. For reconciliation compare by transaction ID, not just date and amount.

Often reversals and adjustments are ignored: provider sends a reversal or corrects liters but your accounting still keeps the original. Then consumption and deviations drift. You need transaction statuses (draft, confirmed, reversed, corrected) and a link from the correcting record to the original.

Another mistake is not storing raw primary data. If you don't keep raw exports, original receipts and provider fields, you can't prove a disputed refuel. Minimum: save the original provider response, the receipt scan/photo, and control fields (station number, pump, authorization, final amount).

Finally, documents are often checked selectively without clear statuses. Introduce a short control cycle:

• new receipt: waiting for upload
• uploaded: under review
• matched: accepted
• mismatch: dispute/request clarifying info
• closed: decision and comment

This prevents backlogs and makes deviations explainable and auditable.

Implementation step by step: from pilot to regular control

Start with reference data: if reference lists “float,” any fuel accounting becomes manual edits. In a pilot agree on unified names and unique identifiers.

Implementation plan

Assemble a minimal loop and assign responsibilities. A practical rollout:

• approve references: vehicles (plate, model, tank), drivers, divisions, gas stations (chain ID, address, fuel type)
• define limits and norms: by vehicle, driver or division, and exception rules (trips, season, special equipment); assign who changes and approves them
• set up transaction and registry ingestion from card providers: unified time, currency, VAT, link to card and vehicle; define duplicate rules (e.g. same operation number + amount + time)
• enable document control: receipt/UPD required, otherwise the operation goes into a review queue; simultaneously enable anomaly queue using simple rules (too frequent, over tank capacity, night/weekend, wrong station)

To keep control from being a checkbox, use a short readiness checklist for month-close:

• mileage exists for the period and who confirmed it is clear
• document (receipt/registry) exists and is legible
• transaction and document amounts and liters match
• deviation from the norm is calculated and a reason recorded (data error, working mode, weather, downtime, route)
• for anomalies there is a resolution: accept, request explanation, withhold, open investigation

Run the pilot on 1–2 divisions for 2–4 weeks and note the most frequent failures: missing mileage, "unknown" stations, lost receipts, disputed limits. After the pilot scale using the template and avoid changing rules weekly.

If implementation is an integration project, plan storage and support in advance: where to keep registries and scans, which tools accounting and dispatchers will use, and who provides support. In Kazakhstan these tasks are often handled with a systems integrator and equipment vendor (for example, GSE.kz) when servers, workstations and unified 24/7 support are required.