Auf dieser Seite
Die kurze Antwort
BR-DEC-16 schlägt fehl, wenn cac:LegalMonetaryTotal/cbc:PrepaidAmount mehr als zwei Zeichen nach dem Dezimalpunkt hat. Schreiben Sie den gezahlten Betrag mit höchstens zwei Nachkommastellen, 10.00 statt 10.000.
Die Vorauszahlung von 10.00 in der aufgezeichneten Rechnung ist richtig, und nur ihre geschriebene Form schlägt fehl. UBL-DT-01 meldet dasselbe cbc:PrepaidAmount.
Was die Regel prüft
Die Regel zählt die Zeichen nach dem Dezimalpunkt im cbc:PrepaidAmount von cac:LegalMonetaryTotal und erlaubt zwei. Ein Dokument ohne gezahlten Betrag hat nichts zu zählen; im Versuch war die minimale Rechnung gültig, nachdem das Element entfernt war.
Die Prüfung des fälligen Zahlungsbetrags erkennt einen kleinen Fehler im gezahlten Betrag nicht immer. Im Versuch meldete 10.004 nur diese Regel und UBL-DT-01, weil BR-CO-16 80.20 - 10.004 vor dem Vergleich wieder auf 70.20 rundet. Bei 10.006 rundet die Differenz auf 70.19, und BR-CO-16 wurde ebenfalls gemeldet.
Eine Vorauszahlung von null wird wie jeder andere Wert gezählt. Im Versuch meldete die minimale Rechnung mit 0.000 als gezahltem Betrag diese Regel und UBL-DT-01.
| Begriff | Bedeutung | UBL-Element |
|---|---|---|
| BT-113 | Gezahlter Betrag | cac:LegalMonetaryTotal/cbc:PrepaidAmount |
Wie es in einer Integration dazu kommt
Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:
- Die Anzahlung ist in einem Zahlungsbuch mit drei oder vier Nachkommastellen erfasst und wird so übernommen, wie sie gespeichert ist.
- Der gezahlte Betrag wird als Anteil der Summe einschließlich Umsatzsteuer berechnet und ungerundet geschrieben.
- Ein vorgegebener gezahlter Betrag von null wird von einem auf drei Nachkommastellen eingestellten Formatierer geschrieben.
So korrigieren Sie das Dokument
- Runden Sie den bereits erhaltenen Betrag auf zwei Nachkommastellen, passend zu dem, was tatsächlich gezahlt wurde.
- Schreiben Sie ihn in
cac:LegalMonetaryTotal/cbc:PrepaidAmount, mit höchstens zwei Nachkommastellen und ohne Leerzeichen, oder lassen Sie das Element weg, wenn nichts im Voraus gezahlt wurde. - Ziehen Sie den gerundeten gezahlten Betrag von der Summe einschließlich Umsatzsteuer ab, wenn Sie den fälligen Zahlungsbetrag berechnen, damit
BR-CO-16übereinstimmt.
Vorher und nachher
Dies sind Ausschnitte, keine vollständigen Dokumente. Die vollständigen synthetischen Dokumente, aus denen sie stammen, sind unten verlinkt.
Ausschnitt der fehlerhaften Rechnung: eine Vorauszahlung von 10.00 als 10.000 geschrieben
<cac:LegalMonetaryTotal>
<!-- line and net totals omitted from this fragment -->
<cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
<!-- allowance and charge totals omitted from this fragment -->
<cbc:PrepaidAmount currencyID="GBP">10.000</cbc:PrepaidAmount>
<!-- rounding amount and amount due omitted from this fragment -->
</cac:LegalMonetaryTotal>Ausschnitt der korrigierten Rechnung: die Vorauszahlung als 10.00 geschrieben
<cac:LegalMonetaryTotal>
<!-- line and net totals omitted from this fragment -->
<cbc:TaxInclusiveAmount currencyID="GBP">80.20</cbc:TaxInclusiveAmount>
<!-- allowance and charge totals omitted from this fragment -->
<cbc:PrepaidAmount currencyID="GBP">10.00</cbc:PrepaidAmount>
<!-- rounding amount and amount due omitted from this fragment -->
</cac:LegalMonetaryTotal>Die beiden Rechnungen unterscheiden sich nur im gezahlten Betrag: 10.000 in der fehlerhaften und 10.00 in der korrigierten. Der fällige Zahlungsbetrag von 70.00 ist in beiden 80.20 - 10.00 - 0.20, daher besteht BR-CO-16. Das fehlerhafte Dokument meldet BR-DEC-16 an cac:LegalMonetaryTotal und UBL-DT-01 am cbc:PrepaidAmount. Jedes Element, dessen Name auf Amount endet, fällt unter UBL-DT-01, außer Artikelpreisen und den Beträgen eines Nachlasses auf Preisebene; der gezahlte Betrag ist in dieser Hinsicht eine gewöhnliche Summe, weshalb sein Befund zusammen mit diesem auftritt.
Was der Validator gemeldet hat
- Die fehlerhafte Rechnung meldet BR-DEC-16 und UBL-DT-01. Das korrigierte Dokument besteht jeden Prüfschritt ohne Befunde.Fehlerhaftes XML herunterladenKorrigiertes XML herunterladen
Aufgezeichnet mit phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, der Engine hinter dem kostenlosen Validator, mit synthetischen Daten. Ein aufgezeichnetes Ergebnis ist ein Regressionsnachweis für diese Dokumente, keine Zertifizierung.
Wo die Regel gilt
- Gilt für UBL
InvoiceundCreditNote. Im Versuch meldete eine Gutschrift mit einem gezahlten Betrag von10.000dieselben zwei Befunde. - Die Grenze ändert sich nicht mit
currencyID.
Verwandte Regeln
- UBL-DT-01 meldet den gezahlten Betrag im selben Lauf
- BR-CO-16 zieht den gezahlten Betrag von der Summe einschließlich Umsatzsteuer ab, um den fälligen Zahlungsbetrag zu prüfen
- BR-DEC-14 wendet dieselbe Grenze auf die Summe einschließlich Umsatzsteuer an, von der der gezahlte Betrag abgezogen wird
- BR-DEC-17 wendet dieselbe Grenze auf den Rundungsbetrag an
- Alle Regeln der Referenz ansehen
- Hintergrund (auf Englisch): Understanding EN 16931 validation errors
Umfang und Quelle
Geschrieben für Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, angewendet auf Invoice- und CreditNote-Dokumente in UBL 2.1. Andere Profile, Syntaxen und Releases können diese Kennung anders definieren. Version des Hinweiskatalogs 2026-09-28.1: Quelle geprüft am 2026-09-28, Erklärung zuletzt aktualisiert am 2026-09-28.
Die offizielle Definition von BR-DEC-16 (auf Englisch) enthält den normativen Wortlaut und den Test. Diese Seite ist unsere Erklärung dazu, keine Kopie.
Die Erklärung ändert das Urteil der Engine nicht. Dass Sie diesen Befund beheben, heißt nicht, dass das Dokument jeden Prüfschritt besteht. Die Validierung bescheinigt keine rechtliche oder steuerliche Konformität und überträgt kein Dokument über Peppol.

