EDI 997 Functional Acknowledgment

What is an EDI 997?

The EDI 997 is the X12 Functional Acknowledgment transaction set. The receiver of a functional group sends it back to the sender to report that the group arrived and whether each transaction set in it passed the syntax check: accepted, accepted with errors, or rejected. Every other document in a trading relationship, from the 850 to the 810, is answered by one.

The X12 definition sets the limit of what it confirms. The 997 reports "the results of the syntactical analysis" of the documents, and the standard "does not cover the semantic meaning of the information encoded in the transaction sets". A 997 with an A in it means the file could be read. It does not mean the purchase order will ship, the ship notice matches the truck or the invoice will be paid. Among the EDI documents a supplier handles it is the only one that goes in both directions for every exchange.

Where the 997 sits in the order-to-cash flow

Each functional group gets its own 997, sent by the party that received the group. AK101 repeats the functional identifier of the group that is being acknowledged.

The 997 is one of four acknowledgments that can follow a file, each at its own level.

The 824 is the one that reports content. X12 defines it as the report of "an application system's data content edits", and Kroger returns it next to the 997 for ship notices.

The segments of a 997

A 997 has one AK1, one AK9, and between them an AK2 loop per transaction set. In X12 004010 the AK2 loop and the AK3 loop inside it can each repeat 999,999 times, and AK4 can occur 99 times per AK3. The functional identifier of a group of 997s is FA.

The status and error codes

X12 004010 lists 6 values for AK501 and 7 for AK901; the three and four above are the ones partner guides use. The rest (M, W, X) report security failures. The standard notes that a group with A or E in AK901 counts as accepted. AK304 has 8 codes, AK403 has 10 and AK502 has 25.

Two samples, with delimiters

The first is the supplier's answer to one purchase order: group 1203, which held one 850 with control number 0001. Elements are separated by *, segments end with ~.

ST*997*0001~
AK1*PO*1203~
AK2*850*0001~
AK5*A~
AK9*A*1*1*1~
SE*6*0001~

One set included, one received, one accepted. From ST to SE there are 6 segments, so SE01 is 6.

The second is a buyer's answer to group 461, in which the supplier sent three invoices. Invoice 0002 is rejected.

ST*997*0001~
AK1*IN*461~
AK2*810*0001~
AK5*A~
AK2*810*0002~
AK3*IT1*10**8~
AK4*3*355*5*EACH~
AK5*R*5~
AK2*810*0003~
AK5*A~
AK9*P*3*3*2~
SE*12*0001~

Read it from the bottom. AK9 says 3 sets were included, 3 received and 2 accepted, so 3 minus 2 is 1 set to resend. AK5 with R and error 5 marks set 0002. AK3 points to the tenth segment of that invoice, an IT1, with error 8. AK4 names the third element of that segment, data element 355, the unit of measure, with error 5: the value EACH is too long for a field of exactly 2 characters. The ERP wrote its own unit name where the code EA belongs. There are 12 segments from ST to SE.

Invoices 0001 and 0003 are with the buyer. Only 0002 is corrected and sent again, in a new group with a new control number. Sending all three again would create two duplicate invoices at the buyer.

The envelope around it

ISA*00*          *00*          *ZZ*NORTHFIELD     *01*123456789      *260928*1412*U*00401*000000454*0*P*>~
GS*FA*NORTHFIELD*123456789*20260928*1412*454*X*004010~
ST*997*0001~
SE*6*0001~
GE*1*454~
IEA*1*000000454~

The 997 travels in its own interchange with its own control numbers: 000000454 in ISA13 and IEA02, 454 in GS06 and GE02. Those belong to the sender of the 997. The link to the acknowledged file is inside, in AK102 (1203) and AK202 (0001). Sender and receiver are the reverse of the file being answered: the standard has the application sender's and receiver's codes of the acknowledged group exchanged in GS02 and GS03. One 997 answers one functional group, so an interchange with a group of orders and a group of order changes gets two. ISA15 is P for production and T for test, and a 997 for a test file carries T as well.

Who requires the 997, and how they differ

Both specifications below are public and were checked on 3 October 2026.

Walmart sends and expects the 997 in both directions and names the file WMI_997FA_... over SFTP. Its guide has no AK3 or AK4, so a rejection from Walmart says which set failed and not where. Kroger reports the segment and the element, and accepts a group in part: its own sample shows nine promotion sets with eight accepted and AK9*P*9*9*8. A program that expects Kroger's P from Walmart, or looks for AK3 in a Walmart rejection, handles neither correctly. The guides: Walmart's 997 page and Kroger's 997 map. Partner specifics are under EDI with Walmart and EDI with Kroger.

What goes wrong and what it costs

• A missing 997 that nobody notices. A ship notice is sent and no 997 comes back. The file never reached the buyer, and the truck arrives without a notice on record. Kroger sets 12 hours as the point at which the vendor has to call. A missing acknowledgment has to raise an alert before that point.
• A 997 read as a business answer. The 850 is acknowledged within minutes and the buyer still waits for the 855. In the other direction, an accepted 997 for an invoice is taken as approval, and the short payment arrives with the remittance.
• P treated as A. Two of three invoices are booked at the buyer. The third stays unpaid until someone compares AK904 with AK902.
• Resending the whole group. After AK9*P*3*3*2 all three invoices go out again. The buyer now has two invoices twice.
• Your own 997 not sent. The partner's order is in your ERP, and the partner's system shows the file as unacknowledged. Kroger states that a 997 is required for EDI data interchange, and partner requirements of this kind are collected under EDI compliance.
• An acknowledgment for an acknowledgment. A translator that answers every inbound group answers the 997 too. The standard forbids it.

The 997 itself carries no penalty. The cost sits in the document it should have confirmed: a ship notice that never arrived or an invoice that was never booked.

Handling the 997 on the ERP side

The 997 creates no record in the ERP. It updates the status of a document that was sent, and that status has to be kept somewhere: per outbound document the group control number, the set control number, the time sent, and the time and code of the acknowledgment.

ERPs have no field for this. NetSuite, Business Central and the store platforms hold the invoice or the fulfillment, not the control number it traveled under. We keep that register in the EDI integration we build and run for you. Every inbound group is answered with a 997 inside the partner's window, every outbound document is matched to the 997 that answers it, and a rejection or a missing acknowledgment is shown in the dashboard with the segment and element from AK3 and AK4. The rules that decide whether a document passes are part of EDI mapping. Tell us which partners you trade with.