}

Order confirmation check in logistics: confirmed is not ordered

By
Bodo Buschick
•
5 min
Order confirmation check in logistics: confirmed is not ordered

We run a check workflow for order confirmations in logistics. It counts its runs like any automation. Eight daily counters between August 24 and September 14, 2026. Together 2,128 orders checked. 1,749 of them corrected. Roughly 82 percent. Not 82 percent errors. 82 percent confirmations that deviated from the order. Different quantity. Different date. Different loading point. An extra line item nobody ordered.

The interesting number is not the 82 anyway. It is the 18 percent. The ones that pass without a look. Because nothing stands out. That is where the problem sits.

The confirmation is legally not a confirmed order

Section 150(2) BGB is clear on this. An acceptance with changes counts as a rejection. Combined with a new offer. A forwarder orders a run for a date. The carrier confirms a different one. That is not a confirmed order. It is a counter-offer. The buyer would have to accept it first.

In practice, nobody actively accepts anything. The confirmation arrives as a PDF. It gets skimmed, if that. It gets filed. Nobody clicks "agreed." Legally, the matter stays open. Until the truck runs or the goods arrive.

A second rule makes this worse. German trade law knows the doctrine of the merchant's confirmation letter. Its basis is Section 242 BGB, good faith. Shaped by case law since the Federal Court ruling of June 26, 1963. Staying silent counts, exceptionally, as agreement. Unless the deviation is too large. Nobody can draw that line. Not without reading the confirmation against the order.

Two rules, one outcome. Leave a deviating confirmation unanswered, and you can be bound by it. By a deviation you never checked.

Why the check still happens at the ramp

The reason is unglamorous. The order and the confirmation live in two formats. The order sits in the TMS, structured, with fields. The confirmation arrives as a PDF, with its own layout per partner. Two documents, no shared view.

So the comparison happens by eye. If it happens at all. With ten confirmations a day, that still works. With a hundred, it does not. The deviation surfaces at the ramp. When the truck shows up with the wrong quantity. Or three weeks later, on the invoice.

Both moments are too late. One costs demurrage and a rushed call. The other costs a complaint nobody can explain anymore.

How the check runs before the truck leaves

We build automation for road logistics companies anyway. For documents no system connects cleanly. The confirmation check is the same mechanism. Just earlier in the process. Four steps.

First: the confirmation gets extracted from the PDF. Quantity, date, loading point, price, extra items. Line by line.

Second: every line gets matched to the order line. By article or order number. Missing a reference, a fuzzy match kicks in. On date, route, and quantity. This is the case that matters most. Without a reference, any match is a guess. A guess needs a confidence score. Not a silent yes.

Third: every line gets a deviation class. Quantity is off. Date is off. Price is off. An extra item appears. A line is missing entirely. Five classes, each with its own tolerance. Two hours late is a different case than two days.

Fourth: anything outside tolerance goes to a review queue. Tagged with the deviation class as the reason. Not a green dot. Whoever opens the line sees the issue at once.

What the review queue does, and does not do

For every flagged line, the system drafts a reply. Short text to the partner. The deviation named. The order line next to it. The draft never goes out on its own. Someone in purchasing or dispatch reads it. Edits it, sends it. Or discards it.

Every confirmation gets a log. What got read, matched, decided. That is the difference from filing. A folder of PDFs answers no question later. A log of lines does.

What changes for purchasing and dispatch

The biggest change is timing on the date. A different confirmation today surfaces in route planning. When the slot is already booked. With the check, it is on the table earlier. A call the day before. Not a rebooking on the day.

For quantity, the place of resolution shifts. No longer the ramp, with a waiting driver. The screen instead, earlier. For an overconfirmation, this matters most. Accept it without objection, and you may owe more than agreed.

A person still decides. The call, the no, the go-ahead. Automation only moves the timing. From the ramp to the inbox.

Where this check breaks

Three honest limits.

A fuzzy match without a reference stays a guess. On similar, parallel orders it can miss. So every uncertain match goes to review. Even without a number off.

Some confirmations arrive as a fax scan or free text in an email. Extraction gets less certain. Not wrong, just less certain. That also lowers the confidence score.

Tolerances are not set by any agent. How much deviation is acceptable is a call for purchasing. The system delivers the number and the class. A person draws the line.

Where this check sits in the chain

Before it comes order capture from mail and PDF. The incoming order against master data, before the order exists. After it, once the run is driven, comes carrier invoice reconciliation. The invoice against rate and run. The confirmation check sits between the two. The only one still correctable before departure.

Tools

Line-by-line PDF extraction. Matching by reference, fuzzy match as fallback. Five deviation classes, each with its own tolerance. A review queue tagged with a reason. A reply draft, never sent on its own. A log per confirmation. None of this needs a new system. Just one look, order next to confirmation, before departure.

How many of your confirmations get checked line by line today? If the answer is "none," I will show you the match in a process check. On a real, anonymized confirmation.