EDI integration for distributors: how do purchase orders, shipment notices and invoices connect to ERP?

What do EDI 850, 855, 856 and 810 connect to?

EDI integration joins the external document exchange to the internal application. Receiving an order in an EDI mailbox is not enough if customer service must type it into the ERP, the enterprise resource planning system. As IBM’s definition of EDI integration explains, the connection carries partner data into internal systems and sends internal records back in the partner’s format.

The table below uses X12 document numbers. Their functions follow X12’s transaction-set descriptions; the ERP records and owners are an implementation design for a distributor selling to a customer, not rules imposed by the standard. A distributor buying from a supplier would reverse the commercial roles.

An 856 is commonly called an advance ship notice, or ASN. It describes a shipment; it is not proof that the buyer received the goods. An 810 is a bill, not proof of payment. X12 also states that an 850 should not carry purchase order changes or acknowledgement information. Agree the change process separately rather than treating a changed PO as another new order.

Does a 997 or 999 mean the order is accepted?

No. X12 defines the 997 Functional Acknowledgment as the result of syntactical analysis, and the 999 Implementation Acknowledgment as syntactical and relational analysis. Neither covers the business meaning of the document. A technically accepted 850 can still have an unknown item, an unapproved price or a credit hold. The 855 is the seller’s business response in this flow; configure its statuses against the partner guide. A 999 is not simply a different spelling of 997, and not every partner requires both.

Keep three separate statuses: transport delivered, EDI validation accepted or rejected, and ERP business accepted or held. Microsoft’s 997 documentation illustrates how processing errors are reported. None of those transport or validation receipts should release stock by itself.

Does the same document map apply to UK partners?

Do not choose the message standard from the country alone. Ask each UK or US partner which standard, version and implementation guide it requires. X12 numbers are not universal EDI message names: EDIFACT has its own message structures and partner agreements, as the official EDIFACT integration documentation shows. The commercial handoffs still need owners, but an X12 mapping cannot simply be renamed for an EDIFACT connection.

Who owns the fields that cross the EDI and ERP boundary?

The translator converts formats; it should not quietly decide a new selling price, substitute an item or grant credit. Give each business decision an owner and preserve the partner’s original values beside the accepted ERP values. This is a proposed ownership map to agree with your teams before building the connection.

Record this map in the partner setup, not only in a developer’s notes. If customer item V-72 means one case for one partner and one unit for another, the cross-reference must include the partner and selling unit. A valid file with the wrong conversion can ship the wrong quantity more efficiently.

The wholesale order management guide places EDI beside email, rep and portal orders. All of those routes should reach the same ERP pricing, credit and release decisions rather than establish competing order rules.

How does one order survive a price difference and two shipments?

Consider this illustrative example, not a client result. A customer sends PO P-410 for 10 cases of valve V-72. One case contains six units. Its 850 requests $48 per case, while the distributor’s approved price is $50. Only eight cases can ship now. For this example, the parties agree the $50 price, a two-case backorder, and one invoice per shipment; tax and freight are excluded. These are scenario assumptions, not universal partner rules.

The customer may require a revised PO or another agreed change exchange before accepting the new price. Do not invent an 855 code that means “approved by phone” or assume a price-change response is permitted. Retain who approved the change, when, and the document or conversation reference; keep the original PO intact.

The second shipment needs a distinct shipment identity linked to the same order line. If a picker finds only seven cases instead of eight, correct the confirmed shipment and packing record before generating the ASN. An ASN prepared from the allocation would describe stock that never left. For routing, split fulfilment and customer updates beyond the EDI boundary, use the fulfilment workflow guide.

If the first 810 is rejected for a missing PO line reference, finance still has invoice I-601. Correct and retransmit according to the partner’s correction rules; do not create invoice I-603 merely to obtain another transmission. If the accounting amount itself is wrong, finance must use its approved correction process rather than editing an already posted invoice invisibly.

What happens when documents are rejected, late or duplicated?

A useful exception queue shows partner, document type, PO and line, ERP record if one exists, validation or business reason, first failure time, deadline, owner and next action. Keep the original payload and each attempt. A support team needs to distinguish a malformed file from a valid order waiting for a price decision.

