Most of us have said some version of "they got the PO, we have the 997" and then watched that order turn into a short ship, a rejected invoice or a chargeback a week later. Every acknowledgment in an EDI exchange answers a narrower question than the green checkmark in your dashboard suggests. An AS2 receipt, a 997 and an 855 each confirm something different, and when a team reads them as one status, problems sit unnoticed until the retailer finds them first.

Below: what each acknowledgment confirms, how to match it to the right order, and what to test before a new trading partner goes live.

Does an EDI 997 mean the order was accepted?

No. An EDI 997 Functional Acknowledgment tells the sender that the receiving translator checked the file's syntax and either accepted it or flagged errors. The X12 standard defines the 997 around that syntax check and leaves the business meaning of the data out of scope. The supplier's answer to the purchase order, whether they will ship those items at that price on that date, comes back in the EDI 855 Purchase Order Acknowledgment. Problems with the business content, such as an unknown item or an invalid store number, usually come back in an 824 Application Advice.

MDN vs 997 vs 999 vs 855: what each one confirms

Think of an order as passing through layers: the network moves the file, a translator checks its structure, and an order system decides what to do with it. Each layer sends its own acknowledgment, and each one only speaks for its own layer.

Two of these get confused more than the rest: the 997 and the 855. Retail suppliers send both in response to an 850 purchase order, often within hours of each other, so it is easy to assume they say the same thing. The 997 says the file parsed. The 855 says what you will do about the order.

What an AS2 MDN tells you

If you exchange files over AS2, the first response you get is a Message Disposition Notification (MDN). RFC 4130, the AS2 specification, allows two kinds: a synchronous MDN returned in the same HTTP session, and an asynchronous MDN sent back later in a separate connection. Your partner agreement decides which one you should expect.

A signed MDN is the strongest receipt you can get at this layer. When you verify the signature and the Message Integrity Check (MIC) it returns, you know the partner's server received exactly the bytes you sent. That is useful evidence in a dispute about whether a file was delivered.

The MDN stops there. The AS2 server that sends it has not run the file through a translator, so a perfect MDN can sit next to a 997 that rejects the same file. A few habits keep this layer honest:

• Keep the HTTP 200 response, the arrival of an MDN and a verified signed MDN as three separate events in your logs.

• Store the AS2 Message-ID with every outbound file so you can match the MDN to it later.

• Alert on missing asynchronous MDNs; a sync MDN fails loudly, an async one can simply never arrive.

If you connect through a VAN instead of AS2, the network's mailbox receipts play a similar role, and they have the same limit: delivered is all they tell you.

What a 997 tells you

The 997 is generated where the receiver's translator unpacks your file, and it goes back to the original sender. X12 allows one 997 per functional group (one GS/GE envelope), and a functional group can hold many transaction sets. So one 997 might be answering for 40 purchase orders at once.

Reading AK5 and AK9 codes

Inside the 997, each segment answers for a different scope:

An AK9 of P is the one to watch. It means some documents in the group passed and some did not, and the AK2/AK5 pairs tell you which. A 997 can report three transaction sets received and zero accepted, and a team skimming only for "997 received" will miss that entirely.

When a 997 comes back rejected, fix the map or the data and resend with fresh control numbers. X12 does not allow a 997 to acknowledge another 997, so if your outbound 997s are malformed, nobody will tell you through EDI; you will hear about it from the partner's support team.

A clean 997 on an outbound 810 invoice or 856 also does not protect you from a later 824 or 864 rejection when the retailer's application checks the content.

What a 999 adds

The 999 Implementation Acknowledgment checks syntax and also the rules of a specific implementation guide, so it can catch errors a 997 would pass. It still makes no claim about business acceptance. You will see 999s mostly in healthcare, where HIPAA transactions require them; retail and CPG partners overwhelmingly expect the 997. Some partners ask for one or the other, rarely both for the same group, so confirm which during onboarding.

What an 855 tells you about the purchase order

The 855 is the supplier's business answer to an 850. Your order system has looked at the items, quantities, prices and dates and decided what it can commit to. The answer can be a clean yes, a yes with changes, or a no, and it can come at the header level or line by line. An 855 arriving in the retailer's system tells them you responded; what you said is in the codes.

Header and line codes worth knowing

The BAK02 element sets the tone for the whole order. Common values include AD (acknowledged with detail, no change), AC (acknowledged with detail and changes), AK (acknowledged with no detail or change), RD (rejected with detail) and RJ (rejected, no detail). At the line level, the ACK01 status code carries the detail, for example IA (item accepted), IB (backordered), IQ (quantity changed), IP (price changed), DR (date rescheduled) and IR (item rejected).

Retailers rarely accept the full code list. Their implementation guides name the subset they support, and sending a valid X12 code your partner does not process can get an otherwise clean 855 bounced or ignored. Pull the allowed codes from each partner's guide during onboarding, and check our EDI glossary if a term in the guide is unfamiliar.

When an 855 changes the order

An 855 with IB or IQ lines tells the buyer what you intend to ship. It does not automatically update their purchase order. Some retailers apply 855 changes directly; others expect to send an 860 PO change before the new terms count. We cover that handoff in detail in EDI 855 vs 860. Whatever the partner's process, your 856 and 810 should match what was acknowledged and accepted, or the mismatch tends to come back as a deduction.

Timing

Many retailers require the 855 within a set window after the PO, commonly 24 hours and sometimes less, and a late or missing 855 is a common source of compliance fines. The automatic 997 your translator sends within minutes does not count toward that requirement. If you want a sense of what those fines add up to, our gross chargeback calculator is a quick way to size it, and our guide to purchase order acknowledgments covers the business case for getting 855s right.

