De Duitse E-Rechnung-plicht: uiterlijk 1 januari 2027 gestructureerde facturen uit uw eigen systemen

Vanaf 1 januari 2027 mag een Duits bedrijf met een omzet van meer dan € 800.000 in 2026 geen papieren factuur of pdf-factuur meer sturen aan een ander Duits bedrijf. De factuur moet een gestructureerde e-factuur zijn: een databestand dat is opgebouwd volgens de Europese norm EN 16931. Vanaf 1 januari 2028 vervalt de drempel en geldt de regel, op een paar smalle uitzonderingen na, voor elk bedrijf.

Voor een klein bedrijf komt dit binnen als software-update. Voor een bedrijf waarvan de facturen uit een eigen factureringssysteem komen, uit een branchepakket of uit een ERP-systeem dat vijftien jaar lang is aangepast, is het een softwareproject, en er zijn nog ongeveer dertien weken. Dit artikel is voor die tweede groep.

Wat de wet zegt

De definitie staat in § 14 UStG: een factuur “die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht”. Het formaat moet voldoen aan de Europese norm op grond van Richtlijn 2014/55/EU (in de praktijk EN 16931), of door de partijen zijn afgesproken, mits de vereiste gegevens juist en volledig kunnen worden omgezet naar een vorm die met die norm verenigbaar is. Een pdf kwalificeert niet, hoe netjes hij er ook uitziet.

De verplichting geldt voor leveringen aan een ander bedrijf waarbij beide partijen in Duitsland zijn gevestigd. De overgangsregeling staat in § 27 Abs. 38 UStG:

• Leveringen in 2025 en 2026 mogen nog op papier worden gefactureerd, of in een ander elektronisch formaat als de afnemer daarmee instemt, zolang de factuur uiterlijk 31 december 2026 de deur uitgaat.
• Leveringen in 2027 krijgen dezelfde ruimte tot 31 december 2027, maar alleen als de totale omzet van de uitgever in het vorige kalenderjaar niet hoger was dan € 800.000.
• EDI dat niet aan de norm voldoet, mag voor leveringen in 2027 blijven bestaan, met instemming van de afnemer, ongeacht uw omvang.

Drie details wegen zwaarder dan ze lijken.

De drempel wordt gemeten op de omzet van vorig jaar. Uw positie in 2027 hangt af van uw cijfer over 2026, dat niemand precies kent tot de boeken zijn afgesloten. Zit u ergens in de buurt van € 800.000, bouw dan alsof u erboven zit.

De overgangsruimte eindigt op een verzenddatum. Letterlijk gelezen dekt de eerste overgangsregel papier en pdf niet meer na 31 december 2026, ook niet voor werk dat in 2026 is gedaan. Zit u boven de drempel en factureert u achteraf, dan moet de factuur die u in de eerste week van januari verstuurt voor het werk van december al gestructureerd zijn. Laat dit bevestigen door uw belastingadviseur, maar plan geen livegang half januari.

Sommige facturen vallen erbuiten: facturen aan consumenten, grensoverschrijdende facturen, facturen voor kleine bedragen tot € 250 bruto, vervoersbewijzen die als factuur gelden, facturen van Kleinunternehmer (de Duitse kleineondernemersregeling) en leveringen die zijn vrijgesteld op grond van § 4 Nr. 8 tot en met 29 UStG.

Wij kennen geen wetsvoorstel dat deze data verschuift. Plan alsof ze blijven staan.

Ontvangen geldt al sinds 2025. Uitreiken is het nieuwe deel.

Sinds 1 januari 2025 moet elk Duits bedrijf e-facturen kunnen ontvangen. De FAQ over e-facturatie van het Duitse federale ministerie van Financiën is daar kort over: “Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.” Een mailbox volstaat.

Let op één zin in § 14 zelf: waar de e-factuurplicht geldt, is de instemming van de ontvanger niet nodig. Een Duitse zakelijke klant kan uw gestructureerde factuur niet weigeren.

