SAP EDI Integration: IDocs, 850 to Sales Orders

You run SAP. A retailer just told you they need EDI 850 purchase orders accepted, an EDI 856 ship notice back within 24 hours, and EDI 810 invoicing. Your SAP team knows IDocs and partner profiles. What they may not know is exactly how the X12 world plugs into that, and where the work actually lives.

SAP is not one product. Most existing deployments run SAP ECC (the older ERP Central Component), while newer projects run S/4HANA. Both process business documents internally as IDocs, and both need a translation layer to turn raw X12 EDI into IDocs and back. This guide walks through that mapping and how to handle orders that never arrive as EDI at all.

Does SAP Have Native EDI Support?

SAP does not parse raw X12 or EDIFACT files on its own. It processes IDocs, and a separate translation layer converts EDI to IDoc format. An IDoc (Intermediate Document) is SAP's structured container for exchanging business data. The EDI standard and the IDoc standard are different formats that describe the same transaction, so something has to sit between them.

That something is either SAP Process Orchestration (PI/PO), SAP Integration Suite on Business Technology Platform, or a third-party EDI translator that hands finished IDocs to SAP. The translator receives an X12 850 over AS2, SFTP, or a VAN, maps each segment to the matching IDoc field, and posts an inbound ORDERS IDoc. SAP then creates the sales order from that IDoc through the standard inbound processing function.

Raw EDI looks like a flat string of segments: ISA*00* *00* *ZZ*BUYERID *ZZ*SELLERID *260101*1200*^*00501*000000001*0*P*>~. SAP has no built-in step that reads that and knows it is a purchase order. The mapping to ORDERS05 is where the intelligence lives. If you want to see how the raw segments break down before they ever reach SAP, the free EDI Inspector parses any X12 file and shows the parsed structure with no signup.

How EDI Transactions Map to SAP IDocs

Each X12 transaction set has a corresponding IDoc message type and basic type in SAP. This mapping is the core of any SAP EDI project. Get it right and documents flow. Get it wrong and IDocs sit in error status waiting for someone to reprocess them.

Direction	X12 Transaction	IDoc Message Type	IDoc Basic Type	SAP Document
Inbound	850 Purchase Order	ORDERS	ORDERS05	Sales order
Outbound	855 PO Acknowledgment	ORDRSP	ORDERS05	Order confirmation
Inbound	860 PO Change	ORDCHG	ORDERS05	Sales order change
Outbound	856 Ship Notice (ASN)	DESADV	DELVRY07 / DESADV01	Outbound delivery
Outbound	810 Invoice	INVOIC	INVOIC02	Billing document
Inbound	820 Payment/Remittance	REMADV	PEXR2002	Incoming payment

The inbound 850 to ORDERS05 flow is the one most projects start with. The translator maps the retailer's buyer part numbers and UPCs to your SAP material numbers, sets the sold-to and ship-to partners, and posts the IDoc. SAP's inbound processing creates a standard sales order you can see in VA03. For the mechanics of the source document, our EDI 850 purchase order guide covers every segment a retailer can send.

Configuring Partner Profiles and Ports

SAP routes IDocs using partner profiles in transaction WE20 and communication ports in WE21. Every trading partner needs a profile that tells SAP which message types are inbound, which are outbound, and what process code and port to use for each. This is standard SAP EDI configuration, and it is where a lot of go-live delays hide.

The pieces your Basis and functional teams configure:

• Partner profile (WE20): defines the partner, the message types exchanged, and the process code that runs the posting logic.
• Port definition (WE21): the technical channel, usually a file port or an XML/tRFC port that connects to the middleware.
• Process codes: link a message type to the function module that creates the SAP document. ORDERS inbound uses process code ORDE, which calls IDOC_INPUT_ORDERS.
• Partner determination: maps the EDI partner identifiers to your SAP customer master records.

Monitoring is its own discipline. Your team watches individual IDocs in WE02 or WE05, and uses BD87 to reprocess IDocs that errored. An 850 that fails because a material number has no cross-reference sits in status 51 until someone fixes the mapping or the master data.

The Full Order-to-Cash Flow in SAP

A complete SAP EDI cycle moves an inbound purchase order through delivery and billing, generating outbound EDI at each posting step. Here is how the documents chain together for a distributor selling to a retailer.

1. Inbound 850: the retailer sends a purchase order. Middleware maps it to an ORDERS05 IDoc, SAP posts it as a sales order, and a 997 functional acknowledgment goes back to confirm receipt.
2. Outbound 855: if the retailer requires acknowledgment, SAP generates an ORDRSP IDoc from the sales order, and the translator sends an 855 confirming or flagging line changes.
3. Outbound 856: when you post the outbound delivery in SAP, a DESADV IDoc generates the EDI 856 ship notice with carton detail and SSCC-18 labels. Timing is strict, most retailers want the ASN before the truck arrives. Our EDI 856 ship notice guide covers the hierarchical structure retailers expect.
4. Outbound 810: after billing, SAP produces an INVOIC02 IDoc that becomes the EDI 810 invoice. Mismatches between the 810 and the original 850 drive payment disputes, so allowances and freight need to map cleanly.

For a broader view of how this sequence works across any ERP, see our overview of order-to-cash automation.

ECC vs S/4HANA: What Changes for EDI

IDocs still work in S/4HANA, but SAP now positions APIs as the primary integration path. ECC and S/4HANA both process ORDERS05, DESADV, and INVOIC02, so an EDI setup built on IDocs carries forward. What changes is the surrounding strategy and the migration clock.

SAP has stated that mainstream maintenance for SAP ECC ends in 2027, with extended maintenance available to 2030 (see SAP's maintenance strategy). That deadline is pushing distributors to plan S/4HANA migrations, and an EDI integration that assumes ECC-only behavior is a risk during that move.

S/4HANA is API-first. SAP publishes OData and SOAP APIs on the SAP Business Accelerator Hub covering sales orders, deliveries, and billing. Some newer integrations create sales orders through the Sales Order (A2X) API instead of an ORDERS IDoc. Both paths exist. IDocs remain fully supported for classic EDI, while the APIs open cleaner options for cloud middleware. For the broader tradeoff between the two models, our EDI vs API comparison breaks down when each fits.

SAP EDI Tcode Quick Reference

These are the transaction codes an SAP EDI administrator lives in. Bookmark them; every failed order investigation starts with one of these.

Tcode	What it does
WE20	Partner profiles: which partner sends which message type, and how each is processed
WE21	Port definitions: the technical channel (file, RFC, HTTP) IDocs move through
WE02 / WE05	IDoc lists: search and display IDocs by date, partner, message type, and status
WE19	Test tool: edit and reprocess a copy of a failed IDoc
BD87	Reprocess IDocs stuck in error status

A typical failure investigation runs WE02 to find the IDoc, checks the status record to see which step failed, WE19 to fix and retest the payload, then WE20 to correct the partner profile so the next transmission processes cleanly.

How OrderSync Connects Orders to SAP

OrderSync turns inbound orders in any format into SAP sales orders, then syncs deliveries and billing back out as EDI. The problem most SAP shops hit is not the EDI partners with clean IDoc feeds. It is the accounts that email a PDF purchase order or drop a spreadsheet, which still end up keyed by hand into VA01. To connect orders to SAP with OrderSync, see the SAP integration page.

OrderSync ingests EDI 850s, PDF purchase orders, emailed orders, and CSV files through one pipeline. It maps buyer part numbers to your SAP material numbers, validates quantities and pricing, and creates the sales order through the IDoc or API path your landscape uses. When you post the delivery and billing document in SAP, OrderSync generates the outbound 856 and 810 for the trading partner. PDF and email orders flow through the same automation.

That matters because most distributors have a long tail of smaller retail accounts that will never send EDI. See how the multi-format order pipeline handles them, and read more about the ERP integration approach for connecting SAP without a per-document VAN bill. We also cover NetSuite EDI integration and QuickBooks EDI integration in dedicated guides.

Frequently Asked Questions

What is an ORDERS05 IDoc in SAP?

ORDERS05 is the IDoc basic type SAP uses for purchase orders and sales orders. When an inbound EDI 850 arrives, the translation layer maps it to an ORDERS05 IDoc with message type ORDERS, and SAP's inbound processing creates a sales order from it. The same basic type carries ORDRSP acknowledgments and ORDCHG changes.

Does S/4HANA still use IDocs for EDI?

Yes. S/4HANA fully supports IDocs including ORDERS05, DESADV, and INVOIC02, so classic EDI integrations carry over from ECC. SAP also promotes OData and SOAP APIs on the SAP Business Accelerator Hub as an alternative path, and some new integrations use the Sales Order API instead of an IDoc. Both approaches are valid.

How do I monitor failed EDI IDocs in SAP?

Use transaction WE02 or WE05 to view individual IDocs and their status codes, and BD87 to reprocess IDocs stuck in error. An inbound 850 that fails on an unmatched material number sits in status 51 until the cross-reference or master data is corrected, then it can be reposted without asking the retailer to resend.

Where are EDI partner profiles configured in SAP?

Partner profiles live in transaction WE20, where you define each trading partner and the inbound and outbound message types they exchange. Communication ports are defined in WE21. Process codes link each message type to the function module that posts the SAP document, such as ORDE and IDOC_INPUT_ORDERS for inbound purchase orders.

Can OrderSync send SAP orders that did not arrive as EDI?

Yes. OrderSync processes EDI 850s alongside PDF, email, and CSV purchase orders through the same pipeline and creates SAP sales orders from all of them. Retail accounts that email a PDF or send a spreadsheet do not require a separate translator or manual keying, which removes the long tail of orders SAP EDI setups usually leave on the table.