Waarom je ERP facturen genereert, geen bewijs
ERP- en boekhoudsoftware zijn opvallend goed in het werk waarvoor ze zijn ontworpen: transacties op grote schaal verwerken, goedkeuringsworkflows afdwingen en gestructureerde output leveren die andere systemen kunnen gebruiken. Zo worden elke dag miljoenen facturen zonder incidenten gegenereerd.
Maar er is een andere taak waarvoor ERP-software nooit is ontworpen, en dat onderscheid doet ertoe zodra een belastingdienst, rechtbank of toezichthouder een lastigere vraag stelt dan “laat me de factuur zien”.
De vraag die de meeste software niet kan beantwoorden
Wordt een routinefactuur betwist, dan volstaat het meestal om de pdf te tonen. De koper herkent hem, de verkoper bevestigt hem, en de zaak is opgelost. Op die workflow is ERP-software geoptimaliseerd.
Een lastigere vraag ziet er zo uit: “Bewijs dat deze factuur op deze datum in precies deze vorm bestond, dat hij sindsdien niet is gewijzigd, en dat de persoon die zegt hem te hebben verstuurd, hem werkelijk via jullie systeem heeft verstuurd.”
Dat is geen documentvraag. Het is een bewijsvraag. En aan bewijs worden andere eisen gesteld dan aan documenten.
Een document is een vastlegging van een transactie. Bewijs is een verifieerbare vastlegging die onafhankelijk onderzoek doorstaat, ook onderzoek door iemand die het actief probeert te betwisten.
Wat ERP-software wel biedt
Om precies te zijn over het gat, helpt het om helder te hebben wat ERP-software goed doet.
De meeste moderne ERP-systemen bieden:
Gestructureerde factuurgegevens. Facturen staan in een database met duidelijke relaties tussen kopers, verkopers, factuurregels, totalen en datums. Daardoor zijn ze doorzoekbaar, controleerbaar via de eigen interface van het ERP en exporteerbaar in gestandaardiseerde formaten zoals UBL- of CII-XML.
Goedkeurings- en auditlogs. De meeste ERP-systemen leggen vast wie wat wanneer heeft goedgekeurd. Die logs zijn nuttig bij interne controles en kunnen aantonen dat het juiste proces is gevolgd.
Formaatconformiteit. Voor Factur-X, ZUGFeRD, XRechnung en Peppol genereert moderne ERP-software XML die valideert tegen het betreffende schema. Daarmee is voldaan aan de formaateis van de EU-verplichtingen voor e-facturatie.
Export en overdraagbaarheid. Facturen kunnen doorgaans in bulk worden geëxporteerd, als XML, als pdf of allebei. Dat dekt de toepassing van dataportabiliteit.
Niets hiervan is triviaal. Formaatconformiteit is een echt technisch vraagstuk waarin ERP-leveranciers veel werk hebben gestoken. Het punt is niet dat ERP-software tekortschiet. Het punt is dat formaatconformiteit noodzakelijk is, maar niet voldoende voor juridisch bewijs.
Wat ERP-software niet biedt
Het gat verschijnt zodra je om onafhankelijke verificatie vraagt van drie dingen die juridische procedures vaak vereisen.
Bewijs van bestaan op een specifiek moment. Een tijdstempel die in je eigen systeem staat, is maar zo betrouwbaar als je systeem. Beheer je het systeem, dan kan een tegenpartij aanvoeren dat je ook de tijdstempel in de hand had. Een RFC 3161-tijdstempel van een onafhankelijke Time Stamping Authority is cryptografisch ondertekend door een derde partij en kan niet achteraf worden vervalst zonder de handtekening ongeldig te maken. De meeste ERP-systemen geven geen RFC 3161-tijdstempels uit en slaan ze ook niet op.
Bewijs van integriteit sinds dat moment. Een pdf- of XML-bestand in een database kan worden gewijzigd. Een databaserecord kan worden bijgewerkt. Zonder een onafhankelijke hashvastlegging (een cryptografische vingerafdruk die bij het aanmaken is gemaakt en ergens buiten je eigen controle is opgeslagen) kun je niet bewijzen dat het document sindsdien niet is gewijzigd. De meeste ERP-systemen maken of bewaren geen cryptografische hashvastleggingen die aan hun records zijn gekoppeld.
Een onafhankelijke chain of custody. Weten dat een document vandaag in een bepaalde staat bestaat, is iets anders dan weten hoe het in die staat is beland. Een chain of custody legt elke handeling op een document vast (wie het heeft geopend, wat er is gedaan en in welke volgorde) in een manipulatiebestendig log. Dat is standaard in juridische en toezichtprocedures, maar zo zijn auditlogs van ERP-systemen doorgaans niet gebouwd.
Wanneer dit in de praktijk telt
Het gat tussen document en bewijs is niet academisch. Dit zijn de situaties waarin het aan het licht komt.
Onderzoeken door de belastingdienst. In meerdere EU-jurisdicties kan de belastingdienst van bedrijven eisen dat ze de integriteit van hun elektronische factuuradministratie aantonen. Een bedrijf dat facturen kan tonen maar niet kan aantonen dat ze sinds de uitgifte niet zijn gewijzigd, staat zwakker dan een bedrijf dat naast de factuur een cryptografisch bewijs van integriteit kan overleggen.
Commerciële geschillen. Betwist een koper een factuur, omdat die achteraf zou zijn gewijzigd of omdat de bedragen niet zouden kloppen met wat is afgesproken, dan moet de verkoper aantonen dat het document authentiek en ongewijzigd is. Een RFC 3161-tijdstempel met een hashketen levert dat bewijs. Een pdf uit een ERP-systeem zonder onafhankelijke verificatie doet dat niet.
Toezichtaudits in de financiële sector. Ondernemingen die onder MiFID II, Solvency II of vergelijkbare kaders vallen, moeten hun administratie zo bijhouden dat integriteit en authenticiteit aantoonbaar zijn. De concrete eisen verschillen, maar de algemene verwachting is dat vastleggingen niet ongemerkt kunnen worden gewijzigd. Dat is een hogere lat dan gangbare ERP-opslag.
Contractgeschillen met lange bewaartermijnen. Bewaartermijnen voor facturen in de EU lopen van 7 jaar (de gangbare norm voor btw-facturen) tot 20 jaar voor bepaalde overheidsarchieven onder Nederlands recht. In een periode van 7 jaar kan veel veranderen: het ERP-systeem kan worden vervangen, de database kan worden gemigreerd, de pdf-bestanden kunnen opnieuw worden geëxporteerd. Zonder tijdstempel en hashketen die bij het aanmaken zijn verankerd, wordt het lastig te bewijzen dat een 7 jaar oude factuur niet is gewijzigd.
Het misverstand over formaatconformiteit
Een veelgehoorde aanname is dat een factuur die voldoet aan Factur-X of Peppol, juridisch als bewijs toelaatbaar is. Formaatconformiteit betekent dat de factuur valideert tegen het schema en de verplichte velden bevat. Het zegt niets over wanneer het document is gemaakt, of het is gewijzigd, of dat de vastlegging onafhankelijk te verifiëren is.
Factur-X is een bestandsformaat. RFC 3161 is een bewijsprotocol. Ze werken op verschillende lagen van de compliancestack, en het ene vervangt het andere niet.
Een vergelijking uit de fysieke wereld: een door een notaris gewaarmerkt document en een geprint document zijn allebei documenten. Het waarmerk van de notaris voegt een laag onafhankelijke verificatie toe: een vertrouwde derde partij die verklaart wanneer en door wie het document is ondertekend. Formaatconformiteit staat dichter bij printen dan bij het waarmerk van een notaris.
Wat de bewijslaag werkelijk vereist
Verifieerbaar bewijs voor een digitaal document vereist minimaal drie dingen.
Een vertrouwde tijdstempel. Een RFC 3161-tijdstempel van een Time Stamping Authority levert een cryptografisch bewijs van bestaan op een specifiek moment. De TSA is een onafhankelijke partij waarvan iedereen de handtekening met standaardtools kan verifiëren. De tijdstempel kan achteraf niet worden vervalst zonder de handtekeningketen ongeldig te maken.
Een hashvastlegging. Voordat het document een tijdstempel krijgt, wordt de inhoud gehasht. SealDoc berekent zowel een SHA-256-digest, waaraan het RFC 3161-verzoek de Time Stamping Authority bindt, als een SHA-384-digest, die het record in het bewijsledger identificeert. De hash is een vingerafdruk van de inhoud. Verandert er één byte van het document nadat de hash is berekend, dan klopt de vingerafdruk niet meer. De hash wordt los van het document opgeslagen, zodat document en vingerafdruk op elk moment in de toekomst tegen elkaar kunnen worden gecontroleerd.
Een chain-of-custody-registratie. Elke handeling op het document na het aanmaken wordt gelogd (toegang, conversie, archivering, opvraging), met de identiteit van de actor, de tijdstempel en het IP-adres, en weggeschreven naar een manipulatiebestendig auditlog.
Samen beantwoorden deze drie elementen de vragen die juridische procedures stellen: bestond dit document op dit moment in deze vorm, is het sindsdien gewijzigd, en wie heeft het behandeld?
De praktische vraag
De vraag doet er het meest toe in deze omstandigheden: gereguleerde sectoren, transacties met een hoge waarde, lange bewaartermijnen, betwiste facturen, of elke situatie waarin een tegenpartij er belang bij kan hebben de integriteit van je administratie aan te vechten.
Voor die toepassingen is het gat tussen “we hebben de factuur” en “we kunnen bewijzen dat de factuur authentiek is” reëel, en formaatconformiteit alleen dicht het niet.
De meest praktische aanpak is de bewijslaag in te bouwen op het moment dat het document wordt gemaakt, en niet achteraf. Een RFC 3161-tijdstempel en hashketen die bij het genereren worden toegevoegd, kosten bij de audit niets. Ze achteraf toevoegen, of proberen te betogen dat bestaande vastleggingen zonder ze volstaan, is lastiger.
SealDoc voegt de bewijslaag toe aan elk document dat door de pijplijn gaat: een RFC 3161-tijdstempel die standaard wordt aangevraagd bij een onafhankelijke Time Stamping Authority in de EU, een SHA-256-chain of custody over de verwerkingsstappen, een SHA-384-bewijsledger over het record, en op verzoek een Legal Evidence Pack dat beide bundelt in één auditeerbaar archief.