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.

One bar. Maybe two, depending on where the truck is parked. It is not going to get better once he is on the route, not in the stretches between stops where the cell towers thin out and the app spins on a loading screen that never quite finishes.

He has been driving for a fuel distributor in the Southeast for six years. The company rolled out a driver app eighteen months ago. Real-time delivery confirmation, signed delivery tickets, rack BOL photos, GPS-stamped timestamps, all of it flowing straight into billing. On paper, exactly what billing needed to stop waiting three days for a paper ticket to make its way back to the office.

Danny still carries a paper ticket book in the truck door.

Not because anyone told him to. Because by his second week with the app, he had already learned the things nobody mentioned in training.

What the app actually requires of him

A delivery for Danny looks like this. Pull into the site. Find the right tank, because not every customer labels them clearly and not every drop is a single tank, sometimes it’s a split drop across two or three tanks from the same compartment. Connect the hose. Start the pump. Watch the meter while it runs, because customers notice if you are looking at your phone instead of the tank.

Somewhere in there, the app wants him to confirm the customer, the product, the tank, the compartment, the starting meter reading, the ending meter reading, the gallons delivered, and whether the drop matched what dispatch actually sent him out for, because sometimes a stop changes mid-route and the order on his phone doesn’t match what the customer is asking for when he pulls in.

He is wearing gloves most months of the year. The touchscreen does not reliably register a gloved finger, so the gloves come off, which means cold hands in winter and the gloves get set down somewhere, usually on top of the tank or the truck step, where they sometimes get forgotten.

The screen is hard to read in direct sun, which is most of his working day. He has learned to angle his body to throw a shadow over the phone just to see what he is tapping.

And if the signal drops mid-entry, which happens at a meaningful number of his stops, the app does not always save what he has entered. Sometimes it does. Sometimes he gets to the next stop and finds the previous delivery sitting in a queue, unsynced, with no clear indication of whether it actually went through.

None of this is a single dramatic failure. It is friction. Thirty seconds here. A minute there. Multiplied across eight to twelve stops a day, it adds up to real time, and more importantly, it adds up to real doubt about whether the app actually captured what happened.

Why the paper ticket survives

The paper ticket does not require a signal. It does not care about gloves. It does not have a loading screen.

Danny writes the numbers down because he trusts what he can see with his own hand on a piece of paper more than he trusts an app that has eaten an entry before. If the app captures the delivery cleanly, great, that is one less thing he has to think about. If it does not, the paper ticket is the backup that makes sure the customer gets billed correctly and he does not get a call from dispatch asking where a load went.

Paper survives because it is reliable, not because drivers are nostalgic.

Over time, the backup became the primary, and the app became the thing he updates when he remembers and has signal.

He is not being defiant. He is doing what any reasonable person would do when a tool fails them often enough: he stopped trusting it as the only system of record and built a workaround that he controls.

In one of my conversations with Stephanie McAnally, a seasoned C-suite leader in the fuel industry, she said something that reframed how I think about this.

“My drivers do their work diligently. They do the paperwork before and after delivery. They make sure it is correct. So if they are resisting a driver app, I don’t see that as a driver problem. I see it as an adoption problem.”

That distinction matters.

A driver who has spent years doing paperwork correctly, loading accurately, delivering cleanly, and making sure the numbers match before handing in the ticket at the end of the shift is not someone who doesn’t care about getting it right. That driver has already proven they care about getting it right. The paper process earned their trust over years of consistent, reliable use.

When that same driver resists an app, the question worth asking is not “why won’t they change” but “what did the implementation process miss?”

Drivers resist when the new workflow creates doubt where the old one created confidence. That is not a driver failure. That is a signal that the technology wasn’t introduced in a way that earned the same trust the paper process had already built.

The only way to close that gap is for the technology to be developed and implemented with every stakeholder involved. Not handed down. Not rolled out in a training session. Built around the actual workflow the driver lives in, tested in the field, and refined until the driver’s natural instinct is to reach for the app the way they used to reach for the ticket book.

Technology changes workflows. Trust drives adoption.

This is the part that almost never gets surfaced back to the people who bought the app. Nobody in the back office sees Danny’s paper ticket book. They see the app’s adoption dashboard, which shows him logging deliveries most days, just with gaps, just with timestamps that sometimes don’t match when the delivery actually happened, just with entries that were backfilled from memory at the end of a long shift using the paper numbers as reference.

The dashboard says adoption is around 70%. What it does not show is that 70% adoption with frequent backfilling is not the same thing as 70% of deliveries being captured accurately at the point of delivery, which was the entire reason the app got bought.

Where this actually costs money

This is not just a story about a frustrated driver and a clunky app.

The cost is delayed invoicing. Disputed gallons because the meter reading entered into the app doesn’t match what’s on the paper ticket, and now someone in billing has to figure out which number is correct before the invoice can go out. Billing staff calling drivers to confirm a delivery that should have already been confirmed automatically. Dispatchers reconstructing what happened on a route because the app shows a gap and nobody remembers the details three days later.

In fuel, bad field data does not stay in the field. It moves downstream into billing, margin, inventory, and customer trust.

The natural fix to the driver-as-data-entry-clerk problem is a driver app. But that fix only works if drivers actually trust and use it the way it was designed. If the app gets used inconsistently, with paper as a silent backup, the original problem has not been solved. It has been relocated, and now there are two records to reconcile instead of one.

Where driver apps actually fail

This is not a story about drivers resisting technology. Most drivers, including Danny, would genuinely prefer a tool that worked reliably over a paper ticket book that gets soggy in the rain and has to be physically transported back to the office.

The failure is almost always in the gap between how the app was designed and how a delivery actually happens in the field.

Screens designed for office fingers, not diesel gloves. Most fuel distribution driver apps were not purpose-built for the conditions drivers actually work in. They were adapted from generic field service or delivery software, with input methods that assume a controlled environment.

Connectivity assumptions that don’t match rural and industrial delivery routes. A meaningful share of fuel deliveries happen at sites with poor cellular coverage. Industrial yards, rural agricultural operations, wet hose jobs where the driver is moving asset to asset, not tank to tank. An app that requires a live connection to confirm a delivery is an app that will fail at exactly the locations where reliable data capture matters most.

Forms that ask for ten fields while the driver is watching a meter, managing a hose, and trying not to block the customer’s yard. Every additional required field is an additional point where the driver either slows down significantly or starts entering placeholder data just to get past it.

No clear signal of what happened to an entry. When a driver submits a delivery and the app does not clearly confirm it was received and synced, the driver has no way to know whether the data made it anywhere. That uncertainty is what brings the paper ticket back as a hedge.

What actually changes adoption

The fuel distributors who get real adoption, not dashboard adoption, but drivers genuinely trusting the app as the system of record, tend to have solved a narrower set of problems than the feature list on most driver app sales decks would suggest.

The app works offline and syncs when signal returns, without losing data or creating ambiguity about whether an entry went through. This single fix addresses the root cause of most paper-ticket-as-backup behavior. If a driver can trust that an entry made with no signal will sync correctly later, the entire reason for keeping a parallel paper system disappears.

The interface is built for the conditions, not adapted to them. Larger touch targets that work with gloves. High contrast displays readable in direct sunlight. Minimal required fields for a standard delivery.

Confirmation is immediate and unambiguous. The driver sees, clearly, that the delivery was captured. Not a spinning icon. A confirmation that removes the doubt that drives backup behavior.

The data the driver enters is the data billing uses, with no second transcription step. If drivers know their entry goes directly into billing and inventory with nobody re-keying it later, the app feels like it matters. If they sense someone in the back office will double check their entry against a paper record anyway, the incentive to be careful erodes.

Adoption is not a training problem. It is a trust problem. Drivers will use a tool reliably the moment they trust it more than the alternative they already know works.

The metric that actually matters

Most fuel distributors measure driver app success by login frequency or entries per day. Those numbers can look healthy while the underlying problem, accurate data capture at the point of delivery, remains unsolved.

A better metric is delivery-to-sync time: the time between the actual delivery completion and when clean delivery data is available for billing, inventory, and customer documentation.

If a stop was completed at 10:15am but entered at 4:40pm, that is not real-time capture. That is end-of-day reconstruction wearing a digital costume.

Another honest metric is the rate of manual correction. How often does someone in billing or dispatch have to adjust, override, or cross-reference an app entry against some other source. A high correction rate, even alongside high login frequency, means the app’s data is not trusted internally either, which mirrors exactly what is happening with the driver in the field.

Four questions worth asking about your own driver app

A driver app that actually replaces paper has to answer four questions clearly.

1. Can the driver complete the stop with no signal?

2. Can the driver see exactly what is saved, synced, and still pending?

3. Can billing invoice from that entry without re-keying anything?

4. Can exceptions be separated out without holding up the clean tickets behind them?

If the answer to any of these is no, the paper ticket is still doing the real work, no matter what the adoption dashboard says.

Danny still keeps the paper ticket book in the truck door. He still puts gloves on and off a dozen times a day. He still loses signal in the same three spots on his route, every single day.

Nobody designed the app to fail him specifically. The people who built it had never stood at a tank with cold hands trying to read a phone screen in direct sun, managing a hose, watching a meter, all while a customer waited.

What Stephanie said is the right frame for all of it. Danny’s drivers do their work diligently. They always have. The paper process earned their trust over years. The app hasn’t earned it yet.

That is not a driver problem. That is an implementation problem. And the only way to fix it is to build and roll out the technology the way trust is actually built, with the people who have to use it, around the workflow they actually live in, until reaching for the app feels as natural as reaching for the ticket book.

Technology changes workflows. Trust drives adoption.

The question worth asking this week

Pull the adoption dashboard for your driver app. Then pull a sample of delivery timestamps and compare them to when the deliveries actually happened, if you have any way to verify that independently.

