E-Invoicing: What Brands Have to Change Now

Most founders think they already invoice electronically. They send a PDF by email, and under the new German rules that is exactly what an e-invoice is not.

The difference sounds like paperwork and it is more than that. It decides whether your bookkeeping gets easier or harder over the next few years. We built our own invoicing and bookkeeping system, with ZUGFeRD, Qonto and a DATEV export. Here is what we learned along the way, and what you practically have to do.

One thing up front: this is not tax advice. I am not a tax advisor and not a lawyer. Which deadline applies to your company, which transition rules kick in and what is permitted in your case is something you settle with your tax advisor. This article describes the technology and the process, not the legal situation.

What makes an invoice an e-invoice

An e-invoice is an invoice in a structured, machine-readable data format. Not a picture of an invoice. The data itself.

The difference in one sentence: a PDF has to be read by a human or guessed at by text recognition. An e-invoice can be read straight into software, because every field is labelled.

The data then says unambiguously what the invoice number is, what the net amount is, what the tax rate is, what the service date is. No searching, no extraction, no transposed digits.

Two formats keep showing up in Germany:

We went with ZUGFeRD for a very practical reason: it works in both worlds. The customer whose bookkeeping still runs by hand sees a familiar PDF. The customer with modern software pulls the data. You do not have to guess how far along the other side is.

Receiving and sending are two separate jobs

This is the point I most often see misunderstood. E-invoicing is not one change. It is two.

Receiving means you have to accept e-invoices and process them properly. That hits you regardless of what you send yourself, because your suppliers decide it.

Sending means your outgoing invoices exist in a structured format. That concerns your own invoicing and your shop system.

The stages of the obligation are staggered over time, and they do not apply to receiving and sending at the same moment. Receiving generally comes first, the obligation to send follows later and is staggered by company size and revenue. There are transition periods, and there are exceptions, for small-amount invoices and for certain kinds of sales.

Which stage applies to you and when is exactly the question for your tax advisor. Ask them two things specifically: from when you have to be able to receive, and from when you have to send.

What you should know regardless of any deadline: the retention requirement covers the structured data, not only the picture of the invoice. A printed PDF in a folder does not replace the file.

What this means day to day in a shop

In e-commerce, three areas are affected. Sort them out once and the whole thing becomes manageable.

First: invoices to business customers. If you sell B2B, to resellers, companies or public bodies, that is your most important area. This is where you land in the obligation to send fastest.

Second: invoices from suppliers. Fulfilment partners, agencies, software vendors, purchasing. Here you are on the receiving side, and the change happens without you doing anything. At some point your suppliers will send structured invoices, whether you are ready or not.

Third: invoices to consumers. Classic shop sales to private individuals are affected differently than business-to-business trade. That is another question for the tax advisor, but it is usually not the area that hits you first.

In practice that means your first worry is not your shop checkout. Your first worry is the inbox where supplier invoices arrive.

What you actually change

Here is the order I would recommend. It follows the effort, not the excitement.

What our own setup looks like

We built this because we needed it ourselves, not as a concept. Three brands plus an agency mean a lot of invoices in both directions.

On the outgoing side our system produces invoices directly in ZUGFeRD format. The PDF looks like our normal invoice layout. Embedded inside it sits the structured file with all the fields. The customer does nothing differently than before, but their software can now read along.

On the incoming side our document scanner runs. Invoices come in through a fixed channel, get read out and matched to the right bank transaction. With a structured invoice this step is far safer, because nothing has to be guessed. How that part works is in capturing and checking receipts automatically.

Behind that hangs the rest of the chain. Our bank is Qonto, the system pulls the transactions through the interface. Rules classify whatever repeats, AI suggests a category for the rest, unclear cases land in a review list. At the end there is a DATEV export for the tax advisor. DATEV is the accounting standard German tax advisors work with. I wrote the complete setup up in automating bookkeeping with AI.

The side effect I had underestimated: structured data also improves the view forward. When invoice data is clean, you can build a real payment plan from it instead of reading your account balance. How we use that is in cash flow forecasting for brands.

The limits

So you do not get too pretty a picture:

Conclusion

E-invoicing is less dramatic than the panic posts suggest, and less trivial than it feels.

The core is simple: structured data instead of a picture. Sort out receiving first, then sending. Set up one fixed inbound channel, ask your tools about their formats, get your master data in order. And sit down with your tax advisor once to clarify your specific deadlines.

Do it properly and the obligation stops being an annoyance. It becomes the occasion you would have needed anyway. For us it was exactly the trigger to build the whole chain, from receipt to DATEV export, properly for once.

If you want a setup like that without building it yourself: that is what we do at Flowhouse. Write to us, we are happy to walk you through our own system in detail.