Every forwarder that books more tours than its own fleet can cover hands part of them to subcontractor carriers. The carrier drives. Afterwards it sends an invoice. Usually a consolidated one. Thirty to a hundred tours at once. As a PDF attached to a mail. Almost no forwarder runs a real carrier invoice reconciliation against it. Line by line. Against the agreed rate. Against the tour that the forwarder's own system says was actually run. Against the proof of delivery. The amounts are close enough often enough that nobody looks. Nobody has the time to recalculate every line.
That is not a small risk. Section 407 of the German Commercial Code obliges the principal to pay the agreed freight rate. Not the invoiced one. The gap between the two is real money. It almost always surfaces at the annual settlement, when a single tour from March is nearly impossible to reconstruct.
A consolidated invoice lists lines. Each line carries, in the best case, a reference. An order number. A plate. A date. In the worse case it carries only a lane and an amount. With no reference to the original booking at all. Every carrier ships its own format. One sends a spreadsheet. The column headers change month to month. Another sends a scanned PDF. The reference number sits in a note in running text. Not in its own field.
For billing that means: read first, check second. Date, lane, plate, amount, surcharge, reference. Out of every line, into fixed fields. It is the same step that carries order capture from mail and PDF. The matching is not what is new. Extraction from an inconsistent document into one data model is. Only here the reference runs the other way. It is not the order coming in. It is the invoice for it.
If the line carries an order or tour number, matching is trivial. A database lookup, done. If it does not, only a fuzzy match remains. Date, lane and plate, taken together. One truck, one plate, one day, one lane: almost always unique. Almost. If the same truck runs the same lane twice on one day, for two different orders, uniqueness breaks. That line has to go to a review list. Not into automatic matching.
One anonymised example. Baltic Freight hands its Hamburg to Poznan lane to three regular subcontractors. Two of them supply an order reference on every line. The third supplies only plate and date. For the third, the fuzzy match carries the entire assignment. Without it, every one of its lines would be a manual case.
Once a line is matched to its tour, the actual comparison happens. The target price comes from the stored rate. A flat fee per lane. A price per kilometer. Or a weight bracket. The actual price is on the invoice. Both numbers side by side. That is the whole point.
The real source of error rarely sits in the calculation itself. It sits in the billing unit. A rate per kilometer and an invoice with a flat fee price the same route two different ways. If the lane has shifted even slightly, both numbers drift apart. The right number on the wrong basis: that is the most common error. Not the number that is simply wrong.
A line that matches the rate exactly needs no person. It gets approved, logged, done. Every other line gets a fixed reason. Not a generic error.
That is the same idea that carries order capture from mail and PDF. It is not the match rate that counts. The reason column of the lines that did not pass counts. A growing "tour not run" category with one particular carrier is not a coincidence. It is a conversation somebody needs to have.
Every line with a reason lands on a list. Not in an automatic rejection. Not in a silent payment. Dispatch or billing sees the list. Line by line. Target price, actual price and reason next to each other.
For part of the lines, a draft is enough. A query to the carrier. With the line, the target price, and the reference that is missing or does not match. That draft does not go out on its own. It lands with the person who knows the carrier and makes the final call: pay, deduct, or clarify. Automation supplies the line and the reasoning. Not the decision on whether a rate was ever up for negotiation.
At the end of every invoice sits a protocol. How many lines. How many in the review queue. With which reason. Which queries are out. Which answer is still open. That protocol is exactly what is missing at the annual settlement, when reconciliation never ran during the year.
Three honest limits.
A fuzzy match on date, lane and plate stays a probability. Not proof. With carriers that supply no reference at all, the number of ambiguous cases grows. Every one of them needs a person who knows the forwarder's own tour list.
A surcharge without proof is not automatically wrong. Waiting time happens. The automation only shows this: the proof is missing. Not that the claim is unfounded. Whether a waiting period is covered under the framework contract stays a question for that contract. Not for a script.
And the German self-billing procedure under Section 14 of the VAT Act only moves the problem. It does not remove it. A forwarder that issues the credit note itself needs the same reconciliation. Just in the other direction. Before that credit note goes out. The duty to check changes sides. It does not disappear.
Without ongoing reconciliation, the annual settlement is a reconstruction. Who drove what, when, at which rate, with which proof. Out of records that are ten months old. With ongoing reconciliation, it is an export. The review queue of the last twelve months. With reason, decision and open rest. No reconstruction. Just reading.
How many of your subcontractor invoices currently go through with no line-level check at all? Send me the number, even a rough one. Is carrier invoice reconciliation the process that costs you the most time? Then I will show you in a process check what the reason column looks like for your three biggest subcontractors.
