Bedrijven wisselen dagelijks grote hoeveelheden documenten met elkaar uit: offertes, orders, orderbevestigingen, verzendberichten, facturen en creditnota’s. Veel van die documenten worden nog altijd verstuurd als PDF, via e-mail of vanuit afzonderlijke portals. Voor mensen is dat goed leesbaar, maar voor systemen is zo’n document vaak nog niet direct bruikbaar.

Universal Business Language, beter bekend als UBL, is ontwikkeld om bedrijfsdocumenten niet alleen digitaal, maar ook gestructureerd uit te wisselen. De gegevens in een factuur, bestelling of leveringsbericht krijgen daarbij een vaste betekenis en positie.

Daardoor kan software de informatie rechtstreeks verwerken.

UBL vormt daarmee een belangrijke technische basis voor elektronische gegevensuitwisseling tussen organisaties. De standaard wordt internationaal gebruikt en speelt onder andere een centrale rol binnen elektronische facturatie en Peppol.

1. Wat is UBL?

UBL staat voor Universal Business Language. Het is een open standaard van OASIS voor het elektronisch uitwisselen van bedrijfsdocumenten.

De standaard definieert gegevensstructuren voor verschillende commerciële documenten. Denk daarbij niet alleen aan facturen en creditnota’s, maar ook aan bijvoorbeeld orders, orderbevestigingen, catalogi, verzendberichten en ontvangstbevestigingen.

UBL beschrijft hoe de informatie in zo’n document gestructureerd wordt vastgelegd.

Bij een factuur kan het bijvoorbeeld gaan om:

• factuurnummer;
• factuurdatum;
• leverancier;
• klant;
• btw-identificatie;
• valuta;
• orderreferentie;
• factuurregels;
• aantallen;
• prijzen;
• btw-percentages;
• betaalgegevens;
• en totalen.

Die gegevens worden niet op een willekeurige plaats gezet. UBL definieert welke elementen beschikbaar zijn en hoe deze zich tot elkaar verhouden.

De informatie wordt doorgaans vastgelegd in XML. Hierdoor ontstaat een bestand dat minder aantrekkelijk is om door mensen te lezen, maar juist zeer geschikt is voor verwerking door software.

UBL en XML zijn daarbij niet hetzelfde.

XML is de technische taal waarmee gegevens gestructureerd kunnen worden opgeslagen. UBL bepaalt vervolgens welke bedrijfsgegevens in die structuur voorkomen en wat zij betekenen.

2. Van digitale factuur naar gestructureerde factuur

Een belangrijk verschil bij elektronische facturatie is het onderscheid tussen een digitaal document en een gestructureerd elektronisch document.

Een PDF-factuur is digitaal, maar in eerste instantie bedoeld om door mensen te worden gelezen.

Op de factuur staat bijvoorbeeld:

Factuurnummer: 2026-10453

Een medewerker begrijpt direct wat daarmee bedoeld wordt. Voor software is die betekenis minder vanzelfsprekend. Eerst moet worden vastgesteld waar het factuurnummer staat en welke tekst of waarde erbij hoort.

Daarvoor kan bijvoorbeeld OCR of documentherkenning worden gebruikt.

Bij een UBL-factuur is dat niet nodig. Het factuurnummer staat in een daarvoor bedoeld gegevenselement. Het ontvangende systeem weet daardoor direct dat de betreffende waarde het factuurnummer is.

Hetzelfde geldt voor andere gegevens.

Een bedrag wordt niet alleen als tekst weergegeven, maar krijgt binnen de datastructuur bijvoorbeeld een betekenis als regelbedrag, btw-bedrag of totaal te betalen bedrag. Ook de valuta, leverancier en referenties worden als afzonderlijke gegevens vastgelegd.

Dat maakt directe systeemverwerking mogelijk.

3. UBL is meer dan een factuurformaat

UBL wordt in Nederland vaak vooral geassocieerd met elektronische facturen. Dat komt doordat UBL veel wordt gebruikt binnen e-invoicing en Peppol.

Maar de standaard is aanzienlijk breder.

UBL bevat datamodellen voor verschillende stappen binnen commerciële processen. Naast Invoice en CreditNote bestaan er bijvoorbeeld documenttypes voor Order, OrderResponse, Catalogue, DespatchAdvice en ReceiptAdvice.

Daarmee kan een groter deel van een Purchase-to-Pay- of Order-to-Cash-proces volgens dezelfde uitgangspunten worden gedigitaliseerd.

Denk bijvoorbeeld aan een inkoopproces:

order → orderbevestiging → verzending → ontvangst → factuur

Wanneer deze berichten gestructureerd worden uitgewisseld, kunnen systemen gedurende het hele proces naar dezelfde transacties en referenties verwijzen.

Een bestelling bevat bijvoorbeeld een ordernummer. Dat ordernummer kan opnieuw voorkomen in de orderbevestiging, het verzendbericht en uiteindelijk de factuur.

Daardoor ontstaat een digitale keten van bij elkaar horende transacties.

4. UBL, Peppol en EN 16931 hebben ieder een andere rol

UBL wordt regelmatig in één adem genoemd met Peppol. De begrippen zijn echter niet uitwisselbaar.

UBL beschrijft in de eerste plaats hoe een elektronisch bedrijfsdocument technisch kan worden gestructureerd.

Peppol gaat verder.

Peppol biedt afspraken voor interoperabiliteit en een netwerk waarlangs organisaties elektronische bedrijfsdocumenten kunnen uitwisselen. Binnen Peppol bestaan Business Interoperability Specifications, of BIS’en, waarin precies wordt vastgelegd welke gegevens voor een specifiek proces gebruikt moeten worden en welke regels daarbij gelden.

Voor elektronische facturatie in Europa speelt daarnaast EN 16931 een belangrijke rol.

EN 16931 definieert het semantische datamodel voor de kerngegevens van een elektronische factuur. Het beschrijft dus welke bedrijfsinformatie een e-factuur bevat en wat die informatie betekent.

UBL kan vervolgens worden gebruikt als technische syntax waarin die gegevens worden vastgelegd.

Peppol combineert deze verschillende lagen.

EN 16931
bepaalt welke informatie een Europese elektronische factuur semantisch bevat.

UBL
biedt een technische structuur waarin die informatie kan worden vastgelegd.

Peppol BIS/PINT
bepaalt hoe een specifieke subset van die informatie binnen een bedrijfsproces moet worden gebruikt.

Peppol-netwerk
zorgt ervoor dat het bericht van verzender naar ontvanger kan worden getransporteerd.

5. Niet iedere UBL-factuur is hetzelfde

Dit is één van de belangrijkste aandachtspunten rondom UBL.

De standaard is bewust uitgebreid.

Dat maakt UBL geschikt voor uiteenlopende landen, sectoren en bedrijfsprocessen, maar betekent tegelijkertijd dat twee organisaties verschillende onderdelen van de standaard kunnen gebruiken.

Wanneer organisatie A een UBL-bestand maakt en organisatie B ook UBL ondersteunt, is volledige interoperabiliteit dus niet automatisch gegarandeerd.

Daarvoor zijn aanvullende afspraken nodig.

Een specificatie kan bijvoorbeeld voorschrijven:

• welke UBL-elementen verplicht zijn;
• welke elementen niet gebruikt mogen worden;
• welke codelijsten toegestaan zijn;
• hoe partijen moeten worden geïdentificeerd;
• welke btw-regels gelden;
• en welke bedrijfsregels tussen waarden bestaan.

Peppol doet precies dat.

Een Peppol BIS gebruikt niet onbeperkt alle mogelijkheden van UBL, maar past een specifieke set regels toe.

6. De waarde van UBL ontstaat bij automatische verwerking

Het versturen van een XML-bestand is op zichzelf geen doel.

De werkelijke waarde van UBL ontstaat wanneer de gegevens aan de ontvangende kant automatisch verder kunnen worden verwerkt.

Bij een inkomende factuur kan bijvoorbeeld eerst technisch worden gecontroleerd of het document voldoet aan de afgesproken structuur.

Vervolgens kunnen aanvullende controles plaatsvinden.

Bestaat de leverancier? Komt het btw-nummer overeen? Is een ordernummer aanwezig? Is de factuur al eerder ontvangen? Kloppen bedragen en btw-berekeningen?

Daarna kan de factuur eventueel automatisch worden gekoppeld aan een bestelling en ontvangst.

Wanneer bestelling, ontvangst en factuur met elkaar overeenkomen, kan verdere handmatige behandeling grotendeels achterwege blijven.

Daarmee ontstaat straight-through processing.

Het verschil met documentherkenning is fundamenteel.

Bij een PDF probeert software eerst te bepalen welke informatie zich in het document bevindt. Bij UBL is die betekenis al vastgelegd voordat het document wordt verzonden.

Herkenning maakt plaats voor validatie.

7. UBL als onderdeel van een breder landschap voor documentuitwisseling

In de praktijk werkt vrijwel geen organisatie uitsluitend met UBL.

Leveranciers en klanten gebruiken verschillende ERP-systemen, netwerken, berichtenstandaarden en transportkanalen.

De ene leverancier stuurt een UBL-factuur via Peppol. Een andere levert een XML-bestand via SFTP. Een grote handelspartner gebruikt EDI. Een kleinere leverancier stuurt nog een PDF per e-mail. Binnen een specifieke sector kan daarnaast bijvoorbeeld DICO worden gebruikt.

Aan de ontvangende kant wil een organisatie deze verschillen uiteindelijk zoveel mogelijk abstraheren.

Daar ontstaat de functie van een integratielaag zoals 4CEE Exchange.

Verschillende kanalen kunnen daarin samenkomen, zoals Peppol, API, SFTP, EDI en e-mail. Berichten kunnen worden gevalideerd en waar nodig worden geconverteerd tussen bijvoorbeeld UBL, Peppol BIS, DICO, XRechnung, Factur-X of een ERP-specifiek formaat.

UBL vormt binnen zo’n landschap een belangrijke bouwsteen.

De kracht zit niet alleen in XML of in de standaard zelf, maar in het feit dat organisaties vooraf afspraken maken over de betekenis van gegevens.

Daardoor hoeft een factuur niet meer gelezen te worden om te begrijpen wat erin staat.

De gegevens kunnen rechtstreeks van systeem naar systeem bewegen.