Infrastructuur voor B2G e-factureren, een keuze-instrument voor kopers en verkopers

Infrastructuur voor B2G elektronisch factureren Keuze-instrument voor kopers en verkopers

Colofon

Datum 22 augustus 2008

Versie 1.0.1

Verandering —

Toegangsrechten Vertrouwelijk

Status Definitief

Redacteurs Paul Oude Luttighuis en Bob Hulsebosch

Auteurs Paul Oude Luttighuis, Ko Mies

Bob Hulsebosch en Jeroen van Beele

Bedrijven Telematica Instituut en Zenc

Dankwoord De opstellers van dit rapport hebben dankbaar gebruik gemaakt van de inzichten van de volgende personen, in alfabetische volgorde:

• Gert Abma, Daamen en Van Sluis Accountants • Wim Bakkeren, GBO.Overheid • Hans Dussel, Regiebureau Inkoop Overheid • Erwin Folmer, SETU • Friso de Jong, Platform ELFA • Joost Kuipers, Belastingdienst • Lex van Lent, Agroportal • Jorinde ter Mors, Gemeente Utrecht • Peter Potgieser, ABN Amro • Ed Rozenbeek, Gemeente Zoetermeer • Paul Schlotter, GBO.Overheid • Jos Verbraak, Gemeente Amsterdam • Sander Zwienink, Bureau Forum Standaardisatie

I n f r a s t r u c t u u r v o o r B 2 G e l e k t r o n i s c h f a c t u r e r e n V

Samenvatting1 Dit rapport wil bijdragen aan het verlagen van enkele herhaaldelijk geconstateerde obstakels voor grootschalige adoptie van elektronisch factureren, namelijk

• een gebrek aan bewustzijn bij kopers en verkopers van de mogelijkheden; • onbekendheid met weten regelgeving.

Het is opgesteld door Telematica Instituut en Zenc, in opdracht van het Ministerie van Econo-mische Zaken en in het kader van het Actieplan Elektronisch Factureren van dit Ministerie. De opstellers hebben daarvoor een reeks aan partijen geïnterviewd en documentatie bestudeerd. Kopers en verkopers vinden in dit rapport ondersteuning bij kiezen van een passende en wer-kende infrastructuur voor elektronisch factureren, die voldoet aan bestaande weten regel-geving. Het rapport beperkt zich tot:

• facturatie tussen bedrijven en overheidsorganisaties, hoewel veel materiaal ook van toepassing is op facturatie tussen bedrijven onderling en met consumenten;

• de op Nederland van toepassing zijnde weten regelgeving. De hoofdtekst beschrijft een keuze-instrument waarmee koper en verkoper stapsgewijs door een reeks aspecten van de infrastructuur worden geleid en worden ondersteund in het maken van keuzes ten aanzien van die aspecten. De aspecten zijn ondergebracht in vier groepen:

• de inrichting van de factuurketen, inclusief de eventuele rol van billing service providers en keuzes over het beleggen van archivering van elektronische facturen;

• de inrichting van het communicatieproces, inclusief een eventuele menselijke rol daarin, de keuze tussen brengen en halen en de gebruikte middelen voor de borging van authenticiteit van de verzender en de integriteit van de elektronische factuur;

• de inrichting van de communicatieketen, inclusief de eventuele rol van communicatie-dienstverleners, met bovendien bijzondere aandacht voor specifieke communicatie-dienstverleners in het overheidsdomein, de OTP, de NTP-infrastructuur en de OSB;

• keuzes op het gebied van (elektronische) factuurformaten, inclusief de keuze van het soort communicatie- en archiveringsformaat en keuzes betreffende formaatvalidatie en –transformatie.

Het keuze-instrument bevat voor de factuurketen een beknopte “outsourcing scorecard”, toe-gespitst op elektronisch factureren. Voor de andere drie onderdelen werkt het keuze-instru-ment met basisopties, waarvan in nader beschreven gevallen kan worden afgeweken. Een totaalpakket aan keuzes die kopers en verkopers op deze aspecten maken vormt een sce-nario. Een aantal bekende scenario’s uit bestaande documentatie wordt in dit rapport beschre-ven in termen van bovengenoemde aspecten. Twee fictieve casussen illustreren het gebruik van het instrument. Het rapport besluit met een aantal adviezen aan de opdrachtgever over:

• de in het kader van voornoemd actieplan voorziene pilots; • het wegnemen van enkele algemene obstakels voor grootschalige adoptie van

elektronisch factureren; • de mogelijke rol van de OTP en de NTP-infrastructuur, beide bestaande voorzieningen

voor elektronische communicatie tussen bedrijven en overheidsorganisaties.

1 Enkele sleuteltermen uit deze samenvatting worden toegelicht in Tabel 1 op pagina 4 van de hoofdtekst.

I n f r a s t r u c t u u r v o o r B 2 G e l e k t r o n i s c h f a c t u r e r e n V I I

Inhoudsopgave

1 Introductie 1 1.1 Elektronisch factureren 1 1.2 Het Actieplan Elektronisch Factureren 1 1.3 Doel en doelroep 2 1.4 Afbakening en definities 3 1.5 Documentatie 4 1.6 Gesprekken 5 1.7 Leeswijzer 5

2 Keuzeruimte 7 2.1 Vooraf 7

2.1.1 Waarom elektronisch factureren? 7 2.1.2 Waar beginnen met elektronisch factureren? 7 2.1.3 Het factuurproces 7 2.1.4 Klassieke facturatie of zelffacturatie 8 2.1.5 Archivering 8

2.2 Overzicht 9 2.3 Vraag 1 — Factuurketen 10

2.3.1 Vraag 1a — Verwerking van elektronische facturen 10 2.3.2 Vraag 1b — Archivering van elektronische facturen 12

2.4 Vraag 2 — Communicatieproces 13 2.4.1 Vraag 2a — Menselijke betrokkenheid 13 2.4.2 Vraag 2b — Initiatief 14 2.4.3 Vraag 2c — Authenticiteit en integriteit 14

2.4.3.1 Authenticiteit en integriteit d.m.v. “EDI” 15 2.4.3.2 Authenticiteit en integriteit d.m.v. de “geavanceerde elektronische handtekening” 16 2.4.3.3 Authenticiteit en integriteit d.m.v. “andere middelen” 16 2.4.3.4 De rol van de Belastingdienst 16

2.5 Vraag 3 — Communicatieketen 17 2.5.1 Vraag 3a — Hoofdvarianten 17 2.5.2 Vraag 3b — Roaming 18

2.6 Vraag 4 — Formaat 19 2.6.1 Vraag 4a — Communicatieformaat 19 2.6.2 Vraag 4b — Formaatvalidatie 20 2.6.3 Vraag 4c — Formaattransformatie 20 2.6.4 Vraag 4d — Archiveringsformaat 21

2.7 Typische scenario’s 21 2.7.1 Seller-direct, buyer-direct, consolidator, e-invoicing en een vijfde 21 2.7.2 Deense scenario’s 21

3 Hoe te kiezen? 25 3.1 Introductie 25 3.2 Wensen en eisen 25 3.3 Overzicht van het keuze-instrument 27 3.4 Basisopties en beperkingen 28

4 Keuze-instrument 31

V I I I I n f r a s t r u c t u u r v o o r B 2 G e l e k t r o n i s c h f a c t u r e r e n

4.1 Stap 1 — Factuurketen 31 4.1.1 Zelf doen of uitbesteden? 31 4.1.2 Stap 1a — Verwerking 32 4.1.3 Stap 1b — Archivering 33

4.2 Stap 2 — Communicatieproces 34 4.2.1 Stap 2a — Menselijke betrokkenheid 34 4.2.2 Stap 2b — Initiatief 35 4.2.3 Stap 2c — Authenticiteit en integriteit 35

4.2.3.1 Liefst de handtekening of “EDI” 35 4.2.3.2 Digid-Bedrijven 36

4.3 Stap 3 — Communicatieketen 36 4.3.1 Stap 3a — Hoofdvariant 36

4.3.1.1 De OTP en de NTP-infrastructuur 37 4.3.1.2 De OSB 38

4.3.2 Stap 3b — Roaming 39 4.4 Stap 4 — Formaat 39

4.4.1 Stap 4a — Communicatieformaat 39 4.4.2 Stap 4b — Formaatvalidatie 40 4.4.3 Stap 4c — Formaattransformatie 41 4.4.4 Stap 4d — Archiveringsformaat 41

4.5 Een lastig probleem: adressering en routering 42

5 Twee fictieve casussen 45 5.1 Gemeente Reggebroek en energiebedrijf Enessuo 45

5.1.1 Vraag 1: Factuurketen 46 5.1.2 Vraag 2: Communicatieproces 46 5.1.3 Vraag 3: Communicatieketen 47 5.1.4 Vraag 4: Formaat 47

5.2 Ministerie van Publieke Zaken en uitzendbureau MedeWerk 48 5.2.1 Vraag 1: Factuurketen 48 5.2.2 Vraag 2: Communicatieproces 49 5.2.3 Vraag 3: Communicatieketen 49 5.2.4 Vraag 4: Formaat 50

5.3 Overzicht 51

6 Adviezen 53 6.1 Ten aanzien van de pilots en de doorontwikkeling 53 6.2 Ten aanzien van algemene randvoorwaarden 53 6.3 Ten aanzien van de OTP, de NTP-infrastructuur en de OSB 54

Lijst van figuren 55

Lijst van tabellen 55

I n f r a s t r u c t u u r v o o r B 2 G e l e k t r o n i s c h f a c t u r e r e n 1

1 Introductie

1.1 Elektronisch factureren

Factureren is een zakelijke handeling die een sleutelrol vervult in commerciële processen. Met het voorleggen van een factuur verzoekt de verkoper de koper te betalen voor geleverde pro-ducten of diensten. Zo verbindt de factuur het leveringsproces met het betalingsproces. De precieze vorm van het factuurproces en die van het factuurdocument hangen af van allerlei factoren. Het factuurproces tussen bedrijven en consumenten ziet er vaak anders uit dan tus-sen bedrijven onderling2. Ook de aard van de geleverde producten en diensten heeft invloed. Soms is het de koper zelf ─ en niet de verkoper ─ die de factuur opstelt en “aan zichzelf” pre-senteert3. Dat gebeurt vooral als de koper zelf het eerst of het best weet wat er op de factuur moet staan. Juist vanwege de sleutelrol van facturatie en vanwege grote factuurvolumes ─ zowel in aantal-len documenten als bedragen ─ is er belangrijke winst te behalen met het vervangen van pa-pieren factuurverkeer door elektronisch factuurverkeer. Deze winst ligt vaak in operationele kostenbesparingen4 in de verwerking van facturen, in het voorkomen van fouten in facturen, in verbetering van het overzicht en inzicht in de status van facturen en in versnelling van de be-taling. Er bestaat al enige jaren een markt voor uiteenlopende oplossingen en dienstverlening op dit gebied. Schattingen stellen dat in 2007 in Nederland tussen de 2% en 3% van alle factu-ren geheel elektronisch worden voorgelegd, dat wil zeggen, zonder een parallelle papieren factuur5. Onder elektronisch factureren zullen we verstaan het door middel van een elektronisch kanaal voorleggen van facturen tussen verkoper en koper. Daarbij vatten we de factuur op in de zin van de Wet op de Omzetbelasting6. Daarmee vallen een aantal andere processen, die welis-waar op facturatie lijken, buiten ons aandachtsgebied. Denk daarbij bijvoorbeeld aan een be-schikking van een verkeersboete van het CJIB of een belastingaanslag van de Belastingdienst.

1.2 Het Actieplan Elektronisch Factureren

Zoals in vele landen, vertegenwoordigt in Nederland de overheid een zeer groot inkoopvolume en dus een zeer groot factuurvolume. Een recente schatting meldt ruim tien miljoen inkoop-facturen op jaarbasis, waarvan ongeveer de helft bij gemeenten en ruim drie miljoen bij grote uitvoeringsorganisaties7. Daarmee biedt het business-to-government factuurverkeer belangrijke kansen om door middel van elektronisch factureren flinke baten te realiseren, voor zowel over-heidsorganisaties als bedrijven die zaken doen met de overheid. Bovendien kan grootschalig elektronisch factureren naar de overheid ─ mits daarbij goede keuzes worden gemaakt ─ ook een flinke stimulans geven aan business-to-business elektronisch factureren. 2 Zozeer zelfs dat in het Engels een consumentenfactuur vaak met “bill” wordt aangeduid en een factuur tussen bedrijven met “invoice”. 3 Zogenaamde self-billing of zelf-facturatie. 4 De gemiddelde verwerkingskosten van papieren facturen worden geraamd op ongeveer acht euro en die van complexere facturen op enkele tientallen euro’s. Zeker bij grotere aantallen facturen herbergen deze bedragen een flinke besparingsbelofte bij automatisering van de factuurverwerking. 5 EBA en Innopay, E-invoicing 2008 ─ European market description and analysis, version 1.0, februari 2008. 6 Artikel 35. 7 J.P. Vendrig, J.J. Boog en H. de Bondt, Omvang (elektronische) facturen business-to-government (B2G), EIM, Zoetermeer, 30 mei 2008.

2 I n f r a s t r u c t u u r v o o r B 2 G e l e k t r o n i s c h f a c t u r e r e n

Daarom voert het Ministerie van Economische Zaken momenteel het actieplan Elektronisch Factureren uit. De overheid wil vanaf de zomer van 2008 het goede voorbeeld geven door als ontvanger van facturen bedrijven te stimuleren de factuur elektronisch te sturen. In 2010 moet de overheid zo 10% van de facturen in elektronische vorm ontvangen en verwerken. In het bijbehorende projectplan is een voorbereidende fase 1 opgenomen. In die fase wordt, in het voorjaar van 2008, gewerkt aan onder andere:

1. een beschrijving van de huidige stand van zaken in Nederland op het gebied van het gebruik van elektronisch factureren;

2. een strategie t.a.v. standaarden voor elektronisch factureren; 3. keuzes voor de infrastructuur voor elektronisch factureren; 4. een projectplan voor de vervolgfasen.

Deze eerste fase geldt als voorbereiding op een pilotfase, waarin specifieke combinaties van (inkopende) overheidsorganisaties en (verkopende) bedrijven elektronische facturatie elektronische facturatie zullen gaan beproeven.

1.3 Doel en doelroep

Het document dat voor u ligt, is het resultaat van de derde activiteit uit fase 1 van het actie-plan. Het Ministerie van Economische Zaken heeft aan Telematica Instituut en Zenc de op-dracht gegund varianten te formuleren voor de logistieke infrastructuur voor elektronisch factureren (tussen bedrijven en overheden) en aan te geven hoe verkopers en (overheids)ko-pers uit deze varianten kunnen kiezen. Met het keuze-instrument dat dit rapport biedt, bouwen koper en verkoper stapsgewijs zo’n variant op, door op een reeks van aspecten een weloverwogen keuze te maken. Het gezamen-lijke resultaat van al deze keuzes heet een scenario. Daarmee is de doelgroep van dit rapport niet allereerst de opdrachtgever (het Ministerie van Economische Zaken), maar de genoemde combinaties van kopers (bij de overheid) en verkopers (in het bedrijfsleven) die onderling elektronisch factureren willen invoeren. Het zij duidelijk dat kopers en verkopers weliswaar de belangrijkste, maar niet de enige belanghebbenden zijn in dit veld. Zo spelen ook dienstverleners van uiteenlopende aard ─ billing service providers, banken, shared services inkoop, et cetera ─ een belangrijke rol, net als softwareleveranciers. Bovendien speelt de overheid, naast die van inkopende partij, nog twee andere rollen, namelijk:

• als beleidsmaker op het gebied van elektronische handel en, in die hoedanigheid, houder van het genoemde actieplan;

• als handhaver van toepasselijke weten regelgeving, waarover dit rapport nog uitgebreid komt te spreken.


1.4 Afbakening en definities

Dit rapport kent een aantal belangrijke beperkingen van de scope. We noemden al: • Het bestrijkt alleen B2G-facturatie, waarbij dus de kopende partij een overheids-

organisatie is en de verkopende een bedrijf8. • Het bestrijkt alleen facturen in de zin van de Wet op de Omzetbelasting9.

Verder richt het document zich alleen op de kern van het factuurproces, namelijk de (elektro-nische) terbeschikkingstelling van de factuur aan de koper (Figuur 1). Dat wil zeggen dat moge-lijke andere delen van het facturatieproces niet aan de orde komen, zoals factuurcorrecties, debetnota’s, creditnota’s, verzamelfacturen, et cetera. En, de rest van het commerciële pro-ces (zoeken, onderhandelen, bestellen, leveren en betalen) valt buiten het blikveld. Dat laat onverlet dat elektronisch factureren vaak juist veel kansen biedt in het koppelen van het fac-tuurproces aan het bestelproces en het betaalproces. Zo kan een elektronische factuur voor de koper de mogelijkheid bieden om

• snel tot een vergelijkende controle met de bijbehorende bestelling te komen (reconciliatie)

• snel tot het in gang zetten van de bijbehorende betaling te komen.

COMMERCIËLE PROCESzoeken onderhandelen bestellen leveren factureren betalenfactureren

COMMERCIËLE PROCESzoeken onderhandelen bestellen leveren factureren betalenfactureren

Figuur 1 — Afbakening van het onderzoek.

Ook beperkt dit rapport zich tot de Nederlandse weten regelgeving op het gebied van elektronisch factureren, hoewel veel bedrijven internationaal zaken doen. Daarnaast zal het geen aandacht besteden aan confidentialiteit en privacy van elektronisch factureren, hoewel daartoe wel aanleiding kan zijn, zowel vanuit zakelijke overwegingen (commerciële vertrouwelijkheid) als vanuit maatschappelijke. Dat laatste speelt bijvoorbeeld als de factuur persoonsgegevens kan bevatten, zoals bij facturen voor uitzendkrachten. Er schuilt een gevaar in deze beperkingen, zeker omdat een infrastructuur meestal niet alleen voor elektronisch factureren wordt gebruikt, maar voor allerlei andere processen en informatieverkeer. Daarom is het goed als kopers en verkopers hun overwegingen over een infrastructuur voor elektronisch factureren steeds combineren met overwegingen over een infrastructuur voor andere, aanpalende doeleinden. Voor de duidelijkheid geven we in Tabel 1 definities van enkele veel gebruikte termen.

