XRechnung für SaaS: Welche Felder Ihr Billing-Datenmodell liefern muss

Die erste XRechnung schreibt meist ein öffentlicher Kunde in den Vertrag. Eine Hochschule, ein Landesamt oder eine Stadtverwaltung kauft Ihre Software und teilt Ihnen mit, dass Rechnungen nur noch als XRechnung mit Leitweg-ID angenommen werden. Ab diesem Moment reicht ein schönes PDF nicht mehr. Ihr Billing muss Felder liefern, die es bisher nirgends gespeichert hat.

Dieser Beitrag zeigt, welche Felder das sind, wie typische SaaS-Positionen (Seats, anteilige Upgrades, Nutzung) in das Datenmodell der EN 16931 passen und wo die Daten herkommen. Wie Sie das Ergebnis anschließend prüfen, beschreibt der Beitrag zur Validierung von XRechnungen.

Wann eine SaaS-Rechnung eine XRechnung sein muss

Öffentliche Auftraggeber in der EU müssen elektronische Rechnungen nach EN 16931 annehmen und verarbeiten. Das regelt die Richtlinie 2014/55/EU. Deutschland setzt sie mit XRechnung um. Bund, Länder und Kommunen haben eigene Vorschriften dazu, das Ergebnis für Sie als Lieferant ist aber dasselbe: Der Auftraggeber verlangt eine XRechnung und nennt Ihnen die Leitweg-ID, an die sie adressiert wird.

Im Geschäft zwischen Unternehmen ist XRechnung eines von mehreren zulässigen E-Rechnungsformaten. Seit 2025 muss jedes inländische Unternehmen E-Rechnungen empfangen können, ab 2028 wird das Ausstellen Pflicht. Die Übergangsfristen und die Folgen für Ihre Softwareauswahl stehen im Beitrag zur Auswahl von E-Rechnung-Software. Für das Datenmodell spielt der Anlass kaum eine Rolle: Wer einmal vollständige EN-16931-Daten erzeugt, kann daraus XRechnung, ZUGFeRD oder Peppol BIS ausgeben.

Felder, die ein Self-Service-Checkout nie abfragt

Die Grundangaben einer Rechnung hat jedes Billing-System: Rechnungsnummer, Datum, Anschriften, USt-IdNr., Beträge. Bei XRechnung kommen Felder hinzu, die teils verpflichtend sind und teils nur dann, wenn der Kunde sie verlangt. Die Bezeichnungen in Klammern sind die Business Terms (BT) und Gruppen (BG) der EN 16931, über die Sie mit Ihrem Engineering-Team sprechen werden.

Der Leistungszeitraum ist keine XRechnung-Erfindung. § 14 Abs. 4 Nr. 6 UStG verlangt den Zeitpunkt der Leistung auf jeder Rechnung. Bei Abonnements ist das der abgerechnete Zeitraum und nicht das Rechnungsdatum. Im PDF steht er oft als Freitext in der Positionsbeschreibung. In der XRechnung braucht er eigene Datumsfelder.

Ein Märzlauf als XRechnung: Seats, Zusatz-Seats, API-Aufrufe

Ein Beispiel mit erfundenen Zahlen: Ein Kunde hat 40 Seats zu 25 € pro Monat. Am 16. März bucht er 10 weitere Seats dazu. Außerdem nutzt er 80.000 API-Aufrufe zu 2,00 € je 1.000 Aufrufe. Rechnungsdatum ist der 1. April, Abrechnungszeitraum (BG-14) 1. bis 31. März.

Summe netto 1.289,03 €, Umsatzsteuer 19 % = 244,92 €, Rechnungsbetrag 1.533,95 €.

Drei Punkte, die in diesem Beispiel stecken:

Der Zeilenbetrag ergibt sich aus Menge mal Preis je Basismenge. Beim API-Preis „2,00 € je 1.000“ steht deshalb 2,00 im Preisfeld und 1.000 als Basismenge. Wer stattdessen 0,002 € je Aufruf schreibt, rechnet zwar richtig, erzeugt aber eine Rechnung, die der Kunde nicht mit seinem Vertrag abgleichen kann.

Die anteilige Position braucht ihren eigenen Zeitraum. Ohne BG-26 sieht der Rechnungsempfänger 10 Seats zu 12,90 € und hält das für einen Preisfehler. Der Einzelpreis darf dabei mehr als zwei Nachkommastellen haben, Zeilenbeträge und Summen nicht. Legen Sie fest, ob Ihr System den Preis oder die Menge anteilig kürzt, und halten Sie das für alle Ausgabeformate gleich.

C62 ist der UN/ECE-Code für die Mengeneinheit „eins“ und passt für Seats und Aufrufe gleichermaßen. Was gezählt wird, sagt die Positionsbezeichnung.

