Prüfen Sie Peppol-Rechnungen gegen EN 16931 und die Peppol-CIUS-Regeln — inklusive der elektronischen Adressen von Verkäufer und Käufer, die für die Zustellung nötig sind. Ihre Datei verlässt Ihren Rechner nie.
Peppol (Pan-European Public Procurement On-Line) ist ein Netzwerk für den Austausch elektronischer Dokumente zwischen Unternehmen und Behörden — in Europa und darüber hinaus. Peppol BIS Billing 3.0 ist sein Abrechnungsprofil: ein CIUS (eine eingeschränkte Spezialisierung) der europäischen Norm EN 16931, in UBL-Syntax. Über EN 16931 hinaus ergänzt es eigene Regeln — allen voran die elektronischen Adressen, mit denen ein Access Point eine Rechnung an den richtigen Empfänger zustellt.
Peppol ist das Rückgrat der E-Rechnung in immer mehr Ländern — die nordischen Staaten, die Niederlande, Belgien, das italienische Austauschsystem und andere setzen darauf, und es ist zentral für die grenzüberschreitenden Pläne der EU. Wenn Ihre Software Rechnungen über europäische Grenzen sendet oder empfängt oder Ihre Kunden an einen Peppol Access Point angebunden sind, ist die Unterstützung von Peppol BIS Billing 3.0 keine Option, sondern Pflicht.
Der häufigste Grund, warum eine technisch gültige EN-16931-Rechnung als Peppol scheitert, sind fehlende elektronische Adressen. Peppol verlangt sowohl eine Verkäufer-EndpointID (BT-34) als auch eine Käufer-EndpointID (BT-49), jeweils mit gültigem Adressschema — nur so weiß das Netzwerk, woher das Dokument kommt und wohin es geht. Billhorse prüft beide mit den Regeln PEPPOL-EN16931-R020 und PEPPOL-EN16931-R010, zusammen mit dem vollständigen EN-16931-Regelwerk.
Validierung ist die eine Hälfte; Billhorse erzeugt Peppol BIS Billing 3.0 auch. Aus einem JSON-Rechnungsmodell liefert POST /v1/generate?format=peppol ein UBL-Dokument mit korrekter Peppol-CustomizationID und -ProfileID; POST /v1/convert?format=peppol gibt eine bestehende Rechnung (UBL, CII oder Hybrid-PDF) als Peppol neu aus. Der Generator erfindet keine Routing-Daten — geben Sie die elektronischen Adressen von Verkäufer und Käufer im Modell an, dann ist die Ausgabe zustellbar. Die Erzeugung können Sie live und im Browser auf der API-Seite ausprobieren.
Wenn Ihr Produkt Peppol-Rechnungen erstellt oder empfängt, ist der Browser-Validator der Anfang: dieselbe Engine gibt es als Developer-API — validieren, parsen, generieren und konvertieren über HTTP, Fehlermeldungen in drei Sprachen, bei Bedarf self-hosted in Ihrer Infrastruktur.
Syntax (UBL), das erkannte Profil über die CustomizationID, die EN-16931-Geschäftsregeln (BR, BR-CO), die Summenarithmetik und die Peppol-spezifischen Regeln PEPPOL-EN16931-R010/R020 — die elektronischen Adressen von Verkäufer und Käufer (EndpointID), die Peppol für die Zustellung verlangt. Jeder Befund trägt eine Regel-ID mit eigener Erklärseite.
Nein. Die Validierung läuft als WebAssembly vollständig in Ihrem Browser. Die Datei verlässt Ihren Rechner nie — deshalb ist der Validator auch für echte Rechnungen mit echten Daten sicher.
Ja. Die API erzeugt Peppol BIS Billing 3.0 aus einem JSON-Rechnungsmodell mit POST /v1/generate?format=peppol und konvertiert eine bestehende Rechnung (UBL, CII oder Hybrid-PDF) mit /v1/convert?format=peppol. Das Dokument ist nur zustellbar, wenn das Modell die elektronischen Adressen von Verkäufer und Käufer (BT-34/BT-49) trägt — dieselben Regeln, die der Validator prüft. Die Erzeugung läuft auch client-seitig per WebAssembly.
Beide sind CIUS-Spezialisierungen von EN 16931. XRechnung ist der deutsche Standard und existiert in UBL und CII; Peppol BIS Billing 3.0 ist das paneuropäische Abrechnungsprofil für das Peppol-Netzwerk, in UBL, und verlangt zusätzlich elektronische Adressen für die Zustellung. Ein Dokument kann beide zugleich erfüllen.
Validieren und Parsen als Developer-API: gleiche Engine, normalisiertes JSON, Meldungen in drei Sprachen. Self-Hosted verfügbar.
Zur API