Dit artikel richt zich tot de vertegenwoordigers van de privésector die verantwoordelijk zijn voor de verzending van facturen naar Belgische overheidsinstellingen of betrokken zijn bij dergelijke projecten. Het gaat bijvoorbeeld om facturatieverantwoordelijken, IT-teams die financiële departementen ondersteunen, externe IT-dienstverleners en/of softwareleveranciers of iedereen betrokken bij uitgaande e-facturatie.

...

Wettelijke achtergrond

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. Daarmee werden de voorwaarden gecreëerd voor de bredere toepassing van e-facturatie.

Richtlijn 2014/55/EU van het Europees Parlement en de Raad van 16 april 2014 verplicht alle Europese overheidsdiensten elektronische facturen, die voldoen aan de Europese Norm EN16931, te aanvaarden en te verwerken. Dit wordt momenteel omgezet in de Belgische wetgeving..

...

De oplossing van de Belgische overheidssector om e-facturen van hun leveranciers te ontvangen, een oplossing die gebaseerd is op PEPPOL Peppol en Mercurius, werd ontworpen om de kosten op lange termijn voor de verzenders te minimaliseren. Op korte termijn is het niet onmogelijk dat verzenders kosten zullen hebben wegens het gebrek aan concurrentie op de markt met oplossingen of wegens tekortkomingen veroorzaakt door problemen die verband houden met onvoldoende ontwikkelde toepassingen, veeleer dan dat het gaat om werkelijke en niet-samendrukbare kosten. Men dient rekening te houden met de volgende aspecten:

...

Stromen en componenten

Het artikel De levenscyclus van een e-factuur aan de Belgische overheidssector legt de stromen uit bij de verwerking van een e-factuur. Dit hoofdstuk geeft meer details bij deze omschrijving, vanuit het standpunt van de privésector (business).  Het (a) legt de gegevensstromen uit die verband houden met het uitwisselen van diensten m.b.t. e-facturen en de componenten die nodig zijn om de stroom operationeel te maken, (b) geeft een technische inleiding tot deze componenten en (c) kadert de beslissende rol van een netwerk van dienstverleners, toegangspunten en software-oplossingen die handelen in deze context. De voornaamste stromen zijn (1) een e-factuur (of e-creditnota) verzenden en (2) een antwoord ontvangen.
Gedetailleerde informatie over specifieke aspecten m.b.t. de overheidssector kunt u vinden op Mercurius voor de overheidssector.

...

...

...

Een formaat behelst twee basisaspecten: (a) de semantiek: het document bestaat uit informatie-elementen die op een dergelijke manier worden omschreven dat interpretatiefouten uitgesloten worden; (b) de syntaxis: deze gemeenschappelijke informatie-elementen worden vertaald in een syntaxis, een voorstelling van gegevens, die een IT-systeem kan lezen/schrijven/begrijpen. 
In 2011 heeft een beperkte maar representatieve groep actoren uit diverse milieus besloten om verschillende workshops te houden met als doel te komen tot een set sectoroverschrijdende en grensoverschrijdende formaten voor de meeste procurementdocumenten (catalogus, bestelling, antwoord op de bestelling, het verzenden van advies, factuur, creditnota, etc.). De CEN BII workshops (EN) hebben de CEN Business Interoperability Interface (BII) WorkGroup Agreements (WGA) opgeleverd, waar de CEN BII-formaten Peppol deel van uitmaken.

Ondertussen werden de CEN BII-reeksen hergebruikt door veel praktische eProcurement-oplossingen, in het bijzonder door (a) het ePRIOR-platform ontwikkeld door de Europese Commissie en (b) de PEPPOL Peppol Business Interoperability Specification (BIS). PEPPOL Peppol BIS vervult de rol van "gemeenschappelijk noemer-formaat", wat betekent dat als twee correspondenten geen gemeenschappelijk formaat kunnen identificeren om documenten uit te wisselen, ze "terugvallen" op het gebruik van PEPPOL BIS.

Tijdens een pilootfase (2013-14) waarin het ePRIOR-platform werd gebruikt, afgestemd op de Belgische context, valideerde de Belgische overheidssector dat de CEN BII documenttypes voor facturen en creditnota's, al hun specifieke informatienoden dekte.

Toen het PEPPOLPeppol -interoperabiliteitskader werd aangenomen waren er geen specifieke businessnoden die de ondersteuning van een ander formaat dan dat van de gemeenschappelijke noemer - BIS - rechtvaardigden.

...

Uiteraard zal de Belgische overheidssector, ingevolge Richtlijn 2014/55/EU zijn systemen upgraden om ook de Europese Norm EN16931 (EN) te ondersteunen in de nabije toekomst. Merk daarbij op dat de EN 16931-vereisten ook een afstemming met CEN BII inhouden. Anders gezegd, het EN 16931-ontwerp integreert de migratie van CEN BII voor e-facturen en e-creditnota's.

...

Zoals aangehaald hierboven ondersteund de Belgische overheidssector de volgende formaten: PEPPOL Peppol BIS voor e-facturen en PEPPOL Peppol BIS voor e-creditnota's. De volgende tabel is een samenvatting van de technische informatie die vereist is om documenten zo voor te bereiden dat ze gegarandeerd ontvangen kunnen worden door de Belgische overheidssector (maar, uiteraard, die niet noodzakelijk goedkeuren).

De Belgische overheidssector volgt nog steeds strikt PEPPOL Peppol BIS. Alle documenten die aan BIS voldoen worden gegarandeerd ontvangen.

...

In een correct geïmplementeerde operationele interactie voor e-facturatie verzendt de klant een antwoord naar de leverancier. Het PEPPOLPeppol -kader biedt nog geen geschikt documenttype, waarmee bedoeld wordt een formaat dat werd ontworpen om business responses te verzenden. Het Invoice Response-formaat zou heel binnenkort beschikbaar moeten worden. In tussentijd biedt PEPPOL Peppol een ander formaat aan, de Message Level Response (MLR). Dit formaat werd ontworpen om technische feedback te verzenden, maar kan worden gebruikt als alternatieve oplossing om business responses te verzenden. De Belgische overheidssector gebruikt deze alternatieve oplossing. Zodra het Invoice Response-formaat beschikbaar is, zal de Belgische overheid een scenario opstellen om de migratie zo vlot mogelijk te laten verlopen.

...

Opmerkingen:

• Om de business response te ontvangen zoals hierboven uitgelegd, moet de verzender van de e-factuur hebben verklaard dat hij in staat is MLR te ontvangen in de PEPPOL Peppol Transport Infrastructure. Zie de volgende afdeling.
• Message Level Response (MLR) is niet verplicht. De afdeling "Bijzondere scenario's" bevat ook aanvullende nuttige gedetailleerde informatie over de inhoud van de MLR.

...

...

Het enige wat u nodig hebt om e-documenten te verzenden via PEPPOL Peppol is een Access Point (AP). Zoals geïllustreerd werd in het hoofdstuk Typische stroom van een e-factuur B2G hierboven, verloopt het verzenden van een e-document via PEPPOL Peppol zoals "een enveloppe in de postbus stoppen". Het enige wat u nodig hebt, is toegang tot een AP dat fungeert als een postbus.

...

Een van de sleutelaspecten van het PEPPOLPeppol -interoperabiliteitskader is dat u de technische details van elke ontvanger niet hoeft te kennen om in staat te zijn e-documenten te verzenden. Hoe is dat mogelijk?  PEPPOL Peppol heeft een register (* ) dat altijd actief is waarin alle bedrijven die e-documenten ontvangen worden geregistreerd. Dat register bevat twee types informatie (a) waar de e-documenten naartoe moeten worden verzonden - dat is eigenlijk het adres van het AP van de ontvanger (waarbij het "postsysteem" moet aangeven welke route het e-document moet volgen) - en (b) welk formaat moet worden gebruikt: alle ontvangers moeten alle formaten aangeven die ze kunnen ondersteunen (en dus lezen), zodat alle verzenders kunnen zien welk formaat kan worden gebruikt. Omdat alle deelnemers altijd in staat moeten zijn om BIS te verwerken is het onmogelijk dat twee deelnemers niet op zijn minst 1 gemeenschappelijk formaat vinden.

...

De bovenstaande omschrijving stemt overeen met de PEPPOL Peppol BIS 36A Message Level Response (EN).

Bijzondere scenario's

Anchor
bijzonderescenarios bijzonderescenarios

Deze afdeling gaat over verschillende bijzondere operationele en technische scenario's en legt uit hoe Mercurius daarmee omgaat.

Niet-naleving van het

...

Peppol BIS-formaat

Elke e-factuur die in overeenstemming wordt geacht met het PEPPOL Peppol BIS-formaat, maar die de formatievalidatiestap niet doorstaat, wordt "gefilterd" door een component die is geïnstalleerd tussen de PEPPOL AP en Mercurius. Leveranciers (e-factuurafzenders) en hun IT-onderaannemers moeten er daarom voor zorgen dat alleen e-facturen die aan het PEPPOL Peppol BIS-formaat voldoen, worden verzonden.
Deze bepaling komt voort uit de volgende overwegingen:

• In de sectie Documentformaten kunnen leveranciers (of hun IT-onderaannemers) de documentformaatvereisten kennen die overheden aankunnen.
• In een context van wijdverbreide e-facturering is naleving van deze vereisten essentieel.
• Het PEPPOLPeppol -kader, dat de belangrijkste technische referentie vormt voor ons veralgemeningsprogramma voor e-facturering, pleit voor een bewezen aanpak die leidt tot de implementatie van hoogwaardige, op formaten gebaseerde stromen. Met name,
  • het PEPPOL Peppol BIS-formaat, het formaat dat wordt ondersteund door de Belgische publieke sector, is uitgerust met validatietools op basis van een veel gebruikte technologie (schematron), waardoor het mogelijk wordt de besturingselementen voor de conformiteit van het formaat te automatiseren.
  • standaardcontracten die exploitanten binden, verbieden de overdracht van niet-conforme documenten in het formaat dat zij geacht worden te respecteren. Niets verplicht de geadresseerde om dergelijke documenten te lezen.
• Daarom wordt elke e-factuur die geacht wordt in overeenstemming te zijn met het PEPPOL Peppol BIS-formaat maar die de formatievalidatiestap niet doorstaat, "gefilterd" door een component geïnstalleerd tussen de PEPPOL AP en Mercurius.
• afzenders (of hun IT-onderaannemers) kunnen de validatie van hun e-facturen volledig automatiseren VOORDAT ze worden verzonden, met behulp van dezelfde validatiehulpmiddelen als het bovenstaande filter, aangezien deze hulpmiddelen openbaar en kosteloos worden verspreid.
• Ten slotte is de Mercurius-Portal uitgerust met een online opzoekprogramma voor testberichten: de afzender (of zijn IT-onderaannemer) kan de e-factuur via PEPPOL Peppol verzenden in de testomgeving en vervolgens online controleren. als het bericht is aangekomen en niet is bedorven door een fout. deze tool vermijdt spreidingsfouten in de feitelijke facturatiestromen.

...

Business response: de leverancier ondersteunt

...

Peppol BIS MLR niet - zie diagram, sequentie 3a

Zoals uitgelegd in de vorige afdeling zal de leverancier het elektronische antwoord alleen ontvangen als hij heeft geregistreerd dat hij in staat is PEPPOL Peppol MLR te ontvangen. Als dat (nog) niet het geval is, dan zal (zoals stroom 3a in het diagram hierboven illustreert) Mercurius een alternatieve bezorgingsmethode voorzien: via e-mail. Mercurius zal in de oorspronkelijke e-factuur zoeken naar het e-mailadres van de leverancier en zal de antwoordinformatie van de MLR naar dit e-mailadres verzenden, in een formaat dat door mensen gelezen kan worden. Het e-mailadres wordt uit het volgende UBL-gegevenselement van de e-factuur gehaald:

...

Als dit gegevenselement leeg is (of niet vermeld) in de oorspronkelijke e-factuur, dan kan er ook geen e-mail worden gestuurd. De enige manier waarop de leverancier het antwoord dan kan verifiëren, is door verificatie op het Mercuriusportaal. Voor meer informatie over het Mercuriusportaal kunt u de volgende pagina raadplegen: Mercuriusportaal hulppagina.

...

Voor leveranciers zou deze Mercuriusdienst niet belangrijk moeten zijn. De ervaring leert echter dat veel leveranciers niet voldoen aan de business rules die worden geverifieerd tijdens deze validatie. Daarom moeten, in de praktijk, veel leveranciers in de toekomst toegang hebben tot deze informatie.

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 hulppagina.

...

• moet de verzendende AP opzoeken wat de ontvanger allemaal in staat is te ontvangen door gebruik te maken van de SMK in plaats van de SML.
  • SML staat voor Service Metadata Locator. Het is het gecentraliseerde systeem dat AP's die opzoeken wat de ontvanger allemaal in staat is te ontvangen omleidt naar de SMP van de ontvanger (zie ook "E-documenten verzenden/ontvangen - belangrijke informatie" hierboven).
  • de SMK is het alter ego van de SML, in de testinfrastructuur.
  • alle instellingen van de overheidssector worden geïdentificeerd met exact dezelfde identifiers in de echte omgeving (productie) en in de testomgeving. Dat gebeurt om het risico op verwarring van identificatienummers te minimaliseren.
