AboutServicesWorkArticles
← Back to Services

E-Invoicing Integration: Peppol, XRechnung, ZUGFeRD and Factur-X for Systems That Were Not Built For It

Buying an e-invoicing product is easy. The problem is almost never the product. It is the twelve-year-old order management system that produces your invoices, the pricing logic nobody has documented, and the fact that your invoice numbers come from a stored procedure written by someone who left in 2019.

We build the connector between what you actually run and what the mandate requires. Structured invoice generation, validation, network transmission, inbound processing and archiving, wired into your existing system rather than replacing it.

The mandates, and when they bite

Europe is converting from PDF invoices to structured, machine-readable ones on a country-by-country schedule, ahead of the EU's VAT in the Digital Age (ViDA) package that harmonises it all. The dates that currently drive projects:

  • Germany: receiving structured e-invoices has been mandatory since 1 January 2025. Issuing becomes mandatory on 1 January 2027 for businesses with turnover above EUR 800,000, and 1 January 2028 for everyone else. The formats in practice are XRechnung (pure XML) and ZUGFeRD 2.x (a hybrid PDF with embedded XML), both conforming to EN 16931.
  • France: receiving, and issuing for large and mid-sized companies, from 1 September 2026; issuing for SMEs from 1 September 2027. Transmission runs through registered platforms, with Factur-X as the common hybrid format.
  • Belgium: mandatory B2B e-invoicing via Peppol since 1 January 2026, with e-reporting on a five-corner model planned for 2028.
  • Poland: KSeF, the national clearance platform, with its own XML schema and its own timetable.
  • Italy: SdI and FatturaPA, live since 2019 and still the strictest clearance model in the EU.
  • Spain: Verifactu and the Crea y Crece invoicing obligations rolling out alongside the regional TicketBAI systems.

If you sell across several of these, you do not have one project. You have one architecture and several country adapters, and the difference between treating it that way and not is the difference between one integration and five.

Where projects actually go wrong

The invoice data does not exist in the shape the standard wants. EN 16931 requires fields many systems never captured: a proper buyer reference, VAT breakdowns per rate rather than per line, structured payment terms, unit codes from a controlled vocabulary. The engineering work is reconstructing those fields from what you have, deterministically, for every invoice you will ever issue.

Validation failures arrive after the fact. A rejected invoice is an unpaid invoice. Validation has to run before transmission, against the current schema and the current country business rules, with failures surfaced to a human who can act on them rather than logged to a file.

Inbound is harder than outbound. Everyone plans for issuing invoices and forgets that from the receiving date they must accept structured invoices from every supplier, in any conforming format, and get them into accounts payable without a person opening each one.

Numbering and idempotency. Retries, network timeouts and platform outages are normal. An invoice sent twice under two numbers is a tax problem, not a software one. This has to be right at the start.

What we build

Assessment and format decision

A short engagement (usually one to two weeks), in which we look at how your invoices are actually produced, which mandates reach you and when, and what your realistic options are. The deliverable is a written recommendation: which formats you need, whether Peppol access should be through a provider or your own access point, what has to change in your source system, and what it costs.

Sometimes the recommendation is that a standard product plus a small adapter will do it. We would rather tell you that in week one than bill you for six months.

Invoice generation and mapping

We build the mapping layer from your source data to the required syntaxes (UBL and CII under EN 16931, XRechnung, ZUGFeRD 2.x, Factur-X, FatturaPA, KSeF XML), with the field derivations documented so an auditor and your finance team can both follow them. Where the source system cannot supply a mandatory field at all, we say so early and design the capture rather than inventing a default.

Validation before transmission

Schema validation, Schematron business rules, and country-specific checks run before anything leaves your building. Failures are routed to a queue a human owns, with a message that says which field failed and why, not a stack trace.

Network connection

Peppol Access Point connection, either through an established provider or by running your own, depending on volume and how much control you need. For clearance-model countries we integrate directly with the national platform (KSeF, SdI, the French PDP ecosystem), including the certificate and authentication handling that these platforms all do differently.

Inbound processing