If there’s a meaningful gap, you don’t have an adoption problem. You have a trust problem, and the dashboard is hiding it.

Ask one driver, off the record, whether they still carry a paper backup. The answer will tell you more than any usage report

I spent it on a plane.

And somewhere between wheels up and landing, I kept thinking about the fuel operators I’ve gotten to know. The ones running dispatch at 5am. The ones on the phone with a driver at 9pm because a delivery went sideways. The ones who haven’t taken a full weekend off since summer 2019.

This industry doesn’t pause for Father’s Day.

Rack prices don’t care. Customers with low tanks don’t care. The driver who called out sick definitely doesn’t care.

So the operator picks up the phone. Again.

Not because they don’t love their family. Because they built something that depends on them showing up. A business that employs people. That keeps hospitals warm. That keeps fleets moving. That keeps towns running through February.

That’s not workaholism. That’s responsibility at a scale most people don’t understand.

I’ve sat across from enough fuel marketers to know: the guilt is real. Missing the game. Missing the recital. Explaining to a kid why a parent has to go check on a terminal issue on a Sunday.

“Yesterday, while I was on a plane, my son earned his Taekwondo belt. I wasn’t there. But he knew I was proud. That’s the quiet bargain every working parent carries.”

But I’ve also seen what they’re building. The pride in knowing their routes cold. The satisfaction when the month closes clean. The quiet confidence of someone who has kept the lights on for their customers through every shortage, every price spike, every snowstorm.

To every fueler who showed up this weekend when they wanted to be somewhere else: your kids will know what you built. Not today, maybe. But they will.

Happy belated Father’s Day. And to every parent in this industry, happy belated to you too.

Go home early this week. You’ve earned it.

A truck delivers 4,200 gallons in the morning.

The driver has the ticket. Dispatch knows the load is done. The customer expects the invoice.

But billing is still waiting.

Waiting for dispatch to close the load. Waiting for the ticket to come in. Waiting for pricing to be checked. Waiting for someone to confirm that the invoice will not create a problem downstream.

That is how same-day invoicing dies.

Not in the software.

In the handoff.

Every fuel distributor I have talked to wants to invoice faster. Most of them cite the same barriers. The driver’s ticket comes in late. Dispatch hasn’t closed the load yet. Pricing needs to be verified before billing can run. The system doesn’t always sync cleanly with accounting.

All of those things are real. None of them are the actual reason same-day invoicing doesn’t happen.

The actual reason is simpler and harder to fix than any of them.

The process was never designed around same-day invoicing as a non-negotiable standard. It was designed around getting invoices out eventually, and eventually became the culture.

Same-day invoicing does not mean every invoice goes out blindly. It means standard deliveries move without unnecessary human delay, and true exceptions are separated from the normal flow.

What “eventually” actually costs

I wrote about this in the first issue of The Fuel Stack.

A mid-market distributor running 250 deliveries a month with a 3-day billing lag has roughly $95,000 in delivered-but-unbilled revenue sitting in limbo at any given moment. Across the year, $11.4M in revenue passes through a delayed billing workflow.

The exact number will vary by gallons, customer mix, fuel price, and delivery size. But the point does not change.

Delivered fuel that has not been invoiced is completed work still waiting to become collectible revenue.

That number is not an argument for faster software. It is an argument for a different commitment.

It is not sitting there because the software is slow. It is sitting there because the process was designed to let it sit there. Dispatch closes loads when they get to it. Billing waits for dispatch. Pricing gets verified after the fact. Every one of those steps has slack built into it, because nobody ever made same-day invoicing the standard that the entire process was built around.

When you build a process around “get it out as soon as we can,” same-day invoicing is a goal. When you build it around “the delivery is not complete until the invoice goes out,” same-day invoicing is an outcome.

Those are two different processes. Not two different software products.

The commitment question

The most useful question to ask about same-day invoicing is not “does our software support it?”

In many cases, the system is capable of producing the invoice faster than the organization is capable of trusting the workflow.

The useful question is:

Has the organization actually committed to same-day invoicing as a non-negotiable standard, and has the process been rebuilt around that commitment?

Those are two different things.

A lot of fuel distributors have expressed a preference for same-day invoicing. They would like it to happen. They have talked about it in operations meetings. Some have tried to push billing to move faster.

Very few have made it a standard in the way that changes how every upstream decision gets made.

A preference changes the goal. A commitment changes the process.

What a commitment to same-day invoicing actually requires

When same-day invoicing is a real standard, not an aspiration, it forces three upstream decisions that most fuel operations have never made cleanly.

Decision one: when does billing start?

In most operations, billing starts when dispatch closes the load. Dispatch closes the load when they get around to it, usually at the end of a busy dispatch window, or when someone reminds them, or when billing asks.

If billing starts when dispatch closes the load, same-day invoicing is hostage to dispatch’s schedule.

The real question is not whether dispatch has closed the load. The real question is: what event in the operation creates billing readiness?

In a same-day invoicing operation, billing readiness is not a mood, a reminder, or an end-of-day task. It is triggered by an operational event.

Delivery confirmation.

The decision that changes this: billing starts when the driver confirms the delivery. Not when dispatch closes the load. The delivery confirmation is the trigger. Dispatch close-out is a separate administrative step that happens in parallel, not in sequence before billing can move.

That one decision eliminates the most common single-point delay in the billing workflow.

Decision two: when is pricing finalized?

In most operations, the answer is: before the invoice goes out. Which means someone in billing is verifying pricing, checking contract terms, confirming rates, after the delivery has already happened.

That feels safe. It is also a workflow design choice that makes same-day invoicing structurally difficult.

In fuel, pricing is not a single number. It may include rack, margin, freight, surcharge, contract terms, product type, tax treatment, and customer-specific rules. If all of that is being reconstructed after delivery, billing is not invoicing. Billing is reverse-engineering the order.

The decision that changes this: pricing is finalized at dispatch, not at billing. The rate that goes on the load ticket is the rate that appears on the invoice. Billing does not rebuild the commercial agreement from scratch. It inherits a price that was already validated before the truck rolled.

If the price is wrong, you want to know before the driver leaves the terminal. Not after the delivery. Not when the customer calls. Before the truck rolls.

Decision three: what is an exception and what is a policy?

Every fuel operation has exceptions. Loads that get split mid-route. Customers who change delivery instructions after dispatch. BOL volumes that don’t match what was scheduled. Contract terms that are under review. Missing common carrier tickets. Freight discrepancies. Tax questions.

The question is whether those exceptions are genuinely rare, or whether they happen often enough that billing holds every invoice pending review just in case.

If billing reviews every invoice before it goes out because exceptions are frequent, the review step is not exception handling. It is the process. And a process that reviews every invoice before it goes out cannot invoice same day at volume.

The decision that changes this: trust the process for standard deliveries, and create a specific exception queue for the deliveries that genuinely need review.

A real exception queue should be specific: missing ticket, BOL mismatch, price conflict, gallons variance, tax issue, customer dispute, common carrier document missing, freight discrepancy.

If the reason cannot be named, it should not be allowed to hold the invoice.

Most invoices should clear without human review. The ones that don’t should be flagged automatically and handled as a small subset, not as the default.

If your exceptions are common enough that reviewing every invoice feels necessary, the exceptions are not the problem. The process that creates them is.

Same-day invoicing is a trust test

Same-day invoicing is ultimately a trust test.

Does billing trust the delivery data? Does billing trust the price? Does accounting trust the sync? Does the customer trust the invoice?

If the answer is no, the invoice waits.

The solution is not to tell people to move faster. The solution is to make the upstream workflow trustworthy enough that waiting is no longer necessary.

That is why same-day invoicing is such a useful operating standard. It exposes every weak handoff before billing.

If tickets are late, it shows up. If pricing is unclear, it shows up. If contract terms live in someone’s head or in a spreadsheet nobody fully trusts, it shows up. If accounting sync issues create duplicate invoices, it shows up.

Same-day invoicing does not create those problems. It reveals them.

Why technology keeps getting blamed

When same-day invoicing doesn’t happen, the instinct is usually to look at the software.

The dispatch system doesn’t integrate well enough with billing. The driver app doesn’t push data in real time. The accounting sync creates duplicates. The pricing module can’t handle the contract complexity cleanly enough to be trusted without a manual check.

All of those things can be true. Better software helps. Integration reduces friction. A driver app that confirms deliveries in real time and pushes data directly to billing eliminates a whole category of delay. A pricing system that handles rack, margin, freight, surcharge, contract terms, tax rules, and customer-specific logic reduces the need for manual review.

But here is what software cannot do.

Software cannot make same-day invoicing a standard if the organization has not committed to it as one.

A better dispatch integration speeds up the handoff between dispatch and billing. But if dispatch’s culture is still to close loads at the end of the day when things settle down, a faster integration just moves slow data faster.

A driver app that confirms deliveries in real time eliminates the ticket-comes-in-late problem. But if billing is still waiting for someone to manually verify pricing before the invoice runs, real-time delivery confirmation doesn’t change when the invoice goes out.

The technology upgrades are real. The efficiency gains are real. But they are downstream of the commitment.

The commitment has to come first. The technology serves the commitment. It cannot substitute for it.

The operators who have figured this out

The fuel distributors invoicing same day consistently are not all running the same software.

Some are running QuickBooks. Some are running mid-market ERPs. Some are using purpose-built fuel distribution platforms. The software varies. What doesn’t vary is the operating model.

Most operations move through three stages.

The mistake is thinking stage two is transformation. It is not. It is pressure. Stage three is the operating model.

And critically, the operators who have figured this out measure it. Not anecdotally. Not by feel. They know their same-day invoice rate. They know their dispute rate. They know which customers, which drivers, which product types, and which delivery workflows create billing delays or errors.

