Is an email inbox really enough?

For the receiving obligation in the narrow sense, yes. It is not enough for the retention duty, where the structured original counts — and an inbox is not an archive.

Which formats must I be able to accept?

Practically all the common ones. You have no choice when receiving: one supplier sends ZUGFeRD, the next a UBL XRechnung, the third a CII XRechnung. A process that knows only one format breaks on the second supplier.

Do I have to validate incoming invoices?

It is not prescribed. It is very sensible: otherwise you book data nobody has checked, and you notice a fault only once it is in the ledger.

May I reject a faulty e-invoice?

You can and should raise it — citing the rule that fails. That is more precise than 'your invoice is wrong' and saves both sides a round trip.

What about the PDF my supplier sends alongside?

If XML and PDF arrive separately, the XML is the original. If a ZUGFeRD arrives, the one file is the original. Avoid filing both in either case — otherwise you have two versions of the truth.

Receiving e-invoices: what comes after the inbox

The duty is small, the task is not

Since January 2026 every business must be able to accept e-invoices — with no transition period and no turnover threshold. This stage takes surprisingly little to satisfy: an email address you give your suppliers is formally enough.

That is exactly where many stop, and exactly where the problem starts. The receiving obligation is not the only duty that attaches to an incoming invoice. There are also retention, traceability and — if you want to deduct input tax — checking the mandatory details.

The flow you need

1. A reliable intake

A named address, not one employee's personal mailbox. This is not about technology but about resilience: invoices left sitting during a holiday turn into reminders.

2. Recognise the format

You will get at least three variants, and nobody announces them:

What arrives	Where the data sits
XRechnung as UBL	directly in the XML file
XRechnung as CII	directly in the XML file
ZUGFeRD / Factur-X	in the XML inside the PDF file
ordinary PDF	nowhere — not an e-invoice

🔴 The fourth row matters: a supplier still sending a normal PDF has not sent you an e-invoice. That is their problem — it becomes yours if you do not notice.

3. Read out the structured original

For an XRechnung that is the file itself. For ZUGFeRD the XML sits in the PDF's attachments — looking only at the visible PDF means you do not have the data.

💡 And regardless of syntax: your processing should read CII and UBL alike and map both onto the same internal model. Otherwise you maintain two paths that do the same thing.

4. Check before you book

Validating incoming invoices is not prescribed. It is sensible for a very practical reason: a fault you catch at intake is a query. The same fault caught after posting is a correction.

Checking also tells you which rule is violated. A complaint quoting the rule ID is fixed by the supplier in minutes; "your invoice is faulty" costs both sides a round trip.

5. Retain — the original

The point where most gaps appear. What you retain is the file as it arrived, in its native format:

XRechnung → the XML file
ZUGFeRD → the PDF file including its embedded XML

Not sufficient: a printout, a PDF view generated from the XML, or with ZUGFeRD only the extracted XML without its shell.

The three gaps that show up in practice

The e-invoice is treated like a PDF. The intake system files it, somebody reads it on screen and types the values in. That is permitted and throws away the entire benefit — the data was already structured.

The archive receives a derivative. A handsome PDF view of the XRechnung goes into the archive, the original does not. Surfaces only during an audit.

Nobody notices a missing invoice. Deliveries fail, mailboxes overflow, filter rules catch too much. Without a reconciliation you find out through the reminder.

What you get out of it

The receiving obligation is often felt as a nuisance, because it comes first and initially returns nothing. That is only true while you stop at the inbox.

Every incoming invoice you read out in structured form replaces a manual entry — along with the errors that come with one. The effort sits in the one-time setup; the benefit accrues on every document.

🔵 Hence the advice if you are late: start with receiving, not with issuing. The obligation already applies, the effort is smaller, and it is the side that pays back immediately.