IFRS 15 im SaaS: Ein Vertrag durch alle fünf Schritte gerechnet

Ein Kunde unterschreibt Anfang Januar: Jahreslizenz für 24.000 €, eine Datenmigration für 6.000 € und 0,01 € pro API-Call, monatlich nachträglich abgerechnet. Am selben Tag stellen Sie 30.000 € in Rechnung. Wie viel davon ist Januar-Umsatz? Je nach Auslegung des Vertrags entweder 9.375 € plus Nutzung oder 2.500 € plus Nutzung. Keiner der beiden Werte steht auf der Rechnung.

Dieser Beitrag geht die fünf Schritte von IFRS 15 an genau diesem Vertrag durch: Vertrag identifizieren, Leistungspflichten bestimmen, Transaktionspreis ermitteln, Preis verteilen, Umsatz erfassen. Alle Beträge sind ein erfundenes Beispiel. Der Text ersetzt keine Bilanzierungsrichtlinie und kein Gespräch mit Ihrem Abschlussprüfer. Er zeigt, welche Entscheidungen Finance treffen muss und welche Daten das Billing-System dafür liefern muss.

Schritt 1 und 2: Ist die Migration eine eigene Leistung?

Schritt 1 ist meist unstrittig. Ein unterschriebener Vertrag mit Preis, Laufzeit und Zahlungsbedingungen ist ein Vertrag im Sinne des Standards. Heikel wird es erst, wenn Rahmenvertrag, Bestellformular und ein Zusatzauftrag kurz nacheinander mit demselben Kunden geschlossen werden und wirtschaftlich zusammengehören. Dann kann es nötig sein, sie als einen Vertrag zu behandeln. Ihr System muss also wissen, welche Dokumente zusammengehören.

Schritt 2 ist die eigentliche Weichenstellung. Eine Zusage ist eine eigene Leistungspflicht, wenn der Kunde allein oder mit leicht verfügbaren Ressourcen Nutzen aus ihr ziehen kann und wenn sie im Vertragskontext von den übrigen Zusagen trennbar ist. Für die Migration gibt es zwei plausible Lesarten:

• Fall A: Die Migration überführt Altdaten in ein Format, mit dem der Kunde auch ohne Ihr Produkt arbeiten könnte, und Dritte bieten dieselbe Leistung an. Dann ist sie eine eigene Leistungspflicht.
• Fall B: Die „Migration“ ist im Kern die Einrichtung des Mandanten, ohne die der Zugang gar nicht funktioniert. Dann ist sie keine eigene Leistung. Die 6.000 € erhöhen den Preis der Lizenz und werden über die Laufzeit verteilt. Verschafft die einmalige Gebühr dem Kunden ein wesentliches Recht, etwa eine Verlängerung ohne erneute Gebühr, kann der Verteilungszeitraum sogar länger sein.

Die Rechnungsposition hilft bei dieser Frage nicht. Sales nennt beides „Onboarding“, auf der Rechnung steht eine Zeile mit 6.000 €. Maßgeblich ist, was tatsächlich geliefert wird. Legen Sie die Einordnung deshalb pro Produkt im Katalog fest und nicht pro Rechnung.

Die API-Gebühr behandeln wir hier als variablen Teil des Entgelts für den laufenden Plattformzugang. Das ist eine verbreitete Lesart, wenn der Zugang als Serie gleichartiger Monatsleistungen gilt.

Schritt 3: Der Transaktionspreis kennt die Nutzung noch nicht

Der Transaktionspreis ist der Betrag, den Sie für die zugesagten Leistungen erwarten. Fix sind 30.000 €. Die API-Gebühr ist variable Gegenleistung. IFRS 15 erlaubt, sie nur so weit einzubeziehen, wie eine wesentliche spätere Umsatzumkehr hochwahrscheinlich ausgeschlossen ist.

Für Gebühren, die monatlich nachträglich auf gemessener Nutzung beruhen, gibt es einen praktischen Weg. Bezieht sich die variable Zahlung ausschließlich auf die Leistung eines bestimmten Monats, wird sie diesem Monat direkt zugeordnet, statt über alle Leistungspflichten verteilt zu werden. Voraussetzung ist, dass das Ergebnis zum Verteilungsziel des Standards passt. Im Beispiel heißt das: Die Nutzung im Januar ist Januar-Umsatz, sobald sie gemessen ist.

Anders liegt es bei Mindestabnahmen, verfallenden Credits und Staffeln, die rückwirkend auf das ganze Jahr greifen. Angenommen, ab zwei Millionen Calls im Jahr sinkt der Preis rückwirkend auf 0,008 €. Dann ist der Januarpreis von 0,01 € nur vorläufig, und Sie brauchen eine Schätzung des Jahresvolumens samt Begrenzung. Wer diese Staffel in der Preislogik als gewöhnliche Monatsstaffel abbildet, bucht im Dezember eine Umsatzkorrektur, die niemand mehr erklären kann.

Schritt 4: 30.000 € nach Einzelveräußerungspreisen verteilen

In Fall A müssen die 30.000 € auf zwei Leistungspflichten verteilt werden, im Verhältnis ihrer Einzelveräußerungspreise. Die Rechnungsbeträge spielen dafür keine Rolle. Angenommen, Sie verkaufen die Lizenz einzeln regelmäßig für 27.000 € und eine vergleichbare Migration für 9.000 €. Der Kunde erhält also 36.000 € Listenwert für 30.000 €.

Die Migration erhält 7.500 € Umsatz, obwohl auf der Rechnung 6.000 € stehen. Die Lizenz erhält 22.500 €, also 1.875 € pro Monat statt 2.000 €. Der Rabatt von 6.000 € wird anteilig verteilt, weil nichts darauf hindeutet, dass er nur einer Leistung gilt. Ausnahmen gibt es für Rabatte, die nachweislich zu einem bestimmten Teil des Vertrags gehören. Die Begründung dafür müssen Sie dokumentieren.

Der Einzelveräußerungspreis ist ein Stammdatum. Er gehört versioniert in den Produktkatalog, mit Gültigkeitszeitraum und Herleitung, etwa aus beobachteten Einzelverkäufen oder Listenpreis abzüglich üblicher Rabatte. Ändern Sie ihn im März, darf sich die Verteilung der Januar-Verträge nicht verschieben. Wie man Kataloge so versioniert, beschreibt unser Beitrag zur Produktkatalog-Versionierung.

Schritt 5: Was Ende Januar im Hauptbuch steht

Die Lizenz wird über die Zeit erfüllt, linear über zwölf Monate. Die Migration nehmen wir als im Januar abgeschlossen an. Im Januar wurden 180.000 API-Calls gemessen, also 1.800 €, fakturiert Anfang Februar. Die Rechnung über 30.000 € ist sofort fällig.

Derselbe Vertrag, dieselbe Rechnung, und doch 6.875 € Unterschied im Januar-Umsatz. Diese Zahl hängt an einer einzigen Katalogentscheidung aus Schritt 2.

Die Umsatzsteuer folgt eigenen Regeln, etwa zum Leistungszeitpunkt und zu Vorauszahlungen, und nicht dem Revenue-Schedule. Die Rechnung über 30.000 € braucht die Pflichtangaben nach § 14 UStG, egal wie Sie den Umsatz verteilen. Steuer und Umsatzrealisierung sind zwei Regelwerke, die sich nur Schlüssel teilen: Kunde, Vertrag, Leistungszeitraum. Wie die Buchungen anschließend in die Finanzbuchhaltung gelangen, zeigt unser Beitrag zum DATEV-Export aus dem Billing.

Monat sieben: Upgrade als neuer Vertrag oder als Anpassung

Im Juli bucht der Kunde ein Zusatzmodul. Wie das in den Schedule eingeht, hängt an zwei Fragen: Ist das Modul eine eigenständige Leistung, und wird es zu seinem Einzelveräußerungspreis verkauft?

• Beides ja: Das Modul ist ein separater Vertrag mit eigenem Schedule. Der Januar-Vertrag bleibt unberührt.
• Eigenständig, aber mit Sonderrabatt: Der bisherige Vertrag wird prospektiv mit dem neuen zusammengeführt. Die noch nicht erfasste Gegenleistung aus der Lizenz (in Fall A 11.250 €) und der Preis des Moduls werden neu auf die verbleibenden Leistungen verteilt.
• Nicht eigenständig, etwa eine Erweiterung, die die bestehende Leistung verändert: Die Anpassung wird kumulativ zum Änderungszeitpunkt nachgeholt.

Die anteilige Berechnung auf der Rechnung beantwortet keine dieser Fragen. Sie ermittelt, was der Kunde für die restlichen sechs Monate zahlt. Die Umsatzseite braucht zusätzlich die Klassifikation der Änderung. Speichern Sie sie am Änderungsereignis, sonst rekonstruiert sie jemand beim Abschluss aus E-Mails.

Welche Daten das Billing-System liefern muss

Das Revenue-Modul ist nur so gut wie die Ereignisse, die es erhält. Für den Beispielvertrag sind das mindestens:

• Vertrag mit Version, Laufzeit und Verweis auf zusammengehörige Dokumente
• Vertragsposition mit Verweis auf eine Leistungspflicht, nicht nur auf ein Produkt
• Einzelveräußerungspreis je Leistungspflicht, versioniert mit Gültigkeitszeitraum
• Erfüllungsmethode je Leistungspflicht: über die Zeit, zu einem Zeitpunkt oder nach Nutzung
• Usage-Events mit Kunde, Meter, Leistungszeitraum, Menge, Quelle und Idempotency-Key
• Änderungsereignisse mit Datum und Klassifikation: separater Vertrag, prospektiv oder kumulativ

Verspätete Usage-Events bringen Nebenbuch und Hauptbuch regelmäßig auseinander. Kommt ein Event für Januar am 3. Februar an, nachdem der Januar geschlossen ist, braucht es eine feste Regel: Buchung im offenen Monat mit Verweis auf den Leistungszeitraum oder Wiedereröffnung der Periode. Doppelt gelieferte Events dürfen gar nicht erst zählen. Das Muster dafür beschreibt der IETF-Entwurf zum Idempotency-Key-Header, die Umsetzung im Billing unser Beitrag zu idempotent verarbeiteten Usage-Events.

Fünf Fragen, die Finance vor der Automatisierung beantwortet

Bevor Revenue-Schedules automatisch entstehen, sollten diese Antworten schriftlich vorliegen:

1. Welche Produkte im Katalog sind eigene Leistungspflichten, und warum? Insbesondere jede Setup-, Onboarding- und Implementierungsgebühr.
2. Woher stammen die Einzelveräußerungspreise, und wer darf sie ändern?
3. Welche Preisbestandteile wirken rückwirkend, etwa Jahresstaffeln, Mindestabnahmen oder verfallende Credits, und brauchen deshalb eine Schätzung?
4. Wie wird jede Art von Vertragsänderung klassifiziert, und wo wird das gespeichert?
5. Bis zu welchem Stichtag werden verspätete Usage-Events noch dem Leistungsmonat zugeordnet?

Testen Sie danach einen einzigen Vertrag wie den obigen von Anfang bis Ende: Rechnung, Schedule, Buchung im Hauptbuch, Upgrade im Juli. Erst wenn die Januarzahlen mit Ihrer Handrechnung übereinstimmen, lohnt sich die Ausweitung auf weitere Vertragsmuster.

Kontier verbindet Vertrags- und Nutzungsereignisse mit Metering, Rechnungsstellung und Revenue-Schedules; Details stehen auf der Seite zur nutzungsbasierten Abrechnung.