Dit artikel richt zich tot de vertegenwoordigers van de overheidsdiensten die worden geconfronteerd met de uitvoering van binnenkomende e-facturatie: inkoopverantwoordelijken, technische diensten belast met de implementatie van systemen, of elke andere betrokken partij bij deze problematiek.
Zoals werd uitgelegd in de Strategie voor elektronische facturatie van de Belgische overheidssector biedt het Mercuriusplatform een gecentraliseerde elektronische mailroomdienst voor de gezamenlijke Belgische overheid, in het kader van de e-facturatie B2G.
Dit artikel is een vervolg op de omschrijving van het Mercuriusplatform vanuit het standpunt van de overheidssector, ontvanger van deze e-facturen.
Het beperkt zich tot de voornaamste elementen (algemene omschrijving, voornaamste stromen, procedure voor de toetreding, etc.) en de elementen die eigen zijn aan de overheid. Specifieke problemen worden besproken in aparte artikels. Daarnaast worden ook de aspecten die eigen zijn aan de privésector, of die ermee gemeenschappelijk zijn, apart behandeld (bv. gebruik van het Mercuriusportaal). Referenties naar deze verwante artikels, alsook naar andere nuttige informatiebronnen, worden op de gepaste plaatsen in dit artikel ingelast.
Het artikel bestaat uit de volgende afdelingen:
De Ministerraad heeft in december 2012 beslist (a) om de Europese strategie te ondersteunen die erop gericht is van elektronische facturatie de meest verspreide wijze van factureren te maken in Europa tegen 2020, en (b) om in dit kader de FOD Budget en Beheer, het Agentschap voor Administratieve Vereenvoudiging, Fedict en de FOD Financiën de opdracht te geven om samen de pilootfase voor e-facturatie en e-scanning B2G te leiden. Fedict heeft het opzetten van het uitwisselingsplatform Mercurius op zich genomen, ter harmonisering van de interface tussen de overheidssector en de privésector, om te vermijden dat de leveranciers (en de overheidsdiensten) worden geconfronteerd met buitensporige verschillen in functie van de gesprekspartner.
Mercurius was toen uitsluitend gebaseerd op een oplossing ontwikkeld door de informaticadiensten van de Europese Commissie, ePRIOR.
Na afloop van de pilootfase werd Mercurius in overeenstemming gebracht met het interoperabiliteitskader PEPPOL. Door de afwezigheid van een dergelijk interoperabiliteitskader waren de overheidsdiensten (en hun leveranciers) immers genoodzaakt om de uitwisselingsvoorwaarden te onderhandelen in functie van de gesprekspartner, wat de uitvoering van e-facturatie op grote schaal uitsloot. PEPPOL lost dit probleem op, voor e-facturatie en meer algemeen voor e-procurement, ten aanzien van de overheidsdiensten en binnen de privésector.
Om het veld te verbreden voor de uitwisseling van documenten van overheidsdiensten met de privésector en te vergemakkelijken dat de Belgische overheidsdiensten in overeenstemming worden gebracht met de Europese norm wordt Mercurius op dit ogenblik herwerkt. De interface met de overheidsdiensten die niet werd gewijzigd sinds de pilootfase wordt nu aangepast om te voldoen aan de nieuwe noden.
Richtlijn 2010/45/EU van de Raad van 13 juli 2010 tot wijziging van Richtlijn 2006/112/EU betreffende het gemeenschappelijke stelsel van belasting over de toegevoegde waarde wat de factureringsregels betreft, heeft de papieren factuur en de e-factuur op juridisch vlak gelijkwaardig gemaakt, en daarmee de basisvoorwaarden gecreëerd voor de ontwikkeling van e-facturatie. De Belgische wet heeft deze Richtlijnen geïntegreerd.
Richtlijn 2014/55/EU van 16 april 2014 legt aan alle Europese overheidsdiensten op dat ze de binnenkomende facturen die voldoen aan de Europese norm EN16931 moeten ontvangen en verwerken in elektronische vorm vanaf 19 april 2019 (de niet-centrale overheidsdiensten kunnen eventueel een bijkomend jaar uitstel krijgen). Deze maatregel is coherent met de Strategie voor elektronische facturatie van de Belgische overheidssector. De strategie die hiervoor de basis vormt streeft er duidelijk naar de 'Overheid als inkoper' te gebruiken als hefboom voor de ontwikkeling van het aanbod aan oplossingen en de uitrusting van de uitwisselingspartners, zowel overheid als privé. Men moet er uiteraard over waken dat de oplossingen die toelaten e-facturen naar de overheidsdiensten te versturen herbruikbaar zijn voor e-facturatie naar privéklanten.
Deze richtlijn wordt op dit ogenblik omgezet in Belgisch recht.
Bepalingen regelen de uitwisseling van gegevens binnen de overheidsdiensten (wet van 15 augustus 2012, KB van 7 oktober 2013). Deze bepalingen zijn van toepassing op de interne informatiestromen binnen de overheidsdiensten en vloeien voort uit de ontwikkeling van e-facturatie.
De invoering van e-facturatie en de veralgemening ervan op nationaal grondgebied is geen eenvoudige stap. Het gaat veeleer om een geheel aan veranderingen en diverse processen. De confrontatie van standpunten en regelmatige uitwisseling maken het mogelijk tot een consensus te komen over een gemeenschappelijke en coherente aanpak. In dit kader, onder impuls van de Vlaamse overheid, werd een denkgroep ('de reflectiewerkgroep') opgericht. Deze structuur laat toe ervaringen te delen en zich ervan te verzekeren dat sleutelinformatie juist wordt overgebracht. Op dit ogenblik volstaat de denkgroep om deze rol te vervullen maar het is waarschijnlijk dat, nu de e-facturatie in opmars is, een stevigere structuur nodig is.
De werking van Mercurius doet twee uitgaven ontstaan: de prestaties van de onderaannemer aan wie het operationele aspect van het platform wordt toevertrouwd en de omkadering van deze onderaannemer.
De prestaties van de onderaannemer vloeien voort uit de uitvoering van een opdracht afgesloten door de opdrachtencentrale. Deze formule laat de cofinanciering van de operationele aspecten toe. Vandaag draagt BOSA DTO de gezamenlijke kosten voor de operationele aspecten. Op korte of lange termijn zullen deze kosten worden verdeeld over de instellingen die van de dienst gebruikmaken, a rato van verdeelsleutels die gebaseerd zullen zijn op de respectieve volumes. De details van deze verdeling moeten nog gedefinieerd worden.
BOSA DTO staat in voor de omkadering van de onderaannemer met zijn eigen budgetten (verwant personeel en verwante opdrachten, bv. tests die het risico op indringing en onttrekking moeten nagaan).
Het artikel De levenscyclus van een e-factuur aan de Belgische overheidssector omschrijft de stappen bij de verwerking van een e-factuur. Dit hoofdstuk vervolledigt die omschrijving, vanuit het standpunt van de overheidssector (* ). Ze (a) bespreekt in detail de informatiestromen die verband houden met de dienst voor het overmaken van e-facturen B2G, alsook de componenten die deze stromen toelaten, (b) geeft een technische inleiding tot deze componenten, en (c) kadert de rol van het netwerk van de dienstintegratoren, die een sleutelrol spelen in dit dossier. De stromen zijn: (1) ontvangst van een e-factuur (of e-creditnota) en (2) terugsturen van een antwoord.
(* ) de gedetailleerde voorstelling van de aspecten die eigen zijn aan de privésector wordt behandeld in het artikel Mercurius voor de privésector.
Stromen en componenten | Sequentie |
| Voorafgaand: de leverancier heeft een uitgaande factuur voorbereid in zijn eigen boekhoudsysteem Stappen:
Resultaat: de e-factuur wordt overgemaakt aan de klant. Ze wordt verwijderd uit de binnenkomende post van de klant op Mercurius. Ze blijft zichtbaar op het Mercuriusportaal. Opmerkingen: 1a: de leverancier die niet in staat is om zijn e-factuur over te maken op PEPPOL kan die ingeven op het Mercuriusportaal (voor zover het gaat om een redelijk eenvoudige factuur) 1b: de leverancier die heeft deelgenomen aan de pilootfase en die nog niet in staat is om zijn e-factuur met PEPPOL over te maken kan zijn e-factuur (tijdelijk) overmaken met de pilootinterface 3c: de klant is nog niet in staat om e-facturen te ontvangen. In dat geval zet Mercurius de e-factuur om in een pdf-document en maakt het die over aan een e-mailadres dat vooraf werd geregistreerd in de configuratie. Zie verder (Omzetten in pdf) |
Stromen en componenten | Sequentie |
Voorafgaand: de klant is overgegaan tot de goedkeuring (of verwerping) van de factuur in zijn eigen boekhoudsysteem. Stappen:
Resultaat: het antwoord is overgemaakt aan de leverancier. Opmerkingen: 5: De status van de e-factuur (ontvangen / goedgekeurd / verworpen) en de details van die status (motivering) kunnen geraadpleegd worden op het Mercuriusportaal. Op elk ogenblik kunnen de leverancier, de klant en alle actoren betrokken bij de uitwisseling er ook de voortgang controleren van het overmaken via het Mercuriusportaal. 1a: krachtens de akkoorden die de dienstintegrators binnen de overheidsdiensten regelen, richt elke aanbestedende overheidsdienst zich tot zijn referentie-integrator. Zie verder. 3a: de leverancier die zijn e-factuur via PEPPOL heeft verstuurd, is niet altijd in staat om het antwoord via PEPPOL te ontvangen. In dat geval stuurt Mercurius hem een antwoord via e-mail, volgens de modaliteiten die hierna worden omschreven: Stap 7: Mercurius stuurt het antwoord naar de leverancier. 3b/4b: de leverancier die heeft deelgenomen aan de pilootfase en die blijft gebruiken ontvangt zijn antwoord (tijdelijk) via die interface |
Zoals geïllustreerd in vorig hoofdstuk biedt Mercurius een dienst aan die de aanbestedende overheidsdiensten toelaat hun e-facturen (en e-creditnota's en bijlagen) volledig elektronisch te ontvangen, en de resultaten van de goedkeuring van deze documenten over te maken.
Deze afdeling omschrijft de kenmerken van deze dienst. In de praktijk wordt deze dienst aangeboden door de integratoren. Dit aspect zal verderop meer gedetailleerd worden behandeld in de afdeling "integratoren".
Tot slot vervolledigt een Portaal deze dienst, waarmee de vertegenwoordigers van de klant (en van de leverancier) de voortgang van het overmaken en de technische verwerking kunnen volgen. Dit aspect wordt behandeld in een afzonderlijke pagina.
SOAP ( XML over HTTPS ) + WS-Security
De pertinente bijkomende technische specificaties kunnen verschillen per integrator en zijn dus bij laatstgenoemde beschikbaar, zie ook de afdeling "integratoren".
Elke klant beschikt over een postvak voor binnenkomende post op Mercurius. Mercurius plaatst daar alle e-facturen, e-creditnota's en bijlagen m.b.t. deze documenten, naarmate ze binnenkomen. Om e-facturen op Mercurius te ontvangen moet men dus de klant registreren op Mercurius, waardoor voor hem een "postvak voor binnenkomende post" wordt aangemaakt. De afdeling "Ondersteuning en begeleiding" legt uit hoe de registratie van een nieuwe klant op Mercurius verloopt. Zodra de klant geregistreerd is, kan hij de dienst gebruiken. De dienst maakt het mogelijk (a) binnenkomende post binnen te halen en (b) antwoorden te versturen die het resultaat zijn van de verwerking van de e-facturen en e-creditnota's.
Post binnenhalen vereist 3 verrichtingen:
In een klassiek scenario voor het gebruik van Mercurius zal de klant dus op regelmatige tijdstippen een sequentie van deze verrichtingen programmeren. (1°) de lijst met de nieuwe documenten raadplegen, (2°) voor elk nieuw document, (a) het document binnenhalen en (b) de goede ontvangst bevestigen en toestemming geven om het document te verwijderen uit de lijst van documenten in de wachtrij.
De documenten die vandaag worden ondersteund zijn de volgende:
Document Type Naam | UBL DocumentTypeCode | syntax (XSD) | Semantic | Bijkomende informatie | |
1 | Factuur | 380 | Peppol BIS Invoice (**) | ||
2 | CreditNota | 81 | |||
3 | Bijlage (*) | 916 | N.A. (*) | FAQ toevoegen |
Opmerkingen
(* ) Bijkomende uitleg:
(**) De afzenders maken e-documenten over in overeenstemming met deze formaatspecificaties. Deze specificatie gebruikt de syntaxis UBL2.1. Om historische redenen zet Mercurius ze om in UBL2.0. Behalve deze omzetting voert Mercurius geen andere transformatie uit. Deze documenten voor formaatspecificatie definiëren dus wel degelijk de respectieve semantiek van deze documenten. Meer informatie over het interoperabiliteitskader PEPPOL is beschikbaar op de volgende pagina: officiële pagina van de Belgische PEPPOL-autoriteit (EN).
Deze actie vereist slechts een verrichting: submitApplicationResponse
Slechts 1 type document wordt op dit ogenblik ondersteund:
Document Type Naam | UBL DocumentTypeCode | XSD | Specificatie | |
1 | ApplicationResponse | 301 |
Opmerking
(* ) Om historische redenen is de opmaak van het antwoord onderworpen aan een interne specificatie, en niet aan de specificatie van PEPPOL BIS, zoals dat het geval is voor de binnenkomende stromen. Mercurius zet het antwoord overgemaakt door de klant om in een document dat in overeenstemming is met de toepasselijke PEPPOL-specificatie, d.w.z. PEPPOL BIS 36A Message Level Response (EN) Dit wordt meer gedetailleerd uitgelegd op de pagina over de privésector.
Dit hoofdstuk gaat dieper in op verschillende bijzondere gevallen en hoe die worden ondersteund door Mercurius.
Mercurius omvat een component die elk e-document valideert (binnenkomend EN uitgaand) vanuit het standpunt business, d.w.z. dat het bepaalde kenmerken controleert van de inhoud van het document. Als de inhoud ergens een inbreuk op deze valideringsregels bevat, dan verwerpt Mercurius het e-document in naam van de eindontvanger. De ontvanger wordt niet van deze verwerping op de hoogte gesteld. De afzender ontvangt wel een antwoord dat hem op de hoogte brengt van de verwerping en van de motivering daarvoor (de aanmaak van het antwoorddocument volgt de modaliteiten omschreven in paragraaf "b. Sturen van een antwoord" van de afdeling Mercurius webdienst.
De volgende controles worden uitgevoerd:
(* ) deze verwerping wordt gerechtvaardigd door de boekhoudkundige verplichtingen waaraan de uitgifte van een factuur volgens de regels van de kunst is onderworpen.
Opmerking: het Mercuriusportaal laat toe dat alle portaalgebruikers die toegang hebben tot het e-document deze verwerping kunnen vaststellen en kennis kunnen nemen van de motivering. Voor meer informatie over het Mercuriusportaal kunt u terecht op de pagina Mercuriusportaal hulp.
Mercurius omvat een component die een e-factuur in pdf-document omzet en die per e-mail overmaakt kan worden aan een vooraf geconfigureerd mailadres. Deze component werd toegevoegd met een dubbel doel:
In het geval dat een e-document niet werd binnengehaald door de ontvanger na 30 kalenderdagen zal het Mercuriusplatform:
In het geval dat de klant het e-document wil reactiveren kan hij een aanvraag daartoe richten tot het Mercurius Support Team via het formulier aanvraag tot assistentie (zie verder, afdeling "ondersteuning")
Opmerking: naast de waarschuwingsmail laat het Mercuriusportaal alle portaalgebruikers die toegang hebben tot het e-document ook toe vast te stellen dat het e-document vervallen is. Voor meer informatie over het Mercuriusportaal kunt u terecht op de pagina Mercuriusportaal hulp.
Het Mercuriusplatform bewaart de ontvangen e-documenten en alle boodschappen die ermee verband houden gedurende 24 maanden. Daarna worden de sporen ervan gewist. Het is echter altijd mogelijk om toegang te krijgen in geval van een audit bij een geschil dat zich voordoet na 24 maanden, op expliciete aanvraag.
Om e-facturen te ontvangen op Mercurius moet men zich vooraf als klant registreren op Mercurius. Deze registratie maakt een "postvak voor binnenkomende post" aan. Deze registratie vereist het gebruik van een identifier. Behoudens uitzonderingen identificeert de klant zich met zijn registratienummer in de Kruispuntbank van Ondernemingen. Voorbeeld: FOD BOSA: 0671.516.647.
De klant die geen eigen ondernemingsnummer heeft kan zich identificeren met een andere identifier. Op dit ogenblik wordt het GLN-nummer gebruikt. Het aanleveren van deze identifier gebeurt door de klant.
De werking van Mercurius levert twee types van operationele activiteiten op: (a) ondersteuning van dag tot dag en (b) begeleiding van de klanten bij hun e-facturatieproject.
In de 2 gevallen, en behoudens bijzondere omstandigheden, moeten de aanvragen tot ondersteuning worden overgemaakt door gebruik te maken van het assistentieformulier, gepubliceerd op de onthaalpagina van het Mercuriusportaal (rechtstreeks adres: aanvraag tot assistentie).
De ondersteuning wordt als volgt georganiseerd:
De inkoopverantwoordelijken en/of de informaticateams betrokken bij het invoeren van e-facturatie krijgen begeleiding bij hun project. Deze begeleiding kan meerdere aspecten dekken:
De begeleiding kan dus starten vóór de technische integratiefase, en zal ook daarna worden voortgezet.
Het invoeren van e-facturatie is niet louter een punctueel technisch project. Het moet veeleer worden gezien als een diepgaande transformatie van lange adem, waarschijnlijk met verschillende stappen. BOSA DTO voert een programma om de overheidsdiensten bewust te maken van deze problematiek. BOSA DTO is beschikbaar voor ontmoetingen om samen de context van de instelling (of instellingengroepering) te bestuderen, en deel te nemen aan de opmaak van de strategie of het actieplan van de instelling. Uiteraard blijft instelling soeverein bij het maken van haar analyse en nemen van haar beslissing. Het is echter erg belangrijk dat ze zo goed mogelijk wordt geïnformeerd. Omdat e-facturatie nog niet voldoende is ontwikkeld, is de informatie erover niet zo eenvoudig beschikbaar, spreken sommige elementen elkaar tegen en zijn die uiteindelijk onvoldoende. In het bijzonder de bijdrage van het PEPPOL-kader wordt ruim misbegrepen; op dezelfde manier worden bepaalde functies van het Mercuriusplatform soms slecht gebruikt omdat men de mogelijkheden ervan niet kent. Deze documentatie wil iets aan deze situatie doen, ter aanvulling van de ontmoetingen binnen de overheidsdiensten.
Samenvattend is de doelstelling van deze ontmoetingen dat de instelling een duidelijk zicht krijgt op de uitdagingen, op de oplossingen die binnen haar bereik liggen, en zo een actieplan kan opstellen. Als voorbeeld zou men op de volgende vragen een antwoord moeten krijgen:
Eens de beslissing is genomen om te integreren met het Mercuriusplatform wordt het technische project opgestart.
Parallel met het technische project, en om ervoor te zorgen dat de inspanningen daarvan lonen, is het essentieel dat de instelling een project ontwikkelt voor de sensibilisering van haar leveranciers voor het versturen van elektronische facturen. Op dit ogenblik bestaat er geen communicatiemodel dat voldoende generiek en herbruikbaar is om aan de instellingen te worden overgemaakt met het oog op hergebruik voor deze stap. BOSA DTO staat ter beschikking van de instellingen om ze te begeleiden bij hun communicatie-activiteiten.
Opmerkingen:
Na de integratie van de instelling met Mercurius zullen er uitbreidings- en optimalisatiefases geprogrammeerd worden naarmate er nieuwe noden en opportuniteiten komen. Op basis van deze verzamelde noden programmeert BOSA DTO de wijzigingen van Mercurius die toelaten er een antwoord op te bieden en voert ze uit. Deze verbeteringen worden vervolgens beschikbaar gemaakt voor de instellingen.
De denkgroep (zie ook hoger, Gebruikersgroepen, denkgroepen) dient als platform voor het verzamelen van de noden van de instellingen, om prioriteiten van de aanvragen vast te stellen, en de roadmap te communiceren met de evolutie van Mercurius.
Het bestaan van de testomgeving van Mercurius vergemakkelijkt de integratiewerken van nieuwe instellingen en nieuwe economische actoren (leveranciers), en de ontwikkeling van nieuwe functies. Deze omgeving, die permanent beschikbaar is, is volledig in overeenstemming met de productie-omgeving (met inbegrip van de identifiers van de correspondenten en de toegangsmachtigingen tot gegevens). Dit laat de correspondenten toe om hun systemen op punt te zetten, volledig geïsoleerd van de productiestromen. De communicatie van de praktische informatie m.b.t. de testomgeving is inbegrepen in de begeleiding van de integratieprojecten van de instellingen met Mercurius.
De systemen van de klanten hebben toegang tot de Mercuriusdienst door de tussenkomst van dienstintegratoren. In overeenstemming met de bepalingen die de uitwisseling van gegevens binnen overheidsdiensten regelen, worden de Mercuriusdiensten aangeboden door de federale en regionale dienstenintegratoren, ten behoeve van hun respectievelijke beleidsniveaus.
Zoals geïllustreerd in het diagram vervult de Federal Service Bus (FSB) een dubbele rol: (1°) enerzijds zorgt het voor de verbinding tussen het informaticasysteem Mercurius en het netwerk van de integratoren. In dat kader vervult het een reeks essentiële functies inzake veiligheid en performantie ; (2°) anderzijds biedt het de Mercuriusdienst aan voor de federale aanbestedende overheden en de derden-integratoren van diensten. Alleen de tweede rol zal worden uiteengezet in het kader van dit artikel.
De algemene bepalingen van de FSB (ondertekening van een gebruiksovereenkomst, openen van stromen, gebruik van een certificaat, rapportering, integratie-omgeving, ondersteuning, etc.) zijn ook van toepassing op de Mercuriusdienst.
De FSB heeft een algemene omschrijving van zijn opdrachten, diensten, procedures, FAQ's en ondersteuningsmodaliteiten gepubliceerd op de volgende pagina:
In dit kader, en gelet op het feit dat de Mercuriusdienst toegang geeft tot de facturen van de betrokken partij, bestaat de enige vereiste administratieve verificatie om toegang te krijgen tot de dienst via de FSB erin te verzekeren dat de aanvrager wel degelijk een rechtspersoon is die onder Belgisch publiekrecht valt op federaal niveau.
Om toegang te kunnen krijgen tot elke dienst die wordt aangeboden op de FSB zijn twee technisch-administratieve formaliteiten nodig: (1°) een certificaat genereren en overmaken en (2°) de toegang aanvragen aan de beoogde dienst(en)
Voor het Vlaams Gewest/de Vlaamse Gemeenschap vervult het platform MAGDA (MAximale GegevensDeling tussen Administraties) de rol van regionale integrator.
De volgende informatie is beschikbaar op de site van MAGDA:
In het Brussels Hoofdstedelijk Gewest vervult ISR/FIDUS de rol van regionale integrator. Voor alle informatie m.b.t. de toegang tot Mercurius voor dit beleidsniveau kunt u de volgende pagina raadplegen: FIDUS homepage NL: FIDUS homepage
In het Waals Gewest vervult BCED de rol van regionale integrator. Op dit ogenblik biedt BCED de diensten van Mercurius nog niet aan. Gelieve uw contactpersoon bij BCED te contacteren, of in voorkomend geval, uw informaticadienst.