Softwarepakketten.nl

Onderzoek

De geschiedenis van Digipoort/OTP vanaf 2001 tot heden, mede in relatie tot XBRL

Plaatsingsdatum 15-12-2015
Berichtdatum Juli 2017 (bijgewerkte versie)

(bijgewerkt juli 2017)

De overheid streeft al lange tijd naar administratieve lastenvermindering voor het bedrijfsleven. XBRL en Digipoort/OTP (Overheidstransactiepoort) worden vaak in één adem genoemd als middel om deze lastenvermindering te bereiken. Over XBRL is de afgelopen periode veel geschreven en kan het beste omschreven worden als:

"XBRL (eXtensible Business Reporting Language) is een op XML (eXtensible Markup Language) gebaseerde standaard en is uitermate geschikt voor financiele verslaggeving, in het bijzonder via internet. De essentie van het XBRL-formaat is de eenmalige identificatie van elk gegevenselement (zoals b.v. "Eigen vermogen") in een soort woordenboek, taxonomie genaamd. Alle gegevenselementen worden op een gestructureerde wijze geordend en kunnen dan automatisch herkend, verwerkt en op verschillende manieren voorgesteld worden al naargelang het gebruik dat ervan moet worden gemaakt (b.v. als jaarrekening of winstaangifte)." Deze tekst is ontleend aan het rapport "De XBRL taxonomie voor gestandaardiseerde jaarrekeningen. Toelichtingsnota van de Balanscentrale van de Nationale Bank van Belgie".

OTP is bedoeld om de communicatie tussen ondernemers en overheid op een efficiente manier te laten verlopen. Dat kan gaan om een XBRL bericht, maar ook om bijvoorbeeld andere (XML) berichten.

De Digipoort/OTP geschiedenis

2001
OTP is bedoeld om op eenduidige wijze elektronisch te kunnen communiceren tussen ondernemers en overheid. Al menig minister en staatssecretaris heeft OTP al in zijn of haar portefeuille gehad. Het begon jaren geleden al met de term "elektronische heerendiensten". "Dit project is een samenwerkingsproject van Belastingdienst, CBS, LISV en EZ en heeft als doel om voor het bedrijfsleven de administratieve lasten, veroorzaakt door overheidsdiensten, te verminderen. LISV, CBS en Belastingdienst hebben een gezamenlijke oplossing ontwikkeld waarmee vanaf volgend voorjaar met een druk op de knop elektronisch opgeslagen gegevens, voor bijvoorbeeld belastingaangiftes of meldingen Sociale Verzekeringen, bij bedrijven kunnen worden geselecteerd en verzonden. De ontwikkeling van het gegevensmodel en specificaties is per 1 oktober 2001 gereed gekomen". Zo lezen we in het document "Elektronische Overheid Voortgangsrapportage 2001" op de website van het Ministerie van Binnenlandse zaken. Toen was van XBRL nog geen sprake en de ontwikkeling van OTP klaarblijkelijk al in volle gang. "Ik proef bij alle deelnemers een gevoel van urgentie", aldus een uitspraak van toenmalig minister Annemarie Jorritsma van Economische Zaken in hetzelfde verslag.

2003
"Het programma ICT en Administratieve Lasten- verlichting, kortweg ICTAL, werd in januari 2003 opgericht. ICTAL was een samenwerkingsverband tussen het bedrijfsleven en de overheid dat de opdracht had ICT-voorzieningen te ontwikkelen en in gebruik te nemen om de administratieve lasten en rompslomp bij het bedrijfsleven te verminderen.

2006
Per 1 april 2006 is het programma ICTAL afgerond en zijn de diverse producten en diensten overgedragen aan de beheer-organisatie van ICTU, GBO.Overheid.". Zo lezen we op de website e-overheid.nl. Op deze website staat ook: "De ontwikkeling van OTP was bij de afronding van het programma nog niet gereed; deze wordt binnen de GBO.Overheid voortgezet".

Na een tweetal mislukte pogingen om te komen tot één OTP wordt het stokje overgedragen aan GBO.Overheid. Op de website van GBO.Overheid lezen we: "GBO.Overheid past binnen het streven van de overheid de dienstverlening aan burgers en bedrijven te verbeteren. Continuiteit, betrouwbaarheid en integriteit van IT-voorzieningen zijn daarvoor eerste vereisten".

2007
Het XBRL NTP Project (Nederlands Taxonmie Project) ontwikkelt een eigen variant van de OTP onder de naam "Koppelvlakspecificaties". De ontwikkeling hiervan loopt parallel met de verdere ontwikkeling van het hiervoor genoemde OTP bij GBO.Overheid. Het XBRL NTP project van de ministeries van Financien en Justitie maken dus geen gebruik van de OTP die GBO.Overheid (dat resulteert onder het ministerie van Binnenlandse Zaken en Koninkrijksrelaties) in ontwikkeling heeft. Het XBRL NTP Project en GBO.Overheid werken in eerste instantie langs elkaar heen en softwareleveranciers weten ook niet meer waar ze aan toe zijn. "Financiele softwaremakers dupe XBRL soap", zo luidt de titel van een persbericht van Bedrijvenweb, d.d. 23 maart 2007. Uiteindelijk lijkt GBO.Overheid aan het kortste eind te trekken.

2008
Het XBRL NTP Project wordt ondergebracht bij GBO.Overheid en deze laatste organisatie moet zorgen voor het beheer van OTP. Eigenlijk het beheer van meerdere OTP's. Want de doelstelling om te komen tot één OTP is nog geen feit. Er blijken meerdere varianten in omloop. De variant van XBRL NTP wordt gevoerd onder de naam "OTP SOAP 2008" en als standaard gepromoot bij leveranciers van administratieve software om XBRL berichten uit te wisselen richting Belastingdienst, CBS en Kamer van Koophandel.  "Deze versie is 7 januari 2008 is productie gegaan", zo wordt bericht in de nieuwsbrief van GBO.Overheid van maart 2008. Aan het einde van dat bericht staat echter ook "Het is de wens om uiteindelijk te komen tot één integrale Overheidstransctiepoort".

Volgens de Belastingdienst wordt het huidige BAPI kanaal (waarmee nu elektronisch aangiftes richting belastingdienst worden verzonden en informatie daarover retour wordt ontvangen) in de toekomst vervangen door OTP. We kregen daartoe de volgende formele reactie van het Ministerie van Financien op 28 oktober 2008. "Er wordt planmatig op gekoerst dat de nieuwe OTP (overheidstransactiepoort) per 1 januari 2010 operationeel is. Mocht dat niet lukken, dan communiceert de Belastingdienst dat tijdig; daarbij geldt dat het moment van overgang op een ander kanaal door de Belastingdienst in ieder geval zeker een jaar van te voren zal worden aangekondigd, zodat er een ruime voorbereidingstijd is. De Belastingdienst wil voor de fiscale aangiftestroom naar een modern kanaal overgaan, daarbij aansluitend bij de GBO en E-overheid". 

De samenhang tussen XBRL en OTP is dat gegevensuitwisseling in XBRL met de overheid (op dit moment Belastingdienst, CBS en Kamer van Koophandel) via de OTP verloopt. Met de gegevensuitwisseling in XBRL zelf wil het echter ook nog niet vlotten.

2009
De nieuwsbrief GBO.Overheid van oktober 2009 meldt: "In januari 2010 is de nieuwe Overheidstransactiepoort klaar. De nieuwe OTP beschikt over een gemoderniseerd systeem met een uitwijkomgeving, de bandbreedte van de verbinding is uitgebreid en er is een nieuw koppelvlak voor postbussen (POP3) gerealiseerd. In November 2009 gaan overheden en bedrijven die al met de huidige Overheidstransactiepoort werken over naar de nieuwe Overheidstransactiepoort.

Dezelfde nieuwsbrief meldt dat op 11 januari 2010 de naam Overheidsheidtransactiepoort wordt gewijzigd in Digipoort. En GBO.Overheid gaat verder onder de naam Logius. Dat een naamswijziging ook geld kost hebben we het dan maar even niet over. De naam Digipoort wordt trouwens gebruikt als "paraplu" term voor meerdere methoden c.q. technieken om informatie met de overheid uit te wisselen. Welke methoden c.q. technieken binnen Digipoort waarvoor precies gebruikt worden is niet helder. Een duidelijke specificatie ontbreekt.

De overheid heeft in 2008 het voortouw genomen om elekronisch facturen vorm te geven als launching customer. Een prima initiatief dat gelijk al veel lof kreeg toebedeeld, vanuit zowel de software industrie als ondernemers. Het is de bedoeling dat ondernemers die elektronische factureren aan de overheid daarvoor gebruik kunnen maken van de Digipoort/OTP. De Digipoort/OTP blijkt echter nog niet geschikt om ok te dienen als communicatiepoort voor elektronische facturen en het is nu de bedoeling dat de Digipoort/OTP daarvoor vanaf 2010 gereed is.  

Wat betreft de gegevensuitwisseling in XBRL loopt het in 2009 ook nog steeds niet storm. De overheid spreekt plotseling niet meer van XBRL, maar van SBR (Standard Business Reporting). Een lichtpuntje is dat de banken (RABO, ABN en ING) hebben besloten om in 2010 kredietrapportages te ontvangen in XBRL. Maar dat loopt dan weer niet via de Digipoort/OTP, maar een eigen banken transactiepoort die nog ontwikkeld moet worden. 

2010
Even leek het erop dat de banken XBRL in 2010 vlot zouden trekken door hun kredietrapportages op te vragen in XBRL. Op 10 september 2009 deed de RABO bank een bericht uitgaan met o.a. de volgende tekst "Uw jaarcijfers in één elektronische rapportage, voor zowel bank als overheid. Vanaf april 2010 wordt dat de normaalste zaak van de wereld.". Die laatste uitspraak is niet waargemaakt en van een grote uitrol van SBR/XBRL bleek ook in 2010 geen sprake. Wat de banken wel bereikt hadden is dat zo'n beetje elke intermediair zich liet informeren over SBR/XBRL. Bijeenkomsten trokken telkenmale volle zalen.

Logius doet op 8 november 2010 een bericht uit met de volgende titel "Gebruik Standard Business Reporting stijgt snel". Het bericht meldt dat in de  maand oktober van 2010 het aantal rapportages dat via Standard Business Reporting is verzonden gestegen is tot circa 10.000. Even verderop in het bericht lezen we dat het echter gaat om meer dan 9.000 OB (BTW) aangiftes. We worden dus blij gemaakt met een dooie mus. Want laat nu juist de maand oktober niet alleen betrekking hebben om maandaangiftes, maar ook op kwartaalaangiftes voor de OB. We hebben het dan over meer dan 600.000 OB aangiftes, waarvan dus minder dan 10.000 via XBRL. Hoezo doorbraak?

Ondertussen wil het met de afstemming van de Digipoort koppelvlakspecificaties voor SBR/XBRL en elektronisch factureren ook niet echt vlotten. Er blijken in de praktijk verschillende Digipoort/OTP koppelvlakspecificaties te zijn ontstaan: voor SBR (onder de naam SOAP2008) en voor elektronisch factureren aan de overheid (onder de naam WUS). En de koppelvlakspecificaties die de banken gebruiken lopen inmiddels ook uit de pas. Hoezo "Open standaarden?".

2011
Dit artikel is begonnen met 2001. We kunnen dus inmiddels spreken van een 10-jarig jubileum als het gaat om de OTP/Digipoort ontwikkeling die nog niet ten einde lijkt. Reden voor een feestje, of valt er nog niet zoveel te vieren? In elk geval is nog steeds niet helder welke methoden c.q. technieken binnen Digipoort nu precies waarvoor gebruikt worden. In elk geval lopen de aansluitingen voor SBR en Elektronisch factureren nog steeds uiteen.

2012...2013.....
Softwareleveranciers die de hiervoor Digipoort/OTP koppelvlakspecificaties SOAP2008 hebben ingebouwd voor SBR worden verzocht gebruik te maken van het hiervoor genoemde koppelvlak WUS. Op zich is dit goed nieuws: Zowel SBR-berichten (met name de aangiftes aan de Belastingdienst) als elektronisch factureren aan de overheid maken dan beiden gebruik van dezelfde Digipoort koppeling, te weten WUS. Maar waarom nu pas als SOAP2008 inmiddels door een groot deel van leveranciers van onder andere boekhoudsoftware is ingebouwd? Betekent toch weer extra werk voor deze leveranciers. Mogelijk zijn de aanpassingen niet erg groot, maar het betekent toch weer testen en opnieuw uitleveren van software bij klanten als de softwareleverancier zijn software nog nog als SAAS (Software as a Service) model via de cloud aanbiedt. En de overheid maar stug blijven volhouden dat SBR zorgt voor lastenvermindering. 

2014
Inmiddels lijkt UBL als standaard door te breken om elektronisch facturen uit te wisselen. Zowel door bedrijven onderling (B2B) als door bedrijven aan de overheid (B2G). Maar is echt sprake van één standaard. Internationaal gezien is al enkele jaren sprake van UBL2.0 en inmiddels UBL2.1. Het verschil tussen 2.0 en 2.1 is trouwens miniem. De overheid heeft in haar wijsheid besloten om UBL-OHNL te definiëren. Sinds 16 oktober 2014 is het niet meer mogelijk om middels het SOAP 2008 koppelvlak (zie hiervoor) aan te leveren aan de Belastingdienst voor SBR. Organisaties dienen dan overgestapt te zijn op het koppelvlak WUS voor bedrijven. Dit laatste geldt dan voor SBR en elektronisch factureren op basis van UBL-OHNL. Leveraniciers van boekhoudsoftware ondersteunen inmiddels UBL (2.0 of 2.1), maar zeker niet UBL-OHNL. Elektronisch factureren aan de overheid via boekhoudpakketten en een directe koppeling met Digipoort is dan ook niet mogelijk (een enkele uitzondering daargelaten). En dat terwijl deze boekhoudpakketten wel Digipoort ondersteunen voor bijvoorbeeld de BTW-aangiftes.

