Peppol & e-facturatie
Peppol: datum of code
Zoek bij een Peppol-export het btw-moment op zijn eigen plaats: een concrete btw-datum en een code voor het soort datum zijn verschillende gegevens. De begin- en einddatum van een factuurperiode vullen die velden niet vanzelf in. Controleer ook of de export beide representaties tegelijk bevat.
Kort antwoord
Noteer documentversie, veldpad en aangetroffen waarde. Vergelijk een eventuele TaxPointDate met de datumcode binnen InvoicePeriod. De beschreven regel BR-CO-03 sluit gelijktijdige aanwezigheid uit. Of een datum of code in jouw situatie nodig en fiscaal juist is, vraagt een afzonderlijke inhoudelijke beoordeling.
Deze uitleg gebruikt de huidige OpenPeppol-documentatie voor BIS Billing 3.0, May 2026 Release, en de UBL Invoice-structuur. BM2810 is onze eigen fictieve vergelijking van vijf onvolledige XML-fragmenten. Geen volledig factuurdocument, pakket, aangifte of verzending getest.
Maak een apart vak voor iedere datumrol
De syntax van IssueDate, BT-2 beschrijft de uitgiftedatum van de factuur en schrijft het formaat YYYY-MM-DD voor. Dat is iets anders dan de waarde die je bij een btw-moment onderzoekt. Een datum die alleen in een omschrijving of pdf staat, bevestigt nog geen gestructureerd veld.
TaxPointDate, BT-7 staat rechtstreeks onder Invoice en bevat een datum. De veldtoelichting noemt het element vereist wanneer het btw-tijdstip afwijkt van de factuurdatum. Die beschrijving stelt niet vast welke datum voor jouw levering fiscaal juist is. Neem een datum niet over alleen omdat de viewer een leeg vak toont.
Begin met dezelfde concept- en exportversie. Noteer naast iedere waarde waar zij vandaan komt en wie de inhoudelijke keuze heeft onderbouwd. Deze technische vergelijking bepaalt geen Nederlands heffingsmoment of aangiftetijdvak.
Lees een datumcode als code, niet als kalenderdatum
DescriptionCode, BT-8 beschrijft het soort datum voor het btw-moment. In de Invoice-structuur staat dit veld binnen de periodegroep op documentniveau: cac:InvoicePeriod/cbc:DescriptionCode. Het is geen vrij tekstveld voor “oktober” en geen plaats voor een datum als 2026-10-26.
De actuele OpenPeppol-subset van UNCL2005 bevat drie codes: 3 voor de factuuruitgiftedatum, 35 voor de daadwerkelijke leverdatum en 432 met de bronbenaming Paid to date. Een aanwezig getal is dus pas een herkenbare code als het bij de gebruikte lijst hoort.
Kies niet automatisch 3 omdat de factuurdatum al beschikbaar is. De lijst verklaart de codebetekenis; zij beslist niet welke keuze bij jouw fiscale situatie hoort. Houd ook de categorie, het tarief en de bedragen van de btw-uitsplitsing afzonderlijk. Een datumcode en een categoriecode hebben verschillende functies.
Houd de periodegrenzen naast de datumcode zichtbaar
De documentgroep InvoicePeriod, BG-14 bevat StartDate en EndDate voor de periode waarop de factuur betrekking heeft. Bij gebruik van de groep is volgens de toelichting een begin- en/of einddatum nodig. In dezelfde groep kan DescriptionCode staan, met de afzonderlijke betekenis BT-8.
Lees daarom het volledige pad, niet alleen de bovenliggende groepsnaam. Een periode-einde van 2026-10-31 is niet automatisch een TaxPointDate met die waarde. Evenmin betekent een datumcode dat je de periodegrenzen al hebt gecontroleerd. De uitleg over perioden op factuur- en regelniveau helpt die andere grenzen te vergelijken.
Onze proef gebruikt uitsluitend de periodegroep op documentniveau. Trek uit een gelijknamig element elders in een bestand geen conclusie over BT-8 zonder de structuur te lezen.
Eigen proef BM2810: vijf afzonderlijke fragmenten
Alle vijf verzonnen Invoice-fragmenten hebben IssueDate 2026-10-28 en een documentperiode van 2026-10-01 tot en met 2026-10-31. We variëren de twee btw-velden; de factuurdatum en periodegrenzen blijven gelijk. De XML-fragmenten gebruiken de UBL-namespaces; zij missen bewust andere verplichte factuuronderdelen en zijn geen verzendbare facturen.
| Fragment | Btw-velden in onze proef |
|---|---|
| A · concrete datum | BT-7: 2026-10-26; geen BT-8. |
| B · datumcode | Geen BT-7; BT-8: 3. |
| C · beide | BT-7: 2026-10-26; BT-8: 3. |
| D · geen van beide | Geen BT-7 en geen BT-8; periodegrenzen wel aanwezig. |
| E · oefenfout in code | Geen BT-7; BT-8: 99. |
A en B zijn geen inhoudelijk gelijkwaardige fiscale oplossingen. In A kozen we op papier 26 oktober; B verwijst met code 3 naar de uitgiftedatum van 28 oktober. Tussen die twee kalenderdatums liggen twee dagen. De proef bepaalt niet welke keuze voor een echte factuur nodig is.
Controleer uitsluiting en codelijst afzonderlijk
BR-CO-03 verklaart BT-7 en BT-8 wederzijds uitsluitend. In onze eigen aanwezigheidsvergelijking staat alleen in C zowel een TaxPointDate als een DescriptionCode op de bedoelde plaatsen. C voldoet niet aan deze ene uitsluitingsvoorwaarde. A, B, D en E hebben dat gelijktijdigheidsprobleem niet.
Daarna vergelijken we de aanwezige codes met de gelezen lijst. B en C bevatten 3; E bevat onze bewust fout gekozen 99, die niet in de huidige subset staat. De afzonderlijke regel PEPPOL-EN16931-CL006 toetst DescriptionCode aan de codelijst. Een lijstcode lost C's gelijktijdigheid niet op; het ontbreken van gelijktijdigheid maakt E's code niet toegestaan.
We hebben de vijf fragmenten onafhankelijk met hun namespaces gelezen en de gevonden aantallen met een vaste matrix vergeleken: vier voldoen aan de beperkte uitsluitingsvergelijking; van de drie aanwezige codevelden bevatten twee een code uit de lijst. Dit is een eigen gerichte vergelijking, geen uitgevoerd Schematron- of XSD-rapport.
Laat een lege uitkomst een open vraag blijven
Bij D ontbreken beide btw-velden. De gepubliceerde test van BR-CO-03 laat ook die combinatie door. Daarmee is uitsluitend deze ene regel verklaard. Het is geen algemene toestemming om een btw-datum weg te laten: de veldtoelichting, overige toepasselijke regels en fiscale onderbouwing blijven relevant.
De periodegrenzen in D beantwoorden nog steeds alleen de periodevraag. Vul niet op eigen initiatief 31 oktober in als btw-datum om het blad compleet te maken. Leg vast welk veld ontbreekt, welke inhoudelijke vraag openstaat en wie die moet beantwoorden.
Vraag om de verklaarde keuze in een nieuwe export
Bewaar documentnummer, exportversie, de twee veldpaden en eventuele regelmelding samen. Laat de verantwoordelijke voor de fiscale inhoud bevestigen welke datum of soort datum bedoeld is. Laat de pakketleverancier vervolgens aanwijzen hoe die keuze in het gebruikte profiel wordt geëxporteerd.
Verwijder bij C niet zomaar een van de velden om alleen een melding te laten verdwijnen. Corrigeer een verklaarde bron- of koppelingsfout via het pakket en vergelijk de nieuwe export opnieuw, inclusief de periodegrenzen. Houd daarnaast een volledige validatie voor het juiste profiel en toepasselijke regels apart van onze kleine proef.
Markeer controles die nog niet zijn uitgevoerd. BM2810 beoordeelt geen echte levering, btw-regime, aangifteperiode, softwareondersteuning of succesvolle Peppol-verzending. De huidige documentatie is de bron voor de beschreven velden en regels, niet een fiscaal oordeel over jouw factuur.
Officiële bronnen en proefgrenzen
Zeven officiële OpenPeppol-pagina's rechtstreeks gelezen op 28 oktober 2026; alle tonen BIS Billing 3.0, May 2026 Release. BM2810 en de vijf fragmenten zijn fictief. Alleen veldplaatsen, aanwezigheid en lijstvergelijking zijn gericht gecontroleerd; geen volledige factuurvalidatie of fiscale beoordeling.