Generate e-invoices in your ERP

Why replacing the system is rarely the answer

When the e-invoicing mandate comes up, many vendors' first instinct is to sell a new system. That is understandable, but for you it is almost always the most expensive route.

An ERP change means data migration, process change, training and, for months, a team operating two systems in parallel. At the end you have a system that does the one thing you are missing today: produce a structured invoice file.

That one thing can usually be retrofitted far more cheaply.

Three ways to extend the ERP

Which one fits depends on how open your system is.

Extension inside the system

If your ERP offers an extension interface, a plugin concept or scripting, I build the generation directly into it. That is the most elegant route: the e-invoice appears in the same step as the PDF did before, and the user notices nothing.

Interface alongside

The second route is more common. Your ERP makes invoice data available — through an API, a scheduled export, a database view. A small service alongside picks that data up, creates the e-invoice, validates it, sends it and writes the status back.

The advantage: nothing inside the ERP changes. Your maintenance contract stays untouched and vendor updates keep running through.

Intermediate layer

If you have several systems producing invoices, a shared intermediate layer pays off. All systems deliver into it, and the layer handles the standard, validation, sending, archiving and logging. That way there is one place where format changes are maintained instead of five.

What often gets overlooked: the inbound side

A lot is said about sending, too little about receiving. Yet receiving has been mandatory since 1 January 2025 — with no transition period.

Every German company has to be able to accept and process e-invoices. An email with an XML file nobody can open does not meet that.

Inbound processing includes:

• recognising the file, whether pure XML or a hybrid ZUGFeRD PDF
• reading the details out and checking them against the standard
• matching the document to a supplier, an order or a project
• producing a human-readable view, because nobody enjoys checking raw XML
• storing the document in an audit-proof way

I build this part along with the rest on request, because it is needed anyway and saves the most work in daily operations.

The route to the recipient

The e-invoice also has to arrive. Depending on your customer base, different routes lead there:

• Public sector clients receive through central portals such as the federal ZRE or the state OZG-RE. The Leitweg-ID is mandatory there.
• Domestic companies predominantly accept sending by email with an attached file.
• Internationally much runs over the Peppol network, which requires access through an Access Point.

I set up the routes you actually need and log every dispatch traceably. If your system is so specific that an integration will not hold, then a dedicated application is the more honest route — and I will say so in the intro call.