Peppol im Abrechnungssystem: Access Point, Teilnehmer-ID, Zustellung
Peppol wird oft mit einem Rechnungsformat verwechselt. Es ist ein Netz zur Zustellung von Geschäftsdokumenten, mit festen Regeln dafür, wer senden darf, wie Empfänger gefunden werden und welche Dokumenttypen unterwegs sind. Die Rechnung selbst bleibt eine EN-16931-Rechnung. Peppol klärt, wie sie ankommt.
Für ein SaaS-Unternehmen stellen sich drei Fragen: Brauchen wir Peppol überhaupt? Werden wir selbst Teil des Netzes oder beauftragen wir einen Dienstleister? Und was muss unser Billing speichern, damit Zustellung und Status nachvollziehbar bleiben?
Wie das Netz funktioniert: vier Ecken, zwei Access Points
Peppol arbeitet nach dem Vier-Ecken-Modell. Ihr Billing-System (Ecke 1) übergibt die Rechnung an Ihren Access Point (Ecke 2). Dieser sucht den Access Point des Empfängers (Ecke 3) und überträgt die Rechnung dorthin. Von dort gelangt sie in das System des Kunden (Ecke 4). Sie brauchen also keine Verbindung zu jedem Kunden, sondern genau einen Access Point.
Woher weiß Ihr Access Point, wohin er senden soll? Jeder Empfänger ist im Netz mit einer Teilnehmer-ID registriert. Ein Service Metadata Publisher (SMP) hält fest, welcher Access Point für diese ID zuständig ist und welche Dokumenttypen der Teilnehmer empfangen kann. Vor jeder Übertragung fragt der sendende Access Point diese Daten ab.
Betrieben werden Access Points und SMPs von zertifizierten Dienstleistern. Das Netz wird von OpenPeppol verwaltet; in vielen Ländern überwacht eine nationale Peppol Authority die Regeln. In Deutschland ist das laut dem Länderprofil von OpenPeppol die KoSIT, die auch XRechnung pflegt.
Wann Sie Peppol brauchen
Der häufigste Anlass in Deutschland ist der öffentliche Sektor. Nach dem Länderprofil hat der IT-Planungsrat beschlossen, dass jede öffentliche Stelle, die elektronische Rechnungen annimmt, über Peppol erreichbar sein muss. Für die Adressierung brauchen Sie dort zwei Angaben: die Peppol-ID und zusätzlich die Leitweg-ID für das interne Routing. Die Leitweg-ID teilt Ihnen die empfangende Stelle mit.
Im deutschen B2B-Geschäft schreibt das Gesetz keinen Übertragungsweg vor. Eine E-Rechnung darf per E-Mail, Schnittstelle oder Portal kommen, solange beide Seiten sich einigen. Peppol ist dort eine Option. Interessant wird sie, wenn größere Kunden ihren Rechnungseingang auf Peppol umstellen und Rechnungen per E-Mail nur noch widerwillig annehmen.
Grenzüberschreitend gewinnt Peppol an Gewicht. Mehrere europäische Länder nutzen das Netz bereits für Rechnungen an Behörden, und mit dem ViDA-Paket wird die E-Rechnung im innergemeinschaftlichen B2B-Geschäft ab dem 1. Juli 2030 Pflicht. Wer heute Zustellkanäle pro Kunde verwaltet, ergänzt dann einen Kanal und baut nicht das Rechnungsmodell um.
Eine einfache Regel: Haben Sie öffentliche Kunden oder Kunden, die Peppol ausdrücklich verlangen, binden Sie es an. Sonst genügt vorerst eine E-Rechnung per E-Mail, und die Peppol-Anbindung steht auf der Roadmap.
Eigener Access Point oder Dienstleister
Einen eigenen Access Point zu betreiben, setzt eine Mitgliedschaft bei OpenPeppol, eine Vereinbarung als Service Provider, Tests im Netz und den laufenden Betrieb unter den Anforderungen der Peppol Authority voraus. Für ein Softwareunternehmen, dessen Produkt nicht die Rechnungszustellung ist, lohnt sich das selten.
Der übliche Weg ist ein zertifizierter Dienstleister, dessen API Sie aus dem Billing ansprechen. Prüfen Sie bei der Auswahl:
- Ob Sie das XML selbst erzeugen und der Dienstleister es nur transportiert, oder ob er aus Ihren Daten konvertiert. Mit eigener Erzeugung bleibt die Rechnung in Ihrem System die führende Fassung.
- Ob er die Teilnehmersuche vorab als eigene API anbietet, sodass Sie vor dem Versand wissen, ob ein Kunde erreichbar ist.
- Welche Statusmeldungen er per Webhook zurückgibt und wie lange er Übertragungsnachweise aufbewahrt.
- Ob er Sie als Empfänger registrieren kann, falls Lieferanten Ihnen künftig über Peppol schicken.
Was Ihr Billing über Teilnehmer speichern muss
Eine Teilnehmer-ID besteht aus einem Schema und einem Wert, etwa einem Schema für Umsatzsteuer-Identifikationsnummern oder dem für Leitweg-IDs. Die zulässigen Schemata stehen in der EAS-Codeliste der Peppol BIS Billing 3.0. Speichern Sie beide Teile getrennt und nicht als zusammengesetzten Text. Dieselben Angaben gehören als elektronische Adresse von Käufer und Verkäufer in die Rechnung selbst.
customer_delivery_profile
channel: peppol | email | portal
peppol_participant: { scheme, value }
buyer_reference: "<Leitweg-ID, bei Behörden>"
last_lookup: { checked_at, found, document_types }
valid_from, valid_to
Vor dem Versand prüfen Sie, ob der Teilnehmer gefunden wird und ob er den Dokumenttyp empfangen kann. Daraus ergeben sich drei Fälle:
| Ergebnis der Abfrage | Was das Billing tut |
|---|---|
| Teilnehmer gefunden, Dokumenttyp unterstützt | senden, Status submitted |
| Teilnehmer gefunden, Dokumenttyp nicht unterstützt | nicht senden, vereinbarten Ersatzkanal nutzen, Kunde informieren |
| Teilnehmer nicht gefunden | Rechnung anhalten, ID und Schema mit dem Kunden klären |
Ein häufiger Fehler: Die Teilnehmer-ID wird mit dem falschen Schema hinterlegt, etwa die USt-IdNr. unter einem Schema für Handelsregisternummern. Die Abfrage findet nichts, obwohl der Kunde registriert ist. Lassen Sie sich die ID deshalb vom Kunden genau so geben, wie sie im Netz registriert ist.
Zustellstatus: übermittelt ist nicht angenommen
Die Bestätigung, die Ihr Access Point nach der Übertragung erhält, besagt nur, dass der Access Point des Empfängers die Nachricht angenommen hat. Ob der Kunde die Rechnung verarbeitet, ist damit nicht gesagt. Fachliche Rückmeldungen wie Annahme oder Ablehnung gibt es in Peppol als eigene Nachrichten. Laut Länderprofil plant die KoSIT, die Message Level Response verpflichtend zu machen. Heute können Sie sich nicht darauf verlassen, dass jeder Empfänger antwortet.
Für das Statusmodell bedeutet das: submitted (an den eigenen Access Point übergeben), delivered (beim Access Point des Empfängers angekommen), optional accepted oder rejected, wenn eine fachliche Antwort kommt. Das Zahlungsziel hängt in Ihrem System an der Zustellung, nicht am Erzeugen der Datei. Eine Rechnung, die etwa nach 48 Stunden noch auf submitted steht, gehört in eine Warteschlange, die jemand ansieht.
Der Inhalt muss vor dem Versand stimmen. Peppol transportiert, was Sie übergeben. Wie Sie XRechnungen vor dem Versand prüfen, beschreibt der Beitrag zur XRechnung-Validierung, welche Felder eine SaaS-Rechnung braucht, der Beitrag zu XRechnung für SaaS-Rechnungen.
Was Sie vor der Anbindung klären
- Welche Kunden verlangen Peppol heute, und welche Teilnehmer-IDs haben sie? Bei Behörden zusätzlich: Leitweg-ID.
- Erzeugen Sie die XRechnung oder Peppol-BIS-Rechnung selbst, und wird sie vor der Übergabe validiert?
- Welcher Dienstleister, welche Statusmeldungen, welche Aufbewahrung der Übertragungsnachweise?
- Gibt es im Billing ein Zustellprofil pro Kunde mit Kanal, Schema, ID und Gültigkeitszeitraum?
- Gibt es eigene Status für
submitted,deliveredundrejected, und sieht jemand die hängenden Rechnungen?
Kontier erzeugt die XRechnung aus denselben versionierten Preis- und Steuerdaten wie PDF und Buchung; welche Kanäle angebunden sind, steht unter Integrationen.
Kein Steuer- oder Rechtsrat. Dieser Beitrag beschreibt die Rechtslage und Praxis allgemein. Für Ihren Einzelfall fragen Sie Ihre Steuerberatung. Stand: