EN 16931 voor ontwikkelaars: business terms, regels en validatie

EN 16931 definieert een factuur als een lijst van genummerde business terms (BT-1, BT-2 …) gegroepeerd in business groups (BG-23, BG-25 …), met kardinaliteiten en bedrijfsregels ertussen. Om een conform bestand te produceren, koppelt u elke term aan één element van een syntax — UBL 2.1 of UN/CEFACT CII — vult u elke verplichte term in, laat u de totalen voldoen aan de rekenregels (BR-CO-xx) en toetst u het resultaat aan de gepubliceerde Schematron voordat het uw systeem verlaat. Deze gids loopt dat door in de volgorde waarin een ontwikkelaar het tegenkomt.

Het model, niet het bestand

Het normatieve deel van de norm, EN 16931-1, is een semantisch gegevensmodel: het zegt wat een factuur bevat en wat elk element betekent, zonder XML voor te schrijven. CEN/TS 16931-2 somt de twee syntaxen op die aanvaard moeten worden: UBL 2.1 (Invoice en CreditNote) en UN/CEFACT Cross Industry Invoice (CII) D16B. De syntaxbindingen in CEN/TS 16931-3 zeggen welk element welke term draagt. De delen 1 en 2 zijn gratis verkrijgbaar bij de nationale normalisatie-instituten op grond van een overeenkomst tussen de Europese Commissie en CEN; de bindingen zijn betaalde documenten, maar alles wat een implementator nodig heeft om te valideren — de Schematron-regels — wordt door het eInvoicing-team van de Commissie openbaar gepubliceerd op GitHub. Voor de achtergrond, versies en het CIUS-concept van de norm, zie EN 16931 uitgelegd.

Drie gevolgen bepalen de implementatie:

• Uw domeinmodel moet business terms dragen, geen XML-paden. Eén intern factuurobject dat één keer naar UBL en één keer naar CII wordt gemapt, is veel minder werk dan twee handgeschreven serialisers, en hetzelfde object dient voor XRechnung, ZUGFeRD, Factur-X en Peppol BIS, die allemaal EN 16931-profielen (CIUS) of -uitbreidingen zijn. Zie de formaten vergeleken.
• Kardinaliteit wordt afgedwongen door Schematron, niet alleen door XSD. Een XSD-geldig UBL-bestand zonder verkopersnaam is schema-geldig en EN 16931-ongeldig.
• De rekenregels kloppen tot op de cent na afronding. Drijvendekommaberekeningen ergens in de pijplijn leveren vroeg of laat een BR-CO-schending op.

De verplichte business terms

Het kernmodel heeft een kleine verplichte set. Elke EN 16931-factuur moet de volgende termen dragen; een CIUS zoals XRechnung of Peppol BIS voegt daar verdere eisen aan toe (kopersreferentie, elektronisch adres van de verkoper, betaalwijze enzovoort), die door de eigen regels van dat profiel worden gecontroleerd.

De volledige elementenlijst, met kardinaliteit en beschrijving van elke term, staat in EN 16931-1 zelf en wordt element voor element herhaald in de syntaxdocumentatie van Peppol BIS. De tabel hierboven is het werkbare minimum, geen vervanging voor het lezen ervan.

De bedrijfsregels

Regels komen in families, herkenbaar aan het voorvoegsel. Een validator rapporteert de regelidentificatie, dus wie de families kent, begrijpt de meeste foutmeldingen vanzelf.

BR-xx

Structurele regels: aanwezigheid en kardinaliteit. BR-01 "An Invoice shall have a Specification identifier (BT-24)"; BR-02 "An Invoice shall have an Invoice number (BT-1)"; BR-03 de factuurdatum; BR-05 de valuta; BR-06 de naam van de verkoper; BR-07 de naam van de koper; BR-16 "An Invoice shall have at least one Invoice line (BG-25)".

BR-CO-xx

Voorwaarden en berekeningen. BR-CO-10: BT-106 = Σ BT-131. BR-CO-13: BT-109 = BT-106 − BT-107 (kortingen) + BT-108 (toeslagen). BR-CO-14: BT-110 = Σ BT-117. BR-CO-15: BT-112 = BT-109 + BT-110. BR-CO-16: BT-115 = BT-112 − BT-113 (betaald) + BT-114 (afronding). BR-CO-17: BT-117 = BT-116 × BT-119 / 100, afgerond op twee decimalen. BR-CO-04 vereist een btw-categoriecode op elke regel.

