E-Rechnungs-Fehler nachschlagen

Die XRechnung verlangt in jeder Rechnung Angaben zum Zahlungsweg. Häufigster Auslöser: Die Software lässt den Block weg, weil keine Bankverbindung hinterlegt ist.

Die XRechnung verlangt eine Kontaktgruppe beim Verkäufer (BG-6) mit Name, Telefon und E-Mail. Warum Briefkopfangaben dafür nicht genügen.

Die XRechnung verlangt den Ort in der Verkäuferadresse als eigenes Datenfeld. Häufigster Auslöser: Die Adresse steckt komplett in einer Freitextzeile.

Die XRechnung verlangt die Postleitzahl in der Verkäuferadresse als eigenes Feld. Häufigster Auslöser: Die PLZ steht mit im Ortsfeld statt in BT-38.

Die XRechnung verlangt in der Verkäufer-Kontaktgruppe einen benannten Ansprechpartner (BT-41). Häufigster Auslöser: Telefon und E-Mail sind hinterlegt, ein Name fehlt.

Die XRechnung verlangt eine Telefonnummer in der Verkäufer-Kontaktgruppe (BT-42). Die Nummer im Briefkopf genügt nicht, sie muss als strukturiertes Feld in der XML stehen.

Die XRechnung verlangt eine E-Mail-Adresse in der Verkäufer-Kontaktgruppe (BT-43). Häufigster Auslöser: Die Adresse steht nur im PDF-Layout, nicht im strukturierten Feld.

Die XRechnung verlangt zwingend eine Käuferreferenz (BT-10). Was dort hineingehört, wenn dein Kunde keine Behörde ist, und wie du die Angabe dauerhaft loswirst.

Die XRechnung verlangt Skonto in BT-20 in einer streng maschinenlesbaren Syntax: #SKONTO#TAGE=n#PROZENT=n.nn#. Der gewohnte Skonto-Satz aus der Rechnungsvorlage fällt durch.

Bei SEPA-Lastschrift (Zahlungsmittel-Code 59) muss das zu belastende Konto (BT-91) eine formal korrekte IBAN enthalten. Häufigster Auslöser: Tippfehler oder Leerzeichen im IBAN-Feld.

Das Feld BT-24 muss exakt die Kennung des XRechnung-Standards enthalten. Häufigster Auslöser: Die Software schreibt eine ZUGFeRD-Profil-Kennung oder die URN einer veralteten XRechnung-Version hinein.

Zwei oder mehr in der Rechnung eingebettete Anhänge tragen denselben Dateinamen. Häufigster Auslöser: Software vergibt für jeden Anhang denselben Standardnamen wie „Anlage.pdf“.

Die CII-Datei enthält hierarchisch verschachtelte Rechnungspositionen. Die XRechnung kennt nur eine flache Positionsliste; typischer Auslöser ist ein ZUGFeRD-Export im Extended-Profil mit Positionsgliederung.

Das Artikel-Attribut mit dem Namen cva enthält einen Wert außerhalb der Codeliste. Zulässig sind nur clean, zero-emission und other, exakt in dieser Schreibweise.

Eine Rechnungszeile trägt die Klassifikation CVD, aber nicht genau ein Artikel-Attribut namens cva. Beide Angaben müssen in einer CVD-Rechnung paarweise auftreten.

Die XRechnung erwartet ein Lieferdatum (BT-72), einen Abrechnungszeitraum (BG-14) oder einen Zeitraum je Position (BG-26). Fehlt alles drei, meldet der Validator diese Warnung.

Der Scheme identifier des Item classification identifier (BT-158) stammt nicht aus der Codeliste UNTDID 7143. Häufigster Auslöser: ein frei erfundenes oder falsch geschriebenes listID-Attribut.

Die Rechnung nennt nicht, nach welcher Spezifikation sie erstellt wurde. Häufigster Auslöser ist ein selbst erzeugtes oder konvertiertes XML, in dem der Kontextblock am Dokumentanfang fehlt.

Die Rechnung enthält keine Rechnungsnummer. Meist wurde ein Entwurf ohne vergebene Nummer exportiert oder das Feld beim Mapping aus dem Vorsystem nicht befüllt.

Die Rechnung enthält kein Ausstellungsdatum. Typische Auslöser sind ein leeres Datumselement im Template oder ein Datum im falschen Format, das beim Einlesen verworfen wird.

Die Rechnung sagt nicht, welche Art Dokument sie ist (Rechnung, Gutschrift, korrigierte Rechnung). Meist fehlt der Code, weil das erzeugende System den Belegtyp nicht auf die UNTDID-1001-Codeliste abbildet.

