EU E-Invoice APIE-invoicing in Germany from 1 January 2027: a developer guide
From 2027, businesses with more than €800,000 prior-year turnover must issue e-invoices for domestic B2B sales in Germany, and from 2028 everyone must. What this means for invoicing, shop and ERP software, which formats count, and which rules invoices fail in practice.
As of 29 October 2026. Not tax or legal advice. Language: Deutsch
The deadlines
| From | Who | What |
|---|---|---|
| 1 January 2025 | every business in Germany | must be able to receive e-invoices (an e-mail inbox is enough) |
| 1 January 2027 | businesses with more than €800,000 total turnover in the previous year | must issue e-invoices for domestic B2B supplies |
| 1 January 2028 | every business | must issue e-invoices; paper and PDF are no longer allowed for domestic B2B invoices |
Exempt are, among others, small invoices up to €250 and travel tickets. Invoices to consumers (B2C) are not covered.
What counts as an e-invoice
An e-invoice is an invoice in a structured electronic format that complies with the European standard EN 16931. A PDF is not an e-invoice. In practice there are two format families:
- XRechnung (plain XML in UBL or CII syntax), maintained by KoSIT. Mandatory for public procurement and common in B2B.
- ZUGFeRD / Factur-X: a PDF/A-3 with an embedded CII XML. According to the Federal Ministry of Finance's letter of 15 October 2024, the profiles EN 16931, EXTENDED and XRECHNUNG are e-invoices, MINIMUM and BASIC WL are not. The XML is what counts, not the picture in the PDF.
Germany does not prescribe a channel: e-mail, portal, API or Peppol are all fine.
What your software has to do
Issuing: write an XRechnung or a ZUGFeRD PDF in profile EN 16931 or higher, with every mandatory field, and validate it against the official rules before sending. The rules change several times a year: KoSIT publishes new validator configurations and FeRD new ZUGFeRD versions. An invoice that passed once can fail after a rule update.
Receiving: recognise incoming files (XML, or PDF with embedded XML), validate them and take the data into bookkeeping instead of retyping the PDF. Since every business has had to accept e-invoices since 2025, this is the feature customers ask for first.
The most common errors
These rules fail particularly often on XRechnung invoices. Each rule has its own page with the official text and the technical check:
| Rule | Meaning | Typical cause |
|---|---|---|
BR-DE-15 | Buyer reference (BT-10) missing | For public bodies the Leitweg-ID; in B2B the reference the buyer asked for |
BR-DE-2 | Seller contact (BG-6) missing | Name, phone and e-mail of a contact point not filled |
BR-DE-1 | Payment instructions (BG-16) missing | Payment means and bank details not sent |
BR-DE-23-a | Credit transfer without account (BG-17) | Payment means 30 or 58 without an IBAN |
BR-DE-21 | Specification identifier (BT-24) is not XRechnung's | Identifier of another XRechnung version or of plain EN 16931 |
BR-CO-10 | Sum of line amounts does not match | BT-106 computed from unrounded line amounts |
BR-CO-15 | Gross amount ≠ net + VAT | VAT rounding difference |
BR-CL-23 | Unit of measure not from the code list | "pcs" instead of the UN/ECE code C62 (one) or H87 (piece); see the unit codes |
All rules: rule index.
Validate, parse and generate by API
The EU E-Invoice API validates XRechnung and ZUGFeRD with the official KoSIT validator and the FeRD rules, parses invoices into clean JSON and generates valid XRechnung and ZUGFeRD PDFs from JSON. Every finding links the page of its rule (docUrl), so your software can explain an error without a support ticket. The Free plan includes 100 documents a month.
curl -H "Authorization: Bearer $API_KEY" --data-binary @invoice.xml \
https://einvoice-api-main-f5141d8.zuplo.app/v1/validateMore: quickstart (Markdown) · API reference · API or self-hosted KoSIT validator?
Check a single invoice for free in the browser, without sign-up.