BR-S, BR-Z, BR-E, BR-AE, BR-IC, BR-G, BR-O, BR-IG, BR-IP

Eén familie per btw-categoriecode (BT-118/BT-151): S normaal tarief, Z nultarief, E vrijgesteld, AE verlegd, K intracommunautaire levering, G export, O niet aan btw onderworpen, en de belastingen van de Canarische Eilanden en Ceuta/Melilla. Elke familie zegt wat de uitsplitsing moet bevatten wanneer een regel van die categorie bestaat. BR-AE-01: een factuur met een regel met verlegde btw moet precies één btw-uitsplitsing met categorie "AE" bevatten. BR-S-08: voor elk normaal tarief is het belastbare bedrag in de uitsplitsing gelijk aan de som van de nettobedragen van de regels (plus toeslagen, min kortingen) tegen dat tarief.

BR-CL-xx

Codelijstregels: de typecode moet uit UNTDID 1001 komen (BR-CL-01), de valuta uit ISO 4217, het land uit ISO 3166-1, de eenheden uit UN/ECE Recommendation 20 en 21, enzovoort.

UBL-SR-xx, CII-SR-xx

Syntaxregels: elementen die de binding niet gebruikt, moeten afwezig zijn, en beperkte elementen mogen niet herhaald worden.

Regelschendingen hebben een vlag. Een fatale fout betekent dat het bestand geen EN 16931-factuur is en dat een ontvanger het mag weigeren; een waarschuwing betekent dat iets ongebruikelijk maar toegestaan is. Behandel fatale fouten als bouwfouten.

Een minimale UBL-factuur

Het volgende bestand voldoet aan de kernregels voor één regel tegen het normale tarief van 19 %. De namespaces zijn die van UBL 2.1; CustomizationID noemt het gewone EN 16931-profiel. Een echt XRechnung- of Peppol BIS-bestand heeft daarnaast een eigen CustomizationID, een ProfileID, een kopersreferentie en betaalgegevens nodig.

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017</cbc:CustomizationID>
  <cbc:ID>RE-2026-0142</cbc:ID>
  <cbc:IssueDate>2026-09-03</cbc:IssueDate>
  <cbc:DueDate>2026-10-03</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:AccountingSupplierParty><cac:Party>
    <cac:PostalAddress><cbc:StreetName>Beispielstrasse 1</cbc:StreetName>
      <cbc:CityName>Berlin</cbc:CityName><cbc:PostalZone>10115</cbc:PostalZone>
      <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme><cbc:CompanyID>DE123456789</cbc:CompanyID>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:PartyTaxScheme>
    <cac:PartyLegalEntity><cbc:RegistrationName>Beispiel GmbH</cbc:RegistrationName></cac:PartyLegalEntity>
  </cac:Party></cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty><cac:Party>
    <cac:PostalAddress><cbc:CityName>Hamburg</cbc:CityName><cbc:PostalZone>20095</cbc:PostalZone>
      <cac:Country><cbc:IdentificationCode>DE</cbc:IdentificationCode></cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity><cbc:RegistrationName>Kunde AG</cbc:RegistrationName></cac:PartyLegalEntity>
  </cac:Party></cac:AccountingCustomerParty>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
      <cac:TaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="HUR">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cac:Item><cbc:Name>Consulting</cbc:Name>
      <cac:ClassifiedTaxCategory><cbc:ID>S</cbc:ID><cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme></cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price><cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount></cac:Price>
  </cac:InvoiceLine>
</Invoice>

Loop de totalen na tegen de regels: regelnetto 10 × 100,00 = 1000,00 (BT-131); Σ regels = 1000,00 (BR-CO-10); geen kortingen of toeslagen, dus BT-109 = 1000,00 (BR-CO-13); één uitsplitsing, S tegen 19 %, belastbaar 1000,00, belasting 190,00 (BR-CO-17); BT-110 = 190,00 (BR-CO-14); BT-112 = 1190,00 (BR-CO-15); niets vooruitbetaald, BT-115 = 1190,00 (BR-CO-16).

Validatieartefacten en tools

Valideer met dezelfde artefacten die de ontvangers gebruiken. Het is niet nodig de regels opnieuw te implementeren.

Een praktische pijplijn draait eerst XSD (goedkoop, vangt misvormde structuur), dan de EN 16931-Schematron, dan de profiel-Schematron (XRechnung of Peppol) en, voor hybride formaten, een PDF/A-3-controle van de container. Neem dit op in de continue integratie met een corpus van uw eigen documenten: één per btw-categorie die u ondersteunt, één met kortingen en toeslagen, één creditnota, één in een vreemde valuta met BT-6 ingevuld.

