Onder "Exit strategie" verstaan we het beëindigen van actief gebruik van boekhoudsoftware. In die zin dat er in elk geval geen mutaties door gebruikers meer plaatsvinden in toekomstige periodes vanaf een overeengekomen datum. Dat laatste aan te duiden als “exit datum”. Als voorbeeld hanteren we "1-1-2022" als exit datum in dit rapport. Maar deze exit datum kan natuurlijk ook midden in een (boek)jaar liggen.
Gebruikers Bij de exit strategie wordt meestal direct gedacht aan het beëindigen van een overeenkomst bij een leverancier van boekhoudsoftware door de gebruiker van deze software. Bijvoorbeeld een kantoor dat voor haar eigen administratie en/of voor de administratie van haar klanten gebruik maakt van betreffende software en dat wil beëindigen.
Dat de exit strategie echter een breder speelveld van betrokkenen kent duiden we aan via onderstaande situaties:
- Een kantoor dat voor haar eigen administratie en/of voor de administratie van haar klanten gebruik maakt van betreffende software en dat beëindigt.
- We richten ons hier primair even op het beëindigen van boekhoudsoftware voor klanten (ZZP en klein MKB).
- Een klant van een kantoor die overstapt naar een ander kantoor of de administratie in eigen beheer gaat voeren.
- Een klant van een kantoor die, al dan niet gedwongen, haar bedrijfsactiviteiten beëindigt.
- Een kantoor dat, al dan niet gedwongen, zelf haar bedrijfsactiviteiten beëindigt.
- Een softwareleverancier die zelf, al dan niet gedwongen, stopt met het voeren van de in gebruik zijnde boekhoudsoftware of zelfs helemaal ophoudt te bestaan.
Bovenstaande is een niet limitatieve opsomming, die duidelijk maakt dat er meerdere partijen en situaties mogelijk zijn aangaande een “exit strategie”.
Exit mogelijkheden
- Bij een geautomatiseerd boekhoudsysteem (lokaal of online) en alle boekingsdocumenten op papier in ordners kun je besluiten de administratie zelf volledig op papier af te drukken. Zeg maar vanaf basisgegevens en journaal t/m balans en resultatenrekening. Iets wat tientallen jaren meer regel dan uitzondering was en misschien nog wel is bij de nodige gebruikers. Speciaal voor de Belastingdienst kan dan eerst nog even een auditfile per boekjaar digitaal aangemaakt en opgeslagen worden.
Bij een geautomatiseerd boekhoudsysteem is een puntje van aandacht dat het boekhoudsysteem nog wel even actief blijft voor de gebruiker. Uitgaande van de genoemde exit datum van 1-1-2022 zal de administratie van 2021 nog afgerond moeten worden in (het eerste kwartaal van) 2022.
- In combinatie met een geautomatiseerd boekhoudsystemen (lokaal of online) wordt tegenwoordig steeds meer gebruik gemaakt van digitale boekingsdocumenten (met name in PDF, maar ook XML (zoals UBL-facturen) wordt steeds meer gebruikt. Betreffende digitale boekingsdocumenten kunnen dan ook beschouwd worden als de originele boekingsdocumenten. Dergelijke boekingsdocumenten zijn vaak gekoppeld aan de betreffende transacties en kunnen van daaruit ook geraadpleegd worden. Een steeds meer voorkomende exit mogelijkheid is dat raadplegen gedurende een aantal jaren dan nog mogelijk blijft in het boekhoudsysteem.
- Als overgestapt wordt naar een ander boekhoudpakket is een exit mogelijkheid om de bestaande administratie(s) te converteren van het huidige naar het nieuwe boekhoudpakket. Al dan niet in combinatie met de hiervoor genoemde mogelijkheden.
Voorwaarde is dan wel dat er geen relevante gegevens verloren gaan tijdens de conversie.
Bewaartermijn Zonder uitgebreid in detail te treden (zie thema bewaarplicht op onze website) moet een administratie in de regel 7 jaar bewaard worden, het gaat dan zowel om gegevens op papier als digitaal. Uitgaande van de eerder genoemde exit datum van “1-1-2022” moet een administratie dus bewaard worden over de jaren “2015 t/m 2021”. Gemakshalve stellen we gehanteerde boekjaren gelijk aan kalenderjaren.
Kosten Hiervoor zijn enkele mogelijkheden genoemd om administratiegegevens te bewaren. Administratiegegevens volledig afdrukken op papier kent printerkosten en is arbeidsintensief (en geeft dus personeelskosten) als het gaat om tientallen of meer administraties. Deze oplossing lijkt ons voor de meeste kantoren ongeschikt. Een beter alternatief is dan al om de gegevens “digitaal” te printen en bijvoorbeeld op te slaan in PDF. Dat scheelt in elk geval printerkosten, maar blijft arbeidsintensief.
Gegevens over voorbije periodes kunnen raadplegen (en dus niet meer muteren na een bepaalde periode) is in de praktijk variërend qua kosten. De ene leverancier biedt dit gratis aan als onderdeel van de exit-strategie en de andere leverancier vraagt een bedrag per administratie, per periode. Stel dat een leverancier een bedrag van € 10 per administratie per jaar vraagt, dan hebben we het over € 70 gedurende de 7 jaren waarvoor de fiscale bewaarplicht geldt. Een kantoor heeft al snel een paar honderd administraties. Bij 200 administraties hebben we het dan al over een totaalbedrag van € 14.000 euro, uitgaande van de genoemde 7 jaar.
Voorgestelde oplossingsvariant GBNED
Naast eerder genoemde varianten hebben wij het volgende voorstel als het gaat om: de exit strategie en bewaarplicht van een geautomatiseerde boekhouding met digitaal opgeslagen boekingsdocumenten, gericht op ZZP en klein MKB.
Uitgangspunt hierbij zijn de volgende 3 onderdelen:
- De boekhouding opgeslagen in het formaat van de Auditfile Financieel (XAF);
- Archief met digitale boekingsdocumenten;
- RGS als standaard Rekeningschema.
Ad. 1 De boekhouding opgeslagen in het XAF-formaat De XAF bestaat inmiddels vele jaren en wordt door meer dan 90% van boekhoudsoftware voor ZZP en klein MKB ondersteund. De Belastingdienst maakt gebruik van de huidige XAF voor het geautomatiseerd controleren van (financiële) administratie en de XAF wordt ingezet als export- en importformaat tussen boekhoud-, rapportage- en analysesoftware.
Tijdens het eerder genoemde onderzoek naar vendor lock-in en dataportabiliteit is wat betreft de XAF tegen het volgende aangelopen:
- Switchen van boekhoudpakket; de XML Auditfile Financieel (XAF) is niet genoeg uitgebreid en standaard voor een goede conversie van het ene naar het andere boekhoudpakket, inclusief de (boeking)historie over afgelopen boekjaren. Zie voor onderbouwing onder meer de volgende punten.
- Voldoen aan wettelijke bewaarplicht boekhouding; De XML Auditfile Financieel (XAF) wordt op dit moment niet geaccepteerd door de overheid, in casu de Belastingdienst, om te voldoen aan de wettelijke bewaarplicht van de geautomatiseerde boekhouding voor in elk geval ZZP en klein MKB.
- Het huidige XAF formaat dient strikter te zijn en uitgebreid te worden met ontbrekende boekhoudelementen. Zo kent de XAF (te)veel vrijheden als het gaat om het invullen van velden die eigenlijk verplicht moeten zijn en de XAF kent geen voorschriften voor de inhoud van bepaalde velden, zoals de soort boeking.
- Een adequate validatietool voor de XAF die validatie uitvoert (voor de technici: well formed XML, XSD-schema en schematron – business rules). Op die wijze kunnen leveranciers het genereren van hun XAF eerst testen, voordat deze uitgezet wordt in de markt. Met nu als gevolg dat de ene XAF de andere niet is qua indeling en ze niet goed gevalideerd kunnen worden.
Een oplossingsrichting voor de punten 3 en 4 kan gevonden worden, analoog aan de EU (16931) UBL-standaard voor elektronisch factureren. Deze handreiking is al eerder gedaan richting het XML Platform dat de coördinatie en ontwikkeling begeleid van de auditfiles.
- Hoewel 9 van de 10 boekhoudingen een vaste activa administratie kennen ontbreekt deze in de XAF. Geadviseerd wordt deze administratie op te nemen in de XAF, in elk geval conform de elementen die door de Belastingdienst uitgevraag worden bij de IB-winstaangifte. Denk hierbij ook aan elementen als: afschrijvingspercentage, restwaarde, afschrijvingsduur, datum afstoting en desinvestering.
De XAF heeft, met inbegrip van bovenstaande, de potentie om een significant deel van een oplossing te kunnen bieden aan exit strategie en bewaarplicht. Ook kan de XAF dan beter ingezet worden voor conversie van gegevens van het ene naar het andere boekhoudpakket.
Ad. 2 Archief met digitale boekingsdocumenten Tegenwoordig bestaat een geautomatiseerde boekhouding niet alleen meer uit rekeningen en transacties, maar ook uit digitaal opgeslagen boekingsdocumenten (brondocumenten, zoals inkoopfacturen, kassabonnen en benzinebonnen). Deze boekingsdocumenten behoren onlosmakelijk tot de boekhouding en vervangen papieren documenten in ordners. In een goed geautomatiseerd boekhoudsysteem is er ook een relatie gelegd tussen de brondocumenten en de boekingen c.q. transacties waarop deze documenten betrekking. Zo is het tegenwoordig usance om vanuit een openstaande post de bijbehorende in- of verkoopfactuur te kunnen raadplegen. Handig voor de ondernemer, maar zeker ook achteraf voor de accountant bij een controle. En ook komen steeds meer boekingen geautomatiseerd tot stand zonder menselijke handelingen c.q. tussenkomst. We hebben het dan over ‘Robotic accounting’. Denk aan inkoopfacturen die in UBL-formaat aangeboden worden en elektronische bankafschriften (in SEPA-formaat) die automatisch in de boekhouding terecht komen en geboekt worden. Of als voorloper het scannen en herkennen dat in elk geval zorgt dat alle (met name inkomende) boekingsdocumenten digitaal opgeslagen worden.
Het digitale archief met de oorspronkelijke boekingsdocumenten is de tweede schakel in de voorgestelde oplossingsvariant. Er moeten afspraken gemaakt worden hoe een dergelijk archief gekoppeld kan worden aan de transacties binnen de XAF en hoe dit archief dan beschikbaar gesteld gaat worden aan de gebruiker. Bij XML-documenten (zoals een elektronische factuur in UBL-formaat) is dan het leesbaar weergeven voor de gebruiker een aandachtspunt.
Hoe heeft u het bewaren van het digitaal archief met documenten nu geregeld? Welke afspraken heeft u gemaakt met uw leverancier van boekhoudsoftware over het beschikbaar stellen van digitaal opgeslagen (boekings-)documenten binnen uw administratie? Het gaat bijvoorbeeld om PDF, GIF en XML (UBL) formaten waarin deze bestanden opgeslagen zijn.
Ad. 3 RGS als standaard Rekeningschema RGS is de derde schakel binnen ons voorstel om te komen tot een marktbrede standaard voor het digitaal bewaren van administraties over afgelopen boekjaren (en eventueel boekingsperiodes).
RGS wordt in dit voorstel gezien als middel om de bewaarde gegevens meer transparant te maken voor betrokken partijen. De RGS-code moet dan altijd opgenomen zijn in de Auditfile financieel (XAF) per grootboekmutaties. Een alternatief is het opnemen van de RGS-code per grootboekrekening in de XAF, maar dan wordt geen rekening gehouden met het eventueel wijzigen van een RGS-code per grootboekrekening in de loop van de tijd.
Voorwaarde is dat:
- Het RGS-schema geaccepteerd én goedgekeurd is door betrokken organisaties als NBA, NOAB, Belastingdienst e.d.
- RGS-extensies ook als onderdeel van de RGS-code opgeslagen worden in de XAF.
- En in de XAF moet duidelijk zijn welke versie van het RGS-schema is gehanteerd per grootboekrekening.
Binnen operationele administraties moet RGS gekoppeld worden aan het grootboek. Een discussie kan zijn of dit ook nodig is voor oude boekjaren. En wat de consequenties van het gebruik van verschillende RGS-versies kan zijn binnen één administratie.
Resultaat Een XML Auditfile financieel (XAF), voorzien van RGS-codes en een relatie met een digitaal archief met corresponderende boekingsdocumenten. Een en ander als één geheel op te vragen (te downloaden) door de gebruiker vanuit boekhoudsoftware. Waarna de gebruiker e.e.a. kan opslaan op een zelf te kiezen (systeem)directory.
Meerdere boekjaren administraties Op dit moment kan de XAF vanuit boekhoudsoftware veelal per administratie, per boekjaar opgevraagd worden. Met name gericht op kantoren moet deze voorziening uitgebreid worden met de mogelijkheid om meerdere administratie, en daarbinnen meerdere boekjaren, in één keer te selecteren. Dat laatste betekent trouwens niet dat dan sprake moet zijn van één XAF met daarin opgeslagen alle administraties en boekjaren.
Het gaat niet om een voorziening om de complete wettelijke bewaarplicht te regelen. Daarvoor kunnen ook andere gegevens gelden, zoals contracten, koopovereenkomsten, al dan niet digitaal vastgelegd. Maar ook andersoortige administraties, zoals een webwinkel-, projecten- of urenadministratie.
Het gaat erom dat deel van de bewaarplicht te regelen dat betrekking heeft op hetgeen vastgelegd is binnen een geautomatiseerd boekhoudsysteem en daaraan gerelateerde digitale (boekings)documenten. Zodat de gebruiker (lees ook kantoor) niet meer gebonden is aan een geautomatiseerd boekhoudpakket om betreffende gegevens te kunnen raadplegen in het kader van de bewaarplicht. Een en ander mede in het kader van administratieve lastenvermindering voor uiteindelijk de ondernemer.
In tweede instantie kunnen leveranciers van boekhoudsoftware nagaan in hoeverre deze voorgestelde oplossingsvariant ondersteunend kan zijn voor conversie tussen boekhoudpakketten onderling.
Auditfile viewer In het verleden heeft de Belastingdienst de “Auditfile-viewer” op de markt gebracht, waarmee op een eenvoudige manier de inhoud van de XAF weergegeven kon worden. Het product “Auditfile-viewer” is zonder verdere toelichting van de markt gehaald. Nu wordt verwezen naar producten van commerciële aanbieders.
Wij willen de aanbeveling doen om wederom vanuit de Belastingdienst de “Auditfile-viewer” opnieuw aan de markt aan te bieden, maar dan conform de mogelijkheden van onze voorgestelde oplossingsvariant. Op die wijze hebben gebruikers, al dan niet op hun lokale computer, altijd op een leesbare wijze toegang tot opgeslagen administraties en kunnen desgewenst medewerkers van de Belastingdienst daar toegang toe bieden.
Digitale kluis per ondernemer Een interessant oplossingsalternatief is dat de gegevens (XAF en digitale boekingsdocumenten) online opgeslagen worden en via een “Auditfile-viewer” zijn op te vragen door de rechtmatige gebruiker (bijvoorbeeld geautoriseerd via een e-Herkenningsmiddel). De rechtmatige gebruiker kan dan bijvoorbeeld derden (Belastingdienst, Bank, etc.) autoriseren om betreffende gegevens (gedurende een bepaalde periode) op te vragen. De ondernemer beschikt dan over een eigen digitale kluis en is dus baas over zijn eigen online gegevens. De ondernemer bepaalt zelf met wie bepaalde gegevens gedeeld gaan worden en gedurende bijvoorbeeld welke periode.
Discussiepunten In dit voorstel zijn al een aantal discussiepunten impliciet genoemd. Expliciet noemen we nog:
- Het versleuteld opslaan van gegevens;
- Het verkennen of blockchain techniek kan bijdragen om de betrouwbaarheid van de opgeslagen gegevens te waarborgen, nu en in de toekomst.
- Een onafhankelijk centrale ‘online’ omgeving waar elke ondernemer zijn digitale kluis ter beschikking heeft en gegevens, op basis van autorisatie, kan delen met derden.
- En misschien wel het belangrijkste. Wie pakt het uitwerken van dit voorstel verder op?
Voor meer informatie en/of reacties op dit rapport kan contact opgenomen worden met: Onderzoeksbureau GBNED. |