The AK segments, in the order you read them
AK1 identifies the functional group being acknowledged by its functional identifier code and group control number. AK2 identifies a transaction set within that group. AK3 and AK4 report the specific segment and data element in error when there is one, which is the part worth logging because it names the field. AK5 reports the status of that one transaction set, and AK9 reports the status of the whole functional group along with counts of transaction sets included, received, and accepted.
- AK1 functional group being acknowledged
- AK2 transaction set within the group
- AK3 segment level error detail
- AK4 data element level error detail
- AK5 status of the individual transaction set
- AK9 status of the functional group, with included, received, and accepted counts
Read AK501 and AK901 as syntax verdicts
Both fields draw on the same family of status values. A means accepted. E means accepted but errors were noted, which is the value most often mishandled because it is neither a clean pass nor a rejection. P on AK901 means the group was partially accepted, so some transaction sets inside it were rejected while others went through. R means rejected. M, W, and X report authentication, assurance, and decryption failures rather than business content problems. Partial acceptance is the dangerous one: the interchange looks delivered while specific orders inside it never arrived.
- A accepted
- E accepted, but errors were noted
- P partially accepted, at least one transaction set rejected
- R rejected
- M rejected, message authentication code failed
- W rejected, assurance failed
- X rejected, content could not be analysed after decryption
Know the neighbours: TA1 and 999
A TA1 is an interchange acknowledgment that reports on the ISA and IEA envelope itself, and it can arrive when the contents were never examined. A 999 implementation acknowledgment is the transaction set used where compliance with a published implementation guide is checked as well as X12 syntax, and it is the norm in the HIPAA healthcare transactions. All three are transport and syntax level documents. None of them is a business answer, and no combination of them tells you whether a supplier will ship.
Why this matters to a purchasing report
A dashboard that counts acknowledged purchase orders from 997 data is counting successful parses. It will report a healthy acknowledgment rate on a supplier base where nobody has committed to a single date. The states that matter operationally are different from each other and should never be merged into one status: sent, delivered, parsed, viewed, replied, accepted at line level, and committed after a buyer decision. Only the last two describe an obligation.
- Sent: your system transmitted the order
- Delivered and parsed: reported by a 997 or a transport receipt
- Replied: the supplier returned an 855 or a message of some kind
- Accepted at line level: the supplier stated quantity, price, and date per line
- Committed: the buyer resolved any difference and authorised the result
The same gap exists off EDI, and it is larger
Outside an EDI relationship the equivalent of the 997 is an email delivery receipt or a successful send in an ERP, and it is treated the same way: as if it meant the supplier agreed. Pacteva is built around that distinction. Delivery, view, response, buyer decision, and current commitment are separate recorded facts, and the queue that matters is the one holding orders where the supplier has not answered at line level. Pacteva does not process 997 documents. It removes the reason to misuse them.
Validate the workflow with one real purchase order
Before buying or replacing software, run one representative multi-line PO from reviewed source through supplier response and buyer resolution. Include at least one accepted line, one proposed date or quantity change, and one delivery or reminder edge case. Confirm that every participant can identify the current owner and next action, that the original order remains unchanged, and that the final commitment can be exported and traced to its response and decision. Also verify the supplier experience on a normal phone and desktop browser, revoke and reissue a response link, inspect a failed delivery, and test the role boundary with a non-owner buyer. This evidence is more useful than a feature checklist because it exposes adoption friction, hidden authority, and incomplete system boundaries before the workflow reaches production volume.
Keep source, proposal, decision, and commitment distinct
Pacteva records supplier responses and authorized buyer decisions. It does not silently alter the reviewed purchase order or claim an ERP changed unless a configured write-back is verified. Requisitions, budgets, receipts, invoices, payments, inventory, and shipping remain in their systems of record.
What buyers usually ask
Does a 997 mean the supplier accepted the order?
No. It means the functional group was received and passed a syntax check. The commercial answer is an 855.
What does AK901 P mean?
The functional group was partially accepted. At least one transaction set inside it was rejected, so specific orders may not have arrived even though the group looks delivered.
What is the difference between a 997 and a 999?
A 997 reports X12 syntax acceptance. A 999 implementation acknowledgment additionally reports compliance with a published implementation guide, and is standard in HIPAA healthcare transactions.
Does Pacteva generate a functional acknowledgment?
No. Pacteva records delivery, view, supplier response, and buyer decision as separate facts for suppliers responding outside EDI.
What informed this page
Reviewed July 31, 2026. Sources link to the public vendor or product material used for factual context. Competitor products and prices can change, so verify them directly before purchasing.
- ASC X12 The standards body that publishes and maintains the X12 transaction sets referenced on this page.