EDI 997 Functional Acknowledgment: Reconciling Missing 997s Daily

The ship notice left the warehouse system at 16:42, the translator logged it as sent, and the integration dashboard stayed green. Next morning the trailer reached the customer's distribution centre with no advance ship notice on file, receiving scanned every carton by hand, and three weeks later a compliance deduction appeared on the remittance. The 997 that said "rejected" had arrived sixteen minutes after sending. Nobody read it.

A functional acknowledgment is only useful if someone compares it, every day, with what was sent. Reconcile each outbound transaction set against its 997 by partner, group control number and set control number, alert on rejections within the hour and on missing acknowledgments by an agreed deadline, and silent EDI failures become same-day fixes instead of month-end deductions.

• What this guide covers: what a 997 does and does not prove, how AK1 to AK9 map to your control numbers, the AK error codes, the TA1 and 999 alternatives, overdue windows and a daily reconciliation query.
• What it adds: a timestamped trace of a rejected ship notice, a worked cost of silent rejections in US ($) and India (₹), and a checklist for running the reconciliation every day.

What a 997 confirms about a functional group, and what it never does

A 997 confirms that the receiver's translator could parse your functional group and its transaction sets; it says nothing about whether the business accepted the content. The 997's own transaction set comments, in the 4010 text reproduced by the Health Industry Business Communications Council, say it reports syntactical analysis and does not report semantic meaning, such as the receiver's ability to comply with a request.

• One per group: there is only one 997 per acknowledged functional group, and its AK1 names that group. A 997 never acknowledges a single interchange or a single document on its own.
• No acknowledgment of acknowledgments: the same text says 997s shall not be acknowledged, and no 997 should report errors in a previous 997. Outbound 997s therefore never appear in your overdue list.
• Swapped sender codes: the 997's GS envelope exchanges the application sender and receiver codes of the group it answers, which is why routing rules that expect your own code in GS02 drop 997s into an error folder.
• Business rejection comes later: a purchase order can be syntactically perfect and still be refused. That answer travels in an 855 acknowledgment or an 824 application advice, not in the 997.

Reading AK1 to AK9 against your GS and ST control numbers

Every 997 can be matched to what you sent using three keys: the partner, the group control number and the transaction set control number. AK1 carries the functional identifier code and group control number of the group being answered, from your GS01 and GS06. Each AK2 carries a transaction set identifier and control number from your ST01 and ST02, in the order the sets were received.

AK5 closes each AK2 loop with AK501, the Transaction Set Acknowledgment Code. In the 5010 code list its values are A Accepted, E Accepted But Errors Were Noted, M Rejected because the message authentication code failed, R Rejected, W Rejected because assurance failed validity tests, and X Rejected because content after decryption could not be analysed. P is not an AK501 value.

• AK901 group code: uses the same letters plus P, Partially Accepted, At Least One Transaction Set Was Rejected.
• AK902 to AK904 counts: the number of sets in your GE01, the number the receiver got, and the number it accepted. AK903 lower than AK902 means sets went missing inside the group.
• AK905 to AK909 group errors: for example 4, group control number in header and trailer do not agree, and 5, number of included transaction sets does not match the actual count.

Partners differ on whether AK2 loops appear for accepted sets. Some translators, including Azure Logic Apps by default, generate AK2 loops only for rejected sets unless the agreement asks for all of them. Record that choice per partner, because it changes how a set with no AK2 should be read when the group status is P.

AK3, AK4 and AK5 codes that point to the faulty segment

When a set is rejected, the AK3 and AK4 segments tell you which segment and which element failed, so the fix rarely needs a phone call. AK3 gives the segment ID, its position counted from ST as 1, any bounded loop identifier and AK304, the segment syntax error code. AK4 gives the element position, the element reference number, AK403, the element error code, and a copy of the bad value.

AK502 to AK506 add set-level reasons. Code 5, one or more segments in error, accompanies most rejections with AK3 detail; code 3, header and trailer control numbers do not match, and code 4, segment count mismatch, point at the envelope builder rather than the data.

Outbound EDI monitoring in the translator should treat an X12 997 with AK501 code R, M, W or X, or AK901 code P or R, as a failure alert within 60 minutes, and store each AK3 segment position and AK4 error code so the analyst can correct the element before the partner's next cut-off.

TA1, 997 and 999 compared at three envelope levels

TA1 answers the interchange envelope, the 997 answers syntax inside a functional group, and the 999 adds conformance to a published implementation guide. A partner can ask for more than one. Knowing which level failed tells you whether to look at the transport and envelope settings, the map, or the implementation guide rules.

The 999 matters to logistics teams that also serve health care customers. The Minnesota Department of Health adopted the 005010X231 implementation acknowledgment into rule in 2016 through its uniform companion guide. A logistics partner that sends a 999 instead of a 997 can still be reconciled with the same keys, because the 999 also uses AK1, AK2 and AK9.

Overdue windows by document type and who is alerted

An overdue window should be set by what the document must achieve before a physical event, not by a single global timer. A ship notice is worthless after the trailer arrives; an invoice can wait hours. The table gives illustrative windows and names who owns the alert and who may authorise a resend.

Resends need a rule too. A corrected set should go out with new ST02 and GS06 control numbers, and the record should link the new set to the rejected one, otherwise the partner's duplicate check or your own reconciliation will treat it as a repeat. Our page on 846 inventory snapshot reconciliation and idempotency covers duplicate and replay handling for the inventory message itself; this one concerns the acknowledgment that sits above every message type.

The daily query that finds unacknowledged transaction sets

One query run on a schedule, and once each morning as a report, should classify every outbound set as accepted, rejected, pending or overdue. The logic has to handle partners that send AK2 loops only for rejected sets, because for them a missing AK2 inside a partially accepted group means accepted, not lost.

-- Classify every outbound transaction set that expects a 997 (last 7 days)
WITH sent AS (
  SELECT o.partner_id, o.ts_code, o.gs06, o.st02, o.sent_at,
         p.fa_window_min, p.ak2_for_accepted,
         g.ak901, g.ak902, g.ak903, s.ak501
  FROM edi_out_set o
  JOIN edi_partner p   ON p.partner_id = o.partner_id
  LEFT JOIN fa_group g ON g.partner_id = o.partner_id AND g.ak102 = o.gs06
  LEFT JOIN fa_set s   ON s.fa_group_id = g.fa_group_id
                      AND s.ak201 = o.ts_code AND s.ak202 = o.st02
  WHERE o.fa_expected = TRUE          -- never TRUE for outbound 997s
    AND o.sent_at >= now() - interval '7 days'
)
SELECT partner_id, ts_code, gs06, st02, sent_at,
  CASE
    WHEN ak501 IN ('A','E')                     THEN 'ACCEPTED'
    WHEN ak501 IN ('R','M','W','X')             THEN 'REJECTED'
    WHEN ak901 IN ('A','E')                     THEN 'ACCEPTED_BY_GROUP'
    WHEN ak901 = 'P' AND NOT ak2_for_accepted   THEN 'ACCEPTED_IMPLIED'
    WHEN ak901 = 'P' AND ak2_for_accepted       THEN 'AK2_MISSING'
    WHEN ak901 IN ('R','M','W','X')             THEN 'REJECTED_BY_GROUP'
    WHEN sent_at < now() - make_interval(mins => fa_window_min) THEN 'OVERDUE'
    ELSE 'PENDING'
  END AS fa_status,
  (ak903 IS NOT NULL AND ak903 < ak902) AS sets_lost_in_group
FROM sent
ORDER BY fa_status, sent_at;

-- Daily acceptance rate R = sets ACCEPTED* / sets sent with fa_expected (target R >= 0.995)

Run the query every fifteen minutes for alerts and once at 07:00 for a report the EDI analyst signs off. Any row in REJECTED, REJECTED_BY_GROUP, AK2_MISSING or OVERDUE is an open exception until it is resent, written off with a reason, or explained by the partner. Our 204 load tender and 990 response timeout rules use a similar overdue ladder for a business response rather than a syntax one.

Daily 997 reconciliation joins each outbound X12 transaction set to the partner's AK1 group control number and AK2 set control number in the EDI translator log, treats sets without AK2 in a P group as accepted only for partners configured that way, and should keep the acceptance rate at or above 99.5%.

A rejected ship notice that surfaced weeks later as a deduction

Most silent EDI failures are not lost files; they are rejections that arrived on time and were never read. The trace follows one functional group of three ship notices from a US distributor to a retail customer, with the control numbers that let the failure be found.

1. 4 Nov 2026, 16:42: The WMS releases three 856 ship notices in functional group 9150 (GS01 = SH); set 0417 covers a trailer of 14 pallets due at the customer's distribution centre at 06:30.
2. 16:58: The 997 arrives: AK1*SH*9150, then AK2*856*0417 with AK3*DTM*4**8, AK4*2**8*20261131 and AK5*R*5, and finally AK9*P*3*3*2. The ship date was computed as 31 November.
3. 17:00: The dashboard reads only AK9, shows P in amber, and an operator acknowledges the alert because two of three sets were accepted. Nobody opens the AK2 loop.
4. 5 Nov, 06:30: The trailer arrives with no ship notice on file. Receiving scans every carton by hand, the appointment overruns by 90 minutes, and the cartons post a day late.
5. 19 Nov: The customer's remittance carries a compliance deduction for the missing notice. Under daily reconciliation, set 0417 would have shown REJECTED at 17:00, the analyst would have fixed the date logic and resent the notice as a new set before 20:00.

Ship notice acknowledgment checks for X12 856 sets must read every AK2 loop and AK5 code, not only AK901, because a functional group returned as AK9*P*3*3*2 still contains one rejected set; alerting the shipping supervisor within 60 minutes leaves roughly 13 hours to resend before a 06:30 trailer arrival.

The date bug itself was found in an hour once someone read the AK4 line. The process failure was that a group-level P status was allowed to stand in for the status of each set. Our 856 ship notice hierarchy and error handling guide covers the ship notice structure that sets like 0417 must follow.

What silent rejections cost a US distributor and an Indian exporter

The cost of an unread rejection is mostly deductions and delayed cash, not EDI fees. The model compares a US distributor with an Indian exporter that sends X12 to US customers; the exporter's deductions are shown converted to rupees at its booking rate. Volumes, rates and the share avoided are illustrative.

The twenty percent left are rejections found too late to matter, such as a ship notice for a trailer already unloaded. Shortening the alert window for 856 sets reduces that share more than any other change, which is why the ship notice row in the deadline table is the strictest.

Checks that run unattended and triage where software assists

Matching, classifying and alerting are fixed rules; deciding what caused a rejection and whether to resend is a person's call that software can speed up. Keep the classification logic in the query and away from any assistant, so the acceptance rate the analyst signs each morning is reproducible.

Putting 997 reconciliation into daily EDI operations

Start by switching every outbound flow to "acknowledgment expected" in the partner profile, then run the query in report-only mode for two weeks before turning on alerts. The checklist sets the conditions for each step. The wider set of messages these acknowledgments cover is listed across our logistics and supply chain library.

For a review of how your translator, partner profiles and alerting handle acknowledgments, or for a monitoring build across many partners, the NextEdge RFP page lets you set out your partner count, message volumes and current tools.