EDI 997 Functional Acknowledgment Builder

What a 997 Functional Acknowledgment Is

The X12 997 is the "I got your message" reply of the EDI world — a small, universal receipt the recipient returns to confirm that an inbound functional group arrived and whether each transaction set inside it was syntactically valid. It isn't a business response (it doesn't say whether the PO was approved or whether the invoice will be paid — those are 855s, 820s, and workflow status codes), but it is the heartbeat that tells a sender the file made it through the VAN, parsed cleanly, and entered the receiver's system. Most trading-partner contracts require a 997 back within a short SLA — 15 minutes to an hour for retail, same business day for healthcare, one calendar day for finance — and a missing 997 is typically treated as a transmission failure that triggers a retry or an escalation.

Structure of a 997

A 997 is one of the smaller X12 transactions: an AK1 at the top identifying which functional group is being acknowledged (the GS01 functional ID code and the GS06 control number of the inbound group), an AK2/AK5 pair for each transaction set inside the group (the ST01 transaction-set code, the ST02 control number, and the single-letter acknowledgment code — A accepted, E accepted with errors, P partially accepted, R rejected), and an AK9 rolling up the whole group (overall code plus totals: transactions included, transactions received, transactions accepted). The envelope is standard ISA/GS/ST, with the GS functional ID code FA (Functional Acknowledgment) identifying the outbound as a 997. Some implementations add AK3 (segment-level error notes) and AK4 (element-level notes); this builder emits the AK1/AK2/AK5/AK9 core, which is what the vast majority of partners require.

How This Tool Generates a Valid 997

Paste or drop the inbound document you're acknowledging — any X12 transaction works (850, 810, 856, 820, 855, 860, 997 itself, anything else). The tool walks the ISA/GS/ST segments, identifies every functional group and every transaction set inside each group, and lists them with an AK5 dropdown per set (defaulting to A Accepted). The reply partner is auto-derived by swapping the inbound ISA06/08 sender and receiver — the outbound 997 naturally goes back to whoever sent the inbound. Override any AK5 to reject a specific transaction; the AK9 overall code rolls up automatically (all-accepted → A, any-rejected with some-accepted → P, all-rejected → R, E preserved when present). Download a ready-to-transmit .edi file with proper ST/SE segment counts and GE/IEA totals. The generated file parses cleanly through the EDI File Parser. For segment-level reference, see the X12 Segment Reference.

What This Tool Isn't

This is a hand-builder for the cases where you need to produce a 997 manually — a trading partner is waiting for an acknowledgment that your system couldn't emit, a developer is testing a new 997 ingest path, or you're reverse-engineering a buyer's ack expectations from a sample. It does not automatically validate the inbound for syntactic errors (garbage elements, missing segment terminators, wrong transaction-set code at ST01) or generate AK3/AK4 error notes. It also does not handle transmission — delivery still happens via AS2, SFTP, VAN, or whatever channel your partner expects. If you need 997s emitted on an SLA from a validator-driven pipeline, Ask James.

EDI Integration with Your Systems

Most of the EDI integration work I do bridges X12 and whatever formats your systems produce and consume — modern APIs, database tables, spreadsheet exports, flat files, or legacy platform-native formats. Inbound direction: a partner's 850/856/997 lands in the exact shape your order entry, WMS, or AP system expects. Outbound direction: validator-clean 810/850/855/856/820 built from your systems' native data — handling partner-specific variations, acknowledgments, and exception workflows.

Need Automated Acknowledgments?

In production, 997s are emitted by software within a partner-defined SLA window that's often measured in minutes, not hours. The real work is the inbound receive loop: accepting AS2 / SFTP / VAN delivery, running the inbound through a syntactic validator that flags missing required segments and out-of-spec qualifiers, generating AK3 and AK4 error notes when something is wrong, emitting the 997 back through the same transport, and — critically — matching 997s to their originating outbound so your monitoring can distinguish a partner who never sent the ack from one who sent it and flagged errors. I build that whole loop — receive → validate → 997 → transmit → reconcile — partner-tested against your trading partner's implementation guide. For 997 SLA compliance, validator-driven rejection pipelines, or rescuing a failing ack loop, Ask James.