> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fynn.eu/llms.txt
> Use this file to discover all available pages before exploring further.

# Vorausabrechnung vs. Nachgelagert

> Wann zahlt der Kunde im Voraus, wann erst danach? Entscheidungshilfe und saubere Modellierung von Mischformen.

Fynn unterstützt zwei Abrechnungszeitpunkte: **Vorausabrechnung** (`payInAdvance = true`) und **Nachgelagert** (`payInAdvance = false`). Welcher davon richtig ist, hängt davon ab, ob die abzurechnende Menge zum Periodenstart bereits feststeht.

Dieser Artikel richtet sich an Solution Architects und Power‑User, die Preismodelle abbilden. Wenn du nur ein einfaches Abo mit Festpreis konfigurierst, brauchst du nicht weiterzulesen — der Default ist Vorausabrechnung und das ist meistens richtig.

***

## Entscheidungsmatrix

| Konstellation                                                                   | Abrechnungszeitpunkt             | Begründung                                        |
| ------------------------------------------------------------------------------- | -------------------------------- | ------------------------------------------------- |
| Festpreis pro Periode (z.B. „99 €/Monat")                                       | **Vorausabrechnung**             | Menge und Preis stehen zum Periodenstart fest     |
| Mengenpreis mit fester Anzahl Einheiten (z.B. „10 Lizenzen × 8 €/Monat")        | **Vorausabrechnung**             | Menge ist im Vertrag/Abonnement gesetzt           |
| Nutzungsbasiert (BillableMetric, z.B. „pro API‑Call")                           | **Nachgelagert** (erzwungen)     | Menge ergibt sich erst aus den Events der Periode |
| Staffelpreis ohne Nutzungsmetrik (z.B. „bis 100 Lizenzen 8 €, ab 101 dann 6 €") | **Vorausabrechnung**             | Menge bleibt im Abonnement gesetzt                |
| Einmalige Setup‑Gebühr                                                          | **Vorausabrechnung** (`OneTime`) | Wird sofort fällig                                |

<Warning>
  Nutzungsbasierte Produkte werden technisch zwingend nachgelagert abgerechnet. Der `Vorausabrechnung`‑Schalter ist im PricePlan‑Editor automatisch gesperrt, sobald das verknüpfte Produkt eine Nutzungsmetrik trägt. Wenn du eine Hybridform brauchst, modellierst du das als zwei Positionen (siehe unten).
</Warning>

***

## Warum Nutzungsbasiert immer nachgelagert ist

Eine Nutzungsmetrik wie „Tokens", „API‑Calls" oder „Storage‑GB" aggregiert Ereignisse, die **während** einer Abrechnungsperiode entstehen. Vor Periodenende kennt das System die Summe nicht.

Wäre die Vorausabrechnung erlaubt, müsste der Wert geschätzt werden. Das führt zu zwei Problemen, die in der Praxis immer auftreten:

1. **Schätzfehler**: Der Schätzwert weicht von der tatsächlichen Nutzung ab. Die erste Rechnung müsste später korrigiert werden — entweder durch eine Gutschrift oder eine Nachberechnung. Bei vielen Abonnements bedeutet das eine Welle korrigierter Rechnungen mit allem Buchhaltungs‑Overhead.
2. **Falsche Signale an den Kunden**: Eine Rechnung, deren Betrag nicht den tatsächlichen Verbrauch widerspiegelt, untergräbt das Versprechen „du zahlst nur, was du verbrauchst".

Deshalb: Nutzung wird gemessen, dann abgerechnet, nie umgekehrt.

***

## Mischformen sauber modellieren

Drei gängige Anforderungen werden oft fälschlich als „BillableMetric mit Vorausabrechnung" formuliert. Alle drei lassen sich sauber mit **zwei Abonnementpositionen** abbilden:

### Mindestabnahme + Mehrverbrauch

**Anforderung:** „Mindestens 10.000 API‑Calls im Monat sind inklusive und werden monatlich im Voraus berechnet. Was darüber hinausgeht, kostet 0,01 € pro Call und wird am Monatsende abgerechnet."

**Modellierung:**

<Steps>
  <Step title="Position 1 – Grundgebühr (Vorausabrechnung)">
    * Produkt: „API‑Zugang Standard"
    * PricePlan: `flat_fee`, **Vorausabrechnung**, 100 €/Monat
    * Keine Nutzungsmetrik
  </Step>

  <Step title="Position 2 – Verbrauch (Nachgelagert)">
    * Produkt: „API‑Calls" mit Nutzungsmetrik (`COUNT` auf Event `api_call`)
    * PricePlan: `per_unit`, **Nachgelagert**, 0,01 €/Call
    * **Freikontingent: 10.000 Calls/Monat** im PricePlan
  </Step>
</Steps>

Effekt: Der Kunde bekommt am 1. eine Rechnung über 100 € (Grundgebühr). Am Monatsende wird Position 2 abgerechnet — wenn er unter 10.000 Calls geblieben ist, beträgt der Betrag 0 €. Liegt er bei 12.000 Calls, sind das 2.000 × 0,01 € = 20 €.

### Prepaid‑Credits / Volumenpaket

**Anforderung:** „Der Kunde kauft ein Paket mit 50.000 Tokens für 200 €. Die Tokens werden verbraucht, dann muss er ein neues Paket kaufen."

**Modellierung:**

<Steps>
  <Step title="Position 1 – Token‑Paket (Vorausabrechnung, einmalig)">
    * Produkt: „Token‑Paket 50k"
    * PricePlan: `OneTime`, **Vorausabrechnung**, 200 € fix
    * Wird beim Kauf abgerechnet
  </Step>

  <Step title="Position 2 – Nutzungs‑Tracking (Nachgelagert, mit Filter)">
    * Produkt: „Token‑Nutzung" mit Nutzungsmetrik (`SUM` auf `tokens_used`)
    * PricePlan: `per_unit`, **Nachgelagert**, 0 €/Token
    * **Freikontingent entspricht dem gekauften Paket‑Volumen**
    * Wenn das Paket aufgebraucht ist, wird über einen Filter oder ein Folge‑Produkt nachgeladen
  </Step>
</Steps>

Das Verbrauchs‑Tracking erzeugt also keine eigene Rechnung (Preis ist 0 €), dient aber der Transparenz im Kundenportal („du hast 32.000 von 50.000 Tokens verbraucht"). Ist das Paket aufgebraucht, sendet dein System das nächste „Paket‑gekauft"‑Event und der Zyklus startet neu.

### Geschätzte Abrechnung mit True‑Up

**Anforderung:** „Der Kunde zahlt monatlich 500 € im Voraus auf Basis einer Schätzung. Am Quartalsende wird die tatsächliche Nutzung gegengerechnet."

**Modellierung:** Diese Variante ist in der Praxis im DACH‑B2B‑SaaS selten und wird in Fynn nicht durch ein Spezial‑Feature unterstützt. Die saubere Abbildung ist:

<Steps>
  <Step title="Position 1 – Abschlagszahlung (Vorausabrechnung, monatlich)">
    * Produkt: „Service Abschlag"
    * PricePlan: `flat_fee`, **Vorausabrechnung**, 500 €/Monat
  </Step>

  <Step title="Position 2 – Tatsächliche Nutzung (Nachgelagert, quartalsweise)">
    * Produkt: „Service Nutzung" mit Nutzungsmetrik
    * PricePlan: `per_unit`, **Nachgelagert**, quartalsweise
  </Step>

  <Step title="Periodenend‑Korrektur über Rechnungskorrektur">
    Am Quartalsende erzeugst du eine Rechnungskorrektur, die die drei Abschlagsrechnungen (Position 1) mit der Nutzungsrechnung (Position 2) gegenrechnet. Saldo positiv → Nachberechnung, Saldo negativ → Gutschrift.
  </Step>
</Steps>

<Tip>
  Wenn du diese Variante häufig brauchst, sprich mit uns. Wir haben in der Roadmap einen „Estimated Billing"‑Workflow, der die True‑Up‑Korrektur am Periodenende automatisiert.
</Tip>

***

## Was im Hintergrund passiert

Wenn ein Abonnement aktiviert wird, gibt es zwei mögliche Verläufe:

**Vorausabrechnung (`payInAdvance = true`):**

1. Subscription‑Start am 1. Mai
2. Sofort wird eine Rechnung für `[1. Mai, 1. Juni)` erzeugt
3. Nächste Abrechnung: 1. Juni für `[1. Juni, 1. Juli)`, etc.

**Nachgelagert (`payInAdvance = false`):**

1. Subscription‑Start am 1. Mai
2. **Keine** Rechnung am 1. Mai
3. Während Mai werden Nutzungsereignisse erfasst
4. Am 1. Juni: Rechnung für `[1. Mai, 1. Juni)` mit der aggregierten Mai‑Nutzung
5. Nächste Abrechnung: 1. Juli für `[1. Juni, 1. Juli)`, etc.

Beide Modelle laufen über denselben Cron‑Lauf — der Unterschied liegt nur darin, wann der erste Rechnungslauf zündet.

***

## Häufige Fragen

<AccordionGroup>
  <Accordion title="Kann ich einen einzelnen Kunden auf Vorausabrechnung umstellen, auch wenn das Produkt nutzungsbasiert ist?">
    Nein. Die Regel gilt produktseitig, nicht kundenseitig. Wenn du für einen Kunden ein anderes Abrechnungsmodell brauchst, modellierst du das über eine separate Abonnementposition mit anderem Produkt.
  </Accordion>

  <Accordion title="Was passiert, wenn ein Kunde mitten in einer Periode kündigt?">
    Bei Vorausabrechnung gibt es typischerweise eine anteilige Gutschrift für den ungenutzten Rest. Bei nachgelagerter Abrechnung wird die bis zur Kündigung erfasste Nutzung wie üblich am nächsten Abrechnungstermin in Rechnung gestellt — ohne Sonderbehandlung.
  </Accordion>

  <Accordion title="Können in einem Abonnement beide Abrechnungszeitpunkte gleichzeitig vorkommen?">
    Ja. Jede Abonnementposition entscheidet selbst. Eine Position mit Grundgebühr kann im Voraus laufen, während eine zweite Position mit Nutzungsabrechnung nachgelagert läuft. Die Rechnungen erscheinen einfach zu verschiedenen Zeitpunkten.
  </Accordion>
</AccordionGroup>

***

## Verwandte Themen

<CardGroup cols={2}>
  <Card title="Nutzungsmetriken" icon="chart-line" href="/guide/catalogue/measurements/billable-metrics">
    Wie du Events erfasst und aggregierst.
  </Card>

  <Card title="Verständnis nutzungsbasierter Abrechnung" icon="calculator" href="/guide/catalogue/measurements/usage-based-billing">
    Wie die Aggregation in der Abrechnung sichtbar wird.
  </Card>
</CardGroup>