Rechnungslogik

Die Erstellung von Rechnungen, Quittungen und eRechnungen in tebio ist das Ergebnis eines mehrstufigen, konfigurierbaren Prozesses.

Ob, wann und in welcher Form ein Abrechnungsdokument für einen Kunden erstellt wird, hängt von mehreren Faktoren ab: von der Zielgruppe des Kontos über die Produkt- und Subscription-Konfiguration bis hin zu Rating, Billrun, Zahlungsabwicklung, Rechnungseinstellungen und Dokumentenrendering.

Dieser Artikel erklärt die wichtigsten Einflussfaktoren auf die Rechnungslogik der tebio Plattform.

Überblick: Welche Faktoren beeinflussen die Rechnungsstellung?

Die Rechnungsstellung in tebio wird insbesondere durch folgende Bereiche beeinflusst:

Bereich	Einfluss auf die Rechnungslogik
Registrierung / Kontokonfiguration	B2B oder B2C, Brutto- oder Netto-Preislogik, eRechnung
Produktkonfiguration	Prepaid oder Postpaid, Charging Type, Bill Cycle, Service Period, Proration
Subscription-Konfiguration	individuelle Abweichungen vom Produktstandard, zum Beispiel Bill Cycle oder Zahlungsziel
Rating	Bewertung abrechenbarer Ereignisse und Ermittlung von Preisen, Rabatten und Steuern
Billrun	Ermittlung abrechenbarer Positionen und Erstellung von Rechnungen oder Quittungen
Finance und Payment	Zahlungstransaktion, Abgleich offener Posten, Reconciliation und Finanz-Journal
Rechnungseinstellungen	PDF-Layout, White-Label-Template, Logo, Fußzeile, Anschreiben und Detailreport
Kommunikation	Versand von Rechnungen, Quittungen oder Benachrichtigungen

1. Zielgruppe und steuerliche Berechnung

Ein wesentlicher Einflussfaktor wird bereits bei der Registrierung festgelegt: die primäre Zielgruppe Ihrer Produkte.

Dabei wird unterschieden zwischen:

• Privatkunden (B2C)
• Geschäftskunden (B2B)

Diese Auswahl beeinflusst, ob Preise in tebio inklusive oder exklusive Steuern verwaltet werden.

B2C: Preise inklusive Steuern

Bei Auswahl von Privatkunden (B2C) werden Preise brutto, also inklusive Steuern, verwaltet und angezeigt.

Die Steuerberechnung erfolgt von brutto zu netto. Das bedeutet: Aus dem Bruttobetrag werden der enthaltene Steuerbetrag und der Nettobetrag rechnerisch abgeleitet.

Diese Berechnung kann Rundungsdifferenzen verursachen. Aus diesem Grund werden bei dieser Preislogik keine eRechnungen erstellt.

Typische Dokumente in B2C-Szenarien sind:

• Quittungen
• Rechnungen ohne eRechnungsformat
• Zahlungsbestätigungen
• Rechnungskorrekturen, sofern erforderlich

B2B: Preise exklusive Steuern

Bei Auswahl von Geschäftskunden (B2B) werden Preise netto, also exklusive Steuern, verwaltet und angezeigt.

Die Steuerberechnung erfolgt von netto zu brutto. Das bedeutet: Auf den Nettobetrag wird die Steuer berechnet und daraus der Bruttobetrag gebildet.

Diese Logik vermeidet die typischen Rundungsdifferenzen einer Brutto-zu-Netto-Berechnung. Bei B2B-Konfiguration können eRechnungen erstellt werden, sofern die weiteren Voraussetzungen erfüllt sind.

Typische Dokumente in B2B-Szenarien sind:

• Rechnungen
• eRechnungen
• Rechnungskorrekturen
• strukturierte Abrechnungsdokumente
• Rechnungen mit Bestellnummer, Projektreferenz oder Vertragsreferenz

2. Rating: Die Vorstufe der Abrechnung

Bevor eine Rechnung oder Quittung erstellt werden kann, müssen abrechenbare Ereignisse bewertet werden. Dieser Prozess wird Rating genannt.

Abrechenbare Ereignisse können aus verschiedenen Quellen entstehen, zum Beispiel:

• Aktivierung einer Subscription
• Verlängerung einer Subscription
• Kündigung oder Deaktivierung
• Pause oder Reaktivierung
• Option Change
• Bestellung
• Versandkosten
• Zahlung oder Rechnung als Grundlage für Servicegebühren
• nutzungsbasierte Ereignisse

Das Rating ermittelt unter anderem:

• welche Subscription betroffen ist
• welches Produkt oder welche Option betroffen ist
• welcher Preis anzuwenden ist
• welcher Zeitraum betroffen ist
• welche Steuerlogik gilt
• ob Rabatte anzuwenden sind
• welchem Bill Cycle und welcher Bill Period die Position zugeordnet wird
• ob die Position Prepaid oder Postpaid ist

Nach erfolgreichem Rating entsteht eine bewertete abrechenbare Position. Diese Position ist noch nicht zwingend abgerechnet. Sie ist zunächst für einen späteren Billrun vorbereitet.

Vereinfacht gibt es zwei wichtige Zustände:

Status	Bedeutung
Rated	Die Position wurde bewertet und ist für einen Billrun vorbereitet.
Billed	Die Position wurde in einem Billrun berücksichtigt und abgerechnet.

3. Bill Cycle und Service Period

Zwei zentrale Konzepte für wiederkehrende Abrechnung sind Bill Cycle und Service Period.

Diese Begriffe dürfen nicht verwechselt werden.

Bill Cycle

Der Bill Cycle bestimmt, wann tebio abrechenbare Positionen in einem Billrun berücksichtigt und daraus eine Rechnung oder Quittung erzeugt.

Typische Frequenzen sind:

• täglich
• wöchentlich
• monatlich
• quartalsweise
• halbjährlich
• jährlich

Ein Bill Cycle definiert also den Abrechnungsrhythmus.

Beispiel:

Ein monatlicher Bill Cycle bedeutet, dass abrechenbare Positionen typischerweise monatlich gesammelt und abgerechnet werden.

Bill Period

Aus einem Bill Cycle entstehen konkrete Bill Periods.

Beispiel für einen monatlichen Bill Cycle:

• 01.03. bis 31.03.
• 01.04. bis 30.04.
• 01.05. bis 31.05.

Der Billrun verwendet die Bill Period, um zu bestimmen, welche bewerteten Positionen in einem Abrechnungslauf berücksichtigt werden.

Service Period / Prolongation Period

Die Service Period beschreibt den Zeitraum, für den eine Leistung erbracht oder berechnet wird.

In Subscription-Kontexten hängt sie eng mit der Prolongation Period zusammen. Eine Prolongation beschreibt die Verlängerung einer Subscription um eine weitere Serviceperiode.

Beispiel:

Ein Produkt kostet 9,99 € pro Woche. Dann gilt der Preis für eine wöchentliche Serviceperiode.

Die Serviceperiode bestimmt also, für welchen Zeitraum eine Gebühr gilt. Der Bill Cycle bestimmt, wann diese Gebühr auf einer Rechnung erscheint.

Beispiel: Monatlicher Bill Cycle, wöchentliche Service Period

Ein Produkt hat:

• monatlichen Bill Cycle
• wöchentliche Service Period
• wiederkehrenden Wochenpreis

In diesem Fall erhält der Kunde einmal pro Monat eine Rechnung. Diese Rechnung kann vier oder fünf wöchentliche Gebühren enthalten.

Dieses Beispiel zeigt: Bill Cycle und Service Period können identisch sein, müssen es aber nicht.

prolongationPeriodStartDay

Der Parameter prolongationPeriodStartDay beeinflusst, wann die erste und die folgenden Verlängerungen einer Subscription stattfinden.

Je nach Einheit der Prolongation Period kann der Wert unterschiedlich interpretiert werden:

Einheit	Bedeutung
Woche	Wochentag, zum Beispiel Montag bis Sonntag
Monat	Tag im Monat
Jahr	Tag im Jahr

Wenn kein Starttag definiert ist, kann die erste Verlängerung relativ zum Aktivierungsdatum der Subscription erfolgen.

Das beeinflusst, wann wiederkehrende abrechenbare Ereignisse entstehen und in welchem Billrun sie berücksichtigt werden.

4. Produktkonfiguration

Die Produktkonfiguration hat großen Einfluss darauf, welche Abrechnungsdokumente entstehen und wann diese erzeugt werden.

Wichtige Parameter sind unter anderem:

• paymentStrategy
• chargingType
• billCycle
• prolongationPeriod
• prolongationPeriodStartDay
• prorataStart
• prorataEnd
• Produktpreise
• Optionen
• zulässige Zahlungsmethoden
• Steuerkategorie
• Laufzeit und Kündigungsregeln

paymentStrategy: Prepaid oder Postpaid

Die paymentStrategy bestimmt, ob eine Leistung vorab oder nachträglich abgerechnet wird.

paymentStrategy	Bedeutung
PREPAID	Der Kunde zahlt im Voraus.
POSTPAID	Die Leistung wird zunächst erbracht und später abgerechnet.

Prepaid

Bei Prepaid steht die Zahlung am Anfang des Prozesses.

Der Kunde bezahlt vor oder während der Bestellung. Erst danach wird die Leistung bereitgestellt oder verlängert.

Typische Anwendungsfälle:

• digitale Subscriptions mit direkter Zahlung
• B2C-Checkout über Hosted Pages
• Zahlung per Kreditkarte oder PayPal
• Guthaben- oder Vorauszahlungsmodelle
• Produkte, bei denen Zahlungsausfälle vermieden werden sollen

Bei Prepaid entstehen typischerweise Quittungen, Zahlungsbestätigungen oder Abrechnungsbelege für bereits bezahlte Leistungen.

Postpaid

Bei Postpaid steht die Leistungserbringung vor der Zahlung.

Der Kunde nutzt die Leistung zunächst. Die Abrechnung erfolgt später, zum Beispiel im Rahmen eines monatlichen Billruns.

Typische Anwendungsfälle:

• Geschäftskundenverträge
• Rechnung mit Zahlungsziel
• SEPA-Lastschrift nach Rechnungserstellung
• nutzungsbasierte Abrechnung
• B2B-Subscriptions
• eRechnungen

Bei Postpaid entstehen typischerweise Rechnungen und, bei entsprechender B2B-Konfiguration, eRechnungen.

chargingType: in advance oder in arrear

Der chargingType bestimmt, ob wiederkehrende Gebühren am Anfang oder am Ende einer Serviceperiode berechnet werden.

chargingType	Bedeutung
IN_ADVANCE	Die Leistung wird im Voraus für die kommende Serviceperiode berechnet.
IN_ARREAR	Die Leistung wird nachträglich für die vergangene Serviceperiode berechnet.

IN_ADVANCE

Bei IN_ADVANCE wird die wiederkehrende Gebühr zu Beginn einer Serviceperiode berechnet.

Beispiel:

Eine monatliche Subscription beginnt am 1. März. Die Monatsgebühr für März wird bereits am Anfang der Periode berechnet.

Wenn die Subscription während der Periode pausiert, gekündigt oder geändert wird, können anteilige Korrekturen oder Erstattungen erforderlich sein, sofern die Produktkonfiguration dies vorsieht.

IN_ARREAR

Bei IN_ARREAR wird die wiederkehrende Gebühr nach Abschluss oder am Ende einer Serviceperiode berechnet.

Beispiel:

Eine monatliche Subscription läuft im März. Die Gebühr für März wird erst nach Abschluss der Periode berechnet.

Dieses Modell eignet sich besonders für Postpaid-Szenarien und nutzungsbasierte Abrechnung.

Proration: anteilige Berechnung

Proration bedeutet, dass Gebühren anteilig berechnet oder korrigiert werden, wenn eine Subscription nicht exakt am Anfang oder Ende einer Serviceperiode beginnt oder endet.

Wichtige Parameter sind:

• prorataStart
• prorataEnd

prorataStart

prorataStart beeinflusst, ob die erste Serviceperiode anteilig berechnet wird, wenn eine Subscription mitten in einer Periode beginnt.

Beispiel:

Eine monatliche Subscription startet am 15. März.

Wenn prorataStart aktiv ist, kann tebio die Gebühr für den Zeitraum vom 15. März bis zum Ende der relevanten Serviceperiode anteilig berechnen.

prorataEnd

prorataEnd beeinflusst, ob am Ende einer Subscription anteilige Korrekturen erfolgen.

