Briefly about the problem
Many companies begin an e-invoicing project with one urgent national requirement. Most often, it is a local tax platform, a specific file format, or a regulatory deadline.
That is understandable, but this is also where a common mistake appears. The integration is designed for one market, one delivery channel and one set of rules. When the company wants to cover another country, it turns out that the logic, data mapping and exception handling have to be rebuilt.
In practice, you need to distinguish between several layers that are often grouped together: the national tax system, the semantic standard, the document syntax, the exchange network and your own data in the ERP.
Without that distinction, it is hard to build a solution that will work not only today, but also when the company enters additional markets.
Why this issue slows down the business
If an organisation does not separate the layers of e-invoicing, tension quickly appears between finance, IT and the business. Everyone uses the same words, but means something different.
For accounting, a “standard” may mean the mandatory data scope. For IT, a “format” is an XML file. For operations, “integration” simply means sending an invoice from the ERP. In reality, these are different parts of the process.
The practical result is:
- The ERP does not contain all the data needed for validation.
- Mapping works for one country, but not for another.
- The sending status does not show whether the document is business-valid, technically valid or tax-valid.
- Corrections and exceptions end up being handled manually.
- A regulatory change requires expensive rework of the integration.
The biggest problem appears when the company treats a local requirement as the full target model. This usually leads to an overly rigid architecture.
What the process looks like in practice
To design the integration properly, it is worth starting not with technology, but with the process and the terminology.
1. A national tax system is not the same as a European standard
KSeF is a national platform and a set of local rules. It defines how an invoice is submitted to the public system, the required data scope, the validations and the statuses related to document acceptance.
EN 16931 is a European semantic standard for electronic invoices. It is not a single platform or a single network. It describes what information an invoice should contain and how individual fields should be understood.
This is an important difference. A national platform says where and how to send the document in a given country. A semantic standard says what the data on the invoice means.
2. Semantics are not the same as file syntax
A company may encounter terms such as XML, UBL or other document profiles. This is the syntax layer, meaning the technical representation of data.
EN 16931 works at a higher level. It defines the information model, not just the shape of the file. As a result, two documents can comply with the same semantic standard, while being written in a specific allowed syntax and subject to local constraints.
For an integration project, this means one thing: it is not enough to generate “some XML”. You also need to ensure data meaning consistency, validation rules and the mandatory elements for a specific scenario.
3. Peppol is an exchange network, not one format for everything
Peppol is a network for exchanging electronic documents between organisations. It makes it easier to send invoices and other documents through an agreed communication model.
It is not the same as a national tax system. It is also not simply the name of one file. In practice, Peppol concerns the exchange channel, participant addressing rules, document profiles and validations related to document movement within the network.
From a business perspective, the most important point is that a company may have all of the following at the same time:
- a requirement to send documents to a national public platform,
- a requirement to comply with EN 16931,
- B2B exchange via Peppol,
- additional country- or recipient-specific rules.
These layers can complement one another, but they are not interchangeable.
4. The ERP is not the source of a ready-made e-invoice
In many organisations, it is assumed that if the ERP already generates a PDF invoice or accounting data, then the e-invoicing topic is almost closed. In practice, that is rarely enough.
The ERP stores transactional data, but often does not have:
- the full codes and identifiers required by a given standard,
- consistent units of measure and tax markings,
- addressing information for the exchange network,
- rules for cross-border scenarios,
- logic for handling rejections, corrections and retries.
That is why e-invoice integration usually does not consist of a simple document export from the ERP. It requires a layer for mapping, validation, orchestration and status tracking.
5. Data mapping matters more than the sending channel itself
Most problems do not come from the transmission itself, but from whether the data from source systems can be correctly translated into the required invoice model.
Typical questions to resolve before implementation include:
- Where does the correct buyer and seller identifier come from?
- How are tax rates, tax bases and exemptions mapped?
- How are discounts, prepayments, corrections and additional charges represented?
- Which fields are mandatory in a given country, and which are only conditional?
- What should be done when the ERP does not store the required information?
If these issues are not defined, even the best communication channel will not solve the problem.
6. Validation has several levels
In e-invoicing projects, the word “validation” is often used too broadly. It is worth separating at least four levels:
- Technical validation – whether the file has the correct structure.
- Semantic validation – whether the data meets the standard’s rules, for example field dependencies.
- Business validation – whether the document reflects the actual transaction and the company policy.
- National or platform validation – whether the document meets the local requirements of a given system.
A document may pass one validation stage and fail at the next. That is why a status of “sent” is not enough.
7. Country-specific extensions are normal, not exceptional
International companies often assume that if a European standard exists, then all countries can be handled with one identical model. That is too optimistic.
In practice, local rules, additional fields, different interpretations of selected data, separate correction scenarios and varying requirements for identifiers, statuses and archiving all appear.
That is why a good integration model should have:
- a core common to multiple countries,
- a layer of local extensions,
- market-specific validation configuration,
- clear rules for versioning changes.
This is much safer than building separate logic from scratch for each country.
8. Statuses and exceptions must be designed from the start
An e-invoice does not end when the file is generated. You still need to know what happens to the document next.
In practice, statuses may cover different stages:
- data preparation,
- internal approval,
- technical validation,
- submission to an operator or network,
- acceptance or rejection by the platform,
- delivery to the recipient,
- handling of corrections or cancellations.
If the company does not have a consistent status model, chaos quickly follows. Finance sees one version of the truth, IT another, and the business a third.
When automation or AI makes sense
Automation makes sense when a company handles a large volume of documents, multiple countries or more than one exchange channel. In such cases, manual checking of data and statuses becomes too error-prone.
The most common automation areas are:
- filling missing data from supporting systems,
- mapping documents to different output models,
- pre-send validation,
- handling retries and exceptions,
- monitoring statuses in one place,
- archiving and audit trail management.
AI can be useful, but it is usually not the first element of the project. It creates the most value where there is a need to structure inconsistent data, classify exceptions or support the operator in analysing rejection reasons.
Examples of sensible AI use include:
- suggesting the reason for an error based on the content of a return message,
- grouping similar exceptions for common handling,
- detecting missing data before submission,
- supporting work with source documents when some data comes from outside the ERP.
However, AI will not replace a proper data model, validation rules and a clearly designed process. If those elements are weak, automation will only spread the errors faster.
When it is better to start with simpler process structuring
Not every company should immediately build an extensive integration layer for the whole of Europe. Sometimes it is better to begin with a simpler step.
This is especially a good approach when:
- ERP data is inconsistent between subsidiaries or countries,
- there is no owner of the end-to-end process,
- document statuses are tracked in email or spreadsheets,
- the company does not have agreed rules for corrections and exceptions,
- regulatory priorities currently concern only one market.
In such a situation, it is worth first:
- describing the target process flow,
- establishing a common terminology for finance and IT,
- identifying the minimum data set required for an invoice,
- outlining exception and rejection scenarios,
- checking which elements are common to all countries.
This usually creates a better foundation than a quick implementation for one local obligation.
Risks and limitations
In European e-invoicing, the biggest risk is not only technology. It often lies in incorrect project assumptions.
The most common risks are:
- confusing concepts – for example, treating Peppol as a replacement for every national system,
- designing for one country – with no room for extensions and additional markets,
- too much faith in the ERP – without analysing source data quality,
- no exception model – which leads to manual work and disputes over responsibility,
- no versioning of rules – which makes it difficult to respond to changing requirements,
- no shared view of statuses – which makes process control and audit harder.
It is also important to remember that regulations and implementation practices in Europe are changing. Concepts related to ViDA e-invoicing and the development of digital reporting obligations increase the importance of an adaptable architecture. However, this does not mean that it is possible today to design one unchanging model for all future scenarios.
Therefore, the goal should not be to create an “integration for ever”. A better goal is to build a solution with a stable core and a controlled way of making changes.
What a first small pilot may look like
A pilot should be small, but well chosen. It is not worth starting with a full rollout across all subsidiaries and countries.
A sensible first scope may include:
- one process, for example outbound invoice processing,
- one company or one country,
- one exchange channel,
- a limited set of document types,
- clearly defined exceptions outside the first-stage scope.
In the pilot, it is worth checking above all:
- whether source data from the ERP is sufficient for correct mapping,
- which fields need to be supplemented from other systems,
- what the most common reasons for rejections are,
- whether statuses are clear for finance and IT,
- how corrections and retries are handled.
It is better if the pilot result is not just a list of technical errors. A more valuable outcome is a process model that can later be replicated in other countries.
Summary
E-invoicing in Europe is not one topic. It is several layers that must be consciously separated: the national system, the semantic standard, the document syntax, the exchange network, ERP data, mapping, validation and exception handling.
KSeF, Peppol and EN 16931 do not compete with one another in a simple way, because they serve different roles. The problem starts when a company builds the integration as if all these elements were the same thing.
The safest approach is to start with one process and one real scenario. Only on that foundation is it worth developing automation, additional countries and a more advanced integration layer.