ZUGFeRD-naleving in Duitsland: profielen, vereisten en ERP-integratie

24 augustus 2026

10 min lezen

Samenvatten met AI

Door de Duitse vereisten voor elektronische facturering kan een vertrouwd factureringsproces plotseling aanvoelen als een veel omvangrijker IT-project. Als uw ERP-systeem al goed functioneert, is het laatste wat u wilt dat u het opnieuw moet opbouwen, alleen maar om een ander factuurformaat te ondersteunen.

Daarom zou ik beginnen met wat je al hebt. Sommige ERP-systemen kunnen gestructureerde e-facturen genereren via ingebouwde modules, API’s of landspecifieke componenten. Andere systemen produceren nog steeds standaard PDF’s en vereisen een extra conversiestap. Zodra je weet hoe je systeem in elkaar zit, wordt het veel eenvoudiger om een ZUGFeRD-opstelling te kiezen die aan de vereisten voldoet, zonder onnodige wijzigingen aan te brengen in het kernproces van de facturering.

Dmitry Nazarevich

Technisch Directeur (CTO)

Als visionair architect overbrugt Dmitry de kloof tussen ruwe innovatie en commerciële levensvatbaarheid. Hij houdt toezicht op de technische routekaart van het bedrijf en zorgt ervoor dat elke oplossing wordt gebouwd op een stack die onmiddellijke bedrijfsproblemen oplost.

Bekijk profiel

Wat is ZUGFeRD?

ZUGFeRD is een hybride formaat voor elektronische facturen. Een ZUGFeRD-factuur bestaat uit een voor mensen leesbaar PDF/A-3-document met daarin ingebedde gestructureerde XML-gegevens die boekhoudsoftware direct kan verwerken.

Het XML-bestand bevat vastgelegde factuurgegevens, zoals informatie over de verkoper en de koper, factuurregels, taxe’s, totalen, betalingsgegevens en referenties. Voor Duitse e-facturering zijn de gekozen ZUGFeRD-versie en het profiel net zo belangrijk als het bestand zelf.

Welk ZUGFeRD-profiel moet je gebruiken?

ZUGFeRD kent vijf hoofdprofielen plus het referentieprofiel XRECHNUNG, die zowel qua gegevensomvang als qua regelgevend gebruik van elkaar verschillen. Voor een typische Duitse B2B-implementatie op basis van EN 16931 zou ik doorgaans beginnen met het EN 16931-profiel en overstappen naar EXTENDED wanneer het bedrijfsproces aanvullende gestructureerde gegevens vereist.

Profiel	Wat eronder valt	Situatie in Duitsland
MINIMUM	Basisgegevens over kopers, verkopers, totalen en belastingen	Wordt niet herkend als een volledige UStG-factuur
BASIC WL	Boekhoudkundige gegevens op koptekstniveau zonder factuurregels	Wordt niet herkend als een volledige UStG-factuur
BASIS	Deel van EN 16931 voor eenvoudigere facturen	Erkend als een volledige UStG-factuur
EN 16931, voorheen COMFORT	Volledig factuurmodel volgens EN 16931	Erkend als een volledige UStG-factuur en de eerste keuze voor standaard e-facturering die voldoet aan de EU-voorschriften
UITGEBREID	EN 16931 plus aanvullende gegevens voor complexere bedrijfsprocessen	Erkend als een volledige UStG-factuur
XRECHNUNG	Referentieprofiel op basis van de XRechnung-vereisten van KoSIT	Vooral relevant wanneer de XRechnung-vereisten van toepassing zijn, met name bij B2G

FeRD beveelt EN 16931 uitdrukkelijk aan voor elektronische facturen die aan de EU-voorschriften voldoen. Ook het Duitse ministerie van Financiën stelt dat ZUGFeRD vanaf versie 2.0.1 voldoet aan de Duitse eisen voor elektronische facturering, met uitzondering van MINIMUM en BASIC-WL.

De profielkeuze moet dus in een vroeg stadium plaatsvinden. Als je bijvoorbeeld voor ‘MINIMUM’ kiest omdat dit de basisbedragen bevat, betekent dat nog niet dat het document voldoet aan de Duitse eisen voor elektronische facturen.

