EDI 997 — Functional Acknowledgement

Purpose

Confirm receipt of an EDI transaction. Flxpoint sends a 997 to you every time it receives a file from you. It confirms the file arrived and was structurally valid — it does not confirm business logic.

In Plain English

The 997 is the receipt. Every time you send Flxpoint a file — an 850, an 856, an 810 — Flxpoint writes a tiny 997 back to your outbound folder that says "got it, the envelope was readable." It is not a business confirmation: it does not promise the inventory was updated, the shipment was accepted, or the order was processed. That is what the 855 (PO acknowledgement) and 810 matching are for. Think of the 997 like a delivery receipt for a certified letter — it proves the letter arrived, not that the recipient agreed with what was inside. Most "overdue 997" support tickets turn out to be SFTP round-trip issues (the partner never picked up the file from /out), not actual processing failures.

Frequency

Sent by Flxpoint automatically in response to every inbound transaction. Find 997s in your /out (outbound from Flxpoint) directory.

Business Rules

• You must generate a 997 for every transaction Flxpoint sends you (850, etc.)
• A 997 with AK501=A means the transaction was accepted
• A 997 with AK501=E means accepted with errors — review the AK5 detail
• A 997 with AK501=R means rejected — the file had structural issues

Acknowledgement Status Codes

AK501 — Transaction Set Acknowledgement Code

AK901 — Group Acknowledgement Code

Segment Hierarchy

ISA  Interchange Header
 GS  Group Header (GS01 = "FA")
  ST   Transaction Set Header (ST01 = "997")
  AK1  Functional Group Response Header
  ┌─ AK2 Loop (one per transaction set)
  │  AK2  Transaction Set Response Header
  │  AK5  Transaction Set Response Trailer
  └─
  AK9  Functional Group Response Trailer
  SE   Transaction Set Trailer
 GE  Group Trailer
IEA  Interchange Trailer

Segment Specifications

ST — Transaction Set Header

AK1 — Functional Group Response Header

AK2 — Transaction Set Response Header

AK5 — Transaction Set Response Trailer

AK9 — Functional Group Response Trailer

SE — Transaction Set Trailer

Example — Accepted 997

ISA*00*          *00*          *ZZ*FLXPOINT       *ZZ*SUPPLIER       *240115*1200*U*00401*000000015*0*P*>~
GS*FA*FLXPOINT*SUPPLIER*20240115*1200*15*X*004010VICS~
ST*997*0001~
AK1*SH*253~
AK2*856*3936~
AK5*A~
AK9*A*1*1*1~
SE*5*0001~
GE*1*15~
IEA*1*000000015~

What this means: Flxpoint received your 856 (Ship Notice, GS control number 253, ST control number 3936) and it was accepted (AK5*A).

Reading 997 Errors

If you receive a 997 with AK501=E or AK501=R, the AK5 segment will include error codes:

How Flxpoint Handles 997s

Because the 997 is an envelope-level acknowledgement (not a business validation), Flxpoint treats it differently from transactions like the 846 or 856:

• Generation is automatic. Every inbound 850 / 855 / 810 / 846 / 856 that Flxpoint receives triggers a 997 response. You do not request it — it is written to your outbound SFTP directory as soon as the file is read.
• Validation is structural only. Flxpoint does not open the business content to produce the 997. The 997 confirms that the interchange, group, and transaction-set envelopes are well-formed — that is all.
• No validation inside Flxpector. The Flxpector inspector does not run schema checks on 997 files because they have no business payload to validate. If you paste a 997 into Flxpector, you will see the envelope parse without errors — that is expected.
• Flxpector focuses on the transactions that carry business data (846, 850, 855, 856, 810). If you need to confirm a 997 round-trip, check your SFTP /out folder and your partner's pickup logs.

This is the same approach most X12 processors take: the 997 is infrastructure, not content.

Troubleshooting — "We didn't receive your 997"

This is one of the most common support requests. Partners occasionally send an "Overdue Ack Report" email listing ASNs or invoices they say were not acknowledged within the expected window.

Before assuming the 997 is missing, verify the round trip:

1. Was the original file received? Check Flxpoint's inbound logs for the ASN / invoice control number (ISA13 / GS06 / ST02) listed in the overdue report. If it is not in the logs, the partner never delivered it — the issue is upstream of Flxpoint.
2. Did Flxpoint generate the 997? Ninety-nine percent of the time the 997 was generated and written to the outbound folder within seconds of receipt. Confirm the file exists in your outbound SFTP directory with the matching control numbers.
3. Did the partner pick it up? If the 997 is on the outbound server and the partner says they did not receive it, the issue is on the partner side or in the SFTP connection configuration. Options:
   • Verify the partner is polling the correct outbound path.
   • Confirm their whitelist includes the Flxpoint SFTP host and static IP.
   • If the partner hosts the SFTP, confirm Flxpoint has write credentials to the expected drop path.

Who handles it? This is operational (SFTP / logs), not parsing. It is worked by the integrations team through backend logs — it is not a Flxpector validation case. When the chatbot is asked about "overdue 997s," it should point the user to this troubleshooting flow and avoid suggesting parser fixes.