Aviation Hub → Standards Distinction
Commercial vs Operational Fuel Data — Why It Matters
Two aviation fuel platforms can look alike and still do completely different jobs. Here's the structural line between commercial and operational fuel data, and why the platform you choose should match the domain you actually work in.
By Klaus-Peter Warnke · Long-form · ~12 min read · Also available as the condensed blog version
1. The single question this page answers
Why do some aviation fuel platforms look superficially similar but lead to very different outcomes?
The short answer: they sit on different sides of a real domain boundary. One side moves the commercial relationship between buyer and seller. The other side moves the operational event at the aircraft. They live in different places, run on different technology, and use different IATA standards. A platform built for one does not — and should not — try to replace a platform built for the other.
The Aviation Hub is a commercial-domain platform, and it's also the connective layer — the middleware — between the two domains: it carries fuel delivery data from the operational side into the commercial process, and it carries fuel authorisations and credit line status back out to the operational side.
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.
2. The two domains
Different location. Different hardware. Different objective. Different standards. Same industry.
Moves: the buyer-seller relationship
Runs on: SaaS — procurement, billing, treasury
Lifecycle: Tender → Bid → Award → Contract → Ticket → Invoice → Settlement
Cadence: per-contract, per-period — monthly invoice cycles
Volume: tens of thousands of tickets/invoices a month
Standards: IATA Fuel XML (Tender/Bid, Invoice) + IATA IS-XML
Objective: digitised quote-to-bill
Moves: the buyer-seller relationship
Runs on: SaaS — procurement, billing, treasury
Lifecycle: Tender → Bid → Award → Contract → Ticket → Invoice → Settlement
Cadence: per-contract, per-period — monthly invoice cycles
Volume: tens of thousands of tickets/invoices a month
Standards: IATA Fuel XML (Tender/Bid, Invoice) + IATA IS-XML
Objective: digitised quote-to-bill
Lives at the airfield
Moves: the refuelling event itself
Runs on: specialised hardware — trucks, hydrants, meters
Lifecycle: Schedule → Fuel orders → Refuelling → Fuel Summary
Cadence: per-flight, compressed into hours pre-departure
Volume: tens of thousands of refuelling events a day
Standards: IATA Fuel XML Transaction + AIDX XML Fuel Summary
Objective: e-fuelling
Moves: the refuelling event itself
Runs on: specialised hardware — trucks, hydrants, meters
Lifecycle: Schedule → Fuel orders → Refuelling → Fuel Summary
Cadence: per-flight, compressed into hours pre-departure
Volume: tens of thousands of refuelling events a day
Standards: IATA Fuel XML Transaction + AIDX XML Fuel Summary
Objective: e-fuelling
3. 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.
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.
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.
4. Why the two shouldn't collapse into one platform
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.
5. The platform landscape, structurally
Operational-only platforms
Move AIDX data between airline-ops and into-plane agents. Essential infrastructure — but no commercial layer. Can't tell you what your supplier billed, or whether an invoice matches a contract.
Vendor-defined commercial portals
Move commercial data, but inside one vendor's customer network. Work well for counterparties already on that portal — a separate integration is still needed for everyone who isn't.
Aviation Hub
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.
6. What this means for buyers
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.
7. Why neutrality matters
A commercial fuel platform that holds the data and the relationship at the same time can extract rent from either side. An open exchange built on industry standards has no such incentive — our value is in the network and the standards, not in being the bottleneck. If we stop being useful, you take your standards investment and go. We have to earn it. Three structural commitments follow:
No proprietary data formats. Every message we process either follows a published IATA standard, or — for outside-scope messages — uses your existing format unchanged.
8. The bottom line
There are two real domains in aviation fuel data — commercial and operational — living in different places, run by different people, on different standards. A single combined platform is structurally missing half of what either job needs.
If your fuel data challenge is commercial — and it almost certainly has commercial components — the Hub is built for it.
Companion pages
- IATA Standards Coverage Map — now the message-coverage table embedded on the live Data Exchange page
- Aviation Hub overview — the main product page
- Start Free — the Basic-tier sign-up flow
- Commercial vs Operational Fuel Data — the condensed blog version
