Updated on: February 7th, 2023
If you have dealt with EDI (electronic data interchange) before, then you must also be familiar with EDIFACT. For the last decades, electronic data interchange and the EDIFACT messaging standard have been essential facilitators of global trade. Business-to-business information exchange has become more critical than ever. Nevertheless, new standards and message formats have appeared to support B2B communication.
At the same time, EDIFACT is still widely used in specific industries, for instance, in the ocean shipping industry. However, most integration architects don’t like or want to deal with it. Why is that? EDIFACT is a rigid format that comes with a lot of rules, and it is difficult to work with it. Validating and enriching an EDIFACT message manually is almost impossible due to its structure and the character sets used. Avoiding it is practically impossible, though before trading parties wouldn’t agree on a new standard. There are formats used, such as XML, JSON, or proprietary in-house formats, but EDIFACT is not about to disappear any time soon.
As this standard is still essential, we want to provide you with more information in this blog, together with tips on how an integration platform can help to ease the pain of dealing with EDIFACT. Hence, this post covers the following topics:
- What is EDIFACT?
- Why was EDIFACT developed?
- What is the structure and what are the components of EDIFACT messages?
- Challenges of EDIFACT
- How does an EDIFACT converter work?
- Leveraging iPaaS to overcome the challenges
What is EDIFACT?
If you google the term, you will find many definitions. One of those is from UNECE, which defines EDIFACT as the following:
“UN/EDIFACT (the United Nations rules for Electronic Data Interchange for Administration, Commerce, and Transport) comprise a set of internationally agreed standards, directories, and guidelines for the electronic interchange of structured data, between independent computerized information systems.”
Why was EDIFACT developed?
The rules of EDIFACT have been approved and published by UNECE, and they also maintain it.
Because of the large number of trading partners a company would typically have, it was critical to develop a format that could be understood by any party. EDIFACT was designed to simplify and standardize the communication between trading parties that were relying on electronic data interchange (EDI) as their primary form of communication. The widespread adoption of EDI meant that global businesses could thrive: they could completely replace paper documentation and manual procedures and share information with their ecosystem electronically, a lot faster than if they used paper. It also meant that they were able to cut costs, not by just using less paper but also by improving operational efficiency.
We can say with confidence that EDI and EDIFACT have had a strategic role in shaping modern supply chains.
When introduced, EDIFACT was revolutionary. It was the missing link to eliminate paper and manual processes and thereby significantly speeding up operations and reducing costs.
It was a safe, effective, and cheap alternative to paper-based communication. It has helped the adoption that many large retailers or manufacturers required the capability of electronic data interchange from their trading parties, no wonder that EDI has quickly become significant (still is today), and there had to be a standard to simplify communication.
What are the structure and components of EDIFACT messages?
The intervention of the United Nations (UN) was unavoidable. They needed to assist in the development of a standard that could fit the need of any trading party. They needed to identify all information that is typically included in trading messages and, deriving from that, identify what shall be included in EDIFACT messages.
United Nations needed to specify the message structure (header, detail, summary) and the content (syntax, data elements, composite data elements, segment, messages). The UN has also defined the number of characters per line and the number of lines per box. The logic of EDIFACT is very similar to the logic of languages: the information can be structured into "words" and then "sentences". The "words" are called data elements (it could be an invoice number or the time of shipment). The United Nations Trade Data Elements Directory (UNTDED) has defined around 700 data elements with associated codes. The data elements can be organized into "sentences" that are called segments. The segments are then grouped to shape a message based on strict syntax rules. The segments, messages, and syntax implementation guidelines can be found in the United Nations Trade Data Interchange Directory (UNTDID).
The handling of an EDIFACT message sounds simple: once you have generated it, you use a tool like EDI Value-Added Network (VAN) for processing and transmission. The basic idea behind EDIFACT was to structure the data better before it would have been sent from one system to another and support multi-country and multi-industry exchange of business-critical information. If your trading partner’s system can understand an EDIFACT message, this is a simple and great solution – and that has been the original intention of EDIFACT. This thought leads us to our next chapter, which is handling the main challenges of EDIFACT.
Challenges with EDIFACT
While a standard, EDIFACT is still somewhat clumsy. Most of the developers don't like to deal with it since the specifications are complex and the data format is only semi-structured. Just take a look at an EDIFACT sample message.
Below is an example of EDIFACT:
One problem with EDIFACT is that it was developed years before XML became widely adopted in machine-to-machine communication. Since EDIFACT is only semi-structured and appears to be just a blob of text, semicolons, and coded values, the data format is difficult to read for humans and difficult to handle by software tools. Understanding the content of each message requires extensive knowledge about the EDIFACT standard and the used message version. Lack of structure also makes implementation projects time-consuming and error-prone.
There are several problems:
Validating EDIFACT
If you need to make sure that all the information is correct in the EDIFACT message, you shouldn’t do it manually. Let’s be honest; it is almost impossible due to all the different rules and characters used, even in a short message.
Enriching EDIFACT
Once you realize that something is missing, it is equally challenging to enrich it. This is something that should be simplified and automated.
Your partners are using formats other than EDIFACT
While EDIFACT was born to standardize electronic B2B communication, other formats are commonly used across companies. Whether your stakeholders use XML, JSON, X12, or any own format, you should be able to communicate with them, and the messages they send should be in EDIFACT, the preferred format that your systems understand.
Still, it's a standard that has been widely adopted and offers a common vocabulary and set of messages for trading partners. No wonder we often still work with companies that are using EDIFACT for business-to-business communication.
EDIFACT made easy
What if there was a way to automatically translate EDIFACT messages to a structured and human-readable format, like XML or JSON, and vice versa?
This would simplify EDIFACT projects so that most of the work would consist of implementing the mappings with commonly available technology such as XSLT. When the conversion to XML format is done, it's a lot easier to transform the message to whatever format you wish: JSON, CEFACT, UBL, GS1 XML, X12, or your in-house XML format, to name a few.
This shorts onboarding of new trading partners to a matter of days instead of weeks or months. This will also dramatically cut the costs of onboarding just by accelerating the speed of development and deployment of EDI solutions. It also helps you manage different versions of the same messages and harmonize them into a single version to be used in your own information systems, such as transport management, order handling, and invoicing systems.
If this is something interesting for you, you should watch our webinar held a while ago in which we demonstrated how simple it is to use the EDIFACT converter.
How iPaaS helps you with your EDIFACT challenge?
First of all, an integration platform can replace any traditional EDI software and service that you are using. Your software and system may work fine, so you are wondering why you would switch it.
We have written a lengthy blog on why you would modernize your EDI and why you would adapt to a cloud-based electronic data interchange service, and we suggest you check out that blog. But, you will be able to communicate with all your partners in real time regardless of the systems they use (on-premise or cloud) and the formats they use. You will not only be able to transmit messages but also translate, validate, and enrich them.
Youredi iPaaS platform offers an out-of-the-box translation of your EDIFACT messages and makes onboarding of new trading partners fast, easy, and less error-prone. And the best news is that Youredi provides 100% managed services (unless, of course, you prefer doing it all by yourself with our support), so you don’t need to do anything to get a state-of-the-art EDI service in place with EDIFACT conversion.
Get your copy of the EDI Transaction sets here:
