An EDI ERP integration is ready to start when you can answer six questions with a yes: you have every trading partner's spec in hand, your item and customer master data is clean, your ERP can create and update the records EDI needs, you know where carton-level shipping data lives, someone owns exceptions, and you have a test plan your partners will accept. Projects that skip one of these usually stall in testing, which is the most expensive place to discover a gap.

This checklist is the prep work. If you want the bigger picture first (how the data flows, the five connection methods, and what integration costs), start with our guide to EDI ERP integration and come back here when you are ready to scope.

1. Trading partner requirements

Every retailer publishes an implementation guide that sits on top of the X12 standard, and two retailers asking for the same 850 will still want different segments and qualifiers. If you start mapping before you have the guides, you will map twice.

You are ready on this item when you have:

• The current EDI implementation guide for every partner in scope, with the version (4010, 5010, and so on) noted for each document. Our EDI standards guide explains why the version matters.

• A list of the documents each partner requires, inbound and outbound. For most retail relationships that is the 850, 855, 856, 810, and 997, with the 846, 860, and 753 showing up often enough that you should ask.

• The transport each partner expects (AS2, SFTP, or a VAN) and their ISA qualifier and ID. See our notes on AS2 connections and ISA ID setup.

• The partner's label, routing, and compliance requirements, since these drive what your ERP or WMS has to produce. The trading partner directory has requirements for retailers such as Walmart, Target, and Costco.

• The partner's testing process and go-live window. Some retailers run certification on a fixed calendar, and missing a window can push you out by weeks.

Not ready yet: you know "Walmart needs EDI" but have not downloaded the spec, or your buyer has promised a ship date before anyone has checked the test calendar.

2. Master data

EDI resolves everything through identifiers. When a retailer's 850 arrives with a UPC your item master does not recognize, or a ship-to code that is not tied to a customer record, the order fails or, worse, posts against the wrong record. Most of the post-launch firefighting we see traces back to master data that looked fine to humans.

You are ready on this item when:

• Every sellable item has a GTIN or UPC, and the case-level GTIN, case pack, dimensions, and weight are filled in and accurate.

