The ERP That Was Supposed to Fix Everything and Didn't
The most expensive software decision a fuel distributor makes is rarely the one that goes wrong. It's the one that almost works.
Lisa didn’t set out to spend nine months of her life in implementation meetings.
She runs operations for a petroleum distributor in the Midwest. Around $120M in annual fuel volume. Eighteen trucks. Customers across three states. She has been in fuel distribution for fourteen years and there is not much about the business she hasn’t seen.
Three years ago she made the biggest technology decision of her career.
She bought an ERP.
The demo that started everything
The vendor flew in on a Tuesday. Two people. A sales rep who knew the right vocabulary and a solutions engineer who ran the demo.
They had done their homework. They knew the pain before Lisa said it out loud. Invoices going out late because dispatch and billing ran on different systems. Inventory that never reconciled cleanly at month-end. AP matching that lived in a spreadsheet nobody fully understood except the person who built it.
The demo showed all of it working. Dispatch closing a load and billing triggering automatically. Inventory updating in real time as the driver confirmed delivery. AP matching running against the BOL without anyone touching a keyboard.
Lisa asked about rack-based pricing. The solutions engineer pulled up a configuration screen. It looked right.
She asked about gross to net gallon conversion. He said the system handled it.
She asked if they had other fuel distributor customers. The sales rep named three.
Six weeks later she signed the contract. Five months. $180,000. The budget covered licensing, implementation, data migration, and three months of consultant time. For a $120M distributor it was aggressive but not unusual.
She felt good about it.
Month one: the first gap
The implementation kicked off with an onsite visit. Two consultants, three days, a conference room full of whiteboards.
Day one went well. System architecture. Data migration planning. User roles and permissions. The consultants were organized and Lisa’s team was engaged.
Day two is when the first gap showed up.
The pricing configuration session. Lisa’s team walked through their pricing structures. Rack plus margin. Contract basis with monthly resets. Tiered volume pricing for their largest fleet accounts. Split billing for customers with multiple delivery sites.
The consultants got through rack plus margin cleanly. Then they hit contract basis.
The system assumed pricing was set when the order was entered.
In Lisa’s operation, pricing wasn’t finalized until dispatch.
A load scheduled at 8:00 AM might lift from a different terminal than originally planned. The rack posting might have changed since the order was entered. A contract customer might be priced off OPIS plus basis, while another customer on the same truck was priced rack plus margin.
The system wanted one price decision.
Fuel operations required several.
The consultant looked at his laptop for a long moment.
“We can handle that with a workaround.”
Lisa wrote it down. First workaround. Day two of the implementation.
The moment Lisa knew
The moment Lisa realized the project was in trouble wasn’t when the timeline slipped.
It wasn’t when the budget started growing.
It was when her team began maintaining the old spreadsheets and the new ERP at the same time.
The pricing spreadsheet stayed open.
The inventory spreadsheet stayed open.
The AP reconciliation spreadsheet stayed open.
Every ERP implementation has a moment like this.The moment the business quietly admits it does not trust the new system enough to let go of the old process.
Month two: the list grows
By the end of the second month Lisa had a document on her laptop titled “Open Items.” It had twenty-three line items.
The BOL workflow required a manual step because the system assumed deliveries were confirmed by the back office, not by the driver at the point of delivery. Workaround.
The inventory reconciliation still ran nightly instead of in real time.
A transport truck could pull 8,500 gallons from one terminal before breakfast and another 7,000 gallons from a different terminal before lunch. The operation knew those gallons had moved. The system wouldn’t know until overnight processing completed. Workaround.
The AP matching module imported supplier invoices correctly but treated nearly every terminal invoice as an exception.
The supplier billed net gallons. The BOL captured gross gallons. Temperature correction created a variance on almost every load. The software saw a mismatch. The AP team saw normal fuel operations.
Every invoice had to be reviewed manually before payment could be approved. Workaround.
The implementation team was responsive. They showed up to every call. They documented everything Lisa raised. They found creative configurations for problems the system was never designed to solve.
But every workaround created friction somewhere else.
Fixing the BOL confirmation step broke the automatic billing trigger. Fixing the billing trigger required a manual approval step that slowed invoicing down. Fixing the invoicing speed required removing an audit control Lisa’s CFO wanted kept.
The implementation team wasn’t cutting corners. They were building a house of cards, one workaround at a time, on a foundation that was never designed for fuel distribution.
Month four: the budget conversation
The original five-month timeline had slipped to eight. The original $180,000 budget had grown to $240,000. A 33% overrun. Painful but, as Lisa would later find out, not unusual for an implementation of this complexity.
Lisa had to walk into her CFO’s office and explain why.
That was the hardest conversation of the implementation.
She had championed this decision. She had sold it to leadership with a business case that showed the system paying for itself in eighteen months through reduced billing errors, faster invoicing, and cleaner inventory reconciliation. Now she was asking for more time and more money with a system that still wasn’t live.
Her CFO approved it. But the question he asked at the end of the meeting stayed with her.
“Is this going to work, or are we throwing good money after bad?”
Lisa said it was going to work. She believed it when she said it.
She was also aware, for the first time, that she might be wrong.
Month seven: go-live
The system went live seven months after the implementation started. Three months late. Sixty thousand dollars over budget.
The go-live weekend was rough. Three critical workflows broke within the first 24 hours. Lisa’s team worked through Saturday night. The implementation consultants were on a call from 11pm to 3am walking through fixes.
By Monday morning the system was stable enough to run the operation.
Not clean. Stable.
Lisa sent an all-staff email saying the implementation was complete and thanking her team for their patience. She meant every word. Her team had absorbed seven months of disruption on top of their regular jobs without complaint.
What she didn’t say in the email was that fourteen of the twenty-three open items were still open.
The AP matching module still required manual clearing for every BOL with a gross to net variance. The inventory reconciliation still ran nightly instead of in real time. The spreadsheet her predecessor had built was still open on the AP manager’s second monitor because the system couldn’t handle three of their largest supplier invoices without manual intervention.
The system was live. The operation looked almost exactly like it did before. Just with a new interface on top of it.
Eighteen months later
I talked to Lisa eighteen months after go-live.
The system had settled into the operation. Her team used it for order entry, customer invoicing, and basic financial reporting. Those parts worked and genuinely saved time.
The dispatch-to-billing automation that was the centerpiece of the original business case still required a manual step. The inventory reconciliation still ran nightly. The AP matching still had a spreadsheet running alongside it.
She had stopped counting the open items. At some point during the first year she had closed the document on her laptop and accepted that this was what the implementation had delivered.
I asked her what she would do differently.
She thought about it for a moment.
“I would have asked them to show me rack pricing working in a live environment with real data before I signed anything. Not a demo environment. Their actual system, configured for a distributor like us, running real loads.”
She paused.
“And I would have asked the implementation team what the system couldn’t do. Not the sales rep. The people who were actually going to build it.”
Two questions. Asked before the contract was signed. That is the distance between the implementation she got and the one she needed.
Why this keeps happening
Lisa’s story is not unusual. It is the pattern.
Software vendors sell to the optimistic version of what their system can do. Implementation teams inherit the gap between that optimism and reality. Operators absorb the cost of that gap in internal time, parallel workflows, and organizational exhaustion that never shows up on any report.
According to Gartner, more than 70% of ERP implementations will fail to meet their original business case goals. As many as 25% will fail catastrophically.
In fuel distribution that number feels low. Because the workflow complexity here is higher than almost any other industry the generic ERP was built for. And the cost of getting it wrong shows up directly. In your DSO. In your inventory variance. In your AP leakage. In the spreadsheet still running on your AP manager’s second monitor eighteen months after go-live.
What due diligence actually looks like
Before the next software evaluation, three things are worth doing that most operators skip.
Talk to a current customer who runs the same operation. Not a reference the vendor provides. A customer you find independently, who runs a similar operation at a similar scale, and who will tell you honestly what the system handles natively and what they work around.
Run a pilot on your actual workflow. Not a demo. Not a sandbox. Your loads, your pricing structures, your BOL workflow, your AP matching. If the vendor won’t support a real pilot before contract signature, that is the answer.
Ask the implementation team, not the sales team, what the system cannot do. Implementation teams are closer to the reality of what gets configured versus what works out of the box. They will tell you things the sales rep won’t.
Lisa wishes she had done all three before she signed. She didn’t because the demo was convincing, the timeline felt urgent, and the sales rep said yes.
Two years later the spreadsheet is still open on the AP manager’s monitor.
The question worth asking before the next contract
Find the workflow most specific to your operation. For a fuel distributor running rack-based pricing, that is price-at-dispatch. For a common carrier, that is carrier settlements. For a wet hose operator, that is delivery reconciliation.
Ask the vendor to demo that workflow specifically. In a live environment. With data that looks like yours. Before you sign anything.
“We can handle that with a workaround” is not yes.
It is the first line item on an Open Items document that is going to have twenty-three entries by month two.
Next issue: Inventory variance. The slow leak most fuel ops managers stop looking for.
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.