Peppol for developers: Streamlined B2B transactions or new IT burden?

Peppol is undoubtedly gaining traction in the world of business messaging. Companies and governments are increasingly migrating business messaging—e-invoices, e-orders, and other transaction flows—from legacy technologies to this new, open standard.

Many articles provide an overview of the basics of Peppol, so we won’t discuss it here. For a summary of its background, check out this post on the history of Peppol. Instead, I’ll go into some depth about its features, technical capabilities, and infrastructure from a developer’s point of view and explain why it has become a new paradigm in B2B.

Business-to-business (B2B) in an IT context refers to the electronic exchange of business messages between companies. Electronic B2B communication has existed for a long time and was one of the driving factors in developing a stable and secure global network — what we today know as the Internet.

Business-to-business (B2B) in an IT context refers to the electronic exchange of business messages between companies. Electronic B2B communication has existed for a long time and was one of the driving factors in developing a stable and secure global network — what we today know as the Internet.

The reason is simple. Businesses realized that with the introduction of computers, they had to share data to utilize their full potential. From this need, B2B arose.

When B2B started in the late 70s, there were no networks between companies, and data (storage) was unimaginably expensive, so everyone did their best to minimize the data models.

From these early days, two leading formats emerged: ANSI X12 (1979) in the US and EDIFACT (1984) in Europe. Both were intended to be a standard for companies to use and to save data as compressed as possible.

Decades later, these formats are still widely used worldwide. X12 is uncommon outside of the US, but EDIFACT is widely spread.

EDIFACT is also the foundation for UBL, the Peppol XML’s building block.

B2B is used by pretty much every company today, as everyone needs to communicate digitally to do business.

As B2B spread, specifically from the mid-90s when the Internet boomed, many companies started establishing “point-to-point” (P2P) connections with their business partners, as there were no other alternatives to share their B2B data.

Sometime later, the first Value-Added-Network (VAN) services were developed to alleviate the growing pains of P2P connections. Companies could connect to one VAN service provider, who, in turn, connected to all the other collaborators, forming a B2B operator network. These service providers are commonly known simply as operators (OP).

More and more OPs were founded — some local, to a specific region or country, and some with global reach. The number of B2B connections grew fast while, at the same time, more and more systems were introduced on the market.

The result was an explosion of message types and formats as the supporting systems lacked common standards.

B2B service providers soon realized they needed transformations (conversions of data formats between customers’ systems and their business partners), which led to the development of more solutions, transformation software for companies, and transformation services from VAN providers.

As you probably can imagine, these caused a mess of B2B traffic. However, for VAN operators, this setup was highly profitable; they could charge both the sending and receiving parties, and to top it off, they could charge extra for transformations!

Sure, “collapse” might be a drastic way of putting it. Still, as the number of formats grew with no central coordination, the Internet spread rapidly, and data storage and transfer prices continuously dropped; the breaking point was looming.

The VAN operators were happy, though. Any participant in an operator network was tightly wedged in and had no other alternative than to continue paying the VAN providers’ bills to carry on with their business.

When the costs became painfully high, companies started looking to bring the B2B functionality home; the integration platform was poking its head out into the light for the first time.

Integration platforms were developed to replace many VAN providers’ functionality in handling transports, transformation, and routing. Those with a few years in the business remember this as the SOA age (and we are now around 2004–2008). Since then, SOA has grown, or somewhat morphed, into the microservices standard. All in all, a great outcome.

However, businesses were often charged substantial licensing fees by integration software providers instead of paying the VAN provider. Furthermore, the flexibility of the integration software made the complexity even worse as companies now could adapt to pretty much anything and process it in their systems, although at a high fixed cost as well as costs for consultants, manual handling, and building integrations. This mess is something that we still suffer from — the integration spaghetti. The number of formats, communication protocols, and P2P connections is overwhelming.

The solution to this inefficient but unfortunate growing situation came unexpectedly. As countries, regions, and systems had their formats and protocols, the European Union identified the problem as hindering an effective inner market. The EU started developing Peppol to have a collaboration network with a precise and controlled standard.

