The order confirmation nobody owns

Look at how a purchase order travels through a typical company. It gets raised from a reorder point, approved by a rule, formatted, and sent, all without anyone touching it. Then the supplier answers, and the answer lands in a shared mailbox where it sits until someone archives it.

The document with no owner

Every other procurement document has a home. Purchase orders belong to buyers. Goods receipts belong to the warehouse. Invoices belong to accounts payable, and they get matched against two other documents before anyone pays them.

The order confirmation belongs to nobody. It arrives between two automated steps, it changes what the supplier has actually agreed to, and in most companies it is filed without being compared to anything.

The cost of that shows up somewhere else entirely: as a stockout nobody predicted, as an invoice that fails matching, as a delivery promise made against a date the supplier never agreed to.

A version of this plays out constantly. A distributor orders forty cases of a consumable on a ten day lead time. The supplier answers the next morning: same quantity, same price, delivery in six weeks. The confirmation goes to the shared inbox. The ERP still holds the ten day date, so the availability calculation still looks healthy, so no replacement order gets raised, and sales quotes a delivery on that basis. The shortage is discovered on day eleven, when the goods do not arrive and the shelf is empty. The warning had been sitting in a folder for four weeks.

Nothing failed technically. The confirmation was received, it was accurate, and it was stored. It was simply never held up against the order.

Four fields that can disagree

An order confirmation can differ from the purchase order in four ways, and treating them as one category is the first mistake.

Most often it is the delivery date, where the supplier commits to something other than what you asked for. That one does the most damage, because the date feeds everything downstream.

Quantity comes next. The supplier confirms less than you ordered, or splits the line across two or three delivery dates, so one PO line turns into three confirmed lines.

Price differences happen because the confirmation carries the supplier's current list price while your PO carried whatever sits in your item master or contract. Somewhere between the two is a price increase letter that arrived and was filed.

Then there is the item itself. When a part is discontinued the supplier confirms the successor, sometimes with a note, usually with nothing but a different number in the line.

Each of these needs a different owner. Dates belong to planning, prices to purchasing, substitutions to whoever maintains item data. Send all four to one inbox and you have recreated the problem you started with.

A wrong date does not stay put

A wrong delivery date does more damage than a wrong price, and the reason is that it travels.

Your MRP run adds open purchase orders to on hand stock and decides from that whether to reorder. If the date it uses was never confirmed, the entire coverage calculation for that item is wrong, and the correction comes too late or not at all.

Your available to promise logic feeds the same open orders into what sales can commit to. Selling against an unconfirmed date is selling stock that will not be there. In healthcare supply that stops being a commercial issue: a kit that misses its date pushes a scheduled procedure.

Your inbound dock schedule is built from expected arrivals. Slots get reserved for deliveries that will not come, and deliveries arrive without slots. Both cost labour, and neither shows up in any report a buyer looks at.

What makes this hard to catch is that a wrong date does not look wrong. It produces a plausible number in a coverage report, that number drives a decision, and three weeks later the shortage gets investigated as a planning failure. Nobody traces it back to a PDF.

Then there is the revised confirmation. The supplier confirms your requested date and sends a second, updated confirmation two weeks later with a different one. It carries the same PO number, it looks identical, and it lands in the same mailbox. If the first one was filed, the second either overwrites it or is never noticed.

Price deviations are free until they are not

A price difference on a confirmation costs nothing while the goods are still in transit. It becomes expensive at invoice matching, where every exception takes weeks to clear.

The sequence is always the same. Your item master holds a price from last year. The supplier sent a price update that someone read and filed. The PO goes out at the old price, the confirmation comes back at the new one, and a four percent difference passes unnoticed. Goods arrive priced correctly. The invoice arrives priced correctly. Three way matching finds a price variance and blocks the invoice, and a clearing process starts between AP, purchasing, and the supplier over something that was documented in writing four weeks earlier.

At a few thousand POs a month, that clearing work is a full time role. Individually the cases are small. Collectively they are not, and most of them would not exist if anything had compared the confirmation to the order.

Deviations in your favour matter too, and they are the ones nobody looks for. If the supplier confirms a lower price because a promotion applies or a volume tier was reached, and your costing keeps using the old purchase price, your selling price stays where it was and the margin goes unclaimed. No exception report will ever surface that, because exception reports are built to find things that cost money.

Split lines break naive matching

Under confirmation is straightforward. Splitting is not.

Forty cases on the fifteenth becomes fifteen cases on the fifteenth and twenty five on the thirtieth. The confirmation now has two lines where the PO has one. Line by line comparison finds no counterpart, and depending on how it was written it either raises a deviation that is not one or silently drops the line because matching failed.

Properly handled, the PO line has to be split in the ERP. Most systems support it. All of them require someone to do it. Until that happens the ERP holds one line for forty on the fifteenth, both partial deliveries post against it, and you end up with an under receipt followed by an over receipt or an open remainder nobody closes.

Blanket orders with releases make this worse. The release references a contract, the confirmation references the release, and the remaining contract quantity is tracked in two places, yours and the supplier's. When those drift apart, nobody finds out until the contract expires and the two numbers disagree.

Rounding to pack size needs handling of its own. You order 100, the supplier confirms 96 because the case holds 24. That is not a supply problem, it is arithmetic, and it will generate a deviation on every single order of that item forever unless the comparison accounts for it.

Substitutions are the ones that hide longest

When a part is discontinued, suppliers confirm the successor. If you are lucky there is a note. Usually there is just a different number in the line and the same description.

Purchasing rarely objects. Everything downstream should. The successor often has a different pack size, a different weight, a different manufacturer reference. In regulated goods it may carry a different device identifier, and your customers still hold the old number in their own material masters.

In hospital supply chains this reaches all the way to the ward. If central stores receives a successor while the ward orders the predecessor, the internal requisition finds nothing. That is a master data problem, triggered by an order confirmation that was processed without anyone reading the part number.

Any comparison that checks quantity, price, and date will miss substitutions entirely, because it uses the item number as the key for matching rather than as a field that can change. That is exactly why this deviation survives the longest.

Auto posting the confirmation makes things worse

The obvious response, once you see the problem, is to write the confirmation straight into the ERP. Update the date, update the price, adjust the quantity. It can be built in an afternoon, and it is worse than filing the document unread.

Writing the confirmation into the PO means accepting whatever the supplier said, automatically, with no record that anything was ever different. Push the date from ten days to six weeks and the ERP now shows a six week date that looks like it was ordered that way. The coverage calculation becomes correct and nobody learns that a delivery slipped by a month.

On price the same mechanism has a direct financial effect. A workflow that writes confirmed prices into the PO converts every unilateral supplier increase into a change you accepted. Invoice matching then finds no variance, because the PO was moved to match the invoice. The control that existed for precisely this case has been switched off by the automation meant to help it.

The useful behaviour is not to adopt the confirmation. It is to compare it, apply tolerances, and surface what falls outside them with both values side by side.

Confirmations carry contractual weight

There is a reason this document exists at all, and it is not logistics. A confirmation that deviates from your order is, in most commercial law, a counter offer. Accept the goods and you have accepted its terms.

Which means a process that files confirmations unread is a process that continuously accepts terms nobody has looked at. On dates that is annoying. On prices it is expensive. On delivery terms it can decide who pays for freight and who carries risk in transit, which is not a footnote on cross border orders.

Then there is the clash of terms. Your PO references your purchasing conditions. The confirmation references the supplier's selling conditions. Both sets say their own prevail. Jurisdictions resolve this differently, and none of the resolutions favour the party that never read the acknowledgment. If you believe the warranty period from your purchasing conditions is agreed, it is worth checking whether anything ever confirmed it.

This is not an argument for legal review of every confirmation. It is an argument for capturing the fields where it matters. Adding delivery terms to the set of compared fields costs one more column and saves an argument that otherwise runs for months.

Every channel at once

Confirmations arrive on every channel that exists, usually several at once.

Larger suppliers send EDI, an X12 855 or an EDIFACT ORDRSP. Only there does the data arrive structured, with your PO number and line references intact. Companies that already have EDI get the comparison almost for free and frequently do not run it, because the message flows into the ERP and only updates a status flag.

The normal case is a PDF attachment. Layout varies by supplier, the PO number sits in the header or the subject line or a footer, and the line table changes column order and breaks across pages.

Smaller suppliers write the confirmation straight into the email body, often without line numbers, with the real information buried in a sentence: "line 3 will not ship until week 41".

Worst of all is the supplier portal, where no outbound message goes anywhere. The status changes and you find out by looking. There is not even a document to file.

Those four channels are why this rarely fails at the comparison. Comparing structured data is trivial. Turning a PDF reliably into lines is the actual work, and the effort is per supplier.

Matching is harder than comparing

Before anything can be compared, the confirmation has to be tied to the right PO and each line to the right line.

For the PO you need the PO number, which is present when the supplier echoed it. Some do not, and quote only their own sales order reference. Then you are matching on supplier, date, and item, which is not unique if you ordered the same item twice in one week.

For lines you need either the line number or the item number. Plenty of suppliers renumber lines, so your line 30 arrives as line 3. Item numbers are more stable, but the supplier usually quotes theirs rather than yours. Matching on manufacturer part number assumes it is populated in your item master, for every supplier you buy that item from.

This is where these projects stall. Comparing four fields takes an hour. Reconciling numbering schemes across 200 suppliers is master data work measured in weeks.

