Incoming invoices

Checking incoming e-invoices: what the BMF asks for, and what it does not

Since the BMF letter of 15 October 2025 there are three named classes of error — and only two of them touch the input VAT deduction. This page sorts out what a technical check on receipt can do, and what it explicitly cannot.

The three classes of error

The letter separates them because they have different legal consequences. That is the change that matters most in practice: "the invoice is faulty" has not been a useful sentence since.

1 · Format errors

The file does not meet the EN 16931 syntax — wrong file format, broken XML, missing technical mandatory fields. Consequence: it is not an e-invoice but an "other" invoice, and once the transition periods end that can affect the input VAT deduction.

Machine-detectable. This is exactly what schema validation checks.

2 · Business-rule errors

Breaches of the EN 16931 check rules and their national extension: a missing buyer reference, amounts that contradict each other. They matter for VAT only insofar as they affect a mandatory particular.

Machine-detectable — these are the BR-Regelcodes, checked against KoSIT rule set v2026-08-31.

3 · Content errors

A wrong tax rate, an inaccurate description of the supply, an incorrect VAT ID. These bear directly on the input VAT deduction — regardless of whether the file passes every technical check.

Not machine-detectable. No validator anywhere can see that 7 % should have been 19 %.

The sentence this page will not say

"The invoice validated, so the input VAT deduction is safe." That is precisely not what the letter says. Class 3 survives every technical check, and reviewing the substance of an invoice stays exactly where it was: with a person who knows what was ordered.

What a check on receipt does is narrower and still worth having: it sorts out the two machine-detectable classes before anybody spends time on them, and it produces a dated record that the check happened.

What has to be kept

The structured part, unchanged. For VAT purposes at least the XML has to be kept as it arrived — not a PDF rendered from it and not a database extract.
The validation report. The letter names retaining validation reports explicitly; it is the record that the diligence was applied whose result you then rely on.

NormAPI stores neither the document nor the report. Both belong in your archive rather than ours — the API response is the report, and what you do with it stays with you.

Automated on receipt

The same call as on the sending side, at a different point in the process: the file as it arrived, against the official rule set.

$ curl -X POST api.normapi.de/v1/validate \
    -H 'Content-Type: application/xml' \
    --data-binary @eingang.xml

Back comes the format and scenario that were recognised, every finding with its rule code, severity and location, and the rule-set version it was checked against. That version belongs in the report: a result without the version behind it cannot be interpreted two years later.

One case that turns up in practice and is easy to misread: when the official KoSIT configuration has no scenario for the profile that arrived — Factur-X EXTENDED, for instance — the business rules are not evaluated at all. The report then does not say "no errors" but "not checked". We return that as its own field so that a receiving process cannot book it as a pass.

Who this is for

Tax practices that take in documents for many clients and have to sort the inbox before anything is posted.
Bookkeeping and document-management vendors that want the checking step inside their product rather than left to their customers.
Companies running their own invoice intake that want the report filed in an auditable way.

Check one incoming invoice API documentation Pricing

Source: the BMF letter of 15 October 2025 on issuing invoices under § 14 UStG (the second application letter on e-invoicing). This page summarises what it means for technical checks on receipt; the letter itself governs. To the guide on the e-invoicing mandate. NormAPI provides technical validation, not tax or legal advice.