2015
Eind 2015 blijkt uit de UBL Ketentest dat ruim 50 boekhoud- en aanverwante (MKB) software de elektronische factuur standaard UBL ondersteunen. Het gaat dan om de standaard UBL 2.0 of 2.1. Ondersteuning van de afwijkende implementatie UBL-OHNL van de Nederlandse overheid is echter niet gegroeid. Het lijkt dus logisch dat via Digipoort facturen ook via UBL 2.0 of 2.1 aangeleverd kunnen worden aan de overheid. Maar we hebben het over de overheid en ICT en dat betekent dat via Digipoort vooralsnog UBL 2.0 en 2.1 niet wordt ondersteund. Onze vraag over dit laatste luidde tot de volgende formele reactie vanuit Logius (de beheerorganisatie van Digipoort) op 8-12-2015:

"Voor het uitwisselen van inkoop- en factuurberichten (waaronder de e-factuur) is er een Nederlandse overheidsstandaard opgesteld die is gebaseerd op UBL (goederen en diensten) en HRXML/SETU (externe inhuur). Berichten die voldoen aan de specificaties van deze overheidsstandaarden kunnen worden uitgewisseld over de Digipoort. Andere standaarden die vanuit de markt zijn opgesteld zoals de UBL-SI worden niet ondersteund in de Digipoort.

Vanuit de opdrachtgevers voor e-facturatie (ministerie van Binnenlandse Zaken en Economische Zaken) is recent het besluit genomen om e-facturatie verder te stimuleren binnen Nederland en niet te wachten op de richtlijnen vanuit de Europese Commissie rondom e-facturatie die vanaf 2018 van kracht moeten worden. Logius zal met haar opdrachtgevers bepalen welke activiteiten uitgevoerd moeten worden om het gebruik van e-facturen te vergroten. Hierbij zullen relevante ontwikkelingen met betrekking tot de gebruikte berichtstandaarden meegenomen worden". 

(Toelichting: UBL-SI is een 100% subset, gebaseerd op UBL 2.0 en 2.1).

De overheid heeft het over meenemen van relevante berichtstandaarden in bovenstaande toelichting, maar hebben zich daar heel 2015 verder niets van aangetrokken in relatie tot Digipoort.   

Een vraag die wij hebben voor 2016 is de volgende: "hoe kan een MKB-ondernemer eenvoudig via zijn of haar boekhoudsoftware (die UBL 2.0/2.1 ondersteunt) elektronisch een factuur doen toekomen aan de Nederlandse overheid. Zonder dat hier extra handelingen en kosten mee gemoeid zijn?".

2017
Op 29 juni 2017 is door KING (Kwaliteits Instituut Nederlandse Gemeenten) het rapport "VERKENNING IMPACT E-FACTUREREN" uitgebracht. In dit rapport staat letterlijk "De Rijksoverheid ontvangt e-facturen via Digipoort. Voor gemeenten raden zowel Logius als KING deze oplossing af vanwege de complexiteit van het implementeren van de oplossing en de relatief hogere kosten die hiermee gepaard gaan".

Dus de overheid verplicht vele softwareleveranciers aan te sluiten op Digipoort, terwijl die zelfde overheid (Logius) gemeenten afraad om aan te sluiten op Digipoort. Wij zijn het spoor na 17 jaar volledig kwijt.

Categorie(n) Branche > Accountantskantoren, Soort > EAI en Webservices, Soort > (Elektronisch) factureren, Standaardisatie, (open)standaarden, SBR / XBRL
Bronvermelding Onderzoeksbureau GBNED

Terug

Gerelateerde berichten

ICT Accountancy softwaregids 2018: overzicht van standaard software van meer dan 100 leveranciers gericht op de accountancy [30-10-2017]

ICT Accountancy award 2017: de meest innovatieve software gericht op de accountancybranche [25-10-2017]

Presentaties beschikbaar van praktijkdag: scannen, herkennen, elektronische factuurverwerking en robotic accounting 2017 [14-09-2017]

Scannen en herkennen van boekingsdocumenten en elektronische factuurverwerking op basis van robotic accounting [12-09-2017]

RGS: Uniform rekeningschema voor alle bedrijven [10-09-2017]


13 december 2017
Seminar: elektronisch factureren in de praktijk
Aan de orde komt: overview elektronisch factureren, Europese standaard EN 16931, SCOBDO.eu: automatische conversie, elektronisch factureren en de originele factuur, elektronisch factureren en de overheid, elektronisch factureren internationaal met o.a. VAT compliance verplichtingen, PEPPOL netwerk, elektronisch factureren in de praktijk, robotic accounting en machine learning en elektronisch factureren en factuurscenario's.
Meer info en aanmelden...


CreAim

Informer software

KING

Timewriter

MUIS Software


Onerzoeksbureau GBNED