Der vorliegende Artikel richtet sich an Vertreter öffentlicher Behörden, die mit der bevorstehenden Einführung von e-invoicing konfrontiert sind: Einkäufer, technische Dienste, die mit der Einführung von Systemen befasst sind oder jeden, der sich für die Problematik interessiert.

...

Rechtlicher Rahmen und Zusammenarbeitsvereinbarungen

e-invoicing

Die Richtlinie 2010/45/EU des Rates vom 13. Juli 2010 zur Änderung der Richtlinie 2006/112/EU bezüglich des gemeinsamen Mehrwertsteuersystems und der Fakturierungsregeln sorgte für eine Gleichstellung von Papierrechnungen und e-invoices in juristischer Hinsicht, sodass die Grundbedingungen für die Entwicklung von e-invoicing erfüllt sind. Diese Richtlinien wurden in belgisches Recht integriert.

Die Richtlinie 2014/55/EU vom 16. April 2014 schreibt die allen europäischen öffentlichen Behörden vor, eintreffende Rechnungen in einem elektronischen Format, das der europäischen Norm EN16931 (EN) entspricht, ab dem 19. April 2019 (nicht zentralen öffentlichen Behörden wird eventuell eine Frist von einem weiteren Jahr eingeräumt) zu erhalten und zu verarbeiten.   Diese Maßnahme entspricht der e-Invoicing-Strategie des belgischen öffentlichen Sektors. Die zugrundeliegende Strategie zielt eindeutig darauf ab, den Staat als Einkäufer als Hebel für die Entwicklung von Lösungsangeboten und die Ausstattung von öffentlichen und privaten Austauschpartnern zu nutzen. Natürlich muss dafür gesorgt werden, dass die Lösungen, mit denen sich Rechnungen an Verwaltungen verschicken lassen, auch für das e-invoicing an Privatkunden verwendbar sind.

...

Bestimmungen zur Regelung des Datenaustauschs innerhalb öffentlicher Behörden (Gesetz vom 25. August 2012 (NL), KB vom 7. Oktober 2013 (FR-NL). Diese Bestimmungen gelten für den internen Informationsfluss in öffentlichen Behörden und in der Folge der Entwicklung des e-invoicing.

...

Ströme und Komponenten

Reihenfolge

Erklärung: FAS Federal Authentication Service (NL) (zur Authentifizierung von Personen beim Zugang zu Mercurius-Leistungen))

Vorher: Der Lieferant hat in seinem eigenen Buchhaltungssystem eine Rechnung vorbereitet Schritte: Der Lieferant versendet die e-invoice über PEPPOL. Siehe auch Schritt 1: Der Lieferant sendet seine Rechnung an den Kunden Mercurius legt die e-invoice im Posteingang des Kunden ab. Siehe auch Schritt 2: Mercurius nimmt die Rechnung entgegen (für den Kunden) Der Kunde fordert den über seinen Integrator zugänglichen Mercurius-Dienst auf, seine eingegangene Post zu entnehmen. Siehe auch Schritt 4: Der Kunde öffnet seine E-Mail Der Integrator greift auf Mercurius zu, entnimmt die e-invoice für den Kunden und übermittelt sie ihm. Resultat: Die e-invoice wird dem Kunden übermittelt. Sie wird dem Posteingang des Kunden in Mercurius entnommen. Sie bleibt im Mercurius-Portal sichtbar Anmerkungen: 5: Der Lieferant, der Kunde und alle am Austausch beteiligten Vermittler können das Fortschreiten der Übertragung über das Mercurius-Portal jederzeit kontrollieren 1a: Der Lieferant, der nicht in der Lage ist, seine e-invoice auf PEPPOL zu übermitteln, kann sie im Mercurius-Portal eingeben (sofern es sich um eine einigermaßen simple Rechnung handelt) 1b: Der Lieferant, der an der Pilotphase teilgenommen hat und noch nicht in der Lage ist, seine e-invoice über PEPPOL zu übermitteln, kann seine Rechnung über die Pilot-Schnittstelle (vorübergehend) übermitteln 3c: Der Kunde ist noch nicht in der Lage, e-invoices zu empfangen. In diesem Fall wandelt Mercurius die e-invoice in ein PDF-Dokument um und übermittelt dieses an eine vorher in der Konfiguration festgehaltene E-Mail-Adresse. Siehe unten (PDF-Konverter) Die Abholung aus dem Posteingang über den Mercurius-Dienst erfordert 3 Aktivitäten (inbox request, retrieve document, mark document).  Siehe unten.

...

