Convert invoices into e-invoices

The most common case in practice

Most companies that approach me do not start from a blank page. They have a system that has produced invoices reliably for years — just as PDFs. And they have an archive full of documents that have to remain traceable if in doubt.

So the question is rarely "where do we start" but "how do we get from what we have to what is required". That is exactly what a conversion is for.

From PDF to ZUGFeRD invoice

The most elegant route runs via ZUGFeRD. Your PDF stays exactly as it is — it merely gets an XML file embedded that contains the same details in machine-readable form.

For you nothing changes visually. For the recipient everything changes: their accounting software can process the invoice automatically instead of someone typing numbers.

For that to work, it must be reliably readable from the PDF which number is the net amount, which is the tax amount and which is the invoice number. With digitally generated PDFs that is solvable, because the text and its position are precisely available. I build rules tailored to your layout — and check the result arithmetically, for example whether the sum of the line items actually matches the stated total.

From legacy formats to XRechnung

The second large case is data that is structured but in a format from another era: CSV exports, fixed-length record files, homegrown XML structures or database tables.

Here the conversion is technically simpler, but the mapping becomes more demanding. EN 16931 has mandatory details that are frequently missing in data grown over time. Typical examples:

• the Leitweg-ID on invoices to public sector clients
• an unambiguous statement of payment terms
• tax categories in standard-compliant codes instead of free text
• the service period, which often only appears in running text

Such gaps can usually be derived from existing data. Where that is not possible I tell you, instead of inserting a placeholder that leads to rejection at the recipient.

Validation is part of it

A conversion without validation is worthless. That is why every file produced is validated against the official rules before it goes anywhere.

The result is a report you can read without technical background: which documents passed cleanly, which with a warning, which not at all. Each error states which field is affected and what the cause is — not the raw rule code from the validator.

In a bulk conversion this report is your most important tool. It shows you the typical patterns so you can fix things at the source instead of handling a thousand individual cases.

One-off or continuous

Some clients need exactly one run: the legacy archive is converted, after which a new system takes over. Others let the conversion run permanently because their upstream system cannot or should not be changed.

For continuous operation I build the conversion so that it runs unattended: you drop files or your system hands them over via an interface, the validated e-invoices appear in the target folder, errors land in a list with a notification. If you would rather have it in your own hands, I build you your own converter instead, which you operate and adjust yourself.