What is an EDI Requirements Document?

Updated January 26, 2022

When suppliers and retailers agree to establish a business relationship, you will inevitably reach a point when the supplier asks the retailer to send their EDI requirements document.

Everyone starts somewhere, and typically before you even have a sense of what your electronic data interchange (EDI) requirements actually are, it can be hard to share technical documentation about them.

An EDI requirements document outlines the unique requirements you have when integrating with your trading partners and the scope of the integration. It ensures that you and your partners are aligned on how your EDI integration will work, which documents are necessary and which ones are optional, protocols around testing the integration and escalating issues, and more.

Note that an EDI requirements document is different from an EDI guidelines document. The former covers the business requirements of a trade relationship built around EDI, while the latter covers the technical requirements of an EDI implementation.

In this article, we’ll explain why companies use EDI requirements documents and the elements that are typically included in one. We’ll also share a few EDI requirements document examples.

Before we dive in, we’ll add that retailers are forced to use EDI requirements documents because EDI is a bottleneck to supplier onboarding and activation. Although requirements documents provide more context for suppliers looking to join a retailer’s marketplace or dropship program, they don’t reduce the months that it takes for suppliers to go live and get transactional.

Why companies use EDI requirements documents

Companies usually have different EDI preferences, which can make integrations between trading partners difficult.

To integrate with your trading partner, you need a good sense of the scope, tech, information, and the business processes involved. Without this, there’s no consistent way to make sure you can integrate with your partner without an excessive amount of back and forth. This is one of the reasons why EDI-based trade relationships take so long to set up.

EDI may be a fairly strictly defined standard, but the documents you use and the way you use them can vary tremendously. Some companies prefer to send changes back and forth via EDI, while others prefer to handle that manually through customer service. Some companies prefer to format item codes in a certain way, while others would not be able to understand it unless it matches their internal format.

EDI can be about preference, which creates complexity. An EDI requirements document clarifies those preferences at the beginning of the relationship so you and your trading partner(s) can get things in order. When you standardize your EDI requirements, you’ll be able to integrate with your trading partners quickly and easily and with multiple partners in parallel.

Elements of an EDI requirements document

An EDI requirements document typically answers the following questions:

How do you want to receive inbound documents? Which tech is used?
In what ways are you capable of sending documents? Which tech is used? Which is preferred?
What EDI documents do you require? What documents are optional?

Retailers often require the following EDI documents:
1. Inventory Updates - EDI 846 (used for dropship partnerships)
2. Purchase Order - EDI 850
3. Purchase Order Acknowledgement - EDI 855
4. Advanced Shipping Notice (ASN) - EDI 856
5. Purchase Order Change - EDI 860
6. Invoices - EDI 810
7. Return to Vendor (RTV) - EDI 180

In answering this question, make sure you mention when your suppliers should default to an EDI transaction versus sending a CSV or XML file, or connecting to an API endpoint instead (if those options are applicable to your business).
Do you have any custom EDI mapping requirements?
What EDI standards are documents formatted in? Is it North American standard (X12), European (EDIFACT) or somewhere else (ERP, region or industry specific?)
What is the procedure for EDI testing to make sure things are working?
What is the penalty or potential impact if something goes wrong?
Who is the main point of contact for this project? Can I call them if something breaks?
Do I have an option of connecting directly or using a service provider?
Anything else that will affect our ability to integrate with each other?

EDI requirements document examples

The best way to understand EDI requirements documents is to read a few of them. Here are a couple of EDI requirements document examples from Tractor Supply Co. (TSC) and Designer Brands. Both of these documents are publicly available on their respective websites and we’ll link to them below.

Tractor Supply Co.

This EDI requirements document from TSC is meant for their dropshipping vendors. It breaks down which EDI codes are required by TSC and when they should be used.

Some key information shared in the document:

Standard format TSC uses for product information (UPCs).
Contact information for the EDI team
Transaction cadence for certain EDI codes (ex: EDI 846 transactions “must be sent Monday-Friday at least once a day).

Designer Brands

This EDI requirements document from Designer Brands is meant for all their vendors. It offers a good contrast to TSC’s requirements document because it has more requirements around its EDI transactions.

Some key information shared in the document:

Instructions on what vendors should do for failures related to inbound and outbound messages.
Resources on third-party EDI providers for vendors to handle their EDI implementation.
Requirements around functional acknowledgement messages (EDI 997). Ex: vendors are required to acknowledge receipt of purchase orders within 72 business hours with a 997 message.

Skip the need for EDI requirements documents with Convictional

A good EDI requirements document sets the stage for a successful EDI implementation. But even with a requirements document, EDI implementations take months to execute. They can also be difficult for your suppliers, especially modern DTC brands, to navigate. A document can’t guide your suppliers to rapidly get on board your marketplace or dropship program and it can’t hold your suppliers accountable to your requirements.

With Convictional, you can skip the need for creating an EDI requirements document. Our supplier onboarding platform enables your sellers to onboard in minutes, whether by syncing their Shopify or BigCommerce store or by connecting via EDI.

You can invite your suppliers to sync their products with a simple email link, after which your suppliers are guided through onboarding step by step. Retailers and brands that use Convictional, like Indigo and Sutro Footwear, have told us that it’s created a more positive supplier-retailer relationship for them.