SAP EDI Basics - Electronic Data Interchange

Getting Started with SAP EDI (Electronic Data Interchange) Integration

The information you need to be successful with SAP EDI Integration

Electronic Data Interchange (EDI) integration with SAP is a critical step for businesses looking to streamline supply chain processes, reduce manual effort, and ensure data accuracy across partners. Whether you're new to SAP or just beginning to explore EDI, this guide covers foundational concepts and frequently asked questions. From understanding IDocs to requirements for partner setup, we’ll walk you through the essentials of making your SAP system EDI-ready.

EDI Basics

What is EDI?

Electronic Data Interchange (EDI) is the automated exchange of standardized business documents-like purchase orders, invoices, and shipping notices-between systems without human input. It replaces manual processes such as emails, faxes, and data entry, enabling real-time, error-free communication between trading partners. By integrating directly with ERP and supply chain platforms, EDI improves accuracy, speeds up transactions, and lowers operational costs.

What Types of SAP Business Documents Can Be Exchanged Using EDI Transactions

EDI supports the automated exchange of a wide range of business documents commonly used in procurement, order fulfillment, logistics, and finance. These include:

Purchase Orders (850): To initiate product or service orders.
Order Acknowledgments (855): To confirm receipt and acceptance of orders.
Advance Ship Notices (856): To communicate shipment details before delivery.
Invoices (810): For billing and payment processing.
Inventory Reports (846): To share stock availability and updates.
Payment Remittance Advice (820): To indicate completed or upcoming payments.
Shipping Instructions and Status Updates (940, 945): To manage warehouse operations and logistics.
Scheduling Agreement Forecasts and Releases (830, 862): To communicate the JIT shipping requirements

By automating these document flows, EDI ensures faster, more accurate transactions across supply chain, finance, and warehouse management operations-reducing manual effort and improving overall efficiency.

What Are Common EDI Standards and Transmission Protocols

EDI relies on standardized formats and secure transmission protocols to ensure consistent, automated communication between business systems.
Common EDI Standards include:

ANSI X12: Widely used in North America across industries like retail, logistics, and healthcare.
EDIFACT: An international standard commonly used in Europe and global trade.
VDA: Frequently used in the automotive sector, especially in Germany.
EANCOM and ODETTE: Adapted for retail and automotive supply chains in Europe.

Common Transmission Protocols include:

VAN (Value Added Network): Think of this as an online mailbox that routes EDI messages to the proper receiver
AS2 (Applicability Statement 2): A secure, internet-based protocol for real-time EDI exchange.
FTP/SFTP: File-based transfer over secure or standard networks.
HTTP/HTTPS: Often used for web-based or API-integrated EDI connections.
API/Web Services: Emerging protocols for real-time integration with cloud-based platforms.

Choosing the right combination of EDI standards and protocols ensures compatibility, security, and performance across your business network and trading partners.

Overview of EDI in SAP

Key Components of SAP EDI

SAP EDI integration relies on several core components that work together to automate data exchange:

IDocs (Intermediate Documents):These are structured electronic messages used to transfer data between SAP and other systems. IDocs are central to SAP's EDI processes, and are structured around standard business transactions.
Partner Profiles:These define how SAP communicates with each trading partner, specifying message types, processing rules, and technical details for inbound and outbound messages.
Ports: A port defines the connection point for sending or receiving IDocs, such as to an EDI subsystem or another SAP system.

Business Integration Points for EDI in SAP

EDI in SAP is tightly integrated with core business processes, enabling automated communication with external trading partners across various functional areas. Key integration points include:

Procure-to-Pay (P2P):Automates the exchange of purchase orders (ORDERS), order acknowledgments (ORDRSP), shipping notifications (DESADV), and vendor invoices (INVOIC) between SAP and suppliers.
Order-to-Cash (O2C): Supports customer-facing processes by sending order confirmations, delivery notes, and invoices to customers via EDI, streamlining sales and fulfillment workflows.
Logistics Execution:: Integrates with warehouse and shipping functions through IDocs for delivery processing, shipment notifications, and goods movement (e.g., DELVRY, SHPMNT).
Finance and Accounting: Facilitates EDI transmission of payment advice (REMADV), remittance details, and invoice reconciliation between SAP and financial institutions or vendors.
Master Data Synchronization: Allows exchange of material master data, customer/vendor master records, and pricing conditions to maintain consistency across systems and partners.

These integration points ensure that business transactions flow seamlessly and accurately between SAP and external systems, reducing manual effort and accelerating business cycles.

SAP EDI Configuration & Setup

What Are Message Types and How Do They Relate to IDocs?

In SAP EDI, a message type defines the kind of business document being exchanged-such as a purchase order (ORDERS), invoice (INVOIC), or delivery note (DELVRY). Each message type is linked to a specific IDoc type (or Basic Type), which determines the structure and format of the data being transmitted. When an EDI process is triggered, SAP uses the message type to identify which IDoc to generate or interpret, ensuring the correct data is sent to or received from a trading partner. This mapping is essential for the smooth processing of business transactions across systems.

How are SAP Partner Profiles Used?

