Let me tell you about something I have seen more than once.

A driver loads 4,000 gallons at the terminal in the morning. Runs his deliveries. Comes back to the yard at the end of the day with 240 gallons still in the tank. Pumps it into bulk storage. Goes home.

The physical movement is simple.

4,000 gallons loaded. 3,760 gallons delivered. 240 gallons returned to bulk storage.

Every gallon is physically accounted for.

But the system recorded the terminal load and the customer deliveries. Nobody recorded the return to the bulk tank.

So the system still shows 240 gallons on the truck. The person at the plant counts those same 240 gallons in storage.

The fuel did not go anywhere.

It just exists in two places at once.

That is the inventory problem I keep seeing in fuel distribution. Not theft. Not careless drivers. Not broken meters.

A movement happened. The system never saw it.

Fuel does not move in a straight line

From inside the office, a fuel delivery looks simple.

Lift at the terminal. Drive to the customer. Drop the product. Done.

That is the clean version.

Here is what a real day often looks like.

A transport lifts 8,500 gallons and brings it back to the bulk plant. Three smaller trucks load from the plant. One comes back with 300 gallons left over and pumps it back into storage. Another driver finds the customer’s tank fuller than expected and adjusts the drop. A third driver is not sure his meter read correctly on the third stop.

Every one of those things changed where the fuel was. What it cost. Which ticket it traced back to.

But most inventory systems just see this:

Beginning inventory plus what came in minus what went out equals what is left.

That math is correct. But it misses everything that happened in the middle.

The missing movement becomes a mystery number

When a return or a transfer does not get recorded, it does not show up immediately.

It shows up at month-end as a variance.

More fuel than expected in one place. A shortage somewhere else. Someone labels it shrink or meter error, edits the balance until the numbers agree, and closes out the month.

The report looks clean. Nobody knows what actually happened.

And the problem does not stop at inventory.

If the system thinks the fuel is still on the truck, dispatch might send that driver on another load without enough product. If a return gets counted as a fresh receipt, the same gallons appear twice. If a transfer loses its connection to the original purchase, the cost on the next delivery is wrong.

That flows into customer margins, cost of goods, and sometimes what gets reported for taxes.

By the time someone notices the number is off, the driver who handled that load is trying to remember a shift from three weeks ago.

That is not reconciliation. That is guessing with extra steps.

A balance only tells you one thing

An inventory balance answers one question.

How much fuel should be here right now?

It cannot tell you where the fuel came from. Which truck carried it. Whether the transfer actually made it to the other end. Which BOL supplied the gallons. Whether the difference was measured or estimated. Who touched it and when.

For that you need a movement record.

Every time fuel changes location, something should capture where it started, where it ended up, how many gallons, which product, when it happened, and what paperwork supports it.

The balance should be built from those movements. Not a number someone can edit when the count does not match.

Transfers need two sides

This is where a lot of records fall apart.

A transport unloads 8,000 gallons into the bulk tank. The truck meter says 8,000. The plant meter says 7,980.

The wrong move is to pick one number and overwrite the other.

Both readings matter.

The record should show 8,000 gallons left the truck and 7,980 arrived at the tank. The 20-gallon difference needs a reason. Until that receiving side is confirmed, those gallons should show as in transit. They should not appear in both places at the same time.

Same goes for fuel moving from a bulk tank to a smaller truck. From one compartment to another. From a driver back to the plant at the end of the day.

One movement. Two sides. Both numbers kept.

The driver’s job is to say what happened. Not to sort out the accounting.

Drivers work fast. They have more stops waiting.

What a driver needs to record is simple.

Loaded 2,000 gallons. Delivered 1,760. Brought back 220. Meter seemed off on the third stop.

That is enough.

The driver should not be figuring out which cost applies to the returned product or how a variance hits the books. That is a back office conversation.

This also matters when the driver is working in an area with no signal. The delivery still needs to be recorded at the right time, tied to the right stop. When the app reconnects, it should sync once. Not create duplicate records.

Month-end should not be the first time you ask where the gallons went

Most operations I visit reconcile inventory once a month.

Someone runs a report. The numbers are off. Adjustments get made. The books close.

A better version happens at the end of every shift.

What came in, what went out, what moved between locations, what came back to the yard. Compare that to the physical reading. If the difference is small and within what you would expect, the shift closes. If it is not, you look at the movements while the day is still fresh.

The driver is still reachable. The terminal BOL is still findable. The return that did not get logged is still in someone’s memory.

Catching a small problem at 5pm costs fifteen minutes. Finding the same problem at month-end costs four days and a lot of guessing.

Three questions worth being able to answer

Fuel inventory is never going to be perfectly clean. Meters differ. Drivers work offline. BOLs arrive late. Product moves between trucks and tanks in ways the office does not see in real time.

That is just the nature of the business.

But if you run a fuel operation, you should be able to answer three questions about any load on any given day.

Where is the fuel right now?

What moved it there?

Can you trace it back to where it started?

If the only way to answer those questions is to edit a number until it looks right, you do not have inventory reconciliation.

You have a new number and the same question you started with.

A few months ago I was sitting with a dispatcher at a mid-sized fuel operation.

She pulled up the tank monitoring screen. Forty-some sites. Every tank had a live reading. Product level, available gallons, last update time. Most had been reporting through the night.

It looked exactly like the kind of visibility software vendors put on the cover of a brochure.

I asked her how she used it.

“I check it when somebody calls worried they’re going to run out.”

That was the whole answer.

The data was there every hour, for every tank. But it was not deciding which sites got a load tomorrow. It was not telling her which stops belonged on the same truck. It was not flagging which customer was going to call at 8am before the customer knew they needed to call.

Those decisions still came from standing orders, experience, and whoever picked up the phone first.

The ATG was being used like a thermometer. You looked at it when you already suspected something was wrong.

She was not doing anything wrong. That is what makes this interesting.

What the data actually tells you versus what you need to know

A tank at 37% is a fact.

But a dispatcher does not need a fact. She needs an answer to a different question.

When will this become a problem?

A tank at 37% burning 120 gallons a day is fine. The same tank burning 900 gallons a day needs to be on tomorrow’s board. And that same tank might behave completely differently on Tuesday than it does on Saturday when the customer’s crew is running double shifts.

The percentage is just the starting point.

What you actually need is the tank level, the consumption rate, the delivery constraints, the truck capacity, and what else is already scheduled in that area.

A 37% reading does not tell you when to send a truck. It tells you where to start looking.

Why the data dies before it reaches dispatch

I keep seeing the same gap across fuel operations. The tank is connected. The readings are coming in. And none of it is making its way into the dispatch decision.

Here is why.

The monitoring system knows: Tank 3. ULSD. 31%. 2,480 gallons.

Dispatch needs to know: Which customer? Which ship-to location? Is this a keep-full account or will-call? Is there already an order scheduled? What are the delivery hours? Which terminal supplies it? Which truck can access the site?

Pulling a tank reading through a connection is the easy part. The harder part is building the relationship between the monitor and everything else the operation needs to know.

Monitor → Tank → Product → Customer → Order → Delivery

Without that connection, you have visibility. You do not have a workflow.

And then there is the trust problem.

Probes fail. Readings drift. Connectivity drops. After enough exceptions, dispatchers start building their own mental correction layer. That one always reads a little low. Do not trust that reading right after a delivery. That monitor has not reported since yesterday.

Eventually the dispatcher trusts experience more than the screen. And experience is very hard to integrate with anything.

Have a lesson worth sharing?

Some of the best lessons in fuel operations never make it into a playbook.

They live in the experience, workarounds, mistakes, and tribal knowledge of people doing the work every day.

If you have something you have learned that could help another fuel marketer, I would love to hear it.

It may become part of a future issue of The Fuel Stack.

Dibyesh Giri.

Book a conversation →

What the data should actually do

I would not want a system automatically creating orders because a tank crossed 30%.

That just replaces one rigid rule with another.

What I would want is the system telling the dispatcher every morning:

Seven tanks are likely to need attention in the next 48 hours.

Then explain why.

Tank A is projected to hit its reorder point tomorrow afternoon based on this week’s consumption.

Tank B’s usage jumped 34% over its normal pattern. Worth a call.

Tank C has enough fuel until Friday but there is already a truck going within five miles of it tomorrow.

Tank D looks low but there is already an order on the board.

Tank E has not reported in eleven hours.

Now the dispatcher is not opening two hundred tank screens looking for trouble. She is looking at five things that deserve her judgment.

ATG data should reduce the search space. Not replace the dispatcher.

That is the immediate value. Not full automation. Just better information reaching the right person earlier in the day so the decision gets made before the customer calls instead of after.

The loop that almost nobody closes

Here is the part I find most interesting.

The tank predicted a delivery. The dispatcher approved it. The truck lifted the product. The driver delivered it.

Now ask: did the gallons reconcile?

The customer tank showed 1,900 gallons before the truck arrived. The meter says 4,100 gallons were delivered. What did the tank show afterward?

Not necessarily exactly 6,000 gallons. Product may have been consumed during delivery. Temperature matters. Measurement has tolerance. But you now have two independent signals you can compare.

And on a full route: terminal BOL, truck inventory, metered delivery, customer tank movement.

The ATG is not just telling you when to deliver. It is helping you validate what happened after you delivered.

That matters for inventory. It matters for billing. It matters for finding the tanks whose readings you cannot trust and figuring out why.

Over time the data starts auditing itself. The tanks that consistently reconcile earn confidence. The ones that consistently show unexplained differences get flagged. Maybe the probe needs calibration. Maybe the product mapping is wrong. Maybe the reading is being assigned to the wrong asset.

The system builds a picture of which monitors are trustworthy without the dispatcher having to maintain that list in her head.

Try it with ten tanks

You do not need a new platform to start seeing whether this matters.

Pick ten tanks you already monitor. For two weeks, record the morning reading and the actual delivery.

Then ask a few simple questions.

How many deliveries happened because the customer called? How many could you have anticipated from the consumption pattern? How much usable capacity was still in the tank when the truck arrived? How often did you go into an area and then return to roughly the same area a day or two later? Did the metered delivery roughly match what the tank showed?

Do not automate anything yet. Just look.

You will start seeing where the decisions are hiding.

The expensive part is already done

The probes are in the tanks. The connectivity exists. The readings are coming in. The history is accumulating.

In most operations I visit, the data already exists to answer much more useful questions than how much fuel is in this tank right now.

The questions worth asking are simpler.

Which tank needs fuel next? When will it need it? How much should we send? Can it fit into a load we are already planning? And after we deliver, did the gallons agree?

Until those questions get answered from the data, ATG is not really tank monitoring. It is a very expensive thermometer that tells you something is wrong after someone calls to tell you something is wrong.

The readings have been coming in for years.

It is time to start using them.

Every fuel operation I visit has one.

Sometimes it is a spreadsheet open on a second monitor. Sometimes it is a shared Google Sheet three people edit simultaneously and nobody fully trusts. Sometimes it is a laminated sheet taped to the wall beside the dispatch desk. Sometimes it is a group text that has been running for two years and contains more operational decisions than any system in the building.

I stopped calling these workarounds a long time ago.

I started calling them signals.

Every workaround in a fuel operation is a signal that the software stopped where the operation did not.

What the workaround is actually telling you

When a dispatch manager opens a spreadsheet before assigning a load, he is not doing it because he enjoys maintaining two sources of truth.

He is doing it because the dispatch system does not know that this customer only accepts deliveries before 6am. Or that this driver cannot go to that terminal because of an incident three months ago that was never logged anywhere official. Or that this load needs to be split across two compartments in a specific sequence because the customer has two tanks and one of them has a slow intake valve.

The dispatch system handles what it was built for. The spreadsheet handles what the dispatch system does not understand.

That boundary, the edge of what the software can do, is exactly where the workaround begins.

Every morning before the first truck rolls, the dispatcher is doing two jobs simultaneously. The visible job is assigning loads in the system. The invisible job is applying a layer of operational knowledge the system has never been taught.

Which driver fits which customer. Which terminal to avoid after 10am. Which load needs a phone call before the truck leaves the yard. Which delivery window is non-negotiable and which one has a thirty-minute buffer the customer will never mention but always expects.

None of that is in the dispatch system. It is in the spreadsheet. Or in the dispatcher’s head. Or in a notes field that one person maintains and nobody else reads.

The dispatcher is not the problem. The software did not understand the operation well enough to hold what the dispatcher was carrying manually.

And as long as that knowledge lives outside the system, the operation is one retirement, one resignation, or one bad morning away from a day that does not run the way it should.

