EN16931 begrijpen: het Europese factuurgegevensmodel

EN16931 is de Europese standaard die bepaalt wat een e-factuur moet bevatten. Het is geen XML-formaat. Het is een semantisch gegevensmodel. Elk belangrijk Europees e-factuurformaat, of het nu Peppol BIS Billing 3.0, Factur-X, ZUGFeRD of XRechnung is, vormt een implementatie van EN16931 in een specifieke XML-syntaxis.

Inzicht in EN16931 bespaart tijd bij het debuggen van validatiefouten, het uitleggen van integratievereisten aan ERP-leveranciers of het implementeren van een nieuw factuurprofiel vanaf de grond.

Wat EN16931 precies specificeert

EN16931 bestaat uit twee delen:

EN 16931-1 definieert het semantische gegevensmodel: welke data-elementen een factuur kan bevatten, welke verplicht zijn en wat de business rules zijn
EN 16931-2 definieert de syntaxbindingen: hoe het semantische model wordt gekoppeld aan UBL 2.1 XML en UN/CEFACT CII XML

Het resultaat is dat een Peppol BIS Billing 3.0 UBL-factuur en een Factur-X CII-factuur dezelfde bedrijfsfactuur kunnen representeren. De semantische inhoud is identiek. De XML-syntaxis is volledig anders.

Business Terms en Business Groups

EN16931 organiseert factuurgegevens in Business Groups (BG) en Business Terms (BT).

Een Business Group is een verzameling gerelateerde termen. Een Business Term is een enkel data-element met een gedefinieerde identificator, naam, kardinaliteit en datatype.

De belangrijkste groepen op het hoogste niveau:

Groep	Inhoud
BG-2 Procesbeheersing	Specificatie-identifier (BT-24), type bedrijfsproces (BT-23)
BG-4 Verkoper	Naam, adres, btw-nummer, wettelijke registratie
BG-7 Koper	Naam, adres, referentie-identificator, elektronisch adres
BG-22 Documenttotalen	Belastinggrondslag, factuurtotaal, btw-bedrag, te betalen bedrag
BG-25 Factuurregel	Hoeveelheid, eenheidsprijs, btw-tarief, nettobedrag regel

Het volledige model omvat meer dan 150 BT’s verdeeld over alle groepen. De meeste implementaties hebben slechts een deelverzameling nodig, maar het valideren van een document vereist kennis van welke BT’s verplicht zijn voor het doelprofiel.

Business Terms waar developers op struikelen

De meeste validatiefouten ontstaan door een kleine set BT’s die worden misverstaan of slecht gedocumenteerd zijn in implementatiehandleidingen.

BT-24: Specificatie-identifier

Dit moet een specifieke URI zijn die aangeeft aan welk profiel de factuur beweert te voldoen. Voor Peppol BIS Billing 3.0:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1

Als dit fout is, wijst de validator van de ontvanger de factuur af voordat hij ook maar een veld controleert. Elk profiel (EN16931-kern, Peppol BIS 3.0, Peppol BIS 3.0 met nationale extensie) heeft een andere URI.

BT-10: Koperreferentie

Wordt in verschillende landen anders gebruikt. In Duitsland bevat dit veld de Leitweg-ID, een verplichte routeringsidentificator voor B2G-facturen. In de meeste andere landen is het een interne inkooporderreferentie of wordt het leeg gelaten. Het veld is optioneel in de EN16931-basis maar verplicht in het Duitse nationale profiel.

BT-49: Elektronisch adres koper

Het Peppol-deelnemers-ID van de koper. Formaat: schema:identificator. Voor een Belgisch bedrijf geidentificeerd via ondernemingsnummer:

<cbc:EndpointID schemeID="0208">0468863455</cbc:EndpointID>

Vereist bij verzending via het Peppol-netwerk. Veel implementaties laten het weg bij B2B-facturen buiten Peppol, wat acceptabel is in de EN16931-basis maar ongeldig is in Peppol BIS-profielen.

BT-131: Nettobedrag factuurregel

Het nettobedrag voor een enkele regel, berekend als hoeveelheid maal eenheidsprijs minus eventuele kortingen op regelniveau. EN16931-bedrijfsregel BR-CO-10 vereist dat de som van alle BT-131-waarden gelijk is aan BT-106 (som van de nettobedragen van factuurregels).

Afronding is hier van belang. De standaard verwacht dat rekenkundige bewerkingen worden uitgevoerd op ruwe waarden en afgerond op het aggregaatniveau, niet per regel. Als elke regel afzonderlijk wordt afgerond en de afgeronde waarden vervolgens worden opgeteld, ontstaan er discrepanties die BR-CO-10 laten mislukken bij grote hoeveelheden.

BT-110: Btw-bedrag per belastingcategorie

Het btw-bedrag per belastingcategorie. EN16931-regel BR-CO-15 vereist dat het factuurtotaal minus de belastinggrondslag gelijk is aan de som van alle BT-117 (btw-bedragen per categorie). Fouten hier worden vaak veroorzaakt door drijvendepunt-rekenkunde of vroegtijdige afronding.

Business Rules: de validatielaag

Business Rules (BR) zijn formele beperkingen uitgedrukt in Schematron. Er zijn twee categorieen.

Structurele regels controleren veldaanwezigheid en -formaat:

BR-01: Een factuur moet een specificatie-identifier hebben (BT-24).
BR-02: Een factuur moet een factuurnummer hebben (BT-1).
BR-04: Een factuur moet een valutacode hebben (BT-5).

Rekenkundige regels controleren de rekensomconsistentie:

BR-CO-10: Som nettobedragen factuurregels (BT-106) = som van alle BT-131-waarden.
BR-CO-15: Totaal btw-bedrag factuur (BT-110) = som van alle BT-117-waarden.
BR-CO-16: Te betalen bedrag (BT-115) = Factuurtotaal incl. btw (BT-112)
          - Betaald bedrag (BT-113) + Afrondingsbedrag (BT-114).

Peppol BIS 3.0 voegt nationale extensieregels toe bovenop de EN16931-basisregels. Voorbeelden:

BR-DE-TMP-32: Leveringsdatum (BT-72) is verplicht voor Duitse B2G-facturen.
BR-DE-18:     Btw-identificator verkoper (BT-31) of belastingregistratie (BT-32)
              moet aanwezig zijn.

Deze extensieregels varieren per landprofiel en worden gepubliceerd bij elke Peppol BIS-release.

Hoe EN16931 koppelt aan UBL en CII

De twee XML-syntaxen verwerken dezelfde BT’s maar gebruiken volledig andere elementnamen en -structuren. Dat is waarom code die UBL-facturen parseert, CII-facturen niet zonder afzonderlijke implementatie kan parsen, ook al zijn beide EN16931-conform.

Naam verkoper (BT-27) in beide syntaxen:

UBL 2.1:

<cac:AccountingSupplierParty>
  <cac:Party>
    <cac:PartyName>
      <cbc:Name>Acme GmbH</cbc:Name>
    </cac:PartyName>
  </cac:Party>
</cac:AccountingSupplierParty>

UN/CEFACT CII:

<ram:SellerTradeParty>
  <ram:Name>Acme GmbH</ram:Name>
</ram:SellerTradeParty>

Beide koppelen aan BT-27. De semantische inhoud is identiek. Het XML-pad verschilt volledig.

Peppol BIS 3.0 gebruikt UBL. Factur-X en ZUGFeRD gebruiken CII. XRechnung ondersteunt beide. Het EN16931-2-toewijzingsdocument (gratis beschikbaar via CEN/TC 434) vermeldt beide paden voor elke BT en is het raadplegen waard tijdens de implementatie.

Schematron-validatie

EN16931-validatie is geimplementeerd als Schematron-regels die zijn voorgecompileerd naar XSLT 2.0. De officiele regelsets worden gepubliceerd bij elke Peppol BIS-release:

github.com/OpenPEPPOL/peppol-bis-invoice-3/releases

De artefacten bevatten gecompileerde XSLT-bestanden:

peppol-en16931-ubl.xsl    (voor UBL-facturen)
peppol-en16931-cii.xsl    (voor CII-facturen)

Het uitvoeren van een van beide op een factuur levert SVRL (Schematron Validation Report Language) op. Een mislukte regel ziet er als volgt uit:

<svrl:failed-assert test="..." location="/Invoice/...">
  <svrl:text>
    [BR-CO-10]-Sum of Invoice line net amount (BT-106) = 
    sum of Invoice line net amount (BT-131).
  </svrl:text>
</svrl:failed-assert>

Er is een XSLT 2.0-processor vereist. In .NET is Saxon HE (open source, geen enterprise-licentie nodig) de standaardkeuze. In Java werken zowel Saxon als Xerces.

Veelgemaakte implementatiefouten

UBL- en CII-elementpaden door elkaar gebruiken. Developers die met beide formaten werken, plakken elementnamen van de verkeerde binding. Het EN16931-2-toewijzingsdocument voorkomt dit.

Ervan uitgaan dat aanwezigheidsregels gelijk zijn voor alle profielen. Een veld dat optioneel is in de EN16931-basis, kan verplicht zijn in Peppol BIS 3.0 of in een nationale extensie. Valideer altijd tegen het doelprofiel, niet tegen de basisstandaard.

Afronden op het verkeerde niveau. Bereken ruwe rekenkundige totalen over alle regels en rond het aggregaat dan af. Per regel afzonderlijk afronden en de afgeronde waarden optellen levert rekenkundige inconsistenties op die BR-CO-10 laten mislukken, vaak met een paar cent verschil bij grote facturen met veel regels.

Verkeerde BT-24 voor het doelprofiel. Elk profiel heeft een specifieke URI als specificatie-identifier. Het gebruik van de EN16931-basis-URI op een Peppol BIS 3.0-factuur zorgt ervoor dat profileniveau-validatie het document direct afwijst.

Btw-categorie-codes hardcoderen. EN16931 definieert specifieke codewaarden voor btw-categorieen (S, Z, E, AE, K, G, O, L, M). Veel implementaties coderen “S” (standaard tarief) vast en breken bij de verwerking van verlegde of nultarief-facturen.

EN16931 is infrastructuurkennis

EN16931 ligt ten grondslag aan elk Europees e-factuurmandaat. Naarmate vereisten worden uitgerold in Belgie, Frankrijk, Duitsland en Polen, wordt inzicht in het semantische model steeds belangrijker voor developers die factuurpijplijnen bouwen of onderhouden.

Inzicht in de BT/BG-structuur, de rekenregels en de syntaxbindingen stelt je in staat validatiefouten te debuggen die anders uren specificatielezen zouden vereisen, nieuwe profielen schoon te implementeren en helder te communiceren met ERP-leveranciers en complianceteams.

Het praktische probleem is niet EN16931 eenmalig leren. Het is implementaties correct houden naarmate regelsets worden bijgewerkt bij elke Peppol BIS-release, nationale extensies nieuwe verplichte velden toevoegen en afrondingsrandgevallen in productie opduiken met echte factuurgegevens uit echte ERP-systemen.

SealDoc wordt geleverd met regelsets die Peppol BIS-releases bijhouden. Wanneer je een factuur genereert via de SealDoc-API, wordt het document gevalideerd tegen het juiste profiel voordat het het systeem verlaat. BR-CO-10 en BR-CO-15 worden serverside afgedwongen zodat afrondingsfouten je kopers niet bereiken. Wanneer je een validatiefout ontvangt van een handelspartner, accepteert de SealDoc publieke validator het document en koppelt elke fout terug aan de specifieke BT en BR die is geschonden, wat de diagnosetijd van uren naar minuten terugbrengt.

Als je EN16931 implementeert vanaf de grond, is de validator een nuttig kalibratiemiddel: genereer een kandidaatdocument, voer het door de validator, los op wat het rapport aangeeft en herhaal.