In SAP, partner profiles are used to route data in and out of the system and associate them with a specific partner (i.e. customer, vendor etc.). You need to set them up to enable inbound and outbound documents of certain types such as orders or invoices to flow into and out of the system. If they are not set up with the right data, you can't post IDOCs to create business documents, nor can you output the necessary data to your EDI subsystem.
They contain a few components:

Partner Number and Type: This links back to your SAP Business Partner number. The type will say if it's a customer (KU), vendor (LI) etc.
Inbound Parameters: The key piece of the inbound parameters tell the system how to receive your inbound IDOC. What type to expect and what process code - linked to a function module - will be used to process your IDOC data.
Outbound Parameters: Similar to inbound parameters, these tell SAP what kind of IDOC you want to generate, described by things like the message type and process code. Also, where to send it (the port). You can add other parameters in here that might be used by your EDI subsystem under the EDI Standard tab

Monitoring and Support

Where can you view errors and issues in SAP for inbound data?

The first place your inbound EDI data will get stuck is your EDI translation/subsystem. This will catch formatting errors in the EDI data as well as missing data for mandatory fields. If your data makes it into SAP as an IDOC, you will need to again check for errors there on a regular basis. The main transactions for doing so are WE02 and WE05. These allow you to filter and sort your IDOCs and look for those in error. For inbound, you want to focus on status 51 and 56 for errors and status 64 for documents waiting to be processed.

Where can you view errors and issues in SAP/EDI for outbound data?

There are several points along the process where your outbound data can error out:

Output fails to save on the document due to incorrect partner profile, missing condition record, or ABAP dump.
IDoc fails to generate or dispatch from SAP because of a connection issue or segment structure - typically caused by a customization
EDI translation fails in your middleware due to missing master data, mapping issues, or invalid values.
Communication to the trading partner fails-common causes include SFTP/AS2 connection issues or expired certificates.
Partner receives the data but rejects it, indicated by a failed 997, EDI 824/864, or direct feedback.

IDoc Structure: What’s Inside an IDoc?

Control Record (EDIDC)

The control record is like the envelope of the IDoc. It contains metadata that determines how the document is processed. The IDoc Type and Message type are found here along with fields like direction, date/time, IDoc number, status and port. This data is all stored in table EDIDC.

For incoming documents:

For inbound IDocs, the combination of message type and sender partner number is used to locate the correct partner profile (transaction WE20), which in turn determines the inbound process code and function module.
This will drive the process code selection determining how the data will be interpreted and processed.

Similarly for outbound:

The partner number and IDoc type will help your EDI system associate the IDoc with the right trading partner in order to map and send the data accordingly.

Data Records (EDID4)

This is the core data, stored in SAP in table EDID4 -hierarchically structured by segments and fields. Segment names follow a pattern:

Header data segments contain a 'K' (e.g., E1EDK01)
Item-level segments contain a 'P' (e.g., E1EDP01)
Summary or totals use an 'S' (e.g., E1EDS01)

Each segment has its own specific set of fields within that contain structured business data relating to that IDoc and maps to a specific business context-like invoice totals, reference numbers, or line items.

The data structure is able to loop and have child transactions. If a custom enhancement causes segments to appear out of their expected sequence, SAP may reject the IDoc with a structure error. Maintaining correct segment hierarchy is essential for successful processing.

Status Records (EDIDS)

Each IDoc has a processing history: every step adds a status record, stored in table EDIDS. Each status includes:

Numeric status code
Message class and number
Human-readable error or confirmation message

Status Code Ranges:

1–49: Outbound processing
50–99: Inbound processing


Status	Description
02	Error passing data to port
03	Data passed to port OK
16	Functional Acknowledgement positive
51	Application document not posted
53	Application document posted
56	IDoc with errors added
64	IDoc ready to be transferred to application

SAP EDI Software and Service Options

What’s the main difference between a Managed Service and handling EDI in-house?

In-house EDI means your team handles mapping, partner onboarding, monitoring, and troubleshooting internally. This requires specialized staff and constant training to keep up with changes. A Managed Service takes over these tasks entirely-monitoring transactions, resolving errors, onboarding partners, and ensuring compliance-so your internal team can focus on strategic projects instead of daily EDI firefighting.

How does a Managed Service compare to a cloud-only EDI solution?

A cloud EDI platform gives you hosted software and tools, but you still need staff to manage configuration, mapping, and error resolution. A Managed Service goes further-providing the platform plus an expert team to run it for you, proactively monitor, and fix issues before they disrupt operations. In short, cloud software is the tool, while Managed Service is the tool and the skilled operator.

Which option offers better scalability for growing transaction volumes?

In-house solutions can struggle to scale without adding more staff or infrastructure. Cloud platforms scale technically but still depend on your team’s bandwidth to handle increased complexity. Managed Services scale both the technology and the operational support-your provider absorbs the extra workload, so growth doesn’t create bottlenecks.

How does each model handle errors and partner changes?

In-House: Your team detects and fixes issues, often reacting after an error is reported.
Cloud-Only: The platform may flag errors, but resolution still falls to your internal staff.
Managed Service: The provider actively monitors transactions, diagnoses the root cause, fixes it, and reports back with a resolution-saving time and preventing repeated issues.