Die Rechnung nennt keine Rechnungswährung. Häufigster Auslöser: Die Software schreibt Währungen nur als Attribut an einzelne Beträge, aber nicht in das Pflichtfeld für die Dokumentwährung.

Die Rechnung enthält keinen Namen des Rechnungsstellers. Meist sind die Firmenstammdaten unvollständig oder der Name steht im falschen Feld, etwa nur als Handelsname.

Die Rechnung enthält keinen Namen des Rechnungsempfängers. Häufigster Auslöser ist ein unvollständiger Kundendatensatz, aus dem die Software das Namensfeld leer übernimmt.

Die Rechnung enthält keine Postanschrift des Rechnungsstellers als strukturierte Datengruppe. Der Briefkopf im PDF ersetzt die XML-Felder nicht.

In der Verkäuferanschrift fehlt der Ländercode. Klassischer Auslöser: Bei Inlandsrechnungen wird das Länderfeld als selbstverständlich weggelassen, die Norm verlangt es trotzdem.

Die Rechnung enthält keine Postanschrift des Käufers (BG-8). Häufigster Auslöser: Der Kunde ist in den Stammdaten nur mit Namen und E-Mail angelegt.

Die Postanschrift des Käufers enthält keinen Ländercode (BT-55). Tritt oft auf, wenn das Land bei Inlandskunden als selbstverständlich weggelassen wird.

In der Rechnung fehlt die Summe der Positionsnettobeträge (BT-106). Meist legt die Software den Summenblock unvollständig an oder lässt ihn bei positionslosen Belegen leer.

In der Rechnung fehlt der Gesamtbetrag ohne Umsatzsteuer (BT-109). Häufigster Auslöser: Der Summenblock wird nur teilweise geschrieben, weil die Quelldaten nur den Bruttobetrag kennen.

In der Rechnung fehlt der Gesamtbetrag mit Umsatzsteuer (BT-112). Meist schreibt die Software den Summenblock unvollständig oder verwechselt Brutto- und Zahlbetrag.

In der Rechnung fehlt der fällige Zahlbetrag (BT-115). Tritt oft auf, wenn Software nur den Bruttobetrag schreibt und den Zahlbetrag für redundant hält.

Eine E-Rechnung muss mindestens eine Rechnungszeile (BG-25) enthalten. Der Fehler trifft vor allem Summenrechnungen und PDF-Konverter, die nur Kopfdaten befüllen.

Wenn ein vom Verkäufer abweichender Zahlungsempfänger (BG-10) angegeben wird, muss dessen Name (BT-59) in der Rechnung stehen. Typischer Auslöser: Factoring-Angaben ohne Namensfeld.

Gibt die Rechnung einen Steuervertreter des Verkäufers (BG-11) an, muss dessen Name (BT-62) enthalten sein. Betrifft fast nur ausländische Unternehmen mit Fiskalvertretung.

Wird ein Steuervertreter des Verkäufers (BG-11) angegeben, muss die Rechnung auch dessen Postanschrift (BG-12) enthalten. Meist fehlt der ganze Adressblock, nicht nur ein Feld.

Die Anschrift des Steuervertreters (BG-12) muss einen Ländercode (BT-69) enthalten. Häufig ist die Adresse zwar befüllt, aber ohne das ISO-Länderkennzeichen.

Jede Rechnungszeile (BG-25) braucht eine eindeutige Kennung (BT-126). Der Fehler entsteht, wenn die erzeugende Software keine Zeilennummern vergibt oder das Feld leer lässt.

Eine Rechnungszeile enthält keine abgerechnete Menge (BT-129). Häufigster Auslöser: Pauschalpositionen oder Textzeilen ohne Mengenangabe.

Eine Rechnungszeile hat eine Menge, aber keinen Einheitencode (BT-130). Häufigster Auslöser: Die Einheit ist als Freitext wie „Std.

Eine Rechnungszeile enthält keinen Positionsnettobetrag (BT-131). Meist berechnet die Software den Zeilenbetrag nicht, sondern erwartet ihn aus den Quelldaten.

Eine Rechnungszeile enthält keine Bezeichnung der Ware oder Leistung (BT-153). Häufigster Auslöser: Die Bezeichnung steht nur im Beschreibungsfeld oder in einer separaten Textzeile.

Die Rechnung enthält einen Nachlass auf Dokumentenebene (BG-20), aber das Betragsfeld BT-92 fehlt. Häufigster Auslöser: die Software legt den Nachlass-Block an, ohne ihn zu füllen.

Ein Nachlass auf Dokumentenebene (BG-20) braucht einen Umsatzsteuer-Kategoriecode (BT-95). Fehlt er, kann der Empfänger den Abzug keiner Steuerposition zuordnen.