Nutzung: aggregieren, aber nachvollziehbar

Niemand will 80.000 Rechnungspositionen. Aggregieren Sie Nutzung pro Tarifstufe und Zeitraum zu einer Zeile, aber speichern Sie im Billing, welche Events in welche Zeile eingeflossen sind. Fragt der Kunde nach, liefern Sie einen Nutzungsnachweis als Anlage. Das XML bleibt schlank.

Bei Staffelpreisen entsteht pro Stufe eine Zeile mit eigenem Preis. Fasst Ihr System alle Stufen zu einer Zeile mit Mischpreis zusammen, stimmt zwar der Betrag, aber der Preis passt zu keiner Zeile im Vertrag. Fällt die Nutzung später an, weil Events verspätet eintreffen, rechnen Sie sie in der nächsten Periode mit dem ursprünglichen Zeitraum als eigene Position ab. Die bereits ausgestellte Rechnung bleibt unverändert. Wie Sie Nutzung aufbereiten, bevor sie die Rechnung erreicht, beschreibt die Seite zur nutzungsbasierten Abrechnung.

Rabatte, Guthaben und Korrekturen

Rabatte gibt es in der EN 16931 auf zwei Ebenen. Ein Nachlass auf eine Position wird als Positionsnachlass (BG-27) geführt und mindert den Zeilenbetrag. Ein Nachlass auf die ganze Rechnung ist ein Nachlass auf Dokumentebene (BG-20) und braucht eine eigene Steuerkategorie. Ein Rabatt, der nur als negative Textzeile existiert, passt in keine der beiden Formen.

Vorausbezahlte Guthaben sind keine Rabatte. Sie mindern den Zahlbetrag, nicht das Entgelt. In der XRechnung stehen sie als bereits gezahlter Betrag (BT-113), der erst nach der Steuer abgezogen wird; die Steueraufschlüsselung bleibt unverändert. Wurde auf die Vorauszahlung schon Umsatzsteuer abgerechnet, braucht die Endrechnung zusätzliche Angaben. Diese Konstellation klären Sie am besten einmal mit Ihrer Steuerberatung.

Korrekturen nach Versand laufen über eine Rechnungskorrektur, im Alltag oft kaufmännische Gutschrift genannt (Rechnungsart 381), oder über Storno und Neuausstellung. Mit der Gutschrift im Sinne des § 14 UStG, also der Abrechnung durch den Leistungsempfänger, hat das nichts zu tun. In beiden Fällen verweist der neue Beleg auf die ursprüngliche Rechnung (BT-25). Ihr Datenmodell braucht dafür eine Beziehung zwischen Belegen und keinen Bearbeiten-Knopf.

Leitweg-ID und Bestellnummer gehören ins Kundenkonto

Die Leitweg-ID vergibt die Stelle, die die Rechnung empfängt. Das Format ist bei XRechnung spezifiziert. Ein Kunde kann mehrere haben, etwa wenn zwei Institute derselben Universität getrennt bestellen. Deshalb hängt sie am Vertrag oder an der Bestellung und nicht nur am Kundenstamm. Eine Skizze:

customer
  e_invoice_profile
    format: xrechnung | zugferd | pdf
    syntax: ubl | cii
    electronic_address: { scheme, id }
    po_number_required: true | false
    valid_from, valid_to
contract
  buyer_reference: "<Leitweg-ID der empfangenden Stelle>"
  po_number: "<Bestellnummer>"

Wichtig sind die Gültigkeitszeiträume. Ändert der Kunde seine Leitweg-ID, muss erkennbar bleiben, an welche Adresse eine bereits ausgestellte Rechnung ging. Wer das Profil versioniert, kann jede ausgestellte Rechnung später aus genau den Daten reproduzieren, mit denen sie entstanden ist.

Was vor der ersten XRechnung geklärt sein muss

• Leitweg-ID, Bestellnummer und Zustellkanal liegen schriftlich vom Kunden vor und sind am Vertrag gespeichert.
• Ihr Verkäufer-Kontakt mit Name, Telefon und E-Mail ist hinterlegt.
• Jede Position hat einen Zeitraum, anteilige Positionen haben einen eigenen.
• Nutzungspreise mit Basismenge sind als Preis plus Basismenge modelliert und nicht als Kleinstpreis.
• Rabatte sind Positions- oder Dokumentnachlässe, Guthaben sind gezahlte Beträge.
• Korrekturen verweisen auf die Ursprungsrechnung, die unverändert bleibt.

Wenn alle sechs Punkte stimmen, ist der XML-Export der kleinste Teil der Arbeit. Kontier erzeugt XRechnung aus denselben versionierten Preis-, Nutzungs- und Steuerdaten wie PDF und Buchung.