Aviation Fuel Management Software: How Airlines and Into Plane Agents Match Every Uplift to the Contract Before Paying the Invoice

Fuel is the one invoice nobody fully checks

Fuel is the largest variable cost line most airlines carry, and it is billed in a way that almost guarantees leakage. A single flight generates a delivery ticket signed by the crew on the ramp, with a volume, a density, a temperature and an into plane agent code. That ticket becomes a line on a supplier invoice weeks later, priced from an index quote on a specific date, plus a differential, plus into plane and throughput fees, plus taxes that depend on the airport, the state or country, and whether the flight was domestic or international.

Checking one line requires pulling the ticket, the contract, the index quote for the right pricing date, the tax rule for that station, and the uplift the aircraft actually recorded. Multiply by tens of thousands of lines a month. Most fuel teams do what any reasonable person would do: they check a sample, they check the big stations, and they pay the rest. That is not negligence. It is the only option when the data lives in five places.

The errors this hides are ordinary rather than dramatic. A ticket billed twice because it appeared on two statements. A price taken from the wrong quote date because the contract says mean of the delivery month and the supplier used the day of delivery. An into plane fee charged at a station where the contract says it is included. A tax charged on an international sector that was exempt. Volume billed at observed litres rather than corrected to standard temperature. None of these is large on its own, which is precisely why nobody catches them by eye.

Why generic procurement and accounts payable tools cannot do this

Standard three way matching compares a purchase order, a receipt and an invoice. Fuel has no purchase order in that sense. The commitment is a contract with a formula, the receipt is a ticket signed on a ramp at three in the morning, and the invoice arrives in a supplier specific layout. The match is not quantity against quantity. It is a recomputation of what the line should have cost from first principles, then a comparison.

The other reason is unit handling. Aviation fuel moves between volume and mass constantly. Crews plan in kilograms or pounds, tickets are often in gallons or litres at observed temperature, contracts price in one unit and invoice in another, and density either comes from the ticket or from a default nobody documented. Any system that stores a single quantity field has already lost the ability to audit, because the discrepancy you are hunting frequently lives in the conversion rather than in the number.

Where FuelPlus and i6 Group stop

Both are established products with real domain depth, and an airline moving off spreadsheets will get value from either. They handle contract libraries, invoice processing and fuel management workflows for carriers, and they know the industry vocabulary, which is more than can be said for a general spend tool.

What tends to remain outside them is the integration edge and the unusual contract. Your ticket data arrives from whichever into plane agent handles each station, in the format that agent produces, and the coverage of automated ticket capture across your network is never complete. Your uplift figures come from your own flight operations system, and matching a ticket to a flight leg means dealing with your own flight numbering, tail assignment and schedule changes. Your tax treatment across jurisdictions reflects advice your tax team has taken. Your hedge accounting sits in treasury. Every one of those seams is where a packaged product hands you a file interface and wishes you luck, and where the reconciliation work quietly returns to a spreadsheet.

What a custom build has to include

A price recomputation engine that takes the contract as its specification. Index source and quote type, pricing window whether that is the day of uplift, a weekly mean or a monthly mean, differential, currency and conversion basis, minimum and maximum clauses, and the fee schedule. Given a ticket it should produce the expected amount independently, without reference to what the supplier billed. That independence is the whole point.

Ticket capture at every level of automation you can get, and manual entry without shame for the rest. Some agents will send structured files. Some will send spreadsheets. Some will send scanned tickets, and document extraction handles those at a quality that is good enough to flag exceptions even when it is not good enough to post unchecked. Do not design as if full electronic coverage is coming.

A proper units model. Store observed volume, temperature, density and corrected volume as separate facts, then derive mass. Every conversion should be reproducible and every default should be visible. Density disputes are common and unwinnable if your system has already collapsed the numbers.

Flight leg matching. A ticket belongs to a flight, and the flight carries the sector, the route, the tail and the operating context that decides tax treatment and cost allocation. Getting this join right is what turns fuel data into cost per block hour, cost per sector and tankering analysis rather than just an accounts payable exercise.

A tax and fee rules layer maintained as data with effective dates, because rates change and you need last quarter's calculation to remain reproducible. Exemptions for international sectors, airport specific charges and local surcharges belong here rather than being hard coded into an invoice template.

An exception and dispute workflow. Every mismatch above a tolerance becomes a case with the ticket, the contract clause, the recomputed price and the supplier line attached, and the case carries through to a credit note. Without the workflow you generate a list of differences that nobody chases, which is a more expensive version of doing nothing.

Tender support if you run seasonal fuel bids. Volume forecasts per station, bid collection, normalisation of offers into a comparable landed cost including fees and taxes, and award. Suppliers price differently and the comparison is rarely apples to apples until someone builds the model.

What it costs and how long it takes

A first release covering contract modelling, ticket ingestion for your largest agents, price recomputation, and the exception workflow runs $90,000 to $180,000 and ships in 12 to 18 weeks. A full platform adding flight leg matching from your operations system, the tax and fee rules layer across jurisdictions, tender management, hedge position reporting and cost analytics runs $250,000 to $550,000 phased over 8 to 14 months.

Cost drivers here are specific. The number of into plane agents and ticket formats, because each new format is real work. The number of tax jurisdictions and how confident your tax team is in writing the rules down. Whether flight data is available cleanly from your operations system or has to be reconstructed. And whether treasury wants hedge positions and effectiveness reporting in the same system, which is a separate discipline and should be scoped as one.

What keeps cost down: begin with your ten highest volume stations. They usually carry the majority of spend, they have the most automated ticket data, and proving recovery there funds the rest of the programme internally.

When buying is the right call

Buy if you fly out of a small number of bases under posted price or fixed differential contracts with one or two suppliers, and if your monthly ticket count is small enough that a person genuinely can check every line. In that world the recovery from automation will not cover the build.

Build when you have found billing errors by accident and suspect there are more, when contract pricing uses index formulas your accounts payable team cannot evaluate, when you operate at enough stations that tax treatment varies materially, or when you want fuel cost attributed accurately to routes and sectors rather than to a single monthly total.

How to choose a developer for aviation fuel software

Ask them how they will store a ticket. If the answer contains one quantity field, stop there. The right answer separates observed volume, temperature, density, corrected volume and mass, and treats the conversion as reproducible.

Ask how the system decides what a line should have cost. You want an independent recomputation from the contract, not a tolerance check against the supplier figure. A tolerance check only finds errors the supplier makes twice.

Ask what happens when a scanned ticket arrives with a smudged density. A team that has done this will describe an exception queue, a confidence score and a human review step, and will tell you honestly what proportion of tickets end up touched by a person.

Ask how they will match tickets to flight legs given schedule changes and tail swaps. If they have not thought about it, the fuel data will never become route economics and you will have built an invoice checker rather than a fuel system.

Ask who owns the code and settle it in writing before kickoff. You should hold the repository, the infrastructure accounts and the right to hire any other firm. At Digital Heroes the client owns the code from the first commit, which matters when the system is producing the evidence behind supplier credit claims.