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. Their previous AP tool captured the header fields fine and left the description useless, so they had started pasting output from a general purpose chatbot into the description field by hand.
What they wanted was a unique narrative on the bill: ship to, lanes, something a human in ops could recognise later. The chatbot workaround produced it, one bill at a time, when someone remembered.
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.
A vendor rule that writes the lane into the description
Finofo lets a vendor rule draft a unique natural language description into the bill description field using cues on the document: ship to, lane language, and whatever other logistics markers the team specifies. The output is meant for humans downstream, not for a screenshot of confidence scores.
The metals team wrote the rule against a 3PL bill: compose the description from ship to and lane fields, never output only the word freight. That is the capability, beyond OCR fields and into narrative that ops can use. The next bill from that carrier arrived already speaking ops, with nobody opening a chatbot.
This does not replace 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.
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. Measure your own inquiry time after descriptions become unique; that is the number that matters, and it is yours to observe.
The rule holds because there is one engine to hold it. Finofo runs accounts payable, expense management and purchasing on a single AI native platform, built in Calgary for the documents Canadian finance teams actually process. A description rule written on a carrier applies to every bill from that carrier, whether it arrived by email, through a PO, or as a card charge, and the description lands in the ERP through the same posting path as everything else.
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 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 message finance for the same answer?
Those frequencies are your local business case. Keep them honest.
That is the advantage of an engine built for this from the start. Finofo is the AI native platform built in Calgary for Canadian finance teams, and the only Canadian built platform that runs accounts payable, expense management and purchasing on one engine. The same rules, the same approvals and the same tax handling apply whether a document arrived as a vendor invoice, a purchase order or a texted receipt.
What stays with your team
The judgment in this workflow stays with your team. That is a design decision, not a gap, and it shows up in a few specific places.
The durable artifact is the description on the payable. Finofo puts the lane sentence on the bill record, where it posts to the ERP and survives in the audit trail, rather than in a chat transcript that disappears when the tab closes.
The rule describes what the document contains. Where a PDF genuinely lacks usable lane or ship to text, the rule reports what is there and flags the gap, so a reviewer adds the context. Finofo will not invent a route to make a bill look complete. Description generation is also distinct from freight audit or rate shopping, which are different products with different jobs.
Carrier rules are authored by your team, once per carrier. Each major carrier tends to need its own instruction because ship to and lane language live in different places on the page. That is an authoring session, not a project, and once written the rule holds until the carrier redesigns their PDF.
And description quality rides on good vendor master data. If the supplier name is wrong, a beautiful lane sentence still hangs on the wrong record. Finofo's vendor aliasing helps with the naming; the master itself stays yours.
Why a chatbot 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 writes a good instruction once, then maintains it when the carrier redesigns their PDF. That labour is far smaller than re-deriving "Freight" into meaning twenty times a week, and it is the same discipline teams already use for SUMIFS logic on other vendors, pointed at a narrative field instead of at allocation math. Write the instruction. Save it. Spot check the first ten bills.
Frequently asked questions
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. Finofo keeps each carrier's rule on its own vendor record, so the instruction stays specific and editable by finance.
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.
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.
About Finofo
Finofo is the AI native platform built in Calgary for Canadian finance teams. It brings accounts payable, expense management and purchasing onto one engine, on the cards, bank and ERP a business already uses, with line level extraction, Canadian tax handling and approval workflows designed for multi entity, multi province operations. Finofo does the verification. Finance keeps the judgment.