Wie moet zich in Duitsland aan de regels houden?

Duitsland introduceert B2B-e-facturering stapsgewijs.

Sinds 1 januari 2025 moeten Duitse bedrijven die onder de regeling vallen, technisch in staat zijn om e-facturen te ontvangen voor transacties waarop de B2B-regels van toepassing zijn.
Tot en met 31 december 2026 blijven papieren facturen op grond van overgangsregels toegestaan, evenals – met toestemming van de ontvanger – andere elektronische formaten, zoals gewone PDF-bestanden.
In 2027 wordt die overgangsperiode verlengd voor emittenten waarvan de omzet in het voorgaande jaar niet hoger was dan 800.000 euro. Ook voor bepaalde EDI-regelingen geldt een overgangsperiode tot en met 2027.
Vanaf 1 januari 2028 loopt de algemene overgangsperiode af voor binnenlandse B2B-facturering die onder de regeling valt.

Ik zou dit niet als een regel beschouwen dat elke Duitse factuur ZUGFeRD moet gebruiken. De reikwijdte hangt nog steeds af van de transactie. B2C-facturen, bepaalde vrijgestelde transacties, facturen met een lage waarde en andere speciale gevallen kunnen onder andere regels vallen.

Waarom gewone PDF-facturen niet langer volstaan

Een standaard PDF bevat voornamelijk informatie die bedoeld is om door mensen te worden gelezen. Een gestructureerde e-factuur bevat daarnaast ook door boekhoudsoftware gedefinieerde, machinaal leesbare velden.

Iemand zou het volgende kunnen zien:

Een gestructureerde factuur geeft een overzicht van de onderliggende bedragen, zodat de software weet welk bedrag de belastbare grondslag, de btw, het brutototaal en het te betalen bedrag vertegenwoordigt.

Dankzij dat onderscheid kunnen ERP- en boekhoudsystemen facturen verwerken zonder dat ze de betekenis ervan moeten afleiden uit de tekst of de pagina-indeling van een PDF-bestand.

Kijk eerst wat je ERP al ondersteunt

Controleer, voordat u een converter implementeert, of het ERP-systeem al landspecifieke functies voor elektronische facturering, API’s of documentmodules biedt.

Er zijn meestal drie mogelijkheden:

In SAP-omgevingen kan bijvoorbeeld gebruik worden gemaakt van landspecifieke functionaliteit via SAP Document and Reporting Compliance. Voor andere ERP-systemen of op maat gemaakte systemen kan middleware of een aparte conversieservice nodig zijn.

Een zelfstandige converter is daarom de meest logische keuze wanneer er geen geschikte ingebouwde ondersteuning is of wanneer het aanpassen van de kernapplicatie voor facturering onnodige projectrisico’s met zich mee zou brengen.

Hoe een zelfstandige PDF-naar-ZUGFeRD-converter kan helpen

Bij een op PDF gebaseerd proces kan de conversiestroom er als volgt uitzien:

Waar mogelijk vormen gestructureerde ERP-gegevens een betere bron dan waarden die uit de PDF zijn gereconstrueerd. JSON, XML, CSV, databaserecords of API-gegevens behouden de betekenis van factuurvelden en verminderen interpretatiefouten.

Factuurgegevens toewijzen aan het EN 16931-model

Voor het aanmaken van de XML is een correcte semantische toewijzing nodig. De converter moet vaststellen wat elke waarde op de factuur betekent en deze in het bijbehorende gestructureerde veld plaatsen.

Een prijs is eenvoudig. Andere velden vereisen meer context: identificatiegegevens van verkoper en koper, factuurtype, belastingcategorieën, eenheidscodes, kortingen, toeslagen, referenties, betalingsvoorwaarden, leveringsgegevens en btw-uitsplitsingen kunnen allemaal van invloed zijn op de XML.

Factuurbedrag	Term uit EN 16931
Factuurnummer	BT-1
Uitgiftedatum	BT-2
Valuta	BT-5
Naam van de verkoper	BT-27
Naam van de koper	BT-44
Nettobedrag per regel	BT-131
Totaal exclusief btw	BT-109
Totaal btw	BT-110
Totaal incl. btw	BT-112
Te betalen bedrag	BT-115