Bemerkungen
(* )  Syntax: UBL 2.0
(**) Zusätzliche Erläuterungen:

• Dieser Dokumenttyp erlaubt die Abholung der Anhänge von Rechnungen und Gutschriften (Empfangsprotokoll, allgemeine Bedingungen usw.) in Form einer separaten und nicht unbedingt strukturierten Datei (PDF, Excel oder jedes andere Dateiformat).
• Aus historischen Gründen extrahiert Mercurius diese Dateien aus dem PEPPOL BIS Dokument, in dem sie enthalten waren (Base64Encoding), übermittelt sie dann und verknüpft sie mit separaten XML-Dokumenten (des Typs AttachedDocument), unter Angabe der ID des übergeordneten Dokuments. Weitere Informationen  entnehmen Sie bitte (a) dem xsd dieses Dokumenttyps und der FAQ zum Thema attachedDocument (TODO: diese FAQ produzieren)
• Die Übertragung der eigentlichen Dateien erfolgt mittels des Protokolls SOAP with Attachment.

(***) Die Versender übermitteln die Dokumente entsprechend diesen Formatspezifikationen. Diese Spezifikation verwendet die Syntax UBL2.1. Aus historischen Gründen wandelt Mercurius sie in UBL2.0 um. Abgesehen von dieser Konversion führt Mercurius keinerlei Umwandlung durch. Diese Formatspezifikationsdokumente definieren also die jeweilige Semantik dieser Dokumente. Weitere Informationen bezüglich des Interoperabilitätsrahmens PEPPOL sind auf folgender Seite zu finden: offizielle Seite der Belgian PEPPOL Authority (nur in englischer Sprache verfügbar).

b. Versand einer Antwort

...

Anmerkung 
(* ) Aus historischen Gründen unterliegt die Abfassung der Antwort einer internen Spezifikation und nicht der PEPPOL BIS Spezifikation, wie dies bei den eingehenden Strömen der Fall ist. Mercurius wandelt die vom Kunden übermittelte Antwort in ein Dokument um, das der anwendbaren PEPPOL-Spezifikation entspricht, d.h. PEPPOL BIS 36A Message Level Response (EN). Dies wird auf der für den privaten Sektor bestimmten Seite näher erläutert.

...

