Opinie 28 mei 2019

Oplossing zoekt probleem!

Recent was ik te gast op het SBR Symposium. Omdat ik tegenwoordig werk bij een club die software levert waarmee XBRL jaarrekeningen worden gemaakt, moesten we daar natuurlijk bij zijn. Mijn afdronk: er bestaat dus toch een parallel universum. En ik heb er een dagje in door mogen brengen.

Een auditorium vol met mensen uit de verschillende SBR-gremia, die door de bank genomen wel raad weten met een taxonomie, entrypoint of tuple. Goed om te zien dat er veel animo was, maar helaas was niet iedereen vertegenwoordigd. Grote afwezigen: ondernemers (voor wie het we 'het' allemaal doen). En zelfreflectie.

De sprekers kwamen uit alle hoeken en gaten en hadden allemaal wel een goed verhaal. Een rode draad kon ik er niet echt in ontdekken, maar ik kreeg toch het idee dat het om twee thema's ging (of had moeten gaan). Omdat die frequent terug kwamen, wil ik ze u niet onthouden.

Het eerste thema was de oproep om een ontwikkeling 'van document-uitwisseling naar data-uitwisseling' in te zetten. Met als achterliggende gedachte dat je dan op het niveau van transacties assurance zou kunnen gaan geven. Een theoretisch concept dat goed klinkt, maar waarvan de marktbehoefte volgens mij nog niet is vastgesteld. En in de context van SBR: ik gok dat bij zo'n 95 procent of meer van de SBR berichten nu helemaal geen assurance wordt gegeven. Laat staan op transactieniveau. Kennelijk vindt de markt dat prima, dus waarom zouden we daar iets aan veranderen?

Wat me aan dit thema overigens met name opviel was het 'frame' van document naar data. Alsof de huidige SBR-documentenstroom niet ook gewoon data is. Je kunt vinden dat de frequentie niet hoog genoeg is of dat je meer detail wilt, maar het is wel gewoon data. Dat de uitvragende partijen van die data geen soep kunnen koken is volgens mij geen reden om ondernemers en hun accountants te gaan belasten met weer nieuwe data-uitwisseling.

En dat brengt me bij het tweede thema dat continu terug kwam: 'data delen'. Nou word ik altijd wat argwanend als volwassenen met (soms) een commercieel belang het gaan hebben over delen. Zeker als ze vinden dat anderen iets moeten delen. De toegevoegde waarde voor het bedrijfsleven dat de data dan zou moeten gaan delen, werd mij niet duidelijk. Laat staan dat SBR hier een rol in zou moeten spelen.

Ik spreek met regelmaat accountantskantoren van allerlei pluimage. Als we het al over SBR of XBRL hebben, staan deze twee thema's niet op de agenda. Persoonlijk zou ik dat voorlopig ook zo willen houden. Toch werd ons de vraag gesteld wat SBR moest gaan bieden 'na de jaarrekening'. Met als suggesties: verbreden of verdiepen. De derde voor de hand liggende mogelijkheid, consolideren en voorlopig even niks doen, was kennelijk geen optie.

Ik gaf al aan dat zelfreflectie op deze dag niet prominent aanwezig was. Daar is echter reden genoeg voor. Na bijna twee decennia is het ons gelukt om op jaarbasis 42 miljoen SBR-berichten te versturen aan met name de overheid (vooral belastingaangiftes). Dat klinkt indrukwekkend, maar gezien de energie die erin gestopt is stelt het weinig voor. Sterker nog, ik schat in dat er in een beetje drukke week van een btw-maand net zoveel berichten tussen verschillende financiële systemen heen en weer worden geschoten. Allemaal via de API-netwerken van softwareleveranciers. En daar komt geen SBR aan te pas. Dan gaat het om facturen, banktransacties, of zelfs hele administraties. Allemaal met een duidelijk doel en een goede businesscase. Bij mijn weten had geen van die datastromen vijftien jaar nodig om tot wasdom te komen.

Een grondige evaluatie van de publiek-private samenwerking die SBR heet en de bereikte resultaten lijkt me dus op zijn plaats. Kritische vragen moeten gesteld worden en de NBA zou daar wat mij betreft een rol in moeten spelen. Vragen zoals:

• Waar is de administratieve lastenverlichting terecht gekomen en wie heeft daarvoor betaald?
• Lopen we nog wel in de pas met Europese ontwikkelingen? En dan bedoel ik niet of we ook XBRL 'doen', maar ook hoe we het doen. Zijn we het beste jongetje van de klas? Het slechtste? Of misschien wel het vreemdste jongetje van de klas?
• Is een standaard van twintig jaar oud nog steeds de juiste weg? Met de kennis van nu hadden we de KvK gewoon een goede OCR-oplossing moeten geven en wat natural language processing kennis. Ik schat dat er binnen zes maanden iets had gestaan waarmee pdf's omgezet konden worden naar gestructureerde data. Hadden we gewoon jaarrekeningen in pdf kunnen blijven sturen.

Overigens hoor ik de argumenten al komen: "Die accountants willen niet veranderen en daarom duurt het allemaal zo lang." Dat is wat mij betreft te makkelijk en ook maar ten dele waar. Als de business case er was geweest, had de sector de adoptie veel sneller georganiseerd.

U begrijpt dat ik wat sceptisch ben. Zal wel het gevolg zijn van mijn jarenlange ervaring als accountant. Het lijkt me echter dat we als accountants dit soort ontwikkelingen in het belang van onze klanten kritisch moeten blijven volgen. Ik hoop op een constructieve discussie.