Het grootste deel van het implementatiewerk betreft dit gegevensmodel en de bijbehorende validatie. Het systeem moet de brongegevens correct toewijzen, geldige XML genereren, deze verpakken in PDF/A-3 en ervoor zorgen dat beide weergaven consistent blijven.

In lagen valideren

Ik zou de factuur in verschillende stappen controleren:

Bijvoorbeeld:

De converter zou deze waarden moeten berekenen en vergelijken, in plaats van opgemaakte tekenreeksen uit de PDF te kopiëren.

Ik zou het voltooide PDF/A-3-bestand ook controleren nadat de XML erin is ingebed. Door het verpakkingsproces verandert het document, dus als je alleen de bron-PDF controleert, krijg je geen volledig beeld van de uiteindelijke uitvoer.

Voordat ik de documenten verstuur, zou ik het factuurnummer, de datums, de partijen, de valuta, de bedragen per regel, de belastinggegevens, de totalen, de betalingsgegevens en de referenties in de PDF- en XML-bestanden met elkaar vergelijken.

Wilt u e-facturering aan uw ERP-systeem toevoegen?

Wij kunnen u helpen bij het beoordelen van uw huidige ERP-opstelling, het vaststellen van de juiste factuurgegevensstroom en het implementeren van e-facturering binnen de systemen die u al gebruikt.

ZUGFeRD-nalevingschecklist

Gebruik een ondersteunde ZUGFeRD-versie en het juiste profiel.
Houd u aan de voorschriften van EN 16931 voor het gekozen factuurtype.
Neem alle vereiste factuurgegevens op in de gestructureerde XML.
Maak een geldig PDF/A-3-document aan.
Sluit de XML op de juiste manier in de PDF in.
Zorg ervoor dat de waarden in PDF- en XML-facturen consistent zijn.
XSD-schema’s en Schematron-bedrijfsregels valideren.
Controleer de waarden in de codelijst voor valuta, eenheden, btw-categorieën en betaalmethoden.
Bereken de btw, totalen, datums en betalingsbedragen opnieuw.
Weiger facturen die niet voldoen aan de vereiste validatiecontroles.
Bewaar de elektronische factuur conform de Duitse bewaarplicht.
Test de bestanden eerst in de boekhoudsystemen van de klanten voordat ze in productie worden genomen.

Meer over dit onderwerp

Diensten

KSeF-integratiediensten — naleving van de regelgeving inzake e-facturering

Blog

Geautomatiseerde factuurverwerking

Blog

SAP e-facturatie: naleving van documenten en rapportage

Blog

ERP-gegevensmigratie: best practices, strategie en hulpmiddelen

Contacteer ons

Boek een gesprek of vul het onderstaande formulier in en we nemen contact met je op zodra we je aanvraag hebben verwerkt.

Naam

Bedrijf

E-mail

Telefoon

Bericht

Stuur ons een spraakbericht

Documenten bijvoegen

Bestand uploaden

Je kunt 1 bestand van maximaal 2 MB bijvoegen. Geldige bestandsformaten: pdf, jpg, jpeg, png.

Door op Verzenden te klikken, stemt u ermee in dat Innowise uw persoonsgegevens verwerkt volgens onze Privacybeleid om u van relevante informatie te voorzien. Door je telefoonnummer op te geven, ga je ermee akkoord dat we contact met je opnemen via telefoongesprekken, sms en messaging-apps. Bellen, berichten en datatarieven kunnen van toepassing zijn.

U kunt ons ook uw verzoek sturen
naar contact@innowise.com

Wat gebeurt er nu?

Zodra we je aanvraag hebben ontvangen en verwerkt, nemen we contact met je op om de details van je projectbehoeften en tekenen we een NDA om vertrouwelijkheid te garanderen.

Na het bestuderen van uw wensen, behoeften en verwachtingen zal ons team een projectvoorstel opstellen met de omvang van het werk, de teamgrootte, de tijd en de geschatte kosten voorstel met de omvang van het werk, de grootte van het team, de tijd en de geschatte kosten.

We zullen een afspraak met je maken om het aanbod te bespreken en de details vast te leggen.

Tot slot tekenen we een contract en gaan we meteen aan de slag met je project.