Beispiel:

Eine Subscription wurde im Voraus für den gesamten Monat berechnet, endet aber am 22. des Monats.

Wenn prorataEnd aktiv ist, kann tebio den nicht genutzten Zeitraum anteilig korrigieren oder erstatten.

Dieser Fall ist besonders relevant bei:

• Kündigung
• Deaktivierung
• Pause
• Reaktivierung
• Option Change
• Mengenänderung
• im Voraus berechneten wiederkehrenden Gebühren

5. Subscription-spezifische Abweichungen

Ein Produkt definiert den Standard für die Abrechnungslogik. Auf Subscription-Ebene können bestimmte Parameter jedoch individuell abweichen, sofern die Konfiguration dies erlaubt.

Wichtige Beispiele sind:

• abweichender Bill Cycle
• abweichendes Zahlungsziel
• individuelle Zahlungsbedingungen
• externe Referenzen
• Projektreferenz
• Bestellnummer oder PO-Nummer
• individuelle Eigenschaften

Beispiel:

Ein Produkt ist standardmäßig monatlich abrechenbar. Für einen bestimmten Geschäftskunden wird auf Subscription-Ebene ein abweichender Abrechnungszyklus oder ein individuelles Zahlungsziel hinterlegt.

Solche Abweichungen beeinflussen, wann eine Rechnung fällig wird, welche Referenzen auf der Rechnung erscheinen und wie Folgeprozesse in Finance und Billing verarbeitet werden.

6. Billrun: Der Abrechnungslauf

Der Billrun ist der zentrale Prozess zur Erstellung von Rechnungen, Quittungen oder anderen Abrechnungsdokumenten.

Ein Billrun ermittelt, welche bewerteten Positionen abrechenbar sind, erzeugt daraus ein Abrechnungsdokument und führt die nachgelagerten Verarbeitungsschritte aus.

Ein Billrun kann:

• automatisch gestartet werden
• manuell gestartet werden
• eine einzelne Subscription betreffen
• mehrere Subscriptions oder einen ganzen Abrechnungszeitraum betreffen

Automatischer Billrun

Ein automatischer Billrun prüft regelmäßig, ob abrechenbare Positionen vorhanden sind.

Typische Voraussetzungen:

• Billrun ist für den Client oder Tenant aktiviert.
• Es gibt bewertete, noch nicht abgerechnete Positionen.
• Die relevante Bill Period ist abgeschlossen oder abrechenbar.
• Eine konfigurierte Karenzzeit oder Grace Period ist abgelaufen.
• Die Subscription und die Abrechnungseinstellungen erlauben die Verarbeitung.

Je nach Konfiguration gibt es getrennte automatische Prozesse für Prepaid und Postpaid.

Manueller Billrun

Ein manueller Billrun kann verwendet werden, wenn eine einzelne Subscription oder ein definierter Vorgang gezielt abgerechnet werden soll.

Typische Gründe:

• Prüfung eines konkreten Falls
• manuelle Abrechnung
• Test im Playground
• kontrollierter Start nach Konfigurationsänderung
• Wiederholung nach korrigierter Konfiguration

Billrun-Ablauf

Ein Billrun umfasst vereinfacht folgende Schritte:

1. Abrechenbare Positionen ermitteln.
2. Positionen aggregieren.
3. Rechnung oder Abrechnungsdokument erzeugen.
4. Positionen als abgerechnet markieren.
5. Rechnung prüfen oder pausieren, falls konfiguriert.
6. Rechnung finalisieren.
7. PDF-Dokument rendern und speichern.
8. Empfänger benachrichtigen, falls konfiguriert.
9. Zahlung oder offene Forderung weiterverarbeiten.
10. Finanzbuchhaltung und Journal aktualisieren.
11. Billrun-Report erzeugen.

Je nach Konfiguration können einzelne Schritte automatisch ausgeführt oder zur Prüfung angehalten werden.

7. Prüfung vor Finalisierung

tebio kann so konfiguriert werden, dass ein Billrun nach Erstellung der Rechnungen pausiert.

Das ist besonders wichtig, weil finalisierte Rechnungen nicht einfach geändert oder gelöscht werden sollten.

Während der Prüfung können Nutzer:

• Billrun-Report herunterladen
• einzelne Rechnungen prüfen
• PDF-Dokumente rendern
• Summen mit vorherigen Billruns vergleichen
• auffällige Positionen prüfen
• Konfiguration oder Stammdaten kontrollieren

Wenn die Rechnungen korrekt sind, wird der Billrun fortgesetzt und finalisiert.

Wenn die Rechnungen nicht korrekt sind, kann der Billrun vor Finalisierung verworfen werden, sofern der Prozess dies unterstützt. Danach können die Ursachen korrigiert und der Billrun erneut gestartet werden.

Wichtig: Während der Korrektur sollte verhindert werden, dass dieselben Positionen unmittelbar erneut automatisch abgerechnet werden.

Finalisierte Rechnungen

Sobald eine Rechnung finalisiert ist, gilt sie als abgeschlossenes Abrechnungsdokument.

Eine finalisierte Rechnung sollte nicht direkt verändert oder gelöscht werden.

Wenn eine finale Rechnung falsch ist, erfolgt die Korrektur über:

• Storno
• Rechnungskorrektur
• Gutschrift im fachlichen Sinne
• neues korrigierendes Abrechnungsdokument

Das ist wichtig für Nachvollziehbarkeit, Buchhaltung und Compliance.

8. Zahlung, Reconciliation und Finanz-Journal

Nach der Rechnungserstellung ist die Abrechnung nicht immer abgeschlossen.

Je nach Zahlungsmethode und Zahlungsstrategie können weitere Prozesse folgen:

• Zahlungstransaktion wird ausgelöst.
• Zahlung wird vom Anbieter bestätigt oder abgelehnt.
• Zahlungseingang wird erfasst.
• Zahlung wird mit offenen Rechnungen abgeglichen.
• Offene Posten werden aktualisiert.
• Buchungen werden im Finanz-Journal erstellt.
• Finanzdaten werden exportiert oder für DATEV vorbereitet.

Dieser Abgleich wird häufig als Reconciliation bezeichnet.

Ziel ist, Rechnungen, Zahlungen und Buchungen konsistent zusammenzuführen.

Das Finanz-Journal dokumentiert buchhalterisch relevante Vorgänge, zum Beispiel:

• Rechnung erstellt
• Zahlung eingegangen
• Zahlung fehlgeschlagen
• Rechnung storniert
• Rechnungskorrektur erstellt
• Erstattung erfasst
• offene Forderung ausgeglichen

9. Das Rechnungsdokument

Die fachliche Rechnungslogik bestimmt, welche Positionen und Beträge entstehen.

Die Rechnungseinstellungen bestimmen, wie das PDF-Dokument aussieht.

tebio unterstützt White-Label-Rechnungsvorlagen, die an das Branding und die rechtlichen Anforderungen des Clients angepasst werden können.

Ein typisches Rechnungsdokument kann aus folgenden Bestandteilen bestehen:

1. optionales Anschreiben
2. Rechnung
3. optionaler Invoice Detail Report

Anschreiben

Das optionale Anschreiben kann dynamische Informationen enthalten, zum Beispiel:

• Name des Empfängers
• Rechnungsnummer
• Rechnungsdatum
• Fälligkeitsdatum
• Rechnungsbetrag
• Abrechnungszeitraum
• Kundennummer

Das Anschreiben eignet sich für individuelle Hinweise, Zahlungsinformationen oder begleitende Kommunikation.

Rechnung

Die Rechnung selbst enthält typischerweise:

• Logo oder Header-Grafik
• Absenderadresse
• Empfängeradresse
• Rechnungsnummer
• Kundennummer
• Rechnungsdatum
• Leistungszeitraum
• Fälligkeitsdatum
• USt.-ID, sofern vorhanden
• Rechnungspositionen
• Steuerinformationen
• Netto- und Bruttobeträge
• Zahlungsinformationen
• rechtliche Pflichtangaben
• Fußzeile

Rechnungspositionen

Rechnungspositionen können je nach Einstellung unterschiedlich detailliert dargestellt werden.

Mögliche Darstellungen sind zum Beispiel:

• einzelne Positionen ohne Aggregation
• Aggregation nach Produkt oder Option
• Aggregation nach Gebührenart
• Aggregation nach Produkt oder Option und Gebührenart

Typische Gebührenarten sind:

• Einrichtungsgebühr
• wiederkehrende Gebühr
• Beendigungsgebühr
• anteilige Korrektur oder Erstattung
• nutzungsbasierte Position
• Versandkosten
• sonstige Gutschrift oder Belastung

Die fachlichen Beträge entstehen aus Rating und Billrun. Die Darstellung im PDF kann diese Beträge detailliert oder zusammengefasst anzeigen.

Summen und Steuern

Die Rechnung enthält typischerweise Summenbereiche für:

• Summe ohne Steuern
• Steuerbetrag
• Summe inklusive Steuern

Wenn mehrere Steuersätze relevant sind, können Steuerbeträge je Steuersatz ausgewiesen werden.

Die Steuerberechnung hängt von der B2B-/B2C-Konfiguration und der jeweiligen Steuerlogik ab.

Footer und rechtliche Angaben

Der Footer kann genutzt werden für:

• Kontodaten
• Zahlungshinweise
• rechtliche Hinweise
• Handelsregisterangaben
• Geschäftsführer
• USt.-ID
• Service- oder Kontaktinformationen
• Hinweise zu Einwendungen gegen Rechnungen

Diese Angaben werden in den Rechnungseinstellungen konfiguriert.

Invoice Detail Report

Der optionale Invoice Detail Report enthält eine detailliertere Aufschlüsselung der Rechnung.

Er kann insbesondere hilfreich sein bei:

• vielen Einzelpositionen
• mehreren Subscriptions
• Produkt- und Optionsentgelten
• nutzungsbasierter Abrechnung
• Rabatten
• anteiligen Korrekturen
• komplexen Geschäftskundenrechnungen

Der Detail Report zeigt mehr fachliche Details als die Rechnung selbst. Die Steuerbeträge werden jedoch typischerweise auf der Rechnung und nicht zwingend im Detail Report ausgewiesen.

10. Steuern und Rabatte

Steuern und Rabatte beeinflussen die Rechnungsbeträge unmittelbar.

Steuern

Die Steuerlogik hängt unter anderem ab von:

• B2B- oder B2C-Kontokonfiguration
• Preislogik inklusive oder exklusive Steuern
• Steuerkategorie des Verkäufers
• Steuerkategorie des Käufers
• Steuerkategorie des Produkts
• Land und Adresse des Kunden
• Zeitpunkt des abrechenbaren Ereignisses
• Zeitraum der Leistung

Bei wiederkehrenden Gebühren ist insbesondere relevant, welchem Servicezeitraum die Gebühr zugeordnet ist.

Steuern werden auf die jeweils rabattierten Beträge angewendet.

Rabatte

Rabatte können zu unterschiedlichen Zeitpunkten berücksichtigt werden.

Rating-time Discounts werden bereits während des Rating-Prozesses berücksichtigt. Sie wirken direkt auf die bewertete Position.

Billing-time Discounts werden erst im Billrun berechnet, weil bestimmte Informationen erst dann vollständig bekannt sind.

Beispiel:

Ein volumenabhängiger Rabatt kann erst berechnet werden, wenn alle relevanten Transaktionen einer Abrechnungsperiode bekannt sind.

11. Beispiele

Beispiel: B2B-Postpaid mit monatlichem Billrun

Ein Geschäftskunde bucht eine monatliche Subscription.

1. Das Konto ist auf B2B konfiguriert.
2. Preise werden netto verwaltet.
3. Das Produkt ist Postpaid.
4. Die Leistung wird im März erbracht.
5. tebio erzeugt abrechenbare Ereignisse für die Subscription.
6. Rating bewertet die Ereignisse.
7. Nach Ende der Bill Period startet der monatliche Billrun.
8. tebio erzeugt eine Rechnung oder eRechnung.
9. Die Rechnung wird finalisiert, gerendert und gespeichert.
10. Der Kunde wird benachrichtigt.
11. Die Zahlung erfolgt per Überweisung oder SEPA-Lastschrift.
12. Zahlung und Rechnung werden abgeglichen und im Journal gebucht.

Beispiel: B2C-Prepaid über Hosted Page

Ein Privatkunde bucht eine digitale Subscription über eine Hosted Page.