Have a lesson worth sharing?

Some of the best lessons in fuel operations never make it into a playbook.

They live in the experience, workarounds, mistakes, and tribal knowledge of people doing the work every day.

If you have something you have learned that could help another fuel marketer, I would love to hear it.

It may become part of a future issue of The Fuel Stack.

Dibyesh G.

Book a conversation →

The group text that runs the dispatch

One of the most revealing workarounds I have seen in fuel distribution is not a spreadsheet. It is a phone.

A dispatcher in East Texas managed a fleet of twelve trucks through a combination of a dispatch system and a group text that had been running for three years. The dispatch system handled the scheduled loads. The group text handled everything else.

Driver calls in sick at 5am. Group text.

Terminal goes down at 7am. Group text.

Customer changes the order after the truck has already left the yard. Group text.

The dispatch system was technically capable of handling some of these scenarios. But it was not fast enough, flexible enough, or visible enough to the right people at the right moment. So the group text filled the gap.

By the time I saw it, the group text had become the real dispatch system. The software had become the record-keeping layer that documented decisions that had already been made somewhere else.

That is what a workaround looks like when it has been running long enough. It stops feeling like a workaround. It becomes the system.

The binder that ran the pricing

I visited a mid-market fuel wholesaler in Washington state last year.

Their pricing manager had a binder.

Not a binder of reference material. A binder of decisions. Thirty-seven customer accounts, each with a page that described how that customer’s price was calculated. Which rack posting to use. Which differential applied. Whether freight was included or billed separately. Whether the customer was on gross or net gallons. Whether there were volume tiers that changed the margin at certain thresholds.

Every one of those pages represented a decision the pricing system could not make on its own.

When an order came in, the pricing manager opened the binder, found the right page, and manually applied the correct logic before the invoice was generated.

She had been doing it for four years. She was fast. She was accurate. She knew every account well enough to catch errors before they reached the customer.

I asked her what would happen if she was not there.

She thought about it.

“They would call me.”

The binder was not a failure of organization. It was four years of operational knowledge that the pricing system had never been built to hold.

Why software creates workarounds in fuel distribution specifically

Most back-office software was not built for fuel distribution.

It was built for businesses that sell discrete products at fixed prices to customers with standard billing requirements.

Fuel distribution does not work that way.

The price changes intraday. The product that leaves the terminal is measured differently than the product that arrives at the customer’s tank. The customer’s billing requirements vary by account, by location, by product type, and by a contract that was negotiated at a specific moment in the market. The freight cost depends on which carrier ran the load, which route they took, and whether there were detention charges the customer may or may not be responsible for.

Generic software handles the standard case. Fuel distribution is full of cases that are not standard.

The workaround is what happens every time the software encounters a case it was not built for and the team has to bridge the gap manually.

In a small operation with low volume, the workarounds are manageable. The dispatcher knows the spreadsheet. The pricing manager knows the binder. The team carries the knowledge and the operation runs.

Then the operation grows.

More trucks. More customers. More loads per day. More edge cases per week. More people who need to share knowledge that used to live in one person’s head.

The workarounds do not scale the way the business does.

What happens when the workaround fails

Most workaround failures in fuel distribution are not dramatic.

They are quiet.

The pricing manager goes on vacation and a new hire applies the standard rate to three accounts that have negotiated differentials. Nobody notices for two weeks. The customer calls on week three.

The dispatcher’s group text loses a message during a busy morning and a driver does not get the update about the terminal that went down. The load gets turned away. The driver waits. The delivery misses the window.

The billing spreadsheet and the accounting system go out of sync during a month-end rush and nobody has time to reconcile them until the following week. Three invoices go out late.

None of those are catastrophic. All of them are expensive. And all of them were predictable consequences of an operation that had grown past what its workarounds could reliably handle.

The workaround works until it does not. And when it stops working, it usually stops working at the worst possible moment.

What the software should do instead

The answer is not better training on the existing software.

The answer is not adding more features to software that was not built for fuel distribution in the first place.

The answer is software that understands the operation well enough that the workaround is no longer necessary.

For the dispatcher with the spreadsheet: customer delivery windows, driver restrictions, terminal preferences, and split-load logic should live in the dispatch system and apply automatically when a load is assigned. Not in a spreadsheet he maintains separately.

For the dispatcher with the group text: mid-route changes, terminal alerts, and driver availability updates should be visible to everyone who needs them inside the dispatch system in real time. Not communicated through a text chain that nobody can search or audit.

For the pricing manager with the binder: every customer’s pricing logic, differentials, volume tiers, freight treatment, and gross or net billing preference should live in the pricing system and apply automatically when an order is created. Not reconstructed manually from a printed page every time a load is dispatched.

The workaround disappears when the software understands what the team was doing manually and builds it into the workflow.

That is the standard we hold ourselves to at Fueleo.

Every time we see a spreadsheet beside a dispatch system, a group text running alongside a load board, or a binder of pricing decisions sitting next to a software platform, we ask the same question.

What did the software not understand that the workaround was compensating for?

The answer to that question is a gap worth closing.

The question worth asking this week

Walk through your operation and count the workarounds.

The spreadsheets that live beside your systems. The group texts that coordinate decisions your software should be coordinating. The binders, the printed sheets, the sticky notes, the shared drives full of documents that exist because your software does not carry that information automatically.

Count them.

Then ask about each one: what does this workaround know that my software does not?

That list is not a list of your team’s inefficiencies. It is a list of the gaps in your software’s understanding of your operation.

And until those gaps close, the workarounds will keep running. Getting faster. Getting better. Getting more embedded in how the operation actually works.

Until the day they stop working.

I keep thinking about one construction site delivery.

640 gallons. Eighteen pieces of equipment. The driver was on site for two hours and twelve minutes.

Then I looked at the invoice.

One line for diesel. 640 gallons. A delivered price that looked perfectly reasonable against the rack.

If you only looked at the invoice, the job looked fine.

But that invoice was missing the most expensive part of the delivery.

Two hours and twelve minutes of somebody’s day.

And that is where wet hosing gets interesting.

Wet hosing is not a bulk delivery problem

A bulk load is fairly easy to understand economically.

Load the truck. Drive to the customer. Drop several thousand gallons into a tank. Move on. Volume helps. If you are already sending the truck, delivering 4,000 gallons is almost always better than delivering 600.

Wet hosing behaves differently.

The driver arrives at a construction site and fuels individual assets one by one. Not tanks. Machines spread across an entire job site. Some labeled clearly. Some not. Some accessible immediately. Some requiring a supervisor to unlock them, a piece of equipment to be repositioned, or a conversation with a site manager who is in the middle of something else.

Unlike bulk delivery, wet hosing is often demanded at night when equipment is idle and trucks will not block day-to-day operations. A stop that takes two hours in daylight can take longer at night with limited visibility and reduced site access.

The driver is not simply delivering diesel. He is navigating a job site, finding equipment, coordinating with people, and fueling assets one at a time.

The gallons matter. But the clock matters too.

Sometimes more.

The driver behind the wheel is not cheap

Before we get to the margin math, one thing is worth naming directly.

A wet hosing driver is not a standard delivery driver.

CDL. Hazmat endorsement. Tanker certification. The licensing requirements narrow the labor pool and raise the cost of the hour before the truck ever leaves the yard.

Add the overtime premium for night fueling, higher turnover from demanding hours, and the cost of training replacements, and the driver hour is already expensive before the stop begins.

A per-gallon margin designed for bulk operations is not carrying those costs accurately.

The stop that should have looked different on paper

The driver arrived at 7:14am. He left at 9:26am.

Eighteen assets. Three generators. Two light towers. One machine that needed a supervisor to unlock it. Two pieces of equipment that had been moved since the order was created. Finding them took twenty minutes.

Total delivered: 640 gallons.

Put a normal rack-plus-margin calculation on those gallons and the delivery looked acceptable.

But think about what the truck and driver were doing for those two hours and twelve minutes.

They were not available for another customer. Wages were running. The truck was running. Insurance, maintenance, and overhead did not stop because the hose was moving from one asset to another.

A margin that works when you drop 4,000 gallons into one tank can disappear quickly when 640 gallons takes more than two hours to deliver.

And that is the daytime version of this problem. Run the same stop at midnight with limited lighting and a crew that is not there to help locate equipment. The time goes up. The cost goes up. The invoice stays the same.

This is where wet hosing pricing gets dangerous

Most wet hosing pricing still has its roots in traditional fuel distribution. Rack plus margin. Maybe a delivery fee. Customers understand it. Operators understand it.

The problem is that wet hosing introduces a cost that does not move neatly with gallons.

Time.

Consider two deliveries on the same day.

Stop A: 800 gallons. Six assets. Everything staged and accessible. Driver finished in 45 minutes.

Stop B: 800 gallons. Twenty-two assets. Equipment spread across the site. Three assets need to be located. Driver waits for a supervisor. Total time: two hours and twenty minutes.

Same gallons. Same invoice structure. Completely different economics.

Yet if both customers are priced on the same rack-plus-margin, those two invoices look nearly identical.

That is why wet hosing operators need to know one number that rarely shows up on a fuel invoice.

Margin per driver hour.

I would not stop charging by the gallon

Customers understand gallons. Nobody needs to turn a fuel invoice into a consulting invoice with twelve different service charges.

But behind the customer-facing price, the operator needs to understand what the stop actually requires.

How many assets are normally fueled? How long does the driver spend on site? How often are assets inaccessible? Does the site regularly make the driver wait? Does a 500-gallon delivery take 40 minutes or two hours? Does the account regularly request after-hours fueling?

Once you know those answers, the pricing structure becomes clearer.

A minimum stop charge. A per-asset fee. A site-service fee. An after-hours premium for night fueling requests. A minimum-gallon requirement. Maybe certain accounts need a different margin altogether.

The exact model will differ by operation. The point is simpler.

You cannot price the account intelligently if you only understand the gallons.

Have a lesson worth sharing?

Some of the best lessons in fuel operations never make it into a playbook.

They live in the experience, workarounds, mistakes, and tribal knowledge of people doing the work every day.

If you have something you have learned that could help another fuel marketer, I would love to hear it.

It may become part of a future issue of The Fuel Stack.

Dibyesh G.

Book a conversation →

The documentation problem nobody talks about

Even when the pricing is right, somebody still has to record the complexity of the stop.

A driver finishes fueling eighteen assets at 9:26am. At that moment he knows exactly what happened. Which equipment was fueled. Which machine was missing. Which asset was locked. How long he waited.

Then he drives to the next stop.

By 4pm some of those details are already fuzzy. By the next morning the stop has become: 640 gallons at the construction site.

This is one reason same-day invoicing matters in wet hosing beyond the cash flow argument.

Same-day invoicing is partly about getting paid faster. In wet hosing it is also about preserving the economics of the stop before they compress into a single line.

The dangerous account is the one that looks fine

A wet hosing account can look like a good customer for years.

Plenty of fuel. Pays on time. Nobody complains. Gross margin looks decent.

Then you break it down stop by stop.

The high-volume, easy-access sites are excellent. The moderate sites are fine. Then there are the smaller deliveries where the driver spent two hours navigating a job site to deliver 640 gallons across eighteen assets while a supervisor was tracked down and two machines were located on the wrong side of the yard.

The good stops are subsidizing the bad ones.

At the account level everything still looks healthy. Until somebody asks:

What are we actually making per driver hour?

That question can be surprisingly hard to answer. Driver time is in one system. Gallons are somewhere else. Asset-level delivery data is in the driver app or on paper. Pricing is in accounting. Supplier cost is somewhere else again.

An operator who understands his business completely still has to pull information from three places and build a spreadsheet just to find out whether a customer is worth serving.

That should make people uncomfortable.

Before you price the next wet hosing account

Take one existing customer. Pull the last month of deliveries.

For every stop: gallons delivered, assets fueled, driver arrival time, driver departure time, gross margin.

Then calculate the margin per driver hour.

You may find the account is even better than you thought. You may also find that a few stops are quietly eating the economics of the entire relationship.

Either answer is useful.

Because wet hosing may be billed in gallons.

But most of the cost is sitting behind the steering wheel. And if you do not measure that time, it is very easy to give it away.

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.

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.

Most Labor Day celebrations run on fuel.

The grill that starts at noon. The generator keeping the lights on at the campsite. The boats on the lake. The trucks moving food to stores that stayed open. The equipment sitting idle on a job site, ready to start again Tuesday morning.

None of it moves without the people who moved the fuel first.

I have spent the last few years sitting beside the people who do this work.

