A finance lead at a metals and materials company named a gap that OCR vendors rarely put on the homepage. QuickBooks held the ledger. A proprietary inventory and PO system sat beside it. Payables were logistics-heavy. They had already been bruised by Bill.com, and they had used Claude ad hoc as a workaround.
One of the main issues with Bill.com for them was the need for a custom prompt that generated a description for logistics bills. They wanted a unique narrative on the bill: ship-to, lanes, something a human in ops could recognize later. Pasting chatbot output into the description field was the interim process.
Short answer: capturing vendor, date, and total is not enough when the payable is freight. The bill description field needs a readable logistics story. Vendor rules can draft that story from the document into the description field, beyond the usual OCR boxes.
Who this applies to: QBO and mid-market teams with frequent carrier or 3PL invoices where ops and finance both search history by lane or ship-to, and where generic "Freight" descriptions make audit and inquiry work slower than the payment itself.
Generic descriptions create a second helpdesk inside AP
Freight invoices are often not PO-backed the way plate steel is. The useful identity of the spend lives in route and destination language buried in the PDF. If the bill posts as "Freight" or "Shipping," two things happen.
Ops cannot find the move when a customer asks. AP cannot answer supplier or internal inquiries without reopening the PDF. Ardent Partners' State of ePayables 2024 finds that AP staff still spend 21.8% of their time managing supplier inquiries on average. Unsearchable bill text is one quiet reason that percentage stays sticky.
Bill.com-class capture products will get many header fields right and still leave the description useless. That is not a rounding error. It is a product philosophy that stops at field extraction.
The metals team was not asking for poetry. They were asking for a durable string that matched how their operations people already talked about a load. Lane language is tribal and specific. "Freight" is none of those things.
What we built beyond the OCR boxes
We let a vendor rule draft a unique natural-language description into the bill description field using cues on the document (ship-to, lane language, other logistics markers the team specifies). The output is meant for humans downstream, not for a demo screenshot of confidence scores.
In the metals session, the buyer showed an Echo-style logistics bill and asked whether a rule could generate the description and place it on the record. That is the capability: beyond OCR fields, into narrative that ops can use.
We are not claiming this replaces PO matching on freight. Many logistics bills will never have a clean PO match. Description generation helps identity and search. It does not invent a three-way match that the process never had.
Evidence depth is narrower than our FX or tax posts. This theme has strong verbatim support from a deep call, and product confirmation to proceed without fake before-and-after time savings. We will not invent a minutes-saved metric. Measure your own inquiry time after descriptions become unique.
Staging shows the Extraction rules surface where such instructions live. The bill description field is the destination artifact. If your evaluation cares about logistics searchability, watch that field populate from a rule, not from a clerk with a chatbot tab open.
A description quality scorecard (no purchase required)
Sample twenty paid logistics bills from last quarter. Grade the posted description.
If most are C, your GL history is a filing cabinet of identical labels. Write the plain-language instruction you wish a clerk followed ("compose description from ship-to and lane fields; never output only the word freight") and ask any vendor whether that instruction can live on the vendor record.
Add two process questions while you grade:
1. How often does AP reopen the PDF solely to answer "which load was this?"
2. How often does ops Slack finance for the same answer?
Those frequencies are your local business case. Keep them honest. Do not inflate them for a blog-shaped story.
Where this does not help
We deliberately did not build a chatbot that answers logistics questions while leaving the bill description empty. The durable artifact is the description on the payable, not a chat transcript that disappears when the tab closes.
We also will not position description generation as freight audit automation or rate shopping. Those are different products. If the PDF itself lacks usable lane or ship-to text, we cannot hallucinate a precise route to make demos prettier.
One deep-call theme is not a vertical encyclopedia. Your carrier formats will need their own rules. Expect an authoring session, not a magic universal freight prompt.
And description quality does not fix bad vendor master data. If the supplier name is wrong, a beautiful lane sentence still hangs on the wrong record.
Why Claude-in-a-tab is a fragile operating model
The metals workaround was understandable. A general LLM can draft a decent lane sentence when a human pastes the PDF text. It fails as an operating model for three reasons.
First, it depends on someone remembering to do it every time. Busy weeks skip steps. Second, the prompt lives in a person's head or a sticky note, not on the vendor record, so quality varies by who is working. Third, the output is not tied to the AP object's audit trail unless someone pastes carefully.
Vendor rules fix the durability problem. The instruction sits on the carrier. The description lands on the bill. The next clerk inherits the pattern without opening a chatbot.
That still requires authorship. Someone has to write a good instruction once, then maintain it when the carrier redesigns their PDF. We are honest about that labor because hiding it creates disappointed buyers. The labor is far smaller than re-deriving "Freight" into meaning twenty times a week.
If your team already maintains SUMIFS logic for other vendors, you already have the muscle. Description rules are the same discipline pointed at a narrative field instead of at allocation math. Reuse that habit. Write the instruction. Save it. Spot-check the first ten bills.
FAQs
Can the same rule serve every carrier?
Sometimes a shared pattern works. Often each major carrier needs its own instruction because ship-to and lane language live in different places on the page.
Does this change the GL account?
Only if you also write coding rules. Description generation fills the narrative field. GL coding is a separate decision, even when both live as vendor instructions.
Close
Stop typing "freight" into the description like it is a complete thought. The bill needs a lane description because humans still have to find the move six weeks later. Put that sentence on the vendor as a rule, and let the next logistics PDF arrive already speaking ops.
