Commercial vs Operational Fuel Data: Why the Difference Matters
Two domains, one industry
Commercial fuel data lives at HQ. It runs on SaaS software — procurement, billing, treasury systems — used by people who never touch a fuel hose: procurement, contracting, accounting, and treasury on the airline side, account management, billing, and credit on the supplier side. Volumes are large — a major airline processes tens of thousands of fuel tickets a month — and accuracy matters because every line item flows into financial reporting and audit. The objective is a digitised quote-to-bill process: tender, bid, award, contract, invoice, payment, without a paper trail or a phone call.
The two domains run on different standards, too. Operationally, a delivery gets reported out using IATA Fuel XML Transaction or AIDX XML Fuel Summary — the formats built to carry a refuelling event off the airfield. Commercially, the buyer-seller lifecycle runs on the broader IATA Fuel XML fuel standards (Tender & Bid, Invoice) and IATA IS-XML.
Different location. Different hardware. Different objective. Different standards. Same industry.
The domains meet — twice
The two domains aren't isolated from each other. They depend on each other, in both directions.
Operational → commercial. The operational domain has to send its fuel delivery data to the commercial domain — to the fuel seller and the fuel buyer both — before the commercial process can move. This is where the fuel ticket comes from: the into-plane agent's meter reading, submitted as IATA Fuel XML Transaction or AIDX XML Fuel Summary, imported by the supplier and the airline and used as the ticket for pricing, invoicing, and payment. Getting this connection right — reliable delivery, clean format conversion between what the airfield sends and what the commercial system expects — is a real integration problem, not a formality.
Commercial → operational. It runs the other way too. The operational domain needs fuel authorisations and credit line status from the commercial domain before it can act — the agent on the ground needs to know which customer to fuel, and which to turn away, before the hose goes anywhere near the aircraft. Without that data flowing back from HQ, the airfield is deciding blind on who's actually allowed to buy fuel today.
Neither direction is optional. The commercial domain can't invoice a delivery it never heard about. The operational domain can't safely decide who to fuel without knowing who's authorised and in good credit standing. Two domains, two platforms, one dependency running both ways.
Why the two shouldn't collapse into one
An operational platform doesn't have contract or pricing data. Without it, there's no way to know which customer is actually authorised to fuel today, and no way to turn a recorded delivery into an invoice — that data lives on the commercial side, not the operational one.
A commercial platform doesn't have the specialised hardware to handle or record an aircraft refuelling — the meters, the dispensers, the physical connection to the aircraft. That's airfield equipment, not something a SaaS platform can absorb.
Put the two jobs on one platform and it's structurally missing half of what either job needs. That's why a single combined platform is hard to build well — and why the two domains stay separate, connected by the data flowing between them in both directions.
The platform landscape breaks into three shapes
Once you see the domain line, aviation fuel platforms sort into three categories:
- Operational-only platforms move AIDX data between airline-ops and into-plane agents. Essential infrastructure — but no commercial layer. They can't tell you what your supplier billed you, or whether an invoice matches a contract.
- Vendor-defined commercial portals move commercial data, but inside one vendor's customer network. They work well for the counterparties already on that portal — and require a separate integration for every counterparty who isn't.
- Open commercial exchanges move commercial fuel data across any participant on standards-first infrastructure. One connection reaches the whole network, not one vendor's slice of it.
None of the three substitutes for the others. They complement.
What this means for your platform choice
Start with the question, not the feature list: what domain does your problem actually live in?
If the pain is operational — fuel-order coordination, refuelling delays, mis-fuelling — you need an operational platform. If the pain is commercial — invoice disputes, slow cash, integration overhead across suppliers, contract compliance — you need a commercial platform. And if the pain is "we're stuck inside one vendor's portal and can't reach everyone else," you need an open commercial exchange that extends your reach without replacing the access you already have.
Aviation Hub is that middleware — the connective layer between the operational domain and the commercial domain. It carries fuel delivery data from the airfield into the commercial process, and it carries fuel authorisations and credit line status back out to the agents on the ground. And because it's a shared exchange rather than a point-to-point link, it solves a second problem at the same time: distributing that fuel data to every third party who needs it — every fuel seller, every fuel buyer — from one connection, instead of a new integration for each one.
Start free. Upgrade as you grow.
