Image: Southeastern Freight Lines truck by Indy beetle, licensed under CC0 1.0.
Your exception queue holds two different kinds of item. One says the carrier billed 1,840 dollars of line haul against a contracted 1,615, and an analyst settles that in four minutes with the rate table open. The other says nothing at all, because the invoice carries a PRO number that matches no shipment in your TMS, and until somebody works out which load it belongs to, there is no rate to check it against.
The second pile is where the hours go, and it is the pile that gets described as a data quality nuisance rather than an audit failure. Rate variance is arithmetic. Load resolution is an identity problem, and identity in freight rests on reference numbers that were never built to be unique, stable, or self-checking.
The keys were never designed to hold
Compare two parts of your own freight for a moment. An ocean container number under ISO 6346 is a structure that validates itself: three letters of owner code registered with the Bureau International des Conteneurs in Paris, an equipment category letter, a six-digit serial, and an eleventh character that is a check digit computed modulo 11 over the first ten. Transpose two digits and the number fails its own arithmetic before it reaches anyone's inbox.
An LTL PRO number has no equivalent property. It is the carrier's tracking reference, assigned at or before pickup, and there is no cross-carrier format behind it. Some are numeric, some alphanumeric, some carry a check digit of the carrier's own design and some carry none. A transposition in one of those survives every system it passes through and arrives at your audit as a load that does not exist.
The carrier identifier is softer than it looks too. The National Motor Freight Traffic Association issues SCACs and renews them annually through its own application system, which makes the code on an invoice a current assignment rather than a permanent fact about a company. Meanwhile the shipper's own reference, the BOL number, is whatever your WMS printed, and the EDI 210 that carries all of this puts its references in the B3 beginning segment and in N9 segments whose meaning depends on a qualifier your trading partner guide defines locally.
So the join key between an invoice and a shipment is a free-text field, issued by one party, retyped by another, and interpreted under a convention negotiated per carrier. Exact matching on that is an optimistic act.
Six failures wearing one label
"We could not find the load" is a verdict, not a diagnosis. Underneath it sit causes that need entirely different fixes.
- The reference is correct but shaped differently. Leading zeros, a hyphen, an embedded SCAC prefix, a check digit the carrier includes and your TMS strips.
- The shipment sits under a different carrier. A broker re-tendered the load and billed under the SCAC that actually hauled it.
- No shipment record exists. A spot move booked by phone or email never reached the TMS, so there is nothing to match against at any price.
- The invoice covers several shipments. One consolidated bill against five BOLs will not match any of them one to one.
- The invoice simply arrived first. Upwell's own product documentation makes this point bluntly: a brand-new invoice always shows matching findings such as "no matching shipment," and those findings clear on their own once matching completes. It tells users not to judge exceptions until ingestion has run.
- An attribute moved. The shipment was created to one destination and delivered to another, so origin and destination no longer agree.
Kuebix publishes the mechanics plainly in its TMS help documentation: a shipment matches an invoice only when the PRO and BOL numbers are an exact match on both, and the listed causes of failure are that the PRO differs, the BOL varies, the origin or destination state varies, or the shipment was never created. Where nothing matches, it offers the operator two exits: delete the invoice, or create a shipment record so the invoice can be approved. The second exit is how an entirely unaudited charge becomes a paid one, and it is a button, not an escalation.
The resolution chain, in order
Penny treats resolution as a ranked sequence rather than a single query, and she records which rung produced the answer.
- Exact key. PRO plus SCAC against open shipments.
- Normalised key. Strip hyphens, spaces, leading zeros and carrier prefixes, then re-match. AR Traffic Consultants, in a case described in Inbound Logistics, searched the client's accrual file on BOL and PRO without the SCAC, added further search layers for whatever still failed, and brought unmatched invoices below one percent.
- Secondary references. BOL, purchase order, shipper reference, delivery receipt number, each tried against the fields that actually carry them.
- Document extraction. Read the POD and the rate confirmation attached to the bill and recover the references the EDI never transmitted.
- Attribute match. Origin and destination ZIP, pickup date window, weight, piece count, freight class, accessorial pattern, carrier.
- Candidate scoring. Declare a match only when exactly one candidate survives the evidence.
Every rung down widens the net and lowers the confidence. The order is the point. A load identified at step one on an exact key and a load identified at step five on three attributes are different claims about the world, and recording them as the same thing is how the right invoice gets audited against the wrong contract.
Where Penny declines to guess
Two loads, same carrier, same lane, same week, 150 dollars apart on line haul. Origin ZIP, destination ZIP and weight fit both. Penny does not pick one. She returns the candidate pair, names the field that would separate them, usually the delivery date or the POD signature, and sends the item back as a question instead of a verdict.
That behaviour demos badly. A vendor who resolves one hundred percent of your invoices is resolving some of them incorrectly, and the two outcomes are not symmetric in cost.
| Unresolved, returned with a question | Resolved on a guess | |
|---|---|---|
| Where it goes | A queue a person reads | Straight to approval |
| What it is checked against | Nothing yet | The wrong contract, confidently |
| How you find out | Immediately, by looking | Months later, or never |
| What it leaves behind | A named missing field | Corrupted lane cost history |
That last row is the expensive one. A misattributed charge lands on a lane that did not incur it, and the distortion propagates: your accrual, your cost per hundredweight, and the baseline Miles quotes against at the next bid. The same confusion between a measurement and an inference runs through three-way matching was built for purchase orders, not freight.
The clock you are actually racing
Statute is not the pressure. Under 49 U.S.C. 14705(b), a person must begin a civil action to recover overcharges within 18 months after the claim accrues, and subsection (a) gives the carrier the same 18 months to sue for charges owed. Eighteen months is generous next to an exception queue.
Your own terms are what bite. The invoice has a pay-by date, the carrier has a relationship with your transportation team, and an item that sits unresolved past that date gets released to keep trucks moving. Nobody decides to pay an unaudited charge. The queue decides it by aging.
What to do next
Stop reporting the exception queue as a single number. Break last quarter's unmatched invoices into the six causes above and the shape of the problem usually turns out to be two of them, not all six. Then measure the figure almost nobody tracks: how many invoices you paid last quarter with no shipment record behind them, and what they totalled.
Finally, age the unmatched queue and look at what leaves it by resolution against what leaves it by deadline. If you want to see the chain run against your own data, book a walkthrough and bring a month of invoices your current process could not match.