De techniek achter formaatconversie

Digitale documentuitwisseling tussen bedrijven lijkt op het eerste gezicht vooral een transportvraagstuk: een factuur, order of pakbon moet veilig van systeem A naar systeem B. In de praktijk zit een groot deel van de complexiteit echter niet in het transport, maar in het formaat van de gegevens.

Een SAP-systeem kan een factuur als IDoc produceren, een bouwbedrijf werkt met DICO SALES005, een leverancier stuurt UBL 2.1, een internationale handelspartner gebruikt EDIFACT en een andere partij levert nog altijd een PDF of CSV-bestand aan. De ontvangende ERP-systemen verwachten ondertussen ieder hun eigen datastructuur.

Formaatconversie vormt daarom een belangrijke laag binnen elektronische documentuitwisseling. Niet door ieder systeem alle mogelijke formaten te laten begrijpen, maar door documenten centraal te herkennen, interpreteren, valideren en om te zetten naar het formaat dat verzender en ontvanger nodig hebben.

Een formaat is meer dan XML, PDF of CSV

Wanneer over documentformaten wordt gesproken, worden vaak brede begrippen als XML en PDF gebruikt. Technisch zegt dat nog relatief weinig.

XML beschrijft bijvoorbeeld vooral hoe gegevens hiërarchisch kunnen worden vastgelegd. Twee XML-bestanden kunnen volledig verschillende structuren, veldnamen en regels gebruiken.

Een UBL-factuur bevat bijvoorbeeld elementen als Invoice, AccountingSupplierParty, TaxTotal en LegalMonetaryTotal. Een SAP IDoc gebruikt segmenten en velden volgens een geheel andere structuur. DICO SALES005 kent weer eigen XML-schema’s, namespaces en businessregels voor transactieberichten binnen de bouw- en technieksector.

Zelfs binnen één familie bestaan verschillende versies en profielen. Organisaties kunnen onder andere te maken krijgen met:

• OASIS UBL 2.0, 2.1, 2.2 en 2.3
• Peppol BIS Billing 3.0 op basis van UBL 2.1
• UN/CEFACT Cross Industry Invoice, waaronder CII D16B
• UN/EDIFACT INVOIC, bijvoorbeeld D96A of D16B
• SAP IDoc INVOIC01 en INVOIC02
• DICO INSBOU004 en SALES005
• cXML InvoiceDetail
• xCBL
• Factur-X en ZUGFeRD
• XRechnung
• leveranciers- en klantspecifieke XML- en JSON-formaten
• CSV-, Excel- en fixed-widthbestanden
• PDF, al dan niet gecombineerd met gestructureerde XML-data

De extensie .xml zegt dus weinig over daadwerkelijke interoperabiliteit. Twee systemen kunnen allebei XML spreken en elkaar toch niet begrijpen.

EN 16931: eerst dezelfde betekenis, daarna dezelfde syntax

Voor elektronische facturen binnen Europa speelt EN 16931 een centrale rol. Daarbij is een belangrijk onderscheid nodig: EN 16931 is geen XML-formaat, maar in de kern een semantisch datamodel voor elektronische facturen.

De standaard beschrijft welke bedrijfsinformatie een elektronische factuur bevat en wat die informatie betekent. Denk aan factuurnummer, factuurdatum, leverancier, afnemer, btw-categorie, betaalvoorwaarden, factuurregels en totalen.

Diezelfde betekenis kan vervolgens in verschillende technische syntaxes worden vastgelegd. Binnen de Europese standaard spelen onder andere de volgende syntaxes een rol:

• OASIS UBL 2.1
• UN/CEFACT Cross Industry Invoice D16B
• UN/EDIFACT INVOIC D16B

Dat onderscheid tussen semantiek en syntax is essentieel voor formaatconversie.

Stel dat een inkomend SAP IDoc een veld bevat voor het btw-identificatienummer van de leverancier. Bij conversie wordt niet simpelweg een XML-tag vervangen door een andere XML-tag. Eerst moet worden vastgesteld welke betekenis het bronveld heeft. Daarna wordt bepaald naar welk gegeven in het doelmodel die informatie moet worden vertaald.

De conversielaag werkt daarmee in feite volgens het principe:

bronveld → betekenis → doelveld

Dit maakt het mogelijk om veel verschillende bronformaten te koppelen aan één afgesproken financieel datamodel.

UBL 2.1, Peppol en andere implementatieprofielen

Ook wanneer twee partijen allebei UBL gebruiken, kan conversie of normalisatie noodzakelijk blijven.

UBL — Universal Business Language — is een uitgebreide OASIS-standaard voor elektronische handelsdocumenten. Naast Invoice en CreditNote bevat UBL bijvoorbeeld structuren voor Order, OrderResponse en DespatchAdvice.

Bovendien bestaan verschillende UBL-versies. Een organisatie kan bijvoorbeeld intern UBL 2.3 gebruiken, terwijl een netwerk of ontvanger UBL 2.1 voorschrijft.

Peppol BIS Billing 3.0 is hiervan een goed voorbeeld. Voor facturen en creditnota’s gebruikt Peppol UBL 2.1 en legt daar aanvullende semantische en businessregels bovenop. Peppol BIS Billing is daarmee niet zomaar UBL, maar een specifiek gebruiksprofiel dat aansluit op EN 16931.

Een willekeurige technisch geldige UBL 2.1-factuur is daarom niet automatisch een geldige Peppol-factuur.

Een document moet onder meer voldoen aan:

• de XML-structuur van UBL 2.1;
• de semantische regels van EN 16931;
• de aanvullende regels van Peppol BIS Billing;
• eventuele nationale of sectorspecifieke regels.

Formaatconversie kan daardoor bijvoorbeeld neerkomen op:

bedrijfsspecifiek UBL 2.3 → canoniek factuurmodel → Peppol BIS Billing 3.0 / UBL 2.1

Het verschil zit dus niet alleen in XML-tags, maar vooral in de regels die bepalen hoe die tags moeten worden gebruikt.

Van SAP IDoc, EDIFACT en DICO naar een gemeenschappelijk model

Bij grote organisaties is de diversiteit vaak nog groter.

SAP gebruikt al decennialang IDocs — Intermediate Documents — voor gegevensuitwisseling tussen SAP en externe systemen. Voor facturatie zijn onder andere INVOIC01 en INVOIC02 bekend. Een IDoc bestaat uit segmenten met velden die binnen SAP een specifieke technische en functionele betekenis hebben.

Een SAP IDoc is geen EN 16931-factuur en ook geen UBL-document. De relevante segmenten moeten daarom inhoudelijk worden gemapt naar het gewenste doelmodel.

In omvangrijke B2B-omgevingen komt daarnaast nog veel UN/EDIFACT voor. Een INVOIC-bericht kan bijvoorbeeld gebruikmaken van segmenten als:

• UNH voor de berichtheader;
• BGM voor documentinformatie;
• DTM voor datums;
• NAD voor partijen;
• LIN voor factuurregels;
• MOA voor bedragen;
• TAX voor belastinginformatie.

Binnen de Nederlandse bouw- en technieksector speelt DICO een vergelijkbare sectorspecifieke rol. DICO omvat gestandaardiseerde berichten voor onder andere offertes, orders, orderbevestigingen, verzendberichten en facturen. Binnen SALES005 worden daarvoor XML-structuren gebruikt die specifiek zijn ingericht voor de informatiebehoefte binnen die sector.

Een leverancier kan daardoor bijvoorbeeld een DICO SALES005-factuur produceren, terwijl de klant intern UBL gebruikt of de factuur via Peppol wil ontvangen.

Dan kunnen conversieketens ontstaan zoals:

DICO SALES005 → canoniek model → UBL 2.1 / Peppol BIS Billing

SAP INVOIC02 → canoniek model → DICO SALES005

EDIFACT INVOIC D96A → canoniek model → UBL 2.1

Een centraal of canoniek model voorkomt dat voor iedere combinatie een afzonderlijke converter moet worden gebouwd. Bij tien bronformaten en tien doelformaten kan een point-to-pointbenadering anders tientallen afzonderlijke mappings opleveren.

Converteren betekent ook interpreteren en valideren

Een goede converter verplaatst niet alleen gegevens. Tijdens conversie moeten ook verschillen in datatype, structuur, codering en businesslogica worden opgelost.

Een bronformaat kan bijvoorbeeld NL, NLD of 528 gebruiken om Nederland aan te duiden. Het doelformaat kan uitsluitend een ISO 3166-1 alpha-2-code toestaan. Een lokale btw-code in het bronsysteem kan semantisch overeenkomen met een bepaalde EN 16931-btw-categorie, maar mag niet zonder mapping worden doorgegeven.

Hetzelfde geldt voor:

• valutacodes;
• eenheden;
• betaalmethoden;
• btw-categorieën;
• documenttypen;
• identificatieschema’s;
• landcodes;
• artikel- en leveranciersidentificaties.

Ook financiële berekeningen vragen aandacht. Een factuur kan afzonderlijke waarden bevatten voor nettoregelbedrag, korting, toeslag, btw-grondslag, btw-bedrag, subtotaal, vooruitbetaald bedrag, afronding en te betalen bedrag.

Het doelmodel kan andere reken- en afrondingsregels voorschrijven dan het bronsysteem. Een XML-document kan daardoor technisch correct zijn en financieel toch ongeldig.

Validatie vindt daarom meestal op meerdere niveaus plaats. Eerst kan een XML-document tegen een XSD-schema worden gecontroleerd om vast te stellen of de technische structuur klopt. Vervolgens kunnen met bijvoorbeeld Schematron-regels inhoudelijke en bedrijfsmatige controles worden uitgevoerd.

Een conversieproces bestaat daarmee eerder uit:

herkennen → uitlezen → normaliseren → mappen → converteren → valideren → afleveren

Wanneer gegevens ontbreken of niet eenduidig kunnen worden geconverteerd, moet dat worden gesignaleerd. Een converter mag ontbrekende financiële feiten niet zelf verzinnen om een document technisch passend te maken.

Eén formaat aan de binnenkant, veel formaten aan de buitenkant

Voor organisaties is het weinig aantrekkelijk om hun ERP telkens opnieuw aan te passen zodra een leverancier, klant, sectorstandaard, netwerk of overheid een ander formaat verlangt.

Een centrale conversielaag draait dat principe om.

Het ERP kan bijvoorbeeld altijd hetzelfde afgesproken XML-formaat produceren en ontvangen. De exchange-laag vertaalt dit aan de buitenkant naar UBL 2.1, Peppol BIS Billing, CII D16B, DICO SALES005, SAP IDoc, EDIFACT, cXML, JSON, CSV of een klantspecifiek formaat.

Ook ongestructureerde documenten kunnen daarin worden opgenomen. Een PDF kan met documentherkenning worden uitgelezen en vervolgens naar hetzelfde centrale datamodel worden vertaald. Bij hybride formaten als Factur-X en ZUGFeRD worden juist een voor mensen leesbare PDF en gestructureerde XML-data gecombineerd.

Daarmee wordt formaatconversie veel meer dan een technische vertaalfunctie. Het wordt een normalisatielaag tussen handelspartners, netwerken en ERP-systemen.

Aan de buitenkant mag de wereld complex blijven: UBL 2.1, CII D16B, INVOIC02, DICO SALES005, EDIFACT, PDF, CSV en toekomstige standaarden kunnen naast elkaar bestaan. Aan de binnenkant hoeft een financieel systeem die complexiteit niet allemaal te kennen.

Dat is uiteindelijk de belangrijkste functie van formaatconversie: niet ieder systeem ieder formaat leren begrijpen, maar ervoor zorgen dat dezelfde financiële betekenis betrouwbaar behouden blijft, ongeacht de technische taal waarin het document binnenkomt of vertrekt.