Checkliste: Rechnungs-Geschäftsvorfälle in der E-Rechnung
Jeder Geschäftsvorfall, der heute eine Rechnung erzeugt, braucht in der E-Rechnung ein festes Mapping auf die EN-16931-Felder – sonst besteht die Datei zwar die Validierung, ist aber steuerlich oder fachlich falsch.
Diese Checkliste listet die 25 Vorfälle, die im Mittelstand typischerweise vorkommen, und sagt je Fall: welche Rechnungsart, welche Pflichtfelder, wo die Stolperfallen liegen und welcher Blogartikel das im Detail erklärt.
Was als PDF geduldet wurde, wird jetzt in Frage gestellt
Ein PDF hat vieles verziehen: Der Empfänger hat gelesen, mitgedacht und notfalls nachgefragt. Eine E-Rechnung wird maschinell verarbeitet – sie muss eindeutig sagen, was gemeint ist. Viele Gewohnheiten, die jahrelang niemanden gestört haben, fallen deshalb erst jetzt auf:
| Heute im PDF geduldet | In der E-Rechnung |
|---|---|
| Anzahlung als Minusposition in der Schlussrechnung | Abzug über BT-113 mit Bezug auf jede Vorrechnung – sonst droht § 14c UStG |
| Gutschrift als Rechnung mit Minusbeträgen | Eigene Rechnungsart 381, positive Beträge, Bezug auf die Originalrechnung |
| Rabatt als Artikelzeile mit Minuspreis | Nachlass in BG-20 oder BG-27 – negative Preise sind nicht zulässig |
| Mehrere Bestellungen in einer Rechnung | Eine Rechnung je Bestellung (BT-13) |
| Stundenzettel und Aufmaß als lose Datei in der E-Mail | Base64-kodiert in der XML (BG-24) |
| Steuer nur in Fremdwährung | Umsatzsteuer zusätzlich in EUR (BT-6, BT-111) |
| Rechnungsadresse „steht irgendwo im CRM“ | Rechnungs-E-Mail bzw. Peppol-ID als gepflegtes Pflichtfeld je Debitor |
| Rechnung mit Zusatzinformationen überfrachtet | Nur was zur Rechnung gehört, strukturiert in die XML – der Rest in einen Anhang oder ein eigenes Dokument |
Die überfrachtete Rechnung
Häufig war die Rechnung über die Jahre mehr als eine Rechnung: Rabattstaffeln und Konditionsübersichten, Detailinformationen zu einzelnen Positionen wie Seriennummern, Chargen, Messwerte oder Projektstände, Hinweise zu Folgeaufträgen. Im PDF war dafür immer Platz – im Datenmodell der E-Rechnung nicht.
- ZUGFeRD kann solche Informationen weitertransportieren: im sichtbaren PDF-Teil und, im Profil EXTENDED, teilweise auch strukturiert im XML.
- Reine XML-Rechnungen (XRechnung) bieten dafür nur wenig Raum: Freitext in BT-22 (Kopf) und BT-127 (Position), Artikeleigenschaften als Name-Wert-Paare in BG-32 – vieles davon kommt beim Empfänger nicht oder nur als Text an.
Die Frage im Projekt lautet deshalb: Was davon braucht der Empfänger zum Buchen und Bezahlen? Das gehört strukturiert in die Rechnung. Alles andere – Staffelübersichten, Positionsdetails, Leistungsnachweise – wandert in einen Anhang (BG-24) oder in ein eigenes Dokument wie Lieferschein, Leistungsnachweis oder Konditionsvereinbarung.
Erst fachlich klären, dann technisch umsetzen
Wir sehen in Projekten häufig: Die eigentlichen Herausforderungen liegen nicht im XML, sondern in Prozessen und Dokumenten, die nie für eine maschinelle Verarbeitung gedacht waren. Genau deshalb wird der Projektumfang oft unterschätzt – gerade wenn die interne Accounting-Abteilung die Umstellung neben dem Tagesgeschäft stemmt. Vor das IT-Projekt gehört daher eine fachliche Beratung, die klärt:
- welche Geschäftsvorfälle tatsächlich vorkommen und wie sie heute abgerechnet werden,
- welche Prozesse sich ändern müssen – von der Auftragsannahme über die Faktura bis zum Korrekturweg,
- welche Dokumente angepasst werden – Angebote, Auftragsbestätigungen, Rahmenverträge, Kundenstammblatt,
- welche Fragen mit Steuerberater oder Steuerabteilung zu entscheiden sind.
Erst danach steht fest, was das ERP-Mapping leisten muss. Die Checkliste unten ist genau dafür gedacht.
Rechtzeitig starten: Wer zu spät beginnt, konkurriert mit Jahresabschluss, Jahresendgeschäft und laufender Buchhaltung um dieselben Köpfe. Planen Sie die fachliche Klärung so, dass sie nicht in diese Spitzenzeiten fällt – mit Blick auf die Ausstellungspflicht ab 1.1.2027 bzw. 1.1.2028.
Drei Felder entscheiden fast jeden Fall
BT-3
Rechnungsart (UNTDID 1001)
Sagt dem Empfänger, was das Dokument ist – Rechnung, Gutschrift, Korrektur, Anzahlung.
BT-25 / BT-26
Bezug auf Vorrechnung
Verknüpft Korrekturen, Storno und Schlussrechnungen mit dem Ursprungsbeleg.
BT-95 / BT-118 / BT-151
USt-Kategorie (S, Z, E, AE, K, G, O …)
Bestimmt, welche Zusatzpflichten wie Befreiungsgrund oder USt-IdNr. greifen.
So nutzen Sie die Checkliste: Gehen Sie die Übersichtstabelle im Projekt mit dem Fachbereich durch, markieren Sie jeden Vorfall, der vorkommt, und arbeiten Sie für diese Fälle die Detail-Checklisten im ERP-Mapping ab. Feldnummern beziehen sich auf EN 16931 / XRechnung; die ZUGFeRD-Profile EN 16931 (Comfort) und EXTENDED nutzen dieselbe Semantik.
Übersicht: 25 Geschäftsvorfälle und ihr Mapping
BT-3 = Rechnungsart; „XR“ = XRechnung, „ZF“ = ZUGFeRD/Factur-X.
| # | Geschäftsvorfall | BT-3 | Mapping-Kern | Typische Stolperfalle | Detail |
|---|---|---|---|---|---|
| 1 | Standardrechnung (Lieferung/Leistung) | 380 | BT-72 Leistungsdatum oder BG-14 Zeitraum, BT-10 Käuferreferenz, BT-49 elektr. Adresse | BT-72 leer oder mit Rechnungsdatum vorbelegt | Fehler-Praxis |
| 2 | Mehrere Bestellungen (POs) in einem Auftrag | 380 | Je Bestellung eine eigene Rechnung: BT-13 Bestellnummer gibt es nur einmal im Kopf, BT-132 verweist nur auf Positionen dieser Bestellung | Mehrere POs in einer Rechnung, weitere PO-Nummern nur im Freitext → kein automatischer 3-Way-Match beim Empfänger | BT-Felder |
| 3 | Sammelrechnung (mehrere Lieferungen) | 380 | BG-14 Gesamtzeitraum, BG-26 Zeitraum je Position, Lieferschein in BT-128 bzw. Positionstext | BT-16 trägt nur einen Lieferschein im Kopf | BT-Felder |
| 4 | Dauer-/Abo-/Mietrechnung | 380 | BG-14 BT-73/74 Abrechnungszeitraum, BT-12 Vertragsreferenz | Dauerrechnung (Vertrag mit Zahlungsplan) braucht eigene Klärung | – |
| 5 | Anzahlungsrechnung | XR 380 / ZF 386 | Eigene Position über den Anzahlungsbetrag, kein BT-72, Hinweis in BT-22 | 386 in XRechnung → BR-DE-17 | Anzahlung/Schluss |
| 6 | Abschlagsrechnung Bau (§ 632a BGB) | 875 | Leistungsstand in Positionen, bei Bauleistung § 13b → Kategorie AE | 875/876/877 mit 326/380 vermischt | Anzahlung/Schluss |
| 7 | Teilrechnung (abgeschlossener Leistungsteil) | 326 (Bau 876) | Echte Positionen, echtes Leistungsdatum, kein BT-113 | Anzahlung als 326 deklariert → behauptet erbrachte Leistung | Anzahlung/Schluss |
| 8 | Schlussrechnung mit Anzahlungen | 380 (Bau 877) | Volle Leistung, BT-113 brutto, BG-3 je Vorrechnung (BT-25/26), BR-CO-16 | Anzahlung als Minusposition → § 14c UStG | Anzahlung/Schluss |
| 9 | Restrechnung (nur Restentgelt) | 380 | Nur offenes Entgelt, Bezug auf Vorrechnungen in BG-3 | Wird selten genutzt, ist aber die sauberste Variante | Anzahlung/Schluss |
| 10 | Staffelpreise (Mengen-/Preisstaffel) | 380 | Je Staffelstufe eine Position oder Durchschnittspreis in BT-146, Basismenge BT-149 | Staffel nur im Positionstext, Preis × Menge ≠ BT-131 | BT-Felder |
| 11 | Ratenzahlung / Zahlungsplan | 380 | BT-9 erste Fälligkeit, Ratenplan in BT-20 (Kernmodell kennt nur eine Fälligkeit) | Mehrere Fälligkeiten strukturiert nur in ZF EXTENDED | – |
| 12 | Rabatte und Zuschläge | 380 | Kopf: BG-20/BG-21, Position: BG-27/BG-28, Grund BT-97/98 bzw. BT-104/105 | Rabatt als negative Position statt Nachlass | Fehler-Praxis |
| 13 | Skonto | 380 | BT-20 strukturiert #SKONTO#TAGE=14#PROZENT=2.00#, BT-9 | Skonto als Freitext (BR-DE-18) oder als Nachlass BG-20 | Skonto |
| 14 | Storno / Gutschrift (Entgeltminderung) | 381 | Positive Beträge, neue BT-1, Pflicht-Bezug auf die Originalrechnung in BT-25 (Nummer) und BT-26 (Datum), BG-16 | 380 mit Minusbeträgen → zweite Forderung beim Empfänger; Gutschrift ohne Bezug auf das Original kann nicht zugeordnet werden | Storno/Gutschrift |
| 15 | Rechnungsberichtigung (Ersatz) | 384 | BT-25 Pflicht (BR-DE-26), Grund in BT-22 | BT-25 nicht befüllt → Ablehnung | Storno/Gutschrift |
| 16 | Selbstfakturierung (Gutschriftverfahren) | 389 | Käufer stellt aus, Vereinbarung nötig, Angabe „Gutschrift“ | Mit 381 verwechselt → Forderung statt Minderung | Storno/Gutschrift |
| 17 | Mehrere Steuersätze (19 % / 7 %) | 380 | Eine BG-23-Gruppe je Kategorie und Satz | Rundung je Position → BR-CO-17 | Fehler-Praxis |
| 18 | Reverse Charge § 13b UStG | 380 | Kategorie AE, BT-120/121 Grund, beide USt-IdNr.: Verkäufer BT-31 und Käufer BT-48 | Steuerbetrag ≠ 0 oder eine der beiden USt-IdNr. fehlt (BR-AE-02) | Fehler-Praxis |
| 19 | Innergemeinschaftliche Lieferung | 380 | Kategorie K, BT-31 + BT-48, Lieferland BT-80 | USt-IdNr. ohne Länderpräfix | Fehler-Praxis |
| 20 | Ausfuhr Drittland | 380 | Kategorie G, Befreiungsgrund | Als E statt G kodiert | – |
| 21 | Steuerfreie Umsätze (§ 4 UStG) | 380 | Kategorie E, BT-120/121 Befreiungsgrund | Grund fehlt oder steht bei S/Z | Fehler-Praxis |
| 22 | Durchlaufende Posten / Auslagen | 380 | Kategorie O (nicht steuerbar) | O darf nicht mit anderen Kategorien gemischt werden → eigene Rechnung | – |
| 23 | Fremdwährung | 380 | BT-5 Rechnungswährung (z. B. USD), BT-6 USt-Währung EUR, BT-111 Umsatzsteuer-Gesamtbetrag in EUR – Pflicht nach Art. 230 MwStSystRL, Umrechnung nach § 16 Abs. 6 UStG | Steuer nur in Fremdwährung ausgewiesen: Ohne BT-6 greift BR-53 nicht, die Datei validiert, ist steuerlich aber unvollständig | – |
| 24 | Rechnung mit Anhängen (Stundenzettel, Aufmaß, Lieferschein) | 380 | BG-24: BT-122 Referenz, BT-123 Beschreibung, Datei Base64-kodiert in BT-125 mit MIME-Typ und Dateiname | Anhang als separate Datei neben der XML verschickt; bei ZUGFeRD zusätzliches PDF neben der factur-x.xml eingebettet | – |
| 25 | Öffentliche Auftraggeber (B2G) | 380 | XRechnung, BT-10 Leitweg-ID, Zustellung Portal/Peppol | Leitweg-ID fehlt oder falsch (BR-DE-15) | OZG-RE |
Nicht E-Rechnungs-pflichtig, aber zur Abgrenzung zu klären: Kleinbetragsrechnungen bis 250 € brutto und Fahrausweise (§§ 33, 34 UStDV) – sie dürfen weiter als PDF oder Papier verschickt werden.
Prüf-Checklisten je Gruppe
Kurz gehalten – die Herleitung steht im jeweils verlinkten Beitrag.
A – Basis jeder Rechnung (gilt für alle Vorfälle)
- BT-3 aus der ERP-Belegart abgeleitet, nicht fest verdrahtet
- BT-1 fortlaufend, eigener Nummernkreis je Belegart geprüft
- Leistungsdatum BT-72 oder Zeitraum BG-14 gesetzt (außer Anzahlung)
- BT-10 Käuferreferenz bzw. Leitweg-ID, BT-49 elektronische Adresse des Käufers
- Kontaktgruppe BG-6 (Name, Telefon, E-Mail) bei XRechnung
- Summen nach „erst runden, dann summieren“ (BR-CO-10 bis BR-CO-17)
- Format je Empfänger festgelegt: XRechnung (UBL/CII) oder ZUGFeRD-Profil EN 16931
B – Korrekturen: Storno, Gutschrift, Berichtigung, Selbstfakturierung
- Entscheidung je Fall: Storno + neu (381 → 380) oder Berichtigung (384)
- Alle Beträge positiv, Richtung kommt aus BT-3 (BR-27, BR-28)
- BT-25/BT-26 auf die Originalrechnung bei 381 und 384 immer befüllt – bei 381 prüft das kein Validator, es muss im Mapping sichergestellt sein
- UBL: 381 als CreditNote, nicht als Invoice
- Selbstfakturierung als 389, Gutschriftvereinbarung liegt vor
- Teilstorno: Menge reduziert, Einzelpreis unverändert, Steuersatz wie Original
- Korrektur im selben Format wie das Original übermittelt
C – Anzahlung, Abschlag, Teil- und Schlussrechnung
- BT-3 formatabhängig gemappt: 386 nur ZUGFeRD, XRechnung 380 bzw. 875/876/877 bei Bau
- Anzahlungsrechnung: eigene Position, kein Leistungsdatum, Hinweis in BT-22
- Schlussrechnung: volle Leistung, BT-113 = Summe der Anzahlungen brutto
- BR-CO-16: BT-115 = BT-112 − BT-113 + BT-114 nachgerechnet
- BG-3 je Anzahlungsrechnung mit BT-25 und BT-26
- Abgesetzte Steuerbeträge dargestellt (strukturiert, BT-22 oder Anhang)
- Gemischte Steuersätze in der Anzahlung: Restrechnung oder EXTENDED als Ausweg
- Negativer BT-115 (Überzahlung) → Gutschrift statt Schlussrechnung
D – Preise, Rabatte, Skonto, Zahlungsbedingungen
- Staffelpreise: BT-146 × Menge / BT-149 = BT-131 je Position
- Rabatte als BG-20/BG-27 mit Grundcode, nie als negative Artikelposition
- Skonto strukturiert in BT-20 (#SKONTO#), je Stufe eine Zeile
- Ratenplan: erste Fälligkeit in BT-9, Plan in BT-20, ggf. EXTENDED
- Zahlungsmittel BG-16 inkl. IBAN, Code BT-81 aus Codeliste
E – Umsatzsteuer-Sonderfälle
- Mapping-Tabelle ERP-Steuerkennzeichen → Kategorie (S, Z, E, AE, K, G, O) erstellt
- Je Kategorie und Satz genau eine BG-23-Gruppe
- Befreiungsgrund BT-120/121 nur bei E, AE, K, G, O – nie bei S/Z
- Reverse Charge (AE) und innergemeinschaftliche Lieferung (K): beide USt-IdNr. mit Länderpräfix – Verkäufer (BT-31) und Käufer (BT-48)
- Kategorie O isoliert: keine Mischung mit anderen Kategorien in einer Rechnung
- Fremdwährung: BT-6 = EUR und BT-111 (USt-Betrag in EUR) immer befüllt – der Validator prüft BT-111 nur, wenn BT-6 gesetzt ist
- Umrechnungskurs festgelegt: amtlicher Monatsdurchschnittskurs des BMF oder Tageskurs (§ 16 Abs. 6 UStG)
F – Sonderprozesse und Zustellung
- Mehrere Bestellungen je Auftrag: Rechnungsstellung 1:1 je PO (BT-13), Sammelrechnung über mehrere POs aufteilen
- B2G: Leitweg-ID je Auftraggeber gepflegt, XRechnung-Version passend zu BT-24
- Anhänge (Stundenzettel, Aufmaß, Vertrag) Base64-kodiert in BG-24 / BT-125, zulässiger MIME-Typ, Größe mit dem Empfänger geklärt
- Weitergeleitete oder weiterberechnete Rechnungen: Anhänge vorher in Base64 umwandeln und in die neue XML übernehmen
- ZUGFeRD: Rechnung und Anhänge im sichtbaren PDF verketten – keine zusätzliche PDF-Datei neben der factur-x.xml einbetten
- Abweichende Lieferadresse BG-13, Rechnungsempfänger im Konzern geklärt
- Dauerrechnungen: Vorgehen für Verträge mit Zahlungsplan mit Steuerberater geklärt
- Kleinbetragsrechnungen ≤ 250 € bewusst ein- oder ausgeschlossen
Vor Projektstart klären
Diese Punkte entscheiden über den Projektaufwand mehr als jedes Feldmapping – und sie liegen meist nicht in der IT. Fehlende Empfängeradressen sind dabei der häufigste Blocker: Die Rechnung ist valide und kommt trotzdem nicht an (fehlende E-Mail-Adressen im Debitorenstamm).
Empfänger und Zustellweg
- Aktive Debitoren der letzten 12–24 Monate ermittelt und nach Rechnungsvolumen priorisiert (statt den ganzen Stamm anzuschreiben)
- Rechnungs-E-Mail je Debitor als eigenes Feld, getrennt vom allgemeinen Kontakt; Syntax und MX geprüft
- Peppol-ID je Empfänger gegen das Peppol-Verzeichnis abgeglichen; Leitweg-ID je öffentlichem Auftraggeber
- Wunschformat je Großkunde: XRechnung UBL oder CII, ZUGFeRD-Profil, ggf. Kundenvorgaben (Lieferantennummer, PO-Pflicht, Anhänge)
- Kunden mit Lieferantenportal (Coupa, Ariba, Tungsten u. ä.) identifiziert – dort gilt der Portalweg, nicht E-Mail
- Konzernkunden: zentraler Rechnungseingang oder Shared Service Center statt Tochtergesellschaft
- Pflichtabgrenzung: inländisch B2B (pflichtig) vs. B2C, Ausland, Kleinbetrag ≤ 250 €
- Übergangsregeln geprüft: sonstige Formate bis 31.12.2026, bei Vorjahresumsatz ≤ 800.000 € bis 31.12.2027
Rechnungsadresse dauerhaft im Prozess verankern
Die einmalige Erhebung reicht nicht: Ohne festen Platz im Onboarding und in den Kundendokumenten ist der Stamm in zwei bis drei Jahren wieder lückenhaft. Das muss mit Client Service bzw. Vertriebsinnendienst abgestimmt werden, nicht nur mit IT und Buchhaltung.
- Kunden-Onboarding: Rechnungs-E-Mail, Peppol-ID/Leitweg-ID und Wunschformat als Pflichtangaben bei der Neuanlage – kein Debitor ohne geklärten Zustellweg
- Dokumente angepasst: Kundenstammblatt, Auftragsbestätigung, Rahmenvertrag/AGB, Lieferantenselbstauskunft mit Feld „E-Rechnungsadresse“
- Client Service eingebunden: Wer fragt nach, wer pflegt, wer ist Ansprechpartner bei Rückfragen der Kunden
- Änderungsprozess: Wechsel der Rechnungsadresse über definierten Kanal (Formular/Portal), nicht per Zuruf an den Kundenbetreuer
- Regelmäßige Prüfung: Bounces und Ablehnungen monatlich auswerten, Kunde wird aktiv kontaktiert
- Vertrieb informiert: Bei Bestandskunden-Terminen Rechnungsadresse und Format mit abfragen
Service-Angebot von rechnungsapi.de
Wir übernehmen auf Wunsch die Einholung der Rechnungs-E-Mail-Adressen für Ihre Kunden – von der Priorisierung der Debitoren über Peppol-Verzeichnisabgleich und Anschreiben bis zur Rückmeldung als importfähige Liste für Ihren Debitorenstamm. Sprechen Sie uns an: Termin buchen oder per E-Mail an support@rechnungsapi.de.
Versand und Absender
- Absenderpostfach für E-Rechnungen festgelegt, SPF/DKIM/DMARC gesetzt (XML-Anhänge landen sonst im Spam)
- Bounce-Rückkopplung: unzustellbare Rechnung erzeugt eine Aufgabe im Stammdatenprozess
- Eigene Peppol-ID und Access Point geklärt, falls Kunden Peppol verlangen
- Zustellnachweis: wo wird dokumentiert, wann welche Rechnung über welchen Kanal raus ist
Datenquellen und Zuständigkeiten
- Belegarten-Liste aus dem ERP inkl. selten genutzter Arten (Storno, Bonus, Bau, Selbstfakturierung)
- Steuerkennzeichen mit steuerlicher Bewertung (Steuerabteilung oder Steuerberater)
- Datenzugriff auf Fakturadaten (IT/Finance-IT), Ausgabeweg geklärt: Datenexport, Formulardruck oder PDF
- ERP-Version und Patchstand, PDF/A-3-Fähigkeit für ZUGFeRD
- Je Vorfall aus der Übersicht eine echte Beispielrechnung als Testfall
Recht, Archiv und Prozess
- Archivierung des strukturierten Teils (XML) GoBD-konform, Aufbewahrung 8 Jahre für Buchungsbelege
- Verfahrensdokumentation an neuen Rechnungsausgang angepasst
- Gutschriftvereinbarungen für Selbstfakturierung (389) vorhanden
- AVV mit dem E-Rechnungsdienstleister abgeschlossen
- Steuerberater-Termin für Anzahlungsdarstellung, Dauerrechnungen und Korrekturprozess
- Umstellungsplan: Stichtag, Parallelbetrieb PDF + E-Rechnung, Kundenanschreiben (ohne Werbung, sonst DSGVO-Einwilligung nötig)
- Eingangsseite mitgedacht: Empfang von E-Rechnungen ist seit 01.01.2025 Pflicht
Typische Probleme aus Projekten
Die Probleme entstehen fast immer dort, wo das ERP mehr kann als das EN-16931-Kernmodell: mehrere Bestellungen je Rechnung, Minusbeträge als Richtungsangabe, Rabatte als Artikelzeile. Die Lösung ist meist ein Split der Rechnung oder ein anderes Feld – nicht ein kreativer Workaround.
Bestellbezug (PO) und Rechnungsauftrennung
| Problem | Warum es scheitert | Lösung |
|---|---|---|
| Mehrere Bestellungen in einer Rechnung | BT-13 Bestellnummer gibt es nur einmal im Kopf; BT-132 trägt nur die Positionsnummer innerhalb dieser Bestellung | Eine Rechnung je PO; nur bei ZUGFeRD EXTENDED Bestellbezug je Position |
| PO-Nummer im Freitext oder Positionstext | Kreditorensysteme (SAP, Coupa, Ariba) matchen nur auf BT-13 → kein automatischer 3-Way-Match | PO strukturiert in BT-13, Bestellposition in BT-132 |
| PO-Nummer im falschen Feld | BT-10 (Käuferreferenz/Leitweg-ID) und BT-13 werden vertauscht | Feldbelegung je Großkunde abstimmen, BT-10 bei B2G immer Leitweg-ID |
| Mehrere Lieferscheine je Rechnung | BT-16 nimmt nur einen Lieferschein auf | Rechnung je Lieferschein, oder Lieferscheinnr. in BT-128 bzw. Positionsnotiz BT-127 |
| Mehrere Kostenstellen / Projekte | BT-19 und BT-11 nur einmal im Kopf | Kontierung je Position in BT-133, sonst Split je Projekt |
| Teillieferungen gegen eine PO | Kumulierte Rechnungsmenge übersteigt PO-Menge → Blockade beim 3-Way-Match | Menge je Rechnung gegen offene PO-Menge prüfen, BT-15 Wareneingang mitgeben |
| Kategorie O mit steuerpflichtigen Positionen | O darf nicht mit anderen Kategorien gemischt werden (BR-O-Regeln) | Durchlaufende Posten als eigene Rechnung |
| Gutschrift auf mehrere Rechnungen | BG-3 ist nicht in jedem Zielprofil mehrfach erlaubt | Je Ursprungsrechnung eine Gutschrift; Kardinalität im Zielprofil prüfen |
Anhänge
| Problem | Warum es scheitert | Lösung |
|---|---|---|
| Anhang als separate Datei neben der XML (z. B. eigener E-Mail-Anhang) | Rechnung ist nur, was in der XML steht; lose Dateien werden beim Empfänger getrennt oder gar nicht verarbeitet | Datei Base64-kodiert in BT-125 einbetten, Bezeichnung in BT-122/BT-123 |
| Weitergeleitete oder weiterberechnete E-Rechnung mit Anhängen | Die Anhänge liegen als Dateien vor (aus dem Rechnungseingang oder dem DMS) und landen nicht automatisch in der neuen XML | Vor dem Erzeugen in Base64 umwandeln und in BG-24 der neuen Rechnung einbetten |
| ZUGFeRD: zusätzliches PDF neben der factur-x.xml eingebettet | Validatoren und Empfangssysteme erwarten im PDF/A-3 nur die Rechnungs-XML – weitere eingebettete Dateien führen in der Praxis zu Fehlern | Rechnung und Anhänge zu einem sichtbaren PDF verketten; Anhänge zusätzlich Base64-kodiert in BG-24 der XML |
| Nicht zulässiger Dateityp (z. B. DOCX, ZIP) | Die Codeliste für MIME-Typen (BR-CL-24) erlaubt nur PDF, PNG, JPEG, CSV, XLSX und ODS | Vorher in PDF umwandeln |
| Sehr große Anhänge | Base64 vergrößert jede Datei um etwa ein Drittel; Portale und Postfächer haben Größenlimits | Scans komprimieren, Größenvorgaben des Empfängers vorab klären |
Negative Beträge
| Problem | Warum es scheitert | Lösung |
|---|---|---|
| Gutschrift als 380 mit Minusbeträgen | Validiert teils, wird beim Empfänger als zweite Forderung gebucht | BT-3 = 381, alle Beträge positiv, Originalrechnung in BT-25/BT-26 |
| Negativer Einzelpreis (BT-146) | BR-27 verbietet negative Netto-, BR-28 negative Bruttopreise | Preis positiv, Richtung über Menge oder BT-3 |
| Retoure in laufender Rechnung | – | Negative Menge (BT-129), positiver Preis → BT-131 negativ ist zulässig |
| Gutschrift in UBL mit negativer Menge | In CreditNote dreht eine negative Menge die Richtung erneut → Belastung | In 381 Mengen positiv |
| Rechnungssumme insgesamt negativ | BT-115 negativ ist zulässig, viele Empfänger verarbeiten es nicht | Als 381 über den Saldo ausstellen |
| Pfand-/Leergutrücknahme | Als Minuspreis modelliert → BR-27 | Negative Menge oder separate Gutschrift |
| ERP-Vorzeichenlogik im Export | Hauptbuch-Vorzeichen (Soll/Haben) wird 1:1 serialisiert | Vorzeichen im Mapping auf Belegart + Betrag umsetzen |
Rabatte, Boni und Zuschläge
| Problem | Warum es scheitert | Lösung |
|---|---|---|
| Rabatt als eigene Artikelzeile mit Minuspreis | BR-27; Empfänger bucht Rabatt als Ware | Positionsnachlass BG-27 oder Belegnachlass BG-20 |
| Kopfrabatt bei gemischten Steuersätzen | Ein BG-20 hat genau eine Steuerkategorie/-satz (BT-95/96) | Rabatt anteilig je Steuersatz in mehrere BG-20 aufteilen |
| Kopfrabatt ohne Steuerkategorie | BR-32 – Ablehnung | BT-95 und BT-96 immer setzen |
| Prozentrabatt mit Rundungsdifferenz | BT-92 ≠ BT-93 × BT-94 / 100 nach Rundung → Folgefehler BR-CO-17 | Betrag aus gerundeter Basis rechnen, dann summieren |
| Stückpreisrabatt vs. Positionsrabatt | BT-147 (Preisnachlass) ist nur Information zum Preis, BG-27 reduziert den Positionsbetrag | Listenpreisrabatt in BT-147/148, echte Positionsrabatte in BG-27 – nicht beides für denselben Rabatt |
| Kaskadierte Rabatte (10 % + 5 %) | Reihenfolge und Basis nicht eindeutig | Je Stufe ein BG-27 mit eigener Basis BT-137 oder Nettopreis bereits rabattiert in BT-146 |
| Naturalrabatt (Gratisware) | Position mit 0,00 € wird teils als Fehler gesehen | Position mit BT-146 = 0 ist zulässig; Grund in BT-127 |
| Nachträglicher Bonus / Jahresrückvergütung | Als Abzug in einer späteren Rechnung versteckt | Eigene Gutschrift 381 mit Bezugszeitraum (BG-14) |
| Skonto als Rabatt | Skonto ist bedingt, ein Nachlass nicht → Steuer zu früh gemindert | Skonto nur in BT-20 (#SKONTO#) |
| Fracht-/Verpackungszuschlag bei gemischten Sätzen | Zuschlag (BG-21) folgt der Hauptleistung, braucht aber eine Kategorie | Anteilig je Steuersatz aufteilen oder als eigene Position |
Was man für die Umsetzung braucht
Der größte Aufwand steckt selten im Format, sondern in fehlenden Stammdaten und in einer Belegart-Logik, die im ERP nie sauber getrennt wurde.
| Baustein | Was konkret | Wer liefert |
|---|---|---|
| Belegarten-Matrix | Jede ERP-Belegart → BT-3 je Zielformat (XR/ZF), inkl. Bau-Codes | Rechnungswesen + IT |
| Steuerkennzeichen-Mapping | ERP-Steuerkennzeichen → Kategorie, Satz, Befreiungsgrund (VATEX) | Rechnungswesen, Steuerberater |
| Debitorenstamm | USt-IdNr. mit Präfix, Rechnungs-E-Mail/Peppol-ID (BT-49), Leitweg-ID, Käuferreferenz, Wunschformat | Vertrieb / Debitorenbuchhaltung |
| Eigene Stammdaten | USt-IdNr., Steuernummer, Kontaktgruppe, IBAN | Rechnungswesen |
| Referenzlogik | Vorrechnungsbezug (BT-25/26) für Storno, Berichtigung, Schlussrechnung im ERP abrufbar | IT |
| Zahlungsbedingungen | Skonto-Stufen und Ratenpläne als Daten, nicht als Freitext | Rechnungswesen |
| Testfälle | Je relevantem Vorfall eine echte Rechnung, validiert gegen KoSIT/EN 16931 | IT + rechnungsapi.de |
| Validierung im Ausgang | API-Prüfung vor Versand, Fehlerliste mit Regel-ID und BT-Feld | rechnungsapi.de |
Mit rechnungsapi.de: Erzeugung aus JSON oder bestehendem PDF, Validierung gegen EN 16931 und XRechnung, verständliche Fehlerliste mit Regel-ID vor dem Versand. Wie die Prüfschichten zusammenspielen, erklärt unser Beitrag zum Schichtenmodell der Validierung.
Zum Weiterlesen: die Detail-Beiträge
| Beitrag | Deckt ab (Zeilen) |
|---|---|
| Anzahlung, Teilrechnung, Schlussrechnung | 5–9 |
| Storno, Gutschrift, Korrektur (381/384/389) | 14–16 |
| Skonto in der E-Rechnung | 13 |
| 1.643 Regeln, 8 Fehler: woran E-Rechnungen scheitern | 1, 12, 17–19, 21 |
| ZUGFeRD BT-Felder: der komplette Leitfaden | 2, 3, 4, 10 |
| OZG-RE und XRechnung beim Bund | 25 |
| Regelwerke und Validierung: das Schichtenmodell | A (Basis) |
| Vorsteuerrisiko E-Rechnung 2027 | Warum falsches Mapping steuerlich zählt |
Häufige Fragen
Welche Rechnungsart (BT-3) nehme ich für eine Anzahlungsrechnung?
In ZUGFeRD 386, in XRechnung 380, weil BR-DE-17 den Code 386 nicht zulässt. Bei Bauleistungen nach § 632a BGB gibt es die eigenen Codes 875 (Abschlag), 876 (Teilrechnung) und 877 (Schlussrechnung).
Darf eine E-Rechnung negative Beträge enthalten?
Negative Einzelpreise nicht (BR-27, BR-28). Negative Mengen und damit negative Positionsbeträge sind zulässig, etwa für Retouren. Eine Gutschrift wird als 381 mit positiven Beträgen und mit Bezug auf die Originalrechnung (BT-25/BT-26) ausgestellt.
Kann eine E-Rechnung mehrere Bestellungen abdecken?
Im EN-16931-Kernmodell nicht sauber: Die Bestellnummer BT-13 gibt es nur einmal im Kopf. Bestellung und Rechnung stehen 1:1 – werden mehrere Bestellungen gemeinsam geliefert, teilen Sie die Abrechnung in eine Rechnung je Bestellung auf. Nur ZUGFeRD EXTENDED kennt einen Bestellbezug je Position, und das verarbeiten längst nicht alle Empfänger.
Wie hänge ich Stundenzettel oder Aufmaß an eine E-Rechnung an?
Base64-kodiert direkt in der XML, in BG-24 mit Dateiname und MIME-Typ (BT-125). Separate Dateien neben der XML gehören nicht zur Rechnung. Bei ZUGFeRD verketten Sie Rechnung und Anhänge zusätzlich zu einem sichtbaren PDF – betten Sie kein weiteres PDF neben der factur-x.xml ein, das führt in der Praxis zu Fehlern.
Darf ich eine E-Rechnung in US-Dollar stellen?
Ja, die Rechnungswährung (BT-5) ist frei wählbar. Die Umsatzsteuer muss bei Umsätzen in Deutschland aber zusätzlich in Euro ausgewiesen werden (Art. 230 MwSt-Systemrichtlinie, Umrechnung nach § 16 Abs. 6 UStG). In der E-Rechnung setzen Sie dafür BT-6 = EUR und geben den Steuerbetrag in EUR in BT-111 an.
Müssen Kleinbetragsrechnungen als E-Rechnung gestellt werden?
Nein. Kleinbetragsrechnungen bis 250 € brutto und Fahrausweise (§§ 33, 34 UStDV) dürfen weiter als PDF oder Papier verschickt werden.
Fachliche Beratung vor dem Projekt
Wir gehen Ihre Geschäftsvorfälle mit Ihnen durch, zeigen, welche Prozesse und Dokumente angepasst werden müssen, und testen Ihre Beispielrechnungen gegen EN 16931 und XRechnung – bevor das IT-Projekt startet.
Quellen
EN 16931-1 (CEN/TC 434) mit Business Rules; XRechnung-Spezifikation (KoSIT) inkl. BR-DE-Regeln; ZUGFeRD 2.x / Factur-X (FeRD); UNTDID 1001 und 5305; §§ 13b, 14, 14c, 16 Abs. 6 UStG; Art. 230 MwSt-Systemrichtlinie 2006/112/EG; §§ 33, 34 UStDV; § 632a BGB; BMF-Schreiben zur E-Rechnung vom 15.10.2024.