Dave dispatches for a fuel wholesaler in East Texas.
When I sat with him for the first time and asked about their delivery fee structure, he gave me the same answer I have heard from almost every dispatcher I have met.
“We charge a flat rate. Pretty straightforward.”
Then I asked what happens after hours.
“Oh, that is different.”
What about weekends?
“Different rate.”
Emergency deliveries?
“That depends on the customer.”
What if the load is under a certain gallon threshold?
He paused.
“That one is complicated. We handle it case by case.”
By the end of that conversation, what started as one flat rate had become seven distinct scenarios. Some of them lived in Dave’s head. Some of them lived in a spreadsheet the billing manager maintained. Some of them lived in email threads between the owner and specific customers that nobody else had read.
The fee was not complicated because the operation was disorganized. It was complicated because the operation was real.
Which fee wins
The hardest part of Dave’s fee structure was not calculating each fee in isolation.
It was deciding which fee should win when multiple conditions were true at the same time.
A customer called on Sunday morning requesting 300 gallons immediately. Three fee conditions applied simultaneously: the weekend rate, the emergency delivery rate, and the minimum-delivery charge for loads under a certain gallon threshold.
Should the customer pay all three? Should the emergency rate replace the weekend rate? Should the minimum-delivery charge still apply if the emergency rate already accounts for the short load? And what if that customer had a negotiated agreement that overrode the standard rates entirely?
Dave knew the answer. He had handled that customer before. But the system did not know. Billing had to call Dave every time a similar situation came up to make sure the invoice reflected the right decision.
That decision should be configured once and applied automatically. Not reconstructed by billing after every delivery.
Joey’s construction site
Joey runs a wet hosing operation out of San Antonio.
His drivers fuel construction sites, data centers, equipment rental yards, and generator accounts across Central Texas.
I went out on a delivery with one of Joey’s drivers on a Tuesday morning. A construction site in the Hill Country. When we pulled in, the site manager walked the driver through the equipment that needed fuel.
Eighteen pieces of equipment. Three generators. Two light towers. One machine that required a supervisor to unlock before the driver could access it. Two pieces of equipment that had been moved since the dispatch record was created and took twenty minutes to locate.
The driver was on-site for over two hours. He delivered 640 gallons.
On a per-gallon basis that delivery looked marginal. On an actual cost basis, accounting for driver time, truck time, and the complexity of the stop, the economics were different.
But the invoice that went out showed one line.
Diesel. 640 gallons. $X.
The fee structure did not reflect the work. Whether that complexity should have been billed separately depended on the customer agreement. But Joey had no reliable way to measure it, price it, or determine whether the account was still profitable.
A controller needs to know whether the margin on a wet hosing account reflects what actually happens at the stop. Without capturing time on-site, assets fueled, and stop complexity, that calculation is always an estimate.
Why the spreadsheet survives
Every fuel operation I have visited has a version of the same document.
It lives in billing. Sometimes in dispatch. Sometimes in a shared folder with a name like Fee Exceptions or Customer Agreements or Do Not Change This.
It is the bridge between what the software calculates and what the customer was actually promised.
It works because the person who maintains it is experienced enough to know which rule applies in which situation. They have been doing it long enough that the exceptions feel like routine.
The problem is not the spreadsheet. The problem is what happens when the person maintaining it leaves, or gets sick, or the operation grows past the point where one person can hold it all together.
That is when charges start slipping through. Not because anyone is careless. Because the rules were never in the system.
If any of this sounds familiar in your operation, I would like to hear about it.
Every issue of The Fuel Stack starts with a conversation. If you want to talk through your fee structure, your billing workflow, or anything else that is quietly costing you margin, book a time directly.
Juan’s margin problem
Juan manages operations at a Southern California-based fuel distributor.
California adds its own layer of complexity to fuel fees. Environmental fees. Regulatory surcharges. Carrier costs that vary by route, by terminal, by time of day. Pass-through charges from carriers that have to be billed to the customer with a margin applied.
When I sat with Juan and his controller, we pulled up six months of carrier invoices.
The carrier had billed detention charges on fourteen loads over that period. Terminal delays, site access issues, customers who were not ready when the truck arrived.
Juan’s team had paid every one of those invoices.
Eight of the fourteen had been passed through to the customer. Six had not. Not because anyone decided to absorb the cost. Because by the time the carrier invoice arrived, the customer invoice had already gone out. The charge landed in accounts payable. Nobody connected it to accounts receivable.
Roughly $2,200 in legitimate pass-through charges that never made it to the customer. Not because the fee was wrong. Because AP and AR were not connected.
A controller should be able to run a report showing every carrier fee received, whether it was passed through, the amount billed to the customer, and the margin recovered. If that requires manually comparing AP and AR, the leakage will remain invisible until someone goes looking for it.
Across a full year, Juan estimated the leakage was significantly larger than anyone had realized before we sat down and looked at it together.
The fee that is also a decision
A delivery fee is not just a number. It is a record of a decision.
When did the order come in? When was it dispatched? What did the driver encounter on-site? What did the customer agree to? What did the carrier charge? Who approved the exception?
Every one of those questions has an answer. In most fuel operations, the answers live in different places and nobody connects them before the invoice goes out.
The software calculates one thing. Billing knows it is wrong. Someone fixes it manually. Sometimes the fix makes it to the invoice. Sometimes it does not.
That gap, between what the system calculates and what the operation actually did, is where margin leaks. Not dramatically. Quietly. Across dozens of deliveries and months that close before anyone looks closely at the pattern.
What the right system actually does
The answer is not simply a larger fee table with more rows.
The answer is a system that understands the operation well enough to apply the right rule at the right time without asking billing to remember it.
When Dave dispatches an after-hours emergency delivery to a customer with a negotiated rate that overrides the standard weekend fee, the system should know that. Not because Dave told it just now. Because the customer agreement was captured at account setup and applied automatically when the conditions are met.
When Joey’s driver leaves a construction site after fueling eighteen assets over two hours, the delivery record should carry that information. The number of assets. The time on-site. The equipment that required extra coordination. Whether the fee structure accounts for that complexity should reflect the customer agreement. But the data to make that decision should exist and be visible.
When Juan’s carrier invoices detention charges, the system should surface them alongside the customer invoice for that load. Not buried in an AP queue that nobody connects to AR. Visible. Reconcilable. Billable.
The fee on the invoice should be the last step of a connected workflow. Not the first place someone tries to figure out what the customer owes.
The question worth asking this week
Pull three of your most complex deliveries from last month.
For each one, ask: does the fee on the invoice reflect what actually happened at that stop?
The driver time. The assets fueled. The hour of the day. The customer agreement that applied. The carrier charge that was passed through or should have been.
If answering that question requires opening a spreadsheet, calling the dispatcher, or asking the billing manager to remember, the fee structure in your operation is living outside your system.
And what lives outside your system does not always make it to the invoice.
The names in this article have been changed. The problems have not.
I run ops at a produce distributor, and the spreadsheet you describe is on our shared drive too. Different product, same file.
Ours is the delivery minimum. A store orders under it, but the truck drives past that store anyway, so somebody says fine, just this once. That is a good call the first time.
Then it goes on the list. And nothing ever comes off the list. The route changes. The store moves to a different day. The guy who made the call gets promoted. The exception is still there, three years later, and now nobody can tell you why.
So my rule now is that every exception gets a reason and a date to look at it again. Not an end date. Just a day somebody has to ask if it still makes sense. Most of them do not survive the question.
In the fuel shops you sit with, does anybody ever clean out that file? Or does it only grow?