Van document naar betrouwbare financiële data

Elektronische documentuitwisseling draait niet alleen om het ontvangen en verzenden van documenten. De waarde ontstaat pas echt wanneer de gegevens in die documenten ook juist, volledig en bruikbaar zijn.

Een factuur kan technisch probleemloos worden ontvangen en toch verkeerde informatie bevatten. Het btw-nummer kan ontbreken, het KvK-nummer kan niet overeenkomen met de leveranciersnaam, een bankrekening kan afwijken van de stamdata of een ordernummer kan niet worden gevonden in het ERP-systeem.

Datavalidatie vormt daarom een belangrijke laag tussen documentuitwisseling en verdere financiële verwerking. Zeker wanneer documenten toch al naar een intern formaat worden geconverteerd, ontstaat een logisch moment om gegevens centraal te controleren en waar mogelijk te verrijken.

Eerst normaliseren, daarna controleren

Documenten kunnen in verschillende formaten binnenkomen en dezelfde gegevens telkens anders structureren. Het is daarom inefficiënt om validatielogica afzonderlijk voor ieder formaat te ontwikkelen.

Een logische aanpak is om inkomende documenten eerst naar één canoniek of intern datamodel te converteren. Een leveranciersnaam, btw-nummer of factuurbedrag krijgt daarin steeds dezelfde betekenis en positie, ongeacht het oorspronkelijke formaat.

Daarna kan dezelfde validatielogica op alle documenten worden toegepast:

ontvangen → converteren → valideren → verrijken → converteren naar uitvoerformaat → afleveren

Zo komt validatie los te staan van formaat en transportkanaal. Een controle op bijvoorbeeld een KvK-nummer, IBAN of btw-nummer hoeft maar één keer te worden ingericht en kan vervolgens op iedere documentstroom worden toegepast.

Voor uitgaande documenten werkt hetzelfde principe. Het ERP levert gegevens aan in het afgesproken interne formaat. Die gegevens worden eerst gecontroleerd en eventueel verrijkt en daarna pas omgezet naar het formaat en kanaal dat de ontvanger verlangt.

Het centrale datamodel wordt daarmee niet alleen een tussenformaat voor conversie, maar ook het punt waarop datakwaliteit centraal kan worden bewaakt.

Controleren tegen vaste regels

De eerste laag van datavalidatie bestaat uit controles die rechtstreeks op de gegevens zelf kunnen worden uitgevoerd.

Een systeem kan bijvoorbeeld controleren of verplichte velden aanwezig zijn, of datums geldig zijn en of identificatienummers aan de vereiste structuur voldoen. Bij facturen kunnen daarnaast financiële controles worden uitgevoerd.

• Klopt de optelling van de factuurregels?
• Sluiten netto-, btw- en brutobedrag op elkaar aan?
• Is het factuurnummer aanwezig?
• Is een geldige valuta gebruikt?
• Heeft het btw-nummer een geldige structuur?
• Is het IBAN technisch geldig?
• Zijn verplichte bedrijfs- en adresgegevens aanwezig?

Veel van deze controles zijn volledig deterministisch. Er hoeft niets te worden geïnterpreteerd: een berekening klopt of klopt niet, een verplicht gegeven is aanwezig of ontbreekt en een identificatienummer voldoet wel of niet aan het vereiste patroon.

Bij gestructureerde elektronische documenten kunnen daarnaast de regels van de betreffende standaard of het gebruikte profiel worden toegepast. Een document kan technisch correct zijn opgebouwd en toch niet voldoen aan de vereiste businessregels.

Validatie gaat daarom verder dan controleren of een bestand technisch kan worden verwerkt. De relevante vraag is of de gegevens inhoudelijk betrouwbaar genoeg zijn om verder het financiële proces in te gaan.

Valideren tegen ERP en stamdata

Nog waardevoller wordt validatie wanneer gegevens uit een document worden vergeleken met informatie die de organisatie zelf al kent.

ERP-systemen en andere bronsystemen bevatten bijvoorbeeld stamdata over leveranciers, klanten, contracten, orders en juridische entiteiten. Daarmee kan veel gerichter worden gecontroleerd of een document daadwerkelijk past bij de bekende financiële werkelijkheid.

Een inkomende factuur kan bijvoorbeeld worden vergeleken met:

• leveranciersnaam en leveranciersnummer;
• KvK- en btw-nummer;
• IBAN en andere bankgegevens;
• adres- en contactgegevens;
• purchase order of contract;
• valuta en betaalvoorwaarden;
• de juridische entiteit waarvoor de factuur bestemd is.

Een IBAN kan bijvoorbeeld technisch geldig zijn, maar toch afwijken van het rekeningnummer dat bij de leverancier in het ERP staat geregistreerd. Technisch is er dan geen probleem, maar bedrijfsmatig is er wel aanleiding om de factuur nader te controleren.

Hetzelfde geldt voor bedrijfsidentiteit. Een leveranciersnaam alleen is niet altijd betrouwbaar genoeg. Bedrijven kunnen vergelijkbare namen hebben of hun handelsnaam anders schrijven dan hun juridische naam. Door naam, KvK-nummer, btw-nummer, adres en bankrekening in samenhang te controleren, ontstaat een veel betrouwbaarder beeld.

Ook procesgegevens kunnen worden gevalideerd. Wanneer een factuur verwijst naar een purchase order, kan worden gecontroleerd of die order bestaat, bij dezelfde leverancier hoort, nog openstaat en logisch aansluit op de gefactureerde goederen of diensten.

