Order to cash: the documents that carry a purchase order
This is the core sequence for a buying organisation. The buyer sends an order, the supplier answers it, either side may change it, goods are notified and then invoiced. The value in brackets is the functional identifier code that appears in GS01 for that group. The purchase order documents each have a segment level reference on this site.
- 850 purchase order, buyer to supplier (PO)
- 855 purchase order acknowledgment, supplier to buyer (PR)
- 860 purchase order change request, buyer initiated (PC)
- 865 purchase order change acknowledgment, seller initiated (CA)
- 856 ship notice and manifest, the ASN, supplier to buyer (SH)
- 810 invoice, supplier to buyer (IN)
- 820 payment order and remittance advice
- 824 application advice, reporting a business level problem with a received document
- 832 price and sales catalog
- 846 inventory inquiry and advice
- 852 product activity data
- 861 receiving advice and acceptance certificate
- 869 order status inquiry and 870 order status report
Warehouse: documents between a shipper and a third party warehouse
These appear where fulfilment is outsourced to a third party logistics provider. They are outside the purchasing team's daily work but frequently show up in the same integration project, which is why the numbers are worth recognising.
- 940 warehouse shipping order
- 943 warehouse stock transfer shipment advice
- 944 warehouse stock transfer receipt advice
- 945 warehouse shipping advice
- 947 warehouse inventory adjustment advice
Transportation: documents between a shipper and a carrier
These carry freight rather than orders. They belong to a logistics or transportation function and are listed here so a number met in a project can be identified, not because a purchasing team owns them.
- 204 motor carrier load tender
- 990 response to a load tender
- 210 motor carrier freight details and invoice
- 214 transportation carrier shipment status message
- 753 and 754 routing request and routing instructions
Acknowledgments: the numbers that are not business answers
These report on transmission and syntax. They are the most commonly misread documents in an EDI flow, because a successful acknowledgment at this level is routinely reported to a business audience as though the supplier had agreed to the order. None of them carries a commitment.
- 997 functional acknowledgment, syntax acceptance of a functional group (FA)
- 999 implementation acknowledgment, syntax plus implementation guide compliance
- TA1 interchange acknowledgment, reporting on the ISA and IEA envelope itself
How to use this list on a real integration
A transaction set number tells you what a document is for. It does not tell you what your trading partner has implemented, which optional segments they populate, or which code values they support. That lives in the partner's implementation guide, and the difference between the standard and the guide is where integration time is actually spent. Ask for the guide before scoping, and test with a real order that includes a change and a partial acceptance rather than a clean one.
The suppliers who are on none of these
In most purchasing organisations, EDI covers the largest suppliers and a long tail responds by email. That tail is often the majority of orders by count and a large share of the schedule risk, because none of its promises are structured. Pacteva collects line level acknowledgment from those suppliers through a secure accountless link and exports the ordered value, the supplier response, the buyer decision, and the current commitment as separate fields. It is not an EDI translator and it does not send or receive X12.
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
Which transaction set acknowledges a purchase order?
The 855. A 997 acknowledges only that the transmission parsed.
What is the difference between an 860 and an 865?
An 860 is a change initiated by the buyer. An 865 is either the supplier's acknowledgment of that change or a change the supplier initiates itself.
Where do the functional identifier codes appear?
In GS01, the first element of the functional group header that wraps one or more transaction sets of the same type.
Do I need EDI to collect purchase order acknowledgments?
No. EDI is the right answer for high volume partners with the capability to support it. For everyone else, a structured accountless response captures the same line level facts without an integration project.
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.