E-Rechnung-Validierungsregeln – Referenz

Schlagen Sie jede E-Rechnung-Validierungsregel anhand ihrer ID nach – was sie prüft, der technische Test, welche Formate sie erzwingen und wie Sie einen Verstoß beheben. Deckt den europäischen Kern EN 16931, PEPPOL BIS 3.0, XRechnung und nationale CIUS-Profile ab, erzeugt aus demselben Schematron, das unsere Validatoren ausführen.

240dokumentierte Regeln
220fatal (blockierend)
13Regelfamilien

Angezeigt240240Regeln

EN 16931 — core rules (59)

BR-01

fatal

Eine Rechnung muss eine Spezifikationskennung (BT-24) haben.

EN 16931CIIUBLBT-24
Technischer Test (XPath)
normalize-space(rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID) != ''
Gegen diese Regel validieren →

BR-02

fatal

Die Rechnungsnummer fehlt – jede Rechnung braucht eine eigene Nummer.

Eine Rechnung muss eine Rechnungsnummer (BT-1) haben.

EN 16931CIIUBLBT-1
Technischer Test (XPath)
normalize-space(rsm:ExchangedDocument/ram:ID) != ''
Gegen diese Regel validieren →

BR-03

fatal

Das Rechnungsdatum fehlt.

Eine Rechnung muss ein Rechnungsdatum (BT-2) haben.

EN 16931CIIUBLBT-2
Technischer Test (XPath)
normalize-space(rsm:ExchangedDocument/ram:IssueDateTime/udt:DateTimeString[@format='102']) != ''
Gegen diese Regel validieren →

BR-04

fatal

Eine Rechnung muss einen Rechnungstypcode (BT-3) haben.

EN 16931CIIUBLBT-3
Technischer Test (XPath)
normalize-space(rsm:ExchangedDocument/ram:TypeCode) != ''
Gegen diese Regel validieren →

BR-05

fatal

Eine Rechnung muss einen Rechnungswährungscode (BT-5) haben.

EN 16931CIIUBLBT-5
Technischer Test (XPath)
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode) != ''
Gegen diese Regel validieren →

BR-06

fatal

Der Name des Verkäufers fehlt.

Eine Rechnung muss den Namen des Verkäufers (BT-27) enthalten.

EN 16931CIIUBLBT-27
Technischer Test (XPath)
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:Name) != ''
Gegen diese Regel validieren →

BR-07

fatal

Der Name des Käufers fehlt.

Eine Rechnung muss den Namen des Käufers (BT-44) enthalten.

EN 16931CIIUBLBT-44
Technischer Test (XPath)
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:Name) != ''
Gegen diese Regel validieren →

BR-08

fatal

Eine Rechnung muss die Postanschrift des Verkäufers enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress
Gegen diese Regel validieren →

BR-09

fatal

Die Postanschrift des Verkäufers (BG-5) muss einen Ländercode des Verkäufers (BT-40) enthalten.

EN 16931CIIUBLBG-5BT-40
Technischer Test (XPath)
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:PostalTradeAddress/ram:CountryID) != ''
Gegen diese Regel validieren →

BR-10

fatal

Eine Rechnung muss die Postanschrift des Käufers (BG-8) enthalten.

EN 16931CIIUBLBG-8
Technischer Test (XPath)
rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:PostalTradeAddress
Gegen diese Regel validieren →

BR-11

fatal

Die Postanschrift des Käufers muss einen Ländercode des Käufers (BT-55) enthalten.

EN 16931CIIUBLBT-55
Technischer Test (XPath)
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:PostalTradeAddress/ram:CountryID) != ''
Gegen diese Regel validieren →

BR-16

fatal

Die Rechnung hat keine Positionen – fügen Sie mindestens eine Rechnungsposition hinzu.

Eine Rechnung muss mindestens eine Rechnungsposition (BG-25) haben.

EN 16931CIIUBLBG-25
Technischer Test (XPath)
//ram:IncludedSupplyChainTradeLineItem
Gegen diese Regel validieren →

BR-17

fatal

Der Name des Zahlungsempfängers (BT-59) muss in der Rechnung angegeben werden, wenn der Zahlungsempfänger (BG-10) vom Verkäufer (BG-4) abweicht.

EN 16931CIIUBLBT-59BG-10BG-4
Technischer Test (XPath)
(ram:Name) and (not(ram:Name = ../../ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:Name) and not(ram:ID = ../../ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:ID) and not(ram:SpecifiedLegalOrganization/ram:ID = ../../ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:SpecifiedLegalOrganization/ram:ID))
Gegen diese Regel validieren →

BR-18

fatal

Der Name des Steuervertreters des Verkäufers (BT-62) muss in der Rechnung angegeben werden, wenn der Verkäufer (BG-4) einen Steuervertreter (BG-11) hat.

EN 16931CIIUBLBT-62BG-4BG-11
Technischer Test (XPath)
(ram:Name)
Gegen diese Regel validieren →

BR-19

fatal

Die Postanschrift des Steuervertreters des Verkäufers (BG-12) muss in der Rechnung angegeben werden, wenn der Verkäufer (BG-4) einen Steuervertreter (BG-11) hat.

EN 16931CIIUBLBG-12BG-4BG-11
Technischer Test (XPath)
(ram:PostalTradeAddress)
Gegen diese Regel validieren →

BR-20

fatal

Die Postanschrift des Steuervertreters des Verkäufers (BG-12) muss einen Ländercode des Steuervertreters (BT-69) enthalten, wenn der Verkäufer (BG-4) einen Steuervertreter (BG-11) hat.

EN 16931CIIUBLBG-12BT-69BG-4BG-11
Technischer Test (XPath)
(ram:PostalTradeAddress/ram:CountryID)
Gegen diese Regel validieren →

BR-21

fatal

Jede Rechnungsposition (BG-25) muss eine Kennung der Rechnungsposition (BT-126) haben.

EN 16931CIIUBLBG-25BT-126
Technischer Test (XPath)
normalize-space(ram:AssociatedDocumentLineDocument/ram:LineID) != ''
Gegen diese Regel validieren →

BR-22

fatal

Jede Rechnungsposition (BG-25) muss eine in Rechnung gestellte Menge (BT-129) haben.

EN 16931CIIUBLBG-25BT-129
Technischer Test (XPath)
(ram:SpecifiedLineTradeDelivery/ram:BilledQuantity)
Gegen diese Regel validieren →

BR-23

fatal

Eine Rechnungsposition (BG-25) muss einen Maßeinheitencode für die in Rechnung gestellte Menge (BT-130) haben.

EN 16931CIIUBLBG-25BT-130
Technischer Test (XPath)
(ram:SpecifiedLineTradeDelivery/ram:BilledQuantity/@unitCode)
Gegen diese Regel validieren →

BR-24

fatal

Jede Rechnungsposition (BG-25) muss einen Nettobetrag der Rechnungsposition (BT-131) haben.

EN 16931CIIUBLBG-25BT-131
Technischer Test (XPath)
(ram:SpecifiedLineTradeSettlement/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount)
Gegen diese Regel validieren →

BR-25

fatal

Einer Rechnungsposition fehlt die Artikelbezeichnung – geben Sie in jeder Position an, was Sie berechnen.

Jede Rechnungsposition (BG-25) muss den Artikelnamen (BT-153) enthalten.

EN 16931CIIUBLBG-25BT-153
Technischer Test (XPath)
normalize-space(ram:SpecifiedTradeProduct/ram:Name) != ''
Gegen diese Regel validieren →

BR-26

fatal

Einer Rechnungsposition fehlt der Nettopreis (der Preis pro Einheit ohne Umsatzsteuer).

Jede Rechnungsposition (BG-25) muss den Nettopreis des Artikels (BT-146) enthalten.

EN 16931CIIUBLBG-25BT-146
Technischer Test (XPath)
(ram:SpecifiedLineTradeAgreement/ram:NetPriceProductTradePrice/ram:ChargeAmount)
Gegen diese Regel validieren →

BR-27

fatal

Ein Artikelpreis ist negativ – geben Sie Preise positiv an und nutzen Sie für Minderungen einen Nachlass oder eine Gutschrift.

Der Nettopreis des Artikels (BT-146) darf NICHT negativ sein.

EN 16931CIIUBLBT-146
Gegen diese Regel validieren →

BR-29

fatal

Wenn sowohl das Startdatum des Rechnungszeitraums (BT-73) als auch das Enddatum des Rechnungszeitraums (BT-74) angegeben sind, muss das Enddatum (BT-74) nach oder gleich dem Startdatum (BT-73) liegen.

EN 16931CIIUBLBT-73BT-74
Gegen diese Regel validieren →

BR-30

fatal

Wenn sowohl das Startdatum des Positionszeitraums (BT-134) als auch das Enddatum des Positionszeitraums (BT-135) angegeben sind, muss das Enddatum (BT-135) nach oder gleich dem Startdatum (BT-134) liegen.

EN 16931CIIUBLBT-134BT-135
Gegen diese Regel validieren →

BR-31

fatal

Jeder Nachlass auf Dokumentebene (BG-20) muss einen Nachlassbetrag auf Dokumentebene (BT-92) haben.

EN 16931CIIUBLBG-20BT-92
Technischer Test (XPath)
(../ram:ActualAmount)
Gegen diese Regel validieren →

BR-32

fatal

Jeder Nachlass auf Dokumentebene (BG-20) muss einen USt.-Kategoriecode des Nachlasses auf Dokumentebene (BT-95) haben.

