SAP EDI integration comes down to five sequential steps:
- Define every business document you'll exchange and its SAP IDoc type (ORDERS05 for 850 POs, INVOIC02 for 810 invoices, DESADV for 856 ASNs)
- Configure communication ports via WE21 for each transport channel (AS2, FTPS, VAN mailbox)
- Map EDI standards to SAP IDoc fields using a certified mapping tool
- Configure partner profiles via WE20 for every active trading partner
- Test across unit, integration and live partner exchange phases before go-live, with WE02/WE05 monitoring in place from day one
Mid-integration and stuck on a mapping or WE20 question? Ask us — this is our favorite subject. Start a conversation.
SAP EDI integration isn't just a compliance project. It's the foundation that determines whether order accuracy, invoice matching and shipment confirmation happen automatically or through manual data entry. Manufacturers who get it right stop rekeying data between EDI and SAP, stop losing paper trails and stop eating chargebacks caused by manual entry errors.
This guide walks through the components in plain English, the five-step roadmap, the partner testing checklist that teams most often abbreviate under time pressure — and pay for later — and the pitfalls that generate the highest ongoing cost.
In this article
Key SAP EDI Components in Plain English
Five native SAP pieces do all the work. If you know what each one is responsible for, the rest of the setup makes sense:
| SAP Component | What It Does | Configuration Transaction |
|---|---|---|
| IDoc (Intermediate Document) | Standardized container format for each business document type — ORDERS05 for purchase orders, INVOIC02 for invoices, DESADV for ASNs | WE30 (IDoc type maintenance) |
| BAPI (Business Application Programming Interface) | SAP's API interface for external systems to read or write SAP data — used for custom workflows beyond standard IDoc processing | SE37 (function module maintenance) |
| Partner Profiles | Which IDoc types to process for each trading partner, with inbound/outbound message type assignments and error handling rules | WE20 |
| Mapping and Translation | The conversion layer between X12/EDIFACT standards and SAP IDoc fields (outbound: ORDERS05 to 850; inbound: 856 to DESADV) | External mapping tool or SAP PI/PO |
| Communication Ports | The transport channels that move documents between SAP and partners — AS2, FTPS, HTTPS, VAN mailbox | WE21 |
The Five-Step SAP EDI Integration Roadmap
1. Define every business document and its IDoc type
Start with a complete inventory of every EDI document you'll exchange — at minimum the 850 purchase order (ORDERS05), 810 invoice (INVOIC02) and 856 ASN (DESADV), plus anything partner-specific. For each one, confirm the required fields, formats and protocols against each trading partner's written specification before mapping begins. The partner's implementation guide is what you build against, not an assumption about what "standard" means.
2. Configure communication ports via WE21
WE21 creates the port for each delivery channel. AS2 with digital signatures and MDN delivery receipts is the right choice for most major retailers and OEMs, where non-repudiation is a compliance requirement; VAN mailbox ports need credentials from your VAN provider. Have IT review firewall rules and security controls for every external endpoint before a port goes to production — a misconfigured cloud connection or exposed BAPI endpoint is a data exposure waiting to happen.
3. Map EDI standards to IDoc fields, outbound and inbound
Mapping defines how each field in a partner's EDI document translates to the corresponding IDoc field and back. Each unique message type and partner combination needs its own map, but once built, it reuses for every transaction with that partner until the partner changes its implementation guide.
This step carries the biggest long-term cost implication of the whole project, and it won't be visible until the first spec update or SAP upgrade after go-live. Certified connector mappings handle those changes as configuration tasks. Custom ABAP middleware handles them as development projects — every single time. If you make one architectural decision deliberately, make this one.
4. Configure partner profiles via WE20
WE20 creates a profile for every company in your EDI network: the partner type (Customer, Vendor, Logical System), the inbound and outbound message types assigned to that partner, and the error handling codes for reprocessing, archiving and exception routing. For partners that need BAPI integration — custom approval workflows or real-time data retrieval — configure and secure the relevant endpoint before any live traffic touches it.
5. Test in phases: unit, integration, live partner exchange
Unit tests confirm each mapping in isolation (does field X in the EDI document land in field Y of the IDoc). Integration tests track full sample transactions through SAP, out to the VAN and into the partner's system. Live partner testing exchanges test documents for every message type and confirms 997 or CONTRL acknowledgments flow in both directions. Monitoring via WE02 or WE05 runs throughout testing and then becomes your production monitoring layer.
Partner Testing: The Checklist You Cannot Skip
Step 5 deserves its own section because it's the step most consistently squeezed when a go-live date is looming — and it's where the most expensive post-go-live problems are born. Before switching any partner to production:
Pre-Go-Live Partner Testing Checklist
- Confirm all partner identifiers (GLN, DUNS, SAP codes) match between your partner profile and the partner's EDI system — mismatches fail silently, showing up as missing documents rather than error codes
- Exchange test documents for every message type in both directions — a working outbound flow tells you nothing about the inbound one
- Test the failure paths on purpose: send documents with missing mandatory fields, simulate transport errors, submit duplicates — production will do all of this eventually
- Get written signoff from each partner; "the test files looked fine" on a phone call is not a record you can point to when a dispute surfaces later
- Agree on a joint go-live date with a confirmed fallback to the previous EDI method if a critical issue appears in the first production cycle
- Have WE02/WE05 monitoring configured and routing exceptions to the right people before the first live document, not after the first missed one
Partway through an SAP integration and something isn't behaving — an IDoc stuck in error status, a partner test that won't pass? Ask us. We troubleshoot this stuff daily. Tell us what you're seeing.
Common SAP EDI Integration Pitfalls
| Pitfall | How It Generates Cost | Prevention |
|---|---|---|
| Incomplete or outdated mapping | One mismapped field corrupts every transaction until corrected; if a partner updated its guide, every shipment in the gap window can generate a chargeback | Certified connector mappings updated when partners publish spec changes; provider-managed spec monitoring |
| Insufficient archiving | Most manufacturing compliance, SOX and audit obligations require 7-year retention — gaps get discovered during an audit, when reconstruction is impossible | A 7-year secure archive included as a standard feature of your EDI subscription, not a premium add-on |
| Lack of real-time visibility | Missing documents get discovered from partner escalations or chargeback notices — after the response window has closed | WE02/WE05 monitoring before go-live, plus real-time dashboards with exception routing to the right team member |
| Per-message or mapping change fees | Creates a financial disincentive to keep maps current — teams end up weighing an update fee against chargeback risk, a trade-off that shouldn't exist | Per-partner flat pricing with mapping changes included in the subscription |
Planning an SAP EDI integration, or living with one that's become a maintenance burden? Talk to us. We've been doing this for more than 25 years, our SAP IDoc connectors are certified for all major versions, and the conversation costs nothing — no demo required.
Let's talk SAP EDIFrequently Asked Questions
What is an IDoc in SAP EDI integration and which IDoc types are most commonly used?
An IDoc (Intermediate Document) is SAP's standardized container format for business documents — the structure SAP uses to represent each document type for exchange with external systems. The most common types in manufacturing EDI are ORDERS05 for purchase orders (inbound 850), INVOIC02 for invoices (outbound 810), DESADV for advance ship notices (outbound 856) and ORDRSP for PO responses (outbound 855).
What is the difference between WE20 and WE21 in SAP EDI setup?
WE21 configures the ports — the AS2 endpoints, FTPS connections and VAN mailboxes that physically move EDI documents between SAP and trading partners. WE20 configures the partner profiles — which IDoc types to process for each partner, in which direction and what happens when processing fails. WE21 is how documents travel; WE20 is which documents go to which partner.
When should BAPI integration be used instead of standard IDoc processing?
Use BAPIs when the requirement involves custom business logic that standard IDoc processing can't handle — multi-step approval workflows triggered by EDI events, real-time retrieval from SAP modules the standard IDoc doesn't include, or external applications that need to write data back to SAP. For standard document exchange (PO in, invoice and ASN out), IDoc processing through certified connectors is the lower-maintenance choice.
How should SAP EDI IDoc errors be monitored in production?
SAP's native tools WE02 (IDoc overview with status filtering) and WE05 (IDoc list with partner and message type filtering) provide real-time IDoc status visibility, direct reprocessing of recoverable errors and an audit trail. Supplement them with real-time alerts from your EDI VAN platform so the right person is notified when an IDoc errors, instead of relying on someone remembering to check the logs.
