Aviation Fuel Management Software Problems: The 7 That Cost Airlines Real Money
The most expensive failure in aviation fuel software is checking the supplier's number instead of recomputing it. A tolerance comparison only catches errors the supplier makes twice, so the ordinary leaks survive: a price taken from the day of delivery when the contract says mean of the delivery month, an into plane fee charged at a station where the contract includes it, volume billed at observed litres rather than corrected to standard temperature, a ticket appearing on two statements. None is large alone, which is exactly why nobody catches them by eye on tens of thousands of lines a month, and why the sampling approach every fuel team uses leaves most of the exposure unexamined.
Why does contract pricing modelling overrun scope?
Fuel projects get scoped from a rate card. That is the wrong artefact. The commitment is a contract with a formula, and the formula has more moving parts than a rate field can hold: index source and quote type, the pricing window whether that is day of uplift, a weekly mean or a monthly mean, the differential, currency and conversion basis, minimum and maximum clauses, and a fee schedule that varies by station.
The scope error compounds because standard three way matching does not apply. There is no purchase order in the usual sense. The receipt is a ticket signed on a ramp at three in the morning and the invoice arrives weeks later in a supplier specific layout. The match is not quantity against quantity, it is a recomputation from first principles followed by a comparison.
Teams that miss this build an invoice checker with tolerances, discover it finds almost nothing, and conclude the data is fine. It is not fine, it is unexamined.
The fix is a price recomputation engine that treats the contract as its specification and produces the expected amount independently, without reference to what the supplier billed. That independence is the entire point of the system. Scope contract modelling as a funded discovery phase, count your structurally distinct contracts rather than your suppliers, and start with the ten highest volume stations, which usually carry most of the spend and have the best ticket data.
What goes wrong with ticket data and unit conversion?
Aviation fuel moves between volume and mass constantly, and the conversion is where the discrepancy usually lives. 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. Density either comes from the ticket or from a default nobody documented.
Any system storing a single quantity field has already lost the ability to audit, because collapsing the numbers destroys the evidence. Migration makes this worse: historical tickets are loaded as one figure with the unit inferred from the station, and a station that changed convention two years ago silently corrupts the history.
The ticket archive has its own problems. Scanned tickets with smudged density readings. Agent codes that changed after a handling contract moved. Ticket numbers that repeat across years because the agent restarts a sequence annually.
The fix is a proper units model from the first release. Store observed volume, temperature, density and corrected volume as separate facts and derive mass. Every conversion is reproducible and every default is visible on screen rather than buried in code, because density disputes are common and unwinnable if the numbers have already been merged. On migration, load only the periods you might realistically dispute, carry the unit and density as recorded rather than normalised, and flag rather than convert anything ambiguous.
Why do agent feeds and flight operations integrations break after launch?
Ticket capture is the fragile input. Some agents send structured files, some send spreadsheets, some send scanned tickets, and coverage across a real network is never complete. Anyone designing as though full electronic coverage is arriving has not worked with fifty agents.
After launch the failures are these. An agent changes their file layout and the parser silently skips rows rather than erroring, so a station's volume drops and looks like a schedule change. An agent stops sending altogether when a handling contract moves, and nobody notices because there is no expected volume to compare against. Extraction quality degrades when a scanner is replaced and confidence scores fall without anyone watching the trend.
Flight operations integration breaks differently. Tickets match to flight legs, and schedule changes, tail swaps and diversions between the ticket being signed and the file being processed mean a naive match fails. If the matching logic has no tolerance and no exception queue, unmatched tickets quietly accumulate and the fuel data never becomes route economics.
The fixes are absence monitoring and exception design. Alert when a station's ticket count falls outside its normal range or when an agent has sent nothing this week. Retain raw files so a layout change can be diagnosed and reprocessed. Build matching with tolerance on date, station and registration, and route the rest to a queue with the evidence attached. Assume manual formats forever and staff for it honestly.
What happens when tax and fee rules are not covered?
Tax gets deferred because it is complicated and it is not a system decision. That deferral is the gap.
Charges depend on the airport, the state or country, whether the sector was domestic or international, and exemptions your tax team has taken a position on. Without a rules layer, tax is either taken from the supplier's figure, which defeats the purpose, or hard coded into an invoice template, which means last quarter's calculation cannot be reproduced after a rate change.
The failures are specific and expensive. Tax charged on an international sector that was exempt, paid because nobody had a rule to check it against. A rate change applied from the wrong date, so a whole quarter is wrong in one direction. An airport specific charge or local surcharge added by a supplier at a station where the contract does not permit it, indistinguishable from a legitimate line without a fee schedule to check against.
Into plane and throughput fees belong in the same layer for the same reason. They are contractual, they vary by station, and they are the fees suppliers most often apply where the contract says they are included.
The fix is to hold tax and fee rules as data with effective dates, owned by your tax team rather than your developer, so a rate change is a dated configuration entry and a prior period recalculates to what it was rather than to today's rules. Then every disputed line has a rule version attached to it, which is what turns a dispute into a short conversation.
Should you build custom or configure what you already own?
Configure, if you fly out of a small number of bases under posted price or fixed differential contracts with one or two suppliers, and your monthly ticket count is small enough that a person can genuinely check every line. In that situation the recovery from automation will not cover the build, and a careful accounts payable clerk with a spreadsheet catches most of what a system would.
FuelPlus and i6 Group are the established products with genuine domain depth, and an airline moving off spreadsheets will get value from either. They handle contract libraries, invoice processing and fuel management workflow, and they know the vocabulary, which is more than a general spend tool. If you have not evaluated them properly, do that before scoping a build.
What tends to remain outside them is the integration edge and the unusual contract. Ticket data arrives from whichever agent handles each station in whatever format that agent produces. Matching to flight legs means dealing with your own flight numbering, tail assignment and schedule changes. Tax treatment reflects advice your tax team has taken. Every one of those seams is where a packaged product hands you a file interface, and where reconciliation quietly returns to spreadsheets.
Build, or build alongside, when those seams have already pushed work back into workbooks, when contract pricing uses index formulas your accounts payable team cannot evaluate, or when you want fuel cost attributed to routes rather than to a monthly total.
How do hidden costs get into the quote?
Ticket format count is the first and most reliable overrun. Each into plane agent produces something different and each new format is real work. Count formats, not agents and not stations.
Tax jurisdictions are the second, and the cost is only partly technical. The expensive part is getting your tax team to write the rules down with enough precision to encode, and that requires their time on their schedule.
Flight data availability is the third. If clean leg data is available from your operations system this is straightforward. If it has to be reconstructed from schedules and movement messages, it is a project.
Hedge reporting is the fourth. Treasury usually wants position and effectiveness reporting in the same place, and that is a separate discipline that should be scoped separately rather than folded in as a report.
Tender support is the fifth. Normalising supplier bids to a comparable landed cost per unit, using your own forecast volumes, sounds like a spreadsheet and is a modelling exercise with real logic behind it.
Ask for those five as named items with days against them, and ask what proportion of tickets the developer expects to be touched by a person. A team that has done this will give you a number rather than a promise.
What separates a build that works from one that fails here?
The builds that work recompute rather than compare. If the system takes the supplier figure and checks it against a tolerance, it will find very little and everyone will conclude the fuel data is clean. Independent recomputation from the contract is the difference between a system that recovers money and one that produces a comfortable report.
They design the exception workflow before the happy path. Every mismatch above tolerance becomes a case carrying the ticket, the contract clause, the recomputed price and the supplier line, and the case runs through to a credit note. Without that, you generate a list of differences nobody chases, which is a more expensive version of doing nothing.
They prove recovery on ten stations before extending. The highest volume stations usually carry most of the spend and have the best ticket data, so they are where the case gets made internally and where the rest of the programme gets funded.
They keep the units honest. Observed volume, temperature, density, corrected volume and mass are separate facts, and every conversion is reproducible on screen. That property is what makes a density dispute short.
And they settle ownership before kickoff: repository, infrastructure accounts, and the unrestricted right to bring in another firm. The system produces the evidence behind supplier credit claims and tax positions, and that evidence has to remain available and explainable long after any single vendor relationship ends.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The federal government spends about 80% of its IT budget on operations and maintenance of existing systems rather than on development or modernization, with many critical systems being decades old. Source: U.S. Government Accountability Office (GAO) (2025) →
- Inventory carrying cost commonly runs about 20% to 30% of inventory value, covering capital cost, storage/warehousing, insurance, taxes, handling, shrinkage, and obsolescence - a recurring cost that better inventory and warehouse software aims to reduce. Source: APQC (2023) →
- Median SaaS spend reached $9,455 per employee, and organizations leave an average of 36% of their SaaS licenses unused. Source: Zylo (2026) →
- Brandon Hall Group research on onboarding reports that done well, structured onboarding drives measurable gains in new-hire productivity, employee engagement, and retention; the page notes 41% of organizations experience greater than 5% turnover among new hires. Source: Brandon Hall Group (2024) →
Eleanor leads client services across the UK and EU, which means she sits between what a client asks for and what the delivery teams can realistically build. She writes about scoping, budget conversations and the questions worth asking before a build starts.
View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
Why does tolerance checking find so few fuel billing errors?
Because it only catches errors the supplier makes twice. A tolerance compares the billed figure against an expectation derived from previous billed figures, so a systematically wrong pricing basis or a fee charged where the contract includes it looks entirely normal. The alternative is independent recomputation: derive the expected amount from the contract, the index quote for the correct pricing window, the differential, the permitted fees and the tax treatment, then compare. That is the only method that finds consistent errors.
How should a fuel ticket be stored?
As separate facts rather than one number. Observed volume, temperature, density, corrected volume and derived mass each need their own field, with the conversion reproducible and any default density visible rather than buried in code. If a system stores a single quantity, the audit capability is already gone, because the discrepancy in a fuel dispute frequently lives in the conversion rather than in the figure itself.
What do we do about agents who send scanned paper tickets?
Extract them and treat the output as exceptions rather than as posted data. Extraction pulls volume, density, temperature, agent and ticket number well enough to run the recomputation and flag mismatches, even where confidence is too low to post unchecked. The honest framing is that it turns unread paper into checked exceptions rather than removing people from the process, and any developer who promises otherwise has not processed a smudged density reading.
How do we notice when an agent stops sending ticket data?
Monitor for absence, not just for errors. Compare each station's ticket count against its normal range and alert when it falls outside, and alert when an agent has sent nothing in an expected period. A missing feed looks exactly like a quiet station in the totals, and by the time it is noticed the accruals for that period have already been estimated. Retain raw inbound files so a layout change can be diagnosed and reprocessed rather than lost.
Where should tax rules live in a fuel system?
In a rules layer held as data with effective dates and owned by your tax team, not in code and not in an invoice template. A rate change then becomes a dated configuration entry, and a prior period recalculates to what it was rather than to today's rules. That matters because tax positions get reviewed retrospectively, and being able to show which rule version applied to a given line is what keeps a review short.
Is FuelPlus or i6 Group enough for a mid sized carrier?
Both are established products with real domain depth and either beats a spreadsheet decisively, so evaluate them properly before scoping a build. What tends to stay outside them is the integration edge: ticket capture from agents who will never send structured data, matching to your own flight numbering and tail assignments, and tax treatment reflecting advice your own team has taken. When those seams have pushed reconciliation back into workbooks, building alongside the product is the honest answer.
How do tickets get matched to flight legs when schedules change?
With tolerance and an exception queue. Tail swaps, delays and diversions occur between a ticket being signed and the file being processed, so exact matching on date, station and registration fails routinely. Build the match with defined tolerance on each of those, then route what remains to a queue with the ticket and candidate legs attached. Without this join the system stays an invoice checker rather than producing cost per sector and tankering analysis.
Which stations should we start with?
Your ten highest volume stations. They usually carry the majority of spend, they tend to have the most automated ticket data, and proving recovery there funds the rest of the programme internally without another budget conversation. Extending to the long tail of small stations with paper tickets is worth doing, but doing it first means spending the hardest engineering effort where the recovery is smallest.
What questions should I ask a development agency on the first call?
Why do companies replace generic SCM software with custom systems?
How much does a custom warehouse management system cost to build?
How long does it take to build a custom web or mobile app from scratch?
Should we start with an MVP or build the full supply chain platform at once?
Should I hire a freelancer or an agency to build supply chain software?
How much does custom supply chain software cost for a small business?
Can we migrate years of data out of our current system into new custom software?
Is custom supply chain software cheaper than SAP over five years?
What happens to our system if the agency shuts down or we part ways?
How many people should be working on my software project?
Who can build a custom supply chain software system?
Digital Heroes builds custom supply chain software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other supply chain software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