One more loop to close: when the retailer receives your 855, their translator sends you a 997 for it. That 997 confirms your 855 parsed. It says nothing about whether the buyer agreed to your changes.

Matching each acknowledgment to the right order

You can receive every acknowledgment on time and still make the wrong call if you attach it to the wrong document. Each one points back to its own identifier, and those identifiers sit at different levels:

The mistakes we see most often come from forcing these into a one-to-one join. A 997 for a group of 12 POs gets attached to the first PO only. Control numbers get reused across partners, so a 997 lands on the wrong file. An 855 is matched by PO number alone, and a revised PO with the same number picks up the old acknowledgment. Unique, sequential control numbers per partner solve a lot of this, and our post on ISA IDs and transaction setup covers the envelope side.

Acknowledgment checklist for trading partner onboarding

Most acknowledgment problems are cheaper to find in testing than in production. Before a new partner goes live, work through this list with their implementation guide open:

1. Get the acknowledgment rules in writing: which of TA1, 997 or 999, 855 and 824 the partner requires, in which direction, and how fast.

2. Confirm the transport details, including sync or async MDN, signed receipts and certificate expiry dates, or the VAN mailbox setup.

3. Test 997s both ways, and send at least one deliberately broken file so you see what a rejection looks like from this partner.

4. List the BAK02 and ACK01 codes the partner accepts and make sure your map can only produce those.

5. Send a functional group with several POs in it and confirm each acknowledgment lands on the right order in your ERP.

6. Run change scenarios (a backorder, a short quantity, a price change, a new ship date) and check that the 856 and 810 that follow use the acknowledged values.

7. Set an alert for every acknowledgment that has a deadline, and name the person who owns each kind of exception.

8. Before go-live, reconcile a sample of orders: your ERP's order state against what the partner's portal shows.

Our guide to testing EDI integrations goes deeper on building the test cases themselves.

Failure scenarios worth testing

How Surpass handles acknowledgments

As a managed EDI provider, we set up each partner's acknowledgment rules during onboarding: which acknowledgments they require, the 855 codes they accept, and the windows they hold you to. After go-live, our team watches for missing and rejected acknowledgments so an AK9 of P or a late 855 gets fixed before it becomes a chargeback.

Because we connect EDI to your ERP, WMS or inventory system, the 855 you send reflects what your system can actually commit to, and the 856 and 810 that follow use the same numbers. If you run NetSuite or Cin7, those integrations are already built.

If you are onboarding a new retailer or cleaning up acknowledgment issues with an existing one, start a conversation with our team.

Frequently asked questions

What is the difference between an EDI 997 and an EDI 855?

A 997 confirms that the receiver's translator parsed an EDI file and reports any syntax errors. It works for any transaction set. An 855 is the supplier's business response to a specific purchase order, saying whether the order is accepted, changed or rejected.

Does the buyer send a 997 for an 855?

Usually, yes. When a retailer receives your 855, their translator returns a 997 for it if your agreement calls for functional acknowledgments. That 997 confirms the 855 parsed; it does not mean the buyer accepted any changes in it.

Is an EDI 855 required?

It depends on the trading partner. Many large retailers require an 855 for every 850, while others skip it. Check the partner's implementation guide or our trading partner directory.

What is the difference between an AS2 MDN and a 997?

The MDN comes from the receiving AS2 server and confirms the file arrived, and with a signature, that it arrived unaltered. The 997 comes from the translator after it checks the file's syntax. You can get a clean MDN and a rejected 997 for the same file.

What is the difference between a 997 and a 999?

Both are X12 syntax acknowledgments. The 999 adds checks against a specific implementation guide and is standard for HIPAA healthcare transactions. Retail and CPG partners mostly use the 997.

What do the codes A, E, P and R mean in a 997?

A means accepted. E means accepted with errors noted: the document will usually be processed, but read the AK3 and AK4 detail and fix the map before the partner tightens validation. R means rejected. P (partially accepted) appears only at the group level in AK9 and means some transaction sets in the group were rejected.

What happens if I don't receive a 997?

You can't confirm the partner's translator processed your file. Check the MDN or VAN receipt first. If delivery is confirmed and the partner's window has passed, contact them with the message and control numbers before resending, so you don't create a duplicate.

How long do you have to send an 855?

The trading partner sets the window in their implementation guide or vendor agreement. 24 hours after the 850 is common, some retailers ask for less, and late 855s often count against vendor scorecards or trigger compliance fees.

Is an EDI 997 mandatory?

Not by the X12 standard itself, but most retail trading partner agreements require one for every functional group you receive, and many expect it within minutes because translators generate it automatically. A missing 997 is a common reason a retailer thinks you never received their PO.

What is the difference between a 997 and an 824?

The 997 comes from the receiver's translator and reports syntax results. The 824 Application Advice comes from the receiver's business system and reports content problems, such as an invalid item, price or store number. A file can pass the 997 and still be rejected on an 824.

What is a TA1 acknowledgment?

A TA1 acknowledges the ISA/IEA interchange envelope. Partners request it by setting ISA14 to 1, and it is most useful when an envelope is so malformed that the translator cannot read far enough to produce a 997.

Can one 855 acknowledge more than one purchase order?

No. Each 855 carries one PO number in BAK03, which must match BEG03 on the original 850. You can send several 855s in the same functional group, one per PO.

What is the EDIFACT equivalent of the 997 and 855?

In EDIFACT, CONTRL plays the role of the 997, and ORDRSP is the purchase order response that matches the 855.