EDI 997 vs 999: acknowledgement is a scoped technical status

Both the 997 and 999 exist to communicate acknowledgement information, but the expected document and interpretation depend on the partnership, transaction family, and implementation. A receiver or managed service may generate one and not the other.

Direct answer: Configure whether each partnership expects a 997, 999, TA1, or combination; correlate every acknowledgement to the exact interchange, group, and transaction controls; preserve group and transaction-level results; and keep business-status monitoring separate. Neither a positive 997 nor 999 proves an ASN was received accurately or an invoice will be paid.

Practical difference

AWS B2B Data Interchange describes a 997 as a functional acknowledgement used for many finance, transportation, supply-chain, and communication/control transactions. It describes 999 generation for configured healthcare-related flows and states that its service generates either a 999 or 997, never both. That is service behavior, not a universal rule for every partner.

The safe product model therefore avoids a hard-coded “997 good, 999 unexpected” assumption. A versioned partnership profile states what response is expected and by when.

Correlation fields

At minimum, preserve enough identity to resolve:

• trading partnership and direction;
• interchange sender/receiver and control;
• functional group and control;
• transaction set and control;
• original content hash and transmission attempt;
• acknowledgement type, status, errors, and receipt time.

An acknowledgement that cannot resolve uniquely is not success. Quarantine it for investigation instead of applying it to every open transaction with a similar filename.

Status precedence

Acknowledgements may be duplicated or arrive out of order. Use monotonic precedence so an accepted duplicate cannot erase a prior rejection or detailed error without an explicit corrected transaction flow.

Record group and transaction results independently. A group-level response can coexist with a transaction-level exception, and a UI should not compress that into one green badge.

Technical versus business status

Keep separate timelines for:

This separation catches the “accepted but nothing happened” failure that no error webhook emits.

Test matrix

• expected 997 accepted, rejected, and accepted-with-errors;
• expected 999 with transaction-level implementation error;
• acknowledgement for an unknown control number;
• same control reused by another partnership;
• accepted response arriving after rejection;
• duplicate response processed twice;
• no response by deadline;
• technical success followed by business failure or stalled status.

Support boundary

This guide describes acknowledgement monitoring and expansion. Production X12 conformance rules need the appropriate licensed sources, and the current Shipment Sentry validator supports only the formats named on its interface.