Softwarepakketten.nl
Exact Software

Onderzoek

Elektronisch factureren 2.0: met UBL, PEPPOL en voorstel voor retourberichten

Plaatsingsdatum 28-04-2020
Berichtdatum 28 april 2020

Door Gerard Bottemanne, Onderzoeksbureau GBNED.

Dit onderwerp beoogt de aandachtspunten in beeld te brengen die massale adoptie van E-factureren in de weg (kunnen) staan en waar mogelijk oplossingsrichtingen aan te dragen. In het bijzonder komt de inzet van PEPPOL als verzendkanaal aan de orde en retourberichten om de status van een factuur kunnen volgen t/m de uiteindelijke betaling daarvan.

Allereerst even de betrokken organisaties die hierna genoemd (kunnen) worden:

  1. NMBF; forum belanghebbenden, onder regie van Ministerie van Binnenlandse Zaken.
  2. STPE; standaardisatieplatform E-factureren, onder regie van Ministerie van Economische Zaken.
  3. SI; simplerinvoicing; Nederlandse PEPPOL authority.
  4. Logius; ondersteuning en secretariaat E-factureren.

Onderstaand volgt telkens een korte toelichting, gevolgd door aandachtspunten en mogelijke oplossingsrichtingen.

1. Het factuurformaat
De overkoepelende factuurstandaard is UBL. Deze standaard is breed geaccepteerd door ALLE betrokkenen.
Er zijn echter een aantal UBL subsets in omloop, waarvan de meest recente in Nederland:
- EN16931; een EU subset die gebruikt wordt in meerdere Europese landen.
- NLCIUS; de Nederlandse implementatie van de EN16931 subset.
- SI UBL 2.0; de Nederlandse implementatie van de EN16931 subset, gebaseerd op PEPPOL.

Verwijzend naar onder meer de UBL Ketentest zijn op dit moment de volgende UBL subsets in gebruik. Met name onder aanbieders van uitgaande- en inkomende factuursoftware:
- UBL 2.0;
- UBL 2.1;
- SI 1.0, 1.1, 1.2 en 2.0;
- EN16931.

Aandachtspunten:

  1. Leveranciers van uitgaande- en inkomende factuursoftware hebben de afgelopen 5 jaar UBL ingebouwd, met name SI 1.2. Er is tot heden geen actie ingezet om betreffende leveranciers te bewegen SI 2.0 of NLCIUS in te bouwen. Lang niet alle Leveranciers van factuursoftware worden actief geïnformeerd. Om die reden zijn de meeste leveranciers blijven steken bij de eerdere versies. Met als resultaat dat er (te) veel versies van UBL in omloop zijn met alle uitdagingen van dien. Maar bijvoorbeeld ook de energiesector heeft een UBL-formaat dat (nog) niet is afgestemd op SI 2.0 of NLCIUS.
       
  2. In de praktijk is niet duidelijk wat vandaag de dag als UBL standaard ondersteund dient te worden. Wat is nu de standaard die we graag ondersteund zien door betreffende leveranciers. Is dat SI 2.0, NLCIUS, EN16931 en wat is precies het verschil tussen deze subsets? Het gros van betrokken softwareleveranciers is hiervan niet op de hoogte.

  3. Er is geen 100% overeenstemming dat SI 2.0 en NLCIUS niet (gaan) afwijken van elkaar. Behoudens de PEPPOL-adressering erg ongewenst. De NLCIUS wordt door STPE onderhouden en SI 2.0 door SimplerInvoicing. Positief is dat SimplerInvoicing ook is betrokken bij STPE.

Kortom:
Hoe gaan we zorgen voor één UBL standaard in Nederland die geïmplementeerd wordt door ALLE aanbieders van factuursoftware, zowel uitgaand- en inkomend? Zodat bijvoorbeeld 1-1-2022 maar één UBL versie in omloop is in Nederland.

Voorstellen:

  1. Vanuit STPE en SI komen tot één UBL versie (is al voor 99% het geval – dus dit mag geen probleem zijn). De standaard stabiel houden en geen wijzigingen doorvoeren als deze niet strikt noodzakelijk zijn. Wijzigingsvoorstellen altijd vooraf breed met de markt afstemmen. In elk geval alle wijzigingsvoorstellen, en doorgevoerde wijzigingen, breed delen met de markt. Zo krijgt het goede werk van beide organisaties meer aandacht, hetgeen de adoptie van elektronisch factureren ongetwijfeld ten goede zal komen.
      
  2. De betreffende UBL standaard uitdragen naar de markt (met name aanbieders van factuursoftware – uitgaand en inkomend) en de voortgang op implementatie monitoren.

2. Het verzendkanaal
Binnen het MKB is email de defacto standaard om facturen uit te wisselen, zowel in PDF als in UBL. Veel aanbieders van standaard boekhoudpakketten binnen het MKB faciliteren het versturen EN ontvangen van elektronische facturen (in UBL-formaat) via email. In de regel krijgt een afnemer van een boekhoudpakket een ‘eigen’ emailadres toegewezen om elektronische facturen te ontvangen. Betreffende facturen komen dan automatisch in het betreffende boekhoudpakket terecht, zonder handmatige handeling(en). PEPPOL wordt door betreffende leveranciers met name aangeboden via de diensten van een Billing Service Provider.

Binnen grote(re) organisaties lijkt de voorkeur duidelijk uit te gaan naar PEPPOL, met name met het oog op mogelijk fraude met facturen per email. De praktijk leert echter dat grote(re) organisaties nu nog overwegend zelf email inzetten om facturen in PDF te verzenden.

Binnen de overheid is PEPPOL het defacto kanaal om inkomende facturen in UBL te ontvangen en verwerken. Al dan niet als voorportaal van Digi-Inkoop. Als het gaat om uitgaande facturen is binnen de overheid (waaronder ook semi-overheid) email het meest gebruikte kanaal om facturen te verzenden.

Aandachtspunten:

  1. Op de website van SimplerInvoicing staat weliswaar een overzicht van softwareleveranciers die via SI facturen kunnen versturen. Dit is echter een fractie van in omloop zijnde factuursoftware en ook wordt geen onderscheid gemaakt naar factuursoftware en ondersteunende software door een BSP.
      
  2. Leveranciers van factuursoftware hebben de mogelijkheid om A) zelf aan te sluiten op PEPPOL of B) gebruik te maken van de diensten van een BSP. Er ontbreekt een vergelijkend overzicht van de mogelijkheden en bijvoorbeeld BSP’s onderling waarmee op PEPPOL aangesloten kan worden. Ook inzicht in kosten ontbreekt en dat is in de praktijk best een belangrijk element (met name in het MKB).
       
  3. Voor aansluiten op PEPPOL via een BSP ben je afhankelijk van de functionaliteit die betreffende BSP levert. Er is, voor zover ik kan nagaan, geen uniforme aansluitkit voor softwareleveranciers die voor alle BSP’s het zelfde is. Denk bijvoorbeeld aan het implementeren van PEPPOl-first.

  4. Er is volgens mij geen teststraat om een PEPPOL implementatie gratis uit te proberen door derden.
      
  5. Er wordt gesproken over ‘PEPPOL-First’. Allereerst zijn er een tweetal definities van PEPPOL-First, te weten:
    A) Automatisch facturen via PEPPOL versturen als de ontvanger is aangesloten op PEPPOL.
    B) Alleen signaleren dat de ontvanger is aangesloten op PEPPOL. De verzendkeuze altijd handmatig bepalen.
    Er is geen goed of fout tussen beide. Maar voor de communicatie wel goed om rekening mee te houden.
    Uniforme voorbeeldscripts om PEPPOL-First te implementeren zijn niet breed beschikbaar.
       
  6. Bij PEPPOL is zowel voor de afzender als ontvanger van een factuur sprake van een ‘On boarding’ proces. De vraag is of alle betrokkenen hier op dezelfde wijze mee omgaan. In het veld hoor ik hier tegenstrijdige verhalen over, echter zonder concrete onderbouwing. Een duidelijk uniforme beschrijving van de On Boarding procedure kan ik niet vinden (is er mogelijk wel).
      
  7. Verhuizen van het ene naar het andere access-point binnen PEPPOL, bijvoorbeeld door te switchen van boekhoudpakket. De vraag is nu hoe dit in de praktijk is geregeld. Moet je als gebruiker eerst opzeggen bij het oude access-point en dan pas aanmelden bij het nieuwe access-point. Hoe zorg je ervoor dat er geen berichten tussen de wal en het schip verdwijnen. Kunnen aanbieders van access-points dit onderling regelen.
    Kortom: hoe werkt het verhuizen van een access-point.
      
  8. Bij PEPPOL heb je uitgaande- en inkomende facturen. Hoe werkt de on boarding precies als je voor uitgaande- en inkomende facturen gebruik maakt van verschillende softwaresystemen? Stel er wordt gebruik gemaakt van een boekhoudpakket voor inkomende facturen via PEPPOL en van aparte factuursoftware voor uitgaande facturen via PEPPOL. Hoe wordt dit afgestemd qua access point binnen PEPPOL en waar kan dat dan het beste aangevraagd worden?
     
  9. Er is al jaren een vraag naar retourberichten via PEPPOL. Het gaat met name om een bericht aan de afzender dat een factuur daadwerkelijk is ontvangen in het administratiesysteem van de ontvanger. Dat retourberichten daarna de status van een factuur kunnen volgen t/m de uiteindelijke betaling behoeft geen betoog. 

