The Rack Price Was Wrong. You Didn't Find Out Until the Customer Called.
Pricing errors in fuel distribution don't announce themselves. They wait.
Pricing disputes are not rare in fuel distribution.
Ask any Ops Director how often a customer calls about an invoice and the answer is usually some version of “more than it should be.” Ask how often the customer is right and the answer gets quieter.
The problem isn’t that fuel distributors are careless about pricing. Most are meticulous. They have contract rates, tier structures, rack-based formulas, seasonal adjustments. The people managing pricing know what they’re doing.
The problem is that pricing in fuel distribution is a moving target. And the systems most distributors use weren’t built to hit a moving target reliably.
How fuel pricing actually works at a mid-market distributor
Most customers aren’t on a flat rate.
They’re on a formula.
Rack plus a margin.
Cost plus a markup.
A tiered structure based on volume.
A contract rate that resets monthly.
Rack price is not a simple once-a-morning update. Supplier postings, rack reports, and effective pricing windows do not always line up cleanly with how dispatch, delivery, and billing teams close the day.
Rack data may already exist in a feed, report, email, API, or pricing platform. The breakdown usually happens after that, when the rate has to move through customer-specific rules, delivery timing, contract terms, and billing.
If your system only refreshes once a day, your billing team may be working with a price that is current for one delivery, pending for another, and stale for the next.
A driver makes a delivery at 2pm. Later that afternoon, a new rack posting comes in for the next pricing cycle. Your billing system has not refreshed yet, and nobody is completely sure whether the delivery should be priced against the prior rack, the new posting, or a customer-specific rule tied to the invoice date. The invoice goes out at the wrong price. Not because anyone made a mistake. Because the timing of how rack price moves in this industry doesn’t match the timing of how most billing systems consume it.
That’s the structural problem. It’s not a human error. It’s a workflow that was never designed around how rack actually works.
The three places pricing breaks down
Every pricing failure usually has a missing control field behind it: effective date, expiration date, pricing basis, tier threshold, contract ID, rack source, or override rule.
Rack timing is one failure point. It's not the only one.
The contract rate that wasn't updated. A customer negotiated a new rate in January. Someone updated the contract file. Nobody updated the billing system. For six weeks, invoices went out at the old rate. The customer paid without saying anything because the new rate was lower and they assumed it was right. You found out during a quarterly review. You issued credits. You never calculated the total cost of that six-week gap.
The tier that tripped at the wrong volume
A customer is on a tiered structure. Under 5,000 gallons a month they pay one rate. Over 5,000 they pay another. They crossed the threshold mid-month. The system didn't catch it. The invoice went out at the higher rate. The customer called on day 31, three days after payment was due, to say they weren't paying until it was corrected.
The special price that expired.
You ran a promotional rate for a customer during a slow season. The promotion ended. Someone forgot to revert the pricing. Three months later a new billing clerk notices the account is still on the promotional rate. You’ve undercharged by $4,200. You write it off because going back to the customer feels worse than absorbing the loss.
None of these are catastrophic in isolation. Together, across a book of 200 accounts with varying contract structures, they represent a quiet and continuous margin bleed that almost nobody is measuring.
Why it's hard to catch
Pricing errors in fuel distribution have a structural camouflage problem.
Customers who are overcharged call. Customers who are undercharged usually don’t. So your error detection system is asymmetric. You catch the errors that cost you customer relationships. You miss the errors that cost you margin.
Your billing team is processing volume. They’re not auditing every invoice against every contract on every delivery. That’s not a criticism of your billing team. That’s just the reality of running billing at scale with manual processes. You can’t catch what you’re not set up to look for.
And the errors that do surface often get resolved individually without anyone asking why they happened or how many similar errors are sitting undetected in the rest of the book.
A customer calls about a pricing dispute. Your AR team investigates, finds the error, issues a credit, and closes the ticket. That resolution takes 45 minutes. Nobody looks at whether the same pricing logic produced errors on 12 other accounts that haven’t called yet.
What the margin bleed actually looks like over a year
This is harder to put a precise number on because it varies by contract complexity and volume. But here’s a conservative frame. This is not an industry benchmark. It is a simple model to size the problem.
A mid-market distributor with 200 active accounts, averaging 15 deliveries per account per month, is running 3,000 invoices a month. If pricing errors affect 2% of invoices, that’s 60 errors a month. At an average error value of $40 per invoice, that’s $2,400 a month in pricing variance. Some in your favor, some against you, and the ones against you are often harder to see until a customer calls.
$28,800 a year. Conservative. At a distributor running tighter margins on commodity product, that’s not noise. That’s a line item.
And that’s before you factor in the customer relationship cost of the disputes you did catch. The accounts that went slow on payment because of a billing dispute. The customer who switched suppliers after the third pricing error in two months. That math is harder to run, but the number is big
What clean pricing actually requires
The distributors who run tight on pricing have solved two things that most haven’t.
First, rack price flows into billing automatically. There’s no manual update step. The formula runs against the correct rack based on the pricing rule, effective date, delivery timing, and customer agreement. When rack moves, pricing moves with it. The human is out of the loop on that specific step.
Second, contract rates live in one place. Not in a spreadsheet that someone maintains separately from the billing system. Not in a filing cabinet with a note taped to the monitor. The contract rate is in the system, it has an effective date and an expiration date, and billing pulls from it directly. When a rate changes, it changes once, in one place, and every subsequent invoice reflects it.
Neither of these is technically complex. Both require discipline about where pricing data lives and how it flows into the billing process. Most distributors haven’t done it because the current process mostly works, most of the time, and the errors that slip through are handled one at a time as they surface.
The problem with that approach is that you’re only seeing the errors that announce themselves. The rest are sitting quietly in your margin.
The question to ask this week
Pull five invoices from last month at random. For each one, trace the pricing back to its source.
Where did that rate come from?
Which rack or contract was used?
What date controlled the price?
When was it last updated?
Is it the rate that should have applied on that delivery date?
If you can’t answer that question cleanly for all five, you have a pricing integrity problem. And the cost of it is somewhere in your margin right now, waiting for a customer to call.
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.


