Why can't a forecourt POS just call the tax authority directly?

Because the customer is waiting and the link is not guaranteed. A design that submits synchronously ties fuel sales to the availability of an external service. The workable pattern computes whatever the receipt must carry locally, in milliseconds, and submits to the authority asynchronously so that a reporting outage never stops a pump.

What has to be printed on a fuel receipt under a structured e-invoicing mandate?

Most clearance and reporting regimes require a machine-readable block, typically a QR code, alongside the human-readable total, because a consumer has no portal in which to view the document. Where the regime specifies derived identifiers, those must be computed deterministically from the invoice's own fields so an auditor can recompute them independently.

What should happen when a station loses connectivity?

The sale proceeds and the receipt prints; the submission queues locally and is retried. Three things must be designed in advance: idempotent submission so retries cannot create duplicates, a bounded queue with alarms before disk fills, and per-site reconciliation against authority acknowledgements rather than assuming a send succeeded.

How do consumer and fleet sales differ at the same pump?

A consumer sale is generally a simplified document with an anonymous buyer, where the printed receipt is the compliance artifact and the obligation is to report it. A fleet or business sale carries a registered buyer identity and must reach that buyer's systems, which is where network delivery over Peppol applies. Treating both as one flow is a common architectural mistake.

How does Oman's Fawtara regime affect a fuel retail network?

Fawtara is a five-corner clearance model in which an accredited service provider sits between the taxpayer and the tax authority. Accreditation is a property of the provider, so keeping current with the PINT OM profile moves off the retailer's roadmap. Because that profile changes, the profile version should be deployable configuration rather than something compiled into station software.

E-Invoicing for Fuel Retail Networks

Fuel retail is the hardest place to put an e-invoicing mandate, and the reason has nothing to do with tax law. It is that the compliance artifact is a printed receipt handed to someone standing at a pump, and the pump does not wait. A network of a few hundred stations generates more individual tax documents in a week than a large manufacturer issues in a year, each one worth a few rials, each one legally an invoice.

This paper sets out a reference architecture for meeting a structured e-invoicing mandate across a forecourt network: where the compute belongs, what the receipt has to carry, how to behave when the network is down, and how to roll the whole thing out across sites you cannot visit.

Why fuel retail is not just high-volume B2C

Retail e-invoicing guidance usually assumes a shop counter with a browser, a stable connection and a customer willing to wait a moment. A forecourt breaks each of those assumptions:

The transaction is already over. Fuel is dispensed before it is priced. The document is produced after delivery, not as part of an approval flow.
Latency is measured against a queue. A second of added wait per transaction is a visible line of cars at peak hour.
Connectivity is not guaranteed. Stations sit on highways and at borders. A design that fails closed when the link drops stops fuel sales.
The hardware is fixed. Forecourt controllers and thermal printers are certified, long-lived equipment. A compliance design that requires new printers is a capital project, not an integration.
Two lanes, one estate. The same station serves anonymous cash customers and fleet accounts that need a proper B2B invoice against a registered buyer.

The reference architecture

The workable pattern separates three concerns that are often collapsed into one: the point of sale, the compliance computation, and the network transport.

At the site: the forecourt system stays the system of record

The pump controller and POS keep doing exactly what they do — metering, pricing, payment, and printing. They are not asked to learn UBL, to hold certificates, or to reason about tax rules. What they gain is one additional call and one additional block of data to print.

At the edge: a local agent does the compliance work

A small agent runs on the station's existing hardware. It receives the transaction from the POS, builds the structured document, computes whatever the mandate requires on the receipt, and hands that back for printing. Because it is local, the round trip is measured in milliseconds and does not depend on the wide-area link being up at that instant.

At the access point: transport, discovery and reporting

Submission to the tax authority or the network happens asynchronously from the site. A certified Access Point handles participant discovery, message-level signing and the retry behaviour that any real network requires. The station never blocks on it.

The important property of this split is that the customer-facing path and the reporting path fail independently. A tax authority outage should never stop a pump.

The receipt is the compliance artifact

In most clearance and reporting regimes the paper handed to the customer is what must carry the proof, because the customer has no portal and no account. That usually means a machine-readable block printed on the receipt alongside the human-readable total.

Two practical constraints govern this and both are physical:

Width. Thermal rolls are typically 80mm or 58mm. A QR code carrying a signed payload has to remain scannable at that size after the roll has been sitting in a hot cab.
Time. Rendering and printing sit in the customer's wait. Anything that takes appreciable time per transaction has to be measured, not assumed.

Where a regime specifies identifiers derived from the transaction, those identifiers must be computed deterministically from the invoice's own fields, so that the same transaction always produces the same value and an auditor can recompute it independently. Getting this wrong is a silent failure: receipts print, customers leave, and the documents are rejected later in bulk.

Designing for the moment the link drops

Offline behaviour is the part most often left until the pilot, and it is the part that decides whether the rollout survives contact with a highway site.

Decide what the receipt says when reporting is unavailable. Most regimes permit the sale and require the document to be reported within a window. The receipt still prints; the submission queues.
Make submission idempotent. A queued document that is retried after a partial failure must not create a duplicate. Deduplicate on a stable key derived from the transaction, not on a locally generated sequence number.
Bound the queue. Disk fills. Decide in advance what happens on a site that has been offline for a week, and alarm on it before it becomes a data-loss event.
Reconcile, do not assume. A site is compliant when the authority acknowledges the document, not when the agent sent it. Track the acknowledgement per site.

Rolling out across an estate

Integrating one station is an engineering task. Integrating two hundred is a logistics one, and the difference is where projects fail.

Integrate with the vendor, not the site. If one forecourt platform runs the estate, the integration is built once against that platform and inherited by every site that already runs it.
Prove it in the vendor's lab first. Lab validation against real controller software removes the entire class of problems that would otherwise be discovered at a live pump.
Assume no site visit. Configuration, upgrade and diagnostics must be remote, because a change requiring an engineer per station will not be delivered on schedule.
Pilot both lanes. Consumer receipts and fleet invoices exercise different rules; a pilot that covers only the pump will discover the B2B gaps in production.

Consumer and business sales are different documents

A cash customer at a pump and a haulage company with a fuel card are not the same transaction in tax terms, even though the fuel and the dispenser are identical.

The consumer sale is typically a simplified document: the buyer is anonymous, the receipt is the artifact, and the obligation is to report it. The business sale carries a registered buyer identity, needs to reach that buyer's own systems, and generally follows the full invoice rules — which is where a network such as Peppol earns its place, because the document has an actual recipient to be delivered to. Treating both as one flow is the most common architectural mistake in this sector.

Oman: Fawtara and the five-corner model

Oman's Fawtara programme is a clearance-style regime built on the five-corner model, in which an accredited service provider sits between the taxpayer and the tax authority rather than the taxpayer reporting directly. For a fuel retailer this matters in a specific way: accreditation is a property of the provider, so the compliance burden of staying current with the specification moves off the retailer's roadmap.

The Omani profile is defined by PINT OM, and it is a moving specification — the move from v1.0.0 to v1.0.1, for instance, tightened identifier requirements in ways that silently invalidate documents built against the older reading. Any forecourt design should treat the profile version as a deployable configuration rather than something compiled into station software, because station software is the slowest thing in the estate to change.

GoRoute is an accredited service provider for Oman and operates a certified Access Point. Further detail on the Omani regime is on our Oman e-invoicing page and in our explainer on the five-corner model.

Questions worth putting to your forecourt vendor

Most of the risk in these programmes sits with the POS vendor rather than the tax rules. Five questions surface it early:

Can the POS call a local service at the point of sale, and what is the timeout behaviour if it does not answer?
Can the receipt template carry an additional machine-readable block, and who controls that template?
What operating system and runtime are the station machines actually on today, across the whole estate?
How is station software updated, and how long does an estate-wide update take in practice?
Is there a lab environment with real controller software where integration can be proven before any site is touched?

If the answers are known, a forecourt e-invoicing programme is a well-understood integration. If they are not, they are the first thing to establish — ahead of any discussion about document formats.

Where to go next

For the network mechanics underneath this architecture, see our whitepaper on connecting ERP systems to a Peppol Access Point. For the group-level view when a retailer operates through several legal entities, see e-invoicing architecture for multi-entity groups. Country requirements are collected on our global e-invoicing compliance pages.

Published by GoRoute.ai Engineering. Last reviewed 28 August 2026.

E-Invoicing for Fuel Retail and Forecourt Networks