Peppol & e-facturatie

Peppol: vervaldatum en betaaltermijn

Gepubliceerd: 2026-10-20 · Bronnen gecontroleerd: 2026-10-20

Staat op de leesbare factuur “30 dagen”, maar noemt de Peppol-export een andere vervaldatum? Vergelijk de factuurdatum, de gestructureerde vervaldatum en de tekst van de betalingsvoorwaarden afzonderlijk. Reken daarna de afspraak uit. Een aanwezige datum bewijst nog niet dat de klant op die datum hoort te betalen.

Houd factuurdatum en vervaldatum uit elkaar

In de officiële uitleg van IssueDate is BT-2 de datum waarop de factuur wordt uitgegeven. Dit element heeft cardinaliteit 1..1. De vervaldatum DueDate is BT-9: de datum waarop de betaling verschuldigd is. Die staat rechtstreeks in de UBL-factuur en heeft cardinaliteit 0..1.

Een factuurdatum is dus geen betaalopdracht en de vervaldatum is geen omschrijving van het werk. Gebruik voor leverdatum en werkperiode onze uitleg van de verschillende datumrollen. Neem een septemberperiode niet als vervaldatum over omdat beide schermvelden iets met een datum vragen.

We behandelen hier de UBL Invoice van Peppol BIS Billing 3.0, May 2026 Release. Pas deze vindplaatsen niet zonder controle toe op een creditnota, Self-Billing of een ander profiel. Land- en toepassingsregels blijven daarnaast relevant.

Zoek de voorwaarden in de bedoelde tekstgroep

De officiële groep PaymentTerms heeft cardinaliteit 0..1. Binnen een gebruikte groep staat één Note voor betalingsvoorwaarden, BT-20. Dat is een tekstuele beschrijving van de voorwaarden voor het te betalen bedrag.

Schrijf op je eigen controleblad daarom niet alleen “Note gevonden”, maar de plaats: cac:PaymentTerms / cbc:Note. Een regelomschrijving, algemene factuurnotitie of tekst in het pdf-sjabloon is niet door de naam “opmerking” automatisch deze betalingsvoorwaarde. Laat bij twijfel de leverancier de koppeling aanwijzen.

Houd ook de betalingsreferentie en de rekening apart. Onze vergelijking van betaalgegevens in dezelfde exportversie helpt die inhoud te controleren. Een juist rekeningnummer vertelt niet of een datum en de afgesproken termijn bij elkaar passen.

Eigen voorbeeld: één afspraak, twee datumvelden

Voor onze fictieve controle DUE2010 spreken twee Nederlandse bedrijven uitdrukkelijk af: 30 kalenderdagen na de factuurdatum, waarbij die factuurdatum dag nul is. We nemen aan dat het concept op 20 oktober 2026 wordt uitgegeven. Deze telwijze is een aanname in de oefening, geen uitspraak over een wettelijke betaaltermijn of de geldigheid van een echte overeenkomst.

OpenPeppol beschrijft PayableAmount, BT-115 als het nog gevraagde bedrag. We gebruiken de positieve waarde alleen om de beschreven voorwaarde bij datum of tekst te bespreken. We hebben geen werkelijke factuur, btw-berekening of bankmutatie onderzocht.

Reken de kalender na en test één afwijking

In DUE2010 tellen 21 tot en met 31 oktober als 11 dagen. Van 1 tot en met 19 november volgen 19 dagen. Samen is dat 11 + 19 = 30 kalenderdagen. De aangenomen afspraak komt zo uit op 19 november 2026. We verschuiven die datum niet op basis van een onbesproken werkdagregel.

Verander nu alleen de exportwaarde van BT-9 naar 2026-11-18, terwijl de tekst en afspraak gelijk blijven. De afstand vanaf 20 oktober wordt dan 29 dagen: één dag minder. De datum heeft nog steeds de vorm jaar-maand-dag, maar sluit in ons voorbeeld niet aan op de tekst. Dat is een handmatige inhoudsvergelijking, geen uitgevoerd validatorrapport.

Zoek bij een echte afwijking uit welke bron is gebruikt: de afspraak, de ingevoerde termijn, een handmatig ingevulde vervaldatum of een oude sjabloontekst. Verander niet willekeurig beide waarden tot ze gelijk lijken. Bevestig eerst wat inhoudelijk bedoeld is en laat het pakket een passende nieuwe conceptversie maken.

Lees bij een regelmelding ook de release

De huidige veldpagina's noemen bij een positief BT-115 nog een vervaldatum of betalingsvoorwaarden. De afzonderlijke documentatiepagina BR-CO-25 toont eveneens die aanwezigheidsvoorwaarde. Daaruit volgt geen vergelijking tussen onze kalenderberekening en de betekenis van de vrije tekst.

