The ASN said 48 cases. The dock saw 47. Now what?

Written for ED-2 — the RFID systems-integrator / VAR practice — the field deployment engineer commissioning a receiving site who needs a result to show the client today.

One thesis: once the paperwork and the portal both speak GTIN and SSCC, "does what was shipped match what was seen" stops being a phone call and becomes a set comparison — four typed verdict classes, one exit code, and an output that is exactly what a receiving advice needs.

The question, stated as set algebra

You are on site. The readers are mounted, the events are flowing, and the client's operations lead asks the only question that ever matters at commissioning: is it right? Strip the question to its structure and it is set algebra over identifiers.

The ASN contributes the document set: the cases and lots the sender claims shipped — class-grain quantities per GTIN and lot, serial sets where the sender serializes, all of it compiled from the 856 into events with the desadv and po references attached. The dock contributes the observed set: the EPCs and classes the receiving events actually captured. Both sides are keyed the same way — the GTIN join, SSCC for logistic units — so the comparison is intersection and difference, not interpretation.

The four verdict classes

Every element of the comparison lands in exactly one class, and each class is typed — a machine token, not a prose remark:

• matched — claimed and seen; identifiers agree at the finest grain both sides carry.
• missing — claimed by the document, absent from the events. The short-ship, the stolen case, the mis-read.
• unexpected — seen at the dock, absent from the document. The over-ship, the wrong-truck case, the substitution's other half.
• lot_mismatch — the GTIN matched but the lot did not: the document said L42, the dock read L57. The class that matters most in a food-safety deployment and the one a quantity-only comparison can never see.

The worked report

One synthetic 856 claiming 48 cases across two lots, against a captured receiving-event set with one case never seen and one lot substituted. The reconcile report, as the verb emits it:

{
  "document": "urn:epcglobal:cbv:bt:0614141000012:SHIP20260730001",
  "po": "urn:epcglobal:cbv:bt:0724142000017:PO-8812",
  "claimed": { "cases": 48, "lots": ["L42", "L57"] },
  "observed": { "cases": 47 },
  "verdicts": [
    { "class": "matched",      "gtin": "00614141123452", "lot": "L42",
      "claimed": 36, "observed": 36 },
    { "class": "missing",      "gtin": "00614141123452", "lot": "L42",
      "claimed": 12, "observed": 11, "delta": -1 },
    { "class": "lot_mismatch", "gtin": "00614141765430",
      "documentLot": "L57", "observedLot": "L58", "quantity": 12 }
  ],
  "verdict": "DISCREPANT",
  "exit": 1
}

Read the exit-code line carefully, because it is the contract the whole report rides on: exit 0 means clean reconciliation, exit 1 means the comparison ran to completion and returned a negative verdict, exit 2 means the inputs were unusable. A discrepancy is a result, not a failure — the full argument for that contract is the reconcile-is-a-verdict post, and it is what lets you wire this report into a go-live gate: the site passes commissioning when the reconcile job runs discrepant-free for the agreed window, and the transcript is the acceptance artifact you hand the client. On go-live day, the demo is one shipment, one report, printed — the client watches their own ASN meet their own dock.

A field note that matters at real sites: the comparison is a pure function of two sets, so it re-runs. A portal that buffered reads through a network outage changes the observed set when it flushes; re-running reconcile over the same ASN then upgrades this morning's missing case to matched without human edits — the verdict history is itself evidence of when the site actually knew what.

Why this is a phone call today

At a franchise or co-manufacturing boundary, the two sets live in two companies. The sender's WMS knows what it claims; the receiver's system knows what it saw; neither speaks the other's grain, so the discrepancy surfaces days later as an invoice deduction and gets resolved by a phone call between two people reading two screens. What changes the physics is shared identifiers on a shared record shape: when the claim is a conformant EPCIS document with desadv and po references and the observation is the same, the comparison needs no meeting — either party, or the read-side view both of them buy, computes the same four classes from the same two sets.

From verdict to receiving advice

The report is not the end of the cycle; it is the input to the document that closes it. Received 47, accepted 47, one line short, one lot substituted — that is, field for field, what a receiving advice says. The recadv reference and the receiving event it rides on are the next post: the reconcile verdict becomes the counterparty's paperwork, and the loop — po to desadv to recadv on one record — closes without a spreadsheet.

If your next commissioning has a receiving bay and a skeptical operations lead, start at the door: the onboarding flow asks what record your receiving side holds today and at what grain the last shift actually captured.

---

828 words. The access flow is at /get-access/; the family's event door is epcis.dev.