Peppol ist mehr als ein Netzwerk für E-Rechnungen. Es ist ein Satz von Vereinbarungen darüber, welche Dokumente Sie austauschen, wie diese Dokumente aufgebaut sind, wie Sie den Empfänger identifizieren und wie Nachrichten sicher vom Absender zum Empfänger gelangen.

Sie entwickeln Software, die E-Rechnungen oder andere Beschaffungsdokumente versendet oder empfängt? Dann bestimmt dieses Wissen, welche Dokumenttypen Sie unterstützen, welche Validierungen Sie durchführen und ob Sie die Infrastruktur selbst aufbauen oder an einen Service Provider auslagern.

Dokumenttypen in Peppol

Jeder Dokumenttyp in Peppol ist in einer Peppol BIS-Spezifikation festgelegt. Eine BIS beschreibt, welche Felder Pflicht sind, welche Codelisten gelten und welchen Business Rules ein Dokument entsprechen muss. Alle Dokumente basieren auf der UBL-Syntax.

Rechnung (Invoice)

Das am häufigsten genutzte Dokument im Netzwerk, basierend auf Peppol BIS Billing 3.0 und damit auf der europäischen Norm EN 16931.

✓ Entspricht dem semantischen Modell der EN 16931
✓ Enthält Pflichtfelder für Umsatzsteuer, Parteien und Positionen
✓ Unterstützt Anhänge, etwa eine PDF-Darstellung

Gutschrift (Credit Note)

Schreibt eine zuvor versendete Rechnung ganz oder teilweise gut. Fällt ebenfalls unter Peppol BIS Billing 3.0.

✓ Eigener UBL-Dokumenttyp neben der Rechnung
✓ Verweist auf die ursprüngliche Rechnung
✓ Dieselben Validierungsregeln wie die Rechnung

Korrigierte Rechnung

Korrigiert eine zuvor versendete Rechnung. Ob dies zulässig ist oder eine Gutschrift vorgeschrieben ist, hängt von den nationalen Vorschriften ab.

✓ Fällt unter Peppol BIS Billing 3.0
✓ Verweist auf das ursprüngliche Dokument
✓ Nationale Vorschriften bestimmen die Verwendung

Bestellung und Auftragsbestätigung

Damit gibt ein Käufer eine Bestellung elektronisch auf. Der Lieferant nimmt sie an, lehnt sie ab oder ändert sie.

✓ Festgelegt in Peppol BIS-Spezifikationen für Ordering
✓ Bestellung und Antwort haben jeweils einen eigenen Dokumenttyp
✓ Schafft die Grundlage für den automatischen Abgleich mit der Rechnung

Lieferavis

Meldet vorab, was wann und in welcher Verpackung geliefert wird.

✓ Unterstützt Wareneingang und Lagerverwaltung
✓ Verweist auf die zugrunde liegende Bestellung
✓ Ermöglicht Three-Way-Matching (Bestellung, Lieferung, Rechnung)

Katalog

Teilt Produktinformationen und Preise zwischen Lieferant und Käufer.

✓ Enthält Artikel, Spezifikationen und Preise
✓ Optional mit einer Katalogantwort des Käufers
✓ Vermeidet die manuelle Erfassung von Artikeldaten

Message Level Response (MLR)

Eine technisch-inhaltliche Rückmeldung: Wurde die empfangene Nachricht korrekt verarbeitet oder abgelehnt?

✓ Meldet Validierungsfehler an den Absender zurück
✓ Betrifft die Nachricht, nicht den geschäftlichen Inhalt
✓ Nützlich für die Fehlerbehandlung in Ihrer Software

Invoice Response (IMR)

Eine geschäftliche Statusmeldung zu einer Rechnung: empfangen, in Bearbeitung, akzeptiert, abgelehnt oder bezahlt.

✓ Gibt dem Lieferanten Einblick in den Rechnungsstatus
✓ Reduziert Statusanfragen per E-Mail und Telefon
✓ Arbeitet mit standardisierten Statuscodes

Ein typischer Dokumentenprozess