8 Niettemin kan veel van de inhoud van dit rapport ook voor B2B of zelfs B2C elektronisch factureren van toepassing kan zijn. 9 Dat betekent vooral dat we op facturen gelijkende documenten zoals boetebeschikkingen en belastingaanslagen niet beschouwen.


Tabel 1 ─ Definities

Term Betekenis

(Logistieke) Infrastructuur

Gezamenlijke partijen (factuurpartijen, BSP’s en CSP’s) en voorzie-ningen die nodig zijn om een factuurdocument elektronisch aan de ontvanger voor te leggen.

Scenario Pakket van keuzes die factuurpartijen kunnen maken over de verschillende aspecten van de logistieke infrastructuur waarover zij hun onderlinge elektronische factuurverkeer afhandelen.

Factuurpartij Koper of verkoper

Billing Service Provider (BSP)

Zakelijk dienstverlener op het gebied van inhoudelijke opstelling en/of verwerking van facturen; dit kan ook een rol van een bredere dienstverlener zijn, zoals een bank, een elektronisch markt of een inkoopdienstverlener. Een BSP is, namens zijn klant, verantwoordelijk voor de factuur en de factuuroverdracht.

Factuurschakel Factuurpartij of BSP

Communicatieschakel Communicatierelatie tussen twee opeenvolgende factuurschakels.

Communicatie Service Provider (CSP)

Dienstverlener die basiscommunicatiediensten verleent voor het elektronisch overdragen of presenteren van facturen; heeft geen bemoeienis met de inhoud van de factuur.

1.5 Documentatie

De volgende documenten zijn onder andere geraadpleegd tijdens het onderzoek: • Ronald Batenburg en Barbera van den Berg, e-Factureren en standaarden voor e-

invoicing in Nederland, Dialogic, maart 2008. • Belastingdienst, Brochure Elektronisch Factureren, november 2007.

http://download.belastingdienst.nl/belastingdienst/docs/elektronisch_factureren_ob2081z4fd.pdf • CEN/ISSS Workshop on Interoperability of Electronic Invoices in the European

Community, CEN Workshop Agreement 15574, juli 2006. ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eInvoicing/CWA15574_2006.pdf

• Ralf Cimander, eInvoicing in Denmark, eGovernment Good Practice Case, 31 januari 2007, http://www.epractice.eu/files/upload/gpc/document/1967-1170249373.pdf

• EIM, Omvang (elektronische) facturen Business-to-Government (B2G), mei 2008. • EBA en Innopay, E-invoicing 2008, version 1.0, februari 2008. • European Commission Informal Task Force on e-Invoicing, European Electronic Invoicing

(EEI), final report, EEI-3.2, juli 2007. http://ec.europa.eu/information_society/eeurope/i2010/docs/studies/eei-3.2-e-invoicing_final_report.pdf

• Innopay, Towards an inclusive e-invoicing network model, White paper, juni 2008. • PWC, E-facturatie: uitzicht door inzicht, presentatie, oktober 2007.

http://www.mediaplaza.nl/uploaded/FILES/seminars/2007/e-Facturatie%2022%20okt/Presentatie_efacturatie_v4_.pdf • PWC, Global (E-)Invoicing & (E-)Archiving, januari 2006. • UN/CEFACT/ITPWG/TBG15, Annex to Recommendation 6 (to accommodate e-Invoicing),

paragraaf 2.2, versie voor Public Review, 21 mei 2008. • Sander Zwienink en Peter Potgieser, Advies e-Factureren, versie 1, Forum

Standaardisatie, 20 maart 2007. http://www.forumstandaardisatie.nl/fileadmin/OVOS/CS_4apr07_doc04.3_eFactureren_Advies_1.0.pdf


Raadpleging van deze documentatie laat zien dat beschikbare documentatie op het gebied van elektronisch factureren flink uiteenloopt in de gehanteerde modellen, termen, oplossingen en hier en daar zelfs beweringen. Dit onderwerp zou erg kunnen profiteren van een meer eensluidend denkraam en terminologie.

1.6 Gesprekken

Met de volgende personen hebben we voor de totstandkoming van dit rapport mogen spreken. • Erwin Folmer, SETU, 11 juni. • Jos Verbraak, Gemeente Amsterdam, 11 juni. • Jorinde ter Mors, Gemeente Utrecht, 20 juni. • Gert Abma, Daamen en Van Sluis Accountants, 23 juni. • Lex van Lent, Agroportal, 25 juni. • Ed Rozenbeek, Gemeente Zoetermeer, 25 juni. • Friso de Jong, Platform ELFA, 30 juni. • Joost Kuipers, Belastingdienst, 1 juli.

Daarnaast heeft de bijwoning van twee bijeenkomsten bijgedragen aan de inhoud van dit rapport:

• Bijeenkomst van het Holland Financial Centre over e-invoicing, Utrecht, 23 juni. • CEN/ISSS eInvoicing Phase 2 Workshop Electronic Invoices & Compliance, Brussel,

19 juni.

1.7 Leeswijzer

Hoofdstuk Inhoud

1 Inleidend hoofdstuk

2 Overzicht van de keuzeruimte: waaraan moet u allemaal denken bij het inrichten van de infrastructuur voor elektronisch factureren? En wat zijn dan de keuzemo-gelijkheden? Welke typische scenario’s kan men tegenkomen?

3 Hoe te kiezen? Wensen en eisen voor elektronisch factureren. Overzicht van het keuze-instrument. Basisopties en beperkingen.

4 Het keuze-instrument: hoe stelt u zelf uw scenario samen voor de logistieke infrastructuur voor elektronisch factureren?

5 Voorbeelden: voor twee fictieve gevallen laten we zien hoe het keuze-instrument werkt.

6 Conclusies en adviezen aan de opdrachtgever.


2 Keuzeruimte

2.1 Vooraf

In deze paragraaf behandelen we een aantal beslispunten voor kopers en verkopers op het gebied van elektronisch facturen, die we niet in het rapport behandelen, omdat het rapport zich op infrastructuur richt.

2.1.1 Waarom elektronisch factureren?

Van een organisatie die dit rapport gebruikt, verwachten we dat zij de keuze heeft gemaakt om elektronisch te (gaan) factureren met één of meerdere van haar klanten, respectievelijk leveranciers. Daarvoor zal veelal een business case worden gemaakt. Dit rapport helpt niet bij het maken van deze keus of het maken van de business case, maar gaat ervan uit dat deze al gemaakt is.

2.1.2 Waar beginnen met elektronisch factureren?

Vaak kiest een kopende organisatie niet om ineens haar totale factuurverkeer elektronisch te maken, maar doet zij dat per inkoopcategorie of per leverancier. De business case voor elek-tronisch factureren kan daarbij steeds anders uitvallen. Sterker nog, het kan zijn dat voor ver-schillende inkoopcategorieën en/of leveranciers verschillende processen, oplossingen en infra-structuren worden gekozen. Dit rapport helpt niet bij het maken van de keus voor een zekere inkoopcategorie of voor zekere klanten of leveranciers om elektronisch mee te gaan facture-ren. Het verwacht dat deze keuze gemaakt is en helpt vervolgens bij het kiezen van infrastruc-tuur daarvoor. Dezelfde kopers of verkopers kunnen dus uiteindelijk meerdere scenario’s naast elkaar gaan gebruiken. Hoewel uit het oogpunt van schaalvoordelen maximaal hergebruik van infrastructu-ren wenselijk is, kunnen verschillende inkoopcategorieën of verschillende klanten of leveran-ciers zo verschillend zijn, dat ze specifieke infrastructuurkeuzes met zich meebrengen. Soms is die diversiteit uiteindelijk niet wenselijk, maar voorlopig het enig haalbare, gegeven reeds in-gerichte processen of systemen.

2.1.3 Het factuurproces

Er moet nogal wat geregeld worden voor elektronisch factureren, zeker als een organisatie momenteel gebruik maakt van een geheel papieren factuurproces. Een investering in elektro-nisch factureren zal voor veel organisaties gepaard gaan met een procesverandering. Misschien wordt het door die investering wel haalbaar om wekelijks te factureren in plaats van maande-lijks. Misschien ook kiest men ervoor om zelffacturatie in te voeren, of om de interne accorde-ring van inkomende of uitgaande facturen aan te passen. Keuzes voor de inrichting van het factuurproces zijn afhankelijk van allerlei specifieke omstandigheden, zoals:

• de aard van de gefactureerde producten of diensten (primaire goederen, primaire diensten, secundaire goederen, secundaire diensten)

• de onderliggende contractvorm (incidentele inkoop of mantelinkoop, vaste prijs of nacalculatie).


Omdat dit rapport helpt bij het maken van infrastructuurkeuzes, is het niet bedoeld als gids voor het aanpassen van het factuurproces zelf. Van organisaties die dit rapport gebruiken verwachten we echter wel dat ze proceskeuzes hebben gemaakt.

2.1.4 Klassieke facturatie of zelffacturatie

Eén proceskeuze is van bijzonder belang voor de infrastructuur, omdat het bepaalt in welke richting het factuurdocument stroomt bij de overdracht. In de klassieke situatie is het de ver-koper die het factuurdocument overdraagt aan de koper ─ al dan niet via allerlei tussenscha-kels. Soms echter is het handiger om de koper zelf de factuur op te laten stellen, vooral als deze eerder of beter dan de verkoper beschikt over de gegevens die in de factuur moeten worden opgenomen: zelffacturatie. Dat komt bijvoorbeeld voor in de uitzendmarkt. Uitzendkrachten die bij een inlener werken, maken daar vaak gebruik van de processen en systemen van de inlener. Typisch verantwoorden zij daarbij de door hen gewerkte uren in de systemen van de inlener. Deze gegevens zijn een wezenlijke informatiebron voor de factuur. Natuurlijk is het mogelijk om deze urenverant-woording (liefst elektronisch) naar de uitzendorganisatie te sturen, die daarmee vervolgens een factuur opmaakt. Maar sneller is het om de inlener zelf zijn factuur te laten opmaken. In dat geval wordt de verkoper nog wel op de hoogte gebracht van de “zelffactuur”, al is het maar om de daaropvolgende betaling te kunnen begrijpen.

private domein

overheids-domein

koper ver-koper

private domein

overheids-domein

koper ver-koper

private domein

overheids-domein

koper ver-koper

private domein

overheids-domein

koper ver-koper

Figuur 2 — Klassieke facturatie (boven) en zelffacturatie (onder) in het B2G-veld.

2.1.5 Archivering

Wet- en regelgeving stelt ook eisen aan de archivering van elektronische facturen. Archivering moet worden meegenomen in de inrichting van het factuurproces, bij zowel koper als verkoper10. In het algemeen geldt daarbij een bewaartermijn van zeven jaar. Archivering mag worden uitbesteed, maar de eindverantwoordelijkheid hiervoor blijft bij de factuurpartij. Ondersteuning bij zulke uitbestedingskeuzes wordt verderop in dit rapport geboden.

10 Voorzover zij BTW-plichtig zijn.


2.2 Overzicht

Als • de keuze voor elektronisch factureren is gemaakt, • het duidelijk is voor welke inkoopcategorie en met wie er elektronisch gefactureerd zal

worden en • het (nieuwe) factuurproces is gekozen

komt de inrichting van de infrastructuur aan de orde. Een belangrijke vraag die zich dan aandient is of er voor de uitvoering van het factuurproces gebruik gemaakt gaat worden van zakelijke dienstverleners die het opstellen of verwerken van facturen uit handen nemen van de factuurpartijen. Dat kunnen specifieke billing service provi-ders zijn (BSP’s), maar ook dienstverleners die dit als onderdeel van een groter dienstenpakket voeren, zoals banken, elektronische markten of inkoopdienstverleners. Het gaat hier om de in-richting van de factuurketen. Dit rapport zal houvast geven bij het maken van keuzes ten aan-zien van de factuurketen, die in feite in- of uitbestedingskeuzes zijn. Als de factuurketen duidelijk is, richt de aandacht zich op de vraag hoe de communicatie tus-sen de factuurschakels zich voltrekt. Hoe is het communicatieproces tussen de opeenvolgende factuurschakels ingericht? Is er sprake van menselijke tussenkomst? Worden facturen en fac-tuurinformatie gebracht of gehaald? En, hoe wordt aan weten regelgeving voldaan inzake de borging van de authenticiteit van de verzender en de integriteit van het factuurdocument? Net als op het niveau van het factuurproces doet zich vervolgens de vraag voor of er in het communicatieproces gebruik gemaakt zou moeten worden van aparte dienstverleners, die we communicatie service providers (CSP’s) zullen noemen. Dergelijke dienstverleners onderschei-den zich van eerdergenoemde BSP’s doordat zij geen factuurdienstverlening bieden, maar pure communicatiedienstverlening. Hoewel het factuurdocument door de handen en systemen van zulke CSP’s stroomt, hebben zij geen bemoeienis met de inhoud ervan. Het gaat hier om de inrichting van de communicatieketen. Aan de overheidszijde is als CSP bijvoorbeeld de OverheidsTransactiePoort (OTP) kandidaat. Aan de private zijde zullen dergelijke pure CSP’s minder vaak worden gekozen, maar verzorgt de BSP veelal ook de communicatie. Ten slotte moeten er keuzes worden gemaakt over het formaat waarin de elektronische fac-tuur wordt uitgewisseld en gearchiveerd. Welke formaat wordt er in de communicatie gebruikt en welke in de archieven? Wordt er onderweg gebruik gemaakt van formaatvalidatie (controles of vormvereisten) en –transformatie (vertaling)? Figuur 3 geeft een overzicht van deze keuze-onderwerpen en geeft aan welke door dit rapport als gegeven worden beschouwd (het factuurproces) en welke keuze-onderwerpen door dit rapport worden ondersteund (alle daaronder liggende). In wat volgt zullen we laagsgewijs door de vragen heenlopen en de keuze-opties beschrijven.

1 0 I n f r a s t r u c t u u r v o o r B 2 G e l e k t r o n i s c h f a c t u r e r e n

Figuur 3 — Afbakening.

2.3 Vraag 1 — Factuurketen

De eerste vraag gaat dus over de factuurketen. Hier is aan de orde of in het factuurproces door factuurpartijen gebruik gemaakt gaat worden van intermediaire dienstverleners, BSP’s. Daarbij maken we onderscheid tussen twee typen (mogelijke) uitbesteding. De eerste gaat over de bewerking van de factuurinhoud. Aan de verkopende zijde gaat het hier allereerst vaak over het opstellen van de elektronische verkoopfactuur (in geval van klassieke facturatie). Maar de dienstverlening van een BSP kan veel verder gaan, zelfs tot het elektro-nisch aanbieden van producten en het afhandelen van bestellingen. Aan de kopende zijde gaat het allereerst over verwerking van inkoopfacturen, mogelijk inclusief factuurcontroles en het in gang zetten van betaling. De tweede soort gaat over het al dan niet uitbesteden van archivering.

2.3.1 Vraag 1a — Verwerking van elektronische facturen

Ook als factuurpartijen hun factuurproces uitbesteden blijven zij eindverantwoordelijk. Uit-besteding wordt daarom bezegeld met een servicecontract. Een beslissing hierover is dus allereerst een zaak voor beide factuurpartijen apart. Echter, mochten zij beide voor uitbe-steding hebben gekozen, is het waardevol om de keuzes voor de respectievelijke dienstver-leners naast elkaar te leggen. Er zitten namelijk specifieke voor- en nadelen aan het kiezen van dezelfde dienstverlener. Een voorbeeld van een BSP aan de inkopende overheidszijde is Flexchange, een inkoopdienst-verlener voor uitzendkrachten. Voorbeelden van BSP’s aan de verkopende (bedrijven)zijde zijn er te over11.

11 Veel van hen participeren in het Platform ELFA (www.platformelfa.nl).

I n f r a s t r u c t u u r v o o r B 2 G e l e k t r o n i s c h f a c t u r e r e n 1 1

Er zijn dus vijf varianten: 1. direct: beide factuurpartijen houden het gehele factuurproces in huis 2. koper-uitbesteed: alleen de koper maakt gebruik van een BSP 3. verkoper-uitbesteed: alleen de verkoper maakt gebruik van een BSP 4. apart uitbesteed: beide partijen besteden uit, maar aan verschillende partijen 5. samen uitbesteed: beide partijen besteden aan dezelfde partij uit

Een voorbeeld van de laatste variant is Z-factuur (voorheen Agroportal). Figuur 4 toont de vijf varianten van boven naar beneden.

koper ver-koper

koper ver-koper

koper ver-koper

koper ver-koper

koper ver-koper

BSP-I

BSP-VBSP-I

BSP-V

BSPI V

communicatie

servicecontract koper ver-koper

koper ver-koper

koper ver-koper

koper ver-koper

koper ver-koper

BSP-I

BSP-VBSP-I

BSP-V

BSPI V

communicatie

servicecontract

communicatie

servicecontract

Figuur 4 — Vijf ketenvarianten voor verwerking van elektronische factureren.

Hoe meer tussenschakels er zijn in de factuurketen, des te meer communicatieschakels er zijn waarover informatie moet worden uitgewisseld. Toch is er maar één plaats waar de feitelijke factuuroverdracht, de feitelijke zakelijke factureerhandeling plaatsvindt. Omdat weten regelgeving zich vooral daarop richt, is het belangrijk die plaats in de factuurketen aan te wijzen. Bij uitbesteding in de factuurketen verplaatst het eindpunt van de factuuroverdracht zich van de factuurpartij naar de gekozen dienstverlener. Door de uitbesteding ontstaat er een nieuwe communicatieschakel. Op die communicatieschakel is echter geen sprake van formele factuur-overdracht, maar hooguit van het uitwisselen van factuurinformatie. Hoe die informatie en die communicatie zijn ingericht, hangt erg van de precieze uitbestedingsrelatie af. Die relatie wordt bezegeld met een servicecontract. Figuur 5 laat voor elk van de vijf varianten zien waar de factuuroverdracht plaatsvindt.


De vijfde variant is een bijzondere, omdat de feitelijke factuuroverdracht zich voltrekt binnen de grenzen van de dienstverlener. Hoewel factuurpartijen huiverig kunnen zijn voor een inter-mediair die beide zijden van de markt bedient, vereenvoudigt deze variant de factuurover-dracht.

