EDI

EDI Translation: X12 & EDIFACT Expert Guide 2026

Learn how EDI translation works for X12 and EDIFACT standards. Covers segments, elements, mapping, and automation tools. Complete expert guide for 2026.

Samadhi Kariyawasam

Samadhi Kariyawasam

Published: 09 Mar 2026

Blog image

Electronic Data Interchange (EDI) is an integral part of modern B2B data exchange, enabling organizations to transmit business documents such as invoices, purchase orders, and shipment notices in a structured, machine-readable format. However, raw EDI files are not designed to be human-friendly or much flexible. This is where EDI translation comes in.

EDI translation is the process of converting structured EDI messages into formats that internal applications can understand (such as JSON, XML, database records etc) or to human readable formats, and vice versa. It acts as a bridge between trading partners that may use different systems, data models, or EDI standards, ensuring that business data flows accurately and consistently across organizational boundaries.

Among the various EDI standards in use today, X12 and EDIFACT are the two most widely adopted. ANSI X12 is primarily used in North America and defines transaction sets for industries such as retail, healthcare, logistics, and finance. EDIFACT, developed under the United Nations, is widely used across Europe, Asia, and global supply chains.

Understanding how EDI translation works is essential for building reliable integrations, maintaining compliance, and scaling B2B operations in 2026 and beyond. This guide breaks down the fundamentals of EDI translation and explores how to work effectively with both X12 and EDIFACT standards.

For any EDI standard, the key to translating a document is the “EDI specification”, a document that defines the EDI data structure and details of the segments and elements for the particular EDI type. A segment is a structured unit of data within an EDI file that represents a particular business concept or piece of information, while a data element is an individual field within a segment that holds a specific value.

X12 Standard

Segment

In X12 standard each segment is identified by a unique segment identifier like ISA, GS, ST, BIG, REF, N1, FOB etc. Segments are separated by a segment terminator, which is commonly a tilde (~) or a newline character. In addition to their position in the transaction, segments have several attributes that control how they are used:

  • Requirement: Indicates whether the segment is Mandatory, Optional, or Conditional, as defined by the EDI standard.
  • Max Use: Specifies how many times the segment may repeat at a given position.
  • Usage: Allows trading partners to tighten requirements. For example, an optional segment can be marked as Must Use. Segments labeled as Used or Recommended are generally optional but may become required depending on business rules or conditions.

Special Segments

There are some special segments in X12 standard that can be found in any EDI document irrespective of the EDI type.

  • ISA (Interchange Control Header) – Starts the interchange and defines sender, receiver, date/time, version, and control information.
  • IEA (Interchange Control Trailer) – Closes the interchange and validates it using control counts and reference numbers.
  • GS (Functional Group Header) – Begins a functional group of related transaction sets (e.g., invoices, purchase orders).
  • GE (Functional Group Trailer) – Ends the functional group and confirms the number of included transaction sets.
  • ST (Transaction Set Header) – Marks the beginning of an individual transaction (such as 810, 850, etc.).
  • SE (Transaction Set Trailer) – Ends the transaction and provides the segment count for validation.

Element

Each segment is made up of elements that carry qualifiers, values, or descriptive information related to that segment. Every element has a defined data type and an associated value. Similar to segments, elements are separated using an element separator, which in most cases is the asterisk (*) character.

Each element is assigned a unique reference, formed by combining the segment identifier with the element’s position within the segment. This reference helps clearly identify each data element within the EDI message.

Sample X12 EDI Translation

With that information let’s translate a few segments of this sample EDI, to a more human readable format.

ISA*00*          *00*          *12*SENDERID       *12*RECEIVERID     *240126*1230*U*00401*000000001*0*P*>~
GS*IN*SENDERID*RECEIVERID*20260126*1230*1*X*004010~
ST*810*0001~
BIG*20260126*INV12345**PO67890~
N1*BY*BUYER COMPANY*92*12345~
IT1*1*10*EA*25.00**VP*ABC123~
TDS*25000~
SE*6*0001~
GE*1*1~
IEA*1*000000001~

The segments in the EDI file can be translated like,

BIG Segment

Contains information like invoice date, invoice number, and related PO. The BIG segment in the sample EDI can be translated to a human readable format as below.

{
  "invoiceDate": "2026-01-26",
  "invoiceNumber": "INV12345",
  "poNumber": "PO67890"
}

N1 Segment

Contains buyer information such as name, address. The below can be a sample translation of the N1 segment.

{
  "entityIdentifierCode": "BY",
  "name": "BUYER COMPANY",
  "identificationCodeQualifier": "92",
  "identificationCode": "12345"
}

For each segment you have to refer back to the specification and translate the EDI file to your desired format.

EDIFACT Standard

Segment

In the EDIFACT standard each segment is identified by a unique three-letter code like UNA, UNB, UNH, BGM, DTM, NAD, LIN, QTY, UNT, UNZ etc and is made up of one or more data elements that carry specific information. Segments are separated using a segment terminator, most commonly the apostrophe (‘).

Special Segments

