EU E-Invoicing: ViDA, Peppol and Digital Product Passports

Two EU changes reach the same company systems. ViDA moves business invoicing to structured e-invoices and digital reporting. Digital product passports add a record of what a product is made from and where it came from. One change touches the invoice. The other touches the product data behind it. Companies that sell into the EU may meet both.

What ViDA Asks of Your Systems

Under ViDA, an invoice to an EU customer must be more than a document. It is validated as structured data, stamped and cleared, not just issued. The invoice and the authority's response become part of the record.

The Peppol network is one route for structured invoice exchange between systems. National platforms and reporting channels are others. A company with several EU entities may meet more than one route at once.

The work starts in the ERP. Customer records, tax codes, item data and amounts must be correct before the invoice is built. The invoice then needs a mapping to the required format, a validation step, a submission and an exception path. A rejection must reach someone who can fix the source data, and the corrected invoice must keep its link to the original.

This is not a one-off project. Formats, reporting rules and national connections change. The company needs a mapping it can update and a team that can see what happened to each invoice.

What Digital Product Passports Ask of Your Systems

A digital product passport is a record of a product's materials, origin and supply chain that the EU will require for many products. The data usually sits in several places: the ERP, product information systems, quality records and suppliers' files.

The passport asks a company to collect that data as goods are made and to keep it linked to the product. It also asks for traceability along the chain, so a passport can be trusted and a recall or audit can follow a part from supplier to customer.

The EU publishes the product groups and the timetable that apply. Check the current scope with your trade or legal team. The systems question is the same either way: who owns each data field, how it is collected and how it is shared with the next party.

Where the Two Changes Meet

Both changes depend on master data. An item sold to an EU customer needs a correct invoice and a correct product record. If the invoice mapping and the passport data are built as separate projects, the company pays twice for the same data work.

Both also depend on suppliers. A supplier that sends a PDF invoice or a spreadsheet of materials creates manual work downstream. A supplier that sends structured data removes it. The integration layer is where that difference is handled.

Where Projects Get Stuck

• Several ERPs and legal entities produce invoices in different ways.

• Customer tax data is held in a CRM and never reaches the billing system.

• The invoice format is assembled by a template, so every rule change is a release.

• Product data sits with suppliers and is rekeyed into the ERP by hand.

• A rejection or a missing passport field has no owner.

• The evidence for an audit is rebuilt by hand after the event.

What to Do First

Map the invoice flows first. List each EU entity, the invoices it issues and the route each one takes. Build one route end to end in a test environment, including the response and the exception path.

Then map the product data. For one product group, list the fields a passport needs, the system that owns each field and the supplier that provides it. Find the gaps before the deadline finds them.

Keep both maps together. The customer, item and tax data they share is the place where most errors begin. A single owner for master data prevents a fix in one flow from breaking the other.

How XSIS Helps

XSIS connects ERPs to e-invoicing and product-data flows, with written mappings, validation, exception handling and evidence. We do not give legal advice. Your legal and trade teams decide how the rules apply, and we build the systems that carry those decisions.