> ## 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. # Nutzungsbasierte Abrechnung verstehen > Erfahre, wie die nutzungsbasierte Abrechnung funktioniert und wie du die Nutzungsdaten interpretierst Nutzungsbasierte Abrechnung Die nutzungsbasierte Abrechnung ermöglicht es dir, Kunden basierend auf ihrer tatsächlichen Nutzung abzurechnen. Anstatt eines festen monatlichen Preises werden Kunden nur für das berechnet, was sie tatsächlich verwenden. ## Wie funktioniert die nutzungsbasierte Abrechnung? ### Grundprinzip 1. **Nutzungsereignisse werden erfasst**: Deine Anwendung sendet Nutzungsereignisse (z.B. API-Aufrufe, gesendete E-Mails, Speicherplatz) an Fynn 2. **Ereignisse werden aggregiert**: Fynn sammelt alle Ereignisse und berechnet die Gesamtnutzung basierend auf dem Aggregationstyp 3. **Abrechnung erfolgt nachträglich**: Am Ende des Abrechnungszeitraums wird die tatsächliche Nutzung abgerechnet ### Abrechnungsmodus: Nachträglich (Arrears) Im Gegensatz zu festen Abonnements, die im Voraus (Advance) abgerechnet werden, erfolgt die nutzungsbasierte Abrechnung **nachträglich (Arrears)**: * **Feste Abonnements**: Du zahlst am 1. Januar für den gesamten Januar im Voraus * **Nutzungsbasierte Abrechnung**: Du zahlst am 1. Februar für die Nutzung im Januar ## Was zeigen die Metriken? Die angezeigten Metriken zeigen die **aggregierten Nutzungswerte für noch nicht abgerechnete Ereignisse**. Das bedeutet: * ✅ **Enthalten**: Alle Nutzungsereignisse, die noch nicht auf einer Rechnung stehen * ❌ **Nicht enthalten**: Bereits abgerechnete Ereignisse (die bereits auf einer Rechnung erscheinen) ### Beispiel Angenommen, du hast ein Produkt "API-Aufrufe" mit nutzungsbasierter Abrechnung: ``` 01.01.2026: 100 API-Aufrufe → noch nicht abgerechnet 15.01.2026: 200 API-Aufrufe → noch nicht abgerechnet 01.02.2026: Rechnung wird erstellt für Januar → 300 API-Aufrufe werden abgerechnet 02.02.2026: 50 API-Aufrufe → noch nicht abgerechnet ``` **Angezeigte Metrik am 02.02.2026:** * **Menge**: 50 API-Aufrufe (nur die noch nicht abgerechneten) * **Zeitraum**: 01.02.2026 bis 02.02.2026 ## Den Zeitraum verstehen Jede Metrik zeigt einen **Zeitraum** an, z.B. "01.01.2026 bis 01.02.2026". Dieser Zeitraum hat eine klare Bedeutung: ### Startdatum Das **Startdatum** ist das Datum, ab dem noch nicht abgerechnete Ereignisse erfasst werden: * **Wenn bereits abgerechnet wurde**: Das Datum der letzten Abrechnung (z.B. 01.01.2026) * **Wenn noch nie abgerechnet wurde**: Das Startdatum des Abonnements **Wichtig**: Wenn eine Schwellenwert-Abrechnung (Threshold Billing) stattfindet, ändert sich das Startdatum entsprechend, da dann ein neuer Abrechnungszeitraum beginnt. ### Enddatum Das **Enddatum** ist immer das aktuelle Datum und die aktuelle Uhrzeit. Es zeigt, bis wann die Nutzung erfasst wurde. ### Beispiel: Zeitraum-Interpretation ``` Zeitraum: 01.01.2026 bis 01.02.2026 ``` **Bedeutung:** * **01.01.2026**: Letztes Abrechnungsdatum (oder Start des Abonnements) * **01.02.2026**: Heutiges Datum **Was wird angezeigt:** * Alle Nutzungsereignisse vom 01.01.2026 00:00:00 bis zum 01.02.2026 (aktueller Zeitpunkt) * Die aggregierte Gesamtnutzung in diesem Zeitraum * **Nur** noch nicht abgerechnete Ereignisse ## Wann wird abgerechnet? ### Reguläre Abrechnung (Period Billing) Die nutzungsbasierte Abrechnung erfolgt **am Ende des Abrechnungszeitraums**: * **Monatliche Abrechnung**: Am 1. des Monats wird die Nutzung des Vormonats abgerechnet * **Quartalsweise Abrechnung**: Am 1. des Quartals wird die Nutzung des Vorquartals abgerechnet **Beispiel:** ``` Abrechnungsintervall: Monatlich Abrechnungsdatum: 01.02.2026 Abrechnungszeitraum: 01.01.2026 - 31.01.2026 ``` ### Schwellenwert-Abrechnung (Threshold Billing) Zusätzlich zur regulären Abrechnung kannst du **Schwellenwerte** definieren, die eine Abrechnung auslösen, wenn ein bestimmter Nutzungswert oder Betrag erreicht wird: * **Beispiel**: Wenn 1000 API-Aufrufe erreicht werden, wird sofort eine Rechnung erstellt * **Vorteil**: Du erhältst früher Zahlungen und reduzierst das Ausfallrisiko **Wichtig**: Nach einer Schwellenwert-Abrechnung beginnt ein neuer Abrechnungszeitraum. Das Startdatum der Metriken wird entsprechend aktualisiert. ## Wie werden die Werte aggregiert? Die Art der Aggregation hängt vom **Aggregationstyp** deiner Messung ab: | Aggregationstyp | Beschreibung | Beispiel | | --------------------- | ------------------------- | -------------------------------- | | **Summe** | Alle Werte werden addiert | 100 + 200 + 50 = 350 API-Aufrufe | | **Anzahl** | Anzahl der Ereignisse | 3 Ereignisse | | **Durchschnitt** | Durchschnittswert | (100 + 200 + 50) / 3 = 116,67 | | **Maximum** | Höchster Wert | max(100, 200, 50) = 200 | | **Zuletzt** | Letzter gemeldeter Wert | 50 (letzter Wert) | | **Eindeutige Anzahl** | Anzahl eindeutiger Werte | 3 eindeutige Kunden | ## Praktisches Beispiel ### Szenario: E-Mail-Versand-Service Du bietest einen E-Mail-Versand-Service an, der pro gesendeter E-Mail abgerechnet wird. **Setup:** * Produkt: "E-Mail-Versand" * Messung: "Gesendete E-Mails" (Aggregation: Summe) * Preis: 0,01 € pro E-Mail **Ablauf:** 1. **01.01.2026**: Abonnement startet * Angezeigte Nutzung: 0 E-Mails * Zeitraum: 01.01.2026 bis 01.01.2026 2. **15.01.2026**: Kunde sendet 1.000 E-Mails * Angezeigte Nutzung: 1.000 E-Mails * Zeitraum: 01.01.2026 bis 15.01.2026 * **Noch nicht abgerechnet** 3. **25.01.2026**: Kunde sendet weitere 500 E-Mails * Angezeigte Nutzung: 1.500 E-Mails * Zeitraum: 01.01.2026 bis 25.01.2026 * **Noch nicht abgerechnet** 4. **01.02.2026**: Reguläre Abrechnung * Rechnung wird erstellt für 1.500 E-Mails × 0,01 € = 15,00 € * Zeitraum der Rechnung: 01.01.2026 - 31.01.2026 5. **02.02.2026**: Kunde sendet 200 weitere E-Mails * Angezeigte Nutzung: 200 E-Mails * Zeitraum: 01.02.2026 bis 02.02.2026 * **Neuer Abrechnungszeitraum beginnt** ## Häufige Fragen ### Warum zeigt die Metrik einen anderen Wert als erwartet? **Mögliche Gründe:** 1. **Ereignisse wurden bereits abgerechnet**: Die Metrik zeigt nur noch nicht abgerechnete Ereignisse 2. **Falscher Zeitraum**: Prüfe, ob der Zeitraum korrekt ist (Startdatum = letztes Abrechnungsdatum) 3. **Ereignisse wurden noch nicht erfasst**: Prüfe, ob die Nutzungsereignisse korrekt an Fynn gesendet wurden ### Warum ändert sich das Startdatum? Das Startdatum ändert sich, wenn: * Eine reguläre Abrechnung stattgefunden hat * Eine Schwellenwert-Abrechnung ausgelöst wurde * Das Abonnement neu gestartet wurde ### Was passiert, wenn Ereignisse verspätet eintreffen? Fynn berücksichtigt auch verspätet eintreffende Ereignisse korrekt: * Ereignisse werden basierend auf ihrem **Zeitstempel** (timestamp) dem richtigen Abrechnungszeitraum zugeordnet * Auch wenn ein Ereignis erst später erfasst wird, wird es dem korrekten Zeitraum zugeordnet ### Wie kann ich die Details einer Metrik einsehen? Du kannst die Details einer Metrik einsehen, um: * Alle einzelnen Nutzungsereignisse zu sehen * Den Zeitraum im Detail zu verstehen * Die Aggregation nachzuvollziehen Nutze hierfür die Detailansicht der Metrik in der Abonnementübersicht. ## Zusammenfassung * ✅ **Metriken zeigen**: Aggregierte Nutzungswerte für noch nicht abgerechnete Ereignisse * ✅ **Startdatum**: Letztes Abrechnungsdatum (oder Abonnementstart) * ✅ **Enddatum**: Aktuelles Datum und Uhrzeit * ✅ **Abrechnung**: Nachträglich am Ende des Abrechnungszeitraums * ✅ **Schwellenwerte**: Können eine frühere Abrechnung auslösen Die nutzungsbasierte Abrechnung gibt dir vollständige Transparenz über die Nutzung deiner Kunden und ermöglicht eine faire, verbrauchsabhängige Abrechnung.