Uitreiken is een ander probleem. Bij ontvangen leest een tool het bestand van iemand anders. Bij uitreiken is uw systeem de auteur: kloppen de gegevens bij de bron niet, dan kan niemand verderop in de keten ze nog herstellen, en een factuur die de validatie van uw klant niet doorstaat, blijft onbetaald liggen.

Wie dit met een update krijgt

Zonder omwegen: bent u een klein bedrijf dat factureert vanuit DATEV, lexoffice, sevDesk of een vergelijkbaar pakket, dan levert uw leverancier het formaat. Controleer uw stamgegevens (btw-identificatienummer, klantadressen, bankgegevens), zet de functie aan en verstuur een testfactuur. U hebt geen project nodig en geen softwarebedrijf.

Ongeveer hetzelfde geldt voor een gangbaar ERP-systeem dat nog dicht bij de standaard zit: de leverancier of uw implementatiepartner levert de output, en het werk bestaat uit configureren en testen.

De rest van dit artikel is voor bedrijven waarvan de facturen uit code komen die ze zelf bezitten, of uit code die niemand meer onderhoudt:

• factureringsengines in abonnementsplatforms, marktplaatsen en nutsbedrijven, die facturen programmatisch en in grote aantallen uitreiken;
• branchesoftware voor groothandel, bouw, logistiek of buitendienst, waarvan de leverancier klein is, traag of niet meer bestaat;
• ERP-systemen waarvan de factuuroutput jaren geleden is herschreven als eigen printprogramma's, rapportsjablonen of een maandelijkse mailmerge.

De formaten: EN 16931, XRechnung en ZUGFeRD

EN 16931 is de Europese norm. Die definieert het semantische model van een factuur (de velden, wat ze betekenen, welke verplicht zijn en welke bedrijfsregels ertussen gelden) en koppelt dat aan twee XML-syntaxen, UBL 2.1 en UN/CEFACT CII.

XRechnung is de Duitse specificatie bovenop EN 16931, beheerd door KoSIT: pure XML in een van beide syntaxen, verplicht bij overheidsinstanties en tussen bedrijven even geldig. Volgens de XRechnung-pagina van KoSIT geldt versie 3.0 sinds 1 februari 2024 en blijft die minstens tot 31 juli 2027 geldig. In september 2026 is een voorlopige versie van 4.0 gepubliceerd; de definitieve release wordt in het voorjaar van 2027 verwacht. U gaat live op 3.0 en upgradet binnen uw eerste jaar.

ZUGFeRD is een hybride: een PDF/A-3-bestand met ingesloten CII-XML. Mensen lezen de pdf, machines lezen de XML. In Frankrijk heet hetzelfde formaat Factur-X, en technisch zijn de twee identiek. FeRD publiceerde versie 2.5.2 op 4 augustus 2026. ZUGFeRD kent profielen (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), en de FAQ van het ministerie accepteert ZUGFeRD vanaf versie 2.0.1 “mit Ausnahme der Profile MINIMUM und BASIC-WL”.

Bij een hybride factuur telt de XML. De FAQ noemt het gestructureerde deel het “führender Teil”, het leidende deel. Spreken uw pdf en uw XML elkaar tegen, dan is de pdf fout.

Voor de meeste Duitse B2B-uitgevers is de verstandige standaard ZUGFeRD in het profiel EN 16931, zodat klanten die facturen nog met het oog lezen gewoon verder kunnen, plus XRechnung voor overheidsinstanties en iedereen die erom vraagt. Beide horen uit één intern factuurobject te komen, niet uit twee codepaden.

Wat er in uw systeem moet veranderen

De factuur wordt data, geen opmaak

Veel oudere systemen bouwen de factuur pas bij het printen op: tekst die in een sjabloon wordt geplakt, totalen die in het rapport worden opgeteld, de btw-vermelding als hardgecodeerde alinea. Niets daarvan overleeft EN 16931. U hebt een opgeslagen factuurobject nodig dat elk veld bevat, en zowel de XML als de pdf worden daaruit gegenereerd.

De velden die meestal ontbreken of niet kloppen:

• Partijgegevens. Gestructureerde adressen met ISO-landcodes, en een btw-identificatienummer of Duits belastingnummer. Adresblokken in vrije tekst moeten worden opgesplitst.
• Leverdatum of prestatieperiode, vastgelegd als data in plaats van als zin in de kop.
• Eenheden. Elke hoeveelheid heeft een code nodig uit UN/ECE-aanbeveling 20 (H87 voor stuk, KGM voor kilogram, DAY voor dag). “Stk.” en “pauschal” moeten worden omgezet.
• Btw. Elke regel draagt een btw-categorie en een tarief. De factuur bevat één btw-uitsplitsing per combinatie van categorie en tarief, en de totalen moeten op twee decimalen exact kloppen. Systemen die de btw per regel afronden, lopen hier vast.
• Teksten voor vrijstelling en verlegging. De zin onderaan de pdf wordt een code voor de btw-categorie plus een reden van vrijstelling.
• Betaling. Betaalwijze, IBAN en betalingsvoorwaarden in gestructureerde vorm.
• Referenties. Het ordernummer of de afnemersreferentie waarop de crediteurenadministratie van uw klant matcht. Hebt u die nooit opgeslagen, begin er dan nu mee.

Regels met alleen tekst (“levering zoals afgesproken”) zijn een veelvoorkomend struikelblok. In een gestructureerde factuur is een regel een factureerbare regel, dus zo'n tekst hoort in een notitie.

Correcties, creditnota's en selfbilling

De FAQ is duidelijk: waar de e-factuurplicht geldt, moet ook een correctie een e-factuur zijn, met het factuurtype voor een correctie. In EN 16931 verwijst die met nummer en uitgiftedatum naar de voorgaande factuur, dus uw systeem moet die koppeling als data bewaren.

Let op de terminologie. In het Duitse btw-recht is een “Gutschrift” een factuur die de afnemer op basis van een voorafgaande afspraak zelf uitreikt (§ 14 Abs. 2 UStG), wat in Nederland selfbilling heet. Wat u een creditnota noemt (een prijsverlaging of een annulering), is in Duitsland een correctie. Veel systemen gebruiken voor beide één documenttype. Scheid ze voordat u ze mapt, en reikt u via selfbilling facturen uit namens uw leveranciers, behandel die documenten dan als facturen die uw systeem uitreikt.

Een eindfactuur mag eerdere deelbetalingen in een bijlage vermelden, mits het gestructureerde deel ernaar verwijst; de FAQ bevestigt dat dit na 2027 blijft gelden.

Validatie voordat er iets vertrekt

KoSIT publiceert een opensource-validator die XML controleert tegen schema's en Schematron-regels, met een openbare configuratie voor XRechnung. Hij draait vanaf de opdrachtregel, als HTTP-daemon of als bibliotheek. Zet hem in het verzendpad: elke factuur wordt gevalideerd voordat ze vertrekt, en een fout komt terecht in een wachtrij met een benoemde eigenaar, met de vermelding welk veld welke regel schond.

Valideer bij ZUGFeRD de ingesloten XML tegen de regels van uw profiel, controleer de PDF/A-3-container apart en ga na of de pdf dezelfde totalen toont als de XML.

Verzending

De wet, zegt de FAQ, “sieht keinen bestimmten Weg vor”: ze schrijft geen kanaal voor. E-mail met het bestand als bijlage is prima. Een API ook, net als een downloadportaal, gedeelde opslag binnen een concern of (het eigen voorbeeld van het ministerie) een usb-stick. Peppol is voor binnenlandse B2B in Duitsland niet verplicht.

Het technische werk zit per klant: een factuuradres, een voorkeursformaat en een registratie van wat waarheen is gestuurd. Een nieuwe poging na een mislukte verzending bevat hetzelfde document met hetzelfde factuurnummer. Twee nummers voor één levering is een fiscaal probleem, geen softwareprobleem.

Archivering

Ten minste het gestructureerde deel moet “unversehrt in seiner ursprünglichen Form” worden bewaard, onaangetast in de oorspronkelijke vorm, en § 14b UStG stelt de bewaartermijn op acht jaar vanaf het einde van het jaar van uitgifte. Bewaar exact de bytes die u hebt verstuurd, met een hash. Reken er niet op dat u facturen later opnieuw uit de database genereert: tegen die tijd zijn de data en de code veranderd. Hetzelfde geldt voor e-facturen die u ontvangt.

Een plan voor oktober tot december 2026

Dertien weken is genoeg voor een gerichte bouw als de brongegevens redelijk op orde zijn. Het is niet genoeg om het factureringssysteem te vervangen.

Week 1 en 2: inventarisatie en beslissingen. Breng elke plek in kaart waar een factuur wordt aangemaakt, inclusief handmatige creditnota's, eindfacturen van projecten en de spreadsheet voor die ene grote klant. Toets de omzet over 2026 aan de drempel. Kies het standaardformaat en beslis of u de generator zelf bouwt of factuurgegevens naar de API van een e-facturatieprovider stuurt.

Week 2 tot 4: analyse van ontbrekende data. Map drie maanden aan echte facturen veld voor veld op EN 16931. Markeer wat ontbreekt, wat een code moet worden en wat anders wordt berekend. Hier wordt de werkelijke omvang van het project zichtbaar.

Week 4 tot 9: bouwen. Het factuurobject, de mapping, de rendering naar XML en PDF/A-3, de validator in het verzendpad, de foutenwachtrij en het archief. Tegelijk schoont iemand de stamgegevens op en verzamelt factuuradressen bij klanten.

Week 9 tot 11: opnieuw afspelen en piloot. Haal de facturen van de afgelopen drie maanden door de nieuwe generator en valideer ze allemaal. Draai daarna een piloot met een paar welwillende klanten en vraag of hun systemen de bestanden kunnen lezen.

Week 11 tot 13: bevriezen en runbook. Bevries wijzigingen in december. Leg vast wie de foutenwachtrij beheert, hoe een correctie wordt uitgereikt en wat er gebeurt als een klant een factuur weigert. Januarifacturen voor werk in december vallen al onder de plicht.

Januari 2027. Ga live en kijk dagelijks naar de wachtrij, tot en met de eerste maandafsluiting en de eerste btw-aangifte.

In de loop van 2027. Plan de upgrade naar XRechnung 4.0 voordat 3.0 niet meer geldig is, en zet groepsmaatschappijen onder de drempel om vóór 1 januari 2028.

Begint u laat, schrap dan automatisering, niet de geldigheid van de output: automatiseer eerst de factuurtypen met het grootste volume en stuur zeldzame documenten een paar weken met de hand via een e-facturatietool.

Waar u hulp krijgt

Wij bouwen de verbinding tussen het systeem dat uw facturen aanmaakt en het formaat dat de wet vereist: wijzigingen in het datamodel, mapping, validatie, verzending en archief, in uw codebase en samen met uw team. Op de pagina van onze dienst voor e-facturatie-integratie leest u hoe die projecten verlopen; valt de verplichting midden in een ERP-overstap, kijk dan bij ERP-modernisering. De bredere kalender staat in onze gids EU digitale compliance 2026.

Wij zijn ingenieurs, geen belastingadviseurs: vragen over de reikwijdte horen bij uw Steuerberater, en wij bouwen naar zijn antwoord. Vertel ons wat uw facturen vandaag aanmaakt en hoeveel er ongeveer per maand de deur uitgaan: schrijf naar office@c9group.dev.