Veelvoorkomende validatiefouten en hun oorzaken

De meeste fouten komen uit een handvol oorzaken. Ze herkennen aan de regelidentificatie bespaart uren.

• BR-CO-10, BR-CO-13, BR-CO-15 — totalen wijken 0,01 af. De regelbedragen zijn afzonderlijk afgerond en de totalen berekend uit niet-afgeronde waarden, of omgekeerd. Kies één afrondingspunt (per regel, twee decimalen, half-up tenzij het profiel anders zegt) en leid elk totaal af uit de afgeronde regelbedragen.
• BR-CO-17 — het belastingbedrag in de uitsplitsing is niet gelijk aan belastbaar × tarief. Dezelfde oorzaak, toegepast op de btw-uitsplitsing. Bereken BT-117 uit BT-116, niet door de btw per regel op te tellen.
• BR-S-08 / BR-AE-08 / BR-E-08 — de uitsplitsing voor een categorie bestaat, maar het belastbare bedrag komt niet overeen met de regels. Meestal is een korting of toeslag op documentniveau op de totalen toegepast zonder btw-categorie, of komen de categorie van een regel en die van de uitsplitsing niet overeen.
• BR-AE-02 … BR-AE-04 — verlegging zonder de identificaties van beide partijen. Voor categorie AE moeten het btw-nummer van de verkoper en het btw-nummer van de koper (of diens fiscale registratie) aanwezig zijn.
• BR-E-10 / BR-AE-10 — een vrijstellingsreden is vereist. Een vrijgestelde of verlegde uitsplitsing heeft een tekst (BT-120) of code (BT-121) voor de btw-vrijstellingsreden nodig; een uitsplitsing tegen het nultarief (BR-Z-10) mag er daarentegen geen dragen.
• BR-CL-xx — een code uit de verkeerde lijst. "PCE" is geen geldige eenheid; "C62" (één) of "H87" (stuk) wel. "EURO" is geen ISO 4217; "EUR" wel. Landcodes bestaan uit twee hoofdletters.
• BR-CO-09 — het btw-nummer van de verkoper mist het landvoorvoegsel ("123456789" in plaats van "DE123456789").
• BR-01 / niet-herkende CustomizationID — de profielidentificatie ontbreekt of noemt een profiel dat de ontvanger niet aanvaardt. Peppol en XRechnung vereisen elk hun eigen exacte string.
• Profielregels (PEPPOL-EN16931-Rxxx, BR-DE-xx) — de kern slaagt, maar de CIUS faalt: ontbrekende kopersreferentie (BR-DE-15), ontbrekend elektronisch adres van de verkoper, ontbrekende betaalwijze, of een verkeerd opgemaakte Leitweg-ID. Zie XRechnung en Peppol.

Om één bestand te controleren zonder een toolchain op te zetten, valideert de gratis e-factuurcontrole een document tegen de regels van een land en rapporteert de regelidentificaties zonder het bestand op te slaan.

Hoe KRONENWERK dit aanpakt

Ondersteund KRONENWERK genereert het gestructureerde document op het moment dat een factuur wordt uitgereikt en valideert het voordat het nummer wordt verbruikt: XRechnung en ZUGFeRD voor Duitsland, gecontroleerd met de KoSIT-Schematronregels en tegengecontroleerd met de Mustang-bibliotheek; Factur-X voor Frankrijk; Peppol BIS Billing 3.0 UBL voor België; FA(3) voor Polen. De btw-categorie op elke regel wordt afgeleid uit een opgeslagen fiscaal oordeel (normaal tarief, nultarief, vrijgesteld, verlegd, buiten het toepassingsgebied) in plaats van ingetypt, en het btw-nummer van een koper wordt bij de uitreiking tegen VIES gecontroleerd, zodat BR-AE- en BR-CO-09-fouten niet uit gegevensinvoer ontstaan. Inkomende XRechnung-, ZUGFeRD/Factur-X- en UBL-bestanden worden als inkoopfacturen ingelezen. Via de API maakt POST /invoices/drafts een concept aan en leest GET /invoices/{number} een uitgereikte factuur; het uitreiken, en dus de generatie en validatie, gebeurt in het product. De API aanvaardt of retourneert geen ruwe XML en valideert geen bestanden van derden — daarvoor dient de controle. Zie de productpagina over e-facturatie en de facturatie-API.