Shipped vs. Seen: Reconciling the ASN Against the Events

Your RFID rollout is funded and in flight, and you are measured on receiving labor and inventory accuracy — which means you are measured, ultimately, on one question asked hundreds of times a day at every DC you run: does what the supplier said was shipped match what actually arrived?

Walk how that question gets answered today. The ASN — the advance ship notice your supplier transmitted before the truck left — lands in the EDI stack and posts to the ERP. The truck arrives; your dock team scans, counts, keys. The two records describe the same physical delivery from two sides, live in two systems, and meet in the middle at a human being: someone comparing a screen against a clipboard, delivery after delivery, shift after shift. Most deliveries match. Your people spend the day confirming matches — receiving as data entry — and the mismatches that matter are found late, disputed later, and written off more often than either side would admit.

The fix is not more scanning. It is putting both sides of the comparison in the same record — which the standard already provides for, because an ASN is desadv in the Core Business Vocabulary and every EPCIS event carries a bizTransactionList naming the documents it answers to (CBV 2.0 §7.3, §8.5 — the spec citations are laid out in po and desadv Are Core CBV). When the dock's receiving events each carry the ASN's reference, "shipped vs. seen" stops being a comparison between systems and becomes a query inside one.

One delivery, reconciled

The worked example — content in its own words, no spec text reproduced. A supplier's ASN announces a mixed delivery under shipment reference SHIP-0731-114, against your PO PO-88123:

The dock captures receiving events as the pallets cross the door — each event carrying the case identities seen, the receiving business step, the attested observer who worked the door (who, distinct always from capturedBy, the warrantor account), and on its bizTransactionList, the references desadv: SHIP-0731-114 and po: PO-88123.

Reconciliation then runs as a comparison the record performs on itself, line by line:

Line one — the overwhelming majority of every receiving day — closes itself. Line two becomes a dispute you can actually have: two cases short against a declared reference, with the receiving events, their timestamps, and the attested observer who worked the delivery already assembled. Line three is the one a spreadsheet reconciliation misses and a lot-blind system cannot even express: the count matches, but the lot is not the lot declared — a substitution that matters enormously on covered foods, caught mechanically because the comparison runs at lot grain, not case-count grain. The discrepancy report that falls out is the content of your receiving advice back to the supplier — the recadv, closing the document loop with the same vocabulary the ASN opened it with.

Receiving as an exception discipline

The ROI shape here is the one you are already measured on, so state it in those terms. Staff work the mismatches, not the matches. When the match rate is what match rates typically are, the labor model inverts: the mechanical majority closes without a touch, and your receiving hours concentrate on the deliveries where judgment earns its wage. That is where receiving-efficiency gains actually live — not in scanning faster, but in never manually confirming what two records already agree on. And every exception your team works arrives pre-assembled: declared line, seen events, observer, timestamps, document references — the difference between opening an investigation and opening a phone call. The wider operational case for capture at receiving, including the public third-party evidence for it, is the restaurant-chain traceability brief; this post is the mechanism underneath its receiving line.

There is a compliance dividend, too, stated as the floor it is: the receiving events that drive the reconciliation are the same events that carry your FSMA 204 receiving KDEs — lot, product, location, date, quantity — so the exception discipline and the regulatory record are one capture, not two programs. The gap between the KDEs the rule reaches and what your suppliers actually send is measured on its own; this reconciliation is the instrument that measures it, delivery by delivery.

What to ask of suppliers

A reconciliation is only as good as the ASN's grain, so the supplier conversation this quarter is short and specific. Ask for three things: lot-level lines (a case count without lots reconciles at the grain of line three's miss), case identity where they already serialize — many of your suppliers are re-marking cases on the Sunrise timeline anyway, which makes this the cheap ask — and the shipment reference carried through consistently, so the join key survives. Suppliers already emitting the despatch-advice hierarchy have everything required; the tree inside their ASN is worked from their side in The ASN's Hierarchy Is Your Custody Tree, and the developer door for wiring document feeds into the record is transactions.dev.

The one-line version for your next ops review: the ASN tells the record what to expect; the events tell it what happened; the record itself tells your team where those differ — and your people work only the differences.

The door here is the get-started interview: your email first, then a short interview that branches on your answers — the restaurant-and-distribution branch asks where your scanning reads actually land today, what triggered your last trace-back and how long it took, and whose data a franchise unit's scan contractually is. We answer in writing.