So the sensible scope is almost never all suppliers. It is the twenty suppliers covering most of your spend, with everything else left as it is. Those twenty usually have the cleanest documents anyway.

Where the comparison should live

Three options show up in practice.

Inside the ERP, using whatever document matching module the vendor ships. Where it exists this is the best answer, because order data, tolerances, and authorisations stay in one place. The limitation is that these modules expect structured input and cannot do anything with a PDF.

In an automation platform, reading the mailbox, extracting the document, pulling the PO through an API, and comparing. This is the usual route once PDFs are involved. It fails slowly when tolerances live in the workflow rather than the ERP, because then purchasing cannot adjust a threshold without going through whoever maintains the workflow. Six months later the values are still whatever they were on day one.

At a service provider, usually alongside invoice capture. If you already outsource inbound invoice scanning, confirmations often fit the same contract.

Whichever route, one rule holds: the result of the comparison belongs on the PO in the ERP, not in a list beside it. The moment "this line deviates" lives in a spreadsheet or a chat channel, it is separated from the document it describes. Six weeks later, when someone asks why the delivery was late, they will look in the ERP.

Keep the source document reachable too. Every extraction is wrong eventually, and then somebody needs the original. A link to the PDF on the PO line costs nothing.

Tolerances decide whether anyone keeps reading

Once comparison runs, the next problem is volume. Without tolerances it flags roughly every second confirmation: one day of date movement, two cents of rounding, four units short because of case quantity. Report all of that and within two weeks nobody opens the list. That is worse than before, because now there is a report that creates the impression of a control.

Set tolerances per field, ideally per category. Reasonable starting points:

Date movement inside your existing safety time is not worth a message. Three days of planning buffer absorbs two days of slippage. The threshold sits where the delay starts eating into coverage, and the message belongs with planning.

For price, the absolute difference matters more than the percentage. Two percent on a forty euro line is noise. The same two percent on thirty thousand euros is not. Trigger on either three percent or a fixed amount, whichever comes first.

Quantity needs pack size rounding stripped out before anything is compared. A shortfall that exactly matches rounding to the next case is not a finding. Anything beyond that is, regardless of size.

Item numbers get no tolerance at all. A different part number always goes to a person.

Treat these as starting values. The routine that matters is reviewing the flagged cases after a month and moving the thresholds. What matters more than the numbers is that somebody is named to move them.

The confirmation that never arrives

Almost every implementation misses this one: no confirmation at all.

A comparison can only compare what exists. If a supplier never answers, there is nothing to check and the workflow correctly reports nothing. The PO sits open at the requested date and everything looks fine.

That silence is a signal. A supplier who normally confirms within 48 hours and has sent nothing in five days either did not receive the order or has a problem. You want to know either one before the delivery date passes.

The check is small: a daily job listing POs older than N days with no confirmation, where N comes from that supplier's usual response time. It needs no document extraction, no line matching, and no tolerances. It regularly catches orders that died in a spam filter or went to an address that no longer exists.

Pound for pound this is the most useful thing you can build here. Start with it.

Confirmed is not the same as delivered

One habit forms as soon as matching is running: treating the confirmed date as a reliable date. It is a statement, and statements vary in quality.

Some suppliers confirm whatever you asked for and ship when they ship. Others quote three weeks later than necessary and hit it every time. A process that treats both the same has moved the problem rather than solved it, replacing unconfirmed dates in the ERP with confirmed dates that are equally unreliable.

The comparison that exposes this runs between confirmation and goods receipt, not between order and confirmation. You already hold both timestamps for every line. Aggregated per supplier, they produce a number that says what a confirmation from that supplier is worth.

That number is useful twice. In planning it sets safety time, since a reliable supplier needs less buffer than one that habitually runs a week late. In annual negotiations it is the only argument on this subject that does not rest on anecdote. "You are often late" starts a debate. "Over the last twelve months, 34 percent of your deliveries arrived more than five days after the date you confirmed yourself" produces a commitment.

Build this alongside the matching. The data is already being joined, so the marginal cost is close to zero, and it is the part that goes beyond avoiding errors.

Check your own process

Open the mailbox where confirmations arrive and count how many of the last four weeks' messages have been opened. That number describes your process more accurately than any procedure document.

Pull the price variance exceptions from AP for the last quarter and take a sample. For each one, check whether the differing price was already stated on the order confirmation. In the processes we look at, that share usually lands somewhere between half and two thirds.

Then take ten open POs and compare the delivery date in the ERP with the date the supplier actually confirmed. More than two mismatches means your planning is running on dates nobody agreed to.

None of this is usually a systems problem. The confirmation arrives, it contains the right information, and it gets filed before anyone holds it against the order. What is missing is the comparison and a threshold at which somebody looks.