There are some special segments in EDIFACT standard, that can be found in any EDI document irrespective of the EDI type.

  • UNA - An optional segment to define the separators used within the EDI file, if not specified the file will use the default separators defined by the standard.
  • UNB - Interchange header which defines the envelope of the EDIFACT message and contains information about the sender and receiver.
  • UNH - Message header indicates the start of a message and contains metadata that helps identify and process the message.
  • BGM - Beginning of the message segment with key details like document type, number and message function.
  • UNT - The message trailer that signals the end of the message and provides control information used for validation, including the segment count and message reference number.
  • UNZ - The interchange trailer that closes the EDIFACT envelope initiated by the UNB segment.

Element

Similar to X12 standard an element in EDIFACT standard also refers to a specific value within the segment. Within a segment, individual data elements are usually separated by the plus (+) character, while sub-elements within a composite data element are separated by the colon (:) character.

Sample EDIFACT EDI Translation

With that information let’s translate a few segments of this sample EDI, to a more human readable format.

UNA:+.? '
UNB+UNOA:1+SENDERID+RECEIVERID+20260126:1230+1'
UNH+1+INVOIC:D:96A:UN'
BGM+380+INV12345+9'
DTM+137:20260126:102'
NAD+BY+12345::92+BUYER COMPANY'
LIN+1++ABC123:VP'
QTY+47:10'
MOA+203:250.00'
UNT+9+1'
UNZ+1+1'

The segments in the EDI file can be translated like,

LIN Segment

Describes a line item and its configuration. The LIN segment can be translated to JSON as below.

{
  "lineNumber": 1,
  "assignedIdentification": "",
  "productId": "ABC123",
  "productIdType": "VP"
}

QTY Segment

Describes the quantity of the item. The QTY segment can be translated to JSON as below.

 {
  "quantityQualifier": "47",
  "quantity": 10
}

MOA Segment

Describes the monetary amount. The MOA segment can be translated to JSON as below.

{
  "amountQualifier": "203",
  "amount": 250.00
}

Since these 3 segments represent a line item they can be combined as,

'LineItems': [
            {
                'LineItem': {
                    "lineNumber": 1,
                    "assignedIdentification": "",
                    "productId": "ABC123",
                    "productIdType": "VP"
                },
                'Quantity': {
                    "quantityQualifier": "47",
                    "quantity": 10
                },
                'MonetaryAmount': {
                    "amountQualifier": "203",
                    "amount": 250.00
                }
            }
        ]
                  ],

Similar to X12 standard, the EDI specification should be referred back and forth for each segment to translate the EDI file manually.

Challenges in Translating EDI Using Specifications

While EDI specifications define the structure and rules for each transaction, translating an EDI file in practice is often more complex than simply following the standard. Specifications can be large, highly detailed, and vary by version, industry, and trading partner. Optional and conditional segments may become mandatory based on business rules. Manually translating an EDI file with only the specification at hand would be a nightmare, demanding deep knowledge of the standard, careful interpretation of qualifiers, and constant cross-referencing of segment rules. This is where an EDI translation software would be a lifesaver, to take over the heavy lifting of this EDI translation and give a more simple and interpretable translation of the EDI file.

How does EDI Generator make things Easier?

EDI Generator, with the help of EDI definition; a set of rules created with the use of the EDI specification, translates the EDI to a more user friendly format, that can be viewed or printed. This makes it much easier to understand and work with EDI data without constantly referring back to the specification.

It also removes the need to manually construct EDI files. Users can simply fill out a form or provide data in a familiar format, and the EDI Generator takes care of creating a valid EDI message behind the scenes. This approach reduces errors and saves time, especially for teams that do not work with EDI on a daily basis.

As an additional capability EDI Generator can automatically convert incoming EDI messages into predefined JSON or XML formats and send them directly to internal systems for further processing. In the opposite direction, they can accept JSON or XML data from internal applications, generate the corresponding EDI messages, and deliver them to trading partners as part of a fully automated workflow. The EDI Generator team creates a customized EDI mapping for each customer, to provide a more tailored service for each use case.

By handling the technical complexity of EDI formats, EDI Generator allows teams to focus on core business processes rather than spending time managing EDI rules, separators, and specifications.

Sign up to enjoy the benefits of EDI generator for 1 month for free. Start EDI Generator free trial.

Samadhi Kariyawasam

Samadhi Kariyawasam

Samadhi is a Software Engineer at Aayu Technologies with around 1 year experience in the company during which she worked in various Aayu products. She specializes in Full Stack Development with a strong focus on B2B communication software and Cloud Technologies. Outside of work she enjoys watching a movie or a TV show or going on a shopping spree with friends.
Talk to an EDI Expert
Stay Compliant. Stay Connected. Powered by AS2.

Join hundreds of organizations already taking full control of their B2B AS2 communications with our trusted solutions. Contact us today to tailor a solution that fits your specific AS2 EDI needs.

Request a demo and take a live look at all the features of our AS2 EDI solutions.
Get answers to your questions and explore customizations that we can offer tailored specifically for you.
Get to know the dedicated deployment option available for your specific use cases.
Loading...
Please wait...

We're processing your request

Related Articles

View All Blogs
EDI Generator
Cloud-Based EDI Solution with AS2 Integration
Aayu logomark
Driving Innovation, Simplifying Connections.
EDI via AS2
30-day Free Trial
Secure and Compliant