koper ver-koper

koper ver-koper

koper ver-koper

koper ver-koper

koper ver-koper

BSP-I

BSP-VBSP-I

BSP-V

BSPI V

koper ver-koper

koper ver-koper

koper ver-koper

koper ver-koper

koper ver-koper

BSP-I

BSP-VBSP-I

BSP-V

BSPI V

Figuur 5 — Factuuroverdracht in de factuurketen (rode, dikke pijlen).

In dergelijke gevallen stelt de weten regelgeving: • de eis dat het moment van factuuroverdracht precies duidelijk moet zijn • geen eisen aan het fysiek scheiden van de beide helften van de dienstverlening door

deze intermediair. Natuurlijk moet de scheiding logisch gezien wel gemaakt worden. Uitbesteding compliceert de adressering factuurketen. Zie hiervoor paragraaf 4.5.

2.3.2 Vraag 1b — Archivering van elektronische facturen

Ook archivering kan en mag worden uitbesteed. In principe kan een beslissing over mogelijke uitbesteding van archivering plaatsvinden los van zo’n beslissing over verwerking. Toch zullen veel factuurpartijen archivering meenemen in hun eventuele overweging om factuurverwerking uit te besteden. In geval van uitbesteding moet voor de uitbestedende partij goede en onmid-dellijke toegang tot de archieven gewaarborgd blijven. Dit moet dus deel uitmaken van het servicecontract. Ook voor archivering geldt dat beide factuurpartijen dezelfde dienstverlener kunnen kiezen, in welk geval weten regelgeving geen eisen stelt aan het fysiek scheiden van beide archieven. De in- en verkoopfacturen zouden in dat geval dus in hetzelfde archief en in dezelfde database mogen worden opgeslagen, zolang toegang vanuit beide kanten logisch goed gescheiden blijft.


Alleen BTW-plichtige kopers of verkopers hebben een archiveringsverplichting.

2.4 Vraag 2 — Communicatieproces

Over het communicatieproces zijn drie vragen aan de orde, namelijk: a. Is er menselijke betrokkenheid en, zo ja, van welke aard? b. Bij wie ligt het initiatief? Is er sprake van halen of brengen? c. Hoe is authenticiteit van de verzender en integriteit van de factuur geborgd?

Deze vragen moeten beantwoord worden voor alle communicatieschakels. Dus, als er in de factuurketen sprake is van intermediaire partijen, gaat het om twee of zelfs drie communi-catieschakels. Toch verdient de factuuroverdracht daarbij bijzondere aandacht, vooral vanwege weten regelgeving. Voor het communicatieproces is het belangrijk de begrippen “zender” en “ontvanger” niet synoniem te zien aan “verkoper” en “koper”. Immers, in geval van uitbesteding in de factuur-keten kan de zender of de ontvanger van de elektronische factuur ook een BSP zijn. Bovendien kan door een keuze voor zelffacturatie de verzendrichting van het factuurdocument wisselen.

2.4.1 Vraag 2a — Menselijke betrokkenheid

Ook al spreken we over elektronisch factureren, in sommige gevallen is menselijke tussen-komst bij de overdracht aan de orde. Dat gebeurt vooral als één van de factuurpartijen een consument is of een kleine onderneming. Omdat dit rapport over B2G-facturatie gaat, zijn consumenten niet aan de orde, maar mogelijk wel kleine leveranciers. Een typisch voorbeeld van menselijke betrokkenheid aan de verzendende kant is het handma-tig versturen van een elektronische factuur via e-mail, of het handmatig uploaden van een elektronische factuur in een portal van de ontvanger. Let wel, dit hoeft niet te betekenen dat de factuur ook handmatig is opgesteld of ingevuld in een elektronisch formulier. Het kan ook zijn dat een al opgestelde elektronische factuur als bijlage aan een e-mailbericht wordt gekop-peld of geselecteerd wordt voor een upload naar een portal. Een typisch voorbeeld van menselijke betrokkenheid aan de ontvangende kant is het handma-tig openen van een ontvangen factuur, hetzij als bijlage aan en binnengekomen e-mailbericht of in een portal waarin facturen worden gepresenteerd. Natuurlijk kan er ook aan beide zijden menselijke betrokkenheid zijn, hoewel dat de efficiën-tie van het factuurproces niet zal bevorderen. Ten slotte kan menselijke betrokkenheid ook aan beide kanten ontbreken. In dat geval hebben we het over machine-machine overdracht van elektronische facturen. Verder is de aard van de menselijke betrokkenheid van belang. Onderdelen van menselijke betrokkenheid kunnen zijn:

• menselijke triggering van de overdracht (versturen of ophalen) • menselijke samenstelling van de factuur (zoals het invullen van een elektronisch

formulier) • menselijke transformatie van facturen (“overtypen”) • menselijke interpretatie van de factuur (zoals het lezen van een factuur van een

scherm)


2.4.2 Vraag 2b — Initiatief

Een tweede vraag over het communicatieproces gaat over het initiatief bij de factuurover-dracht. Als de verzender het initiatief neemt spreken we van brengen (of push); als de ontvanger het initiatief neemt spreken we van halen (of pull). Voorbeelden van brengen zijn:

• een elektronisch formulier intypen in een portal van de ontvanger; • een e-mailbericht naar de ontvanger; • een push-bericht van de verzendende applicatie naar de ontvangende applicatie.

Voorbeelden van halen zijn:

• het downloaden van een factuur vanaf een portal van de verzender • het door de ontvanger aanroepen van een web service bij de verzender.

Bij halen is het natuurlijk zaak dat de ontvanger op de hoogte is van het feit dat er één of meerdere facturen klaarstaan. Dat kan door middel van een notificatie in de vorm van een apart bericht. Een ander model kan zijn om in een overeenkomst (of algemene voorwaarden) te bepalen dat op vaste momenten facturen klaarstaan. Het is belangrijk op te merken dat menselijke betrokkenheid en initiatief niet onderling afhankelijk zijn. Alle combinaties kunnen voorkomen, al is een enkele niet erg gangbaar. Tabel 2 laat dit zien.

Tabel 2 ─ Menselijke tussenkomst en initiatief.

Menselijke betrokkenheid

verzender

Menselijke betrokkenheid

ontvanger Initiatief Voorbeeld

Nee Nee Brengen Push-bericht tussen applicaties Nee Nee Halen Aanroep web service tussen applicaties Nee Ja Brengen Automatisch verzonden e-mailbericht met factuur. Nee Ja Halen Ophalen van een factuur van een portal. Ja Nee Brengen Uploaden van een factuur in een portal. Ja Nee Halen Automatisch sturen van een elektronisch factuurformulier. Ja Ja Brengen Handmatig e-mailen van een elektronische factuur. Ja Ja Halen Handmatig e-mailen van een leeg elektronisch factuurformulier.

2.4.3 Vraag 2c — Authenticiteit en integriteit

In bijna alle elektronische (en vele papieren en face-to-face) zakelijke contacten is het van belang de authenticiteit van de betrokken partijen met enige zekerheid vast te stellen en er-voor te zorgen dat het uitgewisselde document integer blijft. BTW-weten regelgeving op het gebied van elektronisch factureren vereist in het bijzonder maatregelen ter borging van:

• de authenticiteit van de herkomst van de factuur • de integriteit van het factuurdocument


Dit vraagt vooral extra aandacht bij de factuuroverdracht. Op eventuele andere communicatie-schakels moet een en ander worden geborgd in het servicecontract dat bij de uitbesteding hoort. Zoals al aangegeven is in de variant “samen uitbesteden” in de factuurketen de factuur-overdracht een interne aangelegenheid bij de dienstverlener. Hiermee is de authenticiteit van de verzender en de integriteit van het document veel makkelijker geborgd, zolang maar duidelijk is wanneer de feitelijke facturering zich voltrekt. De BTW-weten regelgeving kent een Europese basis, waarbinnen Europese lidstaten nog enige vrijheid hebben12. We baseren ons hier op de Nederlandse weten regelgeving. De weten regelgeving biedt drie opties voor de middelen waarmee de vereiste authenticiteit en integriteit wordt geborgd. Zij heten:

• “EDI” • “geavanceerde elektronische handtekening” • “andere middelen”

We bespreken hieronder de precieze eisen aan deze modellen. De basis van de “EDI”-optie is dat authenticiteit en integriteit worden geregeld in een uitwisselovereenkomst. Anders ge-zegd, het is een contract-gebonden middel. De basis van de optie “geavanceerde elektronische handtekening” is dat authenticiteit en integriteit worden geregeld met een aan de factuur ver-bonden handtekening. Anders gezegd, het is een document-gebonden middel. Hoewel de derde optie (“andere middelen”) niet verder gespecificeerd staat, vallen hieronder vaak sessie-gebonden middelen, waarbij een communicatiesessie worden beveiligd met een technisch protocol of naam-wachtwoord-beveiliging van menselijke gebruikssessies.

2.4.3.1 Authenticiteit en integriteit d.m.v. “EDI”

In deze optie wordt authenticiteit en integriteit geborgd door middel van een uitwisselover-eenkomst, bijvoorbeeld in de vorm van audit trails of anderszins. Daarnaast zijn er aanvullende eisen ingeval aanspraak gemaakt wordt op deze optie. De belangrijkste zijn:

• Er mag geen menselijke tussenkomst zijn. • De factuur moet zijn opgemaakt in een overeengekomen formaat. • Het communicatieformaat moet een elektronisch dataformaat zijn (zie paragraaf 2.6.1) • De betekenis van alle gegevens moet duidelijk gedefinieerd zijn.

12 PWC, Global (E-)Invoicing & (E-)Archiving, januari 2006.


Deze voorwaarden komen overeen met wat men in de dagelijkse praktijk onder de term “EDI” verstaat. Echter, op twee punten dreigt een gevaarlijke overinterpretatie van deze term ten opzichte van de officiële definitie in de weten regelgeving13.

• EDI wordt vaak geïdentificeerd met een specifieke mark-up-standaard, namelijk EDI-FACT, en als zodanig tegenover XML-gebaseerde factuurformaten geplaatst. Dat is niet terecht. Onder de officiële definitie van “EDI” vallen ook XML-gebaseerde formaten, zolang ook aan de andere eisen wordt voldaan. Het argument dat XML alleen niet vol-doende zou zijn omdat het geen betekenis geeft aan de gegevens, is valide, maar dat geldt ook voor de EDIFACT-standaard op zichzelf.

• EDI wordt vaak geïdentificeerd met een specifiek communicatiemodel, waarin zoge-naamde Value-Added Networks (VAN’s) gesloten communicatiediensten bieden (zie paragraaf 2.5.1). De officiële definitie van “EDI” maakt hiervan echter geen enkele melding. Gebruik van het Internet als communicatiekanaal sluit deze optie dus niet uit.

2.4.3.2 Authenticiteit en integriteit d.m.v. de “geavanceerde elektronische handtekening”

In deze optie wordt een elektronische handtekening verbonden aan het elektronische factuur-document. Drie eisen aan deze handtekening dragen zorg voor de authenticiteit van de verzender:

• De handtekening moet verwijzen naar een unieke ondertekenaar. • De ondertekenaar moet bij de handtekening gevonden kunnen worden. • De handtekening wordt gezet met middelen die geheel onder de controle zijn van de

ondertekenaar. Een vierde eis zorgt voor integriteit van het factuurdocument:

• De handtekening is zodanig verbonden met het document, dat aanpassingen in het document opspeurbaar zijn.

Dit zijn de minimumeisen uit de Europese weten regelgeving. Lidstaten mogen strengere eisen stellen door te eisen dat de geavanceerde elektronische handtekening “gekwalificeerd” moet zijn. Dat betekent vooral dat er van een vertrouwde derde partij gebruik gemaakt moet worden voor het uitdelen van certificaten. Nederland heeft niet gekozen voor de strengere variant, maar bijvoorbeeld Duitsland wel. Dat betekent dat de drempel voor het toepassen van deze optie lager is dan vaak wordt aangenomen.

2.4.3.3 Authenticiteit en integriteit d.m.v. “andere middelen”

Aan deze optie worden geen inhoudelijke kenmerken verbonden, maar zij kan gebruikt worden voor puur sessie-gebonden middelen, zoals:

• SSL/TLS-gebaseerde oplossingen voor communicatiesessies • naam/wachtwoord-gebaseerde oplossingen voor menselijke gebruikssessies

2.4.3.4 De rol van de Belastingdienst

De Belastingdienst speelt een handhavende rol bij de genoemde BTW-weten regelgeving op het gebied van elektronisch factureren. In geval van de eerste twee opties hoeft niet vooraf om instemming gevraagd te worden van de Belastingdienst, bij de derde wel.

13 CEN/ISSS Workshop on Interoperability of Electronic Invoices in the European Community, CEN Workshop Agreement 15574, juli 2006.


Mocht eenzelfde scenario herhaald worden toegepast voor meerdere factuurstromen, hoeft slechts één keer de toestemming van de Belastingdienst te worden gevraagd. Wel moeten nieuw aangesloten partijen gemeld worden aan de Belastingdienst. Ten slotte is het van belang dat de genoemde middelen elkaar niet uitsluiten. Soms kunnen contract-gebonden, document-gebonden en sessie-gebonden middelen samen worden toege-past of kunnen sessie-gebonden middelen met een bescheiden inspanning worden opgewaar-deerd tot één van de andere twee middelen. Dat is aantrekkelijk omdat de eerste twee opties de laagste compliancedrempel kennen.

2.5 Vraag 3 — Communicatieketen

Ook op het niveau van de communicatieketen speelt de vraag of de factuurschakels gebruik maken van diensten van externe communicatiedienstverleners (CSP’s). De gemaakte keuzes in de factuurketen bepalen hoeveel en welke communicatieketens er aan de orde zijn.

2.5.1 Vraag 3a — Hoofdvarianten

De hoofdvarianten bij deze vraag zijn volledig analoog aan die op het niveau van de factuurketen (zie paragraaf 2.3.1). We onderkennen daarom vijf hoofdvarianten:

1. direct 2. zender-uitbesteed: alleen de zender gebruikt een CSP 3. ontvanger-uitbesteed: alleen de ontvanger gebruikt een CSP 4. apart uitbesteed: beide gebruiken een andere CSP 5. samen uitbesteed: beide gebruiken dezelfde CSP

Omdat de ontvangende zijde de overheidskant is, zullen we verderop aparte aandacht besteden aan specifieke CSP’s voor B2G-verkeer binnen het overheidsdomein, namelijk de OverheidsTransactiePoort (OTP) en de infrastructuur van het Nationaal TaxonomieProject (NTP), al dan niet in combinatie met de OverheidsServiceBus (OSB). Binnen de afbakening van dit rapport zijn pure CSP’s aan de kant van de verzender zeldzaam. De communicatierol is vaak een onderdeel van de diensten van een BSP. Wel kunnen BSP’s onderling zogenaamde roamingrollen vervullen. Zie hiervoor de volgende paragraaf. Een bekend voorbeeld van de vijfde hoofdvariant betreft de dienstverlening van Value-Added Networks (VAN’s). Deze worden bijvoorbeeld gebruikt in het Deense scenario (zie paragraaf 2.7.2). Figuur 6 toont de vijf hoofdvarianten. Ook in de communicatieketen compliceert uitbesteding de adressering in de factuuroverdracht. Zie hiervoor paragraaf 4.5.


zendersdomeinontvangersdomein

ont-vanger zender

ont-vanger zender

ont-vanger zender

ont-vanger zender

ont-vanger zender

CSP-O

CSP-ZCSP-O

CSP-Z

CSPO Z

communicatie

servicecontract

zendersdomeinontvangersdomein

ont-vanger zender

ont-vanger zender

ont-vanger zender

ont-vanger zender

ont-vanger zender

CSP-O

CSP-ZCSP-O

CSP-Z

CSPO Z

communicatie

servicecontract

communicatie

servicecontract

Figuur 6 — Vijf hoofdvarianten voor de communicatieketen.

2.5.2 Vraag 3b — Roaming

Hoewel de hoofdvarianten van de communicatieketen erg lijken op die van de factuurketen, spelen verschillende overwegingen de hoofdrol in de keuzes tussen de varianten. Weliswaar is op beide niveaus sprake van een keuze tussen zelf doen of uitbesteden. Maar, in de factuur-keten gaat die vraag over inhoudelijke bedrijfsprocessen ─ hoe secundair vaak ook ─ terwijl het in de communicatieketen gaat over technische communicatiediensten. Aan de ene kant is technische communicatie vrijwel nooit een kerncompetentie, aan de ander kant wordt technologie steeds meer standaard en goedkoop. Bovendien komt er op communicatieniveau een erg belangrijke eis aan de oppervlakte: bereik. Factuurpartijen en hun eventuele BSP’s moeten onderling verbonden zijn om een factuur over te kunnen dragen. Een belangrijke eis bij een eventuele keus voor een CSP (of BSP) is dan ook: kan ik via die dienstverlener al mijn communicatiepartners bereiken? Helaas is dat niet altijd het geval. Dienstverleners danken hun positie in de markt vaak aan hun klantenbestand en zijn niet altijd bereid de communicatiedrempel met niet-klanten laag te maken of te houden. Dat beperkt het bereik, dat vanuit het perspectief van de factuurpartijen liefst onbeperkt is. Grofweg zijn er twee modellen om met deze beperking om te gaan:

• consolidatie: in dit model combineren dienstverleners hun respectievelijke bereik tot een groter bereik, en creëren zo een nieuwe grotere, dienstverlener;

• roaming: in dit model maken dienstverleners onderlinge afspraken over het “doorspe-len” van facturen van elkaars klanten.


Momenteel is roaming zeldzaam in Nederland, zo niet afwezig. Consolidatie is in een vrije markt niet af te dwingen, maar kan wel ontstaan wanneer marktpartijen elkaar vanwege bereik voor hun klanten of aanwezige marktaandeel gaan opzoeken. Overigens, ook als BSP’s onderling roamingafspraken zouden maken, spelen zij voor elkaar de CSP-rol. Aan de overheidszijde is consolidatie makkelijker haalbaar, omdat de overheids-ICT onder een zekere gezamenlijke regie staat. Dat zegt overigens nog niets over de wenselijkheid tot conso-lidatie naar bijvoorbeeld de OTP of de NTP-infrastructuur. In het geval van consolidatie komen er geen nieuwe communicatieketenvarianten aan de orde: er ontstaan alleen nieuwe dienstverleners in de markt. In geval van roaming echter krijgt de communicatieketen extra intermediaire schakels. Roaming compliceert de adressering in de factuuroverdracht. Zie hiervoor paragraaf 4.5.

