Peppol & e-facturatie
Peppol: tekens
Een negatief regelbedrag in een Peppol-export vertelt nog niet of de hoeveelheid of de artikelprijs negatief is. Lees documenttype, hoeveelheid, nettoprijs en regelnetto samen. Twee regels kunnen hetzelfde bedrag tonen terwijl één van beide een negatieve artikelprijs bevat die niet bij de prijsregel past.
Kort antwoord
Controleer eerst Invoice of CreditNote. Lees daarna de hoeveelheid en PriceAmount op hun eigen plaats en reken het regelnetto na. BR-27 verlangt een artikelnettoprijs van nul of hoger. Een negatief regelbedrag maakt een negatieve PriceAmount niet alsnog toegestaan.
Begin bij documenttype en betekenis van de correctie
De actuele BIS Billing-uitleg over negatieve facturen en creditnota's behandelt een CreditNote en een negatieve Invoice afzonderlijk. Bij de creditnota is het documenttype bepalend voor de creditwerking; bij de negatieve factuur speelt het teken van de bedragen die rol. Kopieer daarom geen algemene afspraak “alles op min” naar ieder XML-veld.
De officiële voorbeelden gebruiken bij Invoice de groep InvoiceLine met InvoicedQuantity. Bij CreditNote staan CreditNoteLine en CreditedQuantity. Onze proef gebruikt codes 380 en 381 in die respectieve documenttypen. Zij behandelt geen Self-Billing of ander profiel.
Houd daarnaast de oorspronkelijke factuurreferentie en afwikkeling van een credit bij het dossier. Deze uitleg kiest geen juridische correctieroute en bepaalt niet welk bedrag een echte klant nog moet betalen of terugkrijgen.
Een negatieve hoeveelheid is geen negatieve nettoprijs
BR-27 toetst de PriceAmount onder Price aan nul of hoger. De gepubliceerde context noemt zowel InvoiceLine als CreditNoteLine. De regel gaat over de artikelnettoprijs, niet over de tekenwaarde van ieder ander bedrag in het document.
Noteer op je eigen controleblad de volledige veldlocatie. Zet bijvoorbeeld hoeveelheid, prijsbasis, artikelnettoprijs en LineExtensionAmount op verschillende regels. Een invoervak met alleen het woord “bedrag” helpt niet om vast te stellen welk van die velden het pakket schrijft.
Lees bij een prijskorting ook de bruto-, kortings- en nettoprijsvelden afzonderlijk. Onze tekenproef voegt geen prijskortingsgroep toe en onderzoekt niet hoe een leverancierspakket een kortingsknop omzet.
Neem de opgenomen prijsbasis mee
R121 verlangt dat een aanwezige BaseQuantity groter dan nul is. De officiële test staat ook toe dat het element ontbreekt. Onze drie voorbeelden nemen het juist telkens expliciet op met waarde 1. We onderzoeken dus geen afleiding of standaardwaarde bij een ontbrekende prijsbasis.
R120 vergelijkt het regelnetto met hoeveelheid maal nettoprijs gedeeld door prijsbasis, plus regeltoeslagen en min regelkortingen. De gepubliceerde test gebruikt een tolerantie van 0,02. Onze eigen bedragen sluiten exact en onderzoeken geen afrondingsgrens of uitvoering van die volledige test.
Controleer ook de betekenis van de eenheden naast de hoeveelheid en prijsbasis. In onze oefening gebruiken beide hoeveelheden DAY. Dat is een zelfgekozen demonstratie, geen registratie van geleverde werkdagen.
Eigen proef NI2910: hetzelfde minbedrag, andere veldinhoud
We maken drie eigen gedeeltelijke XML-fragmenten. I1 en I2 zijn Invoice-fragmenten met typecode 380; C1 is een CreditNote-fragment met 381. De bedragen zijn fictief, in euro en zonder btw. Prijsbasis is steeds 1; er zijn geen regelkortingen of regeltoeslagen.
| Eigen variant | Vastgelegde waarden en narekening |
|---|---|
| I1: Invoice, hoeveelheid −2. | Prijs 15,00; basis 1; regelnetto −30,00. −2 × 15 = −30. |
| I2: Invoice, hoeveelheid 2. | Prijs −15,00; basis 1; regelnetto −30,00. 2 × −15 = −30. |
| C1: CreditNote, hoeveelheid 2. | Prijs 15,00; basis 1; regelnetto 30,00. 2 × 15 = 30. |
I1 en I2 leveren in deze eigen rekensom hetzelfde −30,00 op. Toch verschilt de prijscontrole: 15,00 is niet negatief, maar −15,00 wel. Een gelijk regelnetto bewijst dus niet dat dezelfde velden en voorwaarden worden gebruikt.
C1 illustreert afzonderlijk een positieve hoeveelheid en positieve regelwaarde binnen het creditnotatype. Dat is geen regel dat iedere creditregel altijd positief moet zijn. In de officiële BIS-voorbeelden komen ook creditregels met een negatieve hoeveelheid voor.
Drie beperkte controles zijn geen volledig validatierapport
We lezen onze fragmenten met hun XML-naamruimten uit. Per regel vergelijken we uitsluitend: is de nettoprijs niet negatief, is de opgenomen prijsbasis positief en sluit onze exacte regelberekening? Daarmee doen we 3 × 3 = 9 beperkte vergelijkingen.
Bij I1 zijn alle drie waar. Bij I2 is de prijsvergelijking onwaar en zijn de andere twee waar. Bij C1 zijn weer alle drie waar. Samen zijn dat acht ware uitkomsten en één onware. We controleerden de velden met twee afzonderlijke XML-lezers en rekenden ook onafhankelijk in hele centen na.
Deze resultaten horen alleen bij onze gedeeltelijke gegevens. We hebben de volledige R120-XPath met tolerantie niet uitgevoerd en geen volledige XSD- of Schematronvalidatie gedaan. Verplichte kopgegevens, btw, totalen, nationale regels en ontvangerseisen zijn niet door deze proef afgetekend.
Laat de bron van een tekenverschil uitleggen
Bewaar de onderzochte conceptversie en export. Vraag bij een afwijking welk bronveld de hoeveelheid bepaalt, welk veld de artikelprijs schrijft en waar het documenttype wordt gekozen. Laat ook vaststellen welke correctie inhoudelijk is bedoeld. Een minteken op een PDF is daarvoor onvoldoende.
Verander I2 niet op goed geluk door alleen −15 in 15 te wijzigen terwijl het regelbedrag −30 blijft staan. Met dezelfde positieve hoeveelheid zou onze exacte rekensom dan 30 worden. Dat voorbeeld laat zien waarom een losse veldwijziging een nieuwe vergelijking nodig maakt; het schrijft geen echte herstelboeking voor.
Laat na een verklaarde correctie een nieuwe export en het bijbehorende volledige validatierapport maken. Bewaar welk bestand daarbij is onderzocht. Hergebruik een ouder rapport niet als bewijs dat de gewijzigde versie is gecontroleerd en stuur geen handmatig gewijzigd XML-fragment als factuur.
Houd bedrag, verzending en afwikkeling apart
Sluit je eigen onderzoek af met documenttype, regelnummer, hoeveelheid, prijsbasis, nettoprijs en regelnetto. Noteer de bronafspraak en wat de leverancier over de mapping heeft bevestigd. Een nog onbekend punt blijft open; de drie rekenuitkomsten kiezen geen contractuele of fiscale behandeling.
Een geslaagde veldvergelijking bewijst evenmin ontvangst of betaling. Controleer voor een werkelijke correctie de oorspronkelijke stukken, de juiste referenties, de actuele pakketroute en de uiteindelijke status. NI2910 is geen echte factuur, creditnota, netwerktransactie of boeking.
Officiële bronnen en reikwijdte
Vier actuele OpenPeppol-bronnen rechtstreeks gelezen op 29 oktober 2026. De productiepagina's tonen May 2026 Release; de BIS vermeldt 3.0.21. Van de BIS is het volledige onderdeel 5.6 gelezen, van de drie regels de volledige pagina met context en test.
NI2910 en alle bedragen zijn eigen oefengegevens. Geen ERP, volledige factuurvalidatie, verzending, echte correctie, btw-beoordeling of betaling getest. Oudere releases, upcoming en Self-Billing zijn niet als deze gewone Billing-route gebruikt.