Katalog: Der Lieferant teilt Artikel und Preise.
Bestellung: Der Käufer bestellt auf Basis des Katalogs.
Auftragsbestätigung: Der Lieferant nimmt die Bestellung an, ändert sie oder lehnt sie ab.
Lieferavis: Der Lieferant meldet, was geliefert wird.
Rechnung: Der Lieferant stellt die Rechnung. Der Käufer kann mit einer Invoice Response den Status zurückmelden.

Nicht jede Organisation nutzt den vollständigen Prozess. Viele Implementierungen beginnen mit der Rechnung und der Gutschrift und werden später um Ordering und Logistikdokumente erweitert.

PINT, das internationale Rechnungsmodell

PINT (Peppol International Invoice Model) ist ein ergänzendes Modell neben Peppol BIS Billing 3.0. BIS Billing 3.0 baut auf der europäischen Norm EN 16931 auf und geht von einem europäischen Mehrwertsteuersystem aus. Länder außerhalb Europas arbeiten oft mit anderen Steuersystemen, etwa GST oder SST. PINT macht Peppol auch für diese Länder nutzbar.

Basisspezifikation

Ein gemeinsamer Kern von Rechnungsfeldern, der für alle PINT-Varianten gilt.

Länderspezifische Erweiterungen

Zusätzliche Regeln je Land oder Region, zum Beispiel für Japan, Australien und Neuseeland, Singapur und Malaysia.

Interoperabel

Dieselbe Infrastruktur und dasselbe Transportprotokoll wie im übrigen Peppol-Netzwerk.

Identifier Schemes: wie Peppol einen Teilnehmer erkennt

Jeder Teilnehmer im Peppol-Netzwerk hat eine Peppol-ID, bestehend aus einer Scheme-ID aus der ISO 6523-Liste und einer Identifikationsnummer. Welche Scheme-IDs häufig vorkommen und wie Sie Ihre eigene Peppol-ID finden, lesen Sie unter Peppol-ID.

Validierung und Compliance

Ein Peppol-Dokument durchläuft zwei Validierungsebenen, bevor es als korrekt gilt.

Syntaktische Validierung

Prüfung der XML-Struktur gegen das XSD-Schema von UBL: Stimmt der Aufbau, stehen die Elemente an der richtigen Stelle und haben sie den richtigen Datentyp?

Schematron-Validierung

Prüfung der Business Rules: die Regeln aus der EN 16931, Peppol-spezifische Regeln und gegebenenfalls länderspezifische Regeln, etwa stimmige Summen und Pflichtfelder je nach Situation.

Länderspezifische Regeln sind zum Beispiel die NLCIUS (die niederländische CIUS) in den Niederlanden und XRechnung in Deutschland; in Belgien und Luxemburg ist Peppol BIS Billing 3.0 der Standard, in Frankreich läuft die E-Rechnungsstellung über plateformes agréées.

Mehr über das semantische Modell hinter der Peppol-Rechnung lesen Sie unter Was ist die EN 16931?. Wie sich die verschiedenen Rechnungsformate zueinander verhalten, lesen Sie auf der Seite Rechnungsformate.

Der technische Kern des Peppol-Netzwerks

In der Peppol-Architektur sind Absender und Empfänger jeweils über einen Access Point angebunden. Die Access Points tauschen die Nachrichten untereinander aus. Wer einen Access Point hat, kann jeden Teilnehmer im Netzwerk erreichen, unabhängig davon, welchen Service Provider dieser Teilnehmer nutzt.

Access Point und AS4

Versendet und empfängt Nachrichten über das AS4-Protokoll. Validiert Nachrichten, leitet sie an den richtigen empfangenden Access Point weiter und verarbeitet technische Empfangsbestätigungen.

SMP (Service Metadata Publisher)

Legt für jeden Teilnehmer fest, welche Dokumenttypen er empfangen kann und über welchen Access Point. Ein Absender fragt den SMP des Empfängers ab, bevor er eine Nachricht versendet.

SML (Service Metadata Locator)

Das zentrale, DNS-basierte Register des Netzwerks. Verweist für jede Peppol-ID auf den richtigen SMP, sodass jeder Access Point den Empfänger ohne zentralen Nachrichten-Hub findet.

PKI und Zertifikate

