Peppol-BIS-Regeln — was zusätzlich gilt, wenn über Peppol zugestellt wird

Peppol ist ein Zustellnetz, keine zweite Norm. Diese Regeln prüfen genau das, was ein Netz braucht und eine Datei allein nicht: wohin sie geht, in welchem Prozess sie steht, und dass sie unterwegs nicht auseinanderfällt.

23 Regeln · 23 erklärt · Regelwerk v2026-08-31

Adressierung ist der Unterschied

Die Regeln, an denen es am häufigsten scheitert, verlangen eine elektronische Adresse für Käufer und Verkäufer (BT-49 und BT-34) samt Schema-Kennung. Eine Rechnung, die per E-Mail oder über ein Portal einwandfrei ankommt, hat diese Felder oft gar nicht — sie brauchte sie nie.

In Deutschland ist die Leitweg-ID der verwandte Fall auf der Verwaltungsseite: dieselbe Idee, eine Adressierung im Dokument, aber ein anderes Feld und ein anderes Schema. Wer beides verwechselt, füllt das falsche.

Strenger als die Norm, mit Absicht

Mehrere Peppol-Regeln verbieten, was EN 16931 zulässt — leere Elemente etwa. Der Grund ist betrieblich: ein Netz mit hunderten Zugangspunkten kann sich Uneindeutigkeit nicht leisten, weil jeder Empfänger sie anders auflöst.

Praktisch heißt das: eine Datei kann gegen EN 16931 sauber sein und über Peppol trotzdem abgewiesen werden. Prüfen Sie gegen das Profil, über das Sie tatsächlich zustellen, nicht gegen das allgemeinste.

Alle Peppol-Regeln

Mit dem offiziellen Regeltext. Regeln mit ausgeschriebener Erklärung tragen Ursache und Behebung direkt darunter.

PEPPOL-EN16931-R001
Business process MUST be provided.
Was die Regel verlangt
Die Rechnung muss den Geschäftsprozess (BT-23) nennen — die Kennung des Prozesses, in dem sie verschickt wird. Sie sagt dem Empfänger, nach welchem Regelwerk er die Rechnung erwartet.
Warum sie ausgelöst wird
Der Wert ist eine Konstante und wird deshalb gern als selbstverständlich behandelt: die Spezifikations-Kennung (BT-24) wird gesetzt, die Prozess-Kennung daneben vergessen, weil beide gleich aussehen und keine aus den Rechnungsdaten stammt.
Wie Sie es beheben
Setzen Sie BT-23 fest auf urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 — cbc:ProfileID in UBL, ram:BusinessProcessSpecifiedDocumentContextParameter/ram:ID in CII. Der Wert hängt nicht von der Rechnung ab.
PEPPOL-EN16931-R005
VAT accounting currency code MUST be different from invoice currency code when provided.
Was die Regel verlangt
Wird eine abweichende Währung für die Umsatzsteuer (BT-6) angegeben, muss sie sich von der Rechnungswährung (BT-5) unterscheiden. Das Feld existiert nur für den Fall, dass die Steuer in einer anderen Währung zu melden ist.
Warum sie ausgelöst wird
Das Mapping füllt BT-6 vorsorglich mit derselben Währung wie BT-5, weil ein leeres Feld nach einer Lücke aussieht. Damit behauptet die Rechnung eine Währungsumrechnung, die es nicht gibt.
Wie Sie es beheben
Lassen Sie BT-6 weg, wenn Steuer und Rechnung dieselbe Währung verwenden: cbc:TaxCurrencyCode in UBL, ram:TaxCurrencyCode in CII. Nur bei tatsächlich abweichender Meldewährung wird es gesetzt.
PEPPOL-EN16931-R008
Document MUST not contain empty elements.
Was die Regel verlangt
Das Dokument darf keine leeren Elemente enthalten. Ein Tag ohne Inhalt ist keine Angabe, sondern eine Behauptung, dass etwas übermittelt wurde.
Warum sie ausgelöst wird
Mappings schreiben Felder unbedingt und setzen den Wert danach. Ist die Quelle null, bleibt ein leeres Tag stehen — besonders häufig bei Notizfeldern, Referenzen und optionalen Kennungen, die nur manchmal belegt sind.
Wie Sie es beheben
Schreiben Sie ein Element erst, wenn ein Wert vorliegt. In den meisten Serialisierern ist das eine Bedingung um den Schreibaufruf herum, keine nachgelagerte Bereinigung — leere Tags nachträglich zu entfernen erwischt selten alle.
PEPPOL-EN16931-R010
Buyer electronic address MUST be provided
PEPPOL-EN16931-R020
Seller electronic address MUST be provided
Was die Regel verlangt
Die elektronische Adresse des Verkäufers (BT-34) muss übermittelt werden — das Gegenstück zu BT-49, an das der Empfänger antworten oder eine Rückmeldung schicken kann.
Warum sie ausgelöst wird
Dieselbe Ursache wie beim Käufer, nur wird sie hier zusätzlich für verzichtbar gehalten: „der Empfänger weiß doch, von wem die Rechnung kommt“. Für die automatische Verarbeitung ist der Absender aber genauso eine Kennung wie der Empfänger.
Wie Sie es beheben
Setzen Sie BT-34 mit Schema-Attribut unter cac:AccountingSupplierParty/cac:Party: cbc:EndpointID mit schemeID in UBL, ram:SellerTradeParty/ram:URIUniversalCommunication/ram:URIID in CII. Der Wert ist für Ihr Unternehmen konstant.
PEPPOL-EN16931-R040
Allowance/charge amount must equal base amount * percentage/100 if base amount and percentage exists
Was die Regel verlangt
Sind sowohl der Grundbetrag als auch der Prozentsatz eines Ab- oder Zuschlags angegeben, muss der Betrag genau daraus folgen: Grundbetrag × Prozentsatz ÷ 100.
Warum sie ausgelöst wird
Der Betrag stammt aus der Preisfindung, Grundbetrag und Prozentsatz werden zur Erläuterung nachträglich ergänzt. Rundet die Preisfindung anders — oder wurde der Rabatt auf einen anderen Grundbetrag gerechnet —, passen die drei Zahlen nicht zusammen.
Wie Sie es beheben
Rechnen Sie den Betrag aus genau den beiden Werten, die im Dokument stehen: cbc:Amount aus cbc:BaseAmount und cbc:MultiplierFactorNumeric im selben cac:AllowanceCharge (UBL), ram:ActualAmount aus ram:BasisAmount und ram:CalculationPercent (CII). Wer den Prozentsatz nicht belegen kann, lässt beide erläuternden Felder weg.
PEPPOL-EN16931-R041
Allowance/charge base amount MUST be provided when allowance/charge percentage is provided.
Was die Regel verlangt
Wird der Prozentsatz eines Ab- oder Zuschlags angegeben, muss auch der Grundbetrag dabeistehen. Ein Prozentsatz ohne Bezugsgröße lässt sich nicht nachrechnen.
Warum sie ausgelöst wird
Der Prozentsatz ist das, was im Vertrag steht, und wird deshalb übernommen. Der Grundbetrag ist ein Zwischenergebnis der Preisfindung und existiert im Rechnungsobjekt oft gar nicht als eigenes Feld.
Wie Sie es beheben
Übermitteln Sie beide oder keines: cbc:MultiplierFactorNumeric zusammen mit cbc:BaseAmount im selben cac:AllowanceCharge (UBL), ram:CalculationPercent zusammen mit ram:BasisAmount (CII). Der reine Betrag allein ist immer zulässig.
PEPPOL-EN16931-R042
Allowance/charge percentage MUST be provided when allowance/charge base amount is provided.
Was die Regel verlangt
Wird der Grundbetrag eines Ab- oder Zuschlags angegeben, muss auch der Prozentsatz dabeistehen — das Gegenstück zu R041.
Warum sie ausgelöst wird
Der Grundbetrag wird gesetzt, weil er in den Daten vorhanden ist, der Prozentsatz nicht, weil der Rabatt in Wahrheit ein fester Betrag war. Dann steht eine Bezugsgröße im Dokument, aus der nichts folgt.
Wie Sie es beheben
Ergänzen Sie cbc:MultiplierFactorNumeric (UBL) beziehungsweise ram:CalculationPercent (CII) — oder lassen Sie den Grundbetrag weg, wenn es sich um einen Festbetrag handelt. Ein Festbetrag braucht nur cbc:Amount.
PEPPOL-EN16931-R043
Allowance/charge ChargeIndicator value MUST equal 'true' or 'false'
Was die Regel verlangt
Das Kennzeichen, ob es sich um einen Zuschlag oder einen Abschlag handelt, muss genau true oder false lauten — kleingeschrieben, ohne Alternativen.
Warum sie ausgelöst wird
Boolesche Werte werden von Serialisierern unterschiedlich geschrieben: 1 und 0 aus vielen Datenbanken, True aus Python, TRUE aus manchen Templates. Jede dieser Schreibweisen ist für einen Menschen eindeutig und für das Schema falsch.
Wie Sie es beheben
Schreiben Sie den Wert als Zeichenkette true oder false in cbc:ChargeIndicator (UBL). Verlassen Sie sich nicht auf die Standard-Serialisierung Ihres booleschen Typs, sondern setzen Sie die beiden Literale ausdrücklich.
PEPPOL-EN16931-R043-1
[PEPPOL-EN16931-R043]-Allowance/charge ChargeIndicator value MUST equal 'true' or 'false'
Was die Regel verlangt
In CII muss das Zuschlags-Kennzeichen eines Ab- oder Zuschlags auf Dokument- oder Positionsebene genau true oder false lauten. Diese Regel prüft die Gruppe ram:SpecifiedTradeAllowanceCharge.
Warum sie ausgelöst wird
In CII steckt der Wert eine Ebene tiefer als in UBL, in ram:ChargeIndicator/udt:Indicator. Mappings, die von UBL portiert wurden, schreiben den Wert versehentlich direkt in ram:ChargeIndicator oder übernehmen die Schreibweise 1 und 0 aus der Datenbank.
Wie Sie es beheben
Schreiben Sie true oder false kleingeschrieben in ram:ChargeIndicator/udt:Indicator innerhalb von ram:SpecifiedTradeAllowanceCharge. Für Ab- und Zuschläge im Preis gilt dieselbe Anforderung an anderer Stelle — siehe R043-2.
PEPPOL-EN16931-R043-2
[PEPPOL-EN16931-R043]-Allowance/charge ChargeIndicator value MUST equal 'true' or 'false'
Was die Regel verlangt
Dieselbe Anforderung wie R043-1, aber für den Ab- oder Zuschlag im Preis: ram:AppliedTradeAllowanceCharge innerhalb des Bruttopreises muss ein Kennzeichen von genau true oder false tragen.
Warum sie ausgelöst wird
Der Preisrabatt wird oft von einer anderen Stelle im Mapping geschrieben als die Rabatte auf Dokumentebene — häufig direkt aus der Artikel-Preisfindung. Eine dort abweichende Schreibweise fällt erst hier auf, obwohl R043-1 längst sauber ist.
Wie Sie es beheben
Schreiben Sie true oder false kleingeschrieben in ram:ChargeIndicator/udt:Indicator innerhalb von ram:AppliedTradeAllowanceCharge unter ram:GrossPriceProductTradePrice. Im Preis ist ohnehin nur false zulässig — siehe R044.
PEPPOL-EN16931-R044
Charge on price level is NOT allowed. Only value 'false' allowed.
Was die Regel verlangt
Im Preis einer Position ist kein Zuschlag erlaubt. Das Kennzeichen dort darf nur false lauten: der Preis kennt ausschließlich den Abschlag vom Bruttopreis auf den Nettopreis.
Warum sie ausgelöst wird
Wer einen Aufschlag auf einen Artikel abbilden will — Mindermenge, Eilzuschlag, Verpackung —, sucht ihn intuitiv im Preis, weil er dort im eigenen System gepflegt wird. Die Norm sieht Zuschläge aber nur auf Positions- oder Dokumentebene vor.
Wie Sie es beheben
Verschieben Sie den Zuschlag in das cac:AllowanceCharge der Position oder des Dokuments mit cbc:ChargeIndicator true. Innerhalb von cac:Price bleibt nur der Abschlag mit false — in CII entsprechend ram:AppliedTradeAllowanceCharge.
PEPPOL-EN16931-R046
Item net price MUST equal (Gross price - Allowance amount) when gross price is provided.
PEPPOL-EN16931-R053
No more than one tax total amount must be provided where currency id equals document currency code.
Was die Regel verlangt
Die Rechnung darf genau eine Steuersumme in Rechnungswährung enthalten — also genau einen Block mit Aufschlüsselung. Mehrere Steuerkategorien gehören als mehrere Unterblöcke in diesen einen Block.
Warum sie ausgelöst wird
Wer je Steuersatz einen eigenen Steuerblock erzeugt, bildet die Struktur des eigenen Systems ab statt die der Norm. Die Rechnung sieht dann korrekt aus und hat trotzdem zwei Gesamtsummen.
Wie Sie es beheben
Erzeugen Sie ein einziges cac:TaxTotal mit cbc:TaxAmount und darin je Steuerkategorie ein cac:TaxSubtotal (UBL). In CII gibt es diese Verschachtelung nicht: dort steht je Kategorie ein ram:ApplicableTradeTax.
PEPPOL-EN16931-R054
Only one tax total amount must be provided where currency id equals tax currency code, if tax currency code (BT-6) is provided.
Was die Regel verlangt
Ein zweiter Steuerblock ohne Aufschlüsselung ist nur erlaubt, wenn eine abweichende Steuerwährung (BT-6) angegeben ist — und dann genau einer. Er nennt die Steuersumme in der Meldewährung.
Warum sie ausgelöst wird
Der Block entsteht aus einer Vorlage für Auslandsrechnungen und bleibt stehen, wenn BT-6 im konkreten Fall nicht gesetzt wird. Dann steht eine Steuersumme in einer Währung im Dokument, die die Rechnung gar nicht kennt.
Wie Sie es beheben
Erzeugen Sie das zusätzliche cac:TaxTotal ohne cac:TaxSubtotal nur zusammen mit cbc:TaxCurrencyCode — beide oder keines. Die eigentliche Aufschlüsselung bleibt im Block der Rechnungswährung, siehe R053.
PEPPOL-EN16931-R055
Invoice total VAT amount and Invoice total VAT amount in accounting currency MUST have the same operational sign
Was die Regel verlangt
Die Steuersumme in Rechnungswährung und die Steuersumme in der Meldewährung müssen dasselbe Vorzeichen tragen. Beide beschreiben denselben Betrag, nur in zwei Währungen.
Warum sie ausgelöst wird
Bei Gutschriften mit negativen Beträgen wird das Vorzeichen an einer Stelle gedreht und an der anderen nicht — typischerweise, weil die Umrechnung in die Meldewährung über einen Betragsdienst läuft, der den Absolutwert liefert.
Wie Sie es beheben
Rechnen Sie die Meldewährung aus dem vorzeichenbehafteten Betrag um, statt Vorzeichen und Betrag getrennt zu behandeln. Geprüft werden die beiden cbc:TaxAmount in den cac:TaxTotal-Blöcken (UBL) beziehungsweise die entsprechenden Beträge in CII.
PEPPOL-EN16931-R061
Mandate reference MUST be provided for direct debit.
PEPPOL-EN16931-R101
Element Additional referenced document can only be used for Invoice line object.
Was die Regel verlangt
Auf einer Rechnungsposition ist als zusätzliche Dokumentenreferenz nur der Objektbezeichner zulässig — der Typcode 130. Andere Belegverweise gehören auf Dokumentebene.
Warum sie ausgelöst wird
Lieferschein- oder Auftragsnummern werden je Position gepflegt und deshalb auch je Position ausgegeben. Auf Positionsebene sieht die Norm dafür aber nur den Objektbezeichner vor.
Wie Sie es beheben
Setzen Sie auf der Position cbc:DocumentTypeCode auf 130 (UBL: cac:InvoiceLine/cac:DocumentReference; CII: ram:AdditionalReferencedDocument der Position). Lieferschein und Auftrag gehören in cac:DespatchDocumentReference beziehungsweise cac:OrderReference auf Dokumentebene.
PEPPOL-EN16931-R110
Start date of line period MUST be within invoice period.
Was die Regel verlangt
Beginnt eine Position einen eigenen Leistungszeitraum, muss dieser innerhalb des Abrechnungszeitraums der Rechnung liegen: das Startdatum der Position darf nicht vor dem Start der Rechnung liegen.
Warum sie ausgelöst wird
Nachberechnungen sind der klassische Fall: eine Leistung aus dem Vormonat wird in die laufende Rechnung aufgenommen und behält ihren echten Zeitraum, während der Rechnungszeitraum nur den aktuellen Monat abdeckt.
Wie Sie es beheben
Weiten Sie den Rechnungszeitraum (cac:InvoicePeriod im Kopf) so, dass er alle Positionen umfasst, oder stellen Sie die Nachberechnung in eine eigene Rechnung. Geprüft wird cbc:StartDate der Position gegen cbc:StartDate im Kopf.
PEPPOL-EN16931-R111
End date of line period MUST be within invoice period.
Was die Regel verlangt
Das Enddatum eines Positionszeitraums darf nicht nach dem Ende des Abrechnungszeitraums liegen — das Gegenstück zu R110 am anderen Ende.
Warum sie ausgelöst wird
Vorausberechnete Leistungen laufen über das Rechnungsende hinaus: eine Jahreslizenz wird im August in Rechnung gestellt und endet im nächsten Juli, während der Rechnungszeitraum den August abdeckt.
Wie Sie es beheben
Setzen Sie den Rechnungszeitraum so, dass er die längste Position einschließt, oder verzichten Sie auf den Kopf-Zeitraum, wenn die Positionen ohnehin eigene tragen. Geprüft wird cbc:EndDate der Position gegen cbc:EndDate im Kopf.
PEPPOL-EN16931-R120
Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount
Was die Regel verlangt
Der Nettobetrag einer Position muss aus ihren eigenen Angaben folgen: Menge × (Nettopreis ÷ Preiseinheit), zuzüglich der Zuschläge und abzüglich der Abschläge auf der Position.
Warum sie ausgelöst wird
Der Positionsbetrag stammt aus dem Rechnungsobjekt und ist dort längst berechnet; Menge, Preis und Rabatte werden daneben geschrieben. Sobald die Preiseinheit nicht 1 ist oder ein Positionsrabatt hinzukommt, weichen die beiden Wege voneinander ab.
Wie Sie es beheben
Berechnen Sie cbc:LineExtensionAmount aus genau den Werten, die in der Position stehen — cbc:InvoicedQuantity, cac:Price/cbc:PriceAmount, cac:Price/cbc:BaseQuantity und die cac:AllowanceCharge der Position. Diese Regel ist eine Warnung, keine Ablehnung: die Rechnung bleibt gültig, aber die Zahlen widersprechen sich.
PEPPOL-EN16931-R121
Base quantity MUST be a positive number above zero.
PEPPOL-EN16931-R130
Unit code of price base quantity MUST be same as invoiced quantity.
Was die Regel verlangt
Die Maßeinheit der Preiseinheit muss dieselbe sein wie die der berechneten Menge. Preis und Menge müssen sich auf dasselbe messen, sonst ist der Positionsbetrag nicht nachrechenbar.
Warum sie ausgelöst wird
Menge und Preis kommen aus verschiedenen Quellen: die Menge aus dem Auftrag, die Preiseinheit aus dem Artikelstamm. Wird dort in Kilogramm gepflegt und im Auftrag in Stück bestellt, treffen zwei verschiedene Einheiten aufeinander.
Wie Sie es beheben
Setzen Sie das unitCode-Attribut von cac:Price/cbc:BaseQuantity gleich dem von cbc:InvoicedQuantity, oder rechnen Sie den Preis vorher auf die berechnete Einheit um. In CII gilt dasselbe für ram:BasisQuantity und ram:BilledQuantity.

NormAPI liefert technische Validierung, keine Steuer- oder Rechtsberatung.