Receiving, validating and normalising supplier invoices into a single internal representation, matched against purchase orders and goods receipts where those exist, and delivered into your accounts payable workflow. This is where the return on the project usually comes from, because it removes manual keying that nobody ever measured.

Archiving and audit trail

Compliant storage of the original structured document, in a form and for a period that satisfies German GoBD, Italian conservazione sostitutiva or the equivalent rules where you operate, with the retrieval path tested rather than assumed.

Systems we integrate with

SAP ECC and S/4HANA, Microsoft Dynamics 365 and Business Central, Odoo, NetSuite, Sage, Infor, Xero, DATEV interfaces, and (most often) a custom or heavily modified system that is central to how the business runs and is not going to be replaced for a mandate. We work in .NET, Java, PHP, Python, Node.js and, when that is what is in front of us, older stacks.

If you run a marketplace, a subscription platform or a billing engine that issues invoices programmatically at volume, that is squarely the case we are built for: the invoice is generated by your code, so the compliance has to live in your code.

What this is not

We do not sell invoicing software and we are not an accounting package. If you are a small business looking for a tool that produces compliant invoices, buy one: DATEV, sevDesk, Lexware and a dozen others do this well and cost a fraction of an integration project.

Come to us when the invoice is produced by a system you already own, when several countries' rules have to coexist, or when volume means this has to run without anybody watching it.

How engagements run

Assessment, one to two weeks, fixed price, ending in a written recommendation and a costed plan.

Build, typically six to twelve weeks for a first country, depending on how clean the source data is. We work in your repository, in your branch strategy, with your team, and we leave tests behind.

Pilot, running real invoices to a small set of counterparties in parallel with the existing process, until the failure rate is where it should be.

Cutover and support, with the failure queue monitored and someone accountable for it, through the first month-end and the first VAT filing, which is when the questions that matter actually surface.

Standards we work to

EN 16931 and its syntax bindings (UBL 2.1, UN/CEFACT CII), Peppol BIS Billing 3.0 and the Peppol transport infrastructure, XRechnung and the KoSIT validator, ZUGFeRD 2.x and Factur-X profiles, FatturaPA, KSeF, and the ViDA proposals shaping what comes after 2030.

Frequently asked questions

When exactly does the German e-invoicing obligation apply to us?

Receiving has applied to all German businesses since 1 January 2025. Issuing applies from 1 January 2027 if your prior-year turnover exceeded EUR 800,000, and from 1 January 2028 otherwise. The obligation covers domestic B2B transactions; the treatment of cross-border and B2C invoicing differs and is worth confirming with your tax adviser.

What is the difference between XRechnung and ZUGFeRD?

XRechnung is pure XML, defined by the German public sector and mandatory for invoices to public authorities. ZUGFeRD 2.x is a hybrid: a PDF/A-3 document with the same structured data embedded inside it, so a human can read the PDF and a machine can read the XML. Both conform to EN 16931. Commercial B2B practice in Germany leans towards ZUGFeRD; many buyers accept either.

Do we need our own Peppol Access Point?

Usually not. Most companies connect through an existing access point provider, which is cheaper and faster. Running your own makes sense at high volume, when you need control over the transport layer, or when you are providing invoicing services to others.

Can you work with our existing e-invoicing vendor?

Yes, and often that is the right shape: the vendor handles transmission and network membership, we build everything between your system and their API, the mapping, the validation, the retries, the failure handling and the reconciliation.

What happens to invoices that fail validation?

They go to a queue with a readable explanation of which field failed which rule. We design that queue deliberately, because in the first months after go-live it is the most-used part of the system, and a bad one turns a compliance project into a permanent manual process.

How do you avoid sending the same invoice twice?

A stable idempotency key derived from your invoice identity, carried through every retry, plus a transmission log that is the authority on what was sent. Any retry reuses the original identifier rather than generating a new one.

Get started

Tell us which countries you invoice into, roughly how many invoices a month, and what produces them today. We will tell you which mandates reach you, in what order, and whether this is a connector or a project.

Contact us to book an e-invoicing readiness assessment.

Related services

Ready to get started with this service?

Get in Touch
← Back to All Services