Wer Peppol in ein ERP-System, eine Buchhaltungssoftware oder ein eigenes Softwareprodukt einbauen möchte, steht vor zwei Entscheidungen. Die erste betrifft die Architektur: Wie verbindet sich Ihre Software mit dem Peppol-Netzwerk? Die zweite ist praktischer Natur: Welche Anforderungen muss die API eines Service Providers erfüllen, damit diese Verbindung zuverlässig und skalierbar ist? Diese Seite stellt die vier gängigen Architekturmuster nebeneinander und bietet eine Checkliste zur Bewertung einer API. Feldzuordnung und Validierungsregeln im Detail liegen außerhalb des Rahmens dieser Seite. Mehr zur zugrunde liegenden Norm lesen Sie auf der Seite zur EN 16931.
Vier Architekturmuster
Es gibt kein Muster, das immer die beste Wahl ist. Die richtige Wahl hängt von Ihrer Größenordnung, der gewünschten Kontrolle über den Prozess und Ihren Kapazitäten für eigene Wartung ab.
Konnektor in der Software
Ein fertiger Peppol-Konnektor, der als Plugin oder Modul eingebaut wird, oft angeboten von einem Service Provider oder einem Drittanbieter. Passt, wenn Sie schnell live gehen und wenig selbst warten möchten. Vorteil: kurze Time-to-Market, bewährte Funktionalität. Nachteil: weniger Spielraum für Anpassungen, abhängig von der Roadmap des Anbieters.
Anbindung über die API eines Service Providers
Ihre Software kommuniziert direkt mit der API eines Service Providers, der die Anbindung an das Netzwerk übernimmt. Passt, wenn Sie selbst bestimmen möchten, wie Senden, Empfangen und Statusverfolgung funktionieren. Vorteil: volle Kontrolle über Prozess und Fehlerbehandlung. Nachteil: Sie entwickeln und warten die Integrationsschicht selbst.
Eigene Middleware
Eine selbst entwickelte oder eingekaufte Zwischenschicht, die mehrere Systeme und gegebenenfalls mehrere Service Provider über eine einzige interne Schnittstelle erschließt. Passt zu größeren Organisationen mit mehreren Quellsystemen. Vorteil: Unabhängigkeit von einem einzelnen Provider, zentrales Logging. Nachteil: höhere Anfangsinvestition und mehr Verwaltungsaufwand.
Selbst Peppol Service Provider werden
Sie entwickeln oder betreiben selbst einen Access Point und einen SMP und werden über eine Peppol Authority Mitglied des Netzwerks. Sie haben maximale Kontrolle, tragen aber auch alle Pflichten: Tests und Zertifizierung, die Identifizierung Ihrer Endnutzer, Verfügbarkeit, Sicherheit (in den Niederlanden ISO 27001) und die verpflichtenden Berichte an OpenPeppol. Passt zu Unternehmen, für die Peppol ein Kernbestandteil ihrer Dienstleistung ist. Siehe Was ist ein Peppol Access Point? und Zertifizierter Service Provider werden.
Worauf Sie bei einer API achten sollten
Entscheiden Sie sich für eine Anbindung über eine API, direkt oder über Middleware, bestimmt die Qualität dieser API weitgehend, wie viel Aufwand die Integration kostet und wie stabil sie bleibt. Gehen Sie diese Punkte bei jeder in Frage kommenden API durch.
Senden und Empfangen
- Validierung vor dem Versand, mit verwertbaren Fehlermeldungen.
- Wie eingehende E-Rechnungen bei Ihnen ankommen (Push oder Pull), einschließlich der Originaldatei.
- Webhooks oder Statusmeldungen und Unterstützung für Invoice Response.
Endnutzer
- Registrierung und Verwaltung von Peppol-IDs über die API.
- Mandantenfähigkeit: mehrere Kunden unter einer Anbindung, jeder mit einer eigenen Peppol-ID.
- Wer die Identifizierung Ihrer Endnutzer durchführt und ob das über die API möglich ist.
- Können Sie Registrierungen zu einem anderen Provider mitnehmen? In den Niederlanden muss der bisherige Provider innerhalb von drei Werktagen mitwirken.
Länder und Formate
- Peppol BIS Billing 3.0 und nationale Varianten wie XRechnung und NLCIUS (die niederländische Variante).
- Wie neue Versionen umgesetzt werden.
- Ob Länder mit eigenem System abgedeckt sind, etwa die plateforme agréée (zugelassene Plattform) in Frankreich.
Technik und Betrieb
- Eine Sandbox, die das Netzwerk nachbildet.
- Versionierungsrichtlinie.
- Rate Limits.
- Schutz vor doppeltem Versand.
- ISO 27001 oder ein gleichwertiger Nachweis.
Mehr zu Formaten lesen Sie in Rechnungsformate und Peppol-Dokumenttypen und Standards.
Testen vor dem Go-live
Eine funktionierende API-Anbindung bedeutet noch nicht, dass der gesamte Prozess funktioniert. Testen Sie End-to-End in der Sandbox mit einigen festen Geschäftspartnern, bevor Sie einen Kunden live schalten. Prüfen Sie dabei Senden und Empfangen, die Verarbeitung von Statusmeldungen und die Behandlung abgelehnter Dokumente.
Führen Sie die Lösung anschließend schrittweise ein. Beginnen Sie mit einem Kunden oder einem Dokumentenfluss, zum Beispiel nur ausgehenden Rechnungen, und skalieren Sie, sobald dieser stabil läuft. So bleiben Fehler auf eine kleine Gruppe beschränkt, und Sie lernen aus der Praxis, bevor Ihr gesamter Kundenstamm umgestellt wird.
Was dies für Integratoren bedeutet
Übertragen Sie die Architekturentscheidung und die API-Checkliste in konkrete Maßnahmen.
- Legen Sie fest, welches Architekturmuster zu Ihrer Größenordnung passt: eine einzelne Integration oder mehrere Kunden und Mandanten
- Fragen Sie jeden in Frage kommenden API-Provider nach der Verfügbarkeit einer Sandbox, der Fehlerbehandlung und der Unterstützung für Mandantenfähigkeit
- Planen Sie vor dem Go-live eine Testphase mit echten Geschäftspartnern
- Legen Sie fest, wie die Registrierung von Peppol-IDs in Ihrem Onboarding-Prozess automatisiert wird
- Legen Sie fest, wer die Identifizierung Ihrer Endkunden übernimmt
Finden Sie Service Provider mit einer API im Vergleichsportal (filtern Sie nach der Kategorie Peppol Access Point as a Service).
Was dies für Softwareanbieter bedeutet
Für Softwareanbieter ist die Wahl auch eine Produktentscheidung. Grob gibt es drei Wege, dieselben wie unter Mit Peppol starten: selbst Peppol Service Provider werden, die Funktionalität eines Service Providers über eine API einbauen (gegebenenfalls als White-Label-Lösung unter Ihrem eigenen Namen) oder mit einem externen Dienst zusammenarbeiten, an den Sie sich anbinden. Selbst Service Provider zu werden bietet maximale Kontrolle, doch Sie übernehmen auch die Zertifizierung und den dauerhaften Betrieb. Der Einbau über eine API hält die Nutzererfahrung in Ihrem eigenen Produkt und lagert die Anbindung an das Netzwerk aus. Ein externer Dienst erfordert die geringste Investition, gibt Ihnen aber auch die geringste Kontrolle.
Wägen Sie ab, welche Rolle die E-Rechnungsstellung in Ihrem Leistungsangebot spielt: Ist sie eine Kernfunktion, mit der Sie sich abheben, oder eine Basisleistung, die einfach funktionieren muss?
Fazit
Eine gute Peppol-Integration beginnt mit einer bewussten Architekturentscheidung und einer kritischen Bewertung der API, auf der Sie aufbauen. Welches Muster Sie auch wählen, die Fragen aus der Checkliste bestimmen, wie skalierbar und wartbar Ihre Lösung wird. Mehr zu Rechnungsformaten und Dokumenttypen lesen Sie unter Rechnungsformate und Peppol-Dokumenttypen und Standards. Suchen Sie Service Provider mit einer API? Sehen Sie sich das Vergleichsportal von Peppol.now an.