2.6 Vraag 4 — Formaat

In deze laatste hoofdvraag onderkennen we vier deelvragen, die allemaal te maken hebben met het formaat van de elektronische factuur:

• de keuze van het communicatieformaat • vragen op het gebied van formaatvalidatie • vragen op het gebied van formaattransformatie • de keuze van het archiveringsformaat

2.6.1 Vraag 4a — Communicatieformaat

Bij elektronisch factureren gaat de eerste gedachte vaak uit naar het formaat van het overgedragen factuurdocument. Immers, dat moet een elektronisch formaat zijn, in tegenstelling tot een papieren formaat. Bij elektronische formaten maken we een nader onderscheid tussen de mate waarin de in het document gevatte informatie expliciet gestructureerd is, zodat automatische verwerking van het document mogelijk wordt gemaakt. We maken in deze context onderscheid tussen drie structuurniveaus:

• elektronische afbeelding • elektronische tekst • elektronische data

Bij een elektronische afbeelding is er sprake van een elektronisch document, bedoeld voor visuele waarneming door een mens of eventueel door een elektronische scanner. Hoewel een gefaxte factuur niet snel als een elektronische zal worden gezien is dat een voorbeeld hiervan. Meer geaccepteerde voorbeelden zijn facturen in de vorm van een JPEG- of GIF-bestand of een “scanned PDF”-bestand. Bij elektronische tekst is de elektronische verwerkbaarheid al groter omdat tekst enigszins automatisch geïnterpreteerd en verwerkt kan worden. Een voorbeeld hiervan is een elektro-nische factuur als tekst in een e-mailbericht of een elektronische factuur in de vorm van een (veelal automatisch aangemaakt) “structured PDF”-document. Het ene PDF-document is dus het andere niet.


In de meest gestructureerde vorm is de factuur een expliciet gestructureerd formulier of be-richt, waarvan de verschillende velden een expliciete betekenis hebben, zodat de verschillen-de velden eenvoudig elektronisch zijn te verwerken. Er is een veelheid aan dergelijk factuur-formaten beschikbaar. Zo bestaat er, naast het door het College Standaardisatie gekozen14 UBL 2.0, ook een XBRL Invoice-formaat, een OAGIS-factuur en een GS1-factuur. UN/CEFACT werkt aan een moderne, wereldwijde standaard voor elektronisch factureren. Met de vertegenwoor-digers van een aantal belangrijke bestaande factuurstandaarden zijn afspraken gemaakt over convergentie naar de UN/CEFACT-standaard.

2.6.2 Vraag 4b — Formaatvalidatie

Vaak maken factuurschakels expliciete afspraken over het formaat van uitgewisselde factuur-informatie of overgedragen facturen, zoals in het geval van de uitwisselovereenkomsten waar-van sprake is bij “EDI” (zie paragraaf 2.4.3.1). Dergelijke afspraken maken het mogelijk om binnengekomen facturen automatisch te verwerken. Voordat een factuur verwerkt kan worden moet echter geverifieerd worden dat deze aan het afgesproken formaat voldoet. Daartoe vindt een formaatvalidatie plaats. Formaatvalidatie is een syntactische controle van het factuurdocument tegen de afspraken die erover zijn gemaakt. Als die controle niet slaagt wordt de factuur geweigerd op basis van “vormfouten”. We gaan er hier van uit dat dergelijke validatie alleen zinvol is bij een communicatieformaat in de vorm van elektronische data. Bij-voorbeeld, als het factuurformaat een op XML gebaseerd formaat heeft, zal formaatvalidatie het factuurdocument valideren tegen een XML Schema-document. In de infrastructuur voor elektronisch factureren is het van belang te bepalen waar dergelijke formaatvalidaties plaatsvinden. Voor de hand ligt dat de factuurpartijen of hun BSP’s ─ vooral de ontvangende ─ dergelijke factuurvalidatie uitvoeren. Soms echter voert ook een tussen-liggende CSP in de communicatieketen dergelijke validaties uit.

2.6.3 Vraag 4c — Formaattransformatie

Niet altijd spreken de factuurschakels hetzelfde communicatieformaat. In dat geval kan het zinvol zijn om een vertaling in te richten van het ene naar het andere communicatieformaat. We onderscheiden daarbij verticale en horizontale transformatie. Verticale transformatie heet zo omdat er bij deze vorm meer structuur wordt aangebracht in het factuurdocument. Voorbeelden daarvan zijn:

• van papier naar een elektronische afbeelding: scannen • van een elektronische afbeelding naar elektronische tekst: Optical Character

Recognition (OCR) • van elektronische tekst naar elektronische data: tekstontleding

Vaak komen deze in combinatie voor, vooral scanning en OCR. Verticale transformatie wordt ingezet op het koppelvlak tussen papieren en elektronische processen. Horizontale transformatie heet zo omdat er bij deze vorm vertaald wordt tussen twee elektro-nische dataformaten, bijvoorbeeld tussen het UBL- en het GS1-factuurformaat. Horizontale transformatie hoort betekenis-behoudend te zijn, dat wil zeggen, een syntactische vertaling waarbij de betekenis van het document niet wordt gewijzigd. 14 Voor nadere informatie over deze keuze, zie http://www.forumstandaardisatie.nl/fileadmin/OVOS/CS03-05-12_besluitenlijst.pdf en http://gbo.overheid.nl/fileadmin/OVOS/CS03-05-06A_-_efactureren.pdf.


Mocht gekozen worden voor de inrichting van één van deze transformatievormen, is het van belang te bepalen wáár in de keten deze transformatie plaatsvindt. Dat zal vaak een factuur-partij of haar BSP zijn.

2.6.4 Vraag 4d — Archiveringsformaat

In uitbreiding op het gestelde in 2.4.3, stel BTW-weten regelgeving dat de authenticiteit van de verzender en de integriteit van het factuurdocument ook tijdens archivering intact moeten blijven. In principe hebben factuurpartijen voor het archiveringsformaat dezelfde keuzes als voor het communicatieformaat (zie paragraaf 2.6.1). Echter, mocht voor de “geavanceerde digitale handtekening” gekozen zijn als middel voor authenticiteit en integriteit, dan stelt de weten regelgeving dat het archiveringsformaat identiek moet zijn aan het communicatieformaat. Bij de andere twee opties is dat geen vereiste.

2.7 Typische scenario’s

2.7.1 Seller-direct, buyer-direct, consolidator, e-invoicing en een vijfde

In deze paragraaf presenteren we een aantal typische scenario’s, waarin voor bovengenoemde vragen keuzes zijn gemaakt. De eerste vier scenario’s komen overeen met de vier vormen van elektronisch factureren die zijn opgenomen in de marktverkenning over elektronisch facture-ren van Dialogic15. Het vijfde scenario (e-mail met PDF-bijlage) hebben we toegevoegd om ook een eenvoudig en laagdrempelig scenario te kunnen beschrijven. Zie Tabel 3. Met het beschrijven van deze scenario’s doen we geen enkele waarderende uitspraak over de scenario’s, relatief noch absoluut. Ook impliceren we niet dat het betreffende scenario altijd voldoet aan de weten regelgeving.

2.7.2 Deense scenario’s

Denemarken heeft de reputatie koploper op het gebied van elektronisch factureren met de overheid te zijn. In 2005 werden alle publieke instanties in Denemarken verplicht om alleen nog maar elektronische facturen te accepteren. Om dit te realiseren hebben de Denen een infrastructuur voor elektronisch factureren ontwikkeld. De Deense overheid maakt gebruik van een mix aan scenario’s om alle bedrijven te kunnen bedienen. Drie scenario’s kunnen worden herkend. Tabel 4 biedt een overzicht. De Deense infrastructuur is gebaseerd op bestaande Value Added Networks (VAN’s) die ervoor zorgen dat een leverancier op een veilige, rechtsgeldige manier een elektronische factuur kan versturen naar de overheid. Omdat meerdere VAN’s actief zijn in deze infrastructuur is roaming ingericht. Daarvoor is een adresseringssystematiek nodig, waarbij gebruik gemaakt wordt van het EAN Global Location Number (GLN). Dit nummer maakt het mogelijk om het elektronische adres van het bedrijf te achterhalen. Het GLN wordt bij het versturen van de factuur op de elektronische envelop geplaatst.

15 Ronald Batenburg en Barbera van den Berg, e-Factureren en standaarden voor e-invoicing in Nederland, Dialogic, maart 2008.


Tabel 3 ─ Typische scenario’s.

Hoofdvraag Deelvraag EIP(P) seller-direct

EIP(P) buyer-direct

EIP(P) consolidator E-invoicing E-mail met

PDF-bijlage

1a. Verwerking Direct Direct Verkoper-

uitbesteed Direct Direct 1. Factuur-keten

1b. Archivering Niet bepaald Niet bepaald Niet bepaald Niet bepaald Niet bepaald

2a. Menselijke tussenkomst

Aan de ontvan-gende kant

Aan de verzen-dende kant

Aan de ontvan-gende kant Nee Aan de ontvan-

gende kant

2b. Initiatief Halen Brengen Halen Halen of

brengen Brengen 2. Communi-catieproces

2c. Authenticiteit en integriteit

“geav. elektr. handtekening” of “andere middelen”



“EDI”


3a. Hoofdvariant Direct Direct Direct Direct/ samen

uitbesteed Direct 3. Communi-catieketen

3b. Roaming Nee Nee Nee Nee Nee

4a. Communi-catieformaat

Elektronisch, niet nader bepaald



Elektronische data

Elektronische afbeelding of tekst

4b. Formaat-validatie

Geen Geen Geen Waarschijnlijk wel, minstens bij ontvanger.

Geen

4c. Formaat-transformatie Geen Geen Geen Geen Geen

4. Formaat

4d. Archive-ringsformaat Niet bepaald Niet bepaald Niet bepaald Niet bepaald Niet bepaald

Denemarken koerst niet alleen op VAN’s. Momenteel is men bezig om de mogelijkheden van een additionele Internet-gebaseerde infrastructuur te onderzoeken. Omdat niet alle bedrijven mee kunnen of willen doen met het elektronisch versturen van fac-turen zijn er twee private dienstverleners aanwezig die papieren facturen scannen en ervoor zorgen dat ze op het goede adres aankomen. Hiervoor staat een maximale termijn van vijf dagen. Deze diensten worden gratis aangeboden. Veel MKB-ers maken gebruik van deze dienst. Het aantal MKB-ers dat gebruik maakt van deze dienst neemt over de jaren niet af. Ten slotte biedt de Deense overheid ook een portaal aan waarin elektronische facturen kunnen worden samengesteld en verstuurd.


Tabel 4 ─ De Deense scenario’s.

Hoofdvraag Deelvraag Deense e-invoicing

Deense portaal

Deense scandienst

1a. Verwerking Direct Koper-uitbesteed Direct 1. Factuurketen

1b. Archivering Niet bepaald Niet bepaald Niet bepaald

2a. Menselijke tussenkomst Nee Aan de verzendende kant

Nee

2b. Initiatief Brengen Brengen Brengen 2. Communicatieproces

2c. Authenticiteit en integriteit “EDI” “digitale handte-kening” of “an-dere middelen”

“EDI”

3a. Hoofdvariant Samen uitbesteed Direct Verzender-

uitbesteed 3. Communicatieketen

3b. Roaming Ja, tussen de VAN’s. Nee Nee

4a. Communicatieformaat Elektronische data (OIOXML16)

Elektronische data (OIOXML16)

Elektronische data (OIOXML16)

4b. Formaatvalidatie Waarschijnlijk wel, minstens bij ontvanger

Waarschijnlijk niet

Waarschijnlijk wel, minstens bij ontvanger

4c. Formaattransformatie Nee Nee Scanning en OCR

4. Formaat

4d. Archiveringsformaat Niet bepaald Niet bepaald Niet bepaald

16 http://en.itst.dk/architecture-and-standards/data-standardisation/e-business-standardisation/oioxml-electronic-invoicing


3 Hoe te kiezen?

3.1 Introductie

Hoofdstuk 2 laat zien dat er nogal wat varianten zijn voor de infrastructuur voor elektronisch factureren. In hoofdstuk 4 zullen we aangeven op welke manier factuurpartijen kunnen kiezen tussen alle mogelijkheden. Deze keuzes worden gedreven door de wensen en eisen van de factuurpartijen op het gebied van elektronisch factureren. In dit hoofdstuk 3 zullen we in paragraaf 3.2 aangeven welke generieke wensen en eisen naar voren zijn gekomen in de gesprekken die we in het kader van dit onderzoek hebben gevoerd (zie paragraaf 1.6) en uit de documentatie die we hebben geraadpleegd (zie paragraaf 1.5). Daarna geven we in paragraaf 3.3 een overzicht van het keuze-instrument dat we in hoofd-stuk 4 in detail zullen presenteren. Voor een belangrijk deel werkt dat instrument met basisopties, waarvan in voorkomend geval kan worden afgeweken. Deze basisopties worden in paragraaf 3.4 ─ per vraag ─ besproken, samen met de omstandigheden die het bereiken van die basisoptie kunnen beperken.

3.2 Wensen en eisen

Natuurlijk gaat het de factuurpartijen niet allereerst om de infrastructuur, maar om de proces-voordelen die met elektronisch factureren zijn te behalen. Infrastructuren zijn daarbij kosten-posten. Wensen en eisen aan infrastructuur hebben daarom meestal te maken met het goed ondersteunen van het elektronische factuurproces en het beperken van kosten en risico’s. Uit de genoemde gesprekken hebben we de volgende wensen en eisen van factuurpartijen ten aanzien van de infrastructuur voor elektronisch factureren opgetekend:

• bereik: De infrastructuur moet het mogelijk maken alle gewenste factuurpartijen te bereiken, zonder onnodige drempels.

• lage communicatiekosten: De uitwisseling van factuurinformatie en de factuurover-dracht moeten de factuurpartijen weinig kosten.

• lage investeringsdrempel: De infrastructuur moet geen grote investeringen vragen, en zeker geen herhaalde investeringen.

• beperking compliancerisico’s: Het moet zo snel mogelijk duidelijk zijn of en hoe een bepaalde infrastructuur voldoet aan de weten regelgeving.

• onafhankelijkheid: Waar van de diensten van intermediairs (BSP’s en CSP’s) gebruik wordt gemaakt, moeten deze geen grote macht in de factuurketen worden.

• hergebruik: De infrastructuur moet liefst kunnen worden hergebruikt voor andere elektronische handelingen, zoals bestellen of betalen.

• internationaal: De infrastructuur moet liefst kunnen worden hergebruikt voor elektronisch factureren met factuurpartijen uit andere landen.


In het kader van dit rapport speelt de overheid verschillende rollen. Naast die van factuurpar-tij zijn dat de rollen van handhaver van BTW-weten regelgeving (bij monde van de Belasting-dienst) en van beleidsmaker. Vanuit deze perspectieven noteren we één bestaande en één nieuwe wens ten aanzien van de infrastructuur:

• compliance aan BTW-weten regelgeving • uitstraling naar B2B en B2C: Het Actieplan Elektronisch Factureren positioneert de

overheid als launching customer van elektronisch factureren, met de bedoeling dat suc-cesvolle B2G-implementaties ook tot meer B2B- en B2C-implementaties zullen leiden.

Tabel 5 ─ Verwerking van de wensen en eisen

Wens of eis Verwerking in keuze-instrument Verwerking in de Adviezen

bereik Dit is een keuzecriterium in hoofdvraag 3. Bevorder maximaal bereik door roaming en/of consolidatie.

lage communicatie-kosten Dit is een keuzecriterium in hoofdvraag 1.

lage investerings-drempel

Het keuze-instrument werkt met een “basisoptie, tenzij”-benadering, waarin de gevraagde investering een reden kan zijn om van de basisoptie af te wijken.

compliance Dit is onderwerp van vooral deelvragen 2c en 4d.

Bevorder duidelijkheid op het gebied van weten regelgeving.

onafhankelijkheid Dit is een keuzecriterium in hoofdvraag 1.

hergebruik

De scope van het instrument is alleen elektro-nisch factureren. Veel van de gebruikte criteria kunnen echter ook voor andere stappen in het commerciële proces worden gebruikt.

internationaal Dit is niet meegenomen in het instrument. Het beperkt zich tot Nederlandse weten regelgeving.

Bevorder internationale harmonisatie van weten regelgeving.

informatie-transparantie

Elektronische data wordt als basisoptie voor het communicatieformaat (deelvraag 4a) gepositioneerd. Dit legt de basis voor maximale informatietransparantie.

reconciliatie

Elektronische data wordt als basisoptie voor het communicatieformaat (deelvraag 4a) gepositioneerd. Dit legt de basis voor reconciliatie.

gestandaardiseerde gegevenselementen

Elektronische data wordt als basisoptie voor het communicatieformaat (deelvraag 4a) gepositioneerd.

Streef naar een beperkt aantal standaarden.

opslag Dit is onderwerp van deelvragen 1b en 4d.

uitstraling naar B2B en B2C

Hoewel het daarvoor niet is gevalideerd, is het instrument in reikwijdte en inhoud ook geschikt voor B2B en B2C. Het leidt niet tot B2G-specifieke keuzes.


In een document van UN/CEFACT17 wordt ook een analyse gedaan van de wensen en eisen van factuurpartijen ten aanzien van elektronisch factureren. Voor een belangrijk deel komen deze overeen met de hierboven al genoemde wensen en eisen, namelijk een lage investeringsdrem-pel, hergebruik en compliance. Aanvullend echter noteren we de volgende wensen en eisen uit dit UN/CEFACT-document:

• informatietransparantie: Factuurpartijen moeten maximaal op de hoogte zijn van alle relevante informatie betreffende de facturatiehandeling.

• reconciliatie: Factuurpartijen moeten in staat zijn de factuur te matchen met andere commerciële handelingen zoals de bestelling en de betaling.

• gestandaardiseerde gegevenselementen: Het factuurdocument moet opgebouwd zijn uit gestandaardiseerde gegevenselementen.