Mercurius umfasst eine Komponente, die jedes (eintreffende UND abgehende) Dokument aus Business-Sicht validiert. D.h., dass bestimmte Merkmale des Inhalts des Dokuments kontrolliert werden. Wenn einer dieser Inhalte gegen diese Validierungsregeln verstößt, weist Mercurius das Dokument im Namen des eigentlichen Empfängers ab. Der Empfänger wird nicht über diese Ablehnung informiert. Der Versender dagegen erhält eine Antwort, in der er über die Abweisung und den Grund informiert wird (die Generierung des Antwortdokuments erfolgt nach den Modalitäten, die im Paragraphen „b. Versand einer Antwort" des Abschnitts Mercurius Web-Service beschrieben werden.

Folgende Kontrollen werden durchgeführt:

...

(* ) Diese Abweisung ist durch buchhalterische Verpflichtungen gerechtfertigt, denen die Ausstellung einer Rechnung in ordnungsgemäßer Form unterliegt.

Anmerkung: Das Mercurius-Portal bietet allen Portalbenutzern, die befugt sind, auf das Dokument zuzugreifen, die Möglichkeit, die Abweisung festzustellen und den Grund zur Kenntnis zu nehmen. Weitere Informationen zum Thema Mercurius-Portal finden Sie auf der Seite Mercurius Portal hilfe.

...

Falls der Kunde das Dokument reaktivieren möchte, kann er mittels des Formulars Hilfeanfrage eine Anfrage an das Mercurius Support Team richten (siehe unten, Abschnitt „Support")

Anmerkung: zusätzlich zur Warn-E-Mail bietet das Mercurius-Portal allen Portalbenutzern, die befugt sind, auf das Dokument zuzugreifen, die Möglichkeit, den Ablauf des Dokuments festzustellen. Weitere Informationen zum Thema Mercurius-Portal finden Sie auf der Seite Mercurius-Portal Hilfe.

...

Um e-invoices auf Mercurius empfangen zu können, muss sich der Kunde vorab auf Mercurius registrieren. Nach dieser Registrierung wird ein „Posteingang" angelegt". Diese Registrierung erfordert die Verwendung einer Benutzeridentifizierung. In der Regel identifiziert sich der Kunde mittels seiner Registernummer in der Zentralen Datenbank der Unternehmen. Beispiel: SPF BOSA: 0671.516.647.

Ein Kunde, der keine eigene Unternehmensnummer hat, kann sich mittels einer anderen Benutzeridentifizierung identifizieren. Derzeit wird die GLN-Nummer verwendet. Die Übermittlung dieser Identifizierung erfolgt auf seine Kosten.

...

Die Funktion von Mercurius geht mit zweierlei betrieblichen Aktivitäten einher: (a) support day to day und (b) Begleitung der Kunden bei ihrem e-invoicing-Projekt
In beiden Fällen müssen, wenn keine besonderen Umstände vorliegen, Support-Anfragen unter Verwendung des Hilfeformulars übermittelt werden, dass auf der Startseite des Mercurius-Portals  zu finden ist (direkte Adresse: Hilfeanfrage).

Normaler Support

Der Support ist wie folgt organisiert:

1. Sehen Sie sich zunächst die auf diesen Seiten veröffentlichten Informationen an. BOSA DTO hat viele Stunden Arbeit investiert, um diese Informationsdatenbank zu sammeln, zu strukturieren, zu organisieren und zu übersetzen. Ihre Frage wird sehr wahrscheinlich an irgendeiner Stelle behandelt.
2. Falls Sie die Antwort nicht gefunden haben, füllen Sie eine Hilfeanfrage aus. Es wird dringend empfohlen, sich zu identifizieren, so können bestimmte Informationen bereits eingetragen werden, was (1) Ihnen die Arbeit erleichtert und (2) die Möglichkeit bietet, die wesentlichen Daten für einen effizienten und hochwertigen Support zu sammeln.
3. Unser Service Desk nimmt Ihre Anfrage entgegen. Unser Service Desk bearbeitet nur häufig gestellte Fragen. Wenn Sie die Online-Dokumentation zur Kenntnis genommen haben, ist es unwahrscheinlich, dass die Mitarbeiter in der Lage sind, Ihnen zu helfen. In diesem Fall leiten Sie Ihre Anfrage an das Mercurius Support Team weiter.
4. Dort wird ihre Frage/Ihr Antrag auf der Grundlage der spezifischen Kenntnisse und der Kontakte mit allen am e-invoicing Beteiligten bearbeitet.

...

1. Verständnis der Datenströme, der Operationen, die sie ermöglichen und Abstimmung mit dem eigenen System zum Empfang von Rechnungen.
2. Einleitung von Entwicklungen, die die Integration des Buchführungssystems in Mercurius erlauben.
3. Parallel dazu
   1. Konfiguration der Integrationsumgebung des Integrators: Kontaktaufnahme mit dem Integrator und Erhalt des Zugangs zum Mercurius-Dienst in der Test-/Integrationsumgebung. Siehe auch Abschnitt „Integratoren"
   2. Konfiguration eines (oder mehrerer) Kunden in der TEST-Umgebung von Mercurius: Der Verantwortliche muss eine Anfrage über das Formular Hilfeanfrage übermitteln und (1°) die Unternehmensnummer(n ) und Bezeichnungen und (2°) den Common Name (CN) des Zertifikats des Systems, das den FSB erfordert, angeben. (eine Anmerkung für die anderen Integratoren hinzufügen, da dies keinen Sinn für ihre Kunden ergibt)
4. Sobald die Entwicklungen ausreichend fortgeschritten und die oben genannten Konfigurationen aktiviert sind, können die Online-Tests durchgeführt werden.
   1. Für weitere Informationen über die Testumgebung und die Testtools verwenden Sie bitte das Support-Anfrageformular.
   2. Mercurius ist so ausgestattet, dass die Partner Tests sehr autonom durchführen können, darunter auch End-to-End-Tests mit den Pilot-Lieferanten. Eine spezifische Aktivität seitens DTO ist daher in dieser Phase nicht vorgesehen. Selbstverständlich bearbeitet das Mercurius Support Team die in diesem Rahmen eingegangenen Support-Anfragen. BOSA DTO kann bei Bedarf auch an der Ausarbeitung dieser Aktivitäten teilnehmen, beispielsweise, um die Funktion der verfügbaren Instrumente zu erläutern.
5. Sobald die Resultate der Online-Tests zufriedenstellend sind, kann das GO-LIVE stattfinden. Es impliziert in der Regel (a) eine Konfiguration der Produktionsumgebung des Integrators und (b) eine Konfiguration der Produktionsumgebung von Mercurius. Diese beiden Konfigurationen erfolgen nach dem Muster der oben beschriebenen Schritte 3a und 3b.

...

Die Reflexionsgruppe (siehe auch oben, Benutzergruppen, Reflexionsgruppen) dient als Plattform für die Erfassung des Bedarfs von Institutionen, für die Priorisierung von Anfragen und zur Vermittlung der Roadmap der Entwicklung von Mercurius.

...

Der FSB veröffentlicht eine allgemeine Beschreibung seiner Aufgaben, Dienstleistungen, Verfahren, FAQ und Support-Modalitäten auf folgender Seite:

Administrative Modalitäten

...

1. Generierung eines Zertifikats: Dieser Schritt erfordert die Verwendung eines Tools zur Generierung eines Zertifikats (auf Kosten der technischen Abteilung des Antragstellers). In administrativer Hinsicht muss ein klassisches administratives Verfahren befolgt werden, das die Möglichkeit bietet, das Zertifikat mit Gewissheit mit dem Rechtssubjekt zu verbinden, das es zur Identifizierung verwenden wird. Dieses Verfahren ist hier dokumentiert: Ich beantrage ein Zertifikat als FSB-Verbraucher (NL)
2. Beantragung eines Zugangs:
   1. Einleitende Bemerkungen:
      1. Die Beantragung eines Zugangs erfolgt über die Einreichung eines Technical Connection Request Form
      2. Wie beschrieben, ist keine administrative Autorisierung (AARF) erforderlich
      3. Der Name des Dienstes lautet  e-InvoicingServices/CustomerService V2.00
      4. Selbstverständlich ist es notwendig, den Zugang im Rahmen der INTEGRATION zu beantragen, da ein Entwicklungs- und Testzyklus erforderlich ist
      5. Verbindungsdaten: nicht anwendbar: der Dienst ist synchron.
      6. Zertifikat: Sobald die Zertifikate (Integration und Produktion) generiert sind, übermitteln Sie den Common Name (CN) im TCRF.
   2.  Link zum Verfahren:  Ich beantrage den Zugang zu einem existierenden FSB Web-Service (NL)

ENGLISH [Expand]
Requestors must perform two parallel actions: (1) generate a certificate and (2) request access to the service 

1. Generate certificate: using the certificates generation procedure and tool (free of charges) 
   1. Preamble: this is a quite standard security procedure, using the services of a subcontractor (QuoVadis). Customer has to generate the ad-hoc security artefacts (keystore,  keys and Certificate Signing request(CSR)), and  upload the CSR to the self-service site for certificates generation; then he can download the certificate afterwards. However, to access this self-service site, he first needs to go through a procedure that identities him as the representative of the organization/person he is requesting a digital certificate for. This requires filling in and signing forms, involving the legal representative of the involved organization. More details in the procedure description.
   2. Procedure: 
      • Ik vraag een FSB consumer certificaat aan
      • fr
2. Request access to the service: 
   1. Remarks over TCRF fill in process: 
      • There is no administrative access request involved, so no AARF info to fill in
      • Name of the service:  e-InvoicingServices/CustomerService V2.00
      • securedEchoService [nb: all consumers have default access on this service. This service is important to test the FSB connectivity in a first phase. Therefore we recommend to start your integration works using this service. Use the business service only afterwards]
      • connection data: the service is synchronous so you don't have to fill in the Response information
      • certificate: please mention the certificate Common Name (CN) that you defined in the certificate generation procedure (see section "generate certificate")
   2. Procedure:
      • nl
      • Je demande d'accéder à un service web FSB existant

b) andere öffentliche Auftraggeber

...

Für die Flämische Region/Gemeinschaft spielt die Plattform MAGDA (MAximale GegevensDeling tussen Administraties) die Rolle des regionalen Integrators.
Die folgenden Informationen sind auf der Website von Magda verfügbar:

• Homepage (NL)
• Anschlussprozess MAGDA-Dienste (gilt auch für Mercurius) (NL)
• Kontaktformular MAGDA - allgemeine Fragen (NL)
• technische Dokumentation (Magda - Allgemein) (NL)

Region Brüssel

In der Region Brüssel übernimmt ISR/FIDUS die Aufgabe des regionalen Integrators. Alle Informationen über den Zugang zu Mercurius für diese Zuständigkeitsebene finden Sie auf folgender Seite: FIDUS homepage (FR)      FIDUS homepage (NL)

Wallonische Region und FWB

In der Wallonischen Region  übernimmt  BCED die Rolle des regionalen Integrators. Derzeit bietet BCED die Mercurius-Dienste noch nicht an. Bitte wenden Sie sich an Ihren Ansprechpartner bei BCED, gegebenenfalls über Ihre IT-Abteilung.