EDI concepts
EDI compliance: what retailers check on every document
EDI compliance means every document you exchange with a trading partner passes three checks: X12 syntax, that partner's implementation guide, and its business rules on timing and accuracy. A failure at the first two comes back as a rejection. A failure at the third comes back as a deduction from your invoice payment.
Updated
What EDI compliance means
A document is compliant when it clears three checks in a row: it is valid X12, it follows the trading partner's implementation guide, and its content agrees with what physically happened, on time. The first two are checked by software when the file arrives. The third is checked later, at the receiving dock and in accounts payable.
Being EDI capable is passing the partner's test once. Compliance is measured on every live document after that. The retail terms for a miss are chargeback and deduction; department store manuals also use expense offset. All three mean the same thing: the retailer pays the invoice minus an amount for the failed requirement.
The three levels of validation
| Level | What is checked | Example failure | How it comes back |
|---|---|---|---|
| 1. Syntax | Segment order, mandatory elements, segment counts, control numbers | SE01 says 19, the file holds 21 segments | A 997 with AK5 code R |
| 2. Partner guide | The codes, qualifiers and segments this partner requires | LIN sent with qualifier UP where the guide requires UK | An 824 application advice, or a message from the partner's EDI team |
| 3. Business rules | Timing and content against the order and the shipment | The 856 reports 24 units, the carton holds 20 | A violation on the receipt, then a deduction |
Level 1 is defined by the standard and is the same for every partner. A rejected transaction set looks like this in the 997:
ST*997*0001~
AK1*SH*457~
AK2*856*0001~
AK5*R*4~
AK9*R*1*1*0~
SE*6*0001~
AK5 carries R for rejected, and error code 4 is "Number of Included Segments Does Not Match Actual Count". AK9 reports the group: 1 transaction set included, 1 received, 0 accepted. The 856 never reached the partner's order system, so for that system the shipment has no notice at all.
Level 2 differs per partner, because each guide is a subset of the standard. Kroger specifies version 5010 and UA or UK item qualifiers; another retailer's guide specifies 4030 and UP. The X12 document for reporting these content errors is the 824 application advice, whose purpose is "to report the results of an application system's data content edits". This is the level EDI mapping exists for.
Level 3 has no file format at all. It is the comparison between the document and reality.
Why an accepted 997 is not an approval
The 997 has three outcomes per transaction set that matter in practice, in AK501: A (accepted), E (accepted, but errors were noted) and R (rejected). At group level AK901 adds P, "Partially Accepted, At Least One Transaction Set Was Rejected".
Take a functional group of 10 ship notices where one has a wrong segment count. The 997 returns AK9*P*10*10*9: 10 included, 10 received, 9 accepted. Nine of ten is 90%, and the sender's system has to find which one of the ten carries the R, correct it and send it again before that truck arrives. A sender that only checks whether a 997 came back treats this group as delivered.
The opposite case: all ten are accepted with A, and three of them report quantities that differ from the cartons. The 997 is correct, because the syntax was valid. Kroger's vendor requirements add a rule for the answer that never comes: the vendor calls the EDI coordinator when an expected 997 or 824 has not arrived within 12 hours of sending the ASNs.
What retailers measure on live documents
Kroger publishes its ASN requirements and its violation descriptions on a public portal, which makes it the clearest example of level 3.
| Requirement | As published by Kroger | Field in the 856 |
|---|---|---|
| Timing | "The ASN is consistently sent at least 90 minutes before the truck arrives" | Transmission time against arrival |
| Accuracy | "100% accurate with respect to license plates, U.P.C./EAN Case Codes, quantities, Expiration/Production Dates" | MAN (SSCC), LIN, SN1, DTM |
| Acknowledgment | A functional acknowledgment is required for EDI data interchange | The 997 for every group received |
Its violation list holds 18 descriptions. They fall into groups: four on the pallet configuration ("TI = 0", "HI = 0", "ASN TI > WIN TI", "ASN HI > WIN HI"), four on duplicates and receipts already started ("Dup. ASN Load", "RCN Exists"), three on quantity ("Qty = 0", "ASN Qty>WIN Qty"), two on the order ("Invalid PO", "PO Is Not Open"), and the rest on the item, the load and its dates ("Invalid UPC", "Load Is Expired"). Every one of the 18 is a data condition. None is a connection failure.
Retailers then score suppliers on a rate over a period. An example with our own numbers: a supplier sends 160 ship notices in four weeks. Six arrive after the truck and three carry a wrong quantity: 9 failures, 151 clean, 151 divided by 160 is 94.4%. If the partner's target were 98%, the allowance would be 3 failures in 160. The rate, the period and the target are set per retailer in its vendor manual.
How penalties are priced and where they start
Penalty schedules use three units: an amount per carton or label, an amount per shipment or purchase order, and a percentage of the cost of the goods on the affected order. Most amounts sit in supplier portals behind a login. One public example is Kroger's EDI non-compliance fee, stated on its own portal: 1% of the total invoice or $250, whichever is greater, deducted from payment once the 90 days to start receiving purchase orders and sending invoices by EDI have passed (see Kroger EDI). The unit matters more than the amount for finding the cause: a per-carton charge points at labels and the MAN segment, a per-order percentage at timing and fill.
Each priced failure traces to one document and one source record.
| Failure | Document and field | Where it starts |
|---|---|---|
| Ship notice late | 856, sent after arrival | The 856 is created at end of day instead of at ship confirmation |
| Units differ from the carton | 856, SN102 | The 856 is built from the order, not from the pack record |
| Label not on the notice | 856, MAN with the SSCC | Labels are printed in one system, the 856 in another |
| Order not confirmed in time | 855 | The 850 waits in a mailbox or a portal until someone opens it |
| Invoice does not match the receipt | 810, IT1 and TDS | The invoice bills ordered quantities, the 856 reported shipped quantities |
| Duplicate document | ISA13, BSN02 or BIG02 repeated | A resend after a timeout without a check on what was already sent |
Five of the six start on the supplier's side of the translator: in the order system, the warehouse or the timing of a job. A valid map does not correct a ship notice built from the wrong record.
What this means for your integration
An EDI integration built for compliance runs the three levels before the partner does. Syntax and the partner's guide are validated on every outbound document. The business rules that can be checked in advance are checked against your own records: the 856 quantity against the pack record, the SSCC against the printed label, the 810 against the 856, the control number against what was already sent.
A document that fails is held and shown in the dashboard with the reason, and every 997 and 824 is matched to the document it answers, so a rejection is seen when it arrives and not when the deduction does. We build that to your systems and your partners' guides, host it and monitor it. Tell us which partner is deducting and for what.
Frequently asked questions
What is the difference between EDI compliance and vendor compliance?
Vendor compliance is the whole rule set a retailer puts on a supplier: routing, packaging, labels, delivery windows and documents. EDI compliance is the part that concerns the documents: that the 855, 856 and 810 arrive on time, follow the retailer's guide and agree with what was shipped. The two overlap at the carton label, because the SSCC on the label has to equal the SSCC in the 856.
What is an EDI chargeback?
A chargeback is an amount the retailer takes off the payment of your invoice because a requirement was missed, for example a ship notice that arrived after the truck. Retailers also call it a deduction or an expense offset. In X12 the adjustment itself can travel as an 812 credit/debit adjustment, which Kroger lists in its document set.
Does an accepted 997 mean my document was compliant?
No. The acknowledgment code in a 997 is defined as an accept or reject condition "based on the syntax editing of the transaction set". It says the file could be parsed. Whether the codes fit the partner's guide and whether the quantities match the shipment is checked later, by other systems. See EDI 997.
Where do I find the penalty amounts for my retailer?
In the retailer's own supplier portal or vendor manual, which for most large retailers sits behind a login. Kroger's public EDI portal lists 18 ASN violation descriptions without amounts, and states one fee: a vendor shipping to a Kroger distribution center that does not receive the purchase order and return the invoice by EDI pays 1% of the invoice or $250, whichever is greater, after a 90-day grace period. Figures quoted on third-party sites are worth checking against the portal before they go into a margin calculation.
Who pays when a mapping error causes a chargeback?
The retailer deducts from the supplier, because the supplier is its trading partner and the invoice is the supplier's. Whether a provider compensates for an error in a map it built is a matter of the contract between supplier and provider. It is one of the points to settle before signing, see EDI provider.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase