“E-Invoicing projects rarely fail because of XML. They fail because companies no longer fully understand their own outbound invoicing processes – and expect compliance to be something they can simply buy.”

E-Invoicing is still often treated as a technical implementation project: a new file format needs to be generated, an interface configured and a transmission channel connected. Once this is done, the company is expected to be compliant.

This view is too narrow.

E-Invoicing is neither just a format change nor an isolated IT project. It is a company-wide tax, compliance and transformation project that affects one of the most critical business processes: invoicing.

For many companies, the first challenge is not changing the technical invoice output. It is understanding why their invoices look the way they do, which business decisions are behind them and how those decisions have been implemented technically.

When outbound invoicing becomes a black box

One of the biggest challenges begins before the actual E-Invoicing implementation.

Many companies are familiar with terms such as EN 16931, XML, Peppol or country-specific reporting systems. However, some are no longer able to fully explain their existing outbound invoicing processes.

Invoice generation may have been defined, implemented and approved years or even decades ago. As long as invoices were generated, sent, paid and posted successfully, the process was considered to be working.

Over time, additional special cases, customer-specific requirements, individual forms, manual additions and technical exceptions were introduced. Employees, external consultants and system owners changed. Documentation was not always maintained in full.

As a result, companies may no longer be able to reliably explain:

• why specific information appears on an invoice,
• which system the information comes from,
• how individual business transactions are treated for tax purposes,
• which rules are behind tax codes and invoice types,
• which special logic is applied in the ERP system or form generation,
• and who is responsible for the underlying business decisions.

When a person reviews a PDF invoice, ambiguities can sometimes be resolved through experience, context or manual clarification. Structured invoice data does not offer the same flexibility. Information has to be clearly defined, semantically mapped and made available in a machine-readable form.

This is the core idea behind the EN 16931 e-invoicing standard. It does not merely define technical fields. It defines the meaning of essential invoice information and the business rules that apply to it.

E-Invoicing does not create this knowledge gap. It makes the gap visible.

A polished PDF is not compliance

Many companies initially focus on the visible invoice: the logo, font, page layout, item tables and familiar appearance should remain unchanged.

A clear visual presentation is still useful. However, it is not the decisive measure of E-Invoicing compliance.

Where structured e-invoicing requirements apply, a simple PDF is not sufficient. The invoice must be available in a structured electronic format that supports automated processing.

This represents a fundamental change in priorities. The central question is no longer:

Does the new invoice look exactly like the old one?

The more important question is:

Do the structured data completely, clearly and correctly represent the actual business transaction?

E-Invoicing is a company-wide tax and compliance project

Before connecting a technical solution, companies need to understand and document their existing invoicing processes.

This includes:

• different invoice types and business transactions,
• source systems and data origins,
• tax logic,
• correction processes,
• special cases,
• manual interventions,
• customer-specific requirements,
• and the responsibilities assigned to individual decisions.

This work cannot be handled by IT alone. It requires the expertise and decisions of tax, finance, sales, master data management, IT and the operational departments involved in invoicing.

Key questions include:

Which business transactions exist? How are they treated for tax purposes? Which invoice information is required? Where does this information come from? Is it available in a structured form in the source system? Which information is generated only within the form logic? Which customer requirements apply? Which country-specific requirements need to be considered? And who has the authority to define how a special case should be handled in the future?

These decisions cannot simply be delegated to a technical service provider.

If the necessary understanding is missing at the start of a project, requirements are often discovered only during mapping, validation or testing. What initially appears to be a technical error then turns into a business clarification, a new exception or another round of adjustments.

The resulting delays are often attributed to the service provider. In reality, they are frequently caused by an outbound invoicing process that the company itself no longer fully understands.

Compliance can be supported – but it cannot be bought

A common misconception is that commissioning an E-Invoicing service provider automatically transfers responsibility for compliance.

That is not the role of the service provider.

A provider can connect source systems, normalize data, generate invoice formats, apply technical business rules, perform country-specific validations, operate transmission channels and monitor processing statuses.

The provider can identify, for example, that a mandatory field is missing, a code is not valid, a calculation does not comply with an implemented rule or a target format is technically invalid.

However, without the company’s business information, the provider cannot determine:

• whether the underlying business transaction has been classified correctly,
• whether the tax treatment is appropriate,
• whether a tax exemption is justified,
• whether the recipient has been identified correctly,
• whether the description of the service reflects the actual transaction,
• or whether the data supplied by the ERP system is complete and accurate.

The European Commission explicitly places responsibility for the invoice content and its compliance with the standard on the invoice issuer. Technical validation artefacts support this process during development and operation, but they do not replace the company’s own business and tax assessment.

The distinction is therefore clear:

The service provider delivers the technical capability. The company remains responsible for the business transaction, the invoice content and the tax treatment.

Or, more simply:

Even the best platform cannot create a correct invoice from incomplete or incorrect source data.

How eDNA makes technical complexity manageable

This is where xSuite eDNA comes in.

eDNA does not make the business decisions on behalf of the customer. Instead, it provides an integration, transformation and validation layer between connected source systems and the required invoice formats and transmission channels.

Invoice data is transferred from source systems through defined interfaces and product-specific connectors. It is then processed in a normalized invoice model. This means that individual ERP systems do not need to implement every country-specific target format and transmission method themselves.

The validation process takes place in several stages.

First, eDNA checks whether the required data is available in the normalized invoice model and whether it is technically plausible. The invoice is then transformed into the required target format and checked against the rules of EN 16931 and the relevant business rules. Depending on the destination, additional validations can be performed against national or network-specific requirements.

Once processing has been completed successfully, the invoice is made available or transmitted through the configured channel. Processing statuses and technical errors can be tracked in the eDNA WebClient and, depending on the integration, in the connected source system.

eDNA supports companies in:

• connecting different source systems,
• normalizing invoice data centrally,
• separating invoice formats from country-specific requirements,
• identifying technical and rule-based errors at an early stage,
• managing transmission channels centrally,
• and tracking processing statuses transparently.

This reduces technical complexity and helps shorten troubleshooting. It does not replace the company’s business analysis of its outbound invoicing process.

eDNA can show that information is missing or violates an implemented rule. It cannot independently reconstruct why a company has been invoicing a particular business transaction in a certain way for years – or whether that approach is still correct from a tax perspective.

This clear division of responsibilities is essential for a successful project.

What companies often underestimate

Companies often underestimate not the implementation time of the interface itself, but the preparatory work required to ensure that the interface receives and delivers correct business data.

Four issues are particularly common:

First, the project is treated as an IT task, even though many of the necessary decisions come from tax, finance and the operational departments.

Second, companies assume that their existing outbound invoicing process is already well documented and clearly defined. In practice, historical logic, special processes and manual interventions often have to be reconstructed first.

Third, attention focuses on the visible invoice while data quality, semantic mapping and machine-readable mandatory information receive less attention.

Fourth, companies expect the service provider to derive business and tax decisions from the existing invoice layout or from incomplete ERP data.

These assumptions lead to delays. Not necessarily because the technical platform is unable to perform, but because the conditions for an unambiguous technical implementation have not yet been established.

From initial implementation to ongoing operations

Once the first E-Invoicing projects have been completed, standard services such as format conversion, validation and transmission will become increasingly comparable.

However, this does not mean that the need for E-Invoicing solutions and services will disappear. The focus will increasingly shift from one-time implementation to the ongoing operation of international E-Invoicing landscapes.

Companies will continue to need:

• support for international E-Invoicing operations,
• adaptation to new country requirements,
• monitoring and error handling,
• updates to formats and validation rules,
• continuous improvement of data quality,
• integration of additional source systems,
• and the connection between E-Invoicing and digital VAT reporting.

Platforms such as eDNA are therefore not merely conversion tools. Their long-term value lies in providing a central integration and processing layer that helps companies manage regulatory and technical changes without having to redesign every ERP system separately.

ViDA opens the next phase of digital reporting

E-Invoicing is not the end of regulatory development.

EN 16931 is a European semantic standard for electronic invoices, not a regulation. It defines core invoice information, the meaning of that information and the corresponding business rules. The standard will continue to evolve.

The EU’s VAT in the Digital Age package, known as ViDA, introduces the next phase of digital reporting. Digital reporting requirements for cross-border B2B transactions are scheduled to apply from 1 July 2030. By 1 January 2035, Member States with existing domestic real-time transaction reporting systems must align them with the European model and its standards.

For companies, this means that E-Invoicing should not be viewed only as a mandatory output format.

Companies that understand their business transactions, clean up their data sources, define responsibilities and establish structured invoicing processes are also creating an important foundation for future digital reporting requirements.

eDNA can support this foundation by receiving, normalizing, validating and transforming invoice data and by providing transparent processing statuses. However, this does not automatically mean that future ViDA or national VAT reporting obligations are fulfilled. The generation and transmission of the required reporting data will remain a separate business and technical step.

Conclusion: The transformation begins before the interface

The biggest challenge of E-Invoicing is not XML. It is not the portal, the transmission channel or the visual representation of the invoice.

The real challenge is that companies need to fully understand their outbound invoicing processes again, redefine responsibilities and translate historically grown processes into clear, structured data.

A service provider can support this transformation technically. It can normalize data, generate formats, apply validation rules, operate transmission channels and make errors transparent. It cannot take responsibility for the company’s tax assessment or for the actual business transaction.

E-Invoicing is therefore not an isolated IT project.

It is a company-wide tax, compliance and transformation project that restructures one of the most critical processes in the business.

The companies that succeed will not be those that merely generate XML files. They will be those that understand the business logic behind their invoices, establish clear ownership of the data and use technology to make their processes transparent, scalable and manageable.

Compliance cannot be bought with a new file format. It begins with understanding the business transaction behind the invoice.