Rabatt, Fracht, Zuschlag: Wo Beträge in der E-Rechnung hingehören

Rabatte, Frachten und Zuschläge gehören in einer E-Rechnung auf die Ebene, auf der sie wirtschaftlich wirken: Ein Nachlass für einen einzelnen Artikel wird an dieser Position ausgewiesen, ein Bonus auf den gesamten Auftrag auf Belegebene und ein Skonto ausschließlich in den Zahlungsbedingungen. Wer diese Ebenen vermischt, kann zwar eine rechnerisch plausible Summe erzeugen, aber trotzdem eine fachlich falsche oder nicht validierbare XML-Rechnung liefern.
Für KMU ist die Unterscheidung praktisch wichtig. Empfänger lesen nicht nur das sichtbare PDF, sondern importieren strukturierte Werte in Einkauf, Buchhaltung und Steuerprüfung. Dort entscheidet die Zuordnung darüber, welcher Nettobetrag, welcher Umsatzsteuersatz und welche Fälligkeit verarbeitet werden. Die folgenden Regeln helfen bei XRechnung, ZUGFeRD und anderen Rechnungen auf Basis der EN 16931.
Vier Ebenen, die nicht dasselbe bedeuten
Im Alltag heißen viele Beträge schlicht „Rabatt“. In der strukturierten Rechnung sind jedoch vier Fälle zu trennen. Die wirtschaftliche Vereinbarung gibt die Ebene vor, nicht die bequemste Eingabemöglichkeit in der Software.
| Fall | Wirkung | Strukturierte Zuordnung | Typisches Beispiel |
|---|---|---|---|
| Preisnachlass | Erklärt den Weg vom Listenpreis zum tatsächlichen Nettopreis | Preisebene der Position | Listenpreis 120 Euro, Nettopreis 100 Euro |
| Positionsrabatt oder Positionszuschlag | Verändert nur eine Rechnungszeile | Allowance oder Charge an der Position | 5 Prozent Projektrabatt auf eine Dienstleistung |
| Belegnachlass oder Belegzuschlag | Verändert die Gesamtrechnung oder einen klar abgegrenzten Teil davon | Allowance oder Charge auf Dokumentebene | Treuebonus, Fracht oder Versicherung |
| Skonto | Wird erst bei rechtzeitiger Zahlung wirksam | Zahlungsbedingungen | 2 Prozent bei Zahlung binnen zehn Tagen |
Die aktuelle Peppol-BIS-Billing-Dokumentation unterscheidet Preis-, Positions- und Dokumentebene ausdrücklich. Ein Betrag darf deshalb nicht gleichzeitig in den Nettopreis eingerechnet und nochmals als Nachlass ausgewiesen werden. Sonst wird er doppelt abgezogen.
Preisnachlass: Listenpreis erklären, nicht erneut summieren
Ein Lieferant kann einen Brutto- oder Listenpreis nennen und dazu einen Preisnachlass angeben. Daraus entsteht der tatsächliche Netto-Einheitspreis der Position. Dieser Preisnachlass erklärt die Preisbildung; er wird nicht noch einmal von der Zeilensumme abgezogen. Für automatische Empfänger ist der Nettopreis die maßgebliche Rechengröße.
Das ist besonders bei importierten Produktstammdaten relevant. Wenn im Katalog 120 Euro stehen, im Auftrag aber 100 Euro vereinbart wurden, sollte der Rechnungsprozess eindeutig festlegen, ob nur der vereinbarte Nettopreis übertragen oder zusätzlich die Preisableitung dokumentiert wird. Beides darf nicht zu zwei Abzügen führen.
Positionsrabatt: nur die betroffene Leistung verändern
Ein Positionsrabatt gehört an genau die Ware oder Leistung, für die er vereinbart wurde. Gleiches gilt für einen Zuschlag, etwa für Expressbearbeitung einer einzelnen Position. Die Umsatzsteuerkategorie und der Steuersatz der Position gelten auch für deren Nachlass oder Zuschlag. Ein pauschaler Steuersatz von null ist hier regelmäßig kein technischer Ausweg.
Die Zeilensumme muss nach der vereinbarten Preislogik nachvollziehbar bleiben. Mengen, Netto-Einheitspreis sowie Nachlässe oder Zuschläge dürfen sich nicht widersprechen. In der Praxis sollte die Software außerdem verhindern, dass ein Rabatt auf eine Textzeile, eine Zwischensumme oder eine bereits reduzierte Position ein zweites Mal angewandt wird.
Belegnachlass und Belegzuschlag: Gesamtbetrag samt Steuerwirkung
Ein auf die gesamte Rechnung bezogener Bonus wird auf Dokumentebene erfasst. Dasselbe gilt typischerweise für eine Frachtpauschale, Versicherung oder Verpackungsgebühr, wenn sie nicht als eigenständige Leistungsposition vereinbart wurde. Nach der EN-16931-Logik ergibt sich der Rechnungsnettobetrag aus der Summe der Nettozeilen abzüglich der Dokumentennachlässe zuzüglich der Dokumentenzuschläge.
Jeder Dokumentennachlass und jeder Dokumentenzuschlag braucht eine Begründung oder einen passenden Reason Code. Außerdem muss er einer Umsatzsteuerkategorie und gegebenenfalls einem Steuersatz zugeordnet sein. Enthält die Rechnung mehrere Steuersätze, reicht ein undifferenzierter Gesamtrabatt häufig nicht aus. Der Abzug muss so aufgeteilt werden, dass die Umsatzsteueraufschlüsselung je Kategorie rechnerisch stimmt.
Skonto: keine sofortige Minderung
Skonto ist vom Rechnungsrabatt zu trennen. Beim Ausstellen der Rechnung steht noch nicht fest, ob der Kunde rechtzeitig zahlt und den Abzug tatsächlich nutzt. Deshalb gehört die Kondition in die Zahlungsbedingungen, nicht als sofort wirksame Dokumenten-Allowance in die Nettosumme. Welche strukturierten Angaben dafür sinnvoll sind, erläutert der Beitrag Skonto in XRechnung und ZUGFeRD korrekt abbilden.
Praxisbeispiel 1: Wartung mit Positionsrabatt und Fracht
Ein österreichischer Maschinenbauer verrechnet zehn Wartungsstunden zu je 90 Euro netto. Für diese konkrete Dienstleistung sind 5 Prozent Projektrabatt vereinbart. Zusätzlich fallen 25 Euro Fracht für ein Ersatzteil an, die als Dokumentenzuschlag vereinbart wurden.
- Ausgangswert der Wartungsposition: 10 × 90 Euro = 900 Euro.
- Positionsrabatt: 5 Prozent von 900 Euro = 45 Euro.
- Nettozeile nach Rabatt: 855 Euro.
- Dokumentenzuschlag Fracht: 25 Euro.
- Rechnungsnettobetrag: 855 Euro + 25 Euro = 880 Euro.
Unter der vereinfachenden Annahme, dass sowohl Leistung als auch Fracht mit 20 Prozent Umsatzsteuer zu behandeln sind, ergeben sich 176 Euro Steuer und 1.056 Euro brutto. In der XML-Struktur bleibt sichtbar, dass 45 Euro nur die Wartungsposition mindern und 25 Euro die Rechnung erhöhen. Eine einzige negative „Rabattzeile“ würde diese Semantik verschleiern.
Vor der Ausstellung muss das Unternehmen dennoch prüfen, ob die Fracht im konkreten Geschäft tatsächlich dieselbe umsatzsteuerliche Behandlung teilt. Der Standard ersetzt keine steuerliche Beurteilung. Er sorgt dafür, dass das fachlich festgelegte Ergebnis eindeutig übertragen wird.
Praxisbeispiel 2: Gesamtrabatt bei zwei Steuersätzen
Ein deutscher Händler liefert Waren im Nettowert von 1.000 Euro zum Regelsteuersatz und weitere Waren im Nettowert von 500 Euro zu einem ermäßigten Steuersatz. Vertraglich gelten 10 Prozent Jahresbonus auf beide Warengruppen. Der Gesamtnachlass beträgt 150 Euro, darf aber für die Steuerberechnung nicht in einem steuerlosen Sammelbetrag verschwinden.
Die sachgerechte Aufteilung folgt der Vereinbarung: 100 Euro Nachlass werden der ersten Steuergruppe, 50 Euro der zweiten zugeordnet. Damit verbleiben 900 Euro beziehungsweise 450 Euro als steuerpflichtige Beträge. In der Umsatzsteueraufschlüsselung sind beide Gruppen getrennt zu berechnen. Ein einziger Belegnachlass mit einem beliebigen Steuersatz könnte zu einer falschen Steuerbasis führen und beim Empfänger oder Validator scheitern.
Gerade bei gemischten Warenkörben sollte die Aufteilungsregel dokumentiert und automatisiert werden. Eine rein proportionale Verteilung ist nur passend, wenn sie der geschäftlichen Vereinbarung entspricht. Gilt der Bonus beispielsweise nur für eine Produktgruppe, darf er nicht auf alle Positionen verteilt werden.
Welche Pflichtangaben Validatoren erwarten
Für Peppol BIS Billing muss der Betrag eines Dokumentennachlasses oder -zuschlags angegeben werden. Werden zusätzlich Basisbetrag und Prozentsatz geliefert, muss der Betrag aus Basis mal Prozentsatz geteilt durch 100 hervorgehen. Der Betrag ist in dieser Spezifikation auf höchstens zwei Dezimalstellen begrenzt. Eine Rundung sollte daher an einer zentral definierten Stelle erfolgen, nicht unabhängig in Oberfläche, PDF und XML.
Bei Dokumentennachlässen verlangt die Validierung außerdem eine Begründung oder einen Reason Code sowie eine Umsatzsteuerkategorie. Entsprechende Regeln gelten für Zuschläge. Das sind keine dekorativen Texte: Sie erlauben dem Empfänger, Rabatt, Fracht, Versicherung oder andere Preisbestandteile fachlich zuzuordnen.
Für die Mengeneinheit der zugrunde liegenden Positionen gelten ebenfalls strukturierte Codes. Pauschal, Stück und Stunde sollten nicht frei in das XML geschrieben werden. Der Beitrag Mengeneinheiten in der E-Rechnung zeigt, wie Unternehmen ihre Stammdaten dafür vorbereiten.
Deutschland und Österreich: gleicher Datenkern, anderer Pflichtkontext
Deutschland
Das deutsche Bundesfinanzministerium beschreibt die E-Rechnung als strukturierten Datensatz, der eine elektronische Verarbeitung ermöglicht. XRechnung und zulässige ZUGFeRD-Profile sind wichtige Beispiele. Bei hybriden Formaten ist entscheidend: Weichen Bildteil und strukturierter Datenteil voneinander ab, ist nach der BMF-Einordnung der strukturierte Teil maßgeblich. Ein Rabatt nur im sichtbaren PDF, aber nicht im XML, ist deshalb besonders riskant.
Unternehmen sollten ihre Testfälle nicht auf das Öffnen einer PDF-Datei beschränken. Sinnvoll sind eine technische Validierung, ein Import in das Zielsystem und ein Vergleich von Netto, Steuer, Brutto und Fälligkeit. Die Rechnungsfunktionen von Claribill umfassen unter anderem prozentuale und absolute Rabatte, Versandpositionen, mehrere Steuersätze sowie einen Factur-X-/ZUGFeRD-Export. Welche Eingabe im konkreten Fall fachlich richtig ist, bleibt dennoch eine Entscheidung des ausstellenden Unternehmens.
Österreich
Die deutsche B2B-Regelung darf nicht unverändert auf Österreich übertragen werden. Für österreichische Rechnungen bleiben Echtheit der Herkunft, Unversehrtheit des Inhalts und Lesbarkeit zentrale Anforderungen; das USP nennt einen verlässlichen Prüfpfad als möglichen Nachweis. Bei Rechnungen an den Bund und andere angeschlossene öffentliche Stellen kommen die dafür vorgesehenen Übermittlungswege und Formate hinzu.
e-Rechnung.gv.at unterstützt für strukturierte Rechnungen an die öffentliche Verwaltung unter anderem ebInterface und PEPPOL. Die Plattform nennt mehrere unterstützte ebInterface-Versionen und bietet einen Test-Upload. Vor dem Versand sollte ein Lieferant deshalb nicht nur „XML vorhanden“ prüfen, sondern das für den Empfänger verlangte Format, dessen Version und die korrekte steuerliche Aufteilung.
Sieben häufige Fehlerbilder
- Rabatt als negative Produktmenge: Eine Rückgabe oder Gutschrift ist ein anderer Geschäftsfall als ein Preisnachlass.
- Doppelter Abzug: Der Nettopreis ist bereits reduziert, zusätzlich wird dieselbe Minderung als Allowance erfasst.
- Skonto sofort abgezogen: Eine bedingte Zahlungskondition verändert unzulässig den ursprünglichen Rechnungsbetrag.
- Steuersatz null für den Rabatt: Der Nachlass wird von der Steuerkategorie der betroffenen Leistung getrennt.
- Gesamtrabatt bei mehreren Steuersätzen nicht aufgeteilt: Die Steuerbasis je Kategorie wird falsch.
- Begründung nur im PDF: Der strukturierte Datensatz enthält weder Reason Code noch verständlichen Grund.
- Abweichende Rundung: Oberfläche, PDF und XML berechnen aus mehr als zwei Dezimalstellen unterschiedliche Endsummen.
Fällt ein Fehler erst nach dem Versand auf, sollte die ursprüngliche Datei nicht still überschrieben werden. Wie eine nachvollziehbare Korrektur vorbereitet wird, steht im Beitrag E-Rechnung berichtigen: Wann eine neue XML-Datei nötig ist.
Checkliste für den Rechnungsprozess
- Ist der Betrag ein endgültiger Rabatt oder nur ein bedingtes Skonto?
- Gilt der Betrag für eine Position, eine Steuergruppe oder das gesamte Dokument?
- Sind Nettopreis und Allowance frei von doppelten Abzügen?
- Sind Grund oder Reason Code sowie Steuerkategorie und Steuersatz hinterlegt?
- Wird ein Gesamtrabatt bei mehreren Steuersätzen fachlich korrekt aufgeteilt?
- Nutzen Berechnung, PDF und XML dieselbe Rundungslogik?
- Stimmen Summe der Nettozeilen, Nachlässe, Zuschläge, Steuer und Zahlbetrag überein?
- Wurde die fertige Datei mit dem für den Empfänger passenden Validator geprüft?
- Wurde ein Probeimport durchgeführt, statt nur die sichtbare Darstellung zu kontrollieren?
Einführungsplan für kleine Rechnungsteams
Eine belastbare Umsetzung beginnt nicht im XML-Export, sondern bei den wiederkehrenden Geschäftsfällen. Das Team sammelt zunächst typische Rabatte, Boni, Frachten, Versicherungen und Skontovereinbarungen aus Angebot, Auftrag und Kundenstamm. Für jeden Fall werden Ebene, Berechnungsbasis, Steuerzuordnung, zulässiger Grund und verantwortliche Freigabe festgelegt. Seltene Sonderfälle bleiben bewusst in einer manuellen Prüfung, bis genügend Beispiele für eine sichere Regel vorliegen.
Danach sollte ein kleiner Testsatz entstehen: eine Rechnung mit Positionsrabatt, eine mit Dokumentenzuschlag, eine mit zwei Steuersätzen und eine mit Skonto. Für jeden Test werden erwartete Netto-, Steuer- und Bruttowerte vorab notiert. Erst dann folgen Export, technische Validierung und Probeimport. So zeigt eine Abweichung nicht nur, dass ein Fehler besteht, sondern auch, auf welcher Ebene er entstanden ist.
Im laufenden Betrieb empfiehlt sich eine Freigaberegel für neue Rabattarten und außergewöhnlich hohe Nachlässe. Änderungen an Produktpreis, Rabattlogik oder Steuercode sollten nachvollziehbar dokumentiert werden. Das reduziert Rückfragen, verhindert spontane Umgehungslösungen und schafft einen klaren Prüfpfad zwischen Auftrag, Rechnung, XML und Buchung.
Kurze Antworten auf typische Fragen
Darf Fracht immer als normale Rechnungsposition stehen?
Nein, „immer“ wäre zu pauschal. Ob Fracht eine eigenständige Leistung, ein Positionszuschlag oder ein Dokumentenzuschlag ist, hängt von Vertrag und steuerlicher Einordnung ab. Die XML-Struktur sollte diese wirtschaftliche Bedeutung abbilden.
Kann ein Gesamtrabatt einfach mit null Prozent Umsatzsteuer erfasst werden?
In der Regel nicht. Ein Dokumentennachlass muss der betroffenen Umsatzsteuerkategorie zugeordnet werden. Bei mehreren Kategorien kann eine Aufteilung in mehrere Nachlässe notwendig sein.
Reicht es, wenn die Endsumme korrekt ist?
Nein. Eine E-Rechnung transportiert semantische Daten. Empfänger und Validatoren prüfen auch Zeilen, Steuergruppen, Gründe, Formeln und Summenbeziehungen. Eine zufällig passende Endsumme kann fachliche Fehler verdecken.
Fazit
Der zuverlässigste Prüfgedanke lautet: Jeder Betrag wird dort erfasst, wo er wirtschaftlich wirkt. Preisnachlässe erklären den Nettopreis, Positionsrabatte verändern eine Zeile, Dokumentennachlässe und -zuschläge verändern die Belegsumme, Skonto bleibt bis zur Zahlung eine Kondition. Mit dieser Trennung werden Steueraufteilung, Validierung und automatischer Import deutlich robuster.
Quellen
- OpenPeppol: Peppol BIS Billing 3.0
- OpenPeppol: Betrag von Nachlässen und Zuschlägen
- OpenPeppol: Berechnung des Rechnungsnettobetrags (BR-CO-13)
- OpenPeppol: Begründung eines Dokumentennachlasses (BR-33)
- OpenPeppol: Umsatzsteuerkategorie eines Dokumentennachlasses (BR-32)
- Deutsches Bundesfinanzministerium: FAQ zur E-Rechnung
- Unternehmensserviceportal Österreich: E-Rechnung
- e-Rechnung.gv.at: ebInterface-Formate
Verwandte Artikel
Kommentare
Noch keine Kommentare. Schreiben Sie den ersten.


