Plan van aanpak om te komen tot best-practic e-factureren via of webservices.

Transcriptie

1 Plan van aanpak om te komen tot best-practic e-factureren via of webservices. Versie 0.1 datum: door:jelle Attema Versie 0.2 datum: door: Jelle Attema Achtergrond. Elektronisch factureren, het maken, verzenden, ontvangen en verwerken elektronische facturen draagt bij aan de vermindering van economische transactiekosten: de faalkosten worden aanzienlijk verminderd wanneer facturen zonder menselijke tussenkomst worden gegenereerd uit een administratie, en kunnen worden verzonden, ontvangen en vervolgens verwerkt (en betaald) in de administratie van de ontvangende partij. Voor organisaties die veel facturen verzenden vormen de vermindering van faalkosten en optimalisatie van interne processen belangrijke drijfveren om te investeren in e-factureren. Voor bedrijven die weinig facturen versturen zijn faalkosten in absolute zin laag zijn: is er vaak geen directe business-case voor partijen om te investeren in e-factureren. Bovendien ontbreekt in deze bedrijven vaak de (technisch, fiscale en juridische) kennis. Fred van Blommestein en Gerard Bottemanne hebben daarom in 2010 in opdracht van het ministerie van EL&I en ECP-EPN een inventarisatie gemaakt van laagdrempelige vormen van e-factureren, die ook voor deze weinig-factureerders interessant kunnen zijn. Twee vormen van e-factureren werden onderzocht: e- factureren via en met hulp van web-services. Opgemerkt moet worden dat weinig-factureerders niet samen vallen met klein-mkb of kleine bedragen: ook grote bedrijven, sturen voor grote, langjarige projecten soms alleen een eind-factuur naar de opdrachtgever en investeren niet in koppelingen tussen de verschillende administratieve systemen. In dat onderzoek werd aan softwareleveranciers van administratieve software en dienstverleners op het gebied van e-factureren gevraagd of zij deze vormen van e-factureren ondersteunden en hun behoefte om afspraken te maken over het verzenden en ontvangen/verwerken van e-facturen via deze kanalen. Uit het onderzoek kwamen het volgende naar voren: 1. E-Factureren per wordt vaak wel ondersteund, maar het automatisch verwerken van gestructureerde factuurberichten nauwelijks. Ook ontbreken vaak basale controlemechanismen waardoor de verzender geen zekerheid heeft of een factuur goed is ontvangen, is geaccepteerd en/of verwerkt. Het rapport inventariseerde de punten waar afspraken over gemaakt moeten worden om e-factureren per bij te laten dragen aan het verminderen van faalkosten (zie bijlage I). 2. E-Factureren via webservices wordt door een flink aantal partijen ondersteund. De vorm van de webservices is echter erg divers. Belangrijk is dat de verschillen op den duur convergeren. Voor de hand liggende oplossingen zijn het beschrijven van webservices die breed worden gebruikt: bijvoorbeeld van Logius, banken en PEPPOL. Ook deze webservices verschillen echter onderling (zie bijlage II). Op basis van deze conclusies is geconcludeerd dat het belangrijk is 1

2 een breed gedragen best-practice te formuleren voor factureren via , die in overeenstemming is met CEN e-invoicing compliance guidelines en softwareleveranciers en ondernemers die willen beginnen met e-factureren een richting kan geven. Voor factureren via web-services de beschikbare open componenten te documenteren, die softwareleveranciers en ondernemers kunnen gebruiken om e-factureren met hulp van webservices te faciliteren. Plan van aanpak e-factureren per Doel: Door het documenteren van een breed gedragen best practice e-factureren per duidelijkheid bevorderen voor welke bedrijven en onder welke omstandigheden e-factureren per een optie kan zijn, welke risico s er aan zijn verbonden en hoe elementaire vormen van veiligheid en controle kunnen worden toegevoegd aan e-factureren per . Activiteit Wanneer Wie Op basis van de landkaart e-factureren en de daarin Q Fred van Blommestein geïnventariseerde punten een best-practice e-factureren beschrijven. Daarin worden voorstellen gedaan om de gesignaleerde problemen (zie bijlage I) op te lossen. Uit de leden van het Forum e-factureren, leden Kennisplatform Administratieve Software en de respondenten Q2/Q Jelle Attema/Gerard Bottemanne: die hebben aangegeven dat ze mee willen werken in een dergelijke werkgroep, wordt een werkgroep samengesteld die het concept best-practice becommentarieert. Ook de Belastingdienst wordt gevraagd om commentaar In september 2012 wordt de best-practice ingebracht in het Kennisplatform Administratieve Software. Q Jelle Attema/Gerard Bottemanne In okt.2012 wordt de best-practice gepubliceerd op e- factureren.info en wellicht gecommuniceerd naar het Europese Forum e-factureren Q Voorzitter forum e-factureren, Jelle Attema Plan van aanpak e-factureren via web-services Doel: versnellen van het inbouwen van web-services voor e-factureren in administratieve software door het benoemen van een geïmplementeerde op open standaarden gebaseerde web-service, bijvoorkeur op basis van publiek beschikbare software componenten en testomgeving. Activiteit Wanneer Wie Op basis van de documentatie voor implementatie van webservices voor e-factureren voor de Digipoort, banken en PEPPOL vergelijken en komen tot voorstel voor één webservice, die geïmplementeerd is, vrij toegankelijke opensource componenten heeft en kan worden getest (zie bijlage II voor de aandachtspunten) Q Fred van Blommestein 2