Ein Nachlass auf Dokumentenebene (BG-20) braucht einen Grund als Freitext (BT-97) oder als Code (BT-98). Meist fehlt schlicht der Eintrag im Rabatt-Formular der Software.

Die Rechnung enthält einen Zuschlag auf Dokumentenebene (BG-21), aber das Betragsfeld BT-99 fehlt. Typisch, wenn die Software den Zuschlag-Block anlegt, ohne ihn zu füllen.

Ein Zuschlag auf Dokumentenebene (BG-21) braucht einen Umsatzsteuer-Kategoriecode (BT-102). Ohne ihn kann der Aufschlag keiner Steuerbemessungsgrundlage zugeordnet werden.

Ein Zuschlag auf Dokumentenebene (BG-21) braucht einen Grund als Freitext (BT-104) oder als Code (BT-105). Meist bleibt das Bezeichnungsfeld in der Software leer.

Ein Nachlass auf Positionsebene (BG-27) braucht ein Betragsfeld (BT-136). Der Fehler entsteht meist, wenn ein Prozentrabatt erfasst wird, aber der ausgerechnete Betrag nicht in die XML kommt.

Ein Nachlass auf Positionsebene (BG-27) braucht einen Grund als Freitext (BT-139) oder als Code (BT-140). Häufig wird nur der Rabattbetrag erfasst und das Grundfeld bleibt leer.

Eine Rechnungsposition enthält einen Zuschlag (BG-28), aber keinen Zuschlagsbetrag (BT-141). Meist legt die Software den Zuschlagsblock an, ohne den Betrag zu füllen.

Ein Zuschlag in einer Rechnungsposition (BG-28) braucht einen Grund als Freitext (BT-144) oder als Code (BT-145). Fehlt beides, lehnt der Validator die Rechnung ab.

In der Umsatzsteuer-Aufschlüsselung (BG-23) fehlt der zu versteuernde Betrag (BT-116). Ohne Bemessungsgrundlage kann der Empfänger die Steuer nicht nachrechnen.

In der Umsatzsteuer-Aufschlüsselung (BG-23) fehlt der Steuerbetrag der Kategorie (BT-117). Auch bei steuerfreien Umsätzen muss das Feld vorhanden sein, dann mit 0.00.

Jede Zeile der Umsatzsteuer-Aufschlüsselung (BG-23) muss über einen Kategorie-Code (BT-118) definiert sein, etwa S für Standardsatz oder AE für Reverse Charge.

In der Umsatzsteuer-Aufschlüsselung (BG-23) fehlt der Steuersatz (BT-119). Er ist Pflicht für alle Kategorien außer O (nicht steuerbar), auch bei 0 % muss er als 0.00 dastehen.

Die Rechnung enthält Zahlungsangaben (BG-16), aber keinen Code für die Zahlungsart (BT-81). Häufig steht die IBAN in der XML, der Code 58 für SEPA-Überweisung fehlt aber.

Die Rechnung enthält eine Überweisungsangabe, aber keine Kontonummer (BT-84). Meist legt die Software den Konto-Block an, ohne dass eine IBAN hinterlegt ist.

Bei Kartenzahlung darf die Rechnung nie die komplette Kartennummer (BT-87) enthalten. Erlaubt sind höchstens die ersten 6 und letzten 4 Ziffern.

Jede rechnungsbegleitende Anlage (BG-24) braucht eine Kennung (BT-122), etwa einen Dateinamen oder eine Belegnummer. Fehlt sie, lehnt der Validator die Rechnung ab.

Wenn eine abweichende USt-Buchungswährung (BT-6) angegeben ist, muss der Steuerbetrag auch in dieser Währung (BT-111) stehen. Meist ist BT-6 versehentlich gesetzt.

Jedes Artikel-Attribut (BG-32) braucht beides: einen Namen (BT-160) und einen Wert (BT-161). Halb gefüllte Attribute wie „Farbe:“ ohne Angabe lehnt der Validator ab.

Jeder Verweis auf eine Vorgängerrechnung (BG-3) muss deren Rechnungsnummer (BT-25) enthalten. Tritt vor allem bei Korrekturrechnungen und Gutschriften auf.

Die Rechnung nennt einen Steuervertreter des Verkäufers (BG-11), aber ohne dessen USt-IdNr. (BT-63). Meist gehört der ganze Block gar nicht in die Rechnung.

Die Rechnung enthält sowohl ein Umsatzsteuer-Datum (BT-7) als auch einen Umsatzsteuer-Datum-Code (BT-8). Erlaubt ist nur eines von beiden, meist füllt die Software beide Felder gleichzeitig.

Die Summe der Positionsnettobeträge (BT-106) muss exakt der Addition aller Zeilennettobeträge (BT-131) entsprechen. Häufigster Auslöser: Rundungsdifferenzen zwischen Positions- und Summenberechnung.

Die Summe der Nachlässe auf Dokumentebene (BT-107) muss der Addition aller einzelnen Nachlassbeträge (BT-92) entsprechen. Bricht meist, wenn Rabatte teils als Position, teils als Dokumentnachlass erfasst sind.

Die Summe der Zuschläge auf Dokumentebene (BT-108) muss der Addition aller einzelnen Zuschlagsbeträge (BT-99) entsprechen. Bricht typischerweise bei Versandkosten, die doppelt oder nur im Summenfeld erfasst sind.

Der Rechnungsgesamtbetrag ohne Umsatzsteuer (BT-109) muss aus Positionssumme minus Nachlässen plus Zuschlägen bestehen. Häufigster Auslöser: Nachlässe oder Zuschläge wurden doppelt oder gar nicht eingerechnet.

Der ausgewiesene Umsatzsteuer-Gesamtbetrag (BT-110) muss der Summe der Steuerbeträge aller Steuerkategorien (BT-117) entsprechen. Bricht meist durch Rundung über mehrere Steuersätze hinweg.

Der Rechnungsgesamtbetrag mit Umsatzsteuer (BT-112) muss exakt Nettobetrag (BT-109) plus Steuerbetrag (BT-110) sein. Bricht meist als Folgefehler einer falschen Netto- oder Steuersumme.

Die Steuer je Steuersatz muss sich exakt aus Bemessungsgrundlage mal Satz ergeben, auf zwei Stellen gerundet. Warum das an der Rundung scheitert und nicht am Rechnen.

Jede E-Rechnung braucht mindestens eine Steueraufschlüsselung (BG-23), auch wenn keine Steuer anfällt. Tritt fast immer bei 0-%-Fällen wie Reverse Charge oder Steuerbefreiung auf.

Die Rechnung enthält einen Abrechnungszeitraum (BG-14), aber weder Startdatum noch Enddatum. Häufigster Auslöser ist ein leer angelegtes Zeitraum-Element.

Eine Rechnungsposition enthält einen Leistungszeitraum (BG-26), aber weder Startdatum noch Enddatum. Meist hat die Software das Zeitraum-Element leer angelegt.

Ein Rabatt auf Rechnungsebene (BG-20) braucht einen Grund als Text (BT-97) oder als Code (BT-98). Fehlt beides, lehnt der Validator die Rechnung ab.

Ein Zuschlag auf Rechnungsebene (BG-21), etwa Versand- oder Anfahrtskosten, braucht einen Grund als Text (BT-104) oder Code (BT-105). Fehlt beides, schlägt die Prüfung fehl.

Ein Rabatt auf eine einzelne Rechnungsposition (BG-27) braucht einen Grund als Text (BT-139) oder Code (BT-140). Häufig geht die Angabe beim Export des Positionsrabatts verloren.

Ein Zuschlag auf eine einzelne Rechnungsposition (BG-28) braucht einen Grund als Text (BT-144) oder Code (BT-145). Typischer Auslöser: Der Zuschlag wird nur als Betrag exportiert.

Sobald ein Betrag zu zahlen ist, verlangt EN 16931 entweder ein Fälligkeitsdatum oder eine Zahlungsbedingung. Warum „zahlbar sofort“ im PDF nicht reicht.

EN 16931 verlangt mindestens eine eindeutige Verkäufer-Kennung: USt-IdNr., Handelsregisternummer oder Verkäufer-ID. Was Kleinunternehmer ohne USt-IdNr. eintragen.

Die Kontokennung des Zahlungsempfängers (BT-84) darf nur einmal angegeben werden: entweder als IBAN oder als sonstige Kontonummer, nicht beides zugleich.

Der Betrag eines Nachlasses auf Dokumentenebene (BT-92) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: ein prozentualer Rabatt wird berechnet und ungerundet in die XML geschrieben.

Der Basisbetrag eines Nachlasses auf Dokumentenebene (BT-93) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die Software übernimmt die intern geführte Zwischensumme ungerundet als Rabattbasis.

Der Betrag eines Zuschlags auf Dokumentenebene (BT-99) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: ein prozentual berechneter Zuschlag wird ungerundet ausgegeben.

Der Basisbetrag eines Zuschlags auf Dokumentenebene (BT-100) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die ungerundete Zwischensumme wird als Berechnungsbasis in die XML übernommen.

Die Summe der Positionsnettobeträge (BT-106) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die Software summiert ungerundete Positionswerte und schreibt das rohe Ergebnis in die XML.

Die Summe der Nachlässe auf Dokumentenebene (BT-107) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die Summe wird aus ungerundeten Einzelnachlässen gebildet.

Die Summe der Zuschläge auf Dokumentenebene (BT-108) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die Summe wird aus ungerundeten Einzelzuschlägen gebildet oder mit fester Vier-Stellen-Genauigkeit serialisiert.

Der Rundungsbetrag (BT-114) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die Software schreibt eine intern berechnete Rundungsdifferenz ungerundet in die XML.

Der Steuerbetrag einer USt-Aufschlüsselung (BT-117) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die Software schreibt das ungerundete Ergebnis aus Bemessungsgrundlage mal Steuersatz in die XML.

Der Nettobetrag einer Rechnungsposition (BT-131) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: Menge mal Einzelpreis wird ungerundet in die XML geschrieben.

Der Nachlassbetrag einer Rechnungsposition (BT-136) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: ein prozentualer Rabatt wird ungerundet aus der Basis berechnet.

Der Grundbetrag, auf den sich ein Positionsnachlass bezieht (BT-137), darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die Software übernimmt den ungerundeten internen Positionswert als Basis.

Der Zuschlagsbetrag einer Rechnungsposition (BT-141) darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: prozentuale Zuschläge wie Mindermengen- oder Energiezuschlag werden ungerundet übernommen.

Der Grundbetrag, auf den sich ein Positionszuschlag bezieht (BT-142), darf höchstens zwei Nachkommastellen haben. Häufigster Auslöser: die Software übernimmt einen ungerundeten internen Wert als Bezugsgröße.

Mindestens eine Position, ein Nachlass oder ein Zuschlag ist mit dem Standardsteuersatz (Kategorie S) kategorisiert, aber die Steueraufschlüsselung enthält keinen Eintrag für S. Meist vergisst die Software den Summenblock.

Sobald eine Rechnungsposition die Kategorie S (Standardsatz) trägt, muss die Rechnung eine USt-IdNr. oder Steuernummer des Verkäufers enthalten. Meist fehlt die Angabe schlicht in den Stammdaten.

Trägt ein Nachlass auf Dokumentebene die Kategorie S (Standardsatz), muss die Rechnung eine USt-IdNr. oder Steuernummer des Verkäufers enthalten. Der Auslöser liegt fast nie beim Nachlass selbst.

Trägt ein Zuschlag auf Dokumentebene die Kategorie S (Standardsatz), muss die Rechnung eine USt-IdNr. oder Steuernummer des Verkäufers enthalten. Typischer Kandidat: die Versandkostenpauschale.

Eine Rechnungsposition mit Kategorie S (Standardsatz) muss einen Steuersatz größer als 0 tragen. Meist steht 0 im Satzfeld, weil eigentlich eine andere Kategorie gemeint war oder das Feld leer blieb.

Ein Nachlass auf Dokumentebene mit Kategorie S (Standardsatz) muss einen Steuersatz größer als 0 tragen. Häufigster Auslöser: die Software schreibt Rabatte ohne Satz ins XML.

Ein Zuschlag auf Dokumentebene mit Kategorie S (Standardsatz) muss einen Steuersatz größer als 0 tragen. Klassiker: Versandkosten werden ohne Steuersatz exportiert.

Mindestens eine Position trägt die Kategorie AE (Reverse Charge), aber in der Steueraufschlüsselung fehlt die zugehörige AE-Gruppe. Häufig fehlt der Aufschlüsselungs-Block komplett.

Eine Rechnungszeile trägt die Steuerkategorie AE (Reverse Charge), aber die Rechnung enthält nicht die USt-IdNr. von Verkäufer und Käufer. Meist fehlt die des Käufers.

Ein Nachlass auf Dokumentebene trägt die Steuerkategorie AE (Reverse Charge), aber die Rechnung enthält nicht die USt-IdNr. von Verkäufer und Käufer. Meist fehlt die des Käufers.

Ein Zuschlag auf Dokumentebene (z. B. Anfahrtspauschale) trägt die Steuerkategorie AE, aber die USt-IdNr. von Verkäufer oder Käufer fehlt in der Rechnung.

Eine Rechnungszeile mit Steuerkategorie AE (Reverse Charge) muss den Steuersatz 0 tragen. Häufigster Auslöser: die 19 % aus dem Artikelstamm bleiben stehen.

Ein Nachlass auf Dokumentebene trägt die Steuerkategorie AE (Reverse Charge), aber sein Steuersatz ist nicht 0. Meist hat die Software den regulären Satz von 19 % mitkopiert.

Ein Zuschlag auf Dokumentebene trägt die Steuerkategorie AE (Reverse Charge), aber sein Steuersatz ist nicht 0. Typischer Auslöser sind Versand- oder Fahrtkosten mit voreingestellten 19 %.

Die Steueraufschlüsselung für Kategorie AE (Reverse Charge) nennt eine Bemessungsgrundlage, die nicht der Summe der AE-Positionen abzüglich Nachlässen plus Zuschlägen entspricht.

Die Steueraufschlüsselung für Kategorie AE (Reverse Charge) weist einen Steuerbetrag ungleich 0 aus. Bei Umkehrung der Steuerschuldnerschaft darf der Verkäufer keine Steuer berechnen.

Die Steueraufschlüsselung mit Kategorie AE (Reverse Charge) enthält weder einen Befreiungsgrund-Text noch einen Befreiungsgrund-Code. Der §13b-Hinweis muss als Datenfeld in der XML stehen.

Die Rechnung enthält Positionen, Nachlässe oder Zuschläge mit der USt-Kategorie E (steuerbefreit), aber keine oder mehrere zugehörige Aufschlüsselungsgruppen. Verlangt ist genau eine.

Eine Rechnungsposition trägt die USt-Kategorie E (steuerbefreit), aber ihr Steuersatz ist nicht 0. Häufigster Auslöser: Der Standardsatz 19 % bleibt beim Umstellen der Kategorie stehen.

Ein Nachlass auf Dokumentenebene trägt die USt-Kategorie E (steuerbefreit), aber sein Steuersatz ist nicht 0. Meist übernimmt die Software den Satz der Hauptpositionen statt den der befreiten.

Ein Zuschlag auf Dokumentenebene trägt die USt-Kategorie E (steuerbefreit), aber sein Steuersatz ist nicht 0. Typisch bei Versand- oder Verpackungskosten, die pauschal den Standardsatz erben.

Die Bemessungsgrundlage in der USt-Aufschlüsselung der Kategorie E (steuerbefreit) muss der Summe aller E-Positionen abzüglich E-Nachlässen plus E-Zuschlägen entsprechen. Meist stimmt die Summenbildung der Software nicht.

In der USt-Aufschlüsselung der Kategorie E (steuerbefreit) steht ein Steuerbetrag ungleich 0. Häufigster Auslöser: Die Software rechnet den Betrag aus einem falsch stehengebliebenen Steuersatz hoch.

Die USt-Aufschlüsselung der Kategorie E (steuerbefreit) nennt weder einen Befreiungsgrund als Text noch als Code. Auf Papierrechnungen genügt der Hinweis im Fließtext, in der E-Rechnung braucht es das strukturierte Feld.

Ein Nachlass auf Dokumentebene trägt die Steuerkategorie K (innergemeinschaftliche Lieferung), aber es fehlt die USt-IdNr des Verkäufers oder des Käufers. Häufigster Auslöser: die Käufer-USt-IdNr wurde nicht in den Kundenstammdaten erfasst.

Ein Zuschlag auf Dokumentebene (z. B. Versandkosten) trägt die Steuerkategorie K, aber die USt-IdNr des Verkäufers oder des Käufers fehlt in der Rechnung.

Eine Rechnungsposition trägt die Steuerkategorie K (innergemeinschaftliche Lieferung), aber der Steuersatz der Position ist nicht 0. Meist steht dort noch ein übernommener 19-%-Satz aus dem Artikelstamm.

Ein Nachlass auf Dokumentebene trägt die Steuerkategorie K, aber sein Steuersatz ist nicht 0. Typischer Auslöser: der Rabatt übernimmt den Standardsatz aus der Software statt den Satz der zugehörigen Positionen.

Ein Zuschlag auf Dokumentebene trägt die Steuerkategorie K, aber sein Steuersatz ist nicht 0. Häufig betrifft es Fracht- oder Verpackungszuschläge, die den Inlandssatz aus den Stammdaten behalten.

Die Bemessungsgrundlage in der Steueraufschlüsselung mit Kategorie K stimmt nicht mit der Summe der zugehörigen Positionen, Nachlässe und Zuschläge überein. Häufigster Auslöser: ein Dokumentrabatt wird in der Basis nicht abgezogen.

In der Steueraufschlüsselung mit Kategorie K (innergemeinschaftliche Lieferung) steht ein Steuerbetrag ungleich 0. Häufigster Auslöser: die Software rechnet trotzdem Basis mal Satz oder übernimmt einen alten 19-%-Wert.

