# SAP EDI Integration: Trading Partners, IDocs, and the Integration Suite Path

SAP EDI integration is how SAP exchanges B2B documents such as purchase orders and invoices with trading partners. Classic SAP maps each EDI message to an IDoc; the modern path uses SAP Integration Suite Trading Partner Management and B2B adapters to translate EDIFACT and ANSI X12 into SAP formats. The hard part is onboarding partners and mapping each one's dialect of the same standard.

Every EDI project looks simple on the architecture slide. A trading partner sends a purchase order, SAP creates a sales order, everyone goes home early. Then two companies that both claim to use the ANSI X12 850 turn out to disagree about which segments are mandatory, and the weeks disappear into reconciling that.

I've spent the better part of a decade on integration work in the Salesforce ecosystem, and B2B document exchange has the same failure mode everywhere. The standard is never as standard as the spec sheet promises. So this guide spends less time on what EDI is and more on where SAP EDI projects actually stall.

EDI, electronic data interchange, is the exchange of structured business documents between companies in a machine-readable format, so a buyer's system can send a purchase order straight into a supplier's system without anyone rekeying it. In an SAP context, EDI integration means getting those documents in and out of SAP as the sales orders, deliveries, and invoices your business processes already understand.

There are two ways SAP does this. The classic approach maps each inbound EDI message to an IDoc, SAP's internal document container, and processes it through the ERP. The modern approach runs the translation and connectivity in SAP Integration Suite, using Trading Partner Management to hold the partner setup and B2B adapters to move the files. Most large SAP estates run a mix of both, because the classic IDoc plumbing rarely gets ripped out just because a cloud option arrived.

An IDoc, or Intermediate Document, is a standardized SAP structure for a business object. A purchase order lands as an ORDERS IDoc, an invoice as an INVOIC IDoc, a shipping notice as a DESADV IDoc. SAP has carried these message types for decades, which is why so much EDI still flows through them.

The classic flow looks like this:

1. A converter translates the EDI file. An EDI subsystem or middleware takes the raw EDIFACT or X12 file from the value-added network and turns it into the matching IDoc structure.

2. SAP receives the IDoc through a port and partner profile. The partner profile, configured in transaction WE20, tells SAP which message types this partner sends, which process code handles them, and where they route.

3. The IDoc posts the business document. A valid inbound ORDERS IDoc creates a sales order; an outbound INVOIC IDoc generates the EDI invoice back to the partner.

The strength of this path is that once an IDoc is valid, the rest of SAP already knows what to do with it. The weakness is everything upstream of that. The translation, the partner profiles, and the error handling live in a subsystem that few people fully own, and a malformed IDoc fails quietly in a queue until someone goes looking.

The cloud path moves the translation and connectivity into SAP Integration Suite. Trading Partner Management, usually shortened to TPM, is where you store each partner's identity, agreements, and the type system that describes their documents. B2B adapters handle the transport over AS2 or SFTP, and a Cloud Integration flow carries the message from the partner through the mapping and into SAP.

The practical difference is where the setup lives. Instead of a partner profile buried in the ERP and a separate converter box, the partner agreement, the mapping, and the connectivity sit together in one managed place with monitoring you can actually read.

Source: appnigma.ai integration practice, 2026, mapped against Trading Partner Management capabilities documented in the SAP Help Portal.

Two standards cover most SAP EDI work. EDIFACT is the international standard, common across Europe and global logistics. ANSI X12 is the North American standard. They describe the same business documents with different names and structures.

Source: standard EDI message directories, cross-referenced to SAP IDoc basic types.

Pro Tip

Two partners can both send you a valid X12 850 and still fail your import for different reasons. One puts the buying party in an N1 loop you expected; the other uses a version you didn't map. The standard is a starting point, not an agreement.

Here is where the real cost sits. A partner running X12 version 4010 and a partner running 5010 will structure the same purchase order differently. One marks a segment mandatory that another leaves out. One sends quantities in a unit of measure your material master does not recognize. None of that shows up until you test with their actual files, which is why partner dialects, not the standard itself, drive the timeline.

The technology is rarely what makes an SAP EDI rollout slow. Onboarding each trading partner is. Every new partner is a fresh agreement, a fresh mapping, and a fresh test cycle, and they repeat for every partner you add.

A workable onboarding sequence:

1. Exchange specs and sample files. Get the partner's implementation guide and, more importantly, real sample documents, not the clean textbook example.

2. Build the map against their dialect. Start from a reusable base map for the standard, then adjust for this partner's segments, qualifiers, and version.

3. Set up connectivity. AS2 certificates or SFTP credentials, exchanged and tested before any business document moves.

4. Test with production-like documents and get sign-off. Run the partner's real samples end to end and confirm the posted SAP document is correct.

The step that always slips is the fourth one. Getting real sample files and a sign-off from the partner's EDI team depends on their schedule, not yours, and it is the single most common reason an EDI go-live moves a week to the right. You cannot fully remove that dependency, but you can shrink it: keep a reusable base map per standard, keep a test harness that replays sample files, and keep a partner onboarding checklist so nothing waits on tribal knowledge.

For where EDI fits among the broader connection styles, our guide on the four types of integration sets the context, and Salesforce integration patterns and best practices covers the monitoring and error-handling discipline that keeps document flows from failing silently. If your EDI feeds ERP order and billing data, the Salesforce ERP integration guide walks the object model on the receiving side.

What is SAP EDI integration? SAP EDI integration is the electronic exchange of structured B2B documents, such as purchase orders and invoices, between SAP and external trading partners. SAP either maps each EDI message to an IDoc for processing in the ERP, or handles the translation and transport in SAP Integration Suite using Trading Partner Management and B2B adapters.

How does SAP handle EDI? Classic SAP uses an EDI converter to translate EDIFACT or ANSI X12 files into IDocs, which post as sales orders, deliveries, or invoices through partner profiles configured in transaction WE20. The modern approach runs translation and connectivity in SAP Integration Suite, where Trading Partner Management stores the partner setup and B2B adapters move files over AS2 or SFTP.

What is Trading Partner Management in SAP? Trading Partner Management is the capability in SAP Integration Suite that stores each trading partner's identity, agreements, and document type system in one place. It pairs with B2B adapters and the built-in EDI converter so partner onboarding, mapping, and connectivity live together with central monitoring, rather than being spread across ERP partner profiles and a separate converter.

Does SAP use IDocs for EDI? Yes. IDocs are SAP's long-standing internal format for EDI, and message types like ORDERS, DESADV, and INVOIC map directly to common EDI documents. Even in cloud-based setups using Integration Suite, the final document is often still posted into SAP as an IDoc, because the rest of the ERP already knows how to process it.

About the author. Sunny Chauhan is the founder of appnigma.ai, where we build native Salesforce apps and integrations without glue code: direct, observable connections instead of a stack of hand-maintained callouts. He's a Salesforce-certified Platform Developer II who spent the better part of a decade building integrations and managed packages, including work at Zennify and Salesforce, before founding appnigma. The lesson that carries across CRM and ERP work is the same one EDI teaches: the standard is never the whole story, and the partner's real data is.

Which of your trading partners took the longest to onboard, and was it the mapping or the sign-off that held it up?