The EDI 997, Decoded: What a Functional Acknowledgment Actually Proves (and What It Doesn't)

A 997 · Functional Acknowledgment proves one narrow thing: your trading partner's translator received your file and could parse its structure. It does not prove the order was accepted, the invoice will be paid, or anyone's business system acted on the data. Treating a clean 997 as "done" is one of the most common — and most expensive — misunderstandings in EDI.

I run SignalEDI, and the 997 is the document I explain most often to teams new to EDI, because it sits exactly on the boundary between "the file moved" and "the business agreed." Everything below is about keeping those two ideas separate.

What is a 997 · Functional Acknowledgment?

It is X12's receipt for structure. When a partner receives a transaction set — say an 850 · Purchase Order — their translator checks the envelope and the segments against the standard and replies with a 997 that says, per transaction set: accepted, accepted with errors noted, or rejected.

The key segments are easy to remember. The AK1 identifies the functional group being acknowledged. The AK2 loops per transaction set inside that group. The AK3 and AK4 segments point at the specific segment and element that failed when something did. The AK5 states the verdict for that transaction set, and the AK9 rolls the whole group up.

That error pinpointing is the underrated part. A good 997 does not just say "bad file." It says which segment, which position, and which element offended — which is why a rejected 997 is diagnostic gold compared to a partner's vague "your file didn't go through."

What does a 997 not prove?

It does not prove business acceptance. An 850 · Purchase Order can earn a perfectly clean 997 and still be refused commercially — wrong pricing, a discontinued item, a ship window the seller cannot meet. That answer lives in a different document, the 855 · Purchase Order Acknowledgment, which is a business reply written by a person or a business system, not a translator.

It also does not prove the data was good. A translator validates structure: segment order, element types, lengths, code values it knows about. It does not know that the quantity should have been 12 instead of 120, or that the ship-to location closed last spring. Structural validity and business correctness are different tests, and only the first one is in the 997's job description.

And it does not prove end-to-end delivery of anything downstream. The 997 acknowledges what that partner's translator received. What their ERP did with it afterward is a separate question.

Why do teams get burned by the 997 anyway?

Because it usually arrives fast and looks reassuring. The failure pattern goes like this: the file goes out, the 997 comes back accepted, the integration dashboard goes green — and three weeks later accounting asks why the 810 · Invoice was never paid, or the warehouse asks where the order went. The business document failed somewhere after the translator said yes, and nobody was watching that layer because the acknowledgment had already closed the mental ticket.

The fix is to track two different states and never merge them. Transport/translator state: sent, received, parsed — that is the 997's territory, plus AS2 MDNs at the protocol layer below it. Business state: accepted, shipped, invoiced, paid — that is tracked with the business documents themselves, the 855, the 856 · Ship Notice / ASN, the 810 · Invoice, and reconciliation against your own system of record. A dashboard that shows one green check for both is lying to you politely.

What should you do when a 997 never arrives?

Silence is information too, but only if you are listening for it. Set an expectation window per partner — many teams use a few hours for a high-volume partner, a business day at the outside — and alert on the absence, not just on rejections. A missing 997 usually means one of four things: the file never left your side, the connection failed silently, the partner's translator is down or backlogged, or the partner never agreed to send 997s in the first place. That last one is more common than it should be: check the trading partner agreement before you debug your network.

For healthcare flows the same discipline applies, with different acknowledgment flavors — the 999 · Implementation Acknowledgment is the HIPAA-era successor for sets like the 837 · Claim, and the 277CA adds a claims-level layer on top. The principle is identical: know which layer each acknowledgment speaks for.

What should you do with a rejected 997?

Read the AK3/AK4 detail before you touch the map. Half of all rejections I see trace to envelope and control-number problems — mismatched counts, reused interchange control numbers — rather than the business data everyone argues about first. Fix the class of error, not just the instance: if one file failed on an element length, every file from the same source system probably will.

Frequently asked questions

Is a 997 the same as an AS2 MDN?
No. An MDN proves the AS2 message arrived and its signature and integrity checked out. A 997 proves the X12 inside it parsed against the standard. You can have an MDN and a rejected 997, and that combination tells you the pipe works and the file does not.

How fast should a 997 come back?
It depends on the partner's processing cycle — near-real-time for some, batched for others. Agree on a window during onboarding and monitor against that agreement, not against hope.

Do all partners send 997s?
No. Some send them only on error, some not at all. Get it in writing in the partner setup, and set your monitoring to match what was actually promised.

The 997 is not paperwork. It is the cheapest monitoring signal in all of EDI — a structured, machine-readable "we got it, and here is exactly how it looked to us." Use it for the one job it does well, track business acceptance separately, and you will catch in hours the failures that otherwise surface as a phone call three weeks later. That discipline — separating delivery truth from business truth — is a lot of what we built SignalEDI around.

— Chris, founder of SignalEDI