Erlöserfassung (IFRS 15 / ASC 606)

Zeilenweise Erlösabgrenzung und planmäßige Realisierung: Vertragsverbindlichkeiten, zeitraumbezogene Methoden, Allokation des Transaktionspreises, Erstattungsverbindlichkeiten, Abonnements und Vertragsänderungen. Der Standardablauf bleibt unverändert – eine einfache Rechnungszeile erfasst den Erlös weiterhin in voller Höhe bei Ausstellung zeitpunktbezogen (Point in Time), was gemäß 606/15 für eine einzelne, bei Lieferung erfüllte Leistungsverpflichtung konform ist. Alles Nachfolgende muss pro Rechnungszeile explizit aktiviert werden (Opt-in).

Die Software ist 606/15-fähig; das berichtende Unternehmen ist dasjenige, das konform ist (oder eben nicht). Die Wahl der richtigen Methode pro Leistungsverpflichtung, die Schätzung von Einzelverkaufspreisen und Erstattungsquoten sowie die Beurteilung, ob verbleibende Güter oder Dienstleistungen bei einer Änderung eigenständig (distinct) sind, bleiben buchhalterische Ermessensentscheidungen des bilanzierenden Unternehmens.

Konten

Drei Konten aus dem Kontenplan bilden diese Zahlungsströme ab und sind als Schlüssel in den Buchungsregeln hinterlegt (pro Unternehmen überschreibbar via ledger/posting-rules/update): revenue.deferredIncome → 4910 "Ateinančių laikotarpių pajamos" (Vertragsverbindlichkeit / passive Rechnungsabgrenzung), revenue.refundLiability → 4450 "Grąžinimo įsipareigojimai pirkėjams" (Erstattungsverbindlichkeit), revenue.contractAsset → 2910 "Sukauptos pajamos" (Vertragsvermögenswert). Bestehende Unternehmen erhalten diese Konten durch erneute Anwendung der Kontenplan-Vorlage (ledger/accounts/apply-template).

Leistungsverpflichtungen auf Rechnungszeilen

Zeilen in sales/invoices/create|update akzeptieren recognition: { method, startDate, endDate, milestones }, wobei method einer der folgenden Werte sein kann:

Methode	Verhalten bei Ausstellung	Realisierung
point_in_time (Standard)	Haben Erlöse in voller Höhe	bei Ausstellung, unverändert
ratable (startDate..endDate)	Haben abgegrenzte Erlöse (Deferred Income)	tagesgewichteter monatlicher Zeitplan über den Leistungszeitraum
milestone (milestones[], Prozentwerte, die in Summe 100 ergeben)	Haben abgegrenzte Erlöse	eine Tranche pro Meilenstein, realisiert bei Eintritt des Ereignisses
percent_complete	Haben abgegrenzte Erlöse	über kumulierte Fortschrittsberichte

Debitoren und USt bleiben unangetastet: Bei Ausstellung wird Soll 2410 für den Bruttobetrag, Haben 4492 für die USt gebucht und der Nettobetrag zwischen Erlösen (zeitpunktbezogene Zeilen) und 4910 (abgegrenzte Zeilen) aufgeteilt. Zeitpläne werden in Basiswährung (EUR) zum Wechselkurs des Ausstellungsdatums gespeichert — sales/recognition-schedules/list (sales:read) zeigt jede Tranche mit dem Status pending | recognized | cancelled.

Allokation des Transaktionspreises. Bei mehr als einer Zeile teilt standaloneSellingPrice auf jeder Zeile den Netto-Rechnungsbetrag anteilig (pro rata) auf die Leistungsverpflichtungen auf (IFRS 15 §76–80); der allokierte Betrag – und nicht der angegebene Zeilenpreis – ist maßgeblich für die Aufteilung zwischen Erlösen/Abgrenzungen sowie für die Zeitpläne. Die USt verbleibt wie angegeben bei den Rechnungszeilen.