Voorstellen:

  1. Een vergelijkend overzicht van ALLE BSP’s die een PEPPOL aansluiting faciliteren, zowel aan leveranciers van standaard software als direct aan eindgebruikers. Waarin ook de kosten (eenmalig en periodiek) meegenomen worden.
      
  2. Zorgen dat er ‘openbare standaard’ aansluitkits beschikbaar komen om aan te sluiten op PEPPOL via een BSP. Bestaande uit zaken als:
    - On boarding;
    - Versturen factuur via PEPPOL;
    - Ontvangen factuur via PEPPOL;
    - PEPPOL First;
    - Wisselen van BSP door een gebruiker;
    - Retourberichten.
       
  3. Zorgen voor een teststraat om PEPPOL implementaties te kunnen testen. Denk hierbij ook aan voorbeeld UBL-facturen met een geldig KVK-nummer, Bankrekening en BTW-nummer. Dan kunnen controles op geldigheid op deze zaken ook getest worden. Van groot belang is dat BSP’s met elkaar samen werken om dit te bereiken. Wellicht kan Logius hier een rol spelen vanuit de Overheid en als organisatie die is aangesloten op PEPPOL.
      
  4. Voorbeelden van PEPPOL-first beschrijven en live tonen (via YouTube?).
       
  5. Voorbeelden van On-boarding beschrijven en live tonen (via YouTube?).

  6. Retourberichten binnen PEPPOL ondersteunen door alle BSP’s (en direct aangesloten partijen op PEPPOL) op een en dezelfde manier. 

    Voorstel afhandelen retourberichten
    Vanuit Onderzoeksbureau GBNED is ook een eerste opzet gemaakt voor het afhandelen van retourberichten. Het gaat om een bericht aan de afzender dat een factuur daadwerkelijk is ontvangen in het administratiesysteem van de ontvanger. Maar ook retourberichten daarna die de status van een factuur kunnen volgen t/m de uiteindelijke betaling.
    Opvragen opzet "Elektronisch factureren 2.0: afhandelen retourberichten" (PDF).

3. e-factureren als basisvereiste in factuursoftware
Hoewel de Overheid in belangrijke mate gereed is om elektronische facturen te ontvangen en ruim 120 softwareleveranciers hebben deelgenomen aan de UBL Ketentest blijkt er nog een omvangrijke hoeveelheid factuursoftware in omloop die niet verder komt dan het versturen van een digitale factuur als PDF-bijlage bij een email. Dit zelfde geldt voor grote factuurverzenders, zoals telecombedrijven en hostingbedrijven. Deze laatste organisaties stellen ook facturen beschikbaar via een eigen platform, waarbij eerst ingelogd moet worden om vervolgens de factuur in PDF-formaat te kunnen downloaden. Dat laatste is buitengewoon omslachtig, zo is mijn persoonlijke ervaring.

Aandachtspunten:

  1. Lang niet alle leveranciers van standaard factuursoftware (boekhoud-, ERP en andere factuursoftware) ondersteunen elektronisch factureren op dit moment.
       
  2. Overheden en grote factuurverzenders ondersteunen uitgaand nauwelijks elektronisch factureren.

Voorstellen:

  1. Leveranciers van standaard factuursoftware die elektronisch factureren niet ondersteunen wijzen op het belang van elektronisch factureren en de wenselijkheid daarvan. Om dit kracht bij te zetten zou een (digitale) brief gestuurd kunnen worden vanuit de Ministeries van Economische- en Binnenlandse Zaken en de Belastingdienst.
       
  2. Via VNO/NCW, MKB Nederland, ZZP Nederland e.d. ondernemers oproepen om elektronisch factureren (uitgaand en inkomend) te omarmen. Vanuit de onder 1 genoemde betrokkenen.
       
  3. Via VNG en andere koepels binnen de (semi)overheid oproepen om elektronisch factureren (uitgaand en inkomend) te omarmen. Eveneens vanuit de onder 1 genoemde betrokkenen.

Aanvullend kan in beeld gebracht worden wie elektronisch factureren wel/niet ondersteund.

4. Definities e-factureren
Al een ruim aantal jaren gebruik ik zelf de volgende definitie voor elektronisch factureren:
"Het op elektronische wijze, in een afgesproken formaat, verzenden van facturen door een leverancier en het op elektronische wijze ontvangen en verwerken van facturen door een afnemer".

Het op elektronische wijze ontvangen en verwerken van facturen wordt ook wel "elektronische factuurverwerking" genoemd.

Een factuur in PDF-formaat is een digitale factuur, maar geen elektronische factuur omdat de elementen op een PDF-factuur, in tegenstelling tot een factuur in XML, niet direct herkend kunnen worden.

Aandachtspunt:

  1. Er blijkt geen eenduidige definitie van elektronisch factureren die door de betrokken partijen wordt gehanteerd.

    Tijdens het NMBF overleg van 16-4-2020 begreep ik dat de Belastingdienst het versturen van een digitale factuur als PDF-bijlage per email ook beschouwd als elektronische factuur.

    En tijdens het ‘Invoice of Holland’ initiatief van 17-4-2020 werd door eVerbinding gesteld dat het versturen van een UBL-factuur per email niet als elektronisch factureren wordt beschouwd.

Voorstel:

  1. Komen tot één definitie (vanuit het NMBF?) voor elektronisch factureren en in het verlengde daarvan voor elektronische factuurverwerking. Breed afgestemd en gedragen door de markt.

5. Out of the box
Elektronisch factureren is lang niet de enige ontwikkeling als het gaat om gegevensuitwisseling en administratieve software. Als andere ontwikkelingen kunnen genoemd worden PSD2, RGS, Auditfiles, API’s, RPA, Robotic accounting, E-herkenning en mogelijk Blockchain. Elektronisch factureren kan hierbij beschouwd worden als een van de onderdelen van Robotic accounting.

Mijn ‘out of the box’ gedachte is om na te gaan in hoeverre een of meer van deze ontwikkelingen en elektronisch factureren elkaar kunnen ondersteunen.

Voorbeelden:

  1. E-herkenning;
    E-herkenning is steeds meer in gebruik, waarbij niveau 3 de standaard is. De relatie tussen de aanvrager en het bedrijf wordt tijdens het aanvraagproces gecontroleerd aan de hand van de Kamer van Koophandel-registratie. Persoonsgegevens worden gecontroleerd door op locatie het originele identiteitsbewijs te tonen.

    Volgens mij heb je dan alle ingrediënten te pakken als het gaat om de on-boarding bij PEPPOL. Mogelijk valt op dat gebied iets te combineren of kan e-herkenning als middel dienen voor on-boarding bij PEPPOL. Het is nogmaals een idee dat verder onderzocht moet worden.
     
  2. RGS;
    RGS staat voor ReferentieGrootboekSchema en is een omvangrijk uniform (grootboek)rekeningschema dat als belangrijkste functie heeft rapportages vanuit de boekhouding te vereenvoudigen. Om na te gaan of RGS ook ingezet kan worden bij elektronisch factureren om factuurregels op de juiste rekening(en) te boeken is al in 2015 een eerste onderzoek gedaan (door GBNED) waarvan de resultaten hier zijn op te vragen.

Voorstel:

  1. Een initiatief starten (vanuit het NMBF?) om nader te onderzoeken met welke andere ontwikkelingen elektronisch factureren raakvlakken heeft. Op basis van het resultaat van dat onderzoek bepalen of het zinvol is daar meer aandacht aan te besteden, mede als doel de belangstelling voor elektronisch factureren te versterken.

Complete document
Een uitgebreide(re) weergave van bovenstaande is te vinden in het gelijknamige document "Elektronisch factureren 2.0: aandachtspunten en oplossingsrichtingen" (PDF). 

Tot slot is alle input welkom die van meerwaarde is voor dit document en mede ondersteunend is aan de massale adoptie van elektronisch factureren. Voor meer informatie en/of een reactie kan contact opgenomen worden met: 

Onderzoeksbureau GBNED
Gerard Bottemanne
Email gerard@gbned.nl 

Categorie(n) Soort > (Elektronisch) factureren, Standaardisatie, (open)standaarden, Branche > Accountantskantoren, UBL, Branche > Financials, XML en EDI
Bronvermelding Onderzoeksbureau GBNED
Internet URL http://www.ublketentest.nl

Automatisch op de hoogte blijven?
Schrijf u in voor onze gratis periodieke nieuwsbrief.

Terug

Gerelateerde berichten

Gids boekhoudsoftware 2020: alle standaard boekhoudsoftware en hun functionaliteit [02-06-2020]

RGS: uniform rekeningschema voor alle bedrijven [06-05-2020]

Gids RPA en robotic accounting [19-04-2020]

Terugblik en presentaties Praktijkdag Practice management 2020 [07-03-2020]

Digitaal dossierbeheer en auditfuncties voor de accountancy [03-03-2020]


Seminar RPA en robotic accounting

Najaar 2020
Seminar RPA en robotic accounting
Met ook gerelateerde ontwikkelingen, zoals: Artificial intelligence (AI), Elektronisch factureren, Purchase-2-Pay, PSD2, Blockchain en Chatbots.
Meer informatie en deelname...



AFAS Software


Visma Software


MUIS Software


RADAR Software


Tecknow



Onerzoeksbureau GBNED