EN 16931CIIUBLBG-20BT-95
Technischer Test (XPath)
(../ram:CategoryTradeTax[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode)
Gegen diese Regel validieren →

BR-33

fatal

Jeder Nachlass auf Dokumentebene (BG-20) muss einen Nachlassgrund auf Dokumentebene (BT-97) oder einen Nachlassgrundcode auf Dokumentebene (BT-98) haben.

EN 16931CIIUBLBG-20BT-97BT-98
Technischer Test (XPath)
(../ram:Reason) or (../ram:ReasonCode)
Gegen diese Regel validieren →

BR-36

fatal

Jeder Zuschlag auf Dokumentebene (BG-21) muss einen Zuschlagsbetrag auf Dokumentebene (BT-99) haben.

EN 16931CIIUBLBG-21BT-99
Technischer Test (XPath)
(../ram:ActualAmount)
Gegen diese Regel validieren →

BR-37

fatal

Jeder Zuschlag auf Dokumentebene (BG-21) muss einen USt.-Kategoriecode des Zuschlags auf Dokumentebene (BT-102) haben.

EN 16931CIIUBLBG-21BT-102
Technischer Test (XPath)
(../ram:CategoryTradeTax[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode)
Gegen diese Regel validieren →

BR-38

fatal

Jeder Zuschlag auf Dokumentebene (BG-21) muss einen Zuschlagsgrund auf Dokumentebene (BT-104) oder einen Zuschlagsgrundcode auf Dokumentebene (BT-105) haben.

EN 16931CIIUBLBG-21BT-104BT-105
Technischer Test (XPath)
(../ram:Reason) or (../ram:ReasonCode)
Gegen diese Regel validieren →

BR-41

fatal

Jeder Nachlass einer Rechnungsposition (BG-27) muss einen Nachlassbetrag der Rechnungsposition (BT-136) haben.

EN 16931CIIUBLBG-27BT-136
Technischer Test (XPath)
(../ram:ActualAmount)
Gegen diese Regel validieren →

BR-42

fatal

Jeder Nachlass einer Rechnungsposition (BG-27) muss einen Nachlassgrund der Rechnungsposition (BT-139) oder einen Nachlassgrundcode der Rechnungsposition (BT-140) haben.

EN 16931CIIUBLBG-27BT-139BT-140
Technischer Test (XPath)
(../ram:Reason) or (../ram:ReasonCode)
Gegen diese Regel validieren →

BR-43

fatal

Jeder Zuschlag einer Rechnungsposition (BG-28) muss einen Zuschlagsbetrag der Rechnungsposition (BT-141) haben.

EN 16931CIIUBLBG-28BT-141
Technischer Test (XPath)
(../ram:ActualAmount)
Gegen diese Regel validieren →

BR-44

fatal

Jeder Zuschlag einer Rechnungsposition muss einen Zuschlagsgrund oder einen Nachlassgrundcode der Rechnungsposition haben.

EN 16931CIIUBL
Technischer Test (XPath)
(../ram:Reason) or (../ram:ReasonCode)
Gegen diese Regel validieren →

BR-45

fatal

Jede USt.-Aufschlüsselung (BG-23) muss einen steuerpflichtigen Betrag der USt.-Kategorie (BT-116) haben.

EN 16931CIIUBLBG-23BT-116
Technischer Test (XPath)
(ram:BasisAmount)
Gegen diese Regel validieren →

BR-46

fatal

Jede USt.-Aufschlüsselung (BG-23) muss einen Steuerbetrag der USt.-Kategorie (BT-117) haben.

EN 16931CIIUBLBG-23BT-117
Technischer Test (XPath)
(ram:CalculatedAmount)
Gegen diese Regel validieren →

BR-47

fatal

Jede USt.-Aufschlüsselung (BG-23) muss durch einen USt.-Kategoriecode (BT-118) definiert sein.

EN 16931CIIUBLBG-23BT-118
Technischer Test (XPath)
(.[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode)
Gegen diese Regel validieren →

BR-48

fatal

Jede USt.-Aufschlüsselung (BG-23) muss einen Satz der USt.-Kategorie (BT-119) haben, außer wenn die Rechnung nicht der USt. unterliegt.

EN 16931CIIUBLBG-23BT-119
Technischer Test (XPath)
(.[upper-case(ram:TypeCode) = 'VAT']/ram:RateApplicablePercent) or (.[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode = 'O')
Gegen diese Regel validieren →

BR-50

fatal

Es sind Überweisungsangaben vorhanden, aber die Kontonummer (IBAN) fehlt.

Eine Kennung des Zahlungskontos (BT-84) muss vorhanden sein, wenn Informationen zur Überweisung (BG-17) in der Rechnung angegeben sind.

EN 16931CIIUBLBT-84BG-17
Technischer Test (XPath)
(ram:IBANID) or (ram:ProprietaryID)
Gegen diese Regel validieren →

BR-51

fatal

Gemäß den Sicherheitsstandards für Kartenzahlungen sollte eine Rechnung niemals eine vollständige primäre Kartennummer (BT-87) enthalten.

EN 16931CIIUBLBT-87
Technischer Test (XPath)
string-length(ram:ID)<=10
Gegen diese Regel validieren →

BR-52

fatal

Jedes zusätzliche Begleitdokument (BG-24) muss eine Referenz auf das Begleitdokument (BT-122) enthalten.

EN 16931CIIUBLBG-24BT-122
Technischer Test (XPath)
normalize-space(ram:IssuerAssignedID) != ''
Gegen diese Regel validieren →

BR-53

fatal

Wenn der Code der USt.-Buchungswährung (BT-6) vorhanden ist, muss der Gesamt-USt.-Betrag der Rechnung in der Buchungswährung (BT-111) angegeben werden.

EN 16931CIIUBLBT-6BT-111
Technischer Test (XPath)
not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode) or (/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode and (ram:TaxTotalAmount/@currencyID = /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode) and not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode = /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode))
Gegen diese Regel validieren →

BR-54

fatal

Jedes Artikelattribut (BG-32) muss einen Artikelattributnamen (BT-160) und einen Artikelattributwert (BT-161) enthalten.

EN 16931CIIUBLBG-32BT-160BT-161
Technischer Test (XPath)
(ram:Description) and (ram:Value)
Gegen diese Regel validieren →

BR-55

fatal

Jede Referenz auf eine vorausgehende Rechnung (BG-3) muss eine Referenz auf eine vorausgehende Rechnung (BT-25) enthalten.

EN 16931CIIUBLBG-3BT-25
Technischer Test (XPath)
normalize-space(ram:IssuerAssignedID) != ''
Gegen diese Regel validieren →

BR-56

fatal

Jeder Steuervertreter des Verkäufers (BG-11) muss eine USt-IdNr. des Steuervertreters des Verkäufers (BT-63) haben.

EN 16931CIIUBLBG-11BT-63
Technischer Test (XPath)
normalize-space(ram:SpecifiedTaxRegistration/ram:ID[@schemeID='VA']) != ''
Gegen diese Regel validieren →

BR-57

fatal

Jede Lieferadresse (BG-15) muss einen Ländercode der Lieferadresse (BT-80) enthalten.

EN 16931CIIUBLBG-15BT-80
Technischer Test (XPath)
(ram:ShipToTradeParty/ram:PostalTradeAddress and normalize-space(ram:ShipToTradeParty/ram:PostalTradeAddress/ram:CountryID) != '') or not (ram:ShipToTradeParty/ram:PostalTradeAddress)
Gegen diese Regel validieren →

BR-61

fatal

Als Zahlungsart ist eine Überweisung angegeben, daher ist die Kontonummer (IBAN) des Zahlungsempfängers erforderlich.

Wenn der Zahlungsmittel-Typcode (BT-81) eine SEPA-Überweisung, eine inländische Überweisung oder eine internationale Nicht-SEPA-Überweisung bedeutet, muss die Kennung des Zahlungskontos (BT-84) vorhanden sein.

EN 16931CIIUBLBT-81BT-84
Technischer Test (XPath)
(ram:IBANID) or (ram:ProprietaryID)
Gegen diese Regel validieren →

BR-62

fatal

Bei der elektronischen Adresse des Verkäufers fehlt das Schema – geben Sie an, welche Art von Kennung es ist (z. B. USt-IdNr. oder GLN).

Die elektronische Adresse des Verkäufers (BT-34) muss eine Schemakennung haben.

EN 16931CIIUBLBT-34
Technischer Test (XPath)
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:URIUniversalCommunication[1]/ram:URIID/@schemeID) != '' or not (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:URIUniversalCommunication)
Gegen diese Regel validieren →

BR-63

fatal

Bei der elektronischen Adresse des Käufers fehlt das Schema – geben Sie an, welche Art von Kennung es ist (z. B. USt-IdNr. oder GLN).

Die elektronische Adresse des Käufers (BT-49) muss eine Schemakennung haben.

EN 16931CIIUBLBT-49
Technischer Test (XPath)
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:URIUniversalCommunication[1]/ram:URIID/@schemeID) != '' or not (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:URIUniversalCommunication)
Gegen diese Regel validieren →

BR-64

fatal

Die Standardkennung des Artikels (BT-157) muss eine Schemakennung haben.

EN 16931CIIUBLBT-157
Technischer Test (XPath)
normalize-space(ram:SpecifiedTradeProduct/ram:GlobalID/@schemeID) != '' or not (ram:SpecifiedTradeProduct/ram:GlobalID)
Gegen diese Regel validieren →

BR-65

fatal

Die Klassifikationskennung des Artikels (BT-158) muss eine Schemakennung haben.

EN 16931CIIUBLBT-158
Technischer Test (XPath)
normalize-space(ram:ClassCode/@listID) != '' or not (ram:ClassCode)
Gegen diese Regel validieren →

EN 16931 — calculation rules (18)

BR-CO-03

fatal

Das Datum des USt.-Anspruchs (BT-7) und der Code für das Datum des USt.-Anspruchs (BT-8) schließen sich gegenseitig aus.

EN 16931CIIUBLBT-7BT-8
Technischer Test (XPath)
((//ram:TaxPointDate) and not(//ram:DueDateTypeCode)) or (not (//ram:TaxPointDate) and (//ram:DueDateTypeCode)) or (not (//ram:TaxPointDate) and not (//ram:DueDateTypeCode))
Gegen diese Regel validieren →

BR-CO-04

fatal

Einer Rechnungsposition fehlt die Umsatzsteuerkategorie – z. B. S (Normalsatz), Z (Nullsatz), E (befreit) oder AE (Reverse Charge).

Jede Rechnungsposition (BG-25) muss mit einem USt.-Kategoriecode des in Rechnung gestellten Artikels (BT-151) kategorisiert werden.

EN 16931CIIUBLBG-25BT-151
Technischer Test (XPath)
(ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[upper-case(ram:TypeCode) = 'VAT']/ram:CategoryCode)
Gegen diese Regel validieren →

BR-CO-05

fatal

Der Nachlassgrundcode auf Dokumentebene (BT-98) und der Nachlassgrund auf Dokumentebene (BT-97) müssen denselben Nachlasstyp angeben.

EN 16931CIIUBLBT-98BT-97
Technischer Test (XPath)
true()
Gegen diese Regel validieren →

BR-CO-06

fatal

Der Zuschlagsgrundcode auf Dokumentebene (BT-105) und der Zuschlagsgrund auf Dokumentebene (BT-104) müssen denselben Zuschlagstyp angeben.

EN 16931CIIUBLBT-105BT-104
Technischer Test (XPath)
true()
Gegen diese Regel validieren →

BR-CO-07

fatal

Der Nachlassgrundcode der Rechnungsposition (BT-140) und der Nachlassgrund der Rechnungsposition (BT-139) müssen denselben Nachlassgrundtyp angeben.

EN 16931CIIUBLBT-140BT-139
Technischer Test (XPath)
true()
Gegen diese Regel validieren →

BR-CO-08

fatal

Der Zuschlagsgrundcode der Rechnungsposition (BT-145) und der Zuschlagsgrund der Rechnungsposition (BT-144) müssen denselben Zuschlagsgrundtyp angeben.

EN 16931CIIUBLBT-145BT-144
Technischer Test (XPath)
true()
Gegen diese Regel validieren →

BR-CO-09

fatal

Eine USt-IdNr. muss mit dem zweistelligen Ländercode beginnen, z. B. DE123456789 (Griechenland verwendet EL).

Die USt-IdNr. des Verkäufers (BT-31), die USt-IdNr. des Steuervertreters des Verkäufers (BT-63) und die USt-IdNr. des Käufers (BT-48) müssen ein Präfix gemäß ISO-Code ISO 3166-1 alpha-2 haben, anhand dessen das Ausstellungsland identifiziert werden kann. Griechenland darf jedoch das Präfix 'EL' verwenden.

EN 16931CIIUBLBT-31BT-63BT-48
Technischer Test (XPath)
contains(' 1A AD AE AF AG AI AL AM AN AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BL BJ BM BN BO BQ BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM DO DZ EC EE EG EH EL ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ MR MS MT MU MV MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR ST SV SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA VC VE VG VI VN VU WF WS XI YE YT ZA ZM ZW ', concat(' ', substring(.,1,2), ' '))
Gegen diese Regel validieren →

BR-CO-10

fatal

Die Summe der Positionsbeträge in der Rechnung stimmt nicht mit den addierten Positionsbeträgen überein – meist eine Rundungsdifferenz oder eine nachträglich geänderte Position.

Summe der Nettobeträge der Rechnungspositionen (BT-106) = Summe der Nettobeträge der Rechnungspositionen (BT-131).

EN 16931CIIUBLBT-106BT-131
Technischer Test (XPath)
xs:decimal(ram:LineTotalAmount) = round(xs:decimal(sum(../../ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:SpecifiedTradeSettlementLineMonetarySummation/ram:LineTotalAmount)) * xs:decimal(100)) div xs:decimal(100)
Gegen diese Regel validieren →

BR-CO-11

fatal

Summe der Nachlässe auf Dokumentebene (BT-107) = Summe der Nachlassbeträge auf Dokumentebene (BT-92).

EN 16931CIIUBLBT-107BT-92
Technischer Test (XPath)
(not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator=false()])and not (ram:AllowanceTotalAmount)) or ram:AllowanceTotalAmount = (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator=false()]/ram:ActualAmount)* 10 * 10 ) div 100)
Gegen diese Regel validieren →

BR-CO-12

fatal

Summe der Zuschläge auf Dokumentebene (BT-108) = Summe der Zuschlagsbeträge auf Dokumentebene (BT-99).

EN 16931CIIUBLBT-108BT-99
Technischer Test (XPath)
(not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator=true()])and not (ram:ChargeTotalAmount)) or ram:ChargeTotalAmount = (round(sum(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge[ram:ChargeIndicator/udt:Indicator=true()]/ram:ActualAmount)* 10 * 10 ) div 100)
Gegen diese Regel validieren →

BR-CO-13

fatal

Der Gesamtbetrag ohne Umsatzsteuer muss der Summe der Positionen abzüglich Nachlässen und zuzüglich Zuschlägen auf Belegebene entsprechen.

Gesamtbetrag der Rechnung ohne USt. (BT-109) = Summe der Nettobeträge der Rechnungspositionen (BT-131) - Summe der Nachlässe auf Dokumentebene (BT-107) + Summe der Zuschläge auf Dokumentebene (BT-108).

EN 16931CIIUBLBT-109BT-131BT-107BT-108
Technischer Test (XPath)
(xs:decimal(ram:TaxBasisTotalAmount) = round((xs:decimal(ram:LineTotalAmount) - xs:decimal(ram:AllowanceTotalAmount) + xs:decimal(ram:ChargeTotalAmount)) *10 * 10) div 100) or ((xs:decimal(ram:TaxBasisTotalAmount) = round((xs:decimal(ram:LineTotalAmount) - xs:decimal(ram:AllowanceTotalAmount)) *10 * 10) div 100) and not (ram:ChargeTotalAmount)) or ((xs:decimal(ram:TaxBasisTotalAmount) = round((xs:decimal(ram:LineTotalAmount) + xs:decimal(ram:ChargeTotalAmount)) *10 * 10) div 100) and not (ram:AllowanceTotalAmount)) or ((xs:decimal(ram:TaxBasisTotalAmount) = round((xs:decimal(ram:LineTotalAmount)) *10 * 10) div 100) and not (ram:ChargeTotalAmount) and not (ram:AllowanceTotalAmount))
Gegen diese Regel validieren →

BR-CO-15

fatal

Der Gesamtbetrag mit Umsatzsteuer muss dem Betrag ohne Umsatzsteuer zuzüglich des Umsatzsteuerbetrags entsprechen.

Gesamtbetrag der Rechnung mit USt. (BT-112) = Gesamtbetrag der Rechnung ohne USt. (BT-109) + Gesamt-USt.-Betrag der Rechnung (BT-110).

EN 16931CIIUBLBT-112BT-109BT-110
Technischer Test (XPath)
every $Currency in rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode satisfies ( count ( rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:TaxTotalAmount[@currencyID=$Currency] ) eq 1 and (//ram:SpecifiedTradeSettlementHeaderMonetarySummation/xs:decimal(ram:GrandTotalAmount) = round( (//ram:SpecifiedTradeSettlementHeaderMonetarySummation/xs:decimal(ram:TaxBasisTotalAmount) + (//ram:SpecifiedTradeSettlementHeaderMonetarySummation/xs:decimal(ram:TaxTotalAmount[@currencyID=$Currency]))) * 10 * 10) div 100)) or (//ram:SpecifiedTradeSettlementHeaderMonetarySummation/xs:decimal(ram:GrandTotalAmount) = (//ram:SpecifiedTradeSettlementHeaderMonetarySummation/xs:decimal(ram:TaxBasisTotalAmount)))
Gegen diese Regel validieren →

BR-CO-16

fatal

Der fällige Betrag muss dem Gesamtbetrag mit Umsatzsteuer abzüglich bereits gezahlter Beträge zuzüglich des Rundungsbetrags entsprechen.

Fälliger Zahlungsbetrag (BT-115) = Gesamtbetrag der Rechnung mit USt. (BT-112) - Bereits gezahlter Betrag (BT-113) + Rundungsbetrag (BT-114).

EN 16931CIIUBLBT-115BT-112BT-113BT-114
Technischer Test (XPath)
(xs:decimal(ram:DuePayableAmount) = xs:decimal(ram:GrandTotalAmount) - xs:decimal(ram:TotalPrepaidAmount) + xs:decimal(ram:RoundingAmount)) or ((xs:decimal(ram:DuePayableAmount) = xs:decimal(ram:GrandTotalAmount) + xs:decimal(ram:RoundingAmount)) and not (xs:decimal(ram:TotalPrepaidAmount))) or ((xs:decimal(ram:DuePayableAmount) = xs:decimal(ram:GrandTotalAmount) - xs:decimal(ram:TotalPrepaidAmount)) and not (xs:decimal(ram:RoundingAmount))) or ((xs:decimal(ram:DuePayableAmount) = xs:decimal(ram:GrandTotalAmount)) and not (xs:decimal(ram:TotalPrepaidAmount)) and not (xs:decimal(ram:RoundingAmount)))
Gegen diese Regel validieren →

BR-CO-17

fatal

Ein Steuerbetrag in der Umsatzsteueraufschlüsselung entspricht nicht Bemessungsgrundlage × Steuersatz, auf zwei Nachkommastellen gerundet.

Steuerbetrag der USt.-Kategorie (BT-117) = Steuerpflichtiger Betrag der USt.-Kategorie (BT-116) x (Satz der USt.-Kategorie (BT-119) / 100), auf zwei Dezimalstellen gerundet.

EN 16931CIIUBLBT-117BT-116BT-119
Gegen diese Regel validieren →

BR-CO-18

fatal

Die Rechnung hat keine Umsatzsteueraufschlüsselung – mindestens eine Steuergruppe (Kategorie, Satz, Bemessungsgrundlage, Steuer) ist nötig, auch bei 0 %.

Eine Rechnung muss mindestens eine USt.-Aufschlüsselungsgruppe (BG-23) haben.

EN 16931CIIUBLBG-23
Technischer Test (XPath)
//rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax
Gegen diese Regel validieren →

BR-CO-21

fatal

Jeder Nachlass auf Dokumentebene (BG-20) muss einen Nachlassgrund auf Dokumentebene (BT-97) oder einen Nachlassgrundcode auf Dokumentebene (BT-98) oder beides enthalten.

EN 16931CIIUBLBG-20BT-97BT-98
Technischer Test (XPath)
(../ram:Reason) or (../ram:ReasonCode)
Gegen diese Regel validieren →

BR-CO-22

fatal

Jeder Zuschlag auf Dokumentebene (BG-21) muss einen Zuschlagsgrund auf Dokumentebene (BT-104) oder einen Zuschlagsgrundcode auf Dokumentebene (BT-105) oder beides enthalten.

EN 16931CIIUBLBG-21BT-104BT-105
Technischer Test (XPath)
(../ram:Reason) or (../ram:ReasonCode)
Gegen diese Regel validieren →

BR-CO-25

fatal

Es ist ein Betrag fällig, daher braucht die Rechnung ein Fälligkeitsdatum oder Zahlungsbedingungen.

Wenn der fällige Zahlungsbetrag (BT-115) positiv ist, muss entweder das Zahlungsfälligkeitsdatum (BT-9) oder die Zahlungsbedingungen (BT-20) vorhanden sein.

EN 16931CIIUBLBT-115BT-9BT-20
Gegen diese Regel validieren →

EN 16931 — VAT category rules (16)

BR-AE-01

fatal

Eine Rechnung, die eine Rechnungsposition, einen Nachlass auf Dokumentebene oder einen Zuschlag auf Dokumentebene enthält, bei der der USt.-Kategoriecode "Umkehrung der Steuerschuldnerschaft" ist, muss in der USt.-Aufschlüsselung genau einen USt.-Kategoriecode gleich "Umkehrung der Steuerschuldnerschaft" enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
(count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='AE'])=0 and count(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='AE'])=0 and count(//ram:CategoryTradeTax[ram:CategoryCode='AE'])=0) or ( count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='AE'])=1 and (exists(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='AE']) or exists(//ram:CategoryTradeTax[ram:CategoryCode='AE'])))
Gegen diese Regel validieren →

BR-AE-02

fatal

Es wird Reverse Charge verwendet, daher müssen beide Parteien steuerlich angegeben sein: die USt-IdNr. (oder Steuernummer) des Verkäufers und die USt-IdNr. (oder Registernummer) des Käufers.

Eine Rechnung, die eine Rechnungsposition enthält, bei der der USt.-Kategoriecode des in Rechnung gestellten Artikels "Umkehrung der Steuerschuldnerschaft" ist, muss die USt-IdNr. des Verkäufers, die Steuerregistrierungskennung des Verkäufers und/oder die USt-IdNr. des Steuervertreters des Verkäufers sowie die USt-IdNr. des Käufers und/oder die rechtliche Registrierungskennung des Käufers enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
(//ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = ('VA', 'FC')] or //ram:SellerTaxRepresentativeTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA']) and (//ram:BuyerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA'] or //ram:BuyerTradeParty/ram:SpecifiedLegalOrganization/ram:ID)
Gegen diese Regel validieren →

BR-AE-05

fatal

In einer Rechnungsposition, bei der der USt.-Kategoriecode des in Rechnung gestellten Artikels "Umkehrung der Steuerschuldnerschaft" ist, muss der USt.-Satz des in Rechnung gestellten Artikels 0 (null) sein.

EN 16931CIIUBL
Technischer Test (XPath)
ram:RateApplicablePercent = 0
Gegen diese Regel validieren →

BR-AE-09

fatal

Der Steuerbetrag der USt.-Kategorie in einer USt.-Aufschlüsselung, bei der der USt.-Kategoriecode "Umkehrung der Steuerschuldnerschaft" ist, muss 0 (null) sein.

EN 16931CIIUBL
Technischer Test (XPath)
../ram:CalculatedAmount = 0
Gegen diese Regel validieren →

BR-AE-10

fatal

Eine Steuergruppe mit Reverse Charge braucht einen Befreiungsgrund – den Code VATEX-EU-AE oder den Text „Reverse charge“.

Eine USt.-Aufschlüsselung mit dem USt.-Kategoriecode "Umkehrung der Steuerschuldnerschaft" muss einen USt.-Befreiungsgrundcode oder den Befreiungsgrundtext "Umkehrung der Steuerschuldnerschaft" haben.

EN 16931CIIUBL
Technischer Test (XPath)
(../ram:ExemptionReason) or (../ram:ExemptionReasonCode)
Gegen diese Regel validieren →

BR-E-01

fatal

Eine Rechnung, die eine Rechnungsposition, einen Nachlass auf Dokumentebene oder einen Zuschlag auf Dokumentebene enthält, bei der der USt.-Kategoriecode "Von der USt. befreit" ist, muss genau eine USt.-Aufschlüsselung mit dem USt.-Kategoriecode gleich "Von der USt. befreit" enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
(count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='E'])=0 and count(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='E'])=0 and count(//ram:CategoryTradeTax[ram:CategoryCode='E'])=0) or ( count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='E'])=1 and (exists(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='E']) or exists(//ram:CategoryTradeTax[ram:CategoryCode='E'])))
Gegen diese Regel validieren →

BR-E-02

fatal

Eine Rechnung, die eine Rechnungsposition enthält, bei der der USt.-Kategoriecode des in Rechnung gestellten Artikels "Von der USt. befreit" ist, muss die USt-IdNr. des Verkäufers, die Steuerregistrierungskennung des Verkäufers und/oder die USt-IdNr. des Steuervertreters des Verkäufers enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = ('VA', 'FC')] or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTaxRepresentativeTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA']
Gegen diese Regel validieren →

BR-G-01

fatal

Eine Rechnung, die eine Rechnungsposition, einen Nachlass auf Dokumentebene oder einen Zuschlag auf Dokumentebene enthält, bei der der USt.-Kategoriecode "Ausfuhr außerhalb der EU" ist, muss in der USt.-Aufschlüsselung genau einen USt.-Kategoriecode gleich "Ausfuhr außerhalb der EU" enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
(count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='G'])=0 and count(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='G'])=0 and count(//ram:CategoryTradeTax[ram:CategoryCode='G'])=0) or ( count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='G'])=1 and (exists(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='G']) or exists(//ram:CategoryTradeTax[ram:CategoryCode='G'])))
Gegen diese Regel validieren →

BR-G-02

fatal

Eine Rechnung, die eine Rechnungsposition enthält, bei der der USt.-Kategoriecode des in Rechnung gestellten Artikels "Ausfuhr außerhalb der EU" ist, muss die USt-IdNr. des Verkäufers oder die USt-IdNr. des Steuervertreters des Verkäufers enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
(//ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA'] or //ram:SellerTaxRepresentativeTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA'])
Gegen diese Regel validieren →

BR-IC-01

fatal

Eine Rechnung, die eine Rechnungsposition, einen Nachlass auf Dokumentebene oder einen Zuschlag auf Dokumentebene enthält, bei der der USt.-Kategoriecode "Innergemeinschaftliche Lieferung" ist, muss in der USt.-Aufschlüsselung genau einen USt.-Kategoriecode gleich "Innergemeinschaftliche Lieferung" enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
(count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='K'])=0 and count(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='K'])=0 and count(//ram:CategoryTradeTax[ram:CategoryCode='K'])=0) or ( count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='K'])=1 and (exists(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='K']) or exists(//ram:CategoryTradeTax[ram:CategoryCode='K'])))
Gegen diese Regel validieren →

BR-IC-02

fatal

Eine Rechnung, die eine Rechnungsposition enthält, bei der der USt.-Kategoriecode des in Rechnung gestellten Artikels "Innergemeinschaftliche Lieferung" ist, muss die USt-IdNr. des Verkäufers oder die USt-IdNr. des Steuervertreters des Verkäufers sowie die USt-IdNr. des Käufers enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
(//ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA'] or //ram:SellerTaxRepresentativeTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA']) and //ram:BuyerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA']
Gegen diese Regel validieren →

BR-O-01

fatal

Eine Rechnung, die eine Rechnungsposition, einen Nachlass auf Dokumentebene oder einen Zuschlag auf Dokumentebene enthält, bei der der USt.-Kategoriecode "Nicht der USt. unterliegend" ist, muss genau eine USt.-Aufschlüsselungsgruppe mit dem USt.-Kategoriecode gleich "Nicht der USt. unterliegend" enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
not(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='O']) or ( count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='O'])=1 and (exists(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='O']) or exists(//ram:CategoryTradeTax[ram:CategoryCode='O'])))
Gegen diese Regel validieren →

BR-S-01

fatal

Ein Teil der Rechnung nutzt den Normalsatz (Kategorie S), aber die Umsatzsteueraufschlüsselung enthält keinen Eintrag dafür.

Eine Rechnung, die eine Rechnungsposition, einen Nachlass auf Dokumentebene oder einen Zuschlag auf Dokumentebene enthält, bei der der USt.-Kategoriecode "Regelsatz" ist, muss in der USt.-Aufschlüsselung mindestens einen USt.-Kategoriecode gleich "Regelsatz" enthalten.

EN 16931CIIUBL
Gegen diese Regel validieren →

BR-S-02

fatal

Es wird der Normalsatz verwendet, daher muss die USt-IdNr. (oder Steuernummer) des Verkäufers auf der Rechnung stehen.

Eine Rechnung, die eine Rechnungsposition enthält, bei der der USt.-Kategoriecode des in Rechnung gestellten Artikels "Regelsatz" ist, muss die USt-IdNr. des Verkäufers, die Steuerregistrierungskennung des Verkäufers und/oder die USt-IdNr. des Steuervertreters des Verkäufers enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = ('VA', 'FC')] or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTaxRepresentativeTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA']
Gegen diese Regel validieren →

BR-Z-01

fatal

Eine Rechnung, die eine Rechnungsposition, einen Nachlass auf Dokumentebene oder einen Zuschlag auf Dokumentebene enthält, bei der der USt.-Kategoriecode "Nullsatz" ist, muss in der USt.-Aufschlüsselung genau einen USt.-Kategoriecode gleich "Nullsatz" enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
(count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='Z'])=0 and count(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='Z'])=0 and count(//ram:CategoryTradeTax[ram:CategoryCode='Z'])=0) or ( count(//ram:ApplicableHeaderTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='Z'])=1 and (exists(//ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax[ram:CategoryCode='Z']) or exists(//ram:CategoryTradeTax[ram:CategoryCode='Z'])))
Gegen diese Regel validieren →

BR-Z-02

fatal

Eine Rechnung, die eine Rechnungsposition enthält, bei der der USt.-Kategoriecode des in Rechnung gestellten Artikels "Nullsatz" ist, muss die USt-IdNr. des Verkäufers, die Steuerregistrierungskennung des Verkäufers und/oder die USt-IdNr. des Steuervertreters des Verkäufers enthalten.

EN 16931CIIUBL
Technischer Test (XPath)
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = ('VA', 'FC')] or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTaxRepresentativeTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID = 'VA']
Gegen diese Regel validieren →

EN 16931 — decimal rules (14)

BR-DEC-01

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Nachlassbetrag auf Dokumentebene (BT-92) ist 2.

