Aviation Fuel Management Software: Buy the Product or Build the Recomputation Layer
The threshold is roughly 25 stations combined with contracts that price off an index formula rather than a posted cents per gallon.
On this page
The threshold is roughly 25 stations combined with contracts that price off an index formula rather than a posted cents per gallon. Below that line, with one or two suppliers and a ticket count one careful person can genuinely check, buy FuelPlus or i6 Group and keep your capital. Most carriers reading this sit below it and should buy. Above it, where ticket data arrives from agents who will never send a structured file and tax treatment varies station to station, the honest answer is almost never full replacement. It is keeping the product for the contract library and building the recomputation and ticket capture layer beside it, at $90,000 to $180,000 over 12 to 18 weeks.
When is off the shelf genuinely the right call here?
Buy, and here is which one. FuelPlus and i6 Group are the two established products in this category and both carry real domain depth. They hold contract libraries, they process supplier invoices, and they know the vocabulary of into plane agents, throughput fees and differentials, which is more than any general spend management tool manages. An airline moving off email and spreadsheets will get value from either within a quarter.
Buy and stop there if you fly out of two or three bases under posted price or fixed differential contracts with one or two suppliers, and your monthly ticket count is small enough that a person genuinely checks every line. At that shape the recovery an automated audit produces will not cover a build, and a careful accounts payable clerk with a workbook catches most of what a system would. Spend the difference on a second pair of eyes.
Buy if your problem is that fuel data lives in inboxes and you want a competent product live this quarter. A packaged product solves that faster than any development programme, because the contract structures and the invoice formats are already there.
There is a fourth buy case that is really a not yet. Ask your fuel team to write out your largest contract in full as a specification: which index, which quote type, which pricing window, which differential, which fees are included at which station. If they cannot produce that in a week, no developer can build you a recomputation engine, because the engine is that document expressed in code. Writing it down costs nothing, it is the pacing item on every build in this category, and it is worth doing whether or not you ever commission software.
When does a custom build actually pay off?
Build when you have found billing errors by accident and suspect there are more. That is the honest trigger. A duplicated ticket, a price taken from the wrong quote date, an into plane fee charged where the contract says it is included, a tax applied to an exempt international sector. None of these is large alone, which is why nobody catches them by eye, and why finding one usually means there is a pattern behind it.
Build when your contracts price off index formulas your accounts payable team cannot evaluate. Three way matching compares a purchase order, a receipt and an invoice. Fuel has no purchase order in that sense. Checking a line means recomputing what it should have cost from the contract, the index quote and the tax rule, then comparing. That is a different operation and no accounts payable tool performs it.
Build when your ticket data arrives from agents who will never send a structured file. This is the integration edge, and it is where reconciliation keeps returning to a spreadsheet even around a product you already pay for. Some agents send clean feeds. Some send a workbook whose column order changes. Some send a scan of a signed pad.
Build when you uplift at enough stations that tax treatment varies materially between them, or when you want fuel cost attributed to routes and sectors rather than to a monthly total. That second one is a planning input, not an accounts payable output, and no invoice checker produces it.
How do they compare on the things that matter in this industry?
The units model. This is the sharpest difference and it is not cosmetic. Crews plan in kilograms, tickets are often in gallons or litres at observed temperature, contracts price in one unit and invoice in another, and density comes either from the ticket or from a default nobody documented. A system that stores one quantity field has already lost the ability to audit, because the discrepancy you are hunting often lives in the conversion rather than in the number. A build can hold observed volume, temperature, density, corrected volume and mass as separate reproducible facts. That is what wins a density dispute.
Independent recomputation against tolerance checking. A tolerance check compares your expectation with the supplier figure and only catches errors the supplier makes twice. Independent recomputation produces the expected amount from the contract without reference to what was billed. Packaged products vary here, and it is worth asking your vendor directly which one their audit module performs before you assume.
Ticket capture coverage. Both routes are limited by what agents send, and the difference is what happens to the rest. A product hands you a file interface for the formats it supports. A build treats scanned tickets as first class, with per field confidence scoring and a review queue, so unread paper becomes checked exceptions rather than an unopened folder.
Flight leg matching. A ticket belongs to a flight, and the flight carries the sector, the tail and the operating context that decides tax treatment and cost allocation. This join lives in your own flight numbering and schedule history, which is exactly the part a vendor cannot supply.
What does total cost of ownership look like at your scale?
Put the two sides on one page. On the buy side, take the annual licence and module fees and note whether they rise with fleet, stations or transaction volume. A volume linked model means growth costs you more forever, which matters if you are adding stations.
Then count what the licence does not remove. Identify the people whose real job is moving fuel data between systems: agent tickets into a workbook, invoice lines into a check sheet, station charges into a cost allocation, plus the hours spent reconciling what the sample missed. In carriers of any scale that figure is usually larger than the licence. Then add what you never invoice for: errors paid because nobody had time, and credits never claimed because assembling the evidence cost more than the credit.
On the build side, a first release covering contract modelling, ticket ingestion for your largest agents, price recomputation and the exception workflow runs $90,000 to $180,000 over 12 to 18 weeks in Digital Heroes delivery experience. A full platform adding flight leg matching, the tax and fee rules layer, tender management, hedge position reporting and cost analytics runs $250,000 to $550,000 phased over 8 to 14 months.
An airline with about 60 aircraft uplifting at 38 stations, roughly 14,000 tickets a month with index priced contracts, lands at about $143,000 for a first release covering its top ten stations. An operator with two agents sending structured files, no scanned tickets and a single posted price contract lands nearer $95,000. Extending that first airline to all 38 stations with tax rules across seven jurisdictions, flight leg matching and cost analytics takes total spend to roughly $330,000 to $420,000.
Afterwards, infrastructure runs $300 to $900 a month and scales with ticket count rather than user count. A price index subscription is separate and not optional, and its terms differ by publisher, some pricing per user and some per application. Scanned ticket extraction carries a per document cost that is not zero at 14,000 tickets a month. Support and enhancement runs 12 to 18 percent of build cost annually, with tax rule maintenance budgeted apart from feature work.
What does the hybrid look like, and when is it the honest answer?
Buy the platform, build the thin layer you actually need. In aviation fuel this is usually the correct answer rather than a compromise, because the two halves of the problem have different owners. Contract libraries, invoice formats and schedule maintenance are commodity work a vendor should carry forever. Your ticket capture coverage, your flight numbering, your tax positions and your recomputation rules are yours and always will be.
The narrowest useful version is a ticket capture pipeline alone. It takes structured agent files, spreadsheets and scanned delivery tickets, and returns a structured uplift record with per field confidence scores and a review queue. That runs $35,000 to $60,000 over six to nine weeks. It audits nothing. What it does is turn unread paper into data your existing process can check, which in our experience surfaces enough recoverable error to fund the recomputation engine that follows.
The other discipline that keeps a hybrid honest is scope. Begin with the ten stations carrying most of your uplift, since they hold the most automated ticket data and the largest share of spend, so the recovery you prove there funds the rest internally. Accept manual entry for the tail rather than integrating a format for a station doing four uplifts a month. Keep tender management and hedge position reporting out of release one, because neither can be built well until the contract model has settled, and folding in a second department's data model turns a 14 week project into a 24 week one.
Which should you choose, by operator size and stage?
Two or three bases, posted price contracts. Buy FuelPlus or i6 Group and stop. Nothing about your operation justifies a build and it will stay that way for years. Document your mappings and move on.
Under 25 stations with some index pricing. Still buy, but do one thing first. Write your largest contract out as a specification and manually recompute a single month of invoices against it. That exercise costs a week and it either finds nothing, which settles the question, or it finds a pattern, which gives you a measured number rather than a suspicion.
Roughly 25 to 60 stations, several agents, scanned tickets in the mix. This is the crossover and the ticket capture pipeline usually goes first. Spend $35,000 to $60,000, get the paper into data, and let the exceptions it surfaces decide whether the recomputation engine is worth the next $90,000.
Above 60 stations, several tax jurisdictions, or route level cost as a planning requirement. Build the full first release beside whatever product you keep, then extend to the tax layer and flight leg matching. At this shape the money is not in efficiency, it is in supplier credits you can evidence and in fuel cost you can attribute, and neither arrives from a licence.
Whichever band you land in, run the recomputation against three months of already paid invoices before go live. It is cheap, it finds the errors in your own rules rather than the supplier's, and it produces the number that justifies the phase after.
When you are ready to turn this into a specification, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. Nothing about that commits you to the build.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- McKinsey reports that autonomous supply-chain planning can raise revenue up to 4%, reduce inventory up to 20%, and cut supply-chain costs up to 10% while maintaining service levels (the wider 20-30% inventory-reduction figure comes from McKinsey's separate distribution-operations research, not this page). Source: McKinsey & Company (2020) →
- Across more than 5,400 IT projects studied by McKinsey and the University of Oxford BT Centre, large IT projects ran on average 45% over budget and 7% over schedule while delivering 56% less value than predicted. Source: McKinsey & Company / University of Oxford (BT Centre for Major Programme Management) (2012) →
- SaaS spend averaged $4,830 per employee (up 21.9% year over year), with large enterprises (10,000+ employees) spending roughly $284M annually and running about 660 apps, while organizations wasted an average of $21M annually on unused licenses. Source: Zylo (2025) →
- 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) →
Frequently asked questions
What does it cost to switch off FuelPlus or i6 Group?
In the shape we usually recommend you do not switch. The recomputation and ticket capture layer sits beside the product, which keeps the contract library, the invoice formats and the schedule maintenance obligation.
If you do move, the real cost is not licence overlap, it is contract re-entry and history. Budget a parallel period where both systems process the same invoices, and confirm before you commit that you can export your contract configuration and your processed ticket history in a usable form rather than as reports.
What happens if our fuel software vendor raises prices or changes its terms?
Check whether your fees rise with fleet, stations or transaction volume, because a volume linked model means every station you add costs you more forever and your bargaining power falls as you grow. That structure matters more than the current number.
The structural protection is keeping the parts that are genuinely yours outside the product. If your contract rules, your ticket history and your tax positions live in a system you own, a vendor change becomes a procurement decision rather than a migration crisis.
How long does an aviation fuel build take?
Twelve to 18 weeks for a first release covering your highest volume stations end to end, then 8 to 14 months in total for network coverage, tax rules and analytics.
The schedule risk is rarely the recomputation engine. It is ticket format work, since each into plane agent produces something different, and it is getting your tax team to commit to a written position on exemptions and airport specific charges. That second one is a decision process and it does not compress with more developers.
Is FuelPlus enough for an airline uplifting at 40 stations?
For contract storage, invoice processing and the fuel management workflow, yes, and you should keep it. It knows the domain far better than a general spend tool and rebuilding that is a poor use of capital.
Where it strains at that size 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 tax team has taken all tend to land back in a spreadsheet. That spreadsheet is the specification for the layer worth building.
Can we build only the ticket capture pipeline?
Yes, and it is the fastest single return in this category. A pipeline that takes structured agent files, spreadsheets and scanned delivery tickets and returns a structured uplift record with per field confidence scores and a review queue runs $35,000 to $60,000 over six to nine weeks.
It audits nothing on its own. It turns unread paper into data your existing accounts payable process can check, which usually surfaces enough recoverable error to fund the recomputation engine that follows it.
Why does each into plane agent format add so much cost?
Because each one is a distinct piece of work rather than a configuration. Roughly $6,000 to $16,000 per agent, with a structured file on a schedule at the low end, a spreadsheet whose column order changes in the middle, and a scanned signed pad at the top because that is extraction and review rather than integration.
The first format costs more than the rest since it establishes the ingestion layer. Integrate the two or three agents covering most of your uplift, prove the pattern, then add the others as discrete line items you can approve individually.
Should hedge position reporting sit in the same system?
It can, and it should not be in release one. Hedge effectiveness reporting is a treasury discipline that happens to share a commodity with your fuel invoices, and it carries its own data model, approvals and audit expectations.
Scope it as a later phase once the uplift and cost data is trustworthy. Folding it into a first release reliably turns a 14 week project into a 24 week one without improving the invoice audit at all.
What is the cheapest credible version of this system?
Around $90,000 for an operator with two into plane agents sending structured files, no scanned tickets, a single contract structure and manual entry for outstation uplifts. That covers the contract model, independent price recomputation and the exception workflow, which is the part that recovers money.
Be sceptical of anything cheaper that claims to audit fuel. If a developer proposes a single quantity field on the ticket record, they have not done this, because the discrepancy you are hunting frequently lives in the volume to mass conversion rather than in the number itself.
What happens to my software if the agency shuts down or we stop working together?
Nothing dramatic, if the engagement was set up correctly: the code sits in your repository, hosting runs on your cloud account, and a handover document explains how to deploy and operate the system. Any competent replacement team can then take over in days rather than months. If the agency controls the repo, the servers, or the domain, fix that now, because renegotiating access during a dispute is the most expensive place to discover the problem.
Will custom software scale as we add warehouses, SKUs, and order volume?
Yes, if multi-location support and your target volumes are stated requirements at design time, because a schema built for one warehouse is expensive to retrofit for ten. A well-built system on PostgreSQL comfortably handles millions of SKUs and tens of thousands of orders per day on modest cloud hardware, so scaling cost shows up in hosting bills rather than rewrites. Give your agency the 3-year growth picture upfront even if phase one covers a single site.
Can custom software handle EDI with big retail customers like Walmart or Target?
Yes, and this is one of the most common reasons distributors go custom, because retailer scorecards penalize late or malformed documents. The typical build covers EDI 850 purchase orders in, 855 acknowledgments, 856 advance ship notices, and 810 invoices out, usually through a network like SPS Commerce or TrueCommerce rather than raw AS2. In Digital Heroes builds, onboarding your first major retailer adds 4 to 8 weeks and $10,000 to $25,000, with each additional trading partner far cheaper once the pipeline exists.
Should we start with an MVP or build the full supply chain platform at once?
Start with an MVP that fixes your single most expensive workflow, prove it in daily operations, then expand module by module. That gets working software onto the warehouse floor in about 12 weeks instead of debating a year-long spec, and real usage always reorders the roadmap; features that felt critical in planning routinely get cut after go-live. Digital Heroes typically scopes phase one at 30 to 40 percent of the total vision and lets measured results justify each next phase.
Why do companies replace generic SCM software with custom systems?
The usual trigger is workflow mismatch: generic SCM tools model a standard distributor, so anything unusual, like mixed lot and serial tracking, consignment inventory, or customer-specific routing rules, ends up managed in spreadsheets beside the system. Companies also leave when per-user pricing punishes growth or the vendor's API cannot support needed integrations. In Digital Heroes projects, the number of spreadsheets living around the official system is the most reliable signal a team has outgrown its off-the-shelf tool.
How much should a small business budget for its first custom app or website?
For a focused first build, most small businesses land between $8,000 and $60,000: roughly $8,000 to $45,000 for a custom website and $25,000 to $60,000 for an internal tool or simple web app, based on Digital Heroes delivery across 2,000+ projects. Customer-facing products with payments, logins, or a mobile app start around $40,000. Quotes far below these bands usually mean a template with your logo on it, not software shaped around your workflow.
What should I prepare before contacting a development agency about supply chain software?
Bring a written list of your workflows from purchase order to delivery, the systems each step touches, and the 3 to 5 pain points costing you the most hours or errors. Export a sample of your real data, SKUs, orders, and locations, because data shape drives half the design decisions. You do not need a formal spec; Digital Heroes scopes most supply chain projects from a two-page problem description plus screen-share walkthroughs of the current process.
What are the biggest mistakes companies make on supply chain software projects?
The top three: replacing every system at once instead of one workflow at a time, skipping data cleanup so the new system inherits years of bad SKUs and phantom stock, and designing screens without the warehouse staff who will use them daily. A fourth is underscoping integrations and discovering mid-project that the ERP connection is half the work. Digital Heroes sees more supply chain projects fail from scope and data problems than from any technical cause.
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.
Related guides
More from Noah.
Senior Android Engineer · APAC · Sydney · 2 posts on the site
Published · Last updated .
