From Email to Peppol: How Companies Exchange Documents Digitally
Companies exchange large volumes of documents with one another every day. Invoices, orders, order confirmations, packing slips, credit memos, and other business documents are constantly moving between suppliers, customers, and their systems.
At first glance, this seems simple: one organization sends a document and the other receives it. In reality, however, there is a complex landscape of different channels, protocols, networks, and document formats. An invoice can arrive as a PDF via email, be delivered as an XML file via SFTP, be exchanged directly via an API, or travel from one system to another via a network such as Peppol.
Especially when it comes to invoices, the differences between these methods of exchange are becoming increasingly important. An invoice is not just a document, but also a collection of financial data that must be exchanged reliably, securely, and—increasingly—in accordance with legal standards.
Document, format, and channel are distinct concepts
To fully understand document exchange, it helps to distinguish between three elements: the content of the document, the format in which that content is recorded, and the channel through which it is transmitted.
For example, an invoice may contain the same data—supplier, customer, invoice number, amounts, VAT, and payment details—but be delivered in very different technical formats. As a PDF, that data is primarily intended to be read by people. In a structured XML format, such as UBL, UN/CEFACT CII, cXML, or Finvoice, individual data fields have a fixed meaning and can be processed directly by systems.
On top of that is the delivery channel. A PDF can be sent as an email attachment, while an XML file is delivered via SFTP, an API, or a network such as Peppol.
That distinction is important. An XML invoice sent via email is structured, but email itself is not a structured B2B network. A PDF sent via an API, on the other hand, uses an automated channel even though its content remains largely unstructured.
Therefore, true automation only occurs when the format, transport, addressing, and processing are properly aligned.
Email: Universal, but Limited in Terms of Automation
Email remains one of the most widely used channels for business document exchange. Virtually every organization can use it, and suppliers require virtually no technical integration.
SMTP—Simple Mail Transfer Protocol— is typically used for sending and forwarding email. SMTP is thus the underlying transport protocol; from the perspective of document exchange, it makes more sense to simply refer to the email channel.
The strength of email is also its limitation. Email is a generic communication channel. It does not recognize that an attachment is an invoice, who the legal supplier is, or which invoice number corresponds to which order.
A received PDF must therefore first be identified and interpreted. This can be done manually, but document recognition is increasingly being used for this purpose. OCR and AI can extract data from invoices, classify it, and convert it into structured data.
This allows a large part of the processing to be automated, but a fundamental difference remains compared to true electronic invoicing. With a structured e-invoice, the data is delivered directly as data by the sending system. With a PDF invoice, that data must be extracted from the visual representation afterward.
Email, therefore, will not simply disappear. It is, in fact, important that a modern infrastructure can also incorporate this channel into a single central document flow. However, for large-scale system-to-system exchange, email is not the end point.
SFTP: Reliably Transferring Files from A to B
The next step in automation is SFTP: SSH File Transfer Protocol. Instead of sending documents to an email inbox, a system places files in a secure location where another system can retrieve them—or vice versa.
SFTP has long been used for business data exchange. It is relatively simple, robust, and suitable for processing large numbers of files.
For example, an organization can periodically check whether new XML invoices are available. New files are automatically retrieved and processed. Orders, payment files, and other commercial documents can also be exchanged in this way.
This eliminates much of the manual effort that might still be required with email.
Nevertheless, SFTP remains, in essence, a point-to-point connection. The sender and recipient must agree on access, filenames, formats, and processing. When a company has to maintain separate connections with dozens or hundreds of trading partners, this quickly leads to complexity.
SFTP effectively solves the transport issue, but it does not automatically standardize the entire document exchange process.
APIs: Connecting Systems Directly
APIs take it a step further. Whereas SFTP typically involves uploading and downloading files, applications can communicate directly with one another via an Application Programming Interface.
For example, an ERP system can submit an invoice to an external service, after which a technical response is returned almost immediately. In the same way, statuses, validation results, or other data can be sent back.
APIs therefore enable more real-time interaction and are well-suited for processes in which systems must respond to one another immediately.
However, an API in and of itself is not a universal standard for document exchange. Each provider may use a different API, with its own endpoints, authentication, data structures, and versions.
When Organization A builds a direct API connection with Organization B, a bilateral connection is created once again. This can work very well for a few strategic partners. With hundreds or thousands of relationships, however, it becomes less practical to build, test, and maintain each connection individually.
This is a key difference between a technical connection and a network. An API is excellent at connecting systems, but it does not automatically solve the issues of reach, addressing, and interoperability among large numbers of organizations.
AS4 and Peppol: From Transport Protocol to Network
For large-scale business document exchange, protocols and networks have been developed that are specifically designed for reliable system-to-system communication. AS4 and Peppol are good examples of two different layers within such an infrastructure.
AS4 is an open standard for the secure and reliable exchange of electronic messages via web services. Among other things, it supports technical acknowledgments of receipt and reliable message delivery.
However, AS4 is not a trading network in and of itself. It is a transport protocol: a technical agreement on how messages are sent between systems or service providers.
Peppol goes a step further. It addresses a fundamental problem of B2B integration: when every supplier must connect directly to every customer, the number of possible connections grows rapidly.
Peppol therefore operates according to a four-corner model. The sender is connected to a Peppol Access Point. The recipient also has an Access Point. These service providers then facilitate the exchange between the two organizations.
As a result, a company does not need to set up a new technical connection for every trading partner. In principle, it can reach other participants within the network via a single connection.
Furthermore, Peppol goes beyond mere transport. It includes agreements on, among other things, addressing, security, document types, validation, and technical interoperability. The network determines where a recipient can be reached and which message types they can receive.
AS4 is used for communication between Access Points. This clarifies the distinction: AS4 governs how messages are technically transmitted; Peppol organizes how organizations can find each other within a standardized network and exchange documents.
The content of documents is also standardized. For invoicing, Peppol BIS Billing is used, among other standards, based on European agreements for structured electronic invoices.
This brings together various layers: the document has an agreed-upon meaning, the network knows where to send it, and the transmission takes place according to standardized technical agreements.
E-invoicing is more than just sending a PDF digitally
This distinction is becoming increasingly relevant, especially when it comes to invoices.
A PDF invoice sent via email is digital, but it is not the same as a structured electronic invoice. With a true e-invoice, the recipient does not receive a digital image that must be read anew, but rather data that can be processed directly by the financial system.
This enables automatic validation before an invoice proceeds further into the Purchase-to-Pay or Order-to-Cash process. Are the required data fields present? Is the sender known? Are the VAT details correct? Does the document comply with the agreed-upon standard?
Within e-transaction networks, documents can also be checked for technical compliance and content accuracy before being forwarded.
The result is a more deterministic process. The data does not need to be reinterpreted from a document but is transferred directly between systems. The original invoice data remains traceable throughout the process.
This is becoming increasingly important as governments are making more and more use of electronic invoicing and digital transaction reporting. As a result, e-invoicing is evolving from merely an efficiency issue into an integral part of the financial and tax infrastructure.
For businesses, this means that the choice of a channel is no longer determined solely by ease of use. Standardization, traceability, data quality, compliance, and integration with financial processes are also playing an increasingly important role.
A Single Infrastructure for Multiple Channels
In practice, document exchange will not take place via a single channel for the time being.
One supplier sends a PDF via email, another delivers XML files via SFTP, major trading partners use API connections, and an increasing number of organizations exchange structured invoices via Peppol or other e-transaction networks.
The challenge, therefore, is not necessarily to immediately replace every existing channel. The greater challenge is to prevent each channel from creating its own process.
A central document exchange layer can accommodate these differences. Externally, it supports various channels and networks: email, SFTP, APIs, Peppol, and other forms of B2B exchange. Incoming PDF and XML formats are recognized, converted, and validated. Internally, information is made available to ERP and financial systems in an agreed-upon format.
For outgoing documents, the same principle works in reverse. For example, the ERP system delivers an invoice in an agreed-upon format. The exchange layer then determines how the recipient can be reached, what format is required, and through which channel or network the document should be sent.
This shifts the complexity away from the ERP. Not every financial system needs to be configured separately for every supplier, customer, standard, or network connection.
And that is precisely where the trend in business document exchange lies: from sending individual documents to reliable data exchange between systems. Email and SFTP remain viable channels. APIs enable direct integration. AS4 provides standardized B2B transport. Networks such as Peppol add reach, addressing, standards, and governance to the mix.
For invoices, this ultimately means that information no longer needs to be translated from system to document and back to data along the way. Financial data can flow directly, in a controlled and traceable manner, from one system to another.