• Retailer item numbers (the buyer's part number) are cross-referenced to your SKUs, if your partners send them.

• Each partner's ship-to and bill-to locations exist as records, keyed by the store or DC numbers the partner sends. Many partners identify locations with a GLN, and some will ask for your DUNS number.

• Your pricing matches the cost the retailer has on file. A price mismatch between the 850 and your 810 is one of the most common reasons invoices get rejected or short-paid.

• Units of measure are consistent. If the partner orders in cases and your ERP sells in eaches, the conversion rule is written down and agreed.

Not ready yet: item data lives in a spreadsheet that one person maintains, or you have duplicate customer records for the same retailer.

3. ERP capability

The integration layer can translate anything, but it still needs somewhere to write. Check that your ERP can hold and return the fields EDI depends on before you commit to a go-live date.

Questions to answer about your ERP:

• Can orders be created through an API, a connector, or a scheduled file import, without someone keying them?

• Can a sales order carry the partner's PO number, department, store or DC number, requested ship and cancel dates, and line-level buyer item numbers? If not, can you add custom fields?

• Can you invoice one PO at a time, and can the invoice reference the original PO line numbers? Retailers match the 810 to the 850 line by line.

• Does the ERP expose fulfillment and shipment records the integration can read when it builds the ASN?

• Are there per-API-call limits, licensing tiers, or user seats the integration will consume?

Prebuilt connectors answer most of these questions for common platforms. If you run NetSuite or Cin7, see our NetSuite and Cin7 integration pages, and browse the rest on the integrations hub.

Readiness for homegrown and custom ERPs

A custom ERP can be a good integration candidate because you control the data model. The checks are the same, with two additions. First, confirm the system can exchange structured data, either through an API or by reading and writing files in an agreed format such as JSON, XML, or CSV. Second, name the developer who will own changes on your side, because every new partner field eventually needs a home in the ERP. If nobody on staff can change the schema, budget for that before you start.

4. Fulfillment and carton data

This is the item that catches the most teams off guard. The 856 advance ship notice needs carton-level detail: which items are in which carton, each carton's SSCC from its GS1-128 label, and how cartons roll up to pallets. Many ERPs only know that an order shipped. The pack detail lives somewhere else.

Before you start, write down:

• Where pack and carton data is created: your ERP, a WMS, a shipping tool, or a 3PL.

• How that data gets back to the system that sends the ASN, and how quickly. A late ASN is a chargeback risk even if the goods arrive on time.

• If a 3PL ships for you, whether they support the 940 warehouse shipping order and 945 warehouse shipping advice. Our guides to the 940 and 945 cover what each carries, and this 3PL integration guide covers the handoff.

• Whether you need lot numbers and expiration dates on the ASN. Food and beverage partners often do.

For the mechanics of a clean ASN, see our ASN accuracy guide and the weight math that prevents chargebacks.

5. People and ownership

Once the integration is live, someone still has to watch the flow. Documents fail translation, retailers change specs, and a new store number shows up on a PO with no matching ship-to. Somebody has to own each of those.

You are ready on this item when you have named:

• An internal owner for EDI exceptions, with a few hours a week set aside, and a backup for when that person is out.

• Who approves maps and test results on your side, usually someone from operations and someone from finance.

• Who talks to each retailer's EDI team during testing.

• Who on the provider side is your single point of contact, if you are outsourcing.

If you cannot name these people, a managed service is worth a look. Our post on when to switch to a full-service EDI provider covers the signs.

6. Testing and cutover

Retailer testing checks structure and content. Your own testing should check that the ERP records come out right, which the retailer never sees.

A workable test plan includes:

• Test cases for every document and every variation you expect: a standard order, a multi-store order, a backorder, a cancellation, a price change, and a partial shipment.

• A check that each inbound document creates the correct ERP record and each outbound document matches the ERP record it came from. Our API testing guide for EDI integration covers how to validate maps.

• 997 reconciliation, so you can prove the partner received what you sent.

• A defined cutover: which orders go through the old process, which go through the new one, and the date you stop keying.

• Go-live criteria written down in advance, such as "five consecutive clean order cycles for each document."

Red flags that mean you should wait

If any of these are true, fix them first. Starting anyway tends to cost more time than it saves.

• Your largest partner's spec is more than a year old or you are not sure which version you have.

• Case-level GTINs, dimensions, or weights are missing for items on your first orders.

• Nobody knows where carton data lives for shipments that go through a 3PL.

• Your ERP is mid-migration or mid-upgrade.

• The go-live date was set by a sales commitment, and nobody has checked the retailer's test calendar.

How long readiness takes

For a brand with a few partners and decent data, readiness is usually one to two weeks of work. Master data cleanup is the variable that stretches it. The full project timeline, from mapping through rollout, is in the EDI ERP integration guide. If you are still deciding whether this is the year to do it, this post on the cost of waiting and our EDI ROI guide will help you build the case.

Frequently asked questions

What do I need before integrating EDI with my ERP?

You need each trading partner's implementation guide, clean item and customer master data, an ERP that can create orders and expose shipment records through an API or file exchange, a known source for carton-level shipping data, a named owner for exceptions, and a test plan.

Can EDI integrate with any ERP?

Almost any ERP that can exchange structured data through an API or files can be integrated. The work varies with how much of the data your partners require the ERP can already store.

What is an EDI readiness assessment?

It is a review of your partners' requirements, your data, your systems, and your team before an integration starts. The goal is to find gaps while they are cheap to fix, instead of during retailer testing.

Do I need a WMS to integrate EDI with my ERP?

Not always. You need a source of carton and pack data for the 856 ASN. That can be a WMS, a shipping tool, your 3PL, or an ERP that tracks packages.

Who should own EDI inside the company?

Usually operations or customer service, since most exceptions are order and shipment problems. Finance should be involved for invoices and remittances.

What if my ERP does not support EDI?

Most ERPs do not handle EDI natively. An integration layer or managed EDI service translates EDI into records the ERP can accept, as long as the ERP has an API or can import files.

How do I test an EDI ERP integration?

Run test cases for every document type and variation, confirm the ERP records match the documents, reconcile 997 acknowledgments, and complete each retailer's certification before production.

Get a readiness review

If you would like a second set of eyes on your partner list, data, and ERP before you commit to a date, talk to our team. We will tell you what is ready and what is not.