Petrol Station Anti-Fraud: Reconciling Fuel Pumps with the ERP

A petrol station sells one product through a handful of machines, and every litre should leave two traces: the pump meter counts it, and the operator's books record the transaction. When the two agree, the forecourt is under control. When they drift apart, fuel is leaving the site without being paid for, or being paid for in a way the books never see.

Fuel is valuable, easy to move and easy to resell. That makes it a target from outside the site and from inside it, through dispensing that is never recorded, transactions that are voided or under-recorded, or stock that simply disappears.

The problem is not limited to forecourts. Teltonika, citing a study published by Springer, reports that "companies that have suffered diesel theft incidents have had a total of 150,225 litres of fuel stolen" (Teltonika, efficient fuel management solutions). In a case documented for Schildknecht AG, employees at a beverage manufacturer's production site discovered one morning that 100 litres of diesel had been stolen from a fuel tank. Without fill-level and flow data, nobody could say when it had been taken.

That last detail is the real issue. The loss was found. The evidence was not.

Most operators already hold both numbers. The pumps, or the controller that runs them, know what was dispensed. The ERP holds the transactions, deliveries and stock. The gap sits between the two systems.

When matching them is a manual job (exports, spreadsheets, someone comparing totals), it happens periodically, often at month-end, and it happens on totals. A shortfall in a monthly total says that something went wrong. It does not say which pump, which shift or which transaction. By the time anyone can ask the question, the trail has gone cold.

Melqart Systems worked on an anti-theft and anti-fraud solution for petrol stations. At its core is an integration: the fuel pumps are connected to the operator's ERP, so pump transactions are tracked automatically and reconciled against the records in the ERP. Where dispensed fuel and recorded transactions do not agree, the mismatch is flagged as possible theft or fraud.

The station does not have to change how it runs. The pumps keep dispensing and the ERP keeps doing the books. What changes is the comparison between them: it stops being a periodic manual task and becomes an automatic one.

The client, its location and the figures behind the project are confidential, so this case study describes the approach rather than the numbers.

Described as a design pattern rather than a site-by-site specification, the solution has four layers:

• Capture at the site: pump transaction data is read where it is generated, by an edge device on the station network. The interface depends on the installed equipment, for example a serial link to the forecourt controller or an interface the controller already exposes.
• Normalize: each transaction becomes one record in a common format (pump, product, volume, amount, timestamp), whatever the make of pump or controller.
• Reconcile: records are matched automatically against the corresponding ERP entries, through whatever interface the ERP offers, for example an API or a scheduled import.
• Flag: transactions without a matching record, or with values that do not agree, are raised as exceptions for review.

Two design choices carry most of the weight. The edge device buffers locally, so a network outage at the station delays reconciliation instead of losing transactions. And the reconciliation rules live in software the operator owns, so the definition of a mismatch can be tuned as the operator learns where its losses come from.

Theft and fraud surface when they happen. A mismatch is flagged when the transaction is reconciled, not weeks later inside a month-end total. The question "which pump, which transaction?" has an answer while it can still be acted on.

One source of truth. Pump records and ERP records are tied to each other, so station management, finance and auditors work from the same reconciled data instead of two systems that disagree.

People work on exceptions. Software does the routine matching. Staff spend their time on the transactions that actually need a look.

Take the forecourt away and the shape is familiar: a machine that measures a physical quantity, a business system that records the money, and a gap between the two where losses hide. Fuel depots, fleet refuelling points, bulk liquid dispensing, any metered product that changes hands. Capture the measurement at the source, match it against the business record automatically, send people only the exceptions.

Melqart Systems is an industrial IoT engineering bureau based in Luxembourg. We build the integration between field equipment and the business systems your teams already use, such as ERP, CMMS and cloud platforms, and the customer owns the result. If your losses only show up at reconciliation, talk to us about a pilot.