Die Steueraufschlüsselung mit Kategorie K braucht einen Befreiungsgrund als Code (BT-121) oder Text (BT-120). Häufigster Auslöser: der Hinweis steht nur im PDF-Layout, nicht als Datenfeld im XML.

Enthält die Rechnung eine Steueraufschlüsselung mit Kategorie K, muss das tatsächliche Lieferdatum (BT-72) oder ein Abrechnungszeitraum (BG-14) angegeben sein. Meist fehlt schlicht das Lieferdatum im Erfassungsdialog.

Die Rechnung weist eine innergemeinschaftliche Lieferung aus, enthält aber keinen Ländercode der Lieferanschrift. Häufigster Auslöser: die Lieferadresse wird gar nicht in die XML übernommen, weil sie der Rechnungsadresse entspricht.

Die Rechnung enthält Positionen, Nachlässe oder Zuschläge mit der USt-Kategorie G (Ausfuhr außerhalb der EU), aber keine oder mehrere zugehörige Aufschlüsselungsgruppen. Verlangt ist genau eine.

Ein Zuschlag auf Dokumentenebene trägt die Steuerkategorie G (Export außerhalb der EU), aber der Rechnung fehlt USt-IdNr., Steuernummer oder Steuervertreter-USt-ID des Verkäufers.

Eine Rechnungszeile mit Steuerkategorie G (Export außerhalb der EU) muss den Steuersatz 0 tragen. Häufigster Auslöser: die Software übernimmt den 19-%-Standardsatz aus dem Artikelstamm.

Ein Nachlass auf Dokumentenebene mit Steuerkategorie G (Export außerhalb der EU) muss den Steuersatz 0 tragen. Meist übernimmt die Software beim Rabatt den Standardsatz statt des Satzes der Exportzeilen.

Ein Zuschlag auf Dokumentenebene mit Steuerkategorie G (Export außerhalb der EU) muss den Steuersatz 0 tragen. Klassischer Auslöser: Versand- oder Verpackungskosten mit 19-%-Default.

Sobald eine Position, ein Nachlass oder ein Zuschlag die Steuerkategorie Z (Nullsatz) trägt, muss die Umsatzsteuer-Aufschlüsselung genau eine Gruppe mit Kategorie Z enthalten. Häufigster Auslöser: die Software erzeugt die Aufschlüsselung nicht oder doppelt.

Enthält eine Rechnungszeile die Steuerkategorie Z (Nullsatz), muss die Rechnung eine USt-IdNr. oder Steuernummer des Verkäufers tragen. Häufigster Auslöser: unvollständige Stammdaten.

Trägt ein Nachlass auf Dokumentebene die Steuerkategorie Z, muss die Rechnung eine USt-IdNr. oder Steuernummer des Verkäufers enthalten. Häufigster Auslöser: der Rabatt erbt die Kategorie Z, während die Stammdaten unvollständig sind.

Eine Rechnungsposition mit Steuerkategorie Z (Nullsatz) muss den Steuersatz 0 tragen. Häufigster Auslöser: die Kategorie wurde auf Z gestellt, der Prozentsatz aber bei 19 oder 7 belassen.

Ein Nachlass auf Dokumentebene mit Steuerkategorie Z muss den Steuersatz 0 tragen. Häufigster Auslöser: der Rabatt erbt die Kategorie Z von den Positionen, der Prozentsatz bleibt aber gefüllt.

Ein Zuschlag auf Dokumentebene mit Steuerkategorie Z muss den Steuersatz 0 tragen. Häufigster Auslöser: Versand- oder Verpackungskosten übernehmen die Kategorie Z, behalten aber einen Prozentsatz größer null.

In der Steueraufschlüsselung zur Kategorie Z muss der Basisbetrag exakt der Summe aller Z-Positionen plus Z-Zuschläge minus Z-Nachlässe entsprechen. Häufigster Auslöser: eine Position wurde umkategorisiert, die Aufschlüsselung aber nicht neu berechnet.

In der Steueraufschlüsselung zur Kategorie Z muss der ausgewiesene Steuerbetrag exakt 0 sein. Häufigster Auslöser: die Software rechnet den Steuerbetrag mit einem falsch hinterlegten Prozentsatz aus.

Eine Steueraufschlüsselung mit Kategorie Z darf weder Befreiungsgrund-Text noch Befreiungsgrund-Code enthalten. Häufigster Auslöser: Verwechslung von Nullsatz (Z) und Steuerbefreiung (E).

In einer Steueraufschlüsselung mit Kategorie O (nicht steuerbar) muss der Steuerbetrag exakt 0 sein. Meist hat die Software trotzdem einen Steuersatz angewendet oder einen Restbetrag stehen lassen.

