Atraxo - Blog , Aviation Hub

Commercial vs Operational Fuel Data

Tue, 04 Aug 2026 17:49:13 +0200

Commercial vs Operational Fuel Data: Why the Difference Matters

Two aviation fuel platforms can look almost identical on the surface — and still be built to do completely different jobs.

That's not a marketing problem. It's a structural one. Aviation fuel data splits into two real domains: commercial data, which moves the buyer-seller relationship, and operational data, which moves the refuelling event itself. They live in different places, run on different technology, and work toward different goals. A platform built for one doesn't — and shouldn't try to — replace a platform built for the other.

If you're evaluating a fuel data platform, the first question isn't "what does it do." It's "which domain does it live in." Here's how to tell the difference, and why it matters for the platform you choose.

This is the condensed version — for the full structural breakdown, see the long-form page.

Two domains, one industry

Operational fuel data lives at the airfield. It's captured on specialised hardware — fuel trucks, hydrant dispensers, meters — by the into-plane agent physically connecting the hose to the aircraft. The people moving it are flight operations and turnaround coordinators on the airline side, and the into-plane fuelling agent on the other. Volumes are flight-volume, compressed into the hours before departure, and accuracy matters because errors here delay flights. The objective is e-fuelling: digitising the refuelling event itself, safely and on time.

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.

Start free

Aviation Hub Overview

Read the long-form version →

Aviation Fuel Data Exchange made easy

Thu, 06 Apr 2023 16:18:25 +0200

Exchanging data with your Aviation Fuel Business Partners is not as difficult as it seems

Business process digitalization and automation is a growing trend in the aviation fuel industry. An important element for process automation is the availability of structured data. While the IATA XML fuel data standards already provide a proven framework for structuring data in a standardized way, the implementation of data transmission infrastructures and the enablement of legacy IT systems to deal with IATA XML-structured data is considered a complex and costly endeavor which is a challenge for many organizations. But is doesn't have to be. The IATA XML fuel data standards in combination with the Atraxo Data Exchange SaaS product represent a great solution to enable existing IT systems and to participate in IATA XML-based data exchanges with business partners.

Introduction to IATA XML Data Standards

Thanks to the IATA XML fuel data standards developed over the past years by the IATA Fuel Data Standard Group (FDSG) of which Atraxo is a member, the aviation fuel industry has already access to an established framework that is used industry-wide to exchange commercial and operational data between business partners. As of today, the IATA XML fuel data standards include i) Fuel Tender/Bid XML schema, ii) Fuel Operational XML schema, iii) Fuel transaction XML schema, and iv) Fuel Invoice XML schema. More information about the IATA XML fuel data standards can be found on IATA's website at https://www.iata.org/en/programs/ops-infra/fuel/data-standards.

XML stands for eXtensible Markup Language and provides a description of data elements that can be included in a certain XML message. In this sense, the IATA XML fuel data schemas define the "language" to be used to build XML messages which are exchanged between business partners. Examples for XML messages are fuel invoices, fuel tender invitation, fuel bids, or fuel tickets. Due to its structured data representation, XML is ideally suited for processing by IT systems and therefore is an essential component for the digitalization and automation of business processes.

Using the IATA XML fuel data standards, business partners can now easily exchange fuel-related business documents in a standardized way that allows immediate processing by IT-supported processes. This is a huge achievement compared to previous processes when paper documents were faxed, PDF documents emailed, or Excel sheets shared.

Current Challenges

However, before enjoying the benefits of automated data exchange, two topics need to be addressed.

First, to connect the IT systems of business partners, both sides need to agree on the technical method of data transmission. In praxis, three methods are in use today which are i) sFTP (secure File Transfer Protocol), ii) eMail attachments, and iii) web services. The decision which of these transmission methods to use often depends on the capability of the IT systems installed. It is not uncommon to see that for example a fuel supplier needs to maintain individual data connections to each of its customers, utilizing different transmission methods. Such IT setup can become quite complex and therefore costly to maintain when doing business with a large number of business partners.

The second and more severe topic is the capability (or lack of capability) of IT systems to generate and process XML messages built according to the IATA XML fuel data standards. While existing IT systems have the capability to generate say fuel invoices, they lack the capability to send the fuel invoice in the IATA XML fuel invoice format to their customers. Such inability to produce IATA XML formatted business documents can seriously impede the growth of an organization since almost every company today is looking to digitize and automate its business processes which required the availability of structured data such as XML-formatted massages. Enabling existing IT systems to process XML data according to the IATA fuel data standards is in almost all cases a costly activity and might also depend on the willingness of the IT system provider to play along.

How Atraxo Data Exchange can help

Luckily, there is a solution to overcome the above mentioned challenges. The Atraxo Data Exchange provides a centralized IT platform that enables the secure exchange of structured data between business partners. These structured data are organized in form of messages which consist of a message header and a message body. The message header is comparable to the outside of an envelope that contains information such as sender, receiver and type of content sent. The message body contains the message itself in form of an XML or similar structure. To ensure confidentiality, the business partners exchanging data can encrypt the message body using any public/private key encryption method.

Functioning as a post office, the Atraxo Data Exchange receives data messages from business partners connected to the data exchange. These messages are processed by a message bus system that guarantees delivery to the receiver or list of receivers as defined in the message header. Since the data exchange takes care of the data delivery, each business partner just needs to configure a single data connection per content type to exchange data with any partner connected to the data exchange. Obviously, this is a huge improvement to the previous situation where individual connections to each business partner had to be configured and maintained.

Another important feature of the Atraxo Data Exchange is the concept of data converters. Data converters are small software programs that process the message body of data messages. Typically, data converters are used to change the format of data contained in the message body. Therefore, data converters are very powerful tools to enable existing IT systems to participate in IATA XML-based data exchanges. Assuming the existing IT system can export/import the required data in any format, the IATA XML enablement is quite straightforward. Firstly, establish a data connection between the IT system and the Data Exchange, using any of the supported transmission methods. Atraxo will then implement a data converter that converts the custom data format provided by the IT system into an equivalent IATA XML message representation. The converted XML message is processed by the Data Exchange transport system and delivered to the intended receiver. The same data conversion process also works the other way around when the IT systems expects to receive data in a custom format. Thus, the data converter concept provides a cost efficient option to enable existing IT system to participate in IATA XML-based data exchanges.

To learn more about the Atraxo Data Exchange and the benefits it provides, please visit https://www.atraxo.com/aviation-hub.

Get Started Now