1. Das Konto ist auf B2C konfiguriert.
2. Preise werden brutto verwaltet.
3. Das Produkt ist Prepaid.
4. Der Kunde bezahlt direkt im Checkout.
5. tebio erstellt die Subscription nach erfolgreicher Zahlung.
6. Die abrechenbaren Positionen sind bereits bezahlt.
7. tebio erzeugt je nach Konfiguration eine Quittung oder einen Abrechnungsbeleg.
8. Es wird keine eRechnung erzeugt.
9. Der Kunde erhält eine Bestätigung und kann die Leistung nutzen.

Beispiel: Monatlicher Bill Cycle mit wöchentlicher Service Period

Ein Produkt hat:

• monatlichen Bill Cycle
• wöchentliche Service Period
• wiederkehrenden Wochenpreis

Ablauf:

1. Subscription ist während des Monats aktiv.
2. Jede wöchentliche Verlängerung erzeugt ein abrechenbares Ereignis.
3. Rating bewertet jede wöchentliche Periode.
4. Der monatliche Billrun sammelt alle relevanten wöchentlichen Positionen.
5. Die Monatsrechnung enthält vier oder fünf wiederkehrende Wochengebühren.

Typische Fehler vermeiden

B2B- und B2C-Logik verwechseln

Die Auswahl der primären Zielgruppe beeinflusst Preislogik, Steuerberechnung und eRechnung.

B2C nutzt Brutto-zu-Netto-Logik. B2B nutzt Netto-zu-Brutto-Logik.

Bill Cycle und Service Period gleichsetzen

Der Bill Cycle bestimmt, wann abgerechnet wird.

Die Service Period bestimmt, für welchen Zeitraum eine Gebühr gilt.

Diese beiden Zeitlogiken können gleich sein, müssen es aber nicht.

Prepaid und Postpaid als Zahlungsmethode verstehen

Prepaid und Postpaid sind keine Zahlungsmethoden.

Sie beschreiben die Zahlungs- und Abrechnungsstrategie eines Produkts.

Finalisierte Rechnungen manuell ändern wollen

Finalisierte Rechnungen sollten nicht direkt geändert werden.

Nutzen Sie Storno, Rechnungskorrektur oder Gutschrift, damit die Abrechnung nachvollziehbar bleibt.

Proration nicht berücksichtigen

Wenn Subscriptions mitten in einer Periode starten, pausieren, wechseln oder enden, können anteilige Beträge entstehen.

Prüfen Sie prorataStart und prorataEnd.

Billrun ohne Prüfung finalisieren

Wenn Sie Billruns prüfen möchten, aktivieren Sie die Pause vor der Finalisierung und nutzen Sie den Billrun-Report.

Rechnungslayout mit Rechnungslogik verwechseln

Das Template bestimmt die Darstellung des PDF-Dokuments.

Die fachliche Rechnungslogik bestimmt, welche Beträge und Positionen entstehen.

API-Hinweis

Für API-Nutzer sind insbesondere folgende Bereiche relevant:

Bereich	Bedeutung
Product	Standardlogik für Preise, Abrechnungszyklus, Serviceperiode und Proration
Subscription	konkrete gebuchte Leistung mit möglichen Abweichungen vom Produktstandard
Order	Ursprung vieler Subscription- und Zahlungsprozesse
Billing	Rating, Billrun und Rechnungserstellung
Invoice / Receipt	erzeugte Abrechnungsdokumente
Payment	Zahlung, Zahlungsstatus und Reconciliation
Document	gerenderte und gespeicherte Rechnungsdokumente
Journal	buchhalterische Nachvollziehbarkeit
Webhook	Benachrichtigung externer Systeme über Folgeprozesse

Die genaue technische Umsetzung der Endpunkte, Parameter und Statuswerte ist in der API-Referenz beschrieben.

Verwandte Themen

• Rechnungen, Quittungen und eRechnungen
• Prepaid und Postpaid im Vergleich
• Usage-based Billing
• Zahlungsstatus
• Fakturierung einrichten
• Rechnungseinstellungen verwalten
• Steuern konfigurieren
• Rechnung verstehen
• Journal einsehen
• Finanz-Reporte herunterladen
• Webhooks verstehen
• Glossar