Document standards are an essential part of electronic data interchange (EDI). In short, EDI standards (aka EDI file formats) are the specific guidelines that govern the content and format of B2B documents such as orders, invoices and order responses. These documents are then sent via EDI protocols to the service provider / business partner.
How EDI file formats work
Sending documents according to an EDI standard ensures that the machine receiving the message is able to interpret the information correctly as each data element is in its expected place. Without such standards the receiver’s system will be unable to identify what part of the message is what, making automated data exchange impossible.
Although EDI documents may seem like a random mix of letters and symbols, all EDI messages conform to very strict rules. Typically EDI standards are based on the following four principles:
Syntax rules determine what characters can be used and in what order.
Codes are used to identify common information such as currencies, country names or date formats.
The message design defines how a particular message type (e.g. invoice or purchase order) is structured and what subset of rules from the prescribed syntax it uses.
The means by which values in an EDI file are identified, e.g. by its position in the file or via the use of separators. These changes from standard to standard.
Most EDI standards also include the following three components:
- Elements – The smallest part of a message, providing submitted values (e.g. “50” or “KGM” or “Potatoes”)
- Segments – A collection of elements or values logically combined to provide an information (e.g. Quantity 50 kilograms of potatoes)
- Transaction sets – A collection of segments, composing a message (e.g. an Invoice for the sale of 50 kilogram of potatoes)
Essentially different formats are like different languages, with the elements and segments of a certain standard mirroring the words and sentences of a regular language.
A brief history of EDI document standards
In the very early days of EDI it quickly became evident that document standards were required to avoid confusion and improve the efficiency of even paper-based supply chain communication. Following the advent of file transfer between computers (FTP) becoming possible, in 1975 the very first EDI standards were published by the Transportation Data Coordinating Committee (an organisation formed by US automotive transport organisations in 1968). In 1981 the American National Standards Institute then published the first multi-industry national standard, X12. In turn this was followed by the creation by the UN of a global standard, EDIFACT, in 1985.
No one attempt to unify standards has ever been completely successful, however. As technology has evolved and industry specific needs have become increasingly disparate, new standards have steadily been introduced over the decades. Somewhat counterintuitively, therefore, today there is no such thing as a single all-encompassing EDI standard for every document type. Instead, businesses choose their preferred document standard from a number of options (usually opting for the one most widely used in their industry). When trading with partners using different standards, businesses then have to ensure that their messages are correctly converted to the recipient’s required format. This process is called mapping.
The 5 most used EDI file format standards:
The most popular EDI file format standard today outside North America is UN/EDIFACT, which stands for United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport. These international B2B message guidelines are extremely widely used across many industries.
In fact, given the scope of EDIFACT’s adoption, several industries have developed subsets of the main standard which allow for automation of industry-specific information. One well-known subset is EANCOM, for example, which is used in the retail industry.
EDIFACT document file types are identified by a six letter reference. For example, three of the most common of these references are:
- ORDERS (for purchase orders)
- INVOIC (for invoices)
- DESADV (for despatch advice)
All of these EDIFACT messages have the same basic structure, consisting of a sequence of segments:
- UNA – separators, delimiters and special characters are defined for the interpreting software
- UNB – file header (with the file end UNZ this makes up the envelope, containing basic information)
- UNG – group start
- UNH – message header
- UNT – message end
- UNE – group end
- UNZ – file end
Example EDIFACT order
As well as transmission format, the EDIFACT standard also defines delivery requirements. EDIFACT provides set guidelines, for example, concerning the exact structure of specific message exchanges, which might themselves contain several individual EDIFACT files.
For a more detailed look at the structure of an EDIFACT file, see our blog post “EDI Standards Overview – Structure of an EDIFACT File” on this topic.
Despite being less widely-used than EDIFACT, the TRADACOMS standard was released several years before the UN standard. Designed primarily for UK domestic trade (and particularly popular in the retail industry), TRADACOMS is made up of a hierarchy of 26 messages. Like EDIFACT, each message is also given a six letter reference.
TRADACOMS does not use a single message format. Instead, a transmission to a trading partner will consist of a number of messages. For example, one purchase order will often contain an Order Header (ORDHDR), several Orders (ORDERS) and an Order Trailer (ORDTLR). Multiple individual order messages can repeat between the ORDHDR and the ORDTLR.
As with EDIFACT standards, the TRADACOMS standard uses segments for ease of translation. Below are four of the most common segments:
- STX – Start of Interchange
- MHD – Message start
- MTR – Message end
- END – End of Interchange
Example TRADACOMS order
3) ANSI ASC X12
ANSI ASC X12 stands for American National Standards (ANSI) Accredited Standards Committee (ASC) X12, though (for obvious reasons) this is often abbreviated to just X12.
Though initially developed in 1979 to help achieve EDI document standardisation across North America, X12 has been adopted as the preferred standard by approaching half a million businesses worldwide.
Compared to other EDI standards organisations, X12 has a particularly comprehensive transaction set. There are over 300 X12 standards, all of which are identified by a three digit number (e.g. 810 for invoices) rather than the six letter code system used by EDIFACT and TRADACOMS. These EDI file format standards fall under X12’s different industry-based subsets:
- AIAG – Automotive Industry Action Group
- CIDX – Chemical Industry Data Exchange
- EIDX – Electronics Industry Data Exchange Group (CompTIA)
- HIPAA – Health Insurance Portability and Accountability Act
- PIDX – American Petroleum Institute
- UCS – Uniform Communication Standard
- VICS – Voluntary Interindustry Commerce Standards
With each containing slight variations, these subsets are used by different industries as appropriate (apparel retail businesses use VICS for example).
In addition, the hundreds of document types are divided into 16 helpful message series, from ‘order’ to ‘transportation’, with each containing the relevant individual message types.
As with Documents conforming to X12 standards are made up of several segments, some of which are optional and some mandatory. Below is a list of the mandatory segments:
- ISA – Start of interchange
- GS – Start of functional group
- ST – Start of transaction set
- SE – End of transaction set
- GE – End of functional group
- IEA – End of Interchange
As with all EDI documents, these segments in turn are comprised of elements, as can be seen in the example X12 document below:
Example X12 order
For more information on the X12 format, please see our more recent article “EDI Standards Overview – Structure of an EDIFACT File”.
The Association of the Automotive Industry (Verband der Deutschen Automobilindustrie in German, or VDA for short) was established in 1901 by German automobile businesses.
The VDA was one of the first associations to develop EDI file formats in 1977, making VDA standards even older than EDIFACT.
Like X12 standards, every VDA message standard has a unique identification number (four digits long in this case). For example, VDA EDI file format 4905 is a delivery forecast.
As worldwide use was not expected when the standards were developed, all VDA standards were published in German – something that continues to this day. This can make interpretation difficult, particularly concerning German business terms. Likewise, as VDA also does not use a naming convention for each element, knowledge of German is required to identify them.
Unlike EDIFACT and X12 standards, VDA standards do not use segments or separators. Instead data elements with a constant length, known as fixed length format elements, are used. When the data to be transmitted is shorter than the required length, spaces are used to fill the gaps. Unfortunately, this fixed length format means that the amount of data that can be transmitted is limited, meaning conversion to/from other EDI standards can be difficult.
Because of these issues, VDA fixed length document standards are slowly being replaced by EDIFACT document types. Today, VDA standards are effectively a subset of the EDIFACT standards used extensively by the automotive industry (much like the EDIFACT subset CEFACT is used by retail businesses).
To aid those using their standards, the VDA have published suggestions regarding transition to EDIFACT.
Example VDA delivery forecast
For more information on VDA standards, please see our dedicated VDA blog post for a more comprehensive explanation.
The Universal Business Language, or UBL, is a library of standard XML-based business document formats. UBL is owned by Organisation for the Advancement of Structured Information Standards (OASIS), who have made it available to all businesses for free.
As UBL uses an XML structure it differs from other more traditional EDI document formats. Perhaps the biggest difference is the fact that XML-based transmissions are easier to read than other EDI file formats. However, XML file sizes are considerably larger than those of other EDI file formats, though this is no longer a problem following the advent of broadband internet.
When first established in 2003, UBL had seven EDI file format standards. By the time version 2.1 was released over a decade later this number had increased to 65, and the release of version 2.2 in 2018 further increased the number of document types to over 80.
Significantly CEN/TC434 recently named UBL as one of two EDI syntaxes which comply with new EU regulations regarding e-invoicing. As such, as the use of PEPPOL grows, so the use of UBL is also likely to increase.
Like X12, UBL message types are split into higher level categories. These categories include pre-award sourcing, post-award sourcing, procurement and transportation. UBL messages themselves, meanwhile, include validators, generators, parsers and authoring software.
Example XML order (ecosio ERPEL)
How to exchange different EDI file formats with your trading partners
Whilst each of the above document standards is widely used, particularly within certain industries, unfortunately no one set of document standards is universally used by all supply chain businesses. As a result, if you wish to grow your business and to automate B2B data exchange with your partner network to achieve the cost benefits of automation you will need the ability to translate data between numerous formats.
Given the amount of technical expertise EDI file format translation requires, the fastest and most efficient way to gain this capability is to enlist the help of a managed EDI solution provider such as ecosio. In addition to enabling you to transfer documents in any required format and over any EDI protocol via a single connection to our Integration Hub, ecosio’s managed services remove virtually all internal effort concerning EDI. For example, new onboardings are handled by a dedicated project manager who is experienced in liaising between both sides to achieve fast, hassle-free and successful connections. Similarly, ecosio’s unique API ensures users are able to send and receive data directly from their ERP’s existing user interface.
For more information on ecosio’s solution and to find out how we could help your business move to the next step, get in touch today!