3 Per Inventariseren van commentaar op de voorgestelde webservice door meeleesgroep samengesteld uit respondenten die hebben meegedaan aan de landkaart efacturen, leden van het kennisplatform Administratieve Software en leden van het Forum e-factureren. In nov.2012 wordt de best-practice gepubliceerd op e- factureren.info en wellicht gecommuniceerd naar het Europese Forum e-factureren Q3/Q Jelle Attema/Gerard Bottemanne: bijeenkomst november Kennisplatform administratieve software Q Voorzitter forum e-factureren, Jelle Attema, 3

4 Bijlage I: voorbeelden van vragen e-factureren per Afspraken rond e-factureren per hebben betrekking op volgende onderwerpen: Hoe wordt een elektronische factuur verpakt in een bericht? Komt het bericht in de body of wordt het als attachment toegevoegd? Hoe wordt het bericht geëncodeerd? Wat komt er in de subjectregel te staan? Hoe en waar wordt aangegeven wat de structuur van de factuur is (bv. UBL, GS1)? Hoe wordt omgegaan met adressering? Hoe worden spam, spookfacturen en spoofing tegengegaan? Wordt voor elektronische handelsdocumenten een aparte mailbox ingesteld? Moet er een aparte mailbox komen per type document? Ontvangstbevestiging: wordt de ontvangst van iedere factuur bevestigd? Gebeurt dat d.m.v. voorzieningen in het protocol of gaat het buiten het protocol om? Binnen hoeveel tijd wordt de ontvangstbevestiging gestuurd? Als er geen ontvangstbevestiging wordt ontvangen, wanneer en hoe vaak wordt dan een factuur herzonden? Hoe wordt dat aangegeven? Indien een factuur wordt betwist, hoe wordt dat dan gecommuniceerd? Gelden de afspraken ook voor creditnota s? Hoe wordt een factuur voorzien van een elektronische handtekening? Hoe wordt de factuur eventueel versleuteld? Hoe worden certificaten gecontroleerd door de ontvanger? Hoe kan een audit-trail worden vastgelegd? Wat en hoe wordt er gearchiveerd? Hoe kunnen gearchiveerde facturen en processtappen later worden gecontroleerd? Afspraken: op welke wijze kunnen partijen met elkaar afspreken dat zij elektronische facturen per gaan uitwisselen? Moeten afspraakberichten gestructureerd worden zodat die kunnen worden verwerkt in het softwarepakket? Wat moet er in zo n afspraakbericht worden geregeld? Hoe kan het profiel praktisch worden ingesteld in populaire omgevingen? Hoe verloopt de communicatie tussen softwarepakket en omgeving? Hoe wordt omgegaan met intermediairs en BSPs? Bijlage II: voorbeelden van vragen factureren met web-services Openstaande vragen e-factureren via web-services Is de Digipoort specificatie van Logius in principe ook bruikbaar voor B2B berichtenverkeer? 4

5 Moeten voor B2B verkeer vereenvoudigingen worden aangebracht of opties worden gespecificeerd? Hoe wordt aangegeven welk format de factuur heeft? Is het nodig dat handelspartijen beide zowel webservice-clients als webservice-servers inrichten? Hoe moet een webservice voor factuurverkeer ingericht worden? Welke software is daar voor nodig? Welke parameters moeten worden ingesteld? Hoe moet het certificaat- en sleutelbeheer worden ingericht? Welk niveau van certificaten en handtekeningen is vereist? Hoe komt een nieuwe e-factureringsrelatie tot stand? Welke afspraken moeten bilateraal worden gemaakt? Hoe? Hoe wordt er getest? Indien een factuur wordt betwist, hoe wordt dat dan gecommuniceerd? Worden ook creditnota s via de webservice uitgewisseld? Wat gebeurt er wanneer een factuur tijdelijk even niet ontvangen kan worden (server down, andere storingen?) Hoe kan een audit-trail worden vastgelegd? Wat en hoe wordt er gearchiveerd? Hoe kunnen gearchiveerde facturen en processtappen later worden gecontroleerd? Indien de webservice (of de client) door een BSP wordt gerund, hoe vindt dan adressering plaats? Hoe wordt webservice-software gekoppeld aan het bedrijfssysteem? Hoe wordt het beheer georganiseerd? PM Begroting 5