• Transport or syntax failure: integration support investigates connection, envelope, version or mapping errors. Fix the cause and follow the agreed resend procedure; do not ask finance to change the order price to clear a syntax error.
• Business hold: product data resolves unknown item/unit mappings, order management resolves dates and substitutions, sales resolves price differences, and finance resolves credit. Return the permitted business response rather than leave the customer to infer acceptance from a 997.
• Missing acknowledgement: alert against the partner’s agreed window. First check delivery and processing history. Absence of a receipt is not proof that the partner did not process the document.
• ASN timing: agree the dispatch event, send-by deadline, time zone and recovery route. Generate from confirmed packing data with enough time for the partner’s receiving process. Do not adopt a generic “within 24 hours” rule or assume every partner expects the same sequence.
• Order changes or cancellations: define which message or approved route handles them and what happens after picking starts. X12 has separate change transactions; a later 850 must not silently overwrite a released order.

How do you prevent a retry from creating a second order?

Use two checks. First, apply the agreed technical duplicate controls to envelope and transaction identifiers. Second, make the ERP posting idempotent: repeating the same business request must return the existing result, not create another order or invoice. A partner can resend the same PO under new envelope numbers, so envelope checks alone are insufficient.

For order intake, agree a business key such as partner, order type, PO and revision. Define how legitimate PO reuse is distinguished. Save the source-to-ERP link durably and enforce uniqueness where the record is created, not just in a temporary queue. If the ERP times out after posting, look up that key before retrying. Changed content under the same key should raise a conflict for review rather than be dropped or applied as a new order.

For outbound documents, retain the invoice or shipment identity, payload version, attempt history and partner receipt. A replay can need new technical control numbers under the agreement while retaining the same business identity. Correction and replacement rules must distinguish a retry from a genuinely changed document. Limit retries, alert a named owner, and protect customer data in logs with appropriate access and retention rules.

What should operations reconcile each day?

Compare received POs with accepted, held and rejected ERP requests; approved responses with sent documents; confirmed shipments with their required ASNs; and posted invoices with sent and acknowledged 810s. Compare line quantities and amounts as well as document counts. In the example, eight shipped cases plus two open cases must explain the ten ordered, and the two invoices must refer to the same accepted $50 price. Never mark the whole order complete because its first shipment received a technical acknowledgement.

What must a trading partner pass before go-live?

Obtain the partner’s current implementation guides and commercial requirements before estimating the mapping. The base standard describes a document; the partner chooses a supported version, fields, identifiers, codes, package hierarchy and operating rules. For a concrete historical example, D&H Distributing’s public V4010 856 guide, dated August 2016, marks some base-standard optional segments as “Must use” and requests a return 997. It demonstrates why a generic X12-valid document is not enough; obtain the current agreed guide rather than copy this older example as today’s requirement.

The partner pack should include test and production IDs/endpoints, connection method, certificates and renewal owner where applicable, message/version list, sample files, item and ship-to cross-references, response deadlines and time zones, carton/label requirements, change procedures, error contacts and cutover approval. If the agreement includes chargebacks, record the exact trigger, evidence, amount and dispute route from those terms. Do not infer a chargeback or a universal fine from the X12 document number.

These are proposed tests, not reported test results. Agree the expected result with the partner and retain its acknowledgement plus the ERP record for each case. Passing a translator’s schema check is only one piece of sign-off.

What should an EDI integration estimate include?

Budget for partner onboarding and versioned mappings, not only the EDI subscription. Ask separately about network or connection charges, document/volume pricing, ERP adapter work, master-data cleanup, package-label data, partner testing, monitoring, support hours and change requests. A new partner can reuse the underlying order process while still needing different identifiers, mandatory fields and acceptance tests. Do not assume that adding a partner means changing only an address.

A packaged connection can fit when it supports the actual partner guide and the ERP’s records without rewriting business rules. A managed EDI service can own translation and communications, but the distributor still needs owners for prices, credit, shipment accuracy and invoices. A web portal with manual entry may be an acceptable low-volume starting point; it does not meet a requirement for automatic ERP posting. Request evidence against the same test matrix whichever route is proposed.

Keep warehouse execution as a separate scope. This guide covers customer-facing orders, responses, ASNs and invoices; detailed 940/945 warehouse/3PL mappings need their own ERP-to-warehouse design. If ERP selection is still open, the distribution ERP evaluation guide helps identify the order and inventory controls the connection will rely on.

Before commissioning the connection, bring one partner guide, a difficult PO, a partial shipment and the related ERP invoice to the table. Harmatiq’s integration and automation work starts by mapping those records, decisions and exceptions. The first useful deliverable is an agreed flow with owners and pass criteria, not a promise that every document will move without intervention.