Engine zur Erlöserfassung

Die Erlöserfassung bucht Soll 4910 / Haben Erlöse (Dienstleistungs-/Produktkonto und Kostenstelle aus der ursprünglichen Zeile) als einzelne Journalbuchung pro Lauf, erfasst in sales/recognition/runs/list.

• POST /v1/sales/recognition/compute (sales:read) { asOfDate? } — Testlauf-Vorschau (Dry-run) der fälligen ratierlichen Tranchen.
• POST /v1/sales/recognition/run (sales:write) { asOfDate?, postingDate?, scheduleIds? } — Buchen der fälligen ratierlichen Tranchen oder exakt jener Tranchen, die in scheduleIds (beliebige Methode) benannt sind.
• POST /v1/sales/recognition/progress (sales:write) { invoiceLineId, percentComplete, date? } — percent_complete-Zeilen: Meldung des kumulierten Fortschritts; das neu verdiente Delta wird sofort gebucht, Rückgänge (Regressions) werden abgelehnt.
• POST /v1/sales/recognition/summary (sales:read) — bisher realisiert, verbleibend, Anzahl der ausstehenden Tranchen und nächstes Fälligkeitsdatum pro Zeile, plus Unternehmenssummen.

Drei Ereignisse steuern die Erlöserfassung ohne ständiges Polling: Ein Periodenabschluss (ledger/periods/lock) realisiert zunächst alles, was bis zum Ende der Periode fällig ist, und bucht es zum Stichtag des Periodenendes; die Ausstellung eines Liefer- und Leistungsprotokolls (sales/acts/issue) realisiert die ausstehenden Meilenstein-Tranchen der verknüpften Rechnung am Datum des Protokolls; und ein Fälligkeitstimer für Zeitpläne (Schedule-due timer) wird auf das nächste ratierliche Fälligkeitsdatum gesetzt und löst die Buchung pro Unternehmen aus, sobald dieses erreicht ist (bei einer geschlossenen Periode erfolgt später ein neuer Versuch). Meilensteine sind bewusst ereignisbasiert – das expectedDate eines Meilensteins dient nur der Planung und löst selbst niemals eine Erlöserfassung aus.

Variable Vergütung — Erstattungsverbindlichkeit

refundEstimatePercent auf einer Zeile bucht diesen Anteil des (allokierten) Nettobetrags bei Ausstellung ins Haben auf 4450 anstelle von Erlösen oder abgegrenzten Erlösen – erwartete Erstattungen sind vom Transaktionspreis ausgeschlossen (IFRS 15 §55). Der Status pro Rechnung findet sich in sales/refund-liability/list (geschätzt, verbraucht, festgestellte PSP-Abwicklungserstattungen, verbleibend).

Tatsächliche Werte (Actuals): Eine Gutschrift zur Rechnung bucht im Soll auf 4450 bis zur Höhe der verbleibenden Verbindlichkeit, bevor Erlöse berührt werden. sales/refund-liability/true-up (sales:write) { invoiceId, estimatedTotal, date? } korrigiert die Schätzung (True-up) und bucht das Delta in beide Richtungen gegen die Erlöse (mit dem verbrauchten Betrag als Untergrenze). PSP-Abwicklungserstattungen, die der Rechnung zugeordnet sind, werden auf der Verbindlichkeit erfasst und lösen einen refund_liability.actual Webhook aus — sie werden nicht direkt gegen 4450 gebucht, da die Minderung von Erlösen und Umsatzsteuer die Gutschrift als USt-Dokument erfordert.

Abonnements — Verträge zu Rechnungen

Wird einem Vertrag (Agreement) eine billingPeriod (monthly | quarterly | annual) zugewiesen, erstellt agreements/generate-invoice (agreements:write) für die nächste nicht abgerechnete Periode einen Rechnungs-Entwurf: Zeilen aus den Vertragspositionen (oder value als eine Zeile pro Periode), jeweils mit ratierlicher Erlöserfassung über den Leistungszeitraum. agreements/billing/run { asOfDate? } erfasst alle aktiven Verträge, generiert jede fällige Periode und lässt Verträge auslaufen, die über ihr Enddatum hinaus vollständig abgerechnet wurden. Letzte Rumpfperioden werden tagesgenau pro rata berechnet; autoRenew verlängert die Laufzeit um ihre eigene Dauer und setzt die Abrechnung fort. Generierte Rechnungen enthalten die agreementId (filterbar in sales/invoices/list).

Vertragsänderungen

POST /v1/sales/recognition/modify (sales:write) { invoiceLineId, approach, date?, newEndDate?, newMilestones? }:

• prospective — bricht den ausstehenden Zeitplan ab und verteilt den noch nicht realisierten Restbetrag ab dem Änderungsdatum über die neuen Bedingungen (verbleibende Güter/Dienstleistungen sind eigenständig: IFRS 15 §20(a), §21(a)). Ratierliche Zeilen übernehmen das newEndDate; Meilenstein-Zeilen übernehmen newMilestones (Prozentanteile des verbleibenden Betrags).
• cumulative_catch_up (nur ratierlich) — berechnet den Erlös neu, als ob die neuen Bedingungen von Anfang an gegolten hätten, und bucht die Differenz sofort in die entsprechende Richtung (einzelne teilweise erfüllte Leistungsverpflichtung: §21(b)); der Rest wird neu verteilt.

Preisminderungen laufen über Gutschriften: Eine Gutschrift zu einer Rechnung mit ausstehenden Zeitplänen belastet (Soll) zunächst die abgegrenzten Erlöse und kürzt den ausstehenden Plan von seinem hinteren Ende aus, dann die Erstattungsverbindlichkeit und erst danach die Erlöse. Preiserhöhungen sind zusätzliche Rechnungen mit ihrer eigenen Erlöserfassung — konzeptionsgemäß prospektiv.

Einschränkungen

• Zeitpläne und Buchungen der Erlöserfassung lauten auf Beträge in Basiswährung (EUR), fixiert zum Wechselkurs am Ausstellungsdatum; abgegrenzte Salden werden nach der Ausstellung nicht neu auf Wechselkursänderungen bewertet.
• Das Konto für Vertragsvermögenswerte (Contract Asset, 2910) ist im Kontenplan und als Buchungsschlüssel vorhanden, aber es wird noch von keinem automatisierten Ablauf für unberechnete Erlöse bebucht — die Realisierung vor der Rechnungsstellung ist derzeit eine manuelle Journalbuchung.
• Die Allokation erfordert einen Einzelverkaufspreis (Standalone Selling Price) für alle Zeilen der Rechnung oder für gar keine; der Residualwertansatz (§79(c)) ist nicht implementiert.
• Erstattungsverbindlichkeiten werden auf Rechnungsebene netto ohne USt nachverfolgt; der entsprechende Vermögenswert für das Recht auf Rückgabe gelieferter Güter (§B25) wird nicht abgebildet.
• Der kumulierte Aufholeffekt (Cumulative Catch-up) gilt für ratierliche Zeilen; eine Neuplanung von Meilensteinen ist ausschließlich prospektiv; percent_complete-Zeilen werden über Fortschrittsberichte angepasst, nicht über modify.
• Wesentliche Finanzierungskomponenten (§60–65), nicht zahlungswirksame Gegenleistungen und an einen Kunden zu zahlende Gegenleistungen sind nicht abgedeckt (Out of Scope).
• Automatische Zeitplan-Fälligkeitsläufe buchen an dem Tag, an dem sie ausgelöst werden; Nachholbuchungen in geschlossene Perioden werden abgelehnt — öffnen Sie die Periode oder verwenden Sie ein offenes Buchungsdatum.