• opslag: Factuurpartijen moeten elektronische facturen kunnen archiveren conform weten regelgeving.

Op een enkele uitzondering na, zijn al deze wensen en eisen verwerkt in het keuze-instrument dat we in hoofdstuk 4 zullen presenteren of in de adviezen die we in hoofdstuk 6 aan de opdrachtgever doen. Tabel 5 biedt een overzicht.

3.3 Overzicht van het keuze-instrument

Het keuze-instrument dat we in hoofdstuk 4 zullen presenteren kent dezelfde structuur als die van de keuzeruimte uit hoofdstuk 2. Dat wil zeggen: in het keuze-instrument worden de ver-schillende hoofd- en deelvragen in dezelfde volgorde doorlopen. De gezamenlijke antwoorden vormen het gekozen scenario. De volgende stappen worden dus doorlopen (Figuur 7):

0. Voorbereiding 1. Maak keuzes over de factuurketen.

a. Factuurverwerking en opslag: zelf doen of uitbesteden? b. Factuuroverdracht versus uitwisseling van factuurinformatie.

2. Maak keuzes over het communicatieproces. a. Menselijke tussenkomst b. Initiatief c. Authenticiteit en integriteit

3. Maak keuzes over de communicatieketen. a. Hoofdvariant b. Roaming

4. Maak keuzes over het formaat.

a. Communicatieformaat b. Formaatvalidatie c. Formaattransformatie d. Archiveringsformaat

17 UN/CEFACT/ITPWG/TBG15, Annex to Recommendation 6 (to accommodate e-Invoicing), paragraaf 2.2, versie voor Public Review, 21 mei 2008.


0. Voorbereiding

1. Factuurketena. Verwerking

b. Archivering

a. Menselijke betrokkenheid

2. Communicatieproces b. Halen of brengen

c. Authenticiteit en integriteit

3. Communicatieketena. Hoofdvarianten

b. Roaming

4. Formaat

a. Communicatieformaat

b. Formaatvalidatie

c. Formaattransformatie

d. Archiveringsformaat

KEUZESSTAPPEN SCENARIO

0. Voorbereiding

1. Factuurketena. Verwerking

b. Archivering

a. Menselijke betrokkenheid

2. Communicatieproces b. Halen of brengen


3. Communicatieketena. Hoofdvarianten

b. Roaming

4. Formaat

a. Communicatieformaat

b. Formaatvalidatie

c. Formaattransformatie


KEUZESSTAPPEN SCENARIO

Figuur 7 — Overzicht van het keuze-instrument.

3.4 Basisopties en beperkingen

Oorspronkelijk leefde het streven om het keuze-instrument voor infrastructuur voor elektronisch factureren vorm te geven als een beslisboom. Al snel bleek echter dat het keuzeveld te ingewikkeld was voor een hiërarchisch keuze-instrument. In plaats daarvan is daarom gekozen voor een benadering waarin een reeks van keuzes worden doorlopen, die onderling voor een groot deel (maar niet geheel) afhankelijk zijn. De eerste hoofdvraag is in essentie een vraag naar het al dan niet uitbesteden van factuur-processen. Om factuurpartijen te helpen deze vraag beantwoorden, maken we daarom gebruik van een bestaand instrument voor “sourcing” van diensten. Voor de hoofdvragen 2, 3 en 4 kiezen we een “basisoptie, tenzij”-benadering, waarbij we steeds een preferente keuze formuleren, samen met mogelijke omstandigheden waaronder van deze voorkeur kan worden afgeweken. Zie Tabel 6. In hoofdstuk 4 komen we terug op het waarom van deze basisopties. Soms vallen beperkingen binnen de directe invloedssfeer van de factuurpartijen, vooral als bestaande processen en systemen (legacy) of bestaande dienstverleners de beperking vormen. Menige beperking echter valt buiten de onmiddellijke invloed van factuurpartijen, zoals:

• beperkt bereik, geen roaming • heterogeen formatenlandschap • onzekerheid over compliance • internationale verschillen in weten regelgeving


Tabel 6 ─ Basisopties en beperkingen

Hoofdvraag Deelvraag Voorkeur Beperkingen

a. Menselijke tussenkomst

Geen menselijke tussenkomst Bestaande processen en systemen

b. Initiatief Brengen Bestaande processen en systemen 2. Communicatie-proces


Eerste keus: geav. elektr. handtekening Tweede keus: EDI

Kosten ontwikkeling en beheer van handtekeninginfrastructuur, resp. uitwisselovereenkomsten

a. Hoofdvariant Direct Beperkt bereik 3. Communicatie-keten b. Roaming

Liefst: niet nodig Indien nodig: volledig en gestandaardiseerd

Bestaand aanbod Eigen strategieën van aanbieders

a. Communicatie-formaat Elektronische data Bestaande processen en systemen

Heterogeen formatenlandschap

b. Validatie Bij factuurschakels Bestaande systemen.

c. Transformatie Overbodig

Bestaande processen en systemen Heterogeen formatenlandschap Geen laagdrempelige transformatie beschikbaar

4. Formaat


Identiek aan communicatieformaat Bestaande processen en systemen

Het keuze-instrument biedt geen concrete houvast bij het opheffen van dergelijke “netwerk-beperkingen”. Dat vraagt gezamenlijke actie van factuurpartijen en dienstverleners en soms de overheid om deze beperkingen op te lossen. Aan het eind van dit hoofdstuk willen we nog drie algemene aanbevelingen doen aan factuurpartijen, voordat zij het keuze-instrument van hoofdstuk 4 gaan toepassen.

• Think big, act small: streef naar een infrastructuur die voldoet aan de geschetste basisopties, maar implementeer stapsgewijs, vanuit de huidige situatie van uw factuurprocessen en –systemen. Vergeet niet de langere-termijn ambitie te formuleren.

• Kies voor openheid en bereik: als u kiest voor dienstverleners, kies dan voor dienstverleners met een open strategie op basis van open standaarden18, groot bereik en bereidheid tot roaming. Voorkom ingevangen te raken door dienstverleners. Waar u zelf voor software kiest, kies voor open architecturen en open standaarden.

• Laat uw stem horen over de “netwerkbeperkingen”: bevorder samen met collega-fac-tuurpartijen, dienstverleners en de overheid het bereik in het elektronische factuurnet-werk, de beperking van het aantal gebruikte factuurformaten, zekerheid over compli-ance en de internationale harmonisatie van weten regelgeving.

18 Zie de definitie op http://www.ososs.nl/wat_zijn_open_standaarden.


4 Keuze-instrument

Dit hoofdstuk behandelt in detail het keuze-instrument voor infrastructuur voor elektronisch factureren. Het doorloopt elk van de hoofd- en deelvragen uit Figuur 7.

4.1 Stap 1 — Factuurketen

4.1.1 Zelf doen of uitbesteden?

De vragen in deze stap gaan over het al dan niet in eigen huis houden van factuurprocessen. Dergelijke “make-or-buy”- of “sourcing”-beslissingen komen in allerlei verschijningsvormen voor in het bedrijfsleven en de overheid. Er is geen reden om aan te nemen dat de criteria bij dergelijke beslissingen fundamenteel anders zijn bij elektronisch factureren. Hooguit kunnen de scores op de criteria en hun onderlinge weging anders uitpakken. We maken in deze stap daarom gebruik van een bestaand eenvoudig keuze-instrument, de Outsourcing Decision Making Scorecard19 (ODMS), die we voor eigen gebruik licht hebben aangepast (Tabel 7). ODMS werkt met een twintigtal vragen, in vier groepen van vijf. Bij de eerste twee groepen geldt dat een positief antwoord op de vraag een argument is vóór zelf doen en tégen uitbesteding. Bij de laatste twee groepen is dat precies andersom.

Tabel 7 ─ ODMS voor elektronisch factureren.

Groep Vraag

Organisatie

1. Betreft (elektronisch) factureren een kerncompetentie van uw organisatie? 2. Zal de dienst slechts incidenteel worden geleverd/gebruikt? 3. Hebt u de voor elektronisch factureren benodigde expertise en middelen in uw organisatie? 4. Zouden bij uitbesteding de coördinatiekosten de eventuele schaalvoordelen overstijgen? 5. Zijn er juridische bezwaren om factureren uit te besteden?

Risico’s

6. Zou verlies aan controle over (elektronische) facturatie uw organisatie schaden? 7. Zou verlies aan expertise over (elektronische) facturatie uw organisatie schaden? 8. Is de geleverde kwaliteit van (elektronische) facturatie een belangrijke voorwaarde? 9. Kan de responsiviteit bij operationele facturatieproblemen in gevaar komen? 10. Kan de uitvoering van huidige taken en contracten lijden onder uitbesteding?

Doelen

11. Kunnen de doelen van de (elektronische) facturatiedienst scherp worden beschreven? 12. Zijn deze doelen voor langere termijn geldig? 13. Kan het bereiken van de doelen nauwkeurig worden gemeten en zijn de meetinstrumenten hiervoor

momenteel beschikbaar? 14. Is het niet bereiken van de doelen schadelijk voor uw organisatie? 15. Is uw situatie vrij van specifieke (niet-standaard) wensen en eisen op het gebied van facturatie?

Evaluatie van

aanbieders

16. Zijn er bekende aanbieders van facturatiediensten? 17. Zijn de missie en de strategische doelen van deze aanbieders in lijn met de uwe? 18. Hebben de aanbieders de positie, de competenties en de middelen om de dienst te kunnen leveren? 19. Hebt u al een relatie (gehad) met deze aanbieders? 20. Hebben de aanbieders bewezen de dienst met passende kwaliteit te kunnen leveren?

19 Robert J. Eger III, Deborah A. Knudson, Justin Marlowe, Libby Ogard, Decision-Making Criteria for Outsourcing Opportunities, Research Summary Series, University of Wisconsin-Milwaukee, oktober 2002. http://www.mrutc.org/research/0103/01-03onepage.pdf


4.1.2 Stap 1a — Verwerking

Voor een antwoord op de vraag of (inkoop- respectievelijk verkoop)factuurverwerking in huis moet blijven of uitbesteed kan worden, passen beide factuurpartijen ODMS allereerst apart toe, op hun eigen situatie. Daarbij is de vraag aan de orde over welke processen of diensten het precies gaat. Zoals gezegd gaat het minmaal over het opstellen van verkoopfacturen, respectievelijk het verwerken van verkoopfacturen. Soms echter maakt dit deel uit van een groter geheel, zoals inkoop of betalingsdiensten. Voor beide factuurpartijen leidt het gebruik van ODMS tot één of meer opties voor al dan niet uitbesteden. Omdat de factuurpartijen onderling zaken doen, is het vervolgens zaak om deze opties naast elkaar te leggen en te bezien of zij onderling op elkaar aansluiten. Bijvoorbeeld, stel dat

• koper K twee uitbestedingsopties heeft, namelijk aan partijen K1 en K2 • verkoper V ook twee opties heeft, namelijk zelf doen of uitbesteden aan partij V2 • K1 niet of alleen tegen hoge kosten verbonden kan worden met V en V2 • K2 niet of alleen tegen hoge kosten verbonden kan worden met V

Dan ligt het voor de hand dat K overweegt uit te besteden aan K2 en V aan V2, omdat K2 en V2 het makkelijkst onderling bereik realiseren. Zie Figuur 8.

Figuur 8 ─ Confronteren van uitbestedingsopties (voorbeeld).

Natuurlijk is dit een speelgoedvoorbeeld. In de praktijk kan het voorkomen dat er nog steeds meer opties overblijven of ─ vervelender ─ dat er geen optie overblijft. In dat geval kan het zijn dat een relatief grote investering in onderling bereik moet worden gedaan of dat de oorspronkelijke ODMS-scores moeten worden heroverwogen om tot nieuwe opties te komen. Zoals gezegd gebruiken we hier een generiek keuze-instrument voor het specifieke geval van factuurverwerking. Op een aantal ODMS-vragen bestaan in het geval van elektronische factuurverwerking typische antwoorden, die we in Tabel 8 presenteren.


Tabel 8 ─ Typische ODMS-antwoorden voor (elektronische) factuurverwerking.

ODMS-vraag Typisch antwoord voor elektronische factuurverwerking

1. Betreft (elektronisch) factureren een kerncompetentie van uw organisatie?

Nee, voor de meeste factuurpartijen is factureren geen kerncompetentie.

4. Zouden bij uitbesteding de coördinatie-kosten de eventuele schaalvoordelen overstijgen?

Bij ontvangers van facturen (kopers bij klassieke facturatie en verkopers bij zelffacturatie) is uitbesteding vaak pas interessant als dat gecombineerd wordt met andere processen, zoals opslag, reconciliatie of betaling.

5. Zijn er juridische bezwaren om factureren uit te besteden?

Nee, uitbesteding is nadrukkelijk toegestaan. Wel zijn er voorwaarden.

15. Is uw situatie vrij van specifieke (niet-standaard) wensen en eisen op het gebied van facturatie?

Ja, facturering is in veel gevallen een standaardproces. Daarop zijn echter belangrijke uitzonderingen.

16. Zijn er bekende aanbieders van facturatiediensten?

Ja, er zijn volwassen dienstverleners in de markt die de BSP-rol kunnen spelen.

17. Zijn de missie en de strategische doelen van deze aanbieders in lijn met de uwe?

Bij grote dienstverleners, uitbesteding van grote diensten of dienstverleners die zowel kopers als verkopers bedienen, kunnen strategische bezwaren spelen bij factuurpartijen.

4.1.3 Stap 1b — Archivering

Ook bij archivering passen factuurpartijen voor de keuze tussen zelf doen en uitbesteden de ODMS toe. Daar komt bij dat de beslissing in stap 1a die in stap 1b beïnvloedt: het scheelt coördinatiekosten als archivering bij dezelfde partij komt te liggen als de factuurverwerking. Toch is dat geen wet van Meden en Perzen. Het hangt bijvoorbeeld van de dienstverlening en de kwaliteit van de beschikbare dienstverleners af. Let wel, alleen BTW-plichtige kopers of verkopers hebben een archiveringsverplichting. In tegenstelling tot bij factuurverwerking speelt bereik hier geen rol. Dat wil zeggen, factuur-partijen hoeven hun ODMS-uitkomsten niet onderling te confronteren (zoals in stap 1a) om onderling bereik zeker te stellen. Er is wel een andere, maar minder pregnante, reden om de ODMS-uitkomsten van beide factuurpartijen bij elkaar te leggen: sommige dienstverleners bedienen zowel kopers als verkopers. In dergelijke gevallen kan een besparing worden bereikt door de inkoop- en verkoopfactuurarchieven te combineren bij dezelfde dienstverlener. Een heikel punt bij uitbesteding van archivering is de beëindiging van het uitbestedingcon-tract. Wet- en regelgeving stelt een bewaartermijn van (minsten) zeven jaar. Er moeten dus voorzieningen worden getroffen om bij contractbeëindiging ook recent gearchiveerde facturen niet te verliezen. Dat kan door deze facturen

• nog bij deze dienstverlener in bewaring te houden (zonder dat nieuwe facturen in be-waring worden gegeven) of

• bij deze dienstverlener weg te halen en zelf te archiveren of bij een nieuwe dienstver-lener in bewaring te brengen.


4.2 Stap 2 — Communicatieproces

4.2.1 Stap 2a — Menselijke betrokkenheid

In paragraaf 3.4 formuleerden we als basisoptie dat er geen menselijke betrokkenheid is bij het overdragen van de factuur of het uitwisselen van factuurinformatie. Let wel, dat wil niet zeggen dat er geen menselijke betrokkenheid moet zijn in het verwerken van een factuur. Zo is het vaak wenselijk de inhoudelijke acceptatie en betaalbaarstelling van een factuur door een medewerker te laten bepalen. Stap 2a gaat echter niet over verwerking, maar over over-dracht en uitwisseling. Die taken kunnen vaak sneller, nauwgezetter en goedkoper langs geheel elektronische weg worden afgehandeld. Die basisoptie vraagt wel om passende automatisering op alle factuurschakels. Daarom kan worden afgeweken van de basisoptie als:

• één of meer van de betrokken factuurschakels geen of eenvoudige financiële software-systemen gebruikt. Dat is bijvoorbeeld aan de orde als een consument of een kleine onderneming (zoals een ZZP-er) factuurpartij is.

• het huidige factuurproces een papieren proces is. In dat geval kan deze stap naar een volledige geautomatiseerde overdracht voor één der betrokken partijen wel eens te groot zijn. Elektronische facturering met menselijke betrokkenheid (zoals in het buyer- of seller-direct scenario) kan dan een zinvolle tussenstap zijn.

In een enkel geval kan zelfs gedacht worden aan een factuurketen met twee communicatie-schakels met menselijke tussenkomst. Denk bijvoorbeeld aan de variant “samen uitbesteden” in de factuurketen, waarbij eenzelfde BSP zowel zeer kleine kopers als zeer kleine verkopers bedient. In dat geval zou de verkoper zijn factuur kunnen aanmaken in het verkopersportal van deze BSP, waarna de koper deze in het kopersportal van diezelfde BSP gepresenteerd krijgt. Hoe dan ook, als in de factuuroverdracht sprake is van enige menselijke tussenkomst, vervalt de “EDI”-optie als middel voor authenticiteit en integriteit ( 4.2.3). Binnen de afbakening van dit rapport (B2G) geldt dat de koper (aan overheidszijde) vaak een schaalgrootte en automatiseringsgraad zal hebben die het mogelijk maakt menselijke betrok-kenheid te voorkomen. Aan de verkopende zijde (bedrijfsleven) ligt dat iets anders, omdat de overheid regelmatig zaken doet met zeer kleine bedrijven zoals ZZP-ers, die een zeer lage automatiseringsgraad hebben. De tweede keus is menselijke tussenkomst te beperken tot het door mensenhand triggeren van de factuuroverdracht, dus zonder menselijke betrokkenheid bij het opstellen of van de fac-tuur. Een voorbeeld daarvan is het handmatig versturen van een e-mailbericht met een automatisch gegenereerde elektronische factuur als bijlage of het downloaden van een elektronische factuur van een portal en het dan importeren van de factuur in de eigen financiële software-applicatie. Transformatie door mensenhand (overtypen) moet in ieder geval worden voorkomen. In dat soort gevallen worden namelijk bijna alle voordelen van elektronisch factureren teniet gedaan. Men zou zelfs kunnen zeggen dat er in dergelijke gevallen geen sprake is van werkelijk elektronisch factureren op de betreffende schakel.


4.2.2 Stap 2b — Initiatief

In 3.4 formuleerden we als basisoptie dat het initiatief van de factuuroverdracht (en uitwis-seling van factuurinformatie) bij de verzender ligt: brengen dus. De reden hiervoor is dat dit de facturatie maximaal versnelt, omdat er niet gewacht hoeft te worden totdat een ontvanger de factuur ophaalt. Zo wordt “real-time” of “straight-through” verwerking van facturen moge-lijk. Opnieuw zijn er omstandigheden waarin deze basisoptie moeilijk haalbaar is. Die liggen vooral aan de ontvangende kant. Niet alle processen en systemen aan de ontvangende kant zijn er namelijk op berekend op willekeurige momenten facturen te ontvangen en te verwerken. Dat kan zowel gelden voor menselijke processen als voor software-applicaties. Dergelijke proces-sen en systemen bepalen dan liever zelf het ontvangst- en verwerkingsritme. Voor voorbeelden van halen en brengen, zie Tabel 2. Als toch voor halen wordt gekozen is het van belang dat het klaarzetten van een factuur niet voldoende is om een factuuroverdracht te bezegelen. Met andere woorden: het klaarzetten van een factuur op een portal of achter een web service is te weinig. De ontvanger moet op de hoogte kunnen zijn dan er nieuwe facturen op hem of haar wachten. Dat kan door een notifi-catiebericht te sturen. In geval van een menselijke ontvanger kan dat en e-mailbericht zijn die met een URL verwijst naar de locatie van de klaarstaande factuur. In geval van een applicatie als ontvanger kan dat een elektronisch notificatiebericht zijn. Een andere mogelijkheid is in sommige gevallen nog om in een uitwisselovereenkomst tijdstippen af te spreken waarop (periodiek) nieuwe facturen klaar staan.

4.2.3 Stap 2c — Authenticiteit en integriteit

4.2.3.1 Liefst de handtekening of “EDI”

Wet- en regelgeving stelt eisen aan de middelen die worden gebruikt voor het borgen van de authenticiteit van de verzender en de integriteit van het factuurdocument, in de factuur-overdracht. Als voorkeursvolgorde voor het hiervoor gebruikte soort middel geldt:

1. “geavanceerde elektronische handtekening” 2. “EDI” 3. “andere middelen”

De redenen hiervoor zijn dat:

• de geavanceerde elektronische handtekening, als het eenmaal is geïmplementeerd, het meest flexibele, schaalbare en herbruikbare middel is;

• “EDI” naast de “geavanceerde elektronische handtekening” het enige middel is dat op zichzelf voldoende borging voor authenticiteit en integriteit heeft, waarvoor om die reden ook geen goedkeuring vooraf aan de Belastingdienst hoeft te worden gevraagd

De meest gangbare reden om af te zien van de eerste keus is dat de drempel voor de imple-mentatie van een daarvoor benodigde certificaat- en sleutelinfrastructuur als te hoog wordt gezien. In dat kader is het van belang te melden dat Nederland op dit punt voor de meest coulante invulling van Europese weten regelgeving heeft gekozen, zodat in Nederland de gebruikte elektronische handtekening niet “gekwalificeerd” hoeft te zijn. Dit verlaagt de drempel voor deze optie.


De meest gangbare redenen om af te zien van de tweede keus is: • dat het opstellen en beheren van uitwisselovereenkomsten, waarin ook authenticiteit

en integriteit zijn geregeld, als te kostbaar of te weinig schaalbaar wordt gezien; • dat andere keuzes deze optie uitsluiten. Dat speelt voor als er menselijke tussenkomst

in het spel is of als het communicatieformaat en elektronische afbeelding of elektronische tekst is (zie paragraaf 4.4.1).

Een belangrijk nadeel van de derde keus is dat het specifieke toestemming vooraf van de Belastingdienst vraagt. In dat kader is het belangrijk niet te snel te besluiten tot de derde optie. Vaak kan een oplossing die schijnbaar in de derde categorie valt met bescheiden middelen worden opgewaardeerd tot één van de andere twee middelen. Let wel! “EDI als tweede keus” slaat alleen op “EDI” als middel voor borging van authenticiteit en integriteit. Alle andere aspecten van de “EDI”-definitie blijven nog steeds de basisoptie, zoals het ontbreken van menselijke tussenkomst en het communicatieformaat (elektronische data). Met andere woorden, de ideale combinatie is het gebruik van “EDI” voor elektronisch facturen, met een geavanceerde elektronische handtekening om het elektronische bericht te ondertekenen. Authenticiteit en integriteit hoeven dan niet meer via de uitwisselovereenkomst te worden geregeld.

4.2.3.2 Digid-Bedrijven

Overheidsorganisaties kunnen gebruik maken van de authenticatiedienst Digid, waarmee bij menselijke gebruikssessies de gebruiker kan worden geauthenticeerd op basis van naam-wacht-woord-combinaties. In eerste instantie is Digid bedoeld voor overheidsdiensten aan burgers, niet aan bedrijven. Daarvoor is momenteel de variant Digid-Bedrijven beschikbaar20. Het toekomstperspectief van Digid Bedrijven is echter zo onzeker dat het vooralsnog geen kandidaat is voor gebruik bij elektronisch factureren. Mocht het dat ooit wel worden, dan is het bruikbaar in specifieke scenario’s, die lijken op het buyer-direct scenario (zie paragraaf 2.7.1). Het middel zou dan vallen onder “andere middelen”.

4.3 Stap 3 — Communicatieketen

4.3.1 Stap 3a — Hoofdvariant

De basisoptie voor de hoofdvariant voor de communicatieketen is direct, dat wil zeggen, zonder aparte CSP aan enige zijde. Oftewel, bij voorkeur communiceren factuurschakels (factuurpartijen en/of hun BSP’s) rechtstreeks met elkaar. De reden hiervoor is dat, vanuit uitbestedingsperspectief, een puur technologische dienstver-lener geen inhoudelijke (proces)waarde toevoegt. Bovendien zullen de kostenbesparingen van uitbesteding in de communicatieketen bescheiden zijn, ervan uitgaande dat de benodigde technologie goedkoop en standaard is. Mocht dat laatste niet het geval zijn, kan natuurlijk wel aan een CSP worden gedacht, maar zou ook verandering van technologie moeten worden overwogen.

20 Digid Bedrijven authenticeert niet zozeer bedrijven alswel medewerkers die namens een bedrijf optreden. Zie http://www.digid.nl/bedrijf/.


Er is echter één belangrijke reden om van de basisoptie af te wijken en die is: bereik. Het kan zijn dat het gebruik van een CSP het bereik tussen factuurschakels belangrijk verbetert. Als twee factuurschakels niet onderling verbonden zijn, kan het zijn dat een CSP de onderliggende verbinding wel biedt. Maar ook met het oog op toekomstige, nieuwe klanten of toeleveranciers kan besloten worden om de taak om steeds nieuwe verbindingen te leggen bij een CSP te leggen. Een tweede reden om toch een CSP in te schakelen voor elektronisch factureren is aan de orde als al voor andere doeleinden van een dergelijke CSP gebruik gemaakt wordt. Een belangrijke kwaliteit van een CSP is dan ook dat zij payload-neutraal is, dat wil zeggen, dat zij liefst geen beperkingen legt op de inhoud van het verkeer dat via haar wordt afgewikkeld. Het inschakelen van CSP’s compliceert de adresseringssystematiek. Zie daarvoor paragraaf 4.5.

4.3.1.1 De OTP en de NTP-infrastructuur

Vanuit overheidsperspectief zijn twee voorzieningen kandidaat als CSP. Het gaat om de OverheidsTransactiePoort21 (OTP) en de infrastructuur van het Nationaal TaxonomieProject22 (NTP). Beide zijn bedoeld als toegangsvoorziening voor elektronisch berichtenverkeer van bedrijfsleven naar de overheid. Zij zijn vooral geschikt voor scenario’s waarin sprake is van

• machine-machine verkeer (geen menselijke tussenkomst) en • elektronische data en • initiatief aan de bedrijfszijde, dus in het geval van klassieke facturatie: brengen

De twee voorzieningen zijn in verschillende projecten ontwikkeld, maar momenteel beide in beheer bij GBO.Overheid. De ambitie is om ze op termijn te laten convergeren naar één infrastructuur voor berichtenverkeer tussen bedrijfsleven en overheid. De stromen die momenteel via deze CSP’s worden afgewikkeld vinden plaats in het kader van de wettelijke verplichtingen van specifieke overheidsorganisaties (veelal grote uitvoerings-organisaties) en de wettelijke aanleververplichtingen die daaruit voor bedrijven voortvloeien, zoals importaangifte aan de douane, winstaangifte aan de Belastingdienst en aanlevering van statistische gegevens aan het CBS. Daarbij staat eenmalige aanlevering van gegevens en meervoudig gebruik ervan door overheidsorganisaties centraal. De OTP en de NTP-infrastructuur zijn kandidaat als CSP in het overheidsdomein in geval dat de factuurpartijen al van de OTP of NTP-infrastructuur gebruik maken of deze CSP’s hun bereik belangrijk verbreden. Mocht de inzet voor elektronisch factureren van de OTP of de NTP-infrastructuur door overheidspartijen worden overwogen, moet daarbij rekening gehouden worden met een aantal complicaties. Allereerst onderscheidt factuurverkeer zich wezenlijk van de huidige stromen die over de OTP en de NTP-infrastructuur worden afgewikkeld. Factuurverkeer vloeit niet voort uit een wette-lijke taak van een specifieke overheidsorganisatie, waarvoor de OTP en de NTP-infrastructuur wel primair zijn opgezet. Populair gezegd: deze voorzieningen zijn gemaakt voor aanlevering aan “de overheid”, waarbij het voor het bedrijf niet belangrijk is om welke overheidsorganisa-tie het gaat. Bij factuurverkeer is dat anders.

21 http://www.overheidstransactiepoort.nl/fileadmin/OTP/factsheet_otp_v3.pdf 22 http://www.xbrl-ntp.nl/PI/


Dat zorgt er onder andere voor dat voor een passende ondersteuning van factuurverkeer het bereik aan overheidszijde veel groter zou moeten zijn dan momenteel bij deze voorzieningen het geval is. In plaats van de huidige beperkte set van bereikte overheidsorganisaties (ca. 10), zou er een veel grotere dekking aan overheidszijde moeten zijn. Daarnaast stelt dit eisen aan de adresseringssystematiek die door deze voorzieningen worden gebruikt (zie ook paragraaf 4.5). De NTP-infrastructuur besluit momenteel op basis van het binnengekomen berichttype naar welke overheidsorganisatie de informatie moet worden doorgestuurd. Dat kan echter alleen bij verkeer dat plaatsvindt in het kader van een wettelijke taak. Uit het enkele feit dat het binnengekomen bericht een factuur is kan niet worden afgeleid waarnaartoe de factuur moet worden doorgeleid. Dat vraagt een expliciete adresseringssystematiek, in plaats van de huidige impliciete. De OTP gebruikt momenteel al een expliciete adressering van de eindbestemming, die samen met het berichttype wordt gebruikt voor routering. In e-mailadressen wordt de OTP zelf als domein geadresseerd en de eindbestemming als account binnen dat domein (bijvoorbeeld: [email protected]). Voor factuurverkeer zou dit betekenen dat een groot aantal over-heidsorganisaties (en vaak zelfs onderdelen daarvan) een dergelijk “OTP-account” zouden moeten krijgen. Momenteel ondersteunden OTP en de NTP-infrastructuur verschillende communicatieproto-collen, namelijk X.400 en SMTP (OTP) en SOAP/HTTP (NTP-infrastructuur), maar hier vindt convergentie plaats23. Een belangrijke complicatie van de OTP is voorts dat het de specifieke installatie van een OTP-mailserver bij de factuurschakel (verkoper of BSP) vereist. Ten slotte is het van belang op te merken dat de NTP-infrastructuur functioneel rijker is dan de OTP. Zo biedt de OTP geen formaatvalidatie (zie paragraaf 4.4.2) en de NTP-infrastructuur wel, waarbij opgemerkt moet worden dat deze alleen geschikt is voor XBRL-verkeer en niet voor ander (XML-)verkeer. Dit moet worden gezien in het licht van het besluit van het College Standaardisatie24 om UBL 2.0 een voorkeurspositie te geven als factuurformaat ten opzichte van andere (en dus ook XBRL). Ook kent de NTP-infrastructuur een portaal, zodat ook aanleververkeer met menselijke tussenkomst kan worden ondersteund.

4.3.1.2 De OSB

De OverheidsServiceBus25 (OSB) is een voorziening voor berichtenverkeer tussen overheids-organisaties onderling. Met het oog op elektronisch B2G-factureren is zij daarmee dus geen kandidaat voor rechtstreeks verkeer tussen partijen in het private en publieke domein. Momenteel wordt onderzocht of de OSB ook gebruikt kan worden door bedrijven die een wettelijke taak uitvoeren, in opdracht van overheidsorganisaties. Dergelijke bedrijven verstu-ren voor die uitvoering facturen naar de overheid, maar het is nog niet duidelijk of dergelijk factuurverkeer ─ dat immers niet bij de wettelijke taak zelf hoort ─ dan ook over de OSB mag worden afgehandeld.

23 Zie bijvoorbeeld http://www.xbrl-ntp.nl/Nieuws/nieuwsbriefotpsoap08. Vooralsnog zal geen van deze protocollen vervallen. 24 http://www.forumstandaardisatie.nl/fileadmin/OVOS/CS03-05-12_besluitenlijst.pdf 25 http://www.overheidsservicebus.nl


Daarom is, voor elektronisch B2G-factureren, de OSB vooralsnog alleen aan de orde als commu-nicatievoorziening tussen partijen in het overheidsdomein, dat wil zeggen tussen:

• een eventuele overheids-BSP en de koper • een overheids-CSP (de OTP of de NTP-infrastructuur) en de koper of een eventuele

overheids-BSP Die laatste optie is echter vooralsnog niet mogelijk, omdat de OSB nog niet gekoppeld is aan de OTP noch aan de NTP-infrastructuur. Een dergelijke koppeling zou wel het bereik van de OTP en de NTP-infrastructuur belangrijk kunnen vergroten (zie paragraaf 4.3.1.1). Omdat de OSB breed binnen de overheid moet gaan worden uitgerold, is het aanbevelens-waardig voor overheidsorganisatie, ook voor elektronisch factuurverkeer, te anticiperen op aansluiting op de OSB, door het maken van vergelijkbare technologische keuzes.

4.3.2 Stap 3b — Roaming

Het liefst is roaming helemaal niet nodig. Als factuurschakels (factuurpartijen of BSP’s) zelf voldoende bereik hebben, hoeft de één niet als doorgeefluik voor de ander op te treden. Roaming is complex, omdat ervoor afspraken tussen dienstverleners moeten worden gemaakt. Roaming compliceert bovendien adressering en routering (zie paragraaf 4.5). Vooralsnog echter is het bereik in het “elektronisch factuurnetwerk” niet dekkend. Bekijk daarom steeds of u, al dan niet via uw BSP of CSP al uw belangrijke factuurpartners kunt bereiken. Is dit niet mogelijk, zet deze partijen dan aan tot roamingafspraken met andere dienstverleners, zodat uw bereik wordt vergroot. Mocht uw dienstverlener zich daar uit het oogpunt van marktpositie tegen verzetten, heroverweeg dan uw keuze voor deze dienstverle-ner.

4.4 Stap 4 — Formaat

4.4.1 Stap 4a — Communicatieformaat

De keuze voor het communicatieformaat is een cruciale. De term “elektronisch factureren” moge de indruk wekken dat een pure vervanging van een papieren factuur door een elektro-nische variant voldoende is om de vruchten van elektronisch factureren te plukken, maar dat is niet zo. De grootste voordelen van elektronisch factureren komen pas in zicht op het moment dat men kiest voor een elektronisch dataformaat en dus verder gaat dan een elektronische afbeelding of elektronische tekst. De reden daarvoor is dat alleen een dergelijk formaat het toestaat elektronische facturen geautomatiseerd te verwerken en te koppelen met andere processen. Daarom is elektronische data de basisoptie. De voordelen van een keuze voor elektronische afbeeldingen, ten opzichte van papieren facturen, beperken zich veelal tot besparingen in de distributiekosten (afdrukken en versturen van facturen) voor de verzender. Zij laten zich echter niet elektronisch verwerken door de ontvanger. Elektronische tekst is al een stap verder, omdat dan in elk geval de tekstuele elementen uit de factuur kunnen worden vrijgemaakt. Dat zorgt ervoor dat er bijvoorbeeld gezocht en genavigeerd kan worden door (gearchiveerde) facturen. Voor archivering (zie paragraaf 4.4.4) zijn elektronische afbeeldingen dan ook af te raden.


Er zijn twee mogelijke redenen om af te wijken van de basisoptie. De eerste is dat huidige processen en systemen van de factuurschakels dit nog niet mogelijk maken. Vanuit een “think big, act small”-strategie, kan men er dan voor kiezen om één stap verder te maken in het communicatieformaat. Dus: van papier naar een elektronische afbeelding, van een elektro-nische afbeelding naar elektronische tekst en pas dan naar elektronische data. Óf men derge-lijke tussenstappen (met beperkte voordelen onderweg) wil maken, hangt af van specifieke overwegingen. Een tweede reden kan zijn dat er een consument of kleine onderneming in het spel is, voor wie automatische verwerking van facturen niet aan de orde is. Als dat de ontvanger van facturen is, kan het overigens nog steeds geen kwaad om elektronische data als formaat te gebruiken. Dergelijke facturen kunnen aan de ontvangende zijde immers eenvoudig getransformeerd worden naar leesbare formaten. Bovendien, als de ontvanger van de factuur BTW-plichtig is, zorgt de archiveringsplicht ervoor dat als communicatieformaat beter geen elektronische afbeelding kan worden gebruikt (zie paragraaf 4.4.4). Als gekozen is voor één van de drie formaatopties, welke dan ook, ligt vervolgens de vraag voor welk formaat er precies wordt gekozen. Deze keuze valt buiten het blikveld van dit rapport. We beperken ons ertoe:

• aan te raden altijd een open formaatstandaard te kiezen; • voor elektronische data te verwijzen naar het besluit van het College Standaardisatie in

dezen26. Mochten verschillende factuurschakels willen kiezen voor verschillende factuurformaten, dan kan formaattransformatie aan de orde zijn (zie paragraaf 4.4.3).

4.4.2 Stap 4b — Formaatvalidatie

Formaatvalidatie is alleen aan de orde bij een elektronisch dataformaat. De vraag op welke plaats in de communicatieketen formaatvalidatie moet worden uitgevoerd wordt bepaald op basis van de vuistregel dat formaatvalidatie op dezelfde plaats gebeurt waar ook de logistieke acceptatie van de ontvangen factuur gebeurt, bijvoorbeeld door middel van een ontvangst-bevestiging. Dat is overigens niet hetzelfde als inhoudelijke acceptatie van de factuur. Soms biedt een CSP deze logistieke acceptatie27, maar vaak wordt die pas gedaan bij de ontvangende factuurpartij zelf. Er kunnen vertrouwelijkheidsbezwaren rijzen bij formaatvalidatie door een CSP. Die moet immers in de factuur kunnen kijken om te valideren. De integriteit van het factuurdocument hoeft echter in dat geval niet in gevaar te komen. De validatie kan immers op een kopie uitgevoerd worden. Bovendien kan het bevorderlijk voor de kwaliteit van de factuur zijn als verzenders hun uitgaande factuur valideren.

26 http://www.forumstandaardisatie.nl/fileadmin/OVOS/CS03-05-12_besluitenlijst.pdf 27 De OTP en de NTP-infrastructuur bieden dergelijke logistieke acceptatie.


Een mogelijke reden om af te wijken van de vuistregel ontstaat als het factuurvolume zo groot is dat foutieve facturen het communicatiekanaal kunnen gaan belasten. In dat geval is het te overwegen om zo vroeg mogelijk in de communicatieketen foutieve facturen te onderschep-pen. Natuurlijk is de verzender de beste plek om dat te doen, maar soms zijn de verzenders talrijk en heterogeen.

4.4.3 Stap 4c — Formaattransformatie

Een behoefte aan formaattransformatie kan ontstaan als verschillen factuurschakels verschil-lende formaten hanteren. Toch is de preferente optie om transformatie te voorkomen, in elk geval onderweg in de communicatieketen (bij een CSP). Dat geldt voor zowel de verticale als de horizontale vorm. Een belangrijke reden hiervoor is dat formaattransformatie de integriteit van het factuur-document in de waagschaal zet. Immers, er moet worden gesleuteld aan de inhoud van het originele factuurdocument. Weliswaar gaat het alleen om een syntactische transformatie, waarbij ─ als het goed is ─ de betekenis behouden blijft, maar dat is vaak moeilijk hard te maken. De inrichting van een audit trail kan hier echter uitkomst bieden. Mocht transformatie toch nodig zijn, dan is het aanbevelenswaardig om dit bij een factuur-schakel (factuurpartij of BSP) uit te voeren, omdat deze inhoudelijke verantwoordelijkheid voor het document kan dragen. Bij verticale transformatie speelt dit vooral wanneer factuurpartijen geen of geen voldoende geavanceerd financieel softwaresysteem gebruiken. In dat geval kan een BSP verticale transformatiediensten (scanning, OCR, tekstontleding) aanbieden aan dergelijke klanten. Horizontale transformatie (tussen elektronische dataformaten) speelt vooral zolang er een heterogeen formatenlandschap is. Dat is momenteel het geval. Daar waar factuurpartijen verschillende elektronische dataformaten hanteren, kan een BSP ervoor kiezen transformatie aan te bieden. Idealiter is dat een tijdelijke situatie. Op het moment dat de markt zich zou hebben geconformeerd aan een homogener formatenlandschap ─ bestaande uit een beperkt aantal breed gedragen standaarden ─ zouden factuurpartijen (en hun financiële software-systemen) idealiter al deze standaarden moeten spreken. Dan is transformatie bij een BSP niet meer nodig. Overigens kan horizontale formaattransformatie ook spelen bij veranderingen in een formaat-standaard. Vaak worden gedurende een overgangsperiode meerdere versies van eenzelfde standaard gehanteerd.

4.4.4 Stap 4d — Archiveringsformaat

Het archiveringsformaat voor een elektronische factuur moet niet een elektronisch afbeel-dingsformaat zijn, en dus minsten van het soort “elektronische tekst”. Verder is het archi-veringsformaat liefst hetzelfde als het communicatieformaat, tenzij bestaande archiverings-systemen dit verhinderen. Dat zorgt ervoor dat de integriteit van het factuurdocument minder in gevaar komt. Deze voorkeuren kunnen dus een probleem opleveren op het moment dat als communicatie-formaat is gekozen voor een elektronische afbeelding. Alleen als de ontvanger niet BTW-plichtig is, levert dit geen probleem op, omdat deze niet hoeft te archiveren.


Als voor de authenticiteit en integriteit van de overdracht de geavanceerde digitale handte-kening wordt gebruikt (zie paragraaf 4.2.3), moet voor archivering hetzelfde formaat worden gebruikt, volgens de weten regelgeving. Let erop dat de certificaten die gebruikt worden voor het zetten van een digitale handtekening kunnen verlopen gedurende de verplichte archiveringsperiode (van minimaal zeven jaar). In dat geval moet aangetoond kunnen worden dat het gebruikte certificaat tijdens het zetten van de handtekening een geldige was.

4.5 Een lastig probleem: adressering en routering

Dit rapport laat zien dat er ingewikkelde constructies denkbaar zijn ─ en wenselijk kunnen zijn ─ om een ogenschijnlijk simpele factuuroverdracht tussen verkoper en koper te laten plaats-vinden. Belangrijke complicaties worden geïntroduceerd door uitbesteding, op het niveau van de factuurketen of dat van de communicatieketen. In weliswaar uitzonderlijke gevallen kunnen er zo’n tien partijen betrokken bij de overdracht. Eén van de vragen die dat oproept is hoe al-le betrokken partijen weten waar de factuur vandaan komt en, nog belangrijker, naar welke volgende partij de factuur toe moet. Als uitbesteding op beide niveaus mogelijk moet zijn, is er op elk moment van de factuur-overdracht sprake van drie niveaus van partijen, namelijk:

• de koper en verkoper • de verzendende en ontvangende factuurschakel • de verzendende en ontvangende communicatieschakel

Op al deze niveaus moet duidelijk zijn om welke partijen het gaat, door een naam, een adres, een nummer, of een andere logische of fysieke aanduiding van de bron of de bestemming van de factuur. In het geval van een elektronisch factuurbericht moet deze identificatieniveaus allemaal tegelijk ergens in het bericht zijn opgenomen. Bovendien moeten betrokken partijen weten waarnaartoe zij een elektronische factuur moe-ten sturen of waarvandaan zij een elektronische factuur moeten halen. In het laatste geval moeten zij door enige partij in de keten op de hoogte worden gesteld van de ophaallocatie, typisch door middel van een notificatie waarin het adres van die locatie is opgenomen. In het geval van brengen moet de verzendende factuurschakel weten waarnaartoe de elektronische factuur moet worden gestuurd. Dat kan de factuurpartij zijn voor wie de factuur bedoeld is, maar ook een BSP van deze factuurpartij of een tussenliggende CSP. Deze keuze kan gemaakt worden op basis van (een combinatie van):

• inhoudelijke factuurinformatie, die in de elektronische factuur is of moet worden opgenomen en door een andere partij wordt aangeleverd;

• expliciete bestemmingsinformatie die door een voorliggende partij op de envelop van de elektronische factuur(informatie) is geplaatst;

• type-informatie die door een andere partij op de envelop van de factuur(informatie) is opgenomen, zoals het onderscheid tussen een eerste factuur en een correctiefactuur;

• informatie over klant-leverancier-relaties tussen (1) factuurpartijen en BSP’s of (2) factuurschakels en CSP’s.


Met behulp van bijvoorbeeld een routeringstabel kan vervolgens uit deze basisinformatie de volgende (tussen)bestemming worden bepaald. Hoe complexer en wisselender factuurketens en communicatieketens kunnen worden ingericht, hoe ingewikkelder het inrichten en bijhou-den van deze routeringstabellen wordt. Daar komt bij dat niet alle partijen de beschikking kunnen of mogen hebben over alle bovengenoemde routeringsinformatie. Vooral CSP’s kunnen of mogen meestal geen toegang hebben tot de factuurinhoud. In het voorbeeld van de Deense infrastructuur moeten tussenliggende CSP’s (de VAN’s) weten wie de factuurpartijen zijn, ook als dat BSP’s zijn. Om die reden is een identificatie van de factuurpartij op de envelop geplaatst, in de vorm van het EAN Global Location Number (GLN) van deze partij. Van de OTP en de NTP-infrastructuur schreven we al iets over hun routerings-systematiek (zie paragraaf 4.3.1.1). Voor de Nederlandse situatie bestaan suggesties voor oplossing van de adresseringsproblema-tiek28, maar bespreking hiervan dit valt buiten de orde van dit rapport.

28 EBA en Innopay, E-invoicing 2008, version 1.0, februari 2008.


5 Twee fictieve casussen

In dit hoofdstuk beschrijven we twee casussen, om de werking van het keuze-instrument te illustreren. De casussen zijn fictief, maar niet onrealistisch. Bij de invulling van deze casussen heeft de overweging meegespeeld een breed palet aan keuzemogelijkheden te kunnen tonen.

5.1 Gemeente Reggebroek en energiebedrijf Enessuo

Reggebroek is een middelgrote gemeente in het oosten van Nederland. Zij heeft ervoor gekozen te gaan werken met elektronische facturen. Dat is niet van de ene dag op de andere gebeurd. Daarvoor heeft de Gemeente een gedegen voorbereiding getroffen. Onderstaand beschrijven wij de hoofdlijnen van deze voorbereiding. In de verschillende stappen die gezet zijn, zijn keuzes gemaakt. Wij geven hier de overwegingen die hebben meegespeeld bij de gemaakte keuzes en ook de voor- en nadelen van eventuele alternatieven. Om beter grip te krijgen op de financiële huishouding heeft de gemeente de financiële admini-stratie gecentraliseerd bij de Dienst Ondersteuning. Bij deze dienst worden alle contracten, verplichtingen, inkoopfacturen en in- en uitgaand betalingsverkeer geadministreerd en be-heerd. Tot een jaar geleden gebeurde dit vooral op basis van papieren documenten. De fysieke documentenstroom tussen diensten, bedrijven en afdelingen van de gemeente was uiteraard enorm. Allereerst zijn de (meeste) papieren documenten gedigitaliseerd en opgeslagen in een Document Management Systeem (DMS). Daarna zijn voor de grootste interne documentstromen standaard werkstromen gedefinieerd. Zowel binnen Dienst Ondersteuning, als bij de andere diensten, bedrijven en afdelingen wordt hiermee gewerkt. Hiermee is een eerste interne efficiëntieslag gemaakt. Het blijkt echter dat met het scannen van de papieren documenten en het daarna handmatig registreren ervan in de administratieve (financiële) systemen nog veel fouten worden gemaakt. Ook blijkt het werken met het DMS en het werkstroomsysteem binnen de organisatie voor veel gebruikers nog onwennig. Toch ─ of juist daarom ─ wil de gemeente verdergaande stappen van digitalisering gaan zetten, vooral van de factuurprocessen omdat deze het leeuwendeel van de stroom omvat. Een tweede reden is dat de afhandeling van facturen foutloos moet gebeuren. Het streven is te komen tot een proces waarbij inkoopfacturen zo geautomatiseerd mogelijk worden afgehandeld. De Gemeente ontvangt jaarlijks tussen de 150.000 en 180.000 inkoopfacturen van ondernemin-gen. Zij is begonnen met een onderzoek naar haar verschillende factuurstromen. Op basis van factuurvolumes en een afweging tussen kosten, baten en risico’s, besluit de Gemeente te willen starten met de facturen van haar energiebedrijf Enessuo. Dit is een klassieke factuur-stroom: Enessuo stuurt periodiek voorschotnota’s naar de Gemeente. De ontvangende afdeling (van de Dienst Ondersteuning namens de opdrachtgevende dienst) van de gemeente registreert en verwerkt de energiefacturen direct.


5.1.1 Vraag 1: Factuurketen

Voor de Gemeente is verwerking van inkoopfacturen geen kerncompetentie. Ook verwacht zij op termijn wel schaalvoordelen te kunnen behalen bij het uitbesteden van factuurverwerking ─ of zelfs delen van de inkoopprocessen ─ naar een shared service center met naburige ge-meenten. Toch besluit zij al snel dat uitbesteding voorlopig niet aan de orde is. De belangrijk-ste reden daarvoor is dat de Gemeente tegelijkertijd haar financiële processen aan het her-inrichten is en dus nog niet voldoende grip heeft op factuurverwerking om het te kunnen uit-besteden. Uitbesteden is momenteel te riskant. Het zijn dus vooral de antwoorden op vragen 6, 11 en 13 uit de ODMS die voor de Gemeente de doorslag geven. Voor Enessuo is facturering een kerncompetentie. Zij gebruikt haar factuurmomenten boven-dien als commerciële contactmomenten met haar klanten. Daarom houdt ook zij facturering in eigen huis. Voor Enessuo is het dus vooral vraag 1 van de ODMS die de doorslag geeft. De onderlinge confrontatie van deze keuzes levert geen probleem op, want Enessuo kan de Gemeente prima rechtstreeks bereiken met elektronische facturen. De factuurketen is hier dus direct. De ontvangende afdeling van de Dienst Ondersteuning zorgt voor de archivering van de inkoop-facturen. Dat is binnen de gemeentelijke organisatie zo afgesproken tussen de opdrachtgeven-de diensten en de Dienst Ondersteuning. Ook Enessuo archiveert de facturen zelf.

5.1.2 Vraag 2: Communicatieproces

Omdat de factuurketen direct is, is er maar één communicatieketen: de factuuroverdracht tussen Enessuo en de Gemeente Reggebroek. De Gemeente wenst de voorschotnota’s van Enessuo rechtstreeks in haar systemen te ontvan-gen, zonder menselijke tussenkomst. Dat kan ze, juist omdat ze ook heeft geïnvesteerd in een werkstroomsysteem. De Gemeente besluit zelfs om die voorschotnota’s niet handmatig te controleren, maar om dat alleen te doen bij de jaarlijkse eindafrekening. Enessuo heeft al geruime tijd haar factureersystemen zodanig op orde dat facturen in verschillende manieren elektronisch aan klanten kunnen worden aangeboden. Beide partijen hebben een uitwisselovereenkomst afgesproken waarin een keur aan afspraken worden gemaakt, zoals over het elektronische formaat, de factuurfrequentie en bijbehorende boekhoudinstructies. Enessuo stuurt elke maand een elektronische voorschotnota door middel van een “push”-bericht naar de elektronische postbus van de gemeente. In de uitwisselovereenkomst zijn bovendien audit trails vastgelegd waarmee kan worden geverifieerd dat de authenticiteit van de verzender en de integriteit van de factuur zijn geborgd. Deze borging vindt dus op “contract-gebonden” wijze plaats (“EDI”-model). Dat model kan in dit geval worden toegepast, omdat er geen menselijke tussenkomst is en het factuurformaat aan de betreffende eisen voldoet. Voor het communicatieproces voldoen de keuzes van de factuurpartijen in deze casus dus bijna geheel aan de basisoptie uit het keuze-instrument. Alleen is niet gekozen voor de geavan-ceerde elektronische handtekening als middel voor authenticiteit en integriteit, vooral omdat Enessuo die optie pas wil gebruiken als het gebruik van een PKI-infrastructuur hiervoor in Ne-derland gemeengoed is. Bovendien moest er toch al een uitwisselovereenkomst komen, waarin nu alleen enkele extra paragrafen moesten worden opgenomen over audit trails.


Bovendien stelt deze keuze de Gemeente in staat het archiveringsformaat te laten verschillen van het communicatieformaat (zie paragraaf 5.1.4).

5.1.3 Vraag 3: Communicatieketen

De Gemeente Reggebroek heeft serieus overwogen gebruik te maken van de OTP als communi-catiedienstverlener en OSB te gebruiken als verbinding met de OTP. Als overheidsorganisatie heeft zij immers het beleid maximaal hergebruik te maken van gezamenlijke ICT-voorzieningen bij de overheid. Momenteel echter is zij nog niet verbonden met de OSB en OTP en zijn OSB en OTP ook nog niet onderling verbonden. Zij neemt zich voor een proef te gaan doen met de combinatie OTP en OSB, op het moment dat deze gekoppeld zijn en met een berichtstroom die bij wet is geregeld als een gemeentelijke taak. Factuurverkeer is dat niet. Wel besluit zij in de uitwisselovereenkomst met Enessuo zodanige afspraken te maken dat op termijn de “omleg-ging” van het factuurverkeer via de OTP eenvoudig is te realiseren. Als zeer grote factuurverzender heeft Enessuo uitgebreide technische mogelijkheden voor het verzenden van facturen naar klanten. Zij heeft geen enkele reden om een communicatie-dienstverlener in de hand te nemen. Bovendien kan Enessuo de systemen van de Gemeente Reggebroek gemakkelijk bereiken door middel van een beveiligde verbinding over het Internet. De communicatieketen is dus direct. Roaming is in dit geval niet nodig. Dit komt overeen met de basisoptie uit het keuze-instrument.

5.1.4 Vraag 4: Formaat