Eine Steueraufschlüsselung mit Kategorie O (nicht steuerbar) braucht einen Befreiungsgrund als Text oder Code. Meist bleibt das Feld leer, weil die Software es nur für Kategorie E kennt.

Enthält die Rechnung eine Steueraufschlüsselung mit Kategorie O (nicht steuerbar), darf es keine zweite Aufschlüsselungsgruppe geben. Gemischte Rechnungen mit O sind unzulässig.

Sobald die Steueraufschlüsselung die Kategorie O (nicht steuerbar) enthält, müssen alle Rechnungspositionen ebenfalls Kategorie O tragen. Gemischte Rechnungen sind unzulässig.

Enthält die Steueraufschlüsselung die Kategorie O (nicht steuerbar), müssen auch alle Nachlässe auf Dokumentebene die Kategorie O tragen. Häufigster Auslöser: ein Rabatt, der mit dem Standard-Steuersatz angelegt wurde.

Enthält die Steueraufschlüsselung die Kategorie O (nicht steuerbar), müssen auch alle Zuschläge auf Dokumentebene die Kategorie O tragen. Typischer Auslöser: eine Versand- oder Bearbeitungspauschale mit 19 %.

Eine ZUGFeRD-/Factur-X-Rechnung, die keine Anzahlungsrechnung (Code 386) ist, muss das tatsächliche Lieferdatum (BT-72) oder einen Abrechnungszeitraum (BG-14) enthalten. Häufigster Auslöser: Das Leistungsdatum steht nur im PDF-Text.

Für den Versand über das Peppol-Netz muss die Rechnung eine Geschäftsprozess-Kennung enthalten. Häufigster Auslöser: die Software füllt nur die Spezifikations-Kennung (BT-24), lässt BT-23 aber leer.

Die Währung für die Umsatzsteuer-Abrechnung (BT-6) darf nur angegeben werden, wenn sie sich von der Rechnungswährung (BT-5) unterscheidet. Häufigster Auslöser: die Software schreibt EUR in beide Felder.

Die Rechnung enthält ein XML-Element ohne Inhalt. Der Fehler kommt fast nie vom Nutzer, sondern vom erzeugenden Programm.

Die Rechnung muss eine elektronische Adresse des Käufers (BT-49) mit Schema-Kennung enthalten. Häufigster Auslöser: für den Kunden ist keine E-Mail- oder Peppol-Adresse hinterlegt.

Bei einem Nachlass oder Zuschlag stimmt der angegebene Betrag nicht mit Basisbetrag mal Prozentsatz überein. Meist eine Rundungs- oder Rechenabweichung der erzeugenden Software.

Ein Nachlass oder Zuschlag nennt einen Prozentsatz, aber keinen Basisbetrag. PEPPOL verlangt beide Felder paarweise, damit der Betrag nachrechenbar ist.

Ein Nachlass oder Zuschlag nennt einen Basisbetrag, aber keinen Prozentsatz. PEPPOL verlangt die beiden Felder nur paarweise, einzeln sind sie unzulässig.

Das Kennzeichen, das Nachlass von Zuschlag unterscheidet, enthält einen anderen Wert als die Literale true oder false. Häufigster Auslöser: die XML-Schema-Schreibweisen 1 und 0.

Die Rechnung nennt Lastschrift als Zahlungsweg (Code 59), enthält aber keine SEPA-Mandatsreferenz (BT-89). Meist übernimmt die Software den Zahlungsweg aus den Stammdaten, die Mandatsdaten aber nicht.

Auf Positionsebene ist nur eine einzige Art von Dokumentreferenz erlaubt: die Objektkennung der Rechnungszeile (BT-128). Lieferschein- oder Bestellnummern je Position lösen den Fehler aus.

Der Leistungszeitraum einer Rechnungsposition (BT-134) startet früher als der Abrechnungszeitraum der Rechnung (BT-73). Häufig ragt eine einzelne Position in den Vormonat hinein.

Der Leistungszeitraum einer Rechnungsposition (BT-135) endet später als der Abrechnungszeitraum der Rechnung (BT-74). Typisch, wenn eine Leistung über das Monatsende hinausläuft.

Die Basismenge des Einheitspreises (BT-149) ist null oder negativ. Fast immer schreibt die Software eine 0 als Standardwert in das Feld, statt es wegzulassen.

Der Einheitencode der Preis-Basismenge (BT-150) muss mit dem der abgerechneten Menge (BT-130) übereinstimmen. Meist exportiert die Software zwei verschiedene Codes für dieselbe Einheit.