This was done independent of the B2B collapse, but the EU needed some form of a joint and efficient communications standard, as none existed on the market.

Not everyone was happy about this. The VAN providers realized that the simplicity of a common standard would radically decrease the amount of charges or fees collected, thus removing a significant revenue stream.

Eventually, with the firm help of European policymakers and the continued adoption of Peppol among governments and companies, most VAN providers realized that maintaining one standard was more cost-efficient in the long run. Keeping up the B2B mess and integration spaghetti wasn’t cutting it anymore. The endorsement from VAN operators helped Peppol take off.

Another party not overwhelmed with joy was the companies that had invested heavily in an integration platform handling all B2B communication in-house. Peppol requires using a Peppol access point (AP), also called a Peppol service provider, as the only way to exchange messages over Peppol. This single interface to the network makes existing P2P connections and the capability to handle many transfer protocols redundant.

The integration platform users have reached the same conclusion as the VAN operators. At least they are beginning to realize it — using ONE standard helps sort out much of the mess. Simultaneously, an increasing number of software providers, e.g., ERPs such as SAP, are adding native support for Peppol, eliminating the need for complex transformations.

Many integration platforms and VAN operators have realized that the Peppol model is highly beneficial.

The AP guarantees message delivery; the protocol and standard are highly structured and validated, and any message received through the network is fully validated and always 100% correct from a syntax and validation rule perspective.

These checks and balances offered using the Peppol network can significantly lower the need for error handling and tracking, thus saving money in the long run. Personnel can be moved to other tasks, and software licensing and systems can be reduced.

When I first started in IT and B2B, one of my first assignments was to upgrade a flow from EDIFACT D.93A to the then newly released D.96A (those in the know of EDIFACT might be aware that D.96A was released in 1996) and my first thought: “what the…? who in God’s name came up with this format?“. Then I realized it was the United Nations, so I accepted the situation.

Peppol has chosen UBL as the underlying standard, which is based on EDIFACT. It is a well-used and proven foundation that meets most companies’ needs.

The UBL messages are sent using AS4 (ebMS) as both signed and encrypted data, securing the message and transport and making Peppol a safe and reliable communication method. Peppol is governed as an open standard, with a committee and members who set the standard and make changes and additions. Each joining country has one or more Peppol Authorities governing the members in each country.

Check out this post to familiarize yourself with the Peppol terminology.

Peppol is a set of standards and infrastructure designed to simplify electronic procurement processes across Europe and beyond. Its adoption has been driven by the need for standardized and interoperable e-procurement solutions to enhance efficiency, reduce costs, and foster international trade.

Key points about Peppol adoption:

Overall, the adoption of Peppol represents a significant advancement in the digitalization of procurement processes, promoting greater efficiency, cost-effectiveness, and global trade integration.

And its challenges?

Adopting Peppol, while advantageous, can face several hindrances. I am being a bit crass here — it is essential to look into Peppol with your eyes fully open:

Addressing these hindrances requires strategic planning, adequate resources, and strong stakeholder engagement to successfully adopt and leverage Peppol’s benefits.

Peppol is growing. Some teething issues are prevalent as new countries want to join, and the community is trying its best to combine resources to mutually fit everyone’s needs.

The standard has split into Peppol BIS, used mainly in Europe, and Peppol PINT, used internationally. It is probably wise, as VAT regulations and requirements can’t be met in a single format, but the mapping (transformation) between the two is clearly laid out.

Looking back at the spaghetti we suffered from years ago, it is proven that Peppol can solve the complexities, help lower costs, reduce errors, and provide higher-quality data. Even though there are valid challenges that might prove difficult for some to overcome, it is evident that Peppol will continue to grow. In the coming years, we’ll see increased support from systems and services, e.g., ERPs, adding support for the Peppol XML formats, more counties joining, and a continuous increase of transactions and users.