The Email Inbox Running Your AP Department. And the AI Agent Watching It.
Most fuel distributor AP processes start in the same place. An email inbox nobody fully owns.
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.
Leo is Fueleo’s AI workflow assistant for the procure-to-pay process. He watches the inboxes and document streams where fuel distribution operational documents arrive and he prepares the work that used to require a person opening emails and keying numbers into systems.
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.
About the author
I’m Dibyesh G., 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.