Tussen de Gemeente en Enessuo is voor de komende tijd een elektronisch dataformaat voor de factuur afgesproken, namelijk de UBL 2.0-factuur. Daarmee zijn zij in lijn met het besluit van het College Standaardisatie. Voor beide partijen was dit formaat nieuw, maar hun respectieve-lijke softwareleveranciers hebben ─ met het besluit van het College Standaardisatie in de hand ─ gemeend dat het de investering waard was om de systemen erop aan te passen. Zij verwach-ten dezelfde vraag nu ook van andere klanten te krijgen. Voordat de Gemeente een ontvangstbevestiging voor de factuur uitstuurt, voert zij eerst een syntactische controle van het factuurdocument uit, op basis van standaard XML-technologie (XSLT). Formaattransformatie is niet nodig. De Gemeente heeft ten slotte gewenst de archivering haar elektronische facturen in te bedden in haar boekhoudsysteem. Omdat deze niet kan omgaan met UBL 2.0, transformeert de Ge-meente de binnenkomende factuur in het interne formaat van het boekhoudsysteem en archi-veert het in dat formaat. Enessuo archiveert in UBL-formaat. Met deze keuzes zijn de partijen vrijwel geheel in lijn met de basisopties uit het keuze-instrument. De enige uitzondering hierop is het archiveringsformaat dat de Gemeente toepast, dat anders is dan het communicatieformaat. Dit is toegestaan, omdat de “EDI”-optie gebruikt wordt voor het borgen van authenticiteit en integriteit. De reden om hier af te wijken van de basisoptie is gelegen in de wens van de Gemeente om het bestaande boekhoudsysteem hier-voor te gebruiken.


5.2 Ministerie van Publieke Zaken en uitzendbureau MedeWerk

De verschillende directies en afdelingen van het Ministerie van Publieke Zaken maken uitge-breid gebruik van uitzendkrachten. Het Ministerie doet daarvoor zaken met meerdere uitzend-bureaus. MedeWerk is daarvan het kleinste. Zij beschikt over beperkte financiële software-systemen. Uitzendkrachten vormen een bijzondere inkoopcategorie. Er zijn belangrijke raakvlakken met HRM, er is uitgebreide specifieke wetgeving en de afhandelingsprocessen verschillen nogal van die van andere inkoopcategorieën. Het Ministerie merkt dat dit bijzondere karakter meer en meer gaat vragen van haar organisatie ─ in termen van kosten en tijdsbeslag ─ en overweegt daarom met andere ministeries te gaan samenwerken in een shared service center inlenen uitzendkrachten (SSCIU). Een drietal andere ministeries is hier al mee begonnen. Deze ontwikkeling gaat gepaard met een herinrichting van het facturatieproces. In de huidige situatie schrijft de uitzendkracht gewerkte uren in het urenregistratiesysteem van het Ministe-rie. Via een werkstroomsysteem wordt dit door een leidinggevende geaccordeerd. De financië-le afdeling van het Ministerie verzamelt elke week de geaccordeerde werkbriefjes, drukt deze af op een verzamelstaat en stuurt die ondertekend, op papier, naar de uitlener. Op basis daar-van verzorgt de uitlener de verloning voor de uitzendkracht en stuurt hij elke maand een pa-pieren verzamelfactuur naar het Ministerie, die deze vervolgens handmatig en minutieus ver-gelijkt met de urenbriefjes. Dat kost tijd en geld, maar zo af en toe wordt er een flinke fout in de factuur ontdekt. In de nieuwe situatie verstuurt het Ministerie elke dag de elektronische werkbriefjes naar SSCIU. Omdat deze de mantelovereenkomst tussen het Ministerie en haar uitleners kent, stelt SSCIU de factuur op en zend deze elektronisch terug naar het Ministerie, nog op dezelfde dag. Het SSCIU stelt bovendien een kopie van de zelffactuur ter beschikking aan de uitlener. Het grote voordeel voor het Ministerie is een flinke efficiëntieslag in de inkoop- en factuur-processen, samen met de schaalvoordelen die het shared service center met zich meebrengt. Het voordeel voor de uitlener is gelegen in de versnelling van het factureer- en daarmee ook het betaalproces.

5.2.1 Vraag 1: Factuurketen

Omdat zij als shared service center niet alleen met de grote uitzenders, maar ook met kleine als MedeWerk wil kunnen koppelen, biedt SSCIU een portaal aan, waarin kleine uitzenders hun factuur kunnen inkijken en downloaden. Echter, MedeWerk doet niet alleen zaken met het Ministerie, maar ook met een aantal andere klanten. Deze vragen steeds meer om elektronische afhandeling van facturen. MedeWerk is te klein om deze ontwikkeling zelf te volgen en besluit daarom gebruik te maken van de diensten van NotaBene, een BSP die zich specifiek richt op kleine bedrijven in de personele sector. NotaBene bedient haar klanten met een portaal waarin zij hun verkoopfactuurinformatie kunnen aanleveren (in geval van klassieke facturatie) of inzien (in geval van zelffacturatie). In het eerste geval is het NotaBene die namens de uitlener de factuur opstelt. NotaBene over-weegt momenteel om haar klanten ook te helpen bij het innen van uitstaande facturen.


Omdat beide partijen facturering hebben uitbesteed is hier sprake van “apart uitbesteed” in de factuurketen. Beide partijen besluiten ook de archivering van elektronische facturen over te laten aan hun respectievelijke dienstverlener. Dus, bij het Ministerie hebben de antwoorden op de vragen 3, 4 en 16 uit de ODMS de hoofdrol gespeeld in het besluit uit te besteden aan SSCIU. Voor MedeWerk gaven de antwoorden op vragen 1 en 3 de doorslag. De onderlinge confrontatie van deze keuze leverde geen problemen op: SSCIU en NotaBene kunnen elkaar prima bereiken met elektronische facturen.

5.2.2 Vraag 2: Communicatieproces

Omdat er twee BSP’s spelen in de factuurketen, zijn er drie communicatieketens. Menselijke tussenkomst is daarbij alleen aan de orde in de communicatieketen tussen NotaBene en MedeWerk. In diezelfde communicatieketen ligt het initiatief bij de ontvanger (halen), in de andere twee bij de zender (brengen). De feitelijke factuuroverdracht speelt tussen SSCIU en NotaBene. Om de authenticiteit van de verzender (SSCIU) en de integriteit van het factuurdocument te borgen, gebruiken zij een ge-avanceerde elektronische handtekening. Daartoe zetten zij een bescheiden certificateninfra-structuur op. Dat kan, omdat het aantal partijen beperkt is (SSCIU, grote uitleners en Nota-Bene) en de Nederlandse weten regelgeving relatief bescheiden eisen stelt aan deze infra-structuur. In het communicatieproces worden dus op bijna alle punten de basisopties uit het keuze-instrument gerealiseerd. Alleen op de schakel tussen NotaBene en MedeWerk worden de keuzes beperkt door de bescheiden automatiseringsgraad van MedeWerk: er is menselijke tussenkomst en MedeWerk moet de zelffacturen ophalen bij NotaBene. Omdat deze schakel buiten de feitelijke factuuroverdracht valt ─ die vindt immers plaats tussen SSCIU en NotaBene ─ levert dat geen bezwaren op van de Belastingdienst.

5.2.3 Vraag 3: Communicatieketen

Een aantal Ministeries en andere overheidsorganisaties maakt29 al gebruik de OTP voor factuur-verkeer met uitzendorganisaties. Omdat het met de oprichting van SSCIU niet een apart com-municatiekanaal voor de uitzendbranche wil openen, besluit SSCIU ook de OTP te gebruiken in haar communicatie met onder andere NotaBene. NotaBene wenst echter niet een e-mailserver van de OTP bij zich te laten installeren en besluit gebruik te maken van een collega-BSP, Zwerfkei, die deze voorziening wel heeft en als doorgeefluik fungeert. Er is hier dus sprake van “zender-uitbesteed” in de communicatieketen tussen SSCIU en NotaBene. Bovendien maakt NotaBene gebruik van roaming. Zwerfkei is zelf een BSP, maar treedt hier op als CSP. Zwerfkei laat dus de elektronische handtekening op de factuur intact. Deze keuzes komen niet overeen met de basisopties uit het keuze-instrument. Aan de over-heidszijde komt dat door dat de gekozen CSP (de OTP) al werd gebruikt voor verkeer naar ondernemingen. Verder bepaalde het beperkte bereik de keuze voor roaming via Zwerfkei. Figuur 9 toont de complexe relaties en de factuurroute in deze casus.

29 In deze fictieve casus.


Figuur 9 ─ De factuurroute in de tweede casus.

5.2.4 Vraag 4: Formaat

De uitzendbranche maakt in de stichting SETU30 eigen afspraken over elektronisch verkeer met haar klanten, inclusief een eigen factuurformaat (op basis van de internationale HR-XML-standaard31). Omdat SSCIU zich specifiek op inlenen van uitzendkrachten richt, besluit het dit formaat ook zelf toe te passen in de factuuroverdracht. Dit formaat is een elektronisch dataformaat. SSCIU en NotaBene hebben een uitwisselovereenkomst, waarin het formaat is geregeld. Het Ministerie kan, net als de andere partners in SSCIU, desgewenst een kopie van de door SSCIU opgestelde zelffactuur krijgen in een ander formaat, zoals UBL. SSCIU verzorgt daarvoor de formaattransformatie. Omdat deze transformatie geheel buiten de eigenlijk factuurover-dracht plaatsvindt, schept dit geen integriteitsproblemen32. SSCIU en NotaBene verzorgen beide formaatvalidatie op basis van het XML Schema-document van de SETU-factuurstandaard. Op de communicatieschakel tussen NotaBene en MedeWerk wordt gewerkt met een gegene-reerd PDF-document (elektronische tekst). MedeWerk heeft zelf namelijk geen systeem waar-mee het elektronische dataformaten zou kunnen lezen of verwerken. Vanwege het gebruik van de elektronische handtekening archiveren SSCIU en NotaBene de elektronische facturen in het SETU-formaat. Op de volgende punten wijken de keuzes dus af van de basisopties uit het keuze-instrument:

• Op de communicatieschakel tussen NotaBene en MedeWerk wordt een elektronisch tekstformaat (gegenereerde PDF) gebruikt, vanwege de beperkte automatiseringsgraad van MedeWerk.

• Er is sprake van formaattransformatie tussen het SETU- en het UBL-formaat (voor de factuurkopie), omdat betrokken partijen hun eigen formaten willen blijven hanteren. Deze transformatie vindt echter buiten de formele factuuroverdracht plaats.

Uitbesteding in de communicatieketen en roaming compliceert de routering. Vooral bij groot-schalige roaming moet gezocht worden naar een breed gedragen adresserings- en route-ringssystematiek. Zie hiervoor paragraaf 4.5.

30 www.setu.nl 31 www.hr-xml.org 32 Omdat hier persoonsinformatie ─ over de uitzendkracht ─ in de facturen staat, is de privacy mogelijk in het geding. Versleu-teling van de factuur kan voor de nodige confidentialiteit zorgen. Echter, transformaties door een derde zijn in dit geval niet meer mogelijk omdat deze de sleutel niet heeft om de factuur weer leesbaar te maken.


5.3 Overzicht

Tabel 9 ─ Overzicht van de keuzes in de casussen.

Hoofdvraag Deelvraag Gemeente Reggebroek en Enessuo

Ministerie van Publieke Zaken en MedeWerk

1a. Verwerking Direct Apart uitbesteed 1. Factuurketen

1b. Archivering Beide zelf Apart uitbesteed

2a. Menselijke tussenkomst Nee Alleen bij MedeWerk

2b. Initiatief Brengen NotaBene haalt bij MedeWerk; elders brengen

2. Communicatieproces

2c. Authenticiteit en integriteit “EDI” “digitale handte-kening”

3a. Hoofdvariant Direct Apart uitbesteed

3. Communicatieketen 3b. Roaming Nee Ja, tussen Nota-

Bene en Zwerfkei

4a. Communicatieformaat UBL 2.0 SETU-factuur-formaat

4b. Formaatvalidatie Ja Ja

4c. Formaattransformatie Nee Bij SSCIU 4. Formaat

4d. Archiveringsformaat Intern formaat, resp. UBL 2.0

SETU-factuur-formaat


6 Adviezen

Dit rapport is allereerst gericht op kopers en verkopers. De ervaringen bij het opstellen van dit rapport brengen ons niettemin tot het doen van enkele aanbevelingen aan de opdrachtgever. Op een aantal punten bevestigen en herhalen we daarmee aanbevelingen die al eerder ─ in nationale of Europese context ─ zijn gemaakt betreffende elektronisch factureren.

6.1 Ten aanzien van de pilots en de doorontwikkeling

Advies 1 Act small: Laat kopers en verkopers in de beoogde pilots hun eigen situationele keuzes maken, ook als dat niet direct tot een ideaal scenario leidt. Vaak weerhouden huidige processen en systemen een directe stap naar een ideale situatie. Een eerste bescheiden stap heeft een grotere kans op succes en zal vervolgstappen naar ambitieu-zere scenario’s aanwakkeren. Partijen kunnen dit rapport gebruiken bij het maken van situa-tionele keuzes. Daarbij kunnen ze bovendien eventuele BSP’s en CSP’s betrekken. Advies 2 Think big: Vraag van de pilotpartijen (ook) een langere-termijnvisie. Een kleine stap zetten is prima, als het langere-termijnperspectief maar in beeld is. Onder-steun desgevraagd de pilotpartijen met het formuleren daarvan, onder andere door als over-heid een implementatievisie en –roadmap op te stellen en te communiceren. Advies 3 Bevorder de structurele en gecoördineerde communicatie, voorlichting en kennisdeling. Streef op dit punt naar coördinatie op nationale schaal en combineer daarbij B2G, B2B en B2C. Vraag van pilotpartijen om hun ervaringen te delen met lotgenoten. Baseer de communicatie zoveel mogelijk op een gezamenlijk denkraam en gezamenlijke terminologie (zie Advies 5). Bevorder de open beschikbaarstelling van kennis en instrumenten aan kopers en verkopers. Advies 4 Vraag van overheidspartijen in de pilots om gebruik te maken van open standaarden, in lijn met de besluiten van het College Standaardisatie. Dat geldt natuurlijk voor het factuurformaat, maar ook voor technische communicatieproto-collen is het aan te bevelen te anticiperen op de keuzes die daar voor de OSB worden gemaakt.

6.2 Ten aanzien van algemene randvoorwaarden

Advies 5 Bevorder de totstandkoming van een gezamenlijk denkraam en terminologie. Er is veel verwarring over het onderwerp. Dit schept een onnodig ernstig beeld van de complexiteit, dat partijen kan afschrikken om de stap naar elektronisch factureren te maken.


Advies 6 Koers op een “beperkt aantal standaarden”-beleid. Het heterogene standaardenlandschap wordt vaak gezien als een belangrijk obstakel. Eén enkele standaard voor alle elektronische facturen zal echter niet haalbaar zijn, al is het maar vanwege de verschillende eisen die verschillende producten dienstensoorten met zich meebrengen. Het beperkte aantal standaarden moet gebaseerd zijn op een expliciet ei-senpakket aan het formaat. De elementen daarvan zijn op zijn minst grotendeels voorhan-den33. Advies 7 Bevorder roaming tussen BSP’s. Een groot bereik, onafhankelijk van specifieke dienstverlenerskeuzes is een belangrijke voor-waarde voor een grootschalige doorbraak van elektronisch factureren. Afgedwongen consoli-datie in die markt is haalbaar noch wenselijk. Roaming op basis van gestandaardiseerde roamingovereenkomsten en gestandaardiseerde routeringssystematieken, maar op basis van wederzijdse vrijwilligheid van betrokken BSP’s, is dat wel. Advies 8 Verduidelijk weten regelgeving en minimaliseer de compliancerisico’s. Onwetendheid over weten regelgeving op het gebied van authenticiteit en integriteit, en de precieze criteria voor goedkeuring door de Belastingdienst is een belangrijke drempel. Publi-ceer criteria en best practices. Bestrijdt met name de onduidelijkheid over de term “EDI” en maak duidelijk dat alleen de optie “andere middelen” vooraf instemming van de Belasting-dienst vereist. Zorg er in het bijzonder voor dat deelnemers in de voorgenomen pilots niet achteraf worden geconfronteerd met juridische bezwaren. Bevorder hergebruik van bestaande goedkeuringen als het concept herhaald wordt toegepast. Advies 9 Bevorder internationale harmonisatie van weten regelgeving. Zelfs kleine ondernemingen doen vaak al internationaal zaken.

6.3 Ten aanzien van de OTP, de NTP-infrastructuur en de OSB

Advies 10 Onderbouw de ambitie om de OTP, de NTP-infrastructuur en de OSB te gebruiken als basisinfrastructuur voor B2G-facturatie met een expliciete kosten-batenafweging. De huidige situatie van deze voorzieningen bemoeilijkt het grootschalig gebruik voor elektronisch factureren, vanwege onder andere:

• het huidige beperkte bereik binnen het overheidsdomein • het niet gekoppeld zijn van de OTP en NTP-infrastructuur enerzijds en de OSB

anderzijds • de adresseringssystematiek • de nog in ontwikkeling zijnde convergentie van de OTP en de NTP-infrastructuur

33 Zie hiervoor paragraaf 3.2.


Lijst van figuren

Figuur 1 — Afbakening van het onderzoek. ............................................................... 3 Figuur 2 — Klassieke facturatie (boven) en zelffacturatie (onder) in het B2G-veld................ 8 Figuur 3 — Afbakening....................................................................................... 10 Figuur 4 — Vijf ketenvarianten voor verwerking van elektronische factureren.................... 11 Figuur 5 — Factuuroverdracht in de factuurketen (rode, dikke pijlen). ............................ 12 Figuur 6 — Vijf hoofdvarianten voor de communicatieketen. ........................................ 18 Figuur 7 — Overzicht van het keuze-instrument. ....................................................... 28 Figuur 8 ─ Confronteren van uitbestedingsopties (voorbeeld). ...................................... 32 Figuur 9 ─ De factuurroute in de tweede casus......................................................... 50

Lijst van tabellen

Tabel 1 ─ Definities .......................................................................................... 4 Tabel 2 ─ Menselijke tussenkomst en initiatief. ........................................................ 14 Tabel 3 ─ Typische scenario’s. ............................................................................ 22 Tabel 4 ─ De Deense scenario’s. .......................................................................... 23 Tabel 5 ─ Verwerking van de wensen en eisen ......................................................... 26 Tabel 6 ─ Basisopties en beperkingen .................................................................... 29 Tabel 7 ─ ODMS voor elektronisch factureren........................................................... 31 Tabel 8 ─ Typische ODMS-antwoorden voor (elektronische) factuurverwerking. ................. 33 Tabel 9 ─ Overzicht van de keuzes in de casussen. .................................................... 51

Infrastructuur voor B2G e-factureren, een keuze-instrument voor kopers en verkopers

Business

Transcript of Infrastructuur voor B2G e-factureren, een keuze-instrument voor kopers en verkopers