• om snel de status van de verzending in de testomgeving te controleren is de volgende online tool beschikbaar via de homepagina van Mercurius: Test document opzoeken.
• op elk ogenblik kunt u ook alle ontvangen verkeer verifiëren, zowel in test als in productie, door het Mercuriusportaal te gebruiken. Voor meer gedetailleerde instructies over het gebruik van het Mercuriusportaal kunt u terecht op de pagina Mercuriusportaal hulppagina.

...

Vertegenwoordigers van de IT-sector kunnen tools gebruiken die beschikbaar zijn op het web om hun systemen te valideren. Er zijn veel tools online beschikbaar voor de validering van verschillende formaten en versies. Deze tools valideren het PEPPOL Peppol BIS-formaat, niet de inhoud ervan. Er wordt echter sterk aanbevolen de mogelijkheid om e-documenten in een geldig formaat te produceren apart te valideren, afzonderlijk van de inhoudelijke aspecten.

De sector van de IT-dienstverleners kan ook het Mercuriusportaal gebruiken om alle verkeer met Mercurius op te sporen en te volgen, dankzij de eGOV-rol "Mercurius_AP". Dit is van toepassing op het verkeer in zowel test als productie. Meer informatie hierover is beschikbaar in de procedure voor onboarding die wordt omschreven in de afdeling Access Points van de officiële pagina van de Belgische PEPPOLPeppol -autoriteit (EN). Deze pagina bevat ook veel nuttige informatie voor de IT-sector m.b.t. het uitvoeren van testactiviteiten en andere doeleinden.

Voor meer gedetailleerde instructies over het gebruik van het Mercuriusportaal kunt u tot slot ook terecht op de pagina Mercuriusportaal hulppagina.

...

Er wordt ook informatie voorzien om hen te helpen vertrouwd te geraken met het PEPPOLPeppol -interoperabiliteitskader. Deze assistentie is echter beperkt tot gemeenschappelijke kennis. De overheid heeft niet de opdracht geavanceerde technische ondersteuning te bieden aan personen die PEPPOL-oplossingen opzetten of in de handel brengen.

De overheid biedt wel bijkomende technische ondersteuning aan bedrijven uit de IT-sector die hun producten integreren met Mercurius via PEPPOLPeppol . Dit houdt ook het raadplegen en registreren van de ontvangstcapaciteiten in op smp.belgium.be (EN).

Organisatie

Voorafgaande opmerking voor leveranciers

...

Als de e-factuur Mercurius niet heeft bereikt, dan zal er zich in de meeste situaties een probleem stellen met de verlener van uw IT-oplossing of Access Point (AP) (intern of extern) en moet dit met hem worden besproken (bv. ongeldig PEPPOL Peppol BIS formaat).

Nu dit verduidelijkt is, volgt hierna een omschrijving van de voorzieningen inzake assistentie en ondersteuning die de overheid levert.

1. Lees eerst de beschikbare informatie. BOSA DTO heeft vele uren werk geïnvesteerd in het verzamelen, structureren, organiseren en vertalen van de informatiedatabase. Het is heel waarschijnlijk dat uw vraag ergens wordt behandeld.
2. Als u het antwoord op uw vraag niet kunt vinden, dan vult u de aanvraag tot ondersteuning in.
   1. Die is ook beschikbaar op de homepagina van het Mercuriusportaal.
   2. We moedigen aan dat u zich identificeert op deze pagina zodat kostbare informatie kan worden verzameld die (1) uw taak gemakkelijker maakt en (2) toelaat essentiële informatie te verzamelen over rollenmanagement om de ondersteuning te vergemakkelijken en deze ondersteuning naar een hoger niveau te tillen.
3. Onze centrale service desk zal verzekeren dat de aanvraag tot ondersteuning correct geïdentificeerd wordt in de tool voor de follow-up van ondersteuning en uw aanvraag zo snel mogelijk behandelen. Zij zijn echter alleen verantwoordelijk voor het behandelen van frequent gestelde vragen. Als u niet vond wat u zocht in onze uitgebreide kennisdatabase, dan is het waarschijnlijk dat zij u niet zullen kunnen helpen. In dat geval wordt uw aanvraag overgemaakt aan het Mercurius Support Team.
4. Het Mercurius Support Team zal uw vraag beantwoorden en uw probleem behandelen. Het Mercurius Support Team behandelt alle aanvragen tot ondersteuning die overblijven. Zij zorgen voor de verdere analyse van het geval, valideren of het binnen de reikwijdte van de dienst valt en verzekeren dat het probleem tijdig wordt aangepakt en opgelost, of welk intern of extern team daar moet bij betrokken worden.