Fuel Distributors Don't Have a Software Problem. They Have a Workflow Problem.
Why fuel software often fails after go-live, why the spreadsheets come back, and what clean operators do differently.
I’ve heard some version of this story more times than I can count.
A fuel distributor hits a wall. Invoices going out late. Dispatch running on a whiteboard and three group texts. Inventory that hasn’t reconciled cleanly in two quarters. Leadership decides to fix it. A software vendor gets selected. A contract gets signed.
Twelve months later, the system is live. It does some things better. But the billing clerk is still waiting for dispatch to close loads before she can run invoices. The dispatcher is still calling drivers to confirm deliveries. The spreadsheet that tracks AP exceptions is still open on someone’s second monitor.
The software got implemented. The workflow didn’t change. And in fuel distribution, unchanged workflow almost always means the same bottlenecks return under a new login screen.
That’s not bad luck. It’s a pattern.
This is not just a fuel industry problem
Before blaming the distributor or the software, it’s worth being honest about the broader context.
Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals. As many as 25% of those will fail catastrophically.
That's not a fuel industry number. That's across all industries, all company sizes, all software vendors.
But it matters especially in fuel distribution because most operators are not implementing software with unlimited budget, unlimited internal staff, or a full-time transformation office. They are doing it while trucks still have to roll, drivers still need routes, customers still need fuel, and invoices still need to go out.
Those numbers should reframe how you think about your own history with software. If you tried a system and it didn’t deliver what was promised, you were not in the minority. You were in the majority.
The question worth asking is not “why did the software fail?”
It’s this:
“why does software keep failing at the same point?”
What actually happens during a fuel software implementation
Most implementations in fuel distribution follow the same arc.
A vendor gets selected based on a demo that shows the system doing everything cleanly. The implementation starts. And here is where the pattern sets in.
The natural inclination is to configure the new software to match existing workflows as closely as possible. This feels safe. It minimizes disruption. Everyone already knows how things work.
So the software gets bent around old handoffs, old approvals, and old exception paths instead of forcing the company to agree on a cleaner operating sequence.
The dispatcher has been closing loads the same way for nine years. The billing clerk knows which accounts need special handling and why. The ops manager has a spreadsheet tracking exceptions the system can’t handle. Rather than redesign those workflows, the implementation team builds workarounds to preserve them.
Six months after go-live, the system is live.
The spreadsheets came back.
Not because people resisted change. Because the system was configured around gaps it was never asked to close.
Research on mid-market ERP implementations puts it plainly: failures rarely occur because the software cannot perform required functions. They occur because the organization did not align on how it wanted to operate, how decisions would be made, or how much internal effort the change would require.
That sentence is the whole article, really.
Why fuel workflows are harder to automate than most
This is worth saying clearly because the failure of software in fuel distribution is not entirely the software’s fault.
Fuel distribution workflows are operationally specific in ways that generic software doesn’t anticipate and industry software often underestimates.
Pricing changes intraday. The rack for next day starts coming in late afternoon. Mid-day changes can take up to 24 hours to propagate. That means a delivery at 10am and a delivery at 3pm on the same day can legitimately carry different rack-based prices. Your billing system needs to know which rack applied to which delivery at which time. Most systems don’t handle that automatically. A human fills the gap.
Inventory exists in multiple states simultaneously. Product in a terminal. Product in a truck compartment. Product dispatched but not yet delivered. Product delivered but not yet confirmed in the system. Each state needs to be tracked and reconciled against physical counts that happen on a different schedule. Manual processes in this environment compound errors at every handoff.
Customer pricing is not simple. Contract rates, volume tiers, seasonal adjustments, promotional rates, split billing for fleet accounts, tax exemptions by delivery site. A mid-market distributor with 200 active accounts might be managing 40 distinct pricing configurations across that book. A generic ERP handles none of that out of the box.
Dispatch is dynamic in ways that break linear workflow assumptions. Routes change mid-day. Loads get split. A driver scheduled for three stops ends up doing five because a customer called in a same-day order. As one Texas fuel distributor put it: “Manual worked for us when we did 20 deliveries a day. Now we do hundreds and need a real solution.”
A generic system may support order entry and inventory balances, yet fail completely at the workflows where fuel operations actually live and die.
Take one simple delivery.
A customer places an order in the morning. The price depends on the correct rack, the correct product, the correct customer agreement, and sometimes the correct delivery site. Dispatch assigns the order. The driver pulls from the terminal. A BOL is generated. The product moves into the truck, then to the customer site. The driver captures the delivery ticket. Billing waits for the load to be closed. AP later receives the supplier invoice. Someone eventually has to match the supplier cost, the BOL, the delivered gallons, and the customer invoice.
If any one of those steps lives outside the system, the workflow is no longer automated. It is just partially digitized.
That is where spreadsheets come back.
The implementation trauma is real and rational
There’s a layer to this that doesn’t get discussed enough in vendor conversations.
Most mid-market fuel distributors have been through at least one software implementation that didn’t deliver what was promised. Some have been through two or three. That history creates a specific kind of skepticism that is completely rational given the evidence.
The ops director who says “we tried that before and it didn’t work” isn’t being difficult. She’s pattern-matching on real experience. The last system required six months of implementation, two outside consultants, and a data migration that scrambled three years of customer pricing history. It went live and immediately created more exceptions than it handled. Her team spent the following year working around it.
That skepticism is not irrational. It is earned.
When the next vendor shows up promising to fix everything, her default position is disbelief. Not because she doesn’t want things to improve. Because she’s been promised better before and she’s still cleaning up the aftermath.
The most expensive mistake isn’t technical. It’s treating a workflow transformation like a software purchase.
That cuts both ways. The buyer who treats it like a software purchase gets the outcome they paid for. The vendor who sells it like a software purchase deserves the outcome they delivered.
The workflow problem underneath the software problem
Here is the thesis, stated plainly.
Most fuel distribution software fails not because it’s bad software, but because it gets implemented on top of a broken workflow instead of replacing the broken workflow.
The billing delay problem is not solved by giving the billing clerk a faster interface. It’s solved by eliminating the handoffs between delivery confirmation and invoice generation. The ticket becomes the delivery record. The delivery record becomes the invoice. That sequence has to be automated, not accelerated.
The inventory variance problem is not solved by a better reporting dashboard. It’s solved by capturing inventory state at every point of movement in real time, so the variance is visible before it becomes a month-end reconciliation problem.
The pricing error problem is not solved by a more flexible contract management module. It’s solved by making rack price flow automatically into billing at the correct timestamp, and making contract rates live in one authoritative place that billing pulls from directly. No manual update step. No spreadsheet maintained by one person.
In each case, the fix is a workflow change that software enables. Not software layered on top of a workflow that doesn’t change.
The single biggest factor separating successful implementations from disappointing ones is the willingness to change processes, not just the tools sitting on top of them.
What a workflow-first implementation actually looks like
The distributors running clean operations didn’t just buy better software. They redesigned the sequence first.
They started with one question: what is the right workflow, and what does software need to do to make that workflow possible?
Not: how do we configure this software to match what we’re already doing?
That reframe changes everything. It means the dispatcher has to change how she closes loads, because the new sequence requires it. It means the driver has to confirm deliveries at the truck, because billing can’t wait for end of shift. It means contract rates have to be fully migrated into the system before go-live, because the system is going to own that data from day one.
It’s harder. It takes longer. It requires the organization to actually change behavior, not just adopt a new interface.
But it’s the only implementation that sticks.
Because it changes the workflow, not just the tool sitting on top of it.
The question worth asking before the next implementation
If you’re evaluating software right now, one question cuts through most of the vendor noise:
Does this system change my workflow, or does it adapt to my existing one?
If the answer is "we'll configure it to match how you work today," listen carefully. That may sound comforting, but it often means the old workflow is being preserved with a new interface.
The right answer is harder to hear:
“Here’s the workflow this system requires, here’s why it’s better than what you’re doing today, and here’s what your team will need to change to make it work.”
That conversation is uncomfortable.
It’s also the only one that leads somewhere different from where you’ve already been.
Next issue: What 3-way match looks like at a $100M fuel distributor. Spoiler: it’s a spreadsheet.
About the author
I’m Dibyesh Giri, founder of Fueleo. I spend my time working with fuel marketers on the messy handoffs between pricing, dispatch, delivery, BOLs, invoicing, and accounting. This newsletter is where I write about the operational problems hiding inside everyday fuel workflows.