EDI 810: How a Mismatch Becomes a Deduction

You run supply chain or finance at a $10M to $500M CPG supplier, and a shortage code just showed up on a remittance. The warehouse confirmed everything shipped. The BOL matches the PO. The truck made its appointment window.

Your team went looking for the missing goods and found nothing missing.

The goods aren’t short. Your data is. One field in the item master, the case-pack count or the unit of measure, was stale when the purchase order downloaded. That stale field traveled through the 856 ASN, through the 810 invoice, and into the retailer’s three-way match without a single validation catching it. The match found a disagreement between your invoice and the receiving scan, and recorded a shortage.

The cost isn’t the one deduction. It’s that the same field stays wrong, the same mismatch fires on every shipment to the same retailer, and your team writes it off each month because the dispute labor exceeds the dollar amount. The root cause is invisible from the remittance.

This piece follows one mismatch through the full document chain, from purchase order to remittance. It connects the rest of this site’s EDI content and deduction-code entries into a single causal chain: most shortage deductions are data problems, not warehouse problems.

What is an EDI 810, and where does it fit in the chain?

The EDI 810 is the electronic invoice you transmit after shipping to bill the retailer for what you sent.

It sits at the end of a three-document sequence: the retailer sends you an 850 purchase order, you ship it and transmit an 856 Advance Ship Notice describing what’s on the truck, then you bill for it with an 810.

Five segment groups inside the 810 determine whether the invoice clears the retailer’s match or triggers a deduction:

• BIG: the beginning segment. Invoice number, invoice date, and the PO number in BIG04. That PO reference is how the retailer’s AP department links this invoice back to the original 850. A mismatched or closed PO reference rejects the invoice before anything else gets checked.
• N1 loops: party identification. Remit-to, ship-to, bill-to. A ship-to that doesn’t match the PO’s destination is how a code 25, “no merchandise received for invoice,” originates, because the retailer’s system has no receiving record at that DC to match against.
• IT1: the line-item detail loop. Invoiced quantity, unit of measure, unit price, and product identifiers (UPC, vendor part number, buyer item number). This is the field set that gets compared against the PO line and the receiving scan. Every IT1 line must align 1:1 with the 850 and the 856.
• SAC: allowances and charges. Freight, promotional allowances, early-pay discounts. A disagreement here produces a pricing-family deduction like code 10, “price difference”.
• TDS: the total invoice amount. Must equal the sum of all IT1 line extensions plus any SAC allowances or charges. A footing error rejects the entire invoice.

What is a three-way match, and how does it decide if you get paid?

The retailer’s AP department compares three records before releasing payment on an invoice. This is the three-way match:

1. The 850: what was ordered (quantity, price, item).
2. The receiving record: what the warehouse scanned in, staged by the 856 you sent before the shipment arrived.
3. The 810: what you invoiced.

If all three agree, the invoice clears. If any leg disagrees, the system either rejects the invoice outright or short-pays it by the difference.

That short-pay shows up on a remittance as a deduction code. The remittance line doesn’t say “invoice quantity differed from receiving scan.” It says shortage, or compliance chargeback, or pricing deduction, depending on which field disagreed and by how much.

This is why these are hard to trace. By the time you’re reading the remittance, thirty to sixty days have passed. Nothing on the deduction line tells you which document created the disagreement, or which field inside that document was wrong.

One case-pack mismatch, followed through every document

Here is what happens when a single stale field in your item master travels through the entire chain and becomes a shortage deduction for goods that physically arrived in full.

The setup. Your item file has a product with a case pack of 12 (12 eaches per case). That was correct at onboarding. Three months ago the retailer’s buyer agreed to change the pack to 6. Your sales team confirmed the change. The buyer updated the PO terms. Nobody updated the item master in your ERP.

The 850 downloads. The retailer sends a purchase order for 10 cases. Your ERP reads 10 cases, applies the stale case-pack count, and calculates 120 eaches (10 x 12). The correct count at the new pack size is 60 eaches (10 x 6). No validation fires. The PO looks clean inside your system.

The warehouse picks. Your warehouse picks 10 physical cases. Each case contains 6 units, because the warehouse received the updated product while the item file didn’t. 60 eaches go on the truck. The pick is correct.