EN 16931CIIUBLBT-92
Technischer Test (XPath)
string-length(substring-after(../ram:ActualAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-02

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Nachlassbasisbetrag auf Dokumentebene (BT-93) ist 2.

EN 16931CIIUBLBT-93
Technischer Test (XPath)
string-length(substring-after(../ram:BasisAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-05

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Zuschlagsbetrag auf Dokumentebene (BT-99) ist 2.

EN 16931CIIUBLBT-99
Technischer Test (XPath)
string-length(substring-after(../ram:ActualAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-06

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Zuschlagsbasisbetrag auf Dokumentebene (BT-100) ist 2.

EN 16931CIIUBLBT-100
Technischer Test (XPath)
string-length(substring-after(../ram:BasisAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-09

fatal

Die maximal zulässige Anzahl von Dezimalstellen für die Summe der Nettobeträge der Rechnungspositionen (BT-106) ist 2.

EN 16931CIIUBLBT-106
Technischer Test (XPath)
string-length(substring-after(ram:LineTotalAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-10

fatal

Die maximal zulässige Anzahl von Dezimalstellen für die Summe der Nachlässe auf Dokumentebene (BT-107) ist 2.

EN 16931CIIUBLBT-107
Technischer Test (XPath)
string-length(substring-after(ram:AllowanceTotalAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-11

fatal

Die maximal zulässige Anzahl von Dezimalstellen für die Summe der Zuschläge auf Dokumentebene (BT-108) ist 2.

EN 16931CIIUBLBT-108
Technischer Test (XPath)
string-length(substring-after(ram:ChargeTotalAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-12

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Gesamtbetrag der Rechnung ohne USt. (BT-109) ist 2.

EN 16931CIIUBLBT-109
Technischer Test (XPath)
string-length(substring-after(ram:TaxBasisTotalAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-13

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Gesamt-USt.-Betrag der Rechnung (BT-110) ist 2.

EN 16931CIIUBLBT-110
Technischer Test (XPath)
not(ram:TaxTotalAmount) or ram:TaxTotalAmount[(@currencyID =/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode and . = round(. * 100) div 100) or not (@currencyID =/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceCurrencyCode)]
Gegen diese Regel validieren →

BR-DEC-14

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Gesamtbetrag der Rechnung mit USt. (BT-112) ist 2.

EN 16931CIIUBLBT-112
Technischer Test (XPath)
string-length(substring-after(ram:GrandTotalAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-15

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Gesamt-USt.-Betrag der Rechnung in der Buchungswährung (BT-111) ist 2.

EN 16931CIIUBLBT-111
Technischer Test (XPath)
not(ram:TaxTotalAmount) or ram:TaxTotalAmount[(@currencyID =/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode and . = round(. * 100) div 100) or not (/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:TaxCurrencyCode)]
Gegen diese Regel validieren →

BR-DEC-16

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den bereits gezahlten Betrag (BT-113) ist 2.

EN 16931CIIUBLBT-113
Technischer Test (XPath)
string-length(substring-after(ram:TotalPrepaidAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-17

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den Rundungsbetrag (BT-114) ist 2.

EN 16931CIIUBLBT-114
Technischer Test (XPath)
string-length(substring-after(ram:RoundingAmount,'.'))<=2
Gegen diese Regel validieren →

BR-DEC-18

fatal

Die maximal zulässige Anzahl von Dezimalstellen für den fälligen Zahlungsbetrag (BT-115) ist 2.

EN 16931CIIUBLBT-115
Technischer Test (XPath)
string-length(substring-after(ram:DuePayableAmount,'.'))<=2
Gegen diese Regel validieren →

PEPPOL BIS 3.0 (38)

PEPPOL-COMMON-R042

fatal

Die dänische Organisationsnummer (CVR) MUSS im korrekten Format angegeben werden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
(string-length(string()) = 10 and substring(string(), 1, 2) = 'DK' and string-length(translate(substring(string(), 3, 8), '1234567890', '')) = 0) or (string-length(string()) = 8) and (string-length(translate(substring(string(), 1, 8),'1234567890', '')) = 0)
Gegen diese Regel validieren →

PEPPOL-COMMON-R049

fatal

Die schwedische Organisationsnummer MUSS im korrekten Format angegeben werden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
string-length(normalize-space()) = 10 and string(number(normalize-space())) != 'NaN' and u:checkSEOrgnr(normalize-space())
Gegen diese Regel validieren →

PEPPOL-EN16931-R001

fatal

Die Geschäftsprozesskennung (ProfileID) fehlt – für eine normale PEPPOL-Rechnung lautet sie urn:fdc:peppol.eu:2017:poacc:billing:01:1.0.

Der Geschäftsprozess MUSS angegeben werden.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
cbc:ProfileID
Gegen diese Regel validieren →

PEPPOL-EN16931-R003

fatal

Die Rechnung braucht eine Käuferreferenz oder eine Bestellnummer – fragen Sie Ihren Kunden, welche er verwendet.

Eine Käuferreferenz oder eine Bestellreferenz MUSS angegeben werden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
cbc:BuyerReference or cac:OrderReference/cbc:ID
Gegen diese Regel validieren →

PEPPOL-EN16931-R004

fatal

Die Spezifikationskennung (CustomizationID) ist nicht die von PEPPOL BIS 3.0 – die Datei wurde womöglich für ein anderes Format erstellt.

Die Spezifikationskennung MUSS den Wert 'urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0' haben.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
starts-with(normalize-space(cbc:CustomizationID/text()), 'urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0')
Gegen diese Regel validieren →

PEPPOL-EN16931-R005

fatal

Der Code der USt.-Buchungswährung MUSS sich vom Code der Rechnungswährung unterscheiden, sofern angegeben.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
not(normalize-space(text()) = normalize-space(../cbc:DocumentCurrencyCode/text()))
Gegen diese Regel validieren →

PEPPOL-EN16931-R008

fatal

Das Dokument enthält ein leeres Element – ein XML-Tag ohne Wert. Füllen Sie das Feld aus oder entfernen Sie es, statt es leer zu lassen.

Das Dokument DARF keine leeren Elemente enthalten.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
false()
Gegen diese Regel validieren →

PEPPOL-EN16931-R010

fatal

Die elektronische Adresse des Käufers (Peppol-ID) fehlt – an sie wird die Rechnung im Peppol-Netzwerk zugestellt.

Die elektronische Adresse des Käufers MUSS angegeben werden.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
cbc:EndpointID
Gegen diese Regel validieren →

PEPPOL-EN16931-R043

fatal

Der Wert des ChargeIndicator für Nachlass/Zuschlag MUSS 'true' oder 'false' sein.

PEPPOL BIS 3.0XRechnung 3.xUBL
Technischer Test (XPath)
normalize-space(cbc:ChargeIndicator/text()) = 'true' or normalize-space(cbc:ChargeIndicator/text()) = 'false'
Gegen diese Regel validieren →

PEPPOL-EN16931-R046

fatal

Wenn ein Bruttopreis angegeben ist, muss der Nettopreis dem Bruttopreis abzüglich des Preisnachlasses entsprechen.

Der Nettopreis des Artikels MUSS gleich (Bruttopreis - Nachlassbetrag) sein, wenn ein Bruttopreis angegeben ist.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
not(cbc:BaseAmount) or xs:decimal(../cbc:PriceAmount) = xs:decimal(cbc:BaseAmount) - xs:decimal(cbc:Amount)
Gegen diese Regel validieren →

PEPPOL-EN16931-R051

fatal

Ein Betrag hat eine andere Währung als die Rechnung – alle Beträge müssen in der Rechnungswährung stehen (nur die Umsatzsteuer in Buchungswährung darf abweichen).

Alle currencyID-Attribute müssen denselben Wert wie der Rechnungswährungscode (BT-5) haben, mit Ausnahme des Gesamt-USt.-Betrags der Rechnung in der Buchungswährung (BT-111).

PEPPOL BIS 3.0UBLBT-5BT-111
Technischer Test (XPath)
@currencyID = $documentCurrencyCode
Gegen diese Regel validieren →

PEPPOL-EN16931-R053

fatal

Es muss genau eine Umsatzsteuersumme mit Aufschlüsselung in der Rechnungswährung geben.

Es DARF nur eine Steuersumme mit Steuerteilbeträgen angegeben werden.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
count(cac:TaxTotal[cac:TaxSubtotal]) = 1
Gegen diese Regel validieren →

PEPPOL-EN16931-R054

fatal

Es DARF nur eine Steuersumme ohne Steuerteilbeträge angegeben werden, wenn der Steuerwährungscode angegeben ist.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
count(cac:TaxTotal[not(cac:TaxSubtotal)]) = (if (cbc:TaxCurrencyCode) then 1 else 0)
Gegen diese Regel validieren →

PEPPOL-EN16931-R055

fatal

Der Gesamt-USt.-Betrag der Rechnung und der Gesamt-USt.-Betrag der Rechnung in der Buchungswährung MÜSSEN dasselbe Vorzeichen haben.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
not(cbc:TaxCurrencyCode) or (cac:TaxTotal/cbc:TaxAmount[@currencyID=normalize-space(../../cbc:TaxCurrencyCode)] <= 0 and cac:TaxTotal/cbc:TaxAmount[@currencyID=normalize-space(../../cbc:DocumentCurrencyCode)] <= 0) or (cac:TaxTotal/cbc:TaxAmount[@currencyID=normalize-space(../../cbc:TaxCurrencyCode)] >= 0 and cac:TaxTotal/cbc:TaxAmount[@currencyID=normalize-space(../../cbc:DocumentCurrencyCode)] >= 0)
Gegen diese Regel validieren →

PEPPOL-EN16931-R101

fatal

Das Element Dokumentreferenz kann nur für das Objekt der Rechnungsposition verwendet werden.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
(not(cac:DocumentReference) or (cac:DocumentReference/cbc:DocumentTypeCode='130'))
Gegen diese Regel validieren →

PEPPOL-EN16931-R110

fatal

Der Zeitraum einer Position beginnt vor dem Rechnungszeitraum – Positionszeiträume müssen innerhalb davon liegen.

Das Startdatum des Positionszeitraums MUSS innerhalb des Rechnungszeitraums liegen.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
xs:date(text()) >= xs:date(../../../cac:InvoicePeriod/cbc:StartDate)
Gegen diese Regel validieren →

PEPPOL-EN16931-R111

fatal

Der Zeitraum einer Position endet nach dem Rechnungszeitraum – Positionszeiträume müssen innerhalb davon liegen.

Das Enddatum des Positionszeitraums MUSS innerhalb des Rechnungszeitraums liegen.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
xs:date(text()) <= xs:date(../../../cac:InvoicePeriod/cbc:EndDate)
Gegen diese Regel validieren →

PEPPOL-EN16931-R120

fatal

Der Nettobetrag einer Position entspricht nicht Menge × Nettopreis (geteilt durch die Preisbasismenge) zuzüglich Zuschlägen und abzüglich Nachlässen der Position.

Der Nettobetrag der Rechnungsposition MUSS gleich (in Rechnung gestellte Menge * (Nettopreis des Artikels / Preisbasismenge des Artikels) + Summe der Zuschlagsbeträge der Rechnungsposition - Summe der Nachlassbeträge der Rechnungsposition) sein.

PEPPOL BIS 3.0XRechnung 3.xUBL
Technischer Test (XPath)
u:slack($lineExtensionAmount, ($quantity * ($priceAmount div $baseQuantity)) + $chargesTotal - $allowancesTotal, 0.02)
Gegen diese Regel validieren →

PEPPOL-EN16931-R121

fatal

Die Preisbasismenge muss größer als null sein – meist 1.

Die Basismenge MUSS eine positive Zahl größer als null sein.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
not(cac:Price/cbc:BaseQuantity) or xs:decimal(cac:Price/cbc:BaseQuantity) > 0
Gegen diese Regel validieren →

PEPPOL-EN16931-R130

fatal

Die Preisbasismenge hat eine andere Einheit als die berechnete Menge – verwenden Sie für beide denselben Einheitencode.

Der Einheitencode der Preisbasismenge MUSS mit dem der in Rechnung gestellten Menge übereinstimmen.

PEPPOL BIS 3.0XRechnung 3.xCIIUBL
Technischer Test (XPath)
not($hasQuantity) or @unitCode = $quantity/@unitCode
Gegen diese Regel validieren →

XRechnung (Germany) (31)

BR-DE-1

fatal

XRechnung verlangt Zahlungsanweisungen – geben Sie die Zahlungsart (z. B. Überweisung) mit Ihren Kontodaten an.

Eine Rechnung (INVOICE) muss Angaben zu "PAYMENT INSTRUCTIONS" (BG-16) enthalten.

XRechnung 3.xCIIUBLBG-16
Technischer Test (XPath)
rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementPaymentMeans
Gegen diese Regel validieren →

BR-DE-2

fatal

XRechnung verlangt einen Ansprechpartner des Verkäufers – Person oder Abteilung, Telefonnummer und E-Mail-Adresse.

Die Gruppe "SELLER CONTACT" (BG-6) muss übermittelt werden.

XRechnung 3.xCIIUBLBG-6
Technischer Test (XPath)
ram:DefinedTradeContact
Gegen diese Regel validieren →

BR-DE-5

fatal

Das Element "Seller contact point" (BT-41) muss übermittelt werden.

XRechnung 3.xCIIUBLBT-41
Technischer Test (XPath)
(ram:PersonName,ram:DepartmentName)[boolean(normalize-space(.))]
Gegen diese Regel validieren →

BR-DE-6

fatal

Das Element "Seller contact telephone number" (BT-42) muss übermittelt werden.

XRechnung 3.xCIIUBLBT-42
Technischer Test (XPath)
ram:TelephoneUniversalCommunication/ram:CompleteNumber[boolean(normalize-space(.))]
Gegen diese Regel validieren →

BR-DE-7

fatal

Das Element "Seller contact email address" (BT-43) muss übermittelt werden.

XRechnung 3.xCIIUBLBT-43
Technischer Test (XPath)
ram:EmailURIUniversalCommunication/ram:URIID[boolean(normalize-space(.))]
Gegen diese Regel validieren →

BR-DE-10

fatal

Das Element "Deliver to city" (BT-77) muss übermittelt werden, wenn die Gruppe "DELIVER TO ADDRESS" (BG-15) übermittelt wird.

XRechnung 3.xCIIUBLBT-77BG-15
Technischer Test (XPath)
ram:CityName[boolean(normalize-space(.))]
Gegen diese Regel validieren →

BR-DE-11

fatal

Das Element "Deliver to post code" (BT-78) muss übermittelt werden, wenn die Gruppe "DELIVER TO ADDRESS" (BG-15) übermittelt wird.

XRechnung 3.xCIIUBLBT-78BG-15
Technischer Test (XPath)
ram:PostcodeCode[boolean(normalize-space(.))]
Gegen diese Regel validieren →

BR-DE-14

fatal

Das Element "VAT category rate" (BT-119) muss übermittelt werden.

XRechnung 3.xCIIUBLBT-119
Technischer Test (XPath)
ram:RateApplicablePercent[boolean(normalize-space(.))]
Gegen diese Regel validieren →

BR-DE-15

fatal

Die Käuferreferenz fehlt – bei Rechnungen an die öffentliche Hand ist das die Leitweg-ID, die Ihnen die Behörde mitgeteilt hat.

Das Element "Buyer reference" (BT-10) muss übermittelt werden. Bei Rechnungen an die öffentliche Verwaltung ist dies die Leitweg-ID.

XRechnung 3.xCIIUBLBT-10
Technischer Test (XPath)
rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerReference[boolean(normalize-space(.))]
Gegen diese Regel validieren →

BR-DE-16

fatal

Bei diesen Umsatzsteuerkategorien muss die USt-IdNr., die Steuernummer oder der Steuervertreter des Verkäufers angegeben sein.

Wenn in einer Rechnung die Steuercodes S, Z, E, AE, K, G, L oder M verwendet werden, muss mindestens eines der Elemente "Seller VAT identifier" (BT-31), "Seller tax registration identifier" (BT-32) oder "SELLER TAX REPRESENTATIVE PARTY" (BG-11) übermittelt werden.

XRechnung 3.xCIIUBLBT-31BT-32BG-11
Technischer Test (XPath)
not((rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:TypeCode = 'VAT' and rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:CategoryCode = ('S', 'Z', 'E', 'AE', 'K', 'G', 'L', 'M')) or (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge/ram:CategoryTradeTax = 'VAT' and rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeAllowanceCharge/ram:CategoryTradeTax/ram:CategoryCode = ('S', 'Z', 'E', 'AE', 'K', 'G', 'L', 'M')) or (rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:TypeCode = 'VAT' and rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:CategoryCode = ('S', 'Z', 'E', 'AE', 'K', 'G', 'L', 'M'))) or ((rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:SpecifiedTaxRegistration/ram:ID[@schemeID='VA' or @schemeID='FC'][boolean(normalize-space(.))], rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTaxRepresentativeTradeParty))
Gegen diese Regel validieren →

BR-DE-17

warning

Mit dem Element "Invoice type code" (BT-3) sollen ausschließlich folgende Codes aus der Codeliste UNTDID 1001 übermittelt werden: 326, 380, 381, 384, 389, 875, 876, 877.

XRechnung 3.xCIIUBLBT-3
Technischer Test (XPath)
rsm:ExchangedDocument/ram:TypeCode = ('326', '380', '384', '389', '381', '875', '876', '877')
Gegen diese Regel validieren →

BR-DE-18

fatal

Skonto-Angaben in den Zahlungsbedingungen "Payment terms" (BT-20) müssen dem vorgeschriebenen Format #SKONTO# entsprechen.

XRechnung 3.xCIIUBLBT-20
Technischer Test (XPath)
every $line in rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:Description[1]/tokenize(. , '(\r?\n)')[starts-with( normalize-space(.) , '#')] satisfies matches ( normalize-space ($line), $XR-SKONTO-REGEX ) and matches( rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:Description[1]/tokenize(. , '#.+#')[last()], '^\s*\n' )
Gegen diese Regel validieren →

BR-DE-19

warning

Bei einer SEPA-Überweisung muss die Kontonummer eine gültige IBAN sein.

"Payment account identifier" (BT-84) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 58 SEPA als Zahlungsmittel gefordert wird.

XRechnung 3.xCIIUBLBT-84BT-81
Technischer Test (XPath)
not(ram:TypeCode = '58') or matches(normalize-space(replace(ram:PayeePartyCreditorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')), '^[A-Z]{2}[0-9]{2}[a-zA-Z0-9]{0,30}$') and xs:integer(string-join(for $cp in string-to-codepoints(concat(substring(normalize-space(replace(ram:PayeePartyCreditorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),5),upper-case(substring(normalize-space(replace(ram:PayeePartyCreditorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),1,2)),substring(normalize-space(replace(ram:PayeePartyCreditorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),3,2))) return (if($cp > 64) then string($cp - 55) else string($cp - 48)),'')) mod 97 = 1
Gegen diese Regel validieren →

BR-DE-20

warning

"Debited account identifier" (BT-91) soll eine korrekte IBAN enthalten, wenn in "Payment means type code" (BT-81) mit dem Code 59 SEPA als Zahlungsmittel gefordert wird.

XRechnung 3.xCIIUBLBT-91BT-81
Technischer Test (XPath)
not(ram:TypeCode = '59') or matches(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')), '^[A-Z]{2}[0-9]{2}[a-zA-Z0-9]{0,30}$') and xs:decimal(string-join(for $cp in string-to-codepoints(concat(substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),5),upper-case(substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),1,2)),substring(normalize-space(replace(ram:PayerPartyDebtorFinancialAccount/ram:IBANID, '([ \n\r\t\s])', '')),3,2))) return (if($cp > 64) then string($cp - 55) else string($cp - 48)),'')) mod 97 = 1
Gegen diese Regel validieren →

BR-DE-21

warning

Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.

XRechnung 3.xCIIUBLBT-24
Technischer Test (XPath)
ram:GuidelineSpecifiedDocumentContextParameter/ram:ID = $XR-CIUS-ID or ram:GuidelineSpecifiedDocumentContextParameter/ram:ID = $XR-EXTENSION-ID
Gegen diese Regel validieren →

BR-DE-22

fatal

Das "filename"-Attribut aller "EmbeddedDocumentBinaryObject"-Elemente muss eindeutig sein.

XRechnung 3.xCIIUBL
Technischer Test (XPath)
count(//ram:AdditionalReferencedDocument) = count(//ram:AdditionalReferencedDocument[not(./ram:AttachmentBinaryObject/@filename = preceding-sibling::ram:AdditionalReferencedDocument/ram:AttachmentBinaryObject/@filename)])
Gegen diese Regel validieren →

BR-DE-23-a

fatal

Wenn BT-81 "Payment means type code" einen Schlüssel für Überweisungen enthält (30, 58), muss BG-17 "CREDIT TRANSFER" übermittelt werden.

XRechnung 3.xCIIUBLBT-81BG-17
Technischer Test (XPath)
ram:PayeePartyCreditorFinancialAccount
Gegen diese Regel validieren →

BR-DE-23-b

fatal

Wenn BT-81 "Payment means type code" einen Schlüssel für Überweisungen enthält (30, 58), dürfen BG-18 und BG-19 nicht übermittelt werden.

XRechnung 3.xCIIUBLBT-81BG-18BG-19
Technischer Test (XPath)
not(ram:ApplicableTradeSettlementFinancialCard) and not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID or ram:PayerPartyDebtorFinancialAccount/ram:IBANID)
Gegen diese Regel validieren →

BR-DE-24-a

fatal

Wenn BT-81 "Payment means type code" einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), muss genau BG-18 "PAYMENT CARD INFORMATION" übermittelt werden.

XRechnung 3.xCIIUBLBT-81BG-18
Technischer Test (XPath)
ram:ApplicableTradeSettlementFinancialCard
Gegen diese Regel validieren →

BR-DE-24-b

fatal

Wenn BT-81 "Payment means type code" einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), dürfen BG-17 und BG-19 nicht übermittelt werden.

XRechnung 3.xCIIUBLBT-81BG-17BG-19
Technischer Test (XPath)
not(ram:PayeePartyCreditorFinancialAccount) and not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID or ram:PayerPartyDebtorFinancialAccount/ram:IBANID)
Gegen diese Regel validieren →

BR-DE-25-a

fatal

Wenn BT-81 "Payment means type code" einen Schlüssel für Lastschriften enthält (59), muss genau BG-19 "DIRECT DEBIT" übermittelt werden.

XRechnung 3.xCIIUBLBT-81BG-19
Technischer Test (XPath)
/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID or ram:PayerPartyDebtorFinancialAccount/ram:IBANID
Gegen diese Regel validieren →

BR-DE-25-b

fatal

Wenn BT-81 "Payment means type code" einen Schlüssel für Lastschriften enthält (59), dürfen BG-17 und BG-18 nicht übermittelt werden.

XRechnung 3.xCIIUBLBT-81BG-17BG-18
Technischer Test (XPath)
not(ram:PayeePartyCreditorFinancialAccount) and not(ram:ApplicableTradeSettlementFinancialCard)
Gegen diese Regel validieren →

BR-DE-26

warning

Wenn im Element "Invoice type code" (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll "PRECEDING INVOICE REFERENCE" (BG-3) mindestens einmal vorhanden sein.

XRechnung 3.xCIIUBLBT-3BG-3
Technischer Test (XPath)
not(rsm:ExchangedDocument/ram:TypeCode = 384) or (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument)
Gegen diese Regel validieren →

BR-DE-27

warning

In "Seller contact telephone number" (BT-42) sollen mindestens drei Ziffern enthalten sein.

XRechnung 3.xCIIUBLBT-42
Technischer Test (XPath)
matches(normalize-space(ram:TelephoneUniversalCommunication/ram:CompleteNumber), $XR-TELEPHONE-REGEX)
Gegen diese Regel validieren →

BR-DE-28

warning

In "Seller contact email address" (BT-43) soll genau ein @-Zeichen enthalten sein, das nicht von einem Leerzeichen oder Punkt, aber von mindestens zwei Zeichen auf beiden Seiten flankiert wird. Ein Punkt soll nicht am Anfang oder am Ende stehen.

XRechnung 3.xCIIUBLBT-43
Technischer Test (XPath)
matches(normalize-space(ram:EmailURIUniversalCommunication/ram:URIID), $XR-EMAIL-REGEX)
Gegen diese Regel validieren →

BR-DE-30

fatal

Wenn "DIRECT DEBIT" (BG-19) vorhanden ist, muss "Bank assigned creditor identifier" (BT-90) übermittelt werden.

XRechnung 3.xCIIUBLBG-19BT-90
Technischer Test (XPath)
(($BT-89-path or $BT-91-path) and $BT-90-path) or $BG-19-not-existing
Gegen diese Regel validieren →

BR-DE-31

fatal

Wenn "DIRECT DEBIT" (BG-19) vorhanden ist, muss "Debited account identifier" (BT-91) übermittelt werden.

XRechnung 3.xCIIUBLBG-19BT-91
Technischer Test (XPath)
(($BT-89-path or $BT-90-path) and $BT-91-path) or $BG-19-not-existing
Gegen diese Regel validieren →

National CIUS (DK) (13)

DK-R-002

fatal

Dänische Lieferanten MÜSSEN die juristische Person (CVR-Nummer) angeben.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
(normalize-space(cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID/text()) != '')
Gegen diese Regel validieren →

DK-R-003

warning

Dänische Lieferanten MÜSSEN die Kennung der juristischen Person (CVR-Nummer) angeben, wenn der Artikelklassifikationscode TST ist.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode/@listID = 'TST') and not((cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode/@listVersionID = '19.05.01') or (cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode/@listVersionID = '19.0501') or (cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode/@listVersionID = '26.08.01') or (cac:Item/cac:CommodityClassification/cbc:ItemClassificationCode/@listVersionID = '26.0801') ) )
Gegen diese Regel validieren →

DK-R-004

fatal

Dänische Lieferanten MÜSSEN einen Grundtext angeben, wenn der Nachlass-/Zuschlagsgrundcode ZZZ ist.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((cbc:AllowanceChargeReasonCode = 'ZZZ') and not(((string-length(normalize-space(cbc:AllowanceChargeReason/text())) = 4) and (number(cbc:AllowanceChargeReason) >= 0) and (number(cbc:AllowanceChargeReason) <= 9999)) or (((cbc:AllowanceChargeReason and contains(cbc:AllowanceChargeReason, '#') and not(starts-with(cbc:AllowanceChargeReason, '#')) and not(ends-with(cbc:AllowanceChargeReason, '#')))) ) ) )
Gegen diese Regel validieren →

DK-R-005

fatal

Für dänische Lieferanten sind folgende Zahlungsmittelcodes zulässig: 1, 10, 31, 42, 48, 49, 50, 58, 59, 93 und 97.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
contains(' 1 10 31 42 48 49 50 58 59 93 97 ', concat(' ', cbc:PaymentMeansCode, ' '))
Gegen diese Regel validieren →

DK-R-006

fatal

Für dänische Lieferanten sind Bankkonto- und Bankleitzahlen bei Zahlung per Banküberweisung obligatorisch.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not(((cbc:PaymentMeansCode = '31') or (cbc:PaymentMeansCode = '42')) and not((normalize-space(cac:PayeeFinancialAccount/cbc:ID/text()) != '') and (normalize-space(cac:PayeeFinancialAccount/cac:FinancialInstitutionBranch/cbc:ID/text()) != '')) )
Gegen diese Regel validieren →

DK-R-007

fatal

Für dänische Lieferanten sind die PaymentMandate-ID und die Konto-ID des Verkäufers bei Lastschriften obligatorisch.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((cbc:PaymentMeansCode = '49') and not((normalize-space(cac:PaymentMandate/cbc:ID/text()) != '') and (normalize-space(cac:PaymentMandate/cac:PayerFinancialAccount/cbc:ID/text()) != '')) )
Gegen diese Regel validieren →

DK-R-008

fatal

Für dänische Lieferanten ist die primäre Kontonummer der PaymentCard bei Kartenzahlung obligatorisch.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((cbc:PaymentMeansCode = '50') and not(((substring(cbc:PaymentID, 1, 3) = '01#') or (substring(cbc:PaymentID, 1, 3) = '04#') or (substring(cbc:PaymentID, 1, 3) = '15#')) and matches(cac:PayeeFinancialAccount/cbc:ID, '^[0-9]{7,8}$') ) )
Gegen diese Regel validieren →

DK-R-009

fatal

Für dänische Lieferanten ist der Name des PaymentCard-Inhabers bei Kartenzahlung obligatorisch.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((cbc:PaymentMeansCode = '50') and ((substring(cbc:PaymentID, 1, 3) = '04#') or (substring(cbc:PaymentID, 1, 3) = '15#')) and not(string-length(cbc:PaymentID) = 19) )
Gegen diese Regel validieren →

DK-R-010

fatal

Für dänische Lieferanten ist die FinancialInstitutionBranch-ID bei Zahlungsart 93 obligatorisch.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((cbc:PaymentMeansCode = '93') and not(((substring(cbc:PaymentID, 1, 3) = '71#') or (substring(cbc:PaymentID, 1, 3) = '73#') or (substring(cbc:PaymentID, 1, 3) = '75#')) and (string-length(cac:PayeeFinancialAccount/cbc:ID/text()) = 8) ) )
Gegen diese Regel validieren →

DK-R-011

fatal

Für dänische Lieferanten ist die PayeeFinancialAccount-ID bei Zahlungsart 93 obligatorisch.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((cbc:PaymentMeansCode = '93') and ((substring(cbc:PaymentID, 1, 3) = '71#') or (substring(cbc:PaymentID, 1, 3) = '75#')) and not((string-length(cbc:PaymentID) = 18) or (string-length(cbc:PaymentID) = 19)) )
Gegen diese Regel validieren →

DK-R-013

fatal

Für dänische Lieferanten sind für die InvoicedQuantity nur positive Werte zulässig.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((boolean(cbc:ID)) and (normalize-space(cbc:ID/@schemeID) = '') )
Gegen diese Regel validieren →

DK-R-014

fatal

Für dänische Lieferanten muss der DocumentCurrencyCode mit dem TaxCurrencyCode übereinstimmen, sofern angegeben.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not(((boolean(cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID)) and (normalize-space(cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID/@schemeID) != '0184')) )
Gegen diese Regel validieren →

DK-R-016

fatal

Für dänische Gutschriften mit dänischem Käufer muss eine Referenz auf eine vorausgehende Rechnung angegeben werden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
not((boolean(/ubl-creditnote:CreditNote) and ($DKCustomerCountry = 'DK')) and (number(cac:LegalMonetaryTotal/cbc:PayableAmount/text()) < 0) )
Gegen diese Regel validieren →

National CIUS (GR) (17)

GR-R-001-2

fatal

Wenn der Lieferant griechisch ist, muss das erste Segment der Rechnungs-ID eine gültige 9-stellige Steuer-ID sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
string-length(normalize-space($IdSegments[1])) = 9 and u:TinVerification($IdSegments[1]) and ($IdSegments[1] = /*/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VAT']/substring(cbc:CompanyID, 3, 9) or $IdSegments[1] = /*/cac:TaxRepresentativeParty/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VAT']/substring(cbc:CompanyID, 3, 9) )
Gegen diese Regel validieren →

GR-R-003

fatal

Für griechische Lieferanten muss die USt-IdNr. mit 'EL' beginnen und eine gültige TIN-Nummer sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
substring(.,1,2) = 'EL' and u:TinVerification(substring(.,3))
Gegen diese Regel validieren →

GR-R-004-1

fatal

Wenn der Lieferant griechisch ist, muss es eine MARK-Nummer geben.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
count(cac:AdditionalDocumentReference[cbc:DocumentDescription = '##M.AR.K##'])=1
Gegen diese Regel validieren →

GR-R-006

fatal

Für griechische Käufer MUSS die Rechnung deren USt-IdNr. enthalten.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
count(cac:PartyTaxScheme[normalize-space(cac:TaxScheme/cbc:ID) = 'VAT']/cbc:CompanyID)=1 and substring(cac:PartyTaxScheme[normalize-space(cac:TaxScheme/cbc:ID) = 'VAT']/cbc:CompanyID,1,2) = 'EL' and u:TinVerification(substring(cac:PartyTaxScheme[normalize-space(cac:TaxScheme/cbc:ID) = 'VAT']/cbc:CompanyID,3))
Gegen diese Regel validieren →

GR-R-008-2

fatal

Wenn der Lieferant griechisch ist, sollte es nicht mehr als eine Rechnungs-URL geben.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
(count(cac:AdditionalDocumentReference[cbc:DocumentDescription = '##INVOICE|URL##']) = 0 ) or (count(cac:AdditionalDocumentReference[cbc:DocumentDescription = '##INVOICE|URL##']) = 1 )
Gegen diese Regel validieren →

GR-R-009

fatal

Griechische Lieferanten, die eine Rechnung über das PEPPOL-Netzwerk senden, müssen eine korrekte TIN-Nummer als elektronische Adresse verwenden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
./@schemeID='9933' and u:TinVerification(.)
Gegen diese Regel validieren →

GR-R-010

fatal

Griechische Lieferanten, die eine Rechnung über das PEPPOL-Netzwerk an einen griechischen Käufer senden, müssen eine korrekte TIN-Nummer als elektronische Adresse verwenden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
./@schemeID='9933' and u:TinVerification(.)
Gegen diese Regel validieren →

National CIUS (IS) (6)

IS-R-002

fatal

Wenn der Verkäufer isländisch ist, muss die rechtliche Kennung des Verkäufers enthalten sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
exists(cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID) and cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:CompanyID/@schemeID = '0196'
Gegen diese Regel validieren →

IS-R-003

fatal

Wenn der Verkäufer isländisch ist, muss seine Adresse mit Straßenname und Postleitzahl enthalten sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
exists(cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:StreetName) and exists(cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:PostalZone)
Gegen diese Regel validieren →

IS-R-004

fatal

Wenn Verkäufer und Käufer isländisch sind, muss die Rechnung die isländische rechtliche Kennung des Käufers enthalten.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
exists(cac:Party/cac:PartyLegalEntity/cbc:CompanyID) and cac:Party/cac:PartyLegalEntity/cbc:CompanyID/@schemeID = '0196'
Gegen diese Regel validieren →

IS-R-005

fatal

Wenn Verkäufer und Käufer isländisch sind, muss die Rechnung die Adresse des Käufers mit Straßenname und Postleitzahl enthalten.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
exists(cac:Party/cac:PostalAddress/cbc:StreetName) and exists(cac:Party/cac:PostalAddress/cbc:PostalZone)
Gegen diese Regel validieren →

IS-R-006

fatal

Wenn der Verkäufer isländisch ist und das Zahlungsmittel eine Lastschrift ist, muss eine gültige PayeeFinancialAccount-ID angegeben werden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
exists(cac:PaymentMeans[cbc:PaymentMeansCode = '9']/cac:PayeeFinancialAccount/cbc:ID) and string-length(normalize-space(cac:PaymentMeans[cbc:PaymentMeansCode = '9']/cac:PayeeFinancialAccount/cbc:ID)) = 12 or not(exists(cac:PaymentMeans[cbc:PaymentMeansCode = '9']))
Gegen diese Regel validieren →

IS-R-007

fatal

Wenn der Verkäufer isländisch ist und das Zahlungsmittel eine Banküberweisung ist, muss eine gültige PayeeFinancialAccount-ID angegeben werden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
exists(cac:PaymentMeans[cbc:PaymentMeansCode = '42']/cac:PayeeFinancialAccount/cbc:ID) and string-length(normalize-space(cac:PaymentMeans[cbc:PaymentMeansCode = '42']/cac:PayeeFinancialAccount/cbc:ID)) = 12 or not(exists(cac:PaymentMeans[cbc:PaymentMeansCode = '42']))
Gegen diese Regel validieren →

National CIUS (IT) (4)

IT-R-001

fatal

Für italienische Lieferanten muss BT-32 eine Mindestlänge von 11 und eine Höchstlänge von 16 haben.

PEPPOL BIS 3.0UBLBT-32
Technischer Test (XPath)
matches(normalize-space(cbc:CompanyID),'^[A-Z0-9]{11,16}$')
Gegen diese Regel validieren →

National CIUS (NL) (9)

NL-R-001

fatal

Für Lieferanten in den Niederlanden MUSS das Dokument eine Rechnungsreferenz enthalten, wenn es sich um eine Gutschrift handelt.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
/*/cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID
Gegen diese Regel validieren →

NL-R-002

fatal

Für Lieferanten in den Niederlanden MUSS die Adresse des Lieferanten Straßenname, Stadt und Postleitzahl enthalten.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
cbc:StreetName and cbc:CityName and cbc:PostalZone
Gegen diese Regel validieren →

NL-R-003

fatal

Für Lieferanten in den Niederlanden MUSS die Kennung der juristischen Person entweder eine KVK- oder eine OIN-Nummer sein (schemeID 0106 oder 0190).

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
(contains(concat(' ', string-join(@schemeID, ' '), ' '), ' 0106 ') or contains(concat(' ', string-join(@schemeID, ' '), ' '), ' 0190 ')) and (normalize-space(.) != '')
Gegen diese Regel validieren →

NL-R-004

fatal

Für Lieferanten in den Niederlanden MUSS die Adresse des Kunden Straßenname, Stadt und Postleitzahl enthalten, wenn der Kunde in den Niederlanden ansässig ist.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
cbc:StreetName and cbc:CityName and cbc:PostalZone
Gegen diese Regel validieren →

NL-R-005

fatal

Für Lieferanten in den Niederlanden MUSS die Kennung der juristischen Person des Kunden entweder eine KVK- oder eine OIN-Nummer sein, wenn der Kunde in den Niederlanden ansässig ist.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
(contains(concat(' ', string-join(@schemeID, ' '), ' '), ' 0106 ') or contains(concat(' ', string-join(@schemeID, ' '), ' '), ' 0190 ')) and (normalize-space(.) != '')
Gegen diese Regel validieren →

NL-R-006

fatal

Für Lieferanten in den Niederlanden MUSS die Adresse des Steuervertreters Straßenname, Stadt und Postleitzahl enthalten, wenn der Steuervertreter in den Niederlanden ansässig ist.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
cbc:StreetName and cbc:CityName and cbc:PostalZone
Gegen diese Regel validieren →

NL-R-007

fatal

Für Lieferanten in den Niederlanden MUSS der Lieferant ein Zahlungsmittel angeben, wenn die Zahlung vom Kunden an den Lieferanten erfolgt.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
(/ubl-invoice:Invoice and xs:decimal(cbc:PayableAmount) <= 0.0) or (/ubl-creditnote:CreditNote and xs:decimal(cbc:PayableAmount) >= 0.0) or (//cac:PaymentMeans)
Gegen diese Regel validieren →

NL-R-008

fatal

Für Lieferanten in den Niederlanden sollte der Zahlungsmittelcode 30, 48, 49, 57, 58 oder 59 sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
normalize-space(cbc:PaymentMeansCode) = '30' or normalize-space(cbc:PaymentMeansCode) = '48' or normalize-space(cbc:PaymentMeansCode) = '49' or normalize-space(cbc:PaymentMeansCode) = '57' or normalize-space(cbc:PaymentMeansCode) = '58' or normalize-space(cbc:PaymentMeansCode) = '59'
Gegen diese Regel validieren →

NL-R-009

fatal

Für Lieferanten in den Niederlanden muss bei Verwendung einer Bestellpositionsreferenz eine Bestellreferenz auf Dokumentebene vorhanden sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
exists(/*/cac:OrderReference/cbc:ID)
Gegen diese Regel validieren →

National CIUS (NO) (2)

NO-R-001

fatal

Norwegische Lieferanten MÜSSEN die USt-IdNr. im korrekten Format angeben (12 Ziffern + 'MVA').

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
cac:PartyTaxScheme[normalize-space(cac:TaxScheme/cbc:ID) = 'VAT']/substring(cbc:CompanyID, 1, 2)='NO' and matches(cac:PartyTaxScheme[normalize-space(cac:TaxScheme/cbc:ID) = 'VAT']/substring(cbc:CompanyID,3), '^[0-9]{9}MVA$') and u:mod11(substring(cac:PartyTaxScheme[normalize-space(cac:TaxScheme/cbc:ID) = 'VAT']/cbc:CompanyID, 3, 9)) or not(cac:PartyTaxScheme[normalize-space(cac:TaxScheme/cbc:ID) = 'VAT']/substring(cbc:CompanyID, 1, 2)='NO')
Gegen diese Regel validieren →

NO-R-002

warning

Für norwegische Lieferanten müssen die meisten Rechnungsaussteller "Foretaksregisteret" an ihre Registrierung anhängen.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
normalize-space(cac:PartyTaxScheme[normalize-space(cac:TaxScheme/cbc:ID) = 'TAX']/cbc:CompanyID) = 'Foretaksregisteret'
Gegen diese Regel validieren →

National CIUS (SE) (13)

SE-R-001

fatal

Für schwedische Lieferanten müssen schwedische USt.-Nummern aus 14 Zeichen bestehen.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
string-length(normalize-space(cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VAT']/cbc:CompanyID)) = 14
Gegen diese Regel validieren →

SE-R-002

fatal

Für schwedische Lieferanten müssen die letzten 12 Zeichen der schwedischen USt.-Nummern numerisch sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
string(number(substring(cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = 'VAT']/cbc:CompanyID, 3, 12))) != 'NaN'
Gegen diese Regel validieren →

SE-R-005

fatal

Für schwedische Lieferanten muss bei Verwendung der Steuerregistrierungskennung des Verkäufers 'Godkänd för F-skatt' angegeben werden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
normalize-space(upper-case(.)) = 'GODKÄND FÖR F-SKATT'
Gegen diese Regel validieren →

SE-R-006

fatal

Für schwedische Lieferanten werden nur die Regel-USt.-Sätze 6, 12 oder 25 verwendet.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
number(cbc:Percent) = 25 or number(cbc:Percent) = 12 or number(cbc:Percent) = 6
Gegen diese Regel validieren →

SE-R-007

warning

Für schwedische Lieferanten, die Plusgiro verwenden, muss die Konto-ID numerisch sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
string(number(normalize-space(.))) != 'NaN'
Gegen diese Regel validieren →

SE-R-008

warning

Für schwedische Lieferanten, die Bankgiro verwenden, muss die Konto-ID numerisch sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
string(number(normalize-space(.))) != 'NaN'
Gegen diese Regel validieren →

SE-R-009

warning

Für schwedische Lieferanten, die Bankgiro verwenden, muss die Konto-ID 7-8 Zeichen haben.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
string-length(normalize-space(.)) = 7 or string-length(normalize-space(.)) = 8
Gegen diese Regel validieren →

SE-R-010

warning

Für schwedische Lieferanten, die Plusgiro verwenden, muss die Konto-ID 2-8 Zeichen haben.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
string-length(normalize-space(.)) >= 2 and string-length(normalize-space(.)) <= 8
Gegen diese Regel validieren →

SE-R-011

warning

Für schwedische Lieferanten, die schwedisches Bankgiro oder Plusgiro verwenden, ist dies korrekt durch den Code 30 für PaymentMeans und die FinancialInstitutionBranch-ID mit dem Code SE:BANKGIRO oder SE:PLUSGIRO anzugeben.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
false()
Gegen diese Regel validieren →

SE-R-012

warning

Für inländische Transaktionen zwischen schwedischen Handelspartnern sollte die Überweisung durch PaymentMeansCode="30" angegeben werden.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
false()
Gegen diese Regel validieren →

SE-R-013

fatal

Die letzte Ziffer einer schwedischen Organisationsnummer muss gemäß dem Luhn-Algorithmus gültig sein.

PEPPOL BIS 3.0UBL
Technischer Test (XPath)
u:checkSEOrgnr(normalize-space(cbc:CompanyID))
Gegen diese Regel validieren →

Häufig gestellte Fragen

Was ist eine PEPPOL- / EN-16931-Validierungsregel?

Es ist eine Geschäftsregel (gekennzeichnet durch einen Code wie BR-CO-13 oder PEPPOL-EN16931-R008), die eine E-Rechnung erfüllen muss, um nach dem europäischen Standard EN 16931 oder einer nationalen CIUS wie PEPPOL BIS 3.0 oder XRechnung gültig zu sein. Validatoren führen diese als Schematron formulierten Regeln gegen die Rechnungs-XML aus.

Was bedeutet eine „fatale“ Regel gegenüber einer „Warnung“?

Eine fatale Regel muss erfüllt sein, sonst wird die Rechnung vom Empfänger abgelehnt. Eine Warnung weist auf einen wahrscheinlichen Fehler hin, blockiert die Rechnung aber nicht. Die meisten BR-*- und PEPPOL-*-Regeln sind fatal; einige wenige sind Warnungen.

Wie behebe ich einen Regelverstoß wie BR-CO-13?

Lesen Sie die Regelmeldung – sie nennt genau, welche Geschäftsbegriffe (BT-/BG-Codes) vorhanden sein oder sich summieren müssen. Korrigieren Sie diese Felder in Ihrer Rechnung und validieren Sie erneut. aiDoks zeigt für jede hochgeladene Rechnung die fehlgeschlagene Regel-ID und -Meldung an.

Welche Formate verwenden diese Regeln?

EN 16931 ist der gemeinsame Kern. PEPPOL BIS 3.0, XRechnung, Factur-X/ZUGFeRD und nationale CIUS-Profile (Deutschland, Dänemark, Schweden, Italien, die Niederlande und andere) ergänzen ihre eigenen Regeln. Diese Seite deckt sie alle ab.

Was, wenn meine Regel hier nicht aufgeführt ist?

Keine Sorge – diese Seite hebt die häufigsten Regeln hervor, aber unser Validator prüft Ihre Rechnung immer gegen den vollständigen Regelsatz (jede EN-16931-, PEPPOL-, XRechnung- und Factur-X-Regel, einschließlich der hier nicht aufgeführten Syntax- und Codelisten-Prüfungen). Laden Sie Ihre Rechnung hoch und Sie erhalten jede zutreffende Regel – ob auf dieser Seite gelistet oder nicht.

Schluss mit dem Rätselraten, warum Ihre Rechnung fehlschlug

Laden Sie Ihre UBL-, CII- oder Factur-X-Rechnung hoch und aiDoks meldet jede fehlgeschlagene Regel mit ID und Meldung – kostenlos, ohne Anmeldung.