Dispatchers who start before 6am and do not stop until the last truck is accounted for.

Drivers who show up on holidays because the customer’s tank does not know it is a holiday.

Billing managers who stay late because the invoice has to go out today, regardless of what day it is.

Terminal operators who work through the weekend because the rack does not close for Labor Day.

And when something goes wrong, a terminal goes down, an allocation changes, a truck gets delayed, or a customer suddenly needs another load, someone has to figure it out.

Usually quickly.

This industry does not get talked about much outside of itself.

And the people running it rarely get recognized outside of the operations they hold together.

So today, before the weekend ends and the workweek starts again, I just want to say something simple.

To the fuel marketer who dispatched a driver at 5am so a construction crew could work Tuesday morning.

To the dispatcher who rerouted three loads when a terminal went down on Saturday.

To the driver who spent two hours on a job site fueling equipment in the heat so the project stayed on schedule.

To the billing manager who caught an error Friday afternoon and fixed it before the customer ever saw it.

That work is not glamorous. It does not get headlines. But it is the work that keeps everything else moving.

Before fuel becomes transportation, construction, agriculture, emergency power, or another day’s business, somebody has to get it from the rack to where it is needed.

Happy Labor Day to everyone in fuel distribution.

Thank you for showing up when it matters.

See you Tuesday.

— Dibyesh

I tried to sit down and write about fuel operations, technology, customers, and the things I normally think about every day. But I could not get myself to do it.

I am from Nepal, and the past few days have been incredibly difficult for many of us.

Recent floods and landslides triggered by a glacier collapse along the Nepal-Tibet border have devastated communities across the region.

The death toll has risen to at least 734. Nearly 2,500 people remain missing. Homes, roads, and infrastructure have been destroyed. Families are waiting desperately for news about their loved ones. NBC News

For me, this tragedy has become deeply personal.

One of my friends, someone who started the early part of his career working with me at one of my startups in Nepal, has been missing for the past four or five days. We believe he may be trapped inside a hydropower tunnel.

There has been very little information.

So much of the last few days has been spent making calls, following updates from Nepal, speaking with people on the ground, and hoping for any piece of good news.

It is difficult to explain the feeling of knowing someone you care about may still be somewhere inside a mountain, while families and rescue teams are doing everything they can to reach them.

So this week, instead of writing about fuel, I just wanted to write this note.

Events like this also make climate change feel much less like an abstract conversation.

Countries like Nepal contribute only a tiny fraction of global greenhouse gas emissions, yet communities across the Himalayas are increasingly exposed to extreme rainfall, glacial lake risks, floods, landslides, and other climate-related disasters.

Researchers have found that glaciers across the Hindu Kush Himalaya region are melting faster, with ice loss rates doubling since 2000. CBC News

The people paying the highest price are often the people who contributed the least to creating the problem.

There are obviously many factors behind any individual disaster, and I do not want to turn this into a policy essay. But a warming climate is changing the risk environment for fragile mountain communities, and countries like Nepal have very limited resources to prepare for and recover from events of this magnitude.

Estimates suggest Nepal may need $4 to $5 billion to rebuild following this disaster. NBC News

For me, though, none of those numbers matter very much this week.

Right now, there is a friend I am hoping comes home.

There are families waiting for their sons, daughters, brothers, sisters, fathers, and friends.

If you are someone who prays, please keep Nepal and the people affected by this tragedy in your prayers.

And please say a prayer for my friend.

If you would like to support the relief efforts, the Government of Nepal has set up a Prime Minister’s Disaster Relief Fund.

Donate to the Nepal PM Disaster Relief Fund →

Every contribution, however small, helps families on the ground who are waiting for help right now.

I hope to return to our regular Fuel Stack conversations next week.

Thank you for understanding.

— Dibyesh

I want to be honest about something.

When fuel marketers started asking me about AI, my first instinct was not to get excited. It was to slow down.

I have watched enough software get sold to this industry to know how the cycle works. Someone shows a demo. The demo is clean. The salesperson answers every question with yes. The contract gets signed.

Six months later the team is managing a tool that promised to fix three problems and created two new ones.

I am not writing this to tell you AI is overhyped. Parts of it are genuinely useful and I will get to that. But before I do, here is the one thing worth understanding first.

You do not have to be first to AI. You need to be ready for AI.

Those are different things. And right now most of the pressure fuel marketers are feeling is about the first one.

The trap is not AI. The trap is buying AI on top of a workflow that was already broken and hoping the AI fixes it.The pressure you are feeling is real

The driver app is the best lesson I have seen

Earlier in this series I wrote about Danny.

His company spent real money rolling out a driver app. Real-time delivery confirmation. GPS timestamps. BOL photos. Management looked at the adoption dashboard and saw seventy percent usage. They assumed the problem was solved.

Here is what was actually happening.

Danny was tapping through the app screens as fast as he could at every stop. Product confirmed. Gallons confirmed. Close the stop. Move on.

The app recorded a verification. The verification was not real. It was a tap.

Nobody designed the app badly on purpose. But nobody designed it around what a delivery actually looks like at 7am in the Texas heat with gloves on and a customer waiting.

AI has the exact same failure mode.

An AI that generates invoices automatically sounds like same-day billing. But if Danny tapped through without entering the right gallons, if the product code in the dispatch record does not match what was actually loaded at the terminal, that AI will generate a wrong invoice faster than any billing clerk would have caught it manually.

Speed is only valuable when what is underneath it is right.

This is the mental model worth keeping in mind when any vendor pitches you AI.

Bad data plus AI automation equals mistakes that move faster.

Operational truth plus AI interpretation plus rule validation equals exceptions that surface before they become problems.

The difference between those two outcomes is not the AI. It is whether the data the AI is working with reflects what actually happened in the field.

Where this actually costs you money

I have seen versions of this repeatedly across mid-market fuel operations.

A fuel marketer adopts an automated collections tool. Follow-up emails go out on a schedule. Aging buckets trigger reminders automatically. The owner feels like AR is finally handling itself.

DSO is still sitting at 52 days. It has not moved.

When you sit with the AR manager and go through the oldest outstanding accounts one by one, the pattern is the same every time.

An invoice with a wrong PO number the customer refused to process. An open credit sitting in billing that the collections team could not see. A delivery discrepancy from three weeks earlier that nobody resolved. An invoice formatted in a way the customer’s AP system kept rejecting.

The automated tool was sending reminders on schedule. Politely. Persistently. To invoices that were never going to get paid in the state they were in.

DSO is rarely a collections problem. It starts as an invoice problem and shows up in the aging report weeks later, by which point it looks like a collections problem because that is where it becomes visible.

For a fuel marketer running $50M in annual revenue, DSO sitting at 45 days instead of 33 is roughly $1.7M in working capital sitting in your aging report instead of your bank account. That cash is not earning anything. It is not buying product. It is just waiting.

What AI actually does well today

There are things AI does genuinely well in fuel operations today.

Reading a supplier invoice that arrives as a PDF in an inconsistent format and pulling the right numbers out of it. Matching that invoice against a purchase order and flagging it when the price or volume does not agree. Surfacing an open credit tied to an outstanding invoice before a collections rep picks up the phone blind. Catching an expired tax exemption certificate before a load goes out against it.

But here is the more important framing for all of those examples.

The real value of AI in fuel distribution right now is not AI doing the work. It is AI telling your people exactly where the workflow broke.

Here are 700 transactions. Tell me which 14 need someone’s attention.

A BOL where gallons do not match what was delivered. A supplier invoice where the price does not match the expected rack. A freight invoice that does not match the dispatched trip. A delivery that closed but an invoice was never generated. A customer who has disputed the same fee type three times in two months. An invoice stuck because a PO is missing. A tax exemption expiring before the next scheduled delivery.

That is AI being useful. Not running your operation. Finding the specific places where your operation needs a human to look.

The best AI in fuel distribution may not be the system doing the work. It may be the system telling your people exactly where the workflow broke.

Three questions worth asking before you buy anything

Every AI vendor will tell you their system is accurate, saves time, and pays for itself.

Ask them three questions before you sign anything.

What data does this need to work correctly, and where does that data live in my operation today?

If it lives in a connected system that is already accurate, the AI has a real chance. If it lives in a spreadsheet, a paper ticket book, or someone’s memory, the AI inherits those problems.

How does the output get validated before it becomes a transaction?

The right architecture is not a human approving every transaction. It is AI interpreting the information, business rules validating whether it is safe to transact, and exceptions going to humans. Clean transactions should flow automatically. Problems should surface to the right person immediately. Know exactly how your vendor handles that.

What happens when it is wrong?

How does the error get caught? Is there an audit trail? Can a bad invoice reach your customer or your accounting system before anyone notices?

A vendor who cannot answer this question clearly is selling you confidence. Not a system.

The thing worth remembering

The operators who will get the most out of AI in the next few years are not the ones adopting it fastest. They are the ones spending this year capturing operational truth. Clean BOLs. Connected dispatch records. Invoices that reflect what actually happened in the field. Driver workflows that record what was delivered rather than what someone tapped through.

Once that foundation is in place, AI has something real to work with.

Fix the workflow. Then let the AI run.

Because automating a broken process does not make it intelligent.

It just makes you faster at the wrong thing.

Cate sent me an email on a Thursday morning.

She runs billing for a Texas fueling company. One of her largest customers had a specific requirement for how they wanted invoices presented. Not a different price. Not a different product. A different format. The layout the customer’s AP team expected before they would process payment.

“Dibyesh, can we create a bulk invoice in this format?”

Simple request. Reasonable customer. The kind of thing you do when an account matters enough to go the extra mile.

The problem was that going the extra mile meant someone on Cate’s team manually rebuilding the invoice every billing cycle.

Cate’s request was not unusual. It was the fourth version of the same conversation I had heard in two months.

Four companies. Four different definitions of an acceptable invoice.

Garrett at American Petroleum started serving equipment rental companies. His customer’s AP team would send the PO number only after receiving the invoice. His billing team had to reopen the invoice, add the PO, generate a new copy, and resend it. Every single time. Three days lost before the invoice even entered the customer’s payment workflow.

Carina is the CFO of an East Coast fuel company. One of her largest customers wanted applicable tax calculated and displayed after every individual delivery line. Not summarized at the bottom the way every accounting system defaults to. Her billing team was manually reworking invoices for that account every billing cycle.

Andy runs a fuel wholesale operation in Washington state. His B2B customers pull their vehicles into his cardlock facilities, swipe a card, and fuel up. Every transaction is tracked: which card, which vehicle, how many gallons, what time. At the end of the billing period his customers want one invoice. Total gallons. Total charges. And underneath that, the full transaction-level breakdown. Every card swipe. Every vehicle. Every gallon traceable to a specific fueling event.

QuickBooks sees one invoice. Andy’s customer needs one invoice that contains hundreds of individual events.

At first these looked like four unrelated requests. They were not.

They were four versions of the same operational problem: the rules for getting paid lived in people’s heads instead of in the system.

The gap between delivery software and accounting software

Generic accounting systems were built around a simple model.

Customer plus items plus quantity plus price plus tax equals invoice.

That model works when every customer receives the same invoice format and the only variables are what was sold and at what price.

Fuel distribution does not work that way.

The invoice may depend on whether deliveries are billed individually or consolidated. Whether it is organized by customer, by location, by asset, by department, or by PO number. Whether the BOL and delivery ticket are attached. Whether the customer provided a PO before or after delivery. Whether tax appears summarized at the bottom or calculated and displayed after each delivery line. Whether cardlock transactions are consolidated by billing period or broken out by vehicle and card.

QuickBooks and most general-purpose ERPs can record the final invoice. Out of the box they usually do not know how to combine delivery records, BOLs, cardlock transactions, pricing rules, tax treatment, and account-specific billing instructions into a customer-ready invoice.

When the system cannot handle the complexity, the billing team absorbs it. Manually. Every billing cycle. For every account that falls outside the default.

What that actually costs

The manual work is visible. Someone rebuilds Cate’s bulk invoice. Someone adds Garrett’s PO number and resends. Someone recalculates Karena’s tax lines. Someone pulls Andy’s cardlock transaction history and assembles the consolidated breakdown.

The cost underneath is less visible.

In practice, many AP teams will not release an invoice into their payment workflow until all required information and supporting documents are present. If regeneration and resubmission takes three days, that is three days lost before the invoice even entered the customer’s payment workflow on a delivery that was completed on time.

Across multiple accounts with multiple billing requirements, that slip compounds. A fuel marketer running significant monthly receivables can have tens of thousands of dollars waiting outside the customer’s payment workflow not because customers are not paying but because invoices are not ready to be paid.

The delivery was on time. The fuel was correct. The invoice failed the last test before payment.

What a billing rules engine actually does

When Cate sent that email I realized the problem was not a one-off customization request.

It was a structural gap in how invoicing software thinks about fuel customers.

We stopped treating these as invoice customizations and started treating them as account-level billing rules.

In Fueleo, each customer profile defines its billing cadence, consolidation method, required PO fields, tax presentation, supporting documents, transaction detail, and approval requirements. When a delivery is completed, the system already knows what must happen before that invoice can be released.

Cate’s consolidated format generates automatically from the customer profile. No manual rebuilding.

For Garrett, Fueleo generates a preliminary billing document when the delivery is complete. When the customer returns the PO number, it is applied to the final invoice without rebuilding the document or re-entering the delivery data.

For Karena, tax is calculated and associated with each delivery line, then presented in the exact structure her customer’s AP team requires. It is not manually moved after invoice generation.

For Andy, cardlock activity is consolidated into one invoice with a traceable transaction appendix. Every card swipe visible. Nobody assembles it manually.

The accounting system still receives the financial transaction. Fueleo handles the operational work required to make that transaction billable.

The question worth asking

If you are a fuel marketer running accounts with specific billing requirements, one question is worth sitting with honestly.

Where do your customers’ billing rules live today: in your system, or in someone’s memory?

Because QuickBooks and most general-purpose ERPs do not carry those rules. They record the invoice after the fact. The customer-specific requirements that have to be met before the invoice is ready to go out live somewhere else. Usually in the billing team’s memory. Usually applied manually. Usually working fine until the person who knows it all is out sick, or leaves, or the account volume grows beyond what one person can handle.

Customer-specific billing should not require manual billing.

The fuel was delivered on time. The invoice should be ready the same day, even when every customer wants it differently.

Cate’s email was not simply a request for another template. It was evidence of a structural gap between delivery completion and invoice readiness.

The invoice is the last mile of fuel delivery.

Most fuel marketers are still walking it by hand.

I want to be honest about something before I start.

When most software companies write about AI they are usually trying to sell you something. A new feature. A new platform. A reason to upgrade.

That is not what this is.

This is me writing down what I have been thinking about after three years of sitting inside fuel operations, watching how the work actually gets done, and asking myself what changes when AI becomes a real part of that workflow rather than a chatbot bolted onto the side of it.

Some of this is happening now. Some of it is two or three years away. All of it is worth thinking about before it arrives.

The work I keep watching

Every fuel operation I visit has the same pattern underneath the surface differences.

Someone takes an order. Someone checks the price. Someone figures out where to load. A dispatcher decides which driver and truck should run it. The driver gets instructions. The truck loads. A BOL comes back. The fuel gets delivered. Someone verifies the gallons. Someone creates the invoice. Someone checks the taxes. Someone gets it into accounting.

Then three days later somebody notices the supplier invoice does not match the BOL and the whole thing backs up while someone figures out why.

None of this work is complicated in isolation. Checking a price is not complicated. Matching a BOL is not complicated. Generating an invoice is not complicated.

The complication is that all of it has to happen in the right order, with the right information, for every single delivery, every single day.

That is coordination work. And coordination work is exactly where AI becomes interesting.

What AI is not going to do

Before I get into what I think changes, let me say clearly what I do not think happens.

AI is not going to replace your dispatcher. Not in the next five years and probably not ever in the way people imagine when they hear that word.

Your dispatcher knows things no software knows. Which driver can handle a difficult customer. Which terminal backs up on Monday mornings. Which customer always changes the order after the truck leaves. That knowledge took years to build and it does not live in any database.

AI is not going to make decisions that require judgment. It is not going to know that a customer is having a hard month and needs a call from the owner rather than an automated reminder. It is not going to know that a driver is dealing with something at home and should not be pushed on a tight route this week.

What AI is going to do is take the coordination work off the plate of the people doing the judgment work.

That is the real opportunity. Not replacement. Subtraction of the work that should never have required a human in the first place.

What that looks like in a fuel operation

Let me make this concrete because I think the abstract version of this conversation is what makes operators tune out.

Right now when a delivery closes, someone in billing has to gather the information to create the invoice. They pull the delivery record. They verify the gallons. They check the pricing agreement. They look up the tax treatment. They check whether the customer needs a PO number. They generate the invoice. They get it into accounting.

On a good day that takes a few hours for a full day’s deliveries. On a bad day, when tickets are missing or prices need to be verified or a customer has a special requirement nobody documented, it takes longer.

What if the invoice was ready three minutes after the delivery was confirmed?

Not because someone worked faster. Because the system already knew the pricing agreement, the tax treatment, the customer’s invoicing requirements, and the BOL matched the delivered gallons within tolerance. All the information was already there. The invoice generated automatically. Someone reviewed the exceptions. Everything else went straight through.

That is not science fiction. That is where the technology is heading and in some cases where it already is.

The dispatcher who manages exceptions instead of transactions

Here is another version of the same idea.

Today a dispatcher builds every route manually. They know which trucks are available. They know which drivers are on. They know the customer delivery windows. They know the terminal loading times. They hold all of that in their head or in a spreadsheet and they make dozens of small decisions every morning before the first truck rolls.

What if the system proposed the day’s dispatch plan automatically based on everything it already knows?

Not a rigid plan that cannot be changed. A starting point. A plan the dispatcher can review, adjust, and approve in fifteen minutes instead of building from scratch over two hours.

And when something goes wrong, because something always goes wrong, a driver calls in sick, a terminal goes down, a customer changes their order, the dispatcher is dealing with the exception from a position of clarity rather than trying to rebuild the entire day while fielding phone calls.

The dispatcher does not disappear. The transaction management does.

What is left is the judgment work. The work that actually requires someone who knows the operation.

What the billing team’s morning looks like

Same idea, different department.

Today a billing team reviews every transaction. Most of them are clean. A small number have issues. But because the system cannot tell which is which, every transaction gets human eyes.

Tomorrow the system handles the clean ones automatically. The billing team sees only the exceptions. The delivery where the gallons do not match. The invoice where the PO number did not arrive. The customer whose exemption certificate expired.

Instead of reviewing 300 transactions and finding 11 problems, the billing team sees 11 problems and resolves them.

That is a different job. A better job. And it produces faster invoicing, cleaner AR, and less end-of-month scramble because the exceptions were caught at the time of delivery rather than discovered three weeks later.

What I think the next few years look like

I am not going to pretend I know exactly how this unfolds. Nobody does.

But based on what I am seeing in the technology and what I know about how fuel operations work, here is my honest read.

In the next year or two the change is mostly about reducing the manual coordination work that slows billing, dispatch, and AR down. Invoices that generate automatically when all the conditions are met. Exceptions that surface to the right person at the right time. Supplier invoices that get matched automatically and flagged when they do not agree.

In the three to five year window the change gets more interesting. The system starts making recommendations that today require a person. Not final decisions. Recommendations. The pricing engine suggests the best terminal based on margin and availability. The dispatch system proposes the optimal route plan before the dispatcher starts their morning. The inventory system flags a replenishment need before anyone has to notice the tank level.

The operator is still making the call. They are just making it from a better starting position with better information.

The goal is not software that replaces the people running the operation. It is software that handles the routine so the people running the operation can focus on the things that actually require them.

The one thing I would tell any fuel operator reading this

The operators who will benefit most from what is coming are not the ones who rush to adopt every new AI tool.

They are the ones who take the time now to document how their operation actually works. The pricing rules. The customer requirements. The dispatch logic. The exception handling.

Because AI is only as good as the operational knowledge underneath it. A system that understands how your operation works can automate your routine. A system that does not understand your operation will create new problems faster than it solves old ones.

The knowledge Bob carries in his head about which terminals to avoid on Monday mornings is more valuable to an AI system than any algorithm. But only if it gets captured somewhere the system can use it.

That is the work worth doing now. Not evaluating AI platforms. Documenting what you know about your own operation before it walks out the door with the next retirement.

Next issue: Your fuel was delivered. Why is the invoice still not ready?cha

Subscribe now

Last month I was sitting with a fuel marketer in Texas.

QuickBooks open on one screen. A spreadsheet on the other. A stack of delivery tickets beside the keyboard that billing had not gotten to yet.

I asked how long they had been on QuickBooks.

Nine years, she said.

I asked if they had ever thought about switching.

She laughed.

“We tried. Spent six months looking. Almost signed with someone. Then we looked at what migration would actually cost and what we would lose and we came back.”

She pointed at the spreadsheet.

“So now we have this.”

That spreadsheet is not unusual. It is the standard solution at mid-market fuel distributors across the country. Built by someone on the team. Maintained by that same person. Quietly holding the operation together in ways nobody fully documented.

QuickBooks is on the first monitor. The spreadsheet is doing the actual work on the second.

That is not a QuickBooks problem. That is a workflow problem wearing a QuickBooks problem’s clothes.

What QuickBooks is actually doing right

QuickBooks handles the accounting well. General ledger, accounts receivable, accounts payable, bank reconciliation, financial reporting.

For a fuel marketer who has been on it for years, that foundation matters. The team knows it. The bookkeeper knows it. The accountant can log in without a learning curve.

That is not nothing. That is years of knowledge embedded in a system that works.

The problem is not the accounting.

The problem is the ten steps between a fuel delivery and a clean transaction arriving in QuickBooks.

Rack price changes intraday. The next day rack starts coming in late afternoon. A delivery at 10am and a delivery at 3pm can carry different prices. Managing that correctly requires a system that understands rack timing.

Gallons are measured in gross at the terminal and net after temperature correction. Someone has to know which one the customer is being billed on.

The driver’s confirmation, the BOL, and the dispatch record all describe the same delivery. They all have to agree before billing can run.

Tax exemptions vary by customer, by site, by product type. They have to be applied correctly every single time.

QuickBooks was not designed to coordinate any of that. It was designed to record the result after it happens.

When a fuel marketer tries to use QuickBooks to manage that coordination, the billing team becomes the integration layer. They gather delivery data. Verify pricing. Apply exemptions. Enter the invoice. Every day. For every delivery.

That is why billing is broken. Not because QuickBooks is the wrong tool. Because it is being asked to do something it was never built for.

Why switching rarely fixes it

The instinct when billing breaks down is to blame the accounting system.

That instinct leads to ERP evaluations. New platforms that promise to handle everything in one place. Nine-month implementations. Budgets that grow. Go-live weekends where things break at midnight and the team works through it.

I wrote about Lisa in an earlier issue. She championed a full ERP implementation. Nine months. $240,000. Eighteen months after go-live, the spreadsheet was still open on the AP manager’s second monitor.

The ERP did not fix billing because billing was not broken inside the accounting system. It was broken in the ten steps before the accounting system ever saw the transaction.

Replacing QuickBooks does not fix the workflow that feeds QuickBooks. It just means you are managing the same broken workflow inside something more expensive and less familiar.

And you gave up eight years of financial history to do it.

The question worth sitting with

Before the next software evaluation, one question is worth asking honestly.

Is billing broken because of where the invoice gets recorded? Or because of how it gets created?

In almost every fuel operation I have visited, the answer is the second one.

The invoice gets created late, or wrong, or with errors, because the workflow between the delivery and the invoice is manual and disconnected. People are filling the gaps by hand because no system was built to fill them automatically.

Fixing that does not require a new general ledger. It requires an operational layer in front of the general ledger that handles the fuel-specific complexity QuickBooks was never designed for.

What that layer actually does

The problems that break billing upstream of QuickBooks are consistent across fuel operations.

1. Pricing. Rack changes intraday. The correct price at 10am is different from the correct price at 3pm. That has to be applied automatically, not looked up manually after the delivery happens.

2. Delivery confirmation. The driver confirms gallons. That confirmation should trigger billing immediately. Not sit in a queue until dispatch closes the load and billing pulls the ticket hours later.

3. Document matching. The BOL, dispatch record, and supplier invoice describe the same transaction. They need to agree before billing runs. In most operations they live in three different places and someone reconciles them at month-end.

4. Tax and exemption logic. A customer’s exemption status varies by site, by product, by monthly volume. That logic needs to live in the system. Not in someone’s memory.

None of these are accounting problems. They are operational problems that show up in the accounting system as billing errors and late invoices.

An operational layer that handles these problems upstream of QuickBooks does not replace the general ledger. It feeds it clean transactions instead of broken ones.

What this looks like in practice

Last year Fueleo processed over $5 million+ in invoices for our design partner customers with less than 1.45% sync error rate to QuickBooks.

Not in a demo. In a live operation. Real deliveries. Real customers. Real invoices syncing cleanly into an accounting system the team already trusted and did not have to replace.

QuickBooks stayed exactly where it was.

What changed was what arrived at QuickBooks before anyone in accounting touched it.

Delivery confirmation triggered billing automatically. Pricing was validated at dispatch, not reconstructed afterward. The BOL matched the dispatch record before the invoice was created. Tax exemptions were applied correctly based on the customer profile.

The accounting team went from spending hours gathering information to spending minutes reviewing exceptions.

That is not a new general ledger. That is a workflow that finally feeds the existing one correctly.

The decision that actually matters

Most fuel marketers do not need to replace QuickBooks.

They need to stop asking QuickBooks to do something it was never designed to do.

The general ledger is fine. The workflow feeding it is not.

Fixing the workflow does not mean tearing out the accounting system and starting over. It means building the layer in front of it that handles pricing, delivery confirmation, document matching, and tax logic before QuickBooks ever sees the transaction.

Smaller than an ERP implementation. Faster. Less expensive. No migration. No learning curve. No eight years of history lost.

Garrett Daley, owner of American Petroleum, said it directly.

“QuickBooks does what QuickBooks does. Our problem is everything that has to happen before QuickBooks can do its job.”

He was right. And once he understood that, the decision about what to build became clear.

The accounting system was never the problem.

It was everything that had to happen before QuickBooks could do its job.

I have talked to enough fuel marketers serving equipment rental companies to know how this conversation usually goes.

The sales call goes well. The account looks clean. Rental company needs fuel delivered to their job sites. Fuel marketer shows up, delivers, sends an invoice. Rental company pays, marks up the fuel to their customer, everyone moves on.

That is the story in the sales meeting.

Here is what happens after the first delivery.

The invoice goes out. Then the PO arrives.

The sales call goes well. The account looks clean. Rental company needs fuel delivered to their job sites. Fuel marketer shows up, delivers, sends an invoice. Rental company pays, marks up the fuel to their customer, everyone moves on.

That is the story in the sales meeting.

Here is what happens after the first delivery.

The invoice goes out. Then the PO arrives.

The driver delivers. Everything goes right. Gallons match. Ticket is legible. Invoice goes out same day.

Then the rental company’s AP team responds.

Not with payment. With a PO number.

A purchase order their team generated after the delivery, which needs to appear on the invoice before their system will touch it.

Billing pulls the invoice, adds the PO, regenerates, resends.

The delivery was right. The invoice was right. The only thing missing was a number that did not exist when the invoice was created.

Payment terms do not start until the corrected invoice lands in AP.

Let’s say you have five equipment rental accounts. Each averages fifteen deliveries a month at $2,500 per invoice.

That is 75 invoices a month. $187,500 in monthly receivables.

If every invoice requires a PO correction cycle that adds three days before payment terms start, you are carrying $18,750 in delayed receivables every month before the customer has even looked at the invoice.

That is $225,000 a year sitting in a correction queue.

Not because customers are not paying. Because the invoice was not ready to be paid.

Not a collections problem. A workflow problem that shows up in the aging report.

Why this happens specifically with rental companies

Most fuel distribution customers generate PO numbers before the order is placed. The PO exists when the order is created. Invoice references it. Done.

Equipment rental companies work differently.

Their fuel subcontracting is operationally driven. A site manager decides machines need fuel. They call the rental company. The rental company calls the fuel marketer. The fuel gets delivered. Procurement catches up afterward.

What most fuel marketers do not realize is that the rental company is not just passing the invoice through. They are marking up the fuel and billing it to their own customer as an ancillary revenue line.

A delayed or incorrect invoice from the fuel marketer does not just slow their payment. It delays their invoice to their customer too.

The problem travels upstream.

The line item problem nobody mentions

Equipment rental companies need fuel cost and delivery charge as separate line items for their own tax treatment.

If the fuel marketer sends one combined line, the AP team has to split it manually before they can process it.

One more invisible step. One more reason the invoice takes longer to move.

The asset detail request

The fuel marketer delivered 800 gallons to a construction site.

But the rental company needs to know how many gallons went into the excavator, how many into the generator, how many into the light tower.

Not because they are being difficult. Because they already track every hour of use on every piece of equipment they rent and bill their customers at the asset level. Fuel is one of twelve revenue streams in a rental operation and each one has its own billing logic.

The fuel marketer is the only vendor not delivering data at that level of detail.

The driver delivered to a site. He did not track by asset. The ticket shows total gallons at a location. Someone now has to reconstruct the breakdown from memory or make an estimate.

All three problems share the same root cause

The billing requirements were never captured before the first truck rolled. They were discovered through rejection.

Every equipment rental account is different. But the fix flows in the same direction every time.

The PO requirement needs to be captured at account setup, not discovered at invoice rejection. If this customer generates PO numbers post-delivery, the invoice should sit in a billing-ready state until the PO is collected. Not sent blank and corrected later.

The asset-level detail needs to flow backward into dispatch before the driver arrives. If the rental company needs gallons by asset, the dispatch record needs the asset list before the driver arrives at the site, not just the address. The driver records gallons by asset at the point of delivery. Not reconstructed afterward from memory.

The line item format and compliance requirements belong in the account profile at setup. Every document the customer needs, every format requirement their AP team has, every certification a site requires, should be visible to billing and dispatch before the first delivery happens.

None of these are complicated fixes. They all require one thing:

Billing requirements flowing backward into the dispatch workflow instead of being discovered forward through invoice rejections.

The question nobody asks in the sales conversation

Walk me through how your AP team processes a fuel invoice.

That one question surfaces the PO requirement, the line item format, the asset-level data expectation, and the compliance documentation before the first delivery. The account works the way the sales conversation described.

Wait until the first invoice comes back and you are three weeks into a correction cycle that was entirely avoidable.

The equipment rental company is a good account. The happy path is real. You just have to ask about the other path before you start driving.

The phone rang before Bob finished his sentence.

He picked it up, said a few words, looked at the load chart on his screen, moved a station from one split to another, changed the compartment assignment on the truck, and called the driver.

Three minutes. Maybe less.

I needed another fifteen minutes afterward just to understand everything that one decision had touched.

That was my introduction to how Bob dispatches fuel in East Texas.

The office

Bob is seventy four years old. He has been running dispatch and operations at this common carrier for four decades. His desk had two monitors, a printed load sheet beside the keyboard, and a phone that did not stay quiet for long. Driver names highlighted in different colors. Terminal notes written in the margins. A stack of dispatch packets waiting to be printed.

The spreadsheet on his left monitor had forty years of revisions. New colors. New tabs. Notes tucked into cells referencing decisions made years ago. It had grown alongside the operation. You could almost read the company’s history in it.

I had expected whiteboards and sticky notes and a system that mostly lived in someone’s head.

What I found was something more interesting. Bob had turned four decades of experience into a visual system that other people could follow.

The spreadsheet was not for him. He already knew the answers. It was for everyone else.

What four decades actually looks like

Bob started dispatching when everything was paper. Load sheets written by hand. Delivery tickets carried back by the driver at the end of the shift. Customer calls taken on a landline with a notepad on the desk.

At some point the fax machine changed things. Then spreadsheets changed things.

But the core of the job never changed.

Knowing the trucks. Knowing the terminals. Knowing the drivers. Knowing which station needs to be hit first and why. Knowing that one customer always changes the order after the packet is printed and that one terminal backs up by 10am on Fridays.

The tools got faster. The judgment stayed the same.

I asked Bob if he had looked at dispatch software before.

He had. More than once.

“The demos always looked clean,” he said. “The reality always looked different. The systems wanted me to work the way they were built. They did not know how my terminals worked, how my drivers worked, or why certain stations had to be delivered in a certain order.”

So the spreadsheet survived. Every time.

Not because Bob was resistant to change. Because nothing he had seen was built around how the job actually works.

The morning before the first truck rolls

Before I arrived I thought the hardest part of common carrier dispatch was routing. Getting trucks to the right places in the right order.

Sitting with Bob changed that.

The hard part is everything that changes after you think you have the plan.

A driver calls in sick. The terminal runs out of premium. A customer adds 1,500 gallons after the packet is already printed. Bob crossed out the original quantity that morning, rewrote the compartment split by hand, and called the driver because the paper packet was now wrong before the truck had even left the yard.

One small change does not stay small. One compartment reassignment touches three loads. One late driver shifts two routes. One terminal running slow pushes the whole day back.

And all of it lands on Bob’s desk before 7am.

The load chart

The first thing Bob walked me through was the load chart.

Every truck broken down by compartment. Product assigned to each slot. Gallon capacity. Delivery sequence.

Before I understood what I was looking at I thought it was about truck capacity. It was not. It was also a training document, a quality control check, and a communication tool rolled into one.

“I have a mix of new and old drivers,” Bob said. “The experienced ones know the trucks. They load and go. The new ones are still figuring things out. This chart tells them exactly which product goes in which compartment. I do not want a new driver putting diesel in the wrong compartment because nobody told them clearly.”

An experienced driver looked at a list of customer names and already knew the likely sequence, the terminal, the compartment setup. A new driver needed every detail written out. The same dispatch packet had to work for both.

Without the chart, the calls started.

“Bob, which compartment is diesel again?”

“Bob, am I loading at Mount Pleasant or Tyler?”

“Bob, which station do I hit first?”

Every one of those calls interrupted dispatch. The load chart was Bob’s way of answering those questions before they got asked.

Bob knew his drivers the way a coach knows a roster. He knew which driver could handle a complicated split load without calling in. He knew which driver needed the terminal written at the top of the packet in large letters because he had missed it before. He knew which driver would push back on a sequence change and which one would just figure it out.

That knowledge was not in any system. It lived in Bob.

The split load logic

The second thing Bob showed me was how he groups his gas stations.

Not alphabetically. Not by account number. By proximity to each other and by which terminal serves them.

“Split loads,” he said. “If I know which stations are close together and which terminal serves them, I can plan a split load in about two minutes. Group the stations, match the terminal, figure out the compartment breakdown, done.”

I initially thought this was a routing problem. Bob showed me it was equally a terminal problem, a compartment problem, a product problem, and a driver-familiarity problem all at once.

The groupings in that spreadsheet were not random. They were the result of thousands of routes, dozens of terminal relationships, and forty years of learning which combinations worked and which ones created problems later in the day.

What happens when Bob takes a vacation

I asked him what happens when he takes a week off.

He smiled.

“I don’t.”

Not complaining. Just stating something that had become true over time.

I pushed a little. What would actually happen if he did?

“They call me anyway.”

Then I asked him what he wanted the operation to look like in five years.

He thought about it for a moment.

“I want whoever does this job after me to be able to do it right. Not have to call me every five minutes because something is not written down anywhere.”

He paused.

“Forty years is a long time to carry something. At some point it should live somewhere else.”

Bob was never the bottleneck. Bob was the system. The spreadsheets existed because nothing had ever been built to hold what he knew. So he carried it. Every day. For forty years.

What the visit changed about the design

I spent the first morning tracing Bob’s process rather than showing him anything. We took one real load and followed it from customer order to terminal selection, compartment assignment, driver instruction, delivery sequence, and printed packet. Every time Bob left the main spreadsheet to check another file, make a phone call, or write something by hand, we marked it.

That exercise changed the design completely.

We stopped treating a dispatch as a simple order assigned to a driver. The operating unit had to include the truck, the compartments, the terminal, the product split, the sequence, the certifications, and the driver instructions, all connected to the same record.

Later I watched a driver review his packet before leaving. He did not read it top to bottom. He looked first for the terminal, then the compartment split, then the stop sequence. That changed how we structured the mobile load screen.

Not every decision belonged in an automated rule. Bob knew one customer disliked late afternoon deliveries. Another site was difficult for a newer driver to navigate. Some knowledge could be structured. Some needed to stay visible as context the dispatcher could see and act on.

The system now flags an expired TCEQ certification before Bob assigns the load instead of relying on him to check a second spreadsheet every morning. It shows Bob’s station groupings, preferred terminals, and compartment logic so a new dispatcher can see the decisions without calling Bob for every one of them. Driver instructions attach directly to the load so the questions that used to require a phone call get answered before the driver asks them.

The goal was never to replace what Bob knows. It was to make sure that knowledge does not disappear the day he finally takes a vacation.

The thing I keep coming back to

Every common carrier has a Bob.

Sometimes he is the dispatcher. Sometimes she is the billing manager. Sometimes it is the owner who has not taken a real week off in fifteen years.

Somewhere in every operation is one person carrying decades of unwritten knowledge the business quietly depends on.

Great software does not replace that person.

It makes sure the operation can still run on the day they finally do.

Monica had the aging report open on her second monitor when I walked in.

Color-coded. Yellow for 30 days. Orange for 45. Red for 60. Dark red for 90.

There was a lot of dark red.

I asked her how she decides where to start each morning.

“We focus on the 90-plus day accounts first,” she said. “By the time we get to 30 or 60 days, the day is already gone.”

That stopped me. Most operations I visit begin active collections around 30 days past due. Monica’s team was not getting to accounts until they were three months overdue. Not because they did not care. Because they did not have time.

When I asked what was consuming the rest of it, she pulled up her task list.

Manual aging reports run in QuickBooks. Manual follow-up emails written from self-made templates that escalate in tone over time. Monthly statements manually generated, saved, and emailed to each customer. COD credit card authorizations routed to AR and processed by hand. ACH payments initiated by emailing Treasury with invoice details, waiting for two approvals, and confirming through the next day’s report.

By Monica’s estimate, 70 to 80 percent of her team’s working time went to manual administrative work.

Not collections. Not relationship management. Not the judgment calls that require someone who knows the customer. Administrative tasks that a well-designed workflow could handle automatically.

What upstream actually means

In fuel operations, an overdue invoice may have started failing weeks earlier. During customer setup. At order entry. In delivery documentation. In pricing. In credit processing. By the time it reaches collections it has already traveled through several hands, and the reason it is outstanding is rarely obvious to the person making the call.

Monica walked me through two accounts sitting in the dark red.

One invoice had a pricing error the customer caught before paying. The invoice used the wrong contract differential. The customer placed it on hold pending a credit. The credit request sat in billing for eight days. Monica’s team called at day 45 with no visibility into the open credit. The rep transferred the call, found the right person, and called the customer back two days later. By then the account was nearly 60 days old and the customer had explained the same problem twice.

And the one that made Monica close her eyes before she pulled it up.

A large fleet customer required a PO number on every invoice before their AP team could process it. The requirement had existed since the account was opened, but it was never captured in the customer’s billing profile. The invoice went out without one.

Monica’s team called at day 30. Waiting on a corrected invoice. Day 45. Same answer. Day 60. Escalated to the sales rep. Sales rep called the customer. Customer explained the PO requirement again. Sales rep emailed billing. Billing emailed the account setup team.

The invoice had been chased for months across four people before anyone understood what was actually wrong.

“That account,” Monica said, “has been sitting since January.”

Months of follow-up calls and internal escalations for a piece of information that should have been captured the day the account was created.

The customer was not refusing to pay. The invoice was not ready to be paid.

The context gap

Monica showed me what her team sees when they call a customer.

Invoice number. Amount. Days outstanding. Customer name.

Then she showed me what they cannot see.

Whether there is an open credit tied to the invoice. Whether the customer already contacted billing about a dispute. When the delivery was completed, when billing finalized the invoice, and when the customer actually received it. Whether the customer has a PO requirement that was never captured in their billing profile.

“We are calling customers about problems we do not fully understand yet,” she said. “And the customer has to explain it to us. Every time.”

The problem was not simply that the company used several systems. The problem was that no system carried the context of an invoice from delivery through payment.

Credits lived in a queue Monica’s team could not see. Disputes were tracked in a spreadsheet one person maintained. Customer-specific billing requirements lived nowhere at all.

So a rep calling at day 45 was calling blind. She knew the invoice was outstanding. She did not know it had been on hold for three weeks. She did not know the customer had already emailed billing twice.

That call did not collect anything. It confirmed that Monica’s team was the fourth group of people the customer had talked to about a problem that should have been resolved in week one.

What a connected workflow looks like

Before a collections rep dials a 45-day account she should be able to see:

When was the delivery completed and when was the invoice actually sent?

Is there an open credit, its current owner, and the next required action?

Does this customer require a PO number and has it been validated on this invoice?

Is the invoice currently blocked and who owns the resolution?

The first call can become a resolution call instead of another discovery call. Context replaces confusion. Monica’s team stops being the fourth person and starts being the one who actually resolves it.

Where agentic workflow comes in

This is where workflow intelligence becomes useful. Not by replacing the collections rep. Not by adding another system to check. But by preventing incomplete invoices from reaching collections in the first place and surfacing unresolved exceptions before the rep picks up the phone.

An agentic workflow operates continuously across the delivery-to-cash chain. It does not wait for a human to run a report or notice a problem. It watches the workflow, checks conditions against account rules, surfaces exceptions to the right people, and routes action to whoever owns the next step.

In the context of Monica’s operation that looks like this.

When a customer account requires a PO, that requirement is captured in the billing profile at account setup. When an order is placed for that customer without a valid PO, the workflow catches it before the invoice goes out. Not after months of follow-up calls. The exception is flagged and routed to the responsible team while there is still time to fix it cleanly.

When an invoice has an open credit or pricing dispute, the workflow surfaces the issue, its current owner, and the next required action alongside the aging record. The collections rep sees it before dialing. The call starts with context instead of confusion.

When monthly statements need to go out, the workflow generates and distributes them automatically. Monica’s team does not spend hours pulling, saving, and emailing.

The agentic workflow does not make the collections call. It makes sure that when Monica’s team picks up the phone they understand why the invoice is outstanding before the customer has to explain it again.

At Fueleo we built this into Leo, Fueleo’s AI workflow assistant, which operates across the procure-to-pay and order-to-cash workflows for fuel marketers. The PO validation. The credit surface. The exception routing. The automated statements. All of it running continuously in the background so the collections team can focus on the work that actually requires human judgment.

Monica’s January account would have been caught in week one. Not months later.

The question worth asking this week

Pull your ten oldest outstanding invoices.

For each one ask three questions:

Why is it still outstanding?

Who owns the next action?

When did the company first know about the blocker?

Then ask whether your collections team can answer those three questions without calling billing, dispatch, sales, or the customer.

If the answer is no, the problem is not collections. The workflow is creating more exceptions than the team can resolve. And no escalation template or collections cadence will fix what is being created upstream.

As I was leaving Monica said something that stayed with me.

“I have a great team. I just wish the rest of the company understood what they were sending us to fix.”

You cannot ask collections to recover cash from invoices the rest of the operation never made collectible.

That is what I hear from a lot of fuel marketers. The accounting system is slow. The invoices do not match the deliveries. The billing team spends half their day reconciling paperwork that should have been in the system already. And eventually someone in leadership says the words that start a very expensive conversation: maybe we need to replace QuickBooks.

Garrett never said that.

What he said, about three months into our conversations, was something more specific and more honest.

“QuickBooks does what QuickBooks does. Our problem is everything that has to happen before QuickBooks can do its job.”

That one sentence changed how I thought about what we were building.

What QuickBooks was actually doing

American Petroleum was not running a broken accounting system. They were running a capable one that was being asked to do something it was never designed for.

QuickBooks was handling customer records, invoices, accounts receivable, payments, bank reconciliation, and financial reporting. For a mid-market fuel marketer that has been on the platform for years, that is not a small thing. Their accounting team knew it. Their accountants knew it. Years of customer balances, payment history, and financial records lived inside it.

Replacing that to solve an operational problem would have been like tearing out a working foundation because the rooms upstairs needed renovation.

The accounting was not broken. The path to the accounting was.

What that path actually looks like

A fuel invoice looks simple from the outside. Customer received gallons. Price applied. Invoice sent.

Here is what actually has to happen before that invoice exists.

Someone has to confirm which customer placed the order and which of their delivery sites it is going to. Which product. Which truck. Which driver. Where the truck loaded. What the supplier cost was at that terminal on that day. How many gallons were ordered versus how many were actually delivered. Which pricing agreement applied, rack plus margin, cost plus, fixed contract, or something negotiated six months ago that lives in someone’s email. Whether there is a freight charge, a minimum delivery fee, an after-hours surcharge. Which fuel taxes apply. Whether the customer or that specific delivery site has a tax exemption. Whether the signed delivery ticket exists. Whether the BOL is attached.

Only after all of that does it become an invoice.

QuickBooks can record the invoice. It cannot coordinate the events that create it.

That distinction is the gap where most fuel marketing billing problems actually live. Not in accounting. In the ten steps before accounting ever sees the transaction.

What was breaking at American Petroleum

The field operation and the accounting workflow were disconnected.

Drivers completed deliveries. Dispatch knew what had been scheduled. Paper tickets contained some of the final information. Text messages contained other details. Pricing might exist in a spreadsheet, an email, or the billing manager’s memory from a conversation with the customer three months ago.

Billing then had to gather all of it together before a single invoice could go out.

When one item was missing, the invoice waited. When a driver’s handwriting was unclear, the invoice waited. When the delivered quantity did not match the original order, the invoice waited. When the pricing rule was ambiguous, the invoice waited.

Garrett’s billing team was not slow. They were capable and organized. They were just spending most of their time doing something that should not have been their job: assembling the delivery story from fragments scattered across three systems, two paper packets, and a group text.

The billing team was not the bottleneck. The missing operational layer was.

Why we did not replace QuickBooks

When we started building Fueleo around American Petroleum’s operation, the decision not to replace QuickBooks was deliberate.

Not because QuickBooks has no limits. It does. It is not a fuel dispatch system. It does not manage driver workflows or capture BOLs as part of a structured delivery record. It cannot calculate rack-based pricing or handle complex tax exemption logic. It cannot show you the difference between gallons delivered and gallons invoiced at any given moment.

But none of those limitations are reasons to replace an accounting system the team already trusts and already knows.

They are reasons to build the operational layer that sits in front of it.

The workflow we designed became:

Fueleo manages the fuel-specific process. QuickBooks remains the accounting system of record. Each platform does the work it is actually built for.

What changed at American Petroleum

The biggest improvement was not faster invoicing in isolation. It was the reduction of the operational friction that was making invoicing slow.

Before the workflow was connected, billing required several hours of manual work each day. The team collected delivery information, reviewed tickets, verified quantities, applied pricing, added fees, and entered invoices one by one.

After the workflow was connected, most of that data was already present by the time billing reviewed the delivery. The process became:

Review the completed delivery. Resolve any exception. Approve the invoice. Sync to QuickBooks.

Invoices went out closer to the delivery date. The billing team spent less time entering data. Management could finally see the difference between what had been delivered and what had been invoiced, in real time, without asking anyone.

Last year, Fueleo processed over $5 million in invoices for our design partner customers with less than 1.45% sync error rate to QuickBooks.

That number is not a demo metric. It is a live operation, real deliveries, real customers, real invoices, syncing cleanly into an accounting system the team already trusted and did not have to replace.

QuickBooks stayed exactly where it was. The operation around it became something different.

The thing Garrett said that I keep coming back to

Toward the end of one of our early conversations, Garrett said something I have repeated probably a hundred times since.

“Same-day invoicing is not an accounting feature. It is what happens when the rest of the operation is running right.”

He was correct. Same-day invoicing is not created by adding a button inside QuickBooks. It requires the order to be structured correctly before the truck leaves. It requires the driver to capture the final gallons at the delivery site. It requires the ticket to exist and be legible. It requires the pricing rule to be known before dispatch, not reconstructed by billing after the fact.

Same-day invoicing is the result of a connected operation. The accounting system just records what a connected operation produces.

What this means for mid-market fuel marketers

Large fuel companies have the budget and staff for a full ERP replacement. Small operators can manage with QuickBooks and a few spreadsheets. Mid-market fuel marketers are caught between those two worlds. Complex enough that basic accounting workflows create constant friction. Not quite large enough to justify tearing out the financial system and starting over.

That gap is where Fueleo fits.

Not as a replacement for what already works. As the operational layer that makes what already works actually work for a fuel business.

QuickBooks keeps the books.

Fueleo connects the work that creates them.

Next issue: The collections team was doing everything right. The system was making sure it did not matter.

In 2024 I flew to Denver to visit my friend Pete.

Pete runs a fueling company. He knows everyone in the industry and his opinion carries weight because he has been inside more fuel operations than most people will see in a career. When he offered to take me to see a friend who ran a bigger operation, I said yes immediately.

I went in thinking I knew what I was going to find.

Dispatch was the problem. I had been thinking about it for months. Mid-market fuel distributors running routes on whiteboards and phone calls. Drivers showing up to sites without clear instructions. Loads getting missed. Customers calling to find out where their fuel was.

I was going to see it in the field and it was going to confirm everything I had been thinking.

The Outlook calendar

We walked into the dispatch office and the owner pulled up his screen.

It was an Outlook calendar.

Every driver had the app on their phone. Recurring orders were scheduled in advance. The owner could see the day’s routes at a glance. Drivers knew their stops before they left the terminal.

I asked him about it.

“It works for us,” he said. “Every driver has it. Easy to maintain recurring orders. We have been doing it this way for years.”

He was not embarrassed. He was not describing a workaround he hoped to replace someday. He was describing a system that worked.

And he was right. Fuel was going out on time. Customers were getting their deliveries. Drivers knew where they were going.

The dispatch problem I flew to Denver to confirm did not exist.

I flew home with a lot to think about.

What I got wrong

I had made the mistake that is easy to make when you are building software for an industry you have not worked inside.

I looked at a tool and I saw a gap. I assumed that because Outlook was not designed for fuel dispatch, the people using it must be struggling.

They were not struggling. They had found something that worked and built their operation around it.

I was solving for the thing I could see. I had not yet spent enough time asking about the thing that was actually costing people money.

Two years later

In 2025 I decided to build Fueleo.

Before writing a line of code, I started having real conversations with fuel marketers. Operators, billing teams, controllers, owners. I asked them what was actually breaking in their operations. Not what looked broken from the outside. What they felt every day.

The same answer kept coming up.

The fuel always goes out on time. The invoice takes three to five days.

A driver delivers 5,000 gallons on a Tuesday morning. The customer has fuel in their tank by 10am. The invoice does not arrive until Friday. Sometimes the following Monday.

Not because anyone is being careless. Because the handoffs between delivery and invoice are long and nobody owns the gap between them.

The driver brings back the ticket. Dispatch closes the load. Billing checks the gallons. Pricing verifies the rack or contract rate. Someone checks freight, fuel surcharge, taxes, exemptions, fees. Then the invoice finally gets created and pushed into accounting.

Each step adds hours. The hours add up to days. And the cash sits unbilled the whole time.

The delivery was never the problem.

The invoice was.

What the Denver trip actually taught me

Looking back, the Outlook calendar was the most important thing I saw on that trip.

Not because it showed me a gap to fill. Because it showed me I was looking at the wrong gap.

The operator had solved dispatch in a way that worked for his operation. What he had not solved, what nobody had solved cleanly, was the three to five day window between a completed delivery and a sent invoice.

That window is where cash flow sits unbilled. Where pricing errors go undetected until the customer calls. Where customer trust quietly erodes one late invoice at a time.

I would not have understood any of that if I had walked into Denver and found the dispatch chaos I was expecting. I would have built a dispatch tool and moved on.

Instead I walked out of an Outlook calendar demo with the most important question I have asked in this industry.

If dispatch is working fine, what is actually broken?

Two years of conversations with fuel marketers gave me the answer.

What I am still figuring out

I do not think I have gotten everything right since Denver.

There are parts of the fuel distribution workflow that are more complex than I understood when I started building. The way common carrier operations handle carrier settlements. The way wet hosing billing differs from tank delivery billing. The way tax exemption compliance sits between systems that were never designed to talk to each other.

Every operator conversation surfaces something I did not account for. That is not comfortable to admit when you are building software that people are trusting with their operations.

But it is true.

The thing I am most certain about is the thing the Denver trip taught me. The best way to understand what is broken is to go see what is working and ask why.

The Outlook calendar was working. That question led me to the invoice.

I am still trying to earn the answer the same way: by walking into real operations, noticing what already works, and asking what still costs money.

Ovante Johnson knows what it is like to sit in the driver’s seat.

Before he became operations manager at Pacific States Petroleum, he drove fuel trucks himself. He has done the early mornings, the unpredictable hours, the remote delivery sites, the customer calls from the cab. He knows what the job actually requires because he has done the job.

That background matters when you are the person deciding who gets hired to do it next.

I sat down with Ovante recently to talk about something that does not get discussed enough in fuel distribution: how hard it actually is to find and keep the right driver. Not just someone with a CDL and a clean record. Someone who fits the culture, handles the complexity, and is still showing up six months later the same way they showed up on day one.

What the resume tells you before you pick up the phone

Ovante is direct about what he looks for on paper before anyone gets a call.

Red flags: multiple roles with three to six month tenures. A pattern of job hopping signals a retention risk before the interview even starts.

“Training a fuel truck driver costs real time and real money,” he said. “If someone has cycled through four companies in two years, I have to ask myself whether it is worth the investment.”

Green lights: longevity at previous companies, an active CDL, and hazmat experience. Fuel distribution experience specifically is not required.

“A driver who spent eight years at a trucking company and never touched fuel is still a strong candidate,” Ovante said. “Long tenure tells me they can commit. We can teach the fuel side. We cannot teach reliability.”

The industry-specific knowledge is learnable. The work ethic and the willingness to show up consistently is much harder to develop after the fact.

The 90-day problem

This is the part of the conversation that stayed with me longest.

I asked Ovante what the biggest challenge in hiring actually is. Not the hardest part of screening. The hardest part of building a driver team that holds together over time.

He did not hesitate.

“The 90-day mark.”

Post-COVID, the CDL pool shifted. A meaningful share of newer drivers have five or six years of experience rather than ten or fifteen. And with that shift came a different set of expectations about what the job looks like day to day.

Ovante tells every candidate upfront: do not schedule appointments on work days. Hours are unpredictable. More hours means more pay, and the company frames that as a positive rather than a burden. But the mindset required to genuinely embrace that reality is harder to screen for than any technical skill.

The interview can reveal a lot. It cannot always reveal how someone will feel about the job three months in when the initial energy has settled and the reality of the schedule sets in.

What Pacific States is actually selling

Pacific States Petroleum is employee-owned. That fact shapes everything about how Ovante talks about the company, how existing employees describe it, and how the culture gets transmitted to new hires.

“If you want to be a number, go elsewhere,” Ovante said. “If you want to be valued, come here.”

The operations manager works alongside drivers and mechanics. There is no practical title hierarchy in the day to day reality of the operation. The president knows the drivers by name. The culture is hard-working and emergency-driven, because fuel distribution does not run on a predictable schedule, but it is also a community.

That community is transmitted peer to peer. Existing drivers, dispatchers, and managers carry the narrative organically. The company does not force a culture deck on new hires. The culture is absorbed by working alongside the people who already live it.

What this means for the industry

The fuel distribution driver shortage is real but it is not simply a supply problem. There are CDL holders in the market. The challenge is finding the ones whose expectations align with what the job actually requires, and retaining them once they understand what that means in practice.

The operators who figure this out first are not necessarily offering the highest pay. They are offering something harder to replicate: a clear culture, honest expectations, and a team environment where the work feels worth doing.

Pacific States has built that. It did not happen by accident. It happened because people like Ovante, who drove the trucks before they managed the teams, understand what the job actually asks of the people doing it.

The hiring problem in fuel distribution is not that there are no good drivers. It is that finding the ones who will still be there at the 90-day mark, and the year mark, and the five-year mark, requires more than a CDL check and a phone screen.

It requires knowing what you are actually hiring for. And being honest about it before anyone signs an offer letter.

The question worth asking if you hire fuel drivers

What do you tell candidates about the hours before they accept the offer?

And more importantly: do you tell them in a way that actually prepares them for a Tuesday in February, or in a way that sounds manageable until it isn’t?

The 90-day problem is almost always a conversation that did not happen clearly enough in the first three weeks.

Next issue: I went to Denver looking for a dispatch problem. I found an Outlook calendar.

I’ve spent the last year sitting beside dispatchers, billing clerks, controllers, and fuel company owners. I ask them one question over and over:

“When did you last lose a customer and actually know why?”

It is the thing I do most in this industry. Not building. Not selling. Asking.

The answers are almost always the same. A contract ended. A competitor undercut the price. The customer moved operations out of the area.

What almost nobody says is: we lost them because billing kept making small errors and the customer got tired of checking.

Not because it does not happen. Because they usually do not find out until it is too late.

One story keeps coming back to me

An ops director in Texas told me about a construction company that had been a customer for six years. Consistent volume. Paid within terms. Never caused problems. The kind of account you stop worrying about because it has always taken care of itself.

The customer never called to complain. Not about the first billing error. Not about the second. Not about the third.

He just stopped answering when the sales rep called. Payments that used to come in at net 28 started arriving at net 38, then net 45. Volume dropped thirty percent over four months. Nobody flagged it.

When he finally said he was moving to a different supplier, the ops director asked why.

“The invoices were always a little off,” he said. “Not by a lot. But every month there was something. I just got tired of having to check.”

Six years. Three billing errors. Not a single escalation.

25 out of 26

Lee Resource found that 25 out of 26 dissatisfied customers never complain.

They simply leave.

That number hits differently in the context of fuel distribution.

In fuel distribution, customers often cannot verify what they received. They were not at the site. They do not own the metering equipment. They are trusting your numbers.

Every small billing mistake becomes another entry in a mental ledger.

The wrong rack differential applied to a load. The freight surcharge pulled from last month’s rate table. Dyed diesel billed with the wrong tax treatment. Each one small enough to pay without calling. Each one just large enough to remember.

They do not call to tell you the ledger tipped. They just stop calling to order

What I keep hearing about how errors go unconnected

When I ask billing teams about disputes they almost always describe individual incidents. A credit was issued. The ticket was closed. Everyone moved on.

What I rarely hear is someone describing those incidents as a pattern connected to a specific customer’s experience over time.

The wrong rack differential applied to one load. Caught and credited. Nobody asked whether the same pricing logic had run on other accounts that month.

A late invoice because dispatch closed the load a day behind. The customer’s payment came in late. Billing noted the slow payment. Nobody connected it to the late invoice.

A volume discrepancy. The invoice said 4,200 gallons. The customer’s equipment logs said 4,050. The customer paid and made a note to watch. They did not call.

Three events. Three systems flagged them. Nobody’s job was to connect them.

That is how a six-year customer becomes a loss without a single escalation.

The AR report is telling you something nobody is reading

When I ask ops directors and controllers to walk me through accounts that started paying slower before they left, the pattern is almost always visible in hindsight.

First, payment timing drifts.

Then, volume softens.

Finally, the customer disappears.

Nobody connected those two things to the billing friction that had been happening on the account for months.

When a historically reliable fuel customer starts paying slower, it is worth asking a different question before it goes to collections. Sometimes it is cash flow. Sometimes it is their AP process.

But often it is a relationship signal hiding inside the AR report.

A customer moving from net 28 to net 45 may not look like churn. But in fuel operations, payment drift is often one of the first visible signs that trust is weakening.

What one AR manager told me

I was sitting with an AR manager at a mid-market distributor last year. I asked her how she knew when an account was starting to go sideways.

She thought about it for a moment.

“Honestly? When they stop calling about errors.”

I asked her to explain.

“When a customer disputes an invoice, it means they are still engaged. They care enough to call. When a customer stops disputing and just starts paying slow, that is when I get nervous. It usually means they have already decided something.”

That observation stayed with me.

The customer who calls to dispute an invoice is giving you a chance to fix the relationship. The customer who stops calling has already made a decision you do not know about yet.

The retention problem starts upstream of AR

When I talk to owners and ops directors about customer retention, the conversation almost always focuses on sales. Who is calling the account. When did the last check-in happen.

What rarely comes up is the operational chain the customer experiences every single time they receive a delivery.

Dispatch accuracy. Delivery confirmation. BOL capture. Pricing logic. Tax handling. Invoice timing. AR follow-up.

The customer experiences all of that as one thing: can I trust this supplier to get it right without making me chase them?

The fix is not another sales call. It is a connected workflow where delivered gallons, BOLs, contract pricing, taxes, fees, credits, and invoices are checked before the customer ever sees the bill. When those pieces connect, exceptions surface before the invoice goes out. The credit gets issued before the customer notices the discrepancy. The mental ledger never starts.

The more time I spend inside fuel companies, the more convinced I become that customer retention is not primarily a sales problem. It is an operational visibility problem.

The question worth asking this week

Look at your top twenty accounts by volume. For each one:

Is their payment timing faster or slower than six months ago?

Has their volume changed in the last ninety days?

How many billing credits have they received in the last year and were those reviewed as a pattern or resolved as individual tickets?

If you cannot answer those three questions without pulling data from multiple systems, you do not have a customer retention problem yet. You have a visibility problem. And the retention problem is building quietly underneath it.

The warning signs were never hidden.

They were sitting in dispatch.

In billing.

In AR.

In delivery tickets.

In credit memos.

Every department saw one piece.

Nobody saw the story.

Maria runs billing for a mid-market fuel distributor in Central Texas. Her company delivers dyed diesel to agricultural customers, construction sites, and equipment rental companies across the region.

Every customer has an exemption on file. An AG number. A DD number. A signed statement. Maria tracks all of it in a spreadsheet: customer name, exemption type, number, expiration date, last delivery date.

She updates it when she remembers. She checks it when someone asks.

Three weeks ago, a large agricultural customer called. Their latest invoice had a tax charge that wasn’t there before. Maria pulled the spreadsheet. The customer’s AG exemption had expired forty-two days earlier. Nobody had noticed. The driver didn’t know to check. Five loads had gone out in that window, tax-exempt, against an invalid certificate.

The spreadsheet had the expiration date. The dispatch system had the delivery dates. The billing software had the invoices. Three systems, all holding a piece of the answer, none of them talking to each other.

The three-system problem nobody designed

Billing applies tax treatment based on the customer record. If it says exempt, the invoice goes out exempt. It doesn’t check expiration dates. It wasn’t built to.

Dispatch assigns drivers, routes, and loads. It has no visibility into exemption status. Compliance isn’t dispatch’s job.

The spreadsheet is supposed to be the bridge. But it’s passive. It doesn’t know when a load gets dispatched. It doesn’t update when a delivery happens. It only knows what someone typed into it, and it only gets checked when someone remembers to look.

The certificate expired on a Tuesday. No alert fired anywhere. The driver picked up Wednesday’s load the same way he always had. By the time Maria found the problem, it was forty-two days and five deliveries old.

What Texas actually requires

Texas taxes diesel at twenty cents per gallon removed from a terminal, unless exempted by law.

An agricultural end user number allows up to 25,000 gallons of tax-free dyed diesel per month. A non-agricultural end user number caps at 10,000 gallons per month.

These limits reset every calendar month. They are not cumulative across the year.

Violations can exceed $10,000 per incident, plus back taxes. Federal penalties start at $1,000 per violation or $10 per gallon of improperly used fuel, whichever is greater, and apply to each separate incident.

Five loads against an expired exemption isn’t one incident. It’s five.

Two questions, asked at the wrong time

1. Is the certificate valid right now?

Not when the account was set up. Today. AG and DD numbers expire and get revoked regularly. Most billing teams check at onboarding, maybe annually. Almost nobody checks before every delivery, and dispatch certainly doesn’t, because dispatch doesn’t have the spreadsheet.

2. Has the customer hit their monthly limit?

This requires pulling delivery history, summing exempt gallons, and comparing against the spreadsheet’s stated limit. At fifty or a hundred deliveries a day, that manual cross-check doesn’t happen consistently. It can’t. There aren’t enough hours.

What an audit actually looks for

Fuel unaccounted for is presumed to have been sold or used for taxable purposes. The burden is on the distributor to prove an exemption was valid, not on the auditor to disprove it.

An auditor wants the valid certificate at the time of each delivery, proof it hadn’t expired, a month-by-month gallon count against the limit, and an invoice that reflects it correctly. If any of that is missing, you’re looking at back taxes, penalties, and interest, not just an awkward conversation.

The auditor does not care that the data was scattered across three systems. That’s your problem to solve, not theirs to accommodate.

What it would have cost

Five loads, roughly 4,000 gallons each, 20,000 gallons total.

State tax exposure alone: $4,000.

Federal exposure at the per-gallon rate: up to $200,000, in a worst-case reading.

In practice, enforcement varies, and a proactive first-time fix is treated differently than a pattern of evasion. But the asymmetry is the point:

The cost of the failure dwarfs the cost of the system that would have prevented it.

What actually closes the gap

Not a better spreadsheet. Not a fourth system. The exemption data has to live inside the same record dispatch and billing both use.

When a load is assigned to an exempt customer, the system checks the certificate automatically. Expired or expiring within thirty days, the load doesn’t move without a documented override. Every closed delivery updates the customer’s monthly exempt gallon total automatically. Approaching the limit triggers a flag both billing and dispatch can see.

The compliance logic has to live inside the workflow, not next to it.

The question worth asking this week

Pick your ten largest dyed diesel customers in Texas. For each: when does their certificate expire, how many exempt gallons have they taken this month, and how close are they to the limit?

Now ask where each answer comes from. Spreadsheet? Billing? Dispatch?

If you need three places to answer three questions about one customer, the compliance information isn’t in your workflow. It’s in the gap between your systems.

Maria got lucky. The customer called before the auditor did.

For the current Texas exemption rules, gallon limits, and registration forms referenced in this issue, see the Texas Comptroller's diesel fuel page: comptroller.texas.gov/taxes/fuels/diesel.php

In fuel distribution, dispatch is not just putting trucks on a schedule.

It is where customer promises, driver judgment, terminal constraints, delivery windows, and billing consequences all meet.

Jenny had been dispatching for the same petroleum distributor in Eastern Washington for fourteen years.

She knew every driver by name, by habit, and by the way each one sounded when something was about to go wrong on a route.

She knew which driver could handle a tight downtown delivery without getting frustrated. She knew which driver preferred certain routes because he understood the sites better. She knew which customers needed a call before the truck arrived. She knew which roads flooded in March. She knew which site had a gate code that changed every few months but never made it into the system.

She knew which terminals moved fast in the morning and which ones backed up by noon.

She knew which customer would complain if the delivery happened after 6am because their yard became too congested.

She knew which wet hose account had equipment spread across three lots even though the order only showed one address.

She knew which driver needed a warning before going to a difficult site.

And she knew the little dispatch decisions that prevented bigger problems later in billing, customer service, and operations.

None of this was documented.

It was just known. Because Jenny knew it.

The company threw her a retirement party on a Friday in October. Cake. A card signed by everyone. A gift card to a place she liked. Her manager gave a speech about what she meant to the operation.

Three weeks later, dispatch started breaking.

What breaking looks like in fuel dispatch

It did not happen all at once.

That is the thing about losing dispatch knowledge. It rarely shows up as one dramatic failure. It shows up as friction across the day.

A driver called from a customer site with a question about the tank setup. Jenny would have known the answer immediately. The new dispatcher searched the system, found nothing useful, called the customer’s main office, and waited.

The driver sat for twenty minutes.

That twenty minutes did not stay isolated. It pushed the next stop. It changed the route. It created another customer call. It made the driver irritated. By the end of the day, one missing site note had become a dispatch problem, a customer service problem, and a driver morale problem.

Another customer complained that the truck arrived too late. The new dispatcher had scheduled the delivery at 9am because, on the route board, that made the most sense.

But Jenny had always known this customer needed delivery before 6am. Their yard became too busy after that. The truck blocked movement. The customer’s team got frustrated.

It was not a written rule. It was a dispatch rule Jenny had carried in her head for years.

The third week, a pricing exception that had been applied manually every month for three years was missed. Not because anyone was careless. Because the exception lived in Jenny’s head, attached to no record anyone else could find, applied correctly every single month for years by a person who was no longer there.

The fourth week, the operations manager sat down and tried to write down everything Jenny knew. He got through about a third of it before he realized he did not actually know what he did not know.

Dispatch is where hidden rules live

In fuel distribution, dispatch is not just a calendar.

Real dispatch is full of hidden rules.

Customer delivery windows. Tank access instructions. Driver-site fit. Terminal preferences. Branded supplier constraints. Weather-related route judgment. Product availability. Runout risk. Equipment limitations. Truck compartment planning. Split-load decisions. Customer communication preferences. Site safety issues. Special instructions that never make it into the order.

This is why dispatch is one of the most knowledge-heavy parts of a fuel operation. The dispatcher is constantly answering questions the system does not fully understand:

Can this customer wait until tomorrow? Can this driver handle that site? Will that terminal be too slow by the time the truck gets there? Can this order be combined with another stop? Is this actually urgent, or does the customer always say it is urgent? Will this delivery create a billing exception? Will the driver have enough product left after the first drop?

Jenny knew these answers because she had lived through them.

The software had records. Jenny had context.

Why dispatch knowledge disappears

Most companies do not intentionally lose dispatch knowledge. They just never capture it.

The dispatcher is too busy moving trucks. The driver calls. The customer calls. A terminal delay changes the plan. A load gets rejected. A truck breaks down. A customer needs an emergency delivery. The dispatcher solves the issue and moves on.

That is the job.

But every time a dispatcher solves something manually and the reason is not captured, the company loses an opportunity to turn experience into process. The knowledge stays in the person. Not in the customer record. Not in the site profile. Not in the route plan. Not in the next dispatcher’s hands.

As long as Jenny was there, nobody felt the pain.

Why document what you can just ask? That is the trap. The best dispatcher makes the system feel better than it actually is.

Software training is not dispatch handover

When companies train a new dispatcher, they usually focus on the visible workflow.

Here is how to create an order. Here is how to assign a driver. Here is how to move a delivery. Here is how to update a route. Here is how to close out the day.

That matters. But that is not the hard part of fuel dispatch.

The hard part is knowing why the route should be built a certain way. Why one driver should go to a certain customer. Why one site must be delivered before sunrise. Why one terminal should be avoided after 10am. Why one customer needs a phone call before the truck leaves. Why a simple dispatch change may create a billing issue later.

A new dispatcher can learn the software in a few weeks. They cannot absorb fourteen years of customer behavior, driver preferences, terminal quirks, site constraints, and operational judgment in a short handover.

The company thinks it transferred the job. But it only transferred the screens.

The cost of weak dispatch knowledge

When dispatch knowledge is missing, the cost does not always show up as a failed delivery. It shows up in smaller ways first.

Drivers wait. Routes get rebuilt. Customers call for updates. Dispatchers make extra phone calls. Managers get pulled in. Invoices need corrections. Customer service has to explain what happened. Drivers lose confidence in the plan.

And then the dangerous one.

Customers start feeling like the company no longer knows their operation.

Fuel customers often do not judge you only by whether the fuel arrived. They judge you by whether the delivery fit their operation. Did the driver know where to go? Did dispatch understand the delivery window? Did the company remember the site constraint? Did they have to explain the same thing again?

When Jenny was there, the customer felt known.

After Jenny left, the customer started feeling like a new account again.

That is how dispatch knowledge becomes customer retention.

What fuel marketers should actually capture

The answer is not to ask dispatchers to write long manuals. That will not happen consistently.

The answer is to capture dispatch knowledge inside the normal workflow. At minimum, every fuel marketer should be capturing:

• Customer delivery windows

• Site access instructions

• Tank and asset notes

• Preferred driver or driver restrictions

• Terminal and supplier preferences

• Product-specific handling notes

• Emergency delivery rules

• Recurring route logic

• Customer communication preferences

• Weather or seasonal route issues

• Special billing or pricing flags dispatch needs to know before delivery

• Driver feedback after difficult deliveries

These should not live in notebooks, text messages, or one person’s memory. They should be attached to the customer, site, order, route, asset, and delivery record.

Dispatch should not have to remember everything. The system should help dispatch remember.

The dispatch test every operator should run

Pick your most experienced dispatcher. Then ask:

If this person could not work for the next three weeks, what would break?

Would another dispatcher know which customers need early deliveries? Would drivers know the site instructions? Would someone know which routes are easy on paper but painful in reality? Would terminal-specific issues be visible before the truck is sent? Would customer communication preferences be clear? Would dispatch know which customers are sensitive, which ones are flexible, and which ones require careful handling?

If the answer is no, the operation is not fully running on a dispatch system. It is running on dispatch memory.

That may work for years.

Until Jenny retires.

The question worth asking this week

The operations manager in Eastern Washington eventually got most of it sorted. It took longer than it should have and cost more than anyone planned. Two customer relationships required active repair work. One took a credit note and a personal call from the owner.

None of that cost appeared on any report. It was absorbed quietly, across dozens of small decisions and extra hours and conversations that should not have been necessary.

When she does retire, the problem will not be that the new dispatcher does not know the software. The problem will be that the software does not know what Jenny knew.

The next Jenny is already somewhere in your fuel operation. She is moving trucks, calming drivers, protecting customer relationships, avoiding terminal delays, remembering site rules, and preventing billing problems before anyone else sees them.

The question is whether that knowledge becomes part of the dispatch system, or walks out the door with her.

Next issue: Why fuel marketers lose customers in silence. Not because of bad fuel or missed deliveries. Because billing friction slowly erodes trust until the customer stops calling.