The 856 transmits. Your ERP generates the ASN from the item fulfillment record. Depending on how your connector is configured, it either pulls the order quantity (120 eaches, wrong) or the confirmed pick quantity (60 eaches, right). If it pulls from the order, the ASN already disagrees with the physical shipment. If it pulls from the pick, the ASN is accurate, but it’s about to disagree with the invoice.

The 810 transmits. Your ERP generates the invoice. The IT1 line carries the invoiced quantity from the sales order, which inherited the stale item file. It bills for 120 eaches at the per-each unit price.

The retailer’s receiving scan. The DC scans 10 cases. Each case contains 6 units. 60 eaches received. Their system now holds either 60 eaches received against an 856 that declared 120 (if the ASN pulled from the order), or 60 eaches received against an 856 that also said 60 (if the ASN pulled from the pick).

The three-way match. The 810 says 120. The receiving scan says 60. The match fails. AP records a shortage of 60 eaches.

The remittance arrives. Thirty to sixty days later, a shortage code shows up on your check. On Walmart, it might be code 22, “merchandise billed not shipped.” On Amazon, an ASN Accuracy chargeback. The deduction line names the PO, the invoice number, and the dollar amount. It does not say “your item file’s case-pack count was wrong.”

Your warehouse confirms the shipment was complete. Your logistics team confirms the delivery was on time. No one can explain the shortage, because there was no shortage. The same mismatch will fire again on the next order to the same retailer, and will keep firing until someone updates the item file. And the invoice mismatch is rarely the only code on the remittance: a single bad ASN can cascade into five separate chargeback categories from one shipment, each filed as a separate event.

Which mismatches produce which deduction codes?

The worked example above is a UOM/case-pack mismatch. Other item-file and document-chain mismatches land as different codes on different retailers.

The full deduction-code lookup covers what each code claims, what evidence reverses it, and how to prevent recurrence.

Where should you put the validation gate to prevent this?

By the time a deduction posts, the dispute window is ticking, the shipment is weeks gone, and the evidence is scattered across your ERP, your VAN, and the retailer’s portal.

The fix is a validation between your ERP and the outbound transmission.

Before the 856 transmits. Reconcile the ASN’s SN1 quantity against the confirmed pick, not the order quantity. The EDI 856 pre-transmission checklist covers the six failure modes and the specific check for each one. On NetSuite, the NetSuite EDI 856 playbook covers five ERP-specific gaps: item cross-references, UOM conversion, pick-confirm timing, subsidiary mapping, and kit explosion. On Business Central, the BC version covers item references, Qty. per Unit of Measure, posting timing, ship-to/GLN mapping, and assembly kits.

Before the 810 transmits. Compare your own three records before the retailer compares theirs: PO price vs. item master price vs. invoice price, and invoiced quantity vs. confirmed pick quantity (not order quantity). If the 810 disagrees with the 856 you already sent, block the invoice. A blocked invoice is a conversation with your team. A transmitted 810 with a quantity mismatch is a deduction on your remittance.

At the item file. This is the upstream root. When a pack-size change, a UOM update, or a cost change is agreed with a buyer, the item master has to reflect it before the next PO downloads. The worked example above would have been prevented by a single field update. Item-file drift between your ERP and the retailer’s system is the most common cause of recurring shortage deductions that have nothing to do with the physical shipment.

An 824 Application Advice, where the retailer sends one, can flag a content mismatch before it becomes a deduction. A 997 Functional Acknowledgment cannot. The 997 confirms the file parsed as valid syntax. It says nothing about whether the quantities inside it make sense.

What to do about it

If you’ve been writing off recurring shortage deductions because the warehouse says everything shipped and the dispute cost isn’t worth it, the problem probably isn’t in the warehouse.

It’s in the item file. One stale field, carried through every document in the chain, producing the same deduction month after month on every order to the same retailer.

Finding which field, in which record, feeding which document is the specific gap a data-bridge assessment is built to close. The data-bridge calculator gives you a rough number for what that gap is worth before you commit to finding it.

Or look up the specific code on your remittance in the deduction-code hub and work backward from there.

If your ERP says the shipment posted in full but the retailer deducted for shortage, the invoice may not be the only break. Four quantities from four systems create the gap. The root-cause trace walks through the full chain.

Segment names and the three-way-match structure described here follow the public X12 standard. Retailer-specific tolerance rules, match thresholds, and which mismatches trigger automatic short-pay vs. invoice rejection vary by trading partner. If a detail here doesn’t match your own experience, tell us.