What gets measured gets managed. What gets managed gets done consistently.

The question that actually matters

Before the next conversation about invoicing software, billing systems, or dispatch integrations, one question is worth asking internally.

Has the organization actually committed to same-day invoicing as a non-negotiable standard?

Not “do we want to invoice faster.” Not “can our software support it.” Has the commitment been made, and has the process been rebuilt around it?

If the answer is no, the software conversation is premature.

Better software on top of a process designed around “eventually” produces faster “eventually.” It does not produce same-day.

Same-day invoicing is not proof that the billing team worked harder. It is proof that dispatch, pricing, delivery, billing, and accounting were designed to work as one flow.

The commitment has to come first. Once it does, the process questions become clear, the technology decisions become obvious, and same-day invoicing stops being a goal that keeps getting pushed back and starts being the way the operation actually runs.

It is not a technology problem. It is a commitment problem. And commitment problems do not get solved in a software demo.

Next issue: The Garrett Daley conversation. American Petroleum’s owner on customer obsession, the fleet account he lost on the invoice, and what same-day invoicing looks like as a living operating standard.

Walk into the back office of almost any mid-market fuel distributor and you will find the same thing.

Five, six, sometimes seven systems open at once. QuickBooks or an ERP for accounting. A separate dispatch tool, maybe a whiteboard. A pricing spreadsheet someone maintains by hand. A driver app that captures deliveries but doesn’t talk to billing. A CRM nobody updates consistently. A separate tool for AP matching. And the spreadsheet that ties it all together, because nothing else does.

Each one of those systems was purchased to solve a specific problem. Each one, on its own, probably does what it was bought to do.

The problem isn’t any individual system. The problem is that nobody owns the space between them.

What that looks like for one delivery

A dispatcher sends a load using today’s rack price. The driver delivers 4,200 gallons. Billing receives the ticket the next morning. Someone checks the pricing spreadsheet to confirm the rate that should have applied. Someone confirms the customer’s contract terms. Someone enters the invoice and hopes the accounting sync doesn’t create a duplicate.

That is not one workflow anymore. That is five systems asking a person to hold the process together.

The dispatch tool dispatched correctly. The driver app captured the delivery correctly. The pricing spreadsheet had the right rate, if someone updated it. The accounting system will record the invoice correctly, once someone enters it. Every system did its job.

Nobody owns the space between them. So a person has to.

How the stack gets built

Nobody sets out to build a seven-system back office. It happens one decision at a time, each one reasonable on its own.

The accounting system was already there when the company reached a certain size. Then dispatch got too complex for a whiteboard, so a dispatch tool got added. Then the driver app got purchased because paper tickets were creating billing delays. Then a CRM got added because sales wanted better visibility into the customer pipeline. Then an AP tool got added because the spreadsheet-based 3-way match was taking too long.

Each addition solved the problem it was bought for. Each addition also added a boundary, a place where data has to move from one system to another, and where it usually doesn’t move cleanly.

Every system boundary is a place where someone has to do the work the systems should be doing for each other.

Feature-level versus workflow-level

There is a common piece of advice in software buying: choose the best tool for each function. Best dispatch tool. Best accounting system. Best CRM. Best driver app. Stitch them together with integrations.

In theory this gives you the best of everything. In practice, the best tool for each individual function can still produce the worst outcome for the workflow that runs across all of them.

The dispatch tool might be the best dispatch tool on the market. The accounting system might be the best accounting system for a business your size. The driver app might have the cleanest interface in the industry. Each one, evaluated on its own, earns a high score.

But the delivery doesn’t happen inside any one of those systems. It happens across all of them, in sequence, with a person at every handoff making sure the baton gets passed correctly.

Best in class at the function level can still be worst in class at the workflow level. And in fuel distribution, the workflow is where the money is made or lost.

This is not an argument against specialized tools in general. A dedicated telematics platform for tracking truck location and driver behavior is genuinely best served by a specialized vendor. That is a complementary function, not part of the core operational chain. The distinction is between systems that handle the core chain, pricing through to cash, and systems that handle adjacent functions that can reasonably plug into that chain from the outside.

The core chain is where the feature-level versus workflow-level gap matters most. Because that is the chain where a broken handoff produces a late invoice, a pricing error, an inventory variance, or a duplicate payment. We have written about all of those in this newsletter. Every one of them traces back to a handoff between systems that didn’t talk to each other cleanly.

Why fuel is uniquely exposed to this

We have spent this entire newsletter establishing why fuel distribution workflows are harder than generic business workflows. Pricing that changes intraday based on rack postings. Volumes measured in gross and net gallons with temperature corrections. Inventory that exists in multiple states across terminals, trucks, and in-transit product. Dispatch that changes mid-route based on real-time customer needs.

Every one of those complexities becomes a boundary problem the moment two different systems are involved in the same workflow. The rack price needs to flow from a pricing system into a dispatch system into a billing system, and if those are three different systems, that price has to survive three handoffs without drift, delay, or manual re-entry.

A retail business with simple SKU-based pricing can tolerate a boundary between its POS system and its accounting system because the data crossing that boundary is simple and stable. A fuel distributor cannot tolerate the same boundary between dispatch and billing, because the data crossing that boundary, price, volume, timing, is exactly the data most likely to be wrong if it has to be re-entered or reconciled manually.

What “more software” actually buys you

When a workflow breaks down across system boundaries, the instinct is usually to add another tool. A middleware product to connect the systems. An integration platform. A reporting tool that pulls data from everywhere into one dashboard so at least someone can see the whole picture.

Each of these additions is reasonable. Each of them also adds a new system to the stack, a new place where something can break, and a new subscription to the monthly software spend.

The stack grows. The core problem, that the workflow crosses boundaries nobody designed for, does not get smaller. It gets more systems wrapped around it.

Complexity has a cost that doesn’t show up on any single vendor’s invoice. It shows up in the time someone spends reconciling data between systems. In the errors that happen at the boundaries. In the new hire who needs to learn seven systems instead of two before they can do their job independently.

The questions worth asking instead

Most software evaluations start with a feature list. Does it do pricing. Does it do dispatch. Does it do billing. Does it integrate with QuickBooks.

The more useful questions are about the boundaries, not the features.

When a load is dispatched, does the price get set automatically from the rack and contract terms that apply at that moment, or does someone need to check a spreadsheet?

When a driver confirms delivery, does that confirmation create the invoice, or does someone need to wait for the ticket to come back and re-enter the data?

When the invoice is created, does it sync to accounting cleanly, or does someone need to reconcile sync errors and duplicate entries?

When a supplier invoice arrives, is it automatically matched against the PO and BOL, or does someone need to find both documents and compare them manually?

If the answer to any of these is “someone needs to,” that is a boundary. And every boundary is a place where the workflow depends on a person remembering to do something, doing it correctly, and doing it on time.

The fewer of those boundaries exist in your core operational chain, the simpler your operation actually is, regardless of how many individual features any single piece of software has.

The question worth asking this week

Map your core operational chain. Pricing, dispatch, delivery confirmation, billing, accounting, purchasing, BOL matching, AP.

For each handoff in that chain, ask whether it happens automatically inside one connected system, or whether it requires someone to manually move information from one place to another.

Count the manual handoffs.

The software count does not matter nearly as much as the handoff count. In fuel operations, that is where complexity actually lives.

Next issue: Why fuel marketers need a single source of truth, not five versions of it.

Mark has been running fuel operations for eleven years.

He manages a petroleum distribution company in the Southeast. Around $90M in annual volume. Twenty-two trucks. Four terminals. A dispatch team that runs tight and a billing team that rarely misses an invoice.

Mark is good at his job. His customers don’t leave. His drivers don’t quit. His DSO is the lowest it has been in three years.

And every single month, his inventory reconciliation comes in slightly off.

Not dramatically off. Not enough to trigger a formal investigation. Just off. A few hundred gallons here. A couple thousand dollars there. Within what the operation loosely calls acceptable tolerance.

For the first two years he dug into it. Chased variances back to specific loads. Called terminals. Questioned drivers. Ran the numbers three different ways.

He never found a clean answer.

So at some point, without making a formal decision about it, he stopped looking.

The variance became a line item. Then it became background noise. Then it stopped being something anyone on his team asked about.

Mark is a composite of several operators I have spoken with. But the pattern is real.

That quiet decision is one of the most expensive ones a fuel distributor makes. Not because the individual variance is large. Because it compounds every single month while nobody is looking for it.

What acceptable variance actually means

Regulatory and internal tolerance thresholds vary widely by state, storage type, product, and operating model. But in most fuel operations, variance that falls inside an accepted monthly tolerance does not trigger serious investigation.

That is the dangerous part.

Acceptable often becomes ignored.

A mid-market distributor moving 10 million gallons a year is operating on roughly $35M in product value at $3.50 per gallon. At 1% variance that is 100,000 gallons a year. At $3.50 per gallon that is $350,000 in product value moving through a variance line annually.

That does not automatically mean $350,000 was lost. Some variance is measurement-related. Some is timing. Some is temperature. Some is product in transit. Some is real operational loss.

But if the operator cannot explain the variance, the business is carrying a blind spot worth hundreds of thousands of dollars.

Mark’s operation moves around 8 million gallons annually. His variance has been running at roughly 0.4% for the past eighteen months. On 8 million gallons that is 32,000 gallons a year. At $3.50 per gallon that is $112,000 in product value moving through his books without a clean operational explanation.

He knew the percentage. He had never translated it into dollars.

Most mid-market distributors haven’t.

They know whether last month’s reconciliation was better or worse than the month before. They do not have a rolling twelve-month variance view by terminal, product, driver, truck, compartment, and customer.

