EDI 997/824 Acknowledgments Explained: Tracing a Lost Transmission When Your Partner Says "Never Received It"

Bottom line up front: when your partner says "never received it," do not resend yet. EDI 997 824 acknowledgment troubleshooting comes down to one rule: locate exactly which hop the transmission died on, then decide whether to resend or resubmit. Resend it wrong and one shipment becomes two documents in your partner's system. I have seen that pitfall three times.

Across thirty-plus go-lives, the EDI problem that eats the most time is never a malformed segment. It is the call where your log says "sent" and your partner says "never arrived." This article gives you a fixed chain. Follow it in order and stop guessing.

The Full Transmission Chain: Count the Doors a Document Passes Through

One EDI document travels through six doors before it lands in your partner's business system. A failure at any one of them produces the same complaint: "never received it."

1. Your WMS or ERP: the business document is created and handed to the translator
2. Your EDI translator: business data becomes an EDI document, format checked
3. Transport: VAN or direct AS2 delivers the document to your partner
4. Partner gateway: receives the document, confirms arrival at the door
5. Partner translator: parses the document, checks format and content
6. Partner business system: writes the document into receiving, orders, or payables

Here is the point most teams miss: the 997 only covers doors 4 and the first half of 5. It confirms "the document arrived and is readable." Whether your partner's business system accepts the document is the 824's job. That split is why EDI 997 824 acknowledgment troubleshooting starts with telling the two apart, not with resending.

EDI 997 vs 824: What Each One Actually Answers

Now the counterintuitive judgment: a clean 997 does not mean your business document was accepted. The 997 is an envelope-level confirmation, not a business-level one. Your partner's translator saying "format looks fine" says nothing about whether their receiving system recognizes your ASN. What decides whether the document entered their system is the 824, or the actual processing result in their business system.

"Never Received It": The Five-Step EDI 997/824 Troubleshooting Chain

Work this chain in order. Do not skip steps. Each step must produce evidence before you move on. "It should have been sent" is not evidence.

Step 1: Check your own send log. Confirm the document actually went out: send time, interchange control number, sender and receiver IDs, send status. Many "partner never received it" cases start with the document never leaving your side: a scheduled job that did not run, a stuck queue, a translator error nobody saw. Screenshot your log and keep it.

Step 2: Check the VAN or transport receipt. If you use a VAN, check its delivery confirmation. If you connect directly, check the transport log and the partner gateway's receipt confirmation. This hop answers one question: did the document leave your side and reach your partner's door?

Step 3: Check the partner gateway. Ask your partner's IT team to confirm whether their gateway received this specific document. Give them precise tracking info: send time, interchange control number, document type, sender and receiver IDs. "We sent an ASN yesterday" is not searchable. Vague tracking info is the most common communication failure in this whole process.

Step 4: Check the partner translator. Gateway receipt does not mean translation passed. Ask the partner to confirm whether their translator parsed the document, whether it threw format errors, or whether it got parked over a mismatched segment or code value. One fall, a 3PL warehouse in California lived this exact failure: an 856 advance ship notice went out, the 997 came back accepted, and the truck still got turned away at the partner's dock door because the receiver could not find the ASN. The translator had passed it, but the ASN never entered their receiving system because an item code did not match. The application layer had already returned an 824 rejection. Nobody was watching the 824.

Step 5: Check the partner business system. If the first four steps pass, confirm the document exists in the partner's business system: can the ASN be found in the receiving plan, can the order be found in their system, did the invoice enter payables? If not, have them search by business fields — document number, ship date, item code — not just the interchange control number.

Resend vs Resubmit: Do Not Turn One Shipment Into Two

Only after you have located the failure do you decide how to fix it. Resend and resubmit are not the same thing, and mixing them up creates duplicate documents.

• Resend: the same document, byte for byte, sent again with the same control number. Use it when the document genuinely never reached the partner — transport failure, gateway never received it. Before resending, confirm the partner truly does not have it, or they will receive two copies of the same document.
• Resubmit: a fresh business submission per the partner's request, with a new control number. Use it when the original arrived but was rejected or parked, or when the partner asks for a new document to replace the old one. Before resubmitting, confirm the old document's status on the partner side: rejected, parked, or already in the system.
• Never do this: change the control number and send again without confirming the partner's status. If the partner's system does not deduplicate on control numbers, one shipment becomes two: two ASNs, two receiving plans, and in the worst case duplicate receipts and duplicate payments. Get written confirmation that the old document is voided before you send the new one.

Common Failure Points

• Treating "accepted with errors" as a pass. The 997 carries three outcomes: accepted, accepted with errors, rejected. Accepted with errors means the format mostly passed but errors were flagged. Plenty of teams only check whether a 997 came back and treat accepted-with-errors as a green light. I have seen this pitfall three times, and every time it blew up after go-live.
• Nobody watches the 824. Many projects connect the 824 but never attach an alert or review routine. The 824 comes back as an application-level rejection while the business side still believes the document entered the partner's system. The 824 belongs in monitoring, in a task queue, with a named owner.
• Testing only the happy path. Before go-live, teams test "document goes out, 997 comes back" and never test "partner rejects it, what then" or "resend creates a duplicate, what then." The go-live night checklist must include dry runs of all three.

Go-Live Night Checklist

The night before go-live, check every item below. Do not go live with a single gap.

1. 997 acknowledgments are connected, and both accepted and rejected outcomes have been tested live for every document type
2. 824 is connected, application-level rejections trigger alerts, and an owner is named
3. The handling flow for 997 accepted-with-errors is written down: who reviews it, how fast, and what happens next
4. Control number rules are confirmed: resends reuse the original number, resubmits get a new one, and the rule is in the operations document
5. Deduplication rules are confirmed: what fields the partner deduplicates on, and whether a duplicate document can create a duplicate business record
6. The five-step troubleshooting chain is printed where the on-call team can see it, and on-call staff can state what each step checks
7. The partner contact list is ready: partner IT contact and partner business contact, with each side's tracking info requirements
8. Dry runs are done: simulate a "never received it" call, walk steps 1 through 5 end to end, and confirm every step produces evidence

EDI troubleshooting is rarely hard. What kills you is having no chain. With a chain, every problem lands on a specific hop. Without one, you argue on the phone forever. Next time a partner says "never received it," send them this five-step EDI 997 824 acknowledgment troubleshooting chain first, then match evidence hop by hop.

By Lin Xiao, WMS Implementation Consultant