Daarmee verschuift validatie van alleen documentcontrole naar controle binnen de context van het Purchase-to-Pay- of Order-to-Cash-proces.

Derde bronnen als extra controlelaag

Niet alle relevante informatie hoeft uit het eigen ERP te komen. Gegevens kunnen ook worden gecontroleerd tegen externe bronnen.

Denk aan handelsregisters, btw-registers, adresbestanden, bankreferenties of commerciële databronnen. Daarmee kan bijvoorbeeld worden gecontroleerd of een KvK-nummer bestaat, of een btw-nummer geldig is, of een organisatie nog actief staat geregistreerd en of naam en adres overeenkomen met officiële registraties.

Externe bronnen zijn vooral waardevol wanneer een leverancier of klant nieuw is en de eigen stamdata nog beperkt is. Ze kunnen ook worden gebruikt om bestaande gegevens periodiek te controleren.

Daarbij is het belangrijk onderscheid te maken tussen valideren en overschrijven. Wanneer een externe bron een andere bedrijfsnaam of ander adres toont dan het ERP, betekent dat niet automatisch dat de externe waarde zonder controle moet worden overgenomen.

Een afwijking is in eerste instantie een signaal. Pas daarna kan worden bepaald welke bron leidend is en of aanpassing noodzakelijk is.

Ook vanuit governance is dat belangrijk. Bij financiële gegevens moet herleidbaar blijven waar informatie vandaan komt, welke controles zijn uitgevoerd en op basis waarvan gegevens eventueel zijn aangepast.

Van validatie naar verrijking

Dezelfde infrastructuur die gegevens controleert, kan ze ook verrijken.

Validatie stelt vooral de vraag: klopt dit gegeven? Verrijking voegt daar een tweede vraag aan toe: welke betrouwbare informatie kunnen we toevoegen zodat het document verder kan worden verwerkt?

Een factuur bevat bijvoorbeeld wel een leveranciersnaam en btw-nummer, maar geen intern leveranciersnummer. Wanneer de leverancier eenduidig kan worden gekoppeld aan de stamdata, kan dat interne nummer automatisch worden toegevoegd.

Op dezelfde manier kunnen bijvoorbeeld een contractnummer, interne klantcode, juridische entiteit, purchase-orderreferentie, kostenplaats of artikelcode worden toegevoegd.

Verrijking kan ook bestaan uit het standaardiseren van gegevens. Een bedrijfsnaam kan in verschillende schrijfwijzen voorkomen, een adres kan anders zijn opgebouwd en landcodes kunnen in verschillende vormen worden aangeleverd. Door deze gegevens naar één interne standaard te normaliseren, worden vergelijking en verdere verwerking eenvoudiger.

Daarbij is wel een belangrijk onderscheid nodig tussen feitelijke verrijking en interpretatieve verrijking.

Het toevoegen van een leveranciersnummer op basis van een exacte match met het btw-nummer kan deterministisch zijn. Het voorspellen van een grootboekrekening op basis van historische facturen is dat niet. Daar kan AI een rol spelen, maar de uitkomst is dan een interpretatie of waarschijnlijkheidsinschatting en geen vastgesteld financieel feit.

Een betrouwbare architectuur houdt die twee soorten verrijking uit elkaar. Objectieve gegevens kunnen automatisch worden toegevoegd, terwijl interpretatieve uitkomsten binnen vooraf bepaalde kaders kunnen worden voorgesteld, gecontroleerd of verwerkt.

Eén validatielaag voor de volledige documentstroom

De kracht van deze aanpak zit uiteindelijk in centralisatie. Wanneer documenten toch al via een exchange-laag worden ontvangen, geconverteerd en doorgestuurd, is diezelfde laag een logisch punt om datakwaliteit te bewaken.

Een inkomende factuur kan eerst worden geconverteerd naar het interne model. Daar worden bedragen, bedrijfsgegevens, btw-informatie, bankgegevens en referenties gecontroleerd tegen vaste regels, stamdata en eventueel externe bronnen. Ontbrekende informatie kan waar verantwoord worden aangevuld.

Pas daarna gaat het document verder naar het ERP of Purchase-to-Pay-proces.

Voor uitgaande documenten werkt het precies andersom. Het ERP levert de gegevens aan, waarna dezelfde validatielaag controleert of de informatie volledig en correct is voordat het document naar het gewenste uitvoerformaat wordt geconverteerd en verzonden.

Hierdoor gelden dezelfde controles voor verschillende documentstromen, handelspartners, formaten en kanalen. Validatieregels hoeven niet telkens opnieuw in ERP-systemen, integraties of afzonderlijke mappings te worden gebouwd.

Dat maakt formaatconversie en datavalidatie nauw met elkaar verbonden. Formaatconversie brengt verschillende documenten terug naar één gemeenschappelijke datastructuur. Validatie en verrijking zorgen er vervolgens voor dat de gegevens binnen die structuur betrouwbaar en bruikbaar zijn.

Het resultaat is niet alleen betere documentuitwisseling, maar een betere financiële basis. Problemen worden gesignaleerd voordat gegevens verder het Purchase-to-Pay- of Order-to-Cash-proces ingaan of bij een handelspartner terechtkomen.

Zo wordt datavalidatie geen losse controle achteraf, maar een structureel onderdeel van de documentstroom: één centrale laag waarin gegevens worden gecontroleerd, vergeleken en waar mogelijk verrijkt voordat ze verder worden verwerkt.