Alle Access Points und SMPs verwenden X.509v3-Zertifikate innerhalb des Peppol-PKI-Frameworks, mit mindestens SHA-256. Der Zertifikatsstatus wird über OCSP geprüft. Zertifikate haben eine begrenzte Gültigkeitsdauer und müssen regelmäßig erneuert werden.

Peppol Directory

Ein öffentlich durchsuchbares Verzeichnis der Teilnehmer im Netzwerk. Sie suchen nach Name oder Peppol-ID und sehen, welche Dokumenttypen eine Organisation unterstützt.

Peppol standardisiert den Verkehr zwischen Access Points. Die Anbindung zwischen Ihrer Software und einem Access Point ist ausdrücklich nicht standardisiert: Jeder Service Provider bietet dafür eine eigene API, meist für den Versand von Dokumenten, Statusabfragen, Validierung und die Suche nach Teilnehmern in SMP und Directory.

Betreiben Sie selbst einen Access Point? Dann sollten Sie operative Anforderungen berücksichtigen, etwa verschlüsselte Verbindungen über TLS 1.2 oder höher, hohe Verfügbarkeit, Monitoring, Protokollierung für Audits und rechtzeitige Zertifikatserneuerung. Technisch genügt eine moderne, unterstützte Laufzeitumgebung, zum Beispiel Java oder .NET.

Was das für Sie als Softwareanbieter bedeutet: selbst entwickeln oder auslagern?

Wenn Sie Peppol in Ihrer Software unterstützen möchten, wählen Sie zwischen einem eigenen Access Point mit SMP und einer Anbindung an einen Service Provider. Ein eigener Access Point bietet volle Kontrolle, aber Sie sind dann selbst für alle nachstehenden Punkte verantwortlich. Ein Service Provider übernimmt diese Aufgaben.

Beitritt und Verträge

Der formelle Beitritt bei der Peppol Authority und die damit verbundenen Pflichten.

Zertifikatsverwaltung

Beantragen, Installieren und regelmäßiges Erneuern von PKI-Zertifikaten, einschließlich OCSP-Prüfung.

AS4-Transport

Versand, Empfang, Empfangsbestätigungen und Fehlerbehandlung zwischen Access Points.

SMP-Registrierung

Ihre Kunden im SMP und im SML registrieren, mit den richtigen Dokumenttypen.

Validierung

Syntaktische und Schematron-Validierung, aktualisiert bei jedem neuen Release der Spezifikationen.

Verfügbarkeit und Monitoring

Redundante Infrastruktur, Protokollierung und Störungsmanagement.

Neue Dokumenttypen und Modelle

Unterstützung für Ordering, Logistik oder PINT ohne eigenen Entwicklungsaufwand auf Transportebene.

Identifizierung der Endnutzer

Feststellen, wer Ihre Kunden sind, bevor Sie sie registrieren.

Berichterstattung

Verpflichtende regelmäßige Berichte an OpenPeppol.

Sicherheit

In den Niederlanden verlangt die Peppol Authority ISO 27001 oder einen gleichwertigen Standard.

Was Sie selbst weiterhin erledigen: Ihr Datenmodell korrekt befüllen, die richtigen Identifier und Scheme-IDs erfassen, Fehler und Statusmeldungen (MLR, Invoice Response) für Ihre Nutzer sichtbar machen und die API Ihres Service Providers integrieren. Achten Sie bei der Auswahl auf die Dokumenttypen und PINT-Varianten, die ein Provider unterstützt, auf die Qualität von API und Dokumentation und darauf, wie Validierungsfehler zurückgemeldet werden.

Für Integratoren gilt derselbe Entscheidungsrahmen. Wer mehrere Kunden an Peppol anbindet, profitiert vor allem von einem Provider mit klarem Onboarding der Teilnehmer und guter Unterstützung bei der SMP-Registrierung.

Die Standards auf dieser Seite bilden das Fundament. Der nächste Schritt ist Peppol in Ihre Software integrieren: welche API, welche Dokumenttypen und welcher Service Provider zu Ihrem Produkt passen.

Finden Sie im Vergleichsportal Service Provider, die zu Ihrem Produkt passen, und fragen Sie nach den Dokumenttypen und PINT-Varianten, die Sie benötigen.