Er is bij de controle op 20 oktober 2026 een relevante beperking: de release notes van versie 3.0.21 vermelden dat BR-CO-25 is verwijderd uit de bijgewerkte CEN-regels. In de op die dag aangeboden TC434-Schematron en Peppol-Schematron vonden we geen assertion met dat identificatienummer.

We beloven daarom niet dat het ontbreken van beide velden in iedere actuele validator een fatal BR-CO-25 oplevert. Vraag bij zo'n melding om de gebruikte versie en het volledige rapport. De afwezigheid van één regel uit twee bestanden bewijst evenmin dat je factuur als geheel geldig is of dat een betaalafspraak vervalt.

Voor de datumvorm beschrijft PEPPOL-EN16931-F001 tien tekens in de vorm YYYY-MM-DD en een geldige datum. Een notatie als 19-11-2026 past daar niet bij. De datumvorm en de overeenstemming met je afspraak blijven twee aparte controles.

Vergelijk de echte export met dezelfde conceptversie

Leg de leesbare versie naast een inhoudsweergave die de gestructureerde export uitleest. Noteer factuurnummer, versie en exporttijd. Zoek BT-2, een eventuele BT-9 en de tekst van BT-20 op hun eigen plaats. Lees de inhoud letterlijk terug in plaats van alleen te kijken of een veld gevuld is.

Controleer daarna het pakketgedrag: wordt de vervaldatum opnieuw berekend na een andere factuurdatum, of blijft een eerder gekozen datum staan? Loopt de zichtbare tekst mee, of komt die uit een los sjabloon? We hebben dit niet in een softwareaccount getest; het zijn gerichte vragen voor je eigen gecontroleerde concept.

Bewaar bij een fout eerst de vergelijking. Laat de bevoegde gebruiker of leverancier de broninvoer herstellen en vraag een nieuwe export. Een los aangepast XML-bestand of alleen een gewijzigde pdf kan het verschil tussen versies juist vergroten. Volg bij een al verzonden document de toepasselijke correctiewerkwijze van je pakket.

Stel een vraag met waarden én vindplaatsen

Voor de afwijkende variant zou onze eigen vraag luiden: “Concept DUE2010 heeft factuurdatum 2026-10-20. De afspraak en BT-20 noemen 19 november na 30 kalenderdagen, maar BT-9 bevat 2026-11-18. Welk invoerveld bepaalt die exportwaarde? Welke regelsversie is voor het bijgevoegde rapport gebruikt?”

Dit is een fictieve vraag, geen verstuurd bericht of ontvangen antwoord. Voeg in je eigen dossier het betrokken fragment en de afspraak toe via de veilige werkwijze die je met de leverancier gebruikt. Een reactie over alleen de datumvorm beantwoordt nog niet waarom de inhoud één dag afwijkt.

Sluit af met afzonderlijke uitkomsten

Noteer wat aanwezig is, welke waarden inhoudelijk zijn vergeleken en wat nog moet worden bevestigd. Zet technische validatie voor het juiste profiel daarnaast. Als je pakket “verzonden” toont, is dat geen zelfstandig bewijs dat de klant de vervaldatum heeft bevestigd of het geld heeft betaald.

In ons voorbeeld zijn 30 en 29 kalenderdagen gecontroleerd en is het datumverschil aangewezen. De twee gepubliceerde Schematron-bestanden zijn op de genoemde regel onderzocht; er is geen volledige validator uitgevoerd. Bewaar de uiteindelijke export en leesbare versie samen met de vastgelegde afspraak en de uitleg van een eventuele correctie.

Bronnen en verder lezen

Acht officiële HTML-pagina's en twee officiële Schematron-downloads rechtstreeks gecontroleerd op 20 oktober 2026. De documentatiesite toont de May 2026 Release van Peppol BIS Billing 3.0. DUE2010, de afspraak, bedragen, kalendercontrole en foutvariant zijn eigen fictieve uitwerkingen. Deze controle bepaalt geen wettelijke betaaltermijn en omvat geen echte factuurverzending of betaling.

• OpenPeppol: factuurdatum BT-2
• OpenPeppol: vervaldatum BT-9
• OpenPeppol: groep betalingsvoorwaarden
• OpenPeppol: voorwaardentekst BT-20
• OpenPeppol: gevraagd restbedrag BT-115
• OpenPeppol: documentatie BR-CO-25
• OpenPeppol: actuele release notes
• OpenPeppol: datumvorm F001
• OpenPeppol: TC434-regelbestand
• OpenPeppol: Peppol-regelbestand

Bekijk het overzicht Peppol en e-facturatie voor andere controles vóór verzending.