VAT is the part of an e-invoice most files fail on — and almost never because an amount is wrong. They fail because “0 %” explains nothing in the structured part: the standard wants to know which category, which rate, and, where nothing is taxed, why not.
This is orientation, not tax advice. Whether a transaction falls under the reverse charge, is exempt or is outside the scope of VAT depends on the case. What follows is the question after that one: how is what your accountant established represented correctly in the file?
Three fields, not one
In an invoice under EN 16931, VAT lives in three places, and they get mixed up constantly:
| Item | On the line | In the breakdown (BG-23) |
|---|---|---|
| Category code | BT-151 | BT-118 |
| Rate in percent | BT-152 | BT-119 |
| Exemption reason | — | BT-120 (text) or BT-121 (code) |
The category code is not the rate. A rate of zero can mean: exempt, reverse charge, intra-community supply, export, or not subject to VAT at all — five different situations with five different codes and different mandatory fields. Writing “tax free” into the invoice text and setting the rate to 0 is therefore not enough.
Every combination of code and rate also forms its own BG-23 group. Several rates on one invoice are not a special case and need no EXTENDED profile: EN 16931 handles that already.
The category codes at a glance
The standard knows nine codes in total. Seven are above; in addition there are L and M for the Canary Islands IGIC and the IPSI in Ceuta and Melilla — outside Spain, almost never.
One mix-up first, because it runs through a lot of guides: the code for an intra-community supply is K. The business rules about it are called BR-IC-*. “IC” is not a category code but the name of the rule family — put “IC” in the field and you get a file that fails against the code list.
Reverse charge: code AE
Under the reverse charge, the buyer accounts for the tax, not the seller (in Germany § 13b UStG; in EU law Articles 194 ff. of the VAT Directive). In the XML that means:
- Category code AE on the line and exactly one AE group in the breakdown (BR-AE-01).
- Rate 0 (BR-AE-05) and tax amount 0 (BR-AE-09).
- An exemption reason: either the code
VATEX-EU-AEin BT-121 or the text “Reverse charge” in BT-120 (BR-AE-10). - Both sides identified: the seller’s VAT identifier or tax registration identifier and the buyer’s VAT identifier (BR-AE-02). This is the condition that trips people up most often.
On the visible page, the statement “Steuerschuldnerschaft des Leistungsempfängers” remains mandatory in Germany under § 14a (5) UStG; wordings from other official languages, such as “Reverse charge”, are equally acceptable. No separate tax amount is shown.
The expensive trap: a seller who states VAT anyway owes that tax under § 14c (1) UStG — while the recipient cannot deduct it as input tax. A single field in the wrong position costs money on both sides.
Intra-community supply: code K
Supplies of goods between businesses in different EU states are exempt where the conditions of Article 138 of the VAT Directive are met (in Germany § 6a UStG). The code for it is K, rate and tax amount are zero, and an exemption reason is mandatory — VATEX-EU-IC or the corresponding text (BR-IC-10).
Two fields that are otherwise optional become compulsory here, and neither of them sits with the amounts — both sit with the delivery:
- Actual delivery date (BT-72) or invoicing period (BG-14) shall not be blank (BR-IC-11).
- The deliver-to country code (BT-80) shall not be blank (BR-IC-12).
- Plus the seller’s VAT identifier and the buyer’s (BR-IC-02).
That is precisely why these invoices fail more often than others: treat the delivery details as decoration and you produce a file whose arithmetic is right and which is rejected anyway. Where those fields sit in the tree is covered in the structure of the XML.
On the tax side there is something no validator can check: since the “quick fixes” of 1 January 2020, a valid customer VAT identifier and a timely EC Sales List are substantive conditions of the exemption, not mere formalities. If either is missing, the exemption falls away even when the goods demonstrably crossed the border. In Germany the list is due by the 25th of the following month.
Exempt (E) — and the small business
E and Z are constantly confused. Z is the zero rate on goods and must carry no exemption reason (BR-Z-10). E is a genuine exemption and must carry one (BR-E-10). Code an exempt supply as Z and you get a formally valid file making the wrong statement — the validator says nothing, the tax office will.
For German small businesses under § 19 UStG, E is the normal case. Their turnover has been explicitly exempt since 1 January 2025 (before that, the tax was simply “not levied”), with new thresholds: €25,000 in the previous year and €100,000 in the current one, exceeding which switches the regime immediately. In the file it looks like this:
- Category code E, rate 0, tax amount 0.
- As the reason, a text in BT-120 referring to § 19 UStG. No VATEX code is provided for this case.
- Without a VAT identifier, the tax number does the job: BR-E-02 accepts BT-31, BT-32 or BT-63.
That reference is not a courtesy but a mandatory item under § 34a UStDV. The same provision exempts small businesses from having to invoice in a structured format at all: paper and a plain PDF remain permitted. They still have to receive e-invoices — that has applied to everyone since 1 January 2025, see deadlines by country.
Since 2025 there is also a cross-border variant: through the special reporting procedure under § 19a UStG, the Federal Central Tax Office issues a small-business identification number with the suffix “EX”, which lets the exemption be used in other member states — with EU-wide turnover of at most €100,000.
Check the VAT number before the invoice goes out
Formally the standard only checks the prefix: BR-CO-09 requires two letters per ISO 3166-1 alpha-2. A look into the validation rules shows the permitted list holds more than you would expect — besides GR also EL for Greece and XI for Northern Ireland. Whether the number exists is checked by nobody there.
For that there are two routes, and they are not equivalent:
- VIES, the European Commission’s service, answers one question: valid or not.
- The qualified confirmation request at the German Federal Central Tax Office (BZSt) under § 18e UStG additionally compares company name including legal form, town, postcode and street against the registered data. The answer is only “matches” or “does not match”, and a simple request has to precede it.
The difference becomes practical when someone asks for proof: the German VAT application decree names, in section 18e.1 (2), the BZSt result as the thing to be retained — as a printout, a file or a record taken into your system. There is no such provision for a VIES screenshot. Anyone checking numbers in bulk uses the BZSt interface rather than the web form.
In practice: check when a customer is created, record the date, and repeat for ongoing relationships — numbers become invalid without anyone telling you.
What goes wrong most often
| Mistake | What validation reports |
|---|---|
| Rate 0 with E, AE, K, G or O, but no exemption reason | BR-E-10, BR-AE-10, BR-IC-10, BR-G-10, BR-O-10 |
| Exemption reason entered on S or Z | BR-S-10, BR-Z-10 |
| AE set, but the buyer’s VAT identifier is missing | BR-AE-02 |
| K without a delivery date and without a delivery country | BR-IC-11, BR-IC-12 |
| “Not subject to VAT” alongside other groups on one invoice | BR-O-11 to BR-O-14 |
| Tax amount per group not rounded to two decimals | BR-CO-17, BR-S-09 |
The rounding cases are a story of their own — why one cent of difference stops an entire invoice is covered under business rules.
One mistake appears in no rule and is still the most dangerous: the visible page shows VAT while the XML says reverse charge. The German Ministry of Finance letter of 15 October 2025 makes clear that in hybrid formats the structured part prevails — a divergence puts the input tax deduction at risk. No validation flags it, because each part is fine on its own.
What E-Rechnung Pro can do here
Checking: all of it. The validator runs the standard’s Schematron, which includes the rule families BR-AE-*, BR-IC-*, BR-E-*, BR-G-* and BR-O-*. For incoming invoices with a reverse charge or an intra-community supply, that is the shortest route to the question of whether your supplier coded it cleanly.
Issuing: zero rate and exemptions. When an invoice carries 0 % VAT, the form asks which case it is — zero rated (Z), small business under § 19 UStG (E), reverse charge (AE) or intra-community supply (K) — and sets the category code accordingly. The BT-120 exemption reason is proposed in the invoice language and can be overwritten; AE and K also get the matching BT-121 code, while the small-business scheme has none. Whatever the case additionally requires is checked before you submit: both parties’ VAT IDs for AE, plus the delivery date and the delivery country for K. The exemption appears on the visible page too — the wording required by § 14a(5) UStG, or the reference to § 19 UStG, is printed with it.
Several cases in one invoice: yes. In the standard a VAT group is the pair of category code and rate — 19 % and 7 % are two groups, and so are S 19 % and AE 0 %. In the form each line therefore carries its own case, and one invoice may mix taxable and exempt lines. Every group gets its own breakdown in the XML with its own taxable amount, and every exemption its own reason. The visible page then shows a VAT column in the line table and one row per group in the totals block — the visible side and the XML say the same thing.
Frequently asked questions
Is it enough to write “reverse charge” in the invoice text?
No. For the structured part, what counts is category code AE with a zero rate and an exemption reason. In Germany the visible statement under § 14a (5) UStG remains mandatory on top of that — both together, not one instead of the other.
What is the difference between Z and E?
Z is the zero rate and must have no exemption reason. E is an exemption and must have one. For § 19 UStG and the exemptions under § 4 UStG, E is the right code.
Do I need a VATEX code for the exemption reason?
Not necessarily, a text in BT-120 is enough. For the clear-cut cases there are matching codes — VATEX-EU-AE, VATEX-EU-IC, VATEX-EU-G, VATEX-EU-O. For the small-business scheme, none is provided.
Does a German small business have to issue e-invoices from 2027?
No, § 34a UStDV exempts it; paper and PDF remain permitted. Receiving and archiving structured invoices, however, has been required since 1 January 2025.
My intra-community invoice fails although all the amounts are right. Why?
Almost always BR-IC-11 or BR-IC-12: the delivery date or invoicing period, or the delivery country, is missing. Both fields are mandatory only under code K, which is why they never stand out otherwise.
May one invoice contain several VAT rates?
Yes. Every combination of category code and rate forms its own BG-23 group. EN 16931 does this without an extension; no EXTENDED profile is needed for it.
Is a VIES query enough as proof?
For the question of whether the number is valid, yes. In Germany, though, it is the result of the qualified confirmation request at the BZSt that the VAT application decree names as the evidence to keep.
In short
- Category, rate and reason are three separate items — “0 %” on its own explains nothing.
- AE needs both VAT identifiers and a reason; stating VAT wrongly costs real money under § 14c UStG.
- K additionally needs a delivery date or period and the delivery country — that is where these invoices fail.
- E rather than Z for genuine exemptions, with the reference to § 19 UStG in BT-120.
- Check the VAT number beforehand, in Germany through the qualified BZSt request; its validity has been a substantive condition of the exemption since 2020.
- The visible page and the XML must say the same thing — where they differ, the XML decides.
Not sure whether an incoming invoice with a reverse charge or an intra-community supply is coded cleanly? Upload the file — those rule families run with it.