Contents
The EDI integration process is broader than opening a connection between two systems. Under what conditions an order is generated, how product codes match, and who manages rejected messages are designed together. If these decisions are not made at the outset, even if technical connectivity works, the flow of orders, shipments, or invoices may not correspond properly within the enterprise.
A well-planned project progresses through seven steps from analysis to live monitoring. The output, owner, and acceptance criteria of each step are distinct. In this way, teams discover problems not in the production system, but in a controlled testing environment.
1. Determine the Business Goal and Project Scope
The first deliverable of the project is not a technical document, but a scoping decision. Which trading partners will be connected, which documents will be sent and received, and what business outcome is expected must be documented. Purchase orders, order confirmations, advance shipping notices, and invoices do not need to be included in the scope all at once.
IBM defines the first step of EDI implementation as defining the business goal. The organization's implementation guide also recommends limiting the scope across trading partners, transaction types, and data sources. This distinction prevents uncontrolled additions of new documents and partner requests during the project. IBM's EDI implementation guide also addresses the internal infrastructure across four layers: operating environment, connectivity, integration, and data management.
The following decisions should be recorded in the kickoff meeting:
- Trading partners in the first phase and their order of priority
- Document types to be sent and received
- Source ERP, WMS, or accounting system
- Acceptable rules for errors, latency, and reprocessing
- Decision owners on the business, IT, and trading partner sides
For an automotive supplier in Turkey, the first phase can start with orders and advance shipping notices. For a retail supplier, orders, despatch advices, and invoices may be a more appropriate starting package. Scope must be derived from actual document flows, not from industry titles.
2. Collect Trading Partner Requirements
Even if every business partner uses the same standard, they may require different fields, codes, and timing rules. Therefore, the team must obtain the counterpart's implementation guide file and test scenarios before mapping begins. Document version, mandatory fields, partner identifiers, connection protocol, and acknowledgment messages are clarified here.
IBM's EDI onboarding explanation cites three X12 transaction sets as common document examples: 850 Purchase Order, 810 Invoice, and 997 Functional Acknowledgment. In European and Turkish connections, EDIFACT or sectoral VDA messages may come to the forefront. MAP's OtoEDI page also lists IDOC, XML, CSV, and TXT conversion alongside EDIFACT and VDA support.
The requirements list should not consist solely of file formats. The uniqueness of order numbers, currency codes, units of measure, date formats, and the procedure to follow for unknown product codes must also be documented. The counterpart's testing environment, contact person, and response turnaround time should be added to the project timeline.
3. Establish the Integration Architecture and Connectivity
The architectural decision determines how the EDI platform communicates with the ERP and through which path the message travels to the trading partner. In internal connectivity, APIs, file transfers, or database integrations can be used. In external communication, AS2, SFTP, OFTP2, or another protocol accepted by the trading partner can be selected.
IBM's onboarding guide describes four common communication options: AS2, SFTP, MFT, and SOAP. The selection should be made based on security, delivery notification, certificate management, existing infrastructure, and partner requirements. The protocol decision alone is not sufficient. Endpoints, certificates, IP permissions, file naming conventions, execution frequency, and retry policies must also be included in the connection documentation.
An organization can manage these layers with its own team or use a service provider. MAP's B2B/EDI integration page should be the owner of the commercial solution aimed at the automated exchange of business messages such as orders and invoices between ERP systems.
4. Prepare Source Data Before Going Live
A mapping table cannot fix unclean source data. Maintaining the same product under two codes, missing tax information, or inconsistent address fields will generate rejections in testing. The team must examine master data and document generation rules in the ERP prior to EDI transformation.
IBM identifies poor data quality as one of the common challenges in the EDI onboarding process. Duplicate records, missing fields, and inconsistent tags can delay the validation step. Even the simple date example in the organization's guide demonstrates the difference: sending a free-text date while standard YYYYMMDD is expected can lead to file rejection.
In data preparation, at least the following checks should be conducted:
- Are customer and supplier codes unique?
- Does the internal product code match the partner's SKU?
- Do unit, country, and currency codes conform to accepted code lists?
- Are mandatory tax, address, and shipment fields populated?
- Are exceptions such as cancellations, partial shipments, and price differences defined?
This work cannot be left to the IT team alone. Sales, logistics, finance, and master data owners must confirm the accuracy of their respective areas.
5. Develop EDI Mapping and Business Rules
EDI mapping converts fields in the internal system into the target message structure. A material_code in an ERP may be expected as SKU on the other side. A field may be mandatory for some partners and optional for others. Therefore, a versioned mapping definition is required for each trading partner.
IBM describes mapping work as the section that cuts across all four infrastructure layers of EDI implementation and often consumes the most time. The counterpart for each field within the implementation guide is found; constant values, code translations, and conditional rules are written separately. If change history is not maintained, a new partner rule can break an existing, functioning flow.
The mapping document should contain source fields, target fields, transformation rules, mandatory status, sample values, and error behaviors. Instead of maintaining the same business rule separately across code, emails, and Excel files, a single controlled source should be used. Mapping approval must be obtained from the business unit using the document alongside the technical developer.
6. Test the End-to-End Process, Not Just the Document
A test file reaching the counterpart does not prove that the integration is ready. The file must be parsed correctly, create the proper record in the ERP, and generate the necessary acknowledgment message in return. Subsequently, exceptions such as cancellations, missing fields, incorrect codes, retransmissions, and connection dropouts must be tested.
IBM's onboarding model divides testing into four categories: connectivity, validation, single transaction, and full flow. A single transaction test shows that the message travels back and forth. A full flow test validates the chain from the moment the order hits the ERP down to shipment and invoice steps. In scenarios using X12, the 997 message is one of the technical proofs indicating document acceptance or rejection status.
The test plan should include expected results, actual results, responsible owners, and evidence records for each scenario. Production connections should not be opened before joint acceptance with the trading partner. If a supplier in Turkey is also using the e-invoice process within the same flow, the responsibilities of the EDI document and the financial document should not be confused.
7. Go Live in a Controlled Manner and Monitor Messages
Going live is not a single date, but a controlled operating period. Initial messages can be compared manually; volume and the number of trading partners can be increased gradually. When the legacy channel will be decommissioned and the rollback plan must be determined before starting.
MAP states on its website that it collects, processes, and distributes 150 million EDI messages annually. An operation at this scale relies not only on message transmission, but on a visible error and reprocessing framework. MAP's corporate EDI data also publishes information regarding over 1,500 clients and 30 years of EDI/B2B integration experience.
The monitoring dashboard should display at least sent, received, pending, rejected, and reprocessed messages. Who receives alerts, for which error the business unit steps in, and how mappings are updated when partner rules change must be defined. First-month metrics should be part of project acceptance.
Conclusion
The success of an EDI integration is measured not on the day connectivity is opened, but by the accurate processing of actual business documents. Scope, partner requirements, source data, mapping, and test evidence must be completed before going live. In production, message status, error ownership, and change management must remain visible.
To evaluate the approach suitable for the trading partners, documents, and ERP structure in your organization, you can explore the MAP B2B/EDI Integration page. You can access other content related to EDI and supply chain digitalization via MAP Blog.
