Alle Artikel

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

von Claribill Redaktion·05. August 2026·9 Min. Lesezeit
Mitarbeiterin und Mitarbeiter prüfen in einem sommerlichen Fahrradbetrieb eine Rechnung mit Rabatt und Versandkosten

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.

FallWirkungStrukturierte ZuordnungTypisches Beispiel
PreisnachlassErklärt den Weg vom Listenpreis zum tatsächlichen NettopreisPreisebene der PositionListenpreis 120 Euro, Nettopreis 100 Euro
Positionsrabatt oder PositionszuschlagVerändert nur eine RechnungszeileAllowance oder Charge an der Position5 Prozent Projektrabatt auf eine Dienstleistung
Belegnachlass oder BelegzuschlagVerändert die Gesamtrechnung oder einen klar abgegrenzten Teil davonAllowance oder Charge auf DokumentebeneTreuebonus, Fracht oder Versicherung
SkontoWird erst bei rechtzeitiger Zahlung wirksamZahlungsbedingungen2 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.

  1. Ausgangswert der Wartungsposition: 10 × 90 Euro = 900 Euro.
  2. Positionsrabatt: 5 Prozent von 900 Euro = 45 Euro.
  3. Nettozeile nach Rabatt: 855 Euro.
  4. Dokumentenzuschlag Fracht: 25 Euro.
  5. 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

  1. Rabatt als negative Produktmenge: Eine Rückgabe oder Gutschrift ist ein anderer Geschäftsfall als ein Preisnachlass.
  2. Doppelter Abzug: Der Nettopreis ist bereits reduziert, zusätzlich wird dieselbe Minderung als Allowance erfasst.
  3. Skonto sofort abgezogen: Eine bedingte Zahlungskondition verändert unzulässig den ursprünglichen Rechnungsbetrag.
  4. Steuersatz null für den Rabatt: Der Nachlass wird von der Steuerkategorie der betroffenen Leistung getrennt.
  5. Gesamtrabatt bei mehreren Steuersätzen nicht aufgeteilt: Die Steuerbasis je Kategorie wird falsch.
  6. Begründung nur im PDF: Der strukturierte Datensatz enthält weder Reason Code noch verständlichen Grund.
  7. 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

Verwandte Artikel

Kommentare

Noch keine Kommentare. Schreiben Sie den ersten.

    Kommentar schreiben

    Mit dem Absenden stimmen Sie der Verarbeitung gemäß Datenschutzerklärung zu. Kommentare werden vor Veröffentlichung geprüft.