Without that visibility, the slow leak is invisible.

Where inventory variance actually comes from

Inventory variance in fuel distribution is not random. It comes from consistent, repeatable, traceable places. You just need the system to show you where to look.

1. Meter calibration drift.

   Truck meters are certified and recalibrated on a schedule. Between calibrations, meters can drift. A meter reading 0.2% high on every delivery creates a small mismatch on every load. The customer received 998 gallons. The system says 1,000. The invoice reflects 1,000. The money may have been collected but the inventory record is now wrong.

   Mark had a truck running a meter 0.3% high for four months before recalibration surfaced the issue. By the time anyone connected the meter to the reconciliation variance, the accumulated discrepancy was 6,200 gallons. At $3.50 per gallon that was $21,700 in product value recorded incorrectly. The money wasn’t necessarily lost. But the inventory record was wrong for four months and nobody knew why.

   Bad inventory records create bad decisions.

3. Temperature correction inconsistencies.

   Fuel volume changes with temperature. Terminal BOLs may show both gross and net gallons. Customer billing may use gross, net, or contract-specific rules depending on product, state, and operating practice. If those rules are not applied consistently across dispatch, BOL, delivery, invoice, and accounting, variance accumulates quietly.

   
   This is especially true when one system holds the BOL, another creates the invoice, the driver app captures delivered gallons, and accounting only sees the final number.

   
   The variance is not always in the fuel. Sometimes it is in the handoff.

3. Compartment heel.

   When a truck delivers a partial load, product remains in the compartment. That heel gets carried to the next delivery. If it is not tracked and reconciled against the next load, it creates a floating inventory discrepancy that moves around the fleet until someone finds it or writes it off. In operations running split loads across multiple product types, heel tracking is where a lot of variance lives.

   
   The product is not gone. The system just does not know where it is.
   

4. Load splitting that does not reconcile cleanly.

   A driver is dispatched with 8,500 gallons for three customers. One customer takes less than ordered. The driver splits the remaining product to a fourth customer added mid-route. The original dispatch record, terminal BOL, driver delivery confirmation, and invoice no longer tell the same story.

   
   Somewhere in that handoff, gallons start to drift. Not because someone made a huge mistake. Because the system was not built to reconcile the operational reality of the route.

5. Shrinkage and spillage.

   Product is lost during loading, unloading, equipment maintenance, spills, and normal field operations. Some of it is unavoidable. All of it should be categorized. When shrinkage gets buried inside a catch-all variance entry, the underlying cause stays hidden and the loss repeats.

None of these are dramatic in isolation. Each one looks like measurement error, rounding, or normal operational noise. Together, across a fleet and a full year of deliveries, they become a real number.

Not all variance is a loss

This is where the conversation gets more interesting than most variance articles let it.

Most people talk about inventory variance like it is always bad. It is not.

Variance can be negative. Variance can also be positive.

An owner of a large Texas-based fuel marketer shared his numbers when I asked about variance thresholds.

His operation runs a 1.4% tolerance in either direction. Last month they wrote on 50,000 gallons against 6.3 million gallons purchased. Not a loss. A gain. Roughly 0.8% positive variance.

In Texas, summer heat changes the equation. Fuel expands. Depending on how the operation buys, stores, delivers, meters, and bills fuel, expansion can create a positive inventory impact. In his case, after accounting for shrinkage and operating reality, the estimated annual impact was around $750,000.

That number surprised him when he calculated it. He had never looked at variance that way before.

The point is not that variance is always good or always bad. The point is that most fuel distributors don’t know which direction their variance runs or what it is worth in dollars.

Climate matters. A distributor in Texas is playing a different variance game than one in Minnesota. Summer heat can create expansion gains. Cold climates can create contraction losses. The direction changes. The principle does not.

The reconciliation that happens too late

Most mid-market fuel distributors reconcile inventory monthly. Some do it weekly. Very few do it close to real time.

Monthly reconciliation means variance accumulates for 30 days before anyone looks at it. By the time the numbers are reviewed, the loads that created the variance have been delivered, invoiced, and closed. The driver who split the load mid-route doesn’t remember the exact details. The dispatch record may not reflect what actually happened in the field. The BOL has been scanned, uploaded, and filed. The invoice has already gone out.

Monthly reconciliation doesn’t catch variance. It counts it after the fact.

A distributor moving 800,000 gallons a month with a 0.4% variance rate is carrying 3,200 gallons a month in unexplained variance. At $3.50 per gallon that is $11,200 a month. Over a year that is $134,400. Caught in real time, some of that variance is explainable or recoverable. Caught thirty days later, most of it becomes a note in the monthly report.

Mark’s team runs reconciliation on the last business day of the month. It takes two people most of the day. The output is a number that goes into a variance line and a note that says inventory was within acceptable range.

Nobody on his team had asked what acceptable range was actually worth in dollars. Until now, neither had Mark.

The variance nobody talks about: product in transit

There is one category of inventory variance that rarely shows up cleanly in reconciliation reports.

Product in transit.

At any given moment, a fuel distributor has product sitting inside truck compartments between the terminal and the customer. That product has left terminal inventory. It has not yet been confirmed as delivered. It exists in a state that most systems do not track cleanly.

If a driver ends his shift with product still in the compartment, that product needs to carry forward to the next day’s inventory. In operations where end-of-shift inventory is manual, inconsistent, or skipped entirely, that product disappears from the books until the next delivery creates a record.

Mark runs twenty-two trucks. If each truck carries an average heel of 200 gallons at end of shift, that is 4,400 gallons floating in transit inventory on any given night.

At $3.50 per gallon that is $15,400 in product value the system cannot account for.

The product exists. The question is whether the system knows where it is.

What clean fuel operators do differently

The best operators have not eliminated variance. That is not the goal. They have made variance visible at the right level of detail. They know which variances to investigate, which ones to explain, and which ones to accept.

Three things separate them from the operations still writing off monthly variance as background noise.

1. They reconcile by transaction, not just by period.

   
   Every load is reconciled at the point of delivery. Dispatched gallons. Loaded gallons. BOL gallons. Delivered gallons. Invoiced gallons. Truck inventory movement. The variance on that specific load is visible before the next load moves.

   
   Patterns emerge quickly. A specific truck compartment running consistently high. A specific terminal where BOL and invoice volumes don’t match. A specific driver whose delivery confirmations consistently show variance above fleet average. A specific customer where ordered gallons and delivered gallons are constantly misaligned.

   
   The key is not only seeing the monthly number. The key is knowing which transaction created it.

2. They track product state continuously.

   Terminal inventory. Truck inventory. In-transit inventory. Delivered but not yet confirmed inventory. Each state is tracked separately and each movement is recorded when it happens. Monthly reconciliation becomes a validation step, not a discovery process.

3. They separate measurement variance from operational variance. A 150-gallon variance on a 10,000-gallon load explained by temperature correction is different from a 150-gallon variance with no explanation. The first may be normal. The second needs investigation. Operations that lump both into the same write-off line never build the pattern recognition needed to manage inventory well.

The goal is not zero variance. The goal is knowing where every gallon went and having a defensible explanation for every variance above your threshold.

The question worth asking this week

Pull your last twelve months of inventory reconciliation reports. Then calculate five numbers:

• Total monthly purchased gallons

• Total delivered gallons

• Net inventory variance by product

• Variance by truck or compartment

• Variance by terminal or supply source

Then ask three questions:

How much of the variance was investigated? How much was traced to a specific source? How much was written off as a catch-all entry?

If the answer to the last question is “most of it,” you do not have a variance problem. You have a visibility problem.

The gallons are not random. They went somewhere. And in some climates, they came back with friends.

Mark did the math after our conversation. His 0.4% variance rate on 8 million gallons at $3.50 per gallon represented $112,000 a year in unexplained product value.

He had never run that number before.

He is running it now.

Next issue: Why fuel marketers need simpler systems, not more software noise.

There is an email inbox at almost every mid-market fuel distributor that does more operational work than any software the company has purchased.

It receives supplier rack quotes every afternoon. BOLs from three terminals arrive as PDF attachments before noon. Carrier freight invoices come in from four different carriers in four different formats. Supplier invoices land two to five days after the lift, sometimes with credits attached, sometimes without, sometimes with line items that don’t match what was agreed on the phone.

Someone processes all of it. Every day. Manually.

They open the email. They read the document. They key the relevant numbers into QuickBooks or the ERP or the spreadsheet that sits alongside both. They cross-reference the BOL against the purchase record. They flag the ones that don’t match. They forward the ones that need someone else’s attention.

That person is your AP department. And that inbox is your procure-to-pay process.

It works until it doesn’t. And when it doesn’t, the problem is already three days old.

Why traditional automation never solved this

The obvious answer to an inbox full of documents is automation. Build a rule. Parse the PDF. Extract the fields. Push the data into the system.

Fuel distribution broke that answer before it got started.

Supplier rack quotes don’t arrive in a standard format. Every supplier has their own template. Some come as structured PDFs. Some come as Excel attachments. Some come as the body of an email that someone formatted differently six months ago and never changed back. Some come from DTN or OPIS feeds. Some still come from a terminal website someone checks manually every afternoon.

BOLs from different terminals have different field layouts, different column headers, different ways of presenting gross versus net gallons, different ways of handling temperature corrections and product codes.

Carrier freight invoices have their own logic entirely. Flat rates, mileage-based rates, fuel surcharges calculated on different base indexes, detention charges that require cross-referencing dispatch records to validate.

Rule-based automation breaks the moment a document arrives outside the expected format. And in fuel distribution, outside the expected format is not an edge case. It is Tuesday.

The problem was never that automation was unavailable. The problem was that document variation in fuel operations made rule-based automation fragile at exactly the moments it mattered most.

The real issue: document variation plus operational context

This is worth stating precisely because it explains why every previous attempt at AP automation in fuel distribution produced the same outcome. A system that worked on 80% of documents and required manual intervention on the other 20%. And the 20% that required manual intervention was always the 20% that mattered most.

The AP problem in fuel distribution is not just data entry. It is context: which load, which BOL, which supplier price, which freight rule, which variance, and who needs to review it.

A BOL that arrives with a field labeled “Net Gals” instead of “Net Gallons” is not an error. It is a formatting variation from a specific terminal. A system that flags it as unreadable is creating work, not eliminating it. A system that understands it belongs to a fuel terminal BOL and maps it correctly is doing what the AP person was doing manually.

Traditional automation follows rules. Leo follows the workflow.

That distinction is what makes the difference in an environment where every supplier, every terminal, and every carrier arrives with their own document format and their own operational logic.

Introducing Leo

At Fueleo, we spent the first six issues of The Fuel Stack writing about the problems in this industry without mentioning what we were building. The invoicing delays. The pricing errors. The AP processes running on spreadsheets one person maintains. The ERP implementations that didn’t deliver.

All of it pointed to the same root cause. The documents that run fuel distribution operations arrive in too many formats, from too many sources, with too much variation for any manual process to handle cleanly at scale.

So we built Leo.

The name came from Sudarshan, our youngest engineer on the team. Sudarshan has the most energy, the least patience for manual processes, and an alarming ability to ship things before anyone has finished writing the requirements document. He named the agent Leo. We did not ask why. Some things you just accept.

Leo lives inside the procure-to-pay workflow. He reads the room, runs the calculations, cross-references the things that haven't been flagged yet, and quietly finds the problem before it becomes someone's bad Tuesday.

One thing to say clearly before the capabilities: Leo does not approve payments on her own. he prepares the work, links the evidence, checks the match, and routes the right exceptions to the right person. The human stays in control. What changes is what lands on the human’s desk.

Here is where Leo is already helping.

What Leo reads

Leo monitors the email inboxes and document feeds where fuel distribution operational documents arrive. Supplier rack quotes. Supplier invoices. BOLs from terminals and drivers. Carrier freight invoices.

He can monitor the inbox continuously so AP does not have to wait for a daily batch or month-end cleanup. When a document arrives, he processes it against the workflow it belongs to.

A BOL from Terminal A has different field names than a BOL from Terminal B. Leo maps both to the same data structure. A supplier invoice with a temperature-corrected net gallon figure gets normalized against the gross gallon BOL. A rack quote that arrives as a structured PDF gets processed the same way as one that arrives as an unstructured email body.

When a field arrives in an unexpected format, Leo flags the variation instead of silently failing. The output is clean, structured data. Not the document. The data inside the document, extracted consistently regardless of source format.

What Leo creates

Based on the normalized data, Leo creates the operational records that used to be created manually.

When a supplier rack quote arrives, Leo ingests the pricing, normalizes it against the relevant terminals and products, and updates the pricing data that flows into dispatch and billing. No manual entry step. No lag between when the rack quote arrives and when the pricing reflects it.

When a fuel purchase or lift is confirmed, Leo creates or updates the purchase record. In some operations that is a formal PO. In others it is the load order or purchase transaction that functions as the PO equivalent for reconciliation purposes. Either way, the record is linked to the load, the terminal, the supplier, the product, the volume, and the pricing that applied at the time of the lift. It exists before the invoice arrives, not after.

When a BOL arrives, Leo links it to the corresponding purchase record and load. The delivery confirmation, the BOL, and the purchase record are connected at the time of delivery, not reconstructed later.

Before Leo. After Leo.

This is what the supplier invoice workflow looked like before:

Supplier invoice arrives by email. AP opens the email. Downloads the PDF. Finds the BOL in the shared drive. Finds the PO or load record in the ERP. Checks the volume. Checks the price against the rack posting. Investigates the variance. Keys the data into QuickBooks or the ERP. Routes for approval. Repeats for every invoice in the batch.

This is what it looks like with Leo:

Supplier invoice arrives. Leo reads it. Links it to the BOL and purchase record. Checks volume, price, rack basis, and open credits. Prepares a payment-ready record if everything matches within tolerance. Surfaces a specific exception with full context if it doesn’t. AP reviews what needs judgment. Everything else moves to the payment queue.

No one had to manually open the email, read the PDF, and key the data. That work happened before the AP manager opened her laptop.

What Leo matches

When a supplier invoice arrives, Leo runs the match automatically. He compares the invoice against the BOL and the purchase record. he checks volume. he checks pricing. He validates the rack basis against the posting that applied at the time of the lift. He checks for open credits tied to that supplier or that load.

If everything matches within defined tolerance, the invoice moves to the payment queue with the right approval controls and payment timing.

If something doesn’t match, he surfaces a specific exception with full context. Not “invoice flagged.” He surfaces:

Supplier invoice shows 8,000 gallons at $3.2140 per gallon for Load #TX-10482. The purchase record expected $3.1890 per gallon based on the rack posting at the time of lift. The $0.0250 per gallon variance creates a $200.00 overbill. No open credit or pricing adjustment is on file. Myra flags the invoice as an exception, links the invoice to the BOL and purchase record, and routes it to AP for review before payment.

The AP person reviews one exception with full context, makes a judgment call, and moves on.

The AP manager who used to spend three days at month-end reconstructing transactions from scattered documents now spends three hours reviewing the exceptions that actually require human judgment.

Carrier freight: the hard case

Carrier freight is where most AP automation tools stop. The variation in carrier invoice formats, rate structures, fuel surcharge calculations, and detention charges makes it one of the hardest document types to process reliably.

Leo can process the freight invoice, validate the logic, and surface the discrepancy.

When a carrier freight invoice arrives, Leo identifies the carrier, the loads covered, the rate structure that applies, and the fuel surcharge basis. He validates the invoice against the dispatch record. He checks whether detention charges are supported by the delivery timestamps. He checks the fuel surcharge calculation against the index the carrier contract references.

If the invoice matches the dispatch record and the contract terms, it moves toward payment. If it doesn’t, Leo surfaces the specific discrepancy with the supporting data the AP person needs to resolve it with the carrier.

What changes for the AP manager

Leo does not replace the AP manager. He changes what the AP manager does.

The work that required opening emails, reading documents, keying numbers, cross-referencing records, and chasing down discrepancies is now done before the AP manager opens her laptop. What remains is the judgment work. The exceptions that require context a human has and a system doesn’t. The supplier relationship calls. The credit negotiations. The decisions about which variances to accept and which ones to pursue.

That is a better use of an experienced AP person than reading PDFs and keying numbers into a system that was never designed to receive them that way.

The inbox is still there. The documents still arrive the same way they always have. What changed is what happens to them next.

Why we are telling you this now

We spent six issues writing about the problems in this industry without mentioning Fueleo once. The invoice that goes out three days late. The driver who is your most expensive data-entry clerk. The rack price that was wrong when the customer called. The ERP that almost worked. The AP process running on a spreadsheet one person built and nobody else understands.

We wrote about those problems because we needed to understand them before we built anything to address them.

Leo is one of those answers. Not a complete one. Not a finished one. But a real one, doing the work that used to require a person opening emails and maintaining the spreadsheet nobody else understands.

We are building more. We will write about it here as it develops.

If any of this sounds like your operation, reply to this email. That conversation is how Leo got built in the first place.

Next issue: Inventory variance. The slow leak most fuel ops managers stop looking for.

Lisa didn’t set out to spend nine months of her life in implementation meetings.

She runs operations for a petroleum distributor in the Midwest. Around $120M in annual fuel volume. Eighteen trucks. Customers across three states. She has been in fuel distribution for fourteen years and there is not much about the business she hasn’t seen.

Three years ago she made the biggest technology decision of her career.

She bought an ERP.

The demo that started everything

The vendor flew in on a Tuesday. Two people. A sales rep who knew the right vocabulary and a solutions engineer who ran the demo.

They had done their homework. They knew the pain before Lisa said it out loud. Invoices going out late because dispatch and billing ran on different systems. Inventory that never reconciled cleanly at month-end. AP matching that lived in a spreadsheet nobody fully understood except the person who built it.

The demo showed all of it working. Dispatch closing a load and billing triggering automatically. Inventory updating in real time as the driver confirmed delivery. AP matching running against the BOL without anyone touching a keyboard.

Lisa asked about rack-based pricing. The solutions engineer pulled up a configuration screen. It looked right.

She asked about gross to net gallon conversion. He said the system handled it.

She asked if they had other fuel distributor customers. The sales rep named three.

Six weeks later she signed the contract. Five months. $180,000. The budget covered licensing, implementation, data migration, and three months of consultant time. For a $120M distributor it was aggressive but not unusual.

She felt good about it.

Month one: the first gap

The implementation kicked off with an onsite visit. Two consultants, three days, a conference room full of whiteboards.

Day one went well. System architecture. Data migration planning. User roles and permissions. The consultants were organized and Lisa’s team was engaged.

Day two is when the first gap showed up.

The pricing configuration session. Lisa’s team walked through their pricing structures. Rack plus margin. Contract basis with monthly resets. Tiered volume pricing for their largest fleet accounts. Split billing for customers with multiple delivery sites.

The consultants got through rack plus margin cleanly. Then they hit contract basis.

The system assumed pricing was set when the order was entered.

In Lisa’s operation, pricing wasn’t finalized until dispatch.

A load scheduled at 8:00 AM might lift from a different terminal than originally planned. The rack posting might have changed since the order was entered. A contract customer might be priced off OPIS plus basis, while another customer on the same truck was priced rack plus margin.

The system wanted one price decision.

Fuel operations required several.

The consultant looked at his laptop for a long moment.

“We can handle that with a workaround.”

Lisa wrote it down. First workaround. Day two of the implementation.

The moment Lisa knew

The moment Lisa realized the project was in trouble wasn’t when the timeline slipped.

It wasn’t when the budget started growing.

It was when her team began maintaining the old spreadsheets and the new ERP at the same time.

The pricing spreadsheet stayed open.
The inventory spreadsheet stayed open.
The AP reconciliation spreadsheet stayed open.

Every ERP implementation has a moment like this.The moment the business quietly admits it does not trust the new system enough to let go of the old process.

Month two: the list grows

By the end of the second month Lisa had a document on her laptop titled “Open Items.” It had twenty-three line items.

The BOL workflow required a manual step because the system assumed deliveries were confirmed by the back office, not by the driver at the point of delivery. Workaround.

The inventory reconciliation still ran nightly instead of in real time.

A transport truck could pull 8,500 gallons from one terminal before breakfast and another 7,000 gallons from a different terminal before lunch. The operation knew those gallons had moved. The system wouldn’t know until overnight processing completed. Workaround.

The AP matching module imported supplier invoices correctly but treated nearly every terminal invoice as an exception.

The supplier billed net gallons. The BOL captured gross gallons. Temperature correction created a variance on almost every load. The software saw a mismatch. The AP team saw normal fuel operations.

Every invoice had to be reviewed manually before payment could be approved. Workaround.

The implementation team was responsive. They showed up to every call. They documented everything Lisa raised. They found creative configurations for problems the system was never designed to solve.

But every workaround created friction somewhere else.

Fixing the BOL confirmation step broke the automatic billing trigger. Fixing the billing trigger required a manual approval step that slowed invoicing down. Fixing the invoicing speed required removing an audit control Lisa’s CFO wanted kept.

The implementation team wasn’t cutting corners. They were building a house of cards, one workaround at a time, on a foundation that was never designed for fuel distribution.

Month four: the budget conversation

The original five-month timeline had slipped to eight. The original $180,000 budget had grown to $240,000. A 33% overrun. Painful but, as Lisa would later find out, not unusual for an implementation of this complexity.

Lisa had to walk into her CFO’s office and explain why.

That was the hardest conversation of the implementation.

She had championed this decision. She had sold it to leadership with a business case that showed the system paying for itself in eighteen months through reduced billing errors, faster invoicing, and cleaner inventory reconciliation. Now she was asking for more time and more money with a system that still wasn’t live.

Her CFO approved it. But the question he asked at the end of the meeting stayed with her.

“Is this going to work, or are we throwing good money after bad?”

Lisa said it was going to work. She believed it when she said it.

She was also aware, for the first time, that she might be wrong.

Month seven: go-live

The system went live seven months after the implementation started. Three months late. Sixty thousand dollars over budget.

The go-live weekend was rough. Three critical workflows broke within the first 24 hours. Lisa’s team worked through Saturday night. The implementation consultants were on a call from 11pm to 3am walking through fixes.

By Monday morning the system was stable enough to run the operation.

Not clean. Stable.

Lisa sent an all-staff email saying the implementation was complete and thanking her team for their patience. She meant every word. Her team had absorbed seven months of disruption on top of their regular jobs without complaint.

What she didn’t say in the email was that fourteen of the twenty-three open items were still open.

The AP matching module still required manual clearing for every BOL with a gross to net variance. The inventory reconciliation still ran nightly instead of in real time. The spreadsheet her predecessor had built was still open on the AP manager’s second monitor because the system couldn’t handle three of their largest supplier invoices without manual intervention.

The system was live. The operation looked almost exactly like it did before. Just with a new interface on top of it.

Eighteen months later

I talked to Lisa eighteen months after go-live.

The system had settled into the operation. Her team used it for order entry, customer invoicing, and basic financial reporting. Those parts worked and genuinely saved time.

The dispatch-to-billing automation that was the centerpiece of the original business case still required a manual step. The inventory reconciliation still ran nightly. The AP matching still had a spreadsheet running alongside it.

She had stopped counting the open items. At some point during the first year she had closed the document on her laptop and accepted that this was what the implementation had delivered.

I asked her what she would do differently.

She thought about it for a moment.

“I would have asked them to show me rack pricing working in a live environment with real data before I signed anything. Not a demo environment. Their actual system, configured for a distributor like us, running real loads.”

She paused.

“And I would have asked the implementation team what the system couldn’t do. Not the sales rep. The people who were actually going to build it.”

Two questions. Asked before the contract was signed. That is the distance between the implementation she got and the one she needed.

Why this keeps happening

Lisa’s story is not unusual. It is the pattern.

Software vendors sell to the optimistic version of what their system can do. Implementation teams inherit the gap between that optimism and reality. Operators absorb the cost of that gap in internal time, parallel workflows, and organizational exhaustion that never shows up on any report.

According to Gartner, more than 70% of ERP implementations will fail to meet their original business case goals. As many as 25% will fail catastrophically.

In fuel distribution that number feels low. Because the workflow complexity here is higher than almost any other industry the generic ERP was built for. And the cost of getting it wrong shows up directly. In your DSO. In your inventory variance. In your AP leakage. In the spreadsheet still running on your AP manager’s second monitor eighteen months after go-live.

What due diligence actually looks like

Before the next software evaluation, three things are worth doing that most operators skip.

Talk to a current customer who runs the same operation. Not a reference the vendor provides. A customer you find independently, who runs a similar operation at a similar scale, and who will tell you honestly what the system handles natively and what they work around.

Run a pilot on your actual workflow. Not a demo. Not a sandbox. Your loads, your pricing structures, your BOL workflow, your AP matching. If the vendor won’t support a real pilot before contract signature, that is the answer.

Ask the implementation team, not the sales team, what the system cannot do. Implementation teams are closer to the reality of what gets configured versus what works out of the box. They will tell you things the sales rep won’t.

Lisa wishes she had done all three before she signed. She didn’t because the demo was convincing, the timeline felt urgent, and the sales rep said yes.

Two years later the spreadsheet is still open on the AP manager’s monitor.

The question worth asking before the next contract

Find the workflow most specific to your operation. For a fuel distributor running rack-based pricing, that is price-at-dispatch. For a common carrier, that is carrier settlements. For a wet hose operator, that is delivery reconciliation.

Ask the vendor to demo that workflow specifically. In a live environment. With data that looks like yours. Before you sign anything.

It is the first line item on an Open Items document that is going to have twenty-three entries by month two.

Next issue: Inventory variance. The slow leak most fuel ops managers stop looking for.

I talked to an AP manager at a mid-size petroleum distributor last year. She handles supplier invoices for a company doing around $80M in annual fuel purchase.

I asked her how she matches vendor invoices to BOLs and purchase orders.

She pulled up her screen and showed me a spreadsheet. Seventeen columns. Color-coded by status. A notes column with entries like “credit pending,” “called terminal, waiting on revised invoice,” and “ask Mike.”

She built it herself three years ago. Nobody else on the team fully understands how it works. She has not taken a full week off since.

That spreadsheet was not a tracker. It was the 3-way match process at an $80M fuel distributor.

What the textbook says versus what actually happens

Three-way match is straightforward in theory. Before paying a supplier invoice, AP confirms that the purchase order, the BOL, and the supplier invoice all agree. The supplier, terminal, product, BOL number, lift date, gallons, price, taxes, freight, and payment terms should all line up.

In fuel distribution, those three records almost never arrive together, in the same system, at the same time.

The PO, if it exists before the load moves, may live in QuickBooks, the ERP, or a purchasing worksheet. Many mid-market fuel purchases still start as a phone call, text, or email to a supplier. The PO is often created after the fact because the operational priority was getting product loaded before the customer called again, the weather changed, or the tank ran low.

The BOL may come back with the driver, get faxed from the terminal, arrive as a PDF, come through a terminal or DTN portal, or get uploaded from a mobile device. It often ends up in an email folder, shared drive, paper packet, or scanned batch that everyone can access and nobody truly owns.

The supplier invoice arrives by email, portal, mail, EDI, or PDF attachment two to five days after the lift. By then, AP has to reconstruct the transaction.

That someone is usually one person. And she built the spreadsheet because nothing else connected those three things.

Without integration across systems, matching becomes a manual scavenger hunt. In fuel distribution, that scavenger hunt happens dozens of times a week, across multiple suppliers, multiple terminals, and multiple product types, all with different payment terms moving toward due dates simultaneously.

Why fuel makes this harder than most industries

This is not a people problem. Fuel AP is structurally harder than generic AP because the transaction is not just vendor, item, quantity, and price. It includes terminal, lift date and time, product code, gross gallons, net gallons, rack basis, freight, fees, taxes, credits, and payment terms.

Rack price moves daily, sometimes intraday. The price on a supplier invoice may reflect the rack posting at the time of lift. That may not match what the buyer expected from a morning call, a contract basis, or an internal pricing sheet. A $0.015 per gallon discrepancy on a 40,000 gallon load is $600. It is easy to miss on a manual review when you are looking at a number that is close but not identical and you are not sure which one is right.

Volumes are measured in gross gallons and net gallons. The BOL may show both. The supplier invoice may show one. The difference is not automatically an error; it may be the result of temperature correction. But if AP does not know which basis the supplier used, a valid invoice can look wrong, or a wrong invoice can look valid.

Payment terms create real pressure. A distributor buying tens of millions of dollars of fuel annually may be managing millions in supplier payables at any given time. If matching takes too long, the company risks late fees, strained supplier relationships, missed early-pay discounts, or avoidable cash planning issues.

The spreadsheet is not a sign that the AP team is behind. It is a sign that nobody built a system that matches how fuel purchasing actually works.

What the data says about manual AP processes

The AP leakage problem in fuel distribution is not unique to the industry. But the commodity nature of the business amplifies every failure point.

Manual processing for an invoice can cost $12 to $30 per item. A mid-market fuel distributor processing 3,000 supplier invoices a year could spend $36,000 to $90,000 annually on manual invoice handling before accounting for payment errors, missed credits, duplicate invoices, and delayed approvals

The larger issue is not that AP people miss obvious errors. It is that manual review is inconsistent. When an invoice is close to expected, when the BOL is hard to find, or when the credit is buried in a note column, the process depends too much on individual judgment and memory.

According to data from the American Productivity and Quality Center, an average of 0.8% to 2% of companies’ annual disbursements are duplicate or erroneous. A SAP Concur study reported that 1.29% of invoices businesses process are duplicates, each valued at an average of $2,034.

Put that in fuel distribution terms. Even a small error rate on $50M of annual supplier payments can become a six-figure exposure. Not every error is recoverable. Some credits age out. Some duplicates are found late. Some pricing variances are never identified because they were close enough to pass manual review.

More than 25% of AP teams’ time is spent identifying and correcting payment errors, time that could otherwise be used for strategic work. At a lean mid-market distributor where the AP function might be one or two people, that is a significant portion of someone’s entire working week spent on error correction rather than financial oversight.

Where the money quietly leaves

The financial exposure from manual 3-way match in fuel distribution usually falls into a few repeatable categories.

Pricing variances that slip through. A supplier invoices at a rack basis, contract basis, or terminal posting that does not match what the buyer expected. The difference is $0.02 per gallon on a 35,000-gallon load. That is $700. On a manual review, with fifteen other invoices waiting and payment terms approaching, it gets marked close enough and paid.

Credits get promised but never closed. A short delivery, pricing correction, freight issue, or tax adjustment gets discussed by phone or email. The supplier agrees to apply a credit on the next invoice. AP writes “credit pending” in the spreadsheet. The next invoice arrives. The credit is missing. Someone means to follow up. Month-end hits. The issue gets buried.

Duplicate payments. The same invoice enters through multiple paths. It arrives by email, then again through a vendor portal, then again in a scanned packet. If invoice number, supplier, amount, BOL, and lift date are not matched systematically, both versions can move forward.

None of these are dramatic in isolation. Together, at volume, across a full year of fuel purchasing, they are a real number sitting inside your AP line that nobody is measuring.

The spreadsheet holding it together

Every mid-market fuel distributor has some version of this spreadsheet.

Columns for supplier, terminal, invoice number, BOL number, lift date, product, gross gallons, net gallons, invoice gallons, expected price, invoice price, variance, credit status, payment terms, and notes column with entries like “within tolerance,” “credit pending,” or “ask Mike.”

It was built by someone who understood the exceptions. It works because that person knows what the colors mean, which variances matter, which supplier needs a phone call, and when “ask Mike” is the fastest path to the truth.

The person who maintains it goes on leave. A formula breaks. The transaction volume grows and a new tab gets started for the current month without fully closing out the previous one.

At that point, your most important AP control is running on something one person understands and nobody has documented.

The spreadsheet does not just track invoices. It stores the company’s unwritten rules: which terminal is always off by a few gallons, which supplier tends to miss credits, which product code maps incorrectly, and which variance is safe to clear.

That is exactly what the spreadsheet represents. Not a system. Tribal knowledge in column format.

What clean AP actually requires

The fix is not a better spreadsheet. It is a transaction record that starts before or at the time product moves and follows the load through BOL, invoice, approval, credit, and payment.

It means capturing the BOL as close to the lift or delivery event as possible, not days later when paperwork is scanned. It means connecting the PO or purchase intent to the load, even if the formal PO is created later. It means receiving the supplier invoice in a structure that can be matched against the BOL and purchase record without AP re-keying every field.

When those three documents are linked to the same transaction before AP touches it, matching becomes exception review instead of a document hunter.. The system flags the 150-gallon variance. AP determines it is within terminal tolerance and clears it in two minutes.Everything that matches cleanly moves to the payment queue with the right controls, approval rules, and payment timing.

The AP person who spent days at month-end reconstructing transactions from scattered documents now spends time on the discrepancies that actually require judgment.

That is not a software pitch. It is what happens when the document workflow is designed before the matching step, instead of the spreadsheet being built to compensate for the fact that it wasn’t.

The question worth asking this week

Find the last vendor invoice your AP team flagged as a discrepancy. Trace it back.

Then ask:

• Where was the BOL when the invoice arrived?

• Was the PO or purchase record already tied to the load?

• Was the invoice matched against gross gallons or net gallons?

• Was the rack price checked against the right terminal and lift date?

• Was there an open credit tied to that supplier, BOL, or invoice?

• How long did it take AP to resolve the exception?

Then ask how many invoices went through last month without that level of scrutiny. And whether the ones that didn’t get flagged were actually correct, or just close enough.

The spreadsheet is holding it together. Until the person holding the spreadsheet is unavailable.

Next issue: The ERP that was supposed to fix everything and didn’t.

I’ve heard some version of this story more times than I can count.

A fuel distributor hits a wall. Invoices going out late. Dispatch running on a whiteboard and three group texts. Inventory that hasn’t reconciled cleanly in two quarters. Leadership decides to fix it. A software vendor gets selected. A contract gets signed.

Twelve months later, the system is live. It does some things better. But the billing clerk is still waiting for dispatch to close loads before she can run invoices. The dispatcher is still calling drivers to confirm deliveries. The spreadsheet that tracks AP exceptions is still open on someone’s second monitor.

The software got implemented. The workflow didn’t change. And in fuel distribution, unchanged workflow almost always means the same bottlenecks return under a new login screen.

That’s not bad luck. It’s a pattern.

This is not just a fuel industry problem

Before blaming the distributor or the software, it’s worth being honest about the broader context.

Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals. As many as 25% of those will fail catastrophically.

That's not a fuel industry number. That's across all industries, all company sizes, all software vendors.

But it matters especially in fuel distribution because most operators are not implementing software with unlimited budget, unlimited internal staff, or a full-time transformation office. They are doing it while trucks still have to roll, drivers still need routes, customers still need fuel, and invoices still need to go out.

Those numbers should reframe how you think about your own history with software. If you tried a system and it didn’t deliver what was promised, you were not in the minority. You were in the majority.

The question worth asking is not “why did the software fail?”

It’s this:

“why does software keep failing at the same point?”

What actually happens during a fuel software implementation

Most implementations in fuel distribution follow the same arc.

A vendor gets selected based on a demo that shows the system doing everything cleanly. The implementation starts. And here is where the pattern sets in.

The natural inclination is to configure the new software to match existing workflows as closely as possible. This feels safe. It minimizes disruption. Everyone already knows how things work.

So the software gets bent around old handoffs, old approvals, and old exception paths instead of forcing the company to agree on a cleaner operating sequence.

The dispatcher has been closing loads the same way for nine years. The billing clerk knows which accounts need special handling and why. The ops manager has a spreadsheet tracking exceptions the system can’t handle. Rather than redesign those workflows, the implementation team builds workarounds to preserve them.

Six months after go-live, the system is live.

The spreadsheets came back.

Not because people resisted change. Because the system was configured around gaps it was never asked to close.

Research on mid-market ERP implementations puts it plainly: failures rarely occur because the software cannot perform required functions. They occur because the organization did not align on how it wanted to operate, how decisions would be made, or how much internal effort the change would require.

That sentence is the whole article, really.

Why fuel workflows are harder to automate than most

This is worth saying clearly because the failure of software in fuel distribution is not entirely the software’s fault.

Fuel distribution workflows are operationally specific in ways that generic software doesn’t anticipate and industry software often underestimates.

Pricing changes intraday. The rack for next day starts coming in late afternoon. Mid-day changes can take up to 24 hours to propagate. That means a delivery at 10am and a delivery at 3pm on the same day can legitimately carry different rack-based prices. Your billing system needs to know which rack applied to which delivery at which time. Most systems don’t handle that automatically. A human fills the gap.

Inventory exists in multiple states simultaneously. Product in a terminal. Product in a truck compartment. Product dispatched but not yet delivered. Product delivered but not yet confirmed in the system. Each state needs to be tracked and reconciled against physical counts that happen on a different schedule. Manual processes in this environment compound errors at every handoff.

Customer pricing is not simple. Contract rates, volume tiers, seasonal adjustments, promotional rates, split billing for fleet accounts, tax exemptions by delivery site. A mid-market distributor with 200 active accounts might be managing 40 distinct pricing configurations across that book. A generic ERP handles none of that out of the box.

Dispatch is dynamic in ways that break linear workflow assumptions. Routes change mid-day. Loads get split. A driver scheduled for three stops ends up doing five because a customer called in a same-day order. As one Texas fuel distributor put it: “Manual worked for us when we did 20 deliveries a day. Now we do hundreds and need a real solution.”

A generic system may support order entry and inventory balances, yet fail completely at the workflows where fuel operations actually live and die.

Take one simple delivery.

A customer places an order in the morning. The price depends on the correct rack, the correct product, the correct customer agreement, and sometimes the correct delivery site. Dispatch assigns the order. The driver pulls from the terminal. A BOL is generated. The product moves into the truck, then to the customer site. The driver captures the delivery ticket. Billing waits for the load to be closed. AP later receives the supplier invoice. Someone eventually has to match the supplier cost, the BOL, the delivered gallons, and the customer invoice.

If any one of those steps lives outside the system, the workflow is no longer automated. It is just partially digitized.

That is where spreadsheets come back.

The implementation trauma is real and rational

There’s a layer to this that doesn’t get discussed enough in vendor conversations.

Most mid-market fuel distributors have been through at least one software implementation that didn’t deliver what was promised. Some have been through two or three. That history creates a specific kind of skepticism that is completely rational given the evidence.

The ops director who says “we tried that before and it didn’t work” isn’t being difficult. She’s pattern-matching on real experience. The last system required six months of implementation, two outside consultants, and a data migration that scrambled three years of customer pricing history. It went live and immediately created more exceptions than it handled. Her team spent the following year working around it.

That skepticism is not irrational. It is earned.

When the next vendor shows up promising to fix everything, her default position is disbelief. Not because she doesn’t want things to improve. Because she’s been promised better before and she’s still cleaning up the aftermath.

The most expensive mistake isn’t technical. It’s treating a workflow transformation like a software purchase.

That cuts both ways. The buyer who treats it like a software purchase gets the outcome they paid for. The vendor who sells it like a software purchase deserves the outcome they delivered.

The workflow problem underneath the software problem

Here is the thesis, stated plainly.

Most fuel distribution software fails not because it’s bad software, but because it gets implemented on top of a broken workflow instead of replacing the broken workflow.

The billing delay problem is not solved by giving the billing clerk a faster interface. It’s solved by eliminating the handoffs between delivery confirmation and invoice generation. The ticket becomes the delivery record. The delivery record becomes the invoice. That sequence has to be automated, not accelerated.

The inventory variance problem is not solved by a better reporting dashboard. It’s solved by capturing inventory state at every point of movement in real time, so the variance is visible before it becomes a month-end reconciliation problem.

The pricing error problem is not solved by a more flexible contract management module. It’s solved by making rack price flow automatically into billing at the correct timestamp, and making contract rates live in one authoritative place that billing pulls from directly. No manual update step. No spreadsheet maintained by one person.

In each case, the fix is a workflow change that software enables. Not software layered on top of a workflow that doesn’t change.

The single biggest factor separating successful implementations from disappointing ones is the willingness to change processes, not just the tools sitting on top of them.

What a workflow-first implementation actually looks like

The distributors running clean operations didn’t just buy better software. They redesigned the sequence first.

They started with one question: what is the right workflow, and what does software need to do to make that workflow possible?

Not: how do we configure this software to match what we’re already doing?

That reframe changes everything. It means the dispatcher has to change how she closes loads, because the new sequence requires it. It means the driver has to confirm deliveries at the truck, because billing can’t wait for end of shift. It means contract rates have to be fully migrated into the system before go-live, because the system is going to own that data from day one.

It’s harder. It takes longer. It requires the organization to actually change behavior, not just adopt a new interface.

But it’s the only implementation that sticks.

Because it changes the workflow, not just the tool sitting on top of it.

The question worth asking before the next implementation

If you’re evaluating software right now, one question cuts through most of the vendor noise:

Does this system change my workflow, or does it adapt to my existing one?

If the answer is "we'll configure it to match how you work today," listen carefully. That may sound comforting, but it often means the old workflow is being preserved with a new interface.

The right answer is harder to hear:

“Here’s the workflow this system requires, here’s why it’s better than what you’re doing today, and here’s what your team will need to change to make it work.”

That conversation is uncomfortable.

It’s also the only one that leads somewhere different from where you’ve already been.

Next issue: What 3-way match looks like at a $100M fuel distributor. Spoiler: it’s a spreadsheet.

About the author

I’m Dibyesh Giri, founder of Fueleo. I spend my time working with fuel marketers on the messy handoffs between pricing, dispatch, delivery, BOLs, invoicing, and accounting. This newsletter is where I write about the operational problems hiding inside everyday fuel workflows.

Pricing disputes are not rare in fuel distribution.

Ask any Ops Director how often a customer calls about an invoice and the answer is usually some version of “more than it should be.” Ask how often the customer is right and the answer gets quieter.

The problem isn’t that fuel distributors are careless about pricing. Most are meticulous. They have contract rates, tier structures, rack-based formulas, seasonal adjustments. The people managing pricing know what they’re doing.

The problem is that pricing in fuel distribution is a moving target. And the systems most distributors use weren’t built to hit a moving target reliably.

How fuel pricing actually works at a mid-market distributor

Most customers aren’t on a flat rate.

They’re on a formula.

Rack plus a margin.
Cost plus a markup.
A tiered structure based on volume.
A contract rate that resets monthly.

Rack price is not a simple once-a-morning update. Supplier postings, rack reports, and effective pricing windows do not always line up cleanly with how dispatch, delivery, and billing teams close the day.

Rack data may already exist in a feed, report, email, API, or pricing platform. The breakdown usually happens after that, when the rate has to move through customer-specific rules, delivery timing, contract terms, and billing.

If your system only refreshes once a day, your billing team may be working with a price that is current for one delivery, pending for another, and stale for the next.

A driver makes a delivery at 2pm. Later that afternoon, a new rack posting comes in for the next pricing cycle. Your billing system has not refreshed yet, and nobody is completely sure whether the delivery should be priced against the prior rack, the new posting, or a customer-specific rule tied to the invoice date. The invoice goes out at the wrong price. Not because anyone made a mistake. Because the timing of how rack price moves in this industry doesn’t match the timing of how most billing systems consume it.

That’s the structural problem. It’s not a human error. It’s a workflow that was never designed around how rack actually works.

The three places pricing breaks down

Every pricing failure usually has a missing control field behind it: effective date, expiration date, pricing basis, tier threshold, contract ID, rack source, or override rule.

Rack timing is one failure point. It's not the only one.

The contract rate that wasn't updated. A customer negotiated a new rate in January. Someone updated the contract file. Nobody updated the billing system. For six weeks, invoices went out at the old rate. The customer paid without saying anything because the new rate was lower and they assumed it was right. You found out during a quarterly review. You issued credits. You never calculated the total cost of that six-week gap.

The tier that tripped at the wrong volume

A customer is on a tiered structure. Under 5,000 gallons a month they pay one rate. Over 5,000 they pay another. They crossed the threshold mid-month. The system didn't catch it. The invoice went out at the higher rate. The customer called on day 31, three days after payment was due, to say they weren't paying until it was corrected.

The special price that expired.

You ran a promotional rate for a customer during a slow season. The promotion ended. Someone forgot to revert the pricing. Three months later a new billing clerk notices the account is still on the promotional rate. You’ve undercharged by $4,200. You write it off because going back to the customer feels worse than absorbing the loss.

None of these are catastrophic in isolation. Together, across a book of 200 accounts with varying contract structures, they represent a quiet and continuous margin bleed that almost nobody is measuring.

Why it's hard to catch

Pricing errors in fuel distribution have a structural camouflage problem.

Customers who are overcharged call. Customers who are undercharged usually don’t. So your error detection system is asymmetric. You catch the errors that cost you customer relationships. You miss the errors that cost you margin.

Your billing team is processing volume. They’re not auditing every invoice against every contract on every delivery. That’s not a criticism of your billing team. That’s just the reality of running billing at scale with manual processes. You can’t catch what you’re not set up to look for.

And the errors that do surface often get resolved individually without anyone asking why they happened or how many similar errors are sitting undetected in the rest of the book.

A customer calls about a pricing dispute. Your AR team investigates, finds the error, issues a credit, and closes the ticket. That resolution takes 45 minutes. Nobody looks at whether the same pricing logic produced errors on 12 other accounts that haven’t called yet.

What the margin bleed actually looks like over a year

This is harder to put a precise number on because it varies by contract complexity and volume. But here’s a conservative frame. This is not an industry benchmark. It is a simple model to size the problem.

A mid-market distributor with 200 active accounts, averaging 15 deliveries per account per month, is running 3,000 invoices a month. If pricing errors affect 2% of invoices, that’s 60 errors a month. At an average error value of $40 per invoice, that’s $2,400 a month in pricing variance. Some in your favor, some against you, and the ones against you are often harder to see until a customer calls.

$28,800 a year. Conservative. At a distributor running tighter margins on commodity product, that’s not noise. That’s a line item.

And that’s before you factor in the customer relationship cost of the disputes you did catch. The accounts that went slow on payment because of a billing dispute. The customer who switched suppliers after the third pricing error in two months. That math is harder to run, but the number is big

What clean pricing actually requires

The distributors who run tight on pricing have solved two things that most haven’t.

First, rack price flows into billing automatically. There’s no manual update step. The formula runs against the correct rack based on the pricing rule, effective date, delivery timing, and customer agreement. When rack moves, pricing moves with it. The human is out of the loop on that specific step.

Second, contract rates live in one place. Not in a spreadsheet that someone maintains separately from the billing system. Not in a filing cabinet with a note taped to the monitor. The contract rate is in the system, it has an effective date and an expiration date, and billing pulls from it directly. When a rate changes, it changes once, in one place, and every subsequent invoice reflects it.

Neither of these is technically complex. Both require discipline about where pricing data lives and how it flows into the billing process. Most distributors haven’t done it because the current process mostly works, most of the time, and the errors that slip through are handled one at a time as they surface.

The problem with that approach is that you’re only seeing the errors that announce themselves. The rest are sitting quietly in your margin.

The question to ask this week

Pull five invoices from last month at random. For each one, trace the pricing back to its source.

Where did that rate come from?
Which rack or contract was used?
What date controlled the price?
When was it last updated?
Is it the rate that should have applied on that delivery date?

If you can’t answer that question cleanly for all five, you have a pricing integrity problem. And the cost of it is somewhere in your margin right now, waiting for a customer to call.

Next issue: What 3-way match looks like at a $100M fuel distributor. Spoiler: it’s a spreadsheet.

About the author

I’m Dibyesh Giri, founder of Fueleo. I spend my time working with fuel marketers on the messy handoffs between pricing, dispatch, delivery, BOLs, invoicing, and accounting. This newsletter is where I write about the operational problems hiding inside everyday fuel workflows.