finance-billing-ops
affaan-m/ECC
Bietet evidenzbasierte Workflows für Umsatz, Preisgestaltung, Rückerstattungen, Teamabrechnung und die Überprüfung der Abrechnungsmodelle – für Vertriebsübersichten, Preisvergleiche, die Diagnose von Doppelabrechnungen oder die Überprüfung der Abrechnungsrealität anhand von Codes.
...Alle erweiternFinanzen und Abrechnung
Verwenden Sie dies, wenn der Nutzer Geld, Preisgestaltung, Rückerstattungen, die Logik hinter Team-Lizenzen verstehen möchte oder wissen möchte, ob sich das Produkt tatsächlich so verhält, wie es die Website und die Werbetexte vermuten lassen.
Dieser Bereich ist umfassender als die Kundenabrechnung. Bei letzterer geht es um die Behebung von Kundenproblemen. Hier geht es um die operativen Fakten: Umsatzstatus, Preisentscheidungen, Teamabrechnung und das durch den Code festgelegte Abrechnungsverhalten.
Kompetenz-Stack
Beziehen Sie diese ECC-eigenen Kompetenzen bei Bedarf in den Arbeitsablauf ein:
„Kundenabrechnung“für kundenspezifische Problemlösung und Nachverfolgung„research-ops“, wenn die Preisgestaltung der Wettbewerber oder aktuelle Marktdaten eine Rolle spielen„market-research“, wenn die Antwort in einer Preisempfehlung münden sollgithub-ops, wenn die Abrechnungsdaten von Code, Backlog oder dem Release-Status in verwandten Repos abhängenverification-loop, wenn die Antwort vom Nachweis des Checkouts, der Lizenzverwaltung oder des Berechtigungsverhaltens abhängt
Anwendungsfälle
- Der Nutzer fragt nach Stripe-Umsätzen, Rückerstattungen, MRR oder den jüngsten Kundenaktivitäten
- Der Nutzer fragt, ob Teamabrechnung, Abrechnung pro Lizenz oder Quoten-Stacking im Code tatsächlich umgesetzt sind
- Der Benutzer wünscht Preisvergleiche mit Wettbewerbern oder Benchmarks für Preismodelle
- Die Frage vermischt Umsatzdaten mit Fakten zur Produktumsetzung
Leitplanken
- Unterscheiden Sie Live-Daten von gespeicherten Momentaufnahmen
- Trennen Sie:
- Umsatzdaten
- Auswirkungen auf den Kunden
- durch Code gestützte Produktwahrheit
- Empfehlung
- Sagen Sie nicht „pro Arbeitsplatz“, es sei denn, der tatsächliche Berechtigungspfad schreibt dies vor
- Gehen Sie nicht davon aus, dass doppelte Abonnements einen doppelten Wert bedeuten
Ablauf
1. Gehen Sie von den aktuellsten Abrechnungsdaten aus
Bevorzuge aktuelle Abrechnungsdaten. Wenn die Daten nicht aktuell sind, gib den Zeitstempel der Momentaufnahme ausdrücklich an.
Normalisieren Sie die Daten:
- bezahlte Umsätze
- aktive Abonnements
- fehlgeschlagene oder unvollständige Kaufvorgänge
- Rückerstattungen
- Streitfälle
- doppelte Abonnements
2. Trennen Sie Kundenvorfälle von den Produktdaten
Wenn die Frage kundenspezifisch ist, klassifizieren Sie zunächst:
- doppelte Kaufabwicklung
- tatsächliche Absicht des Teams
- defekte Selbstbedienungsfunktionen
- nicht erfüllter Produktnutzen
- fehlgeschlagene Zahlung oder unvollständige Einrichtung
Trennen Sie dies nun von der allgemeineren Produktfrage:
- Gibt es die Teamabrechnung wirklich?
- Werden Lizenzen tatsächlich gezählt?
- Ändert die Bestellmenge die Berechtigung?
- Wird das aktuelle Verhalten auf der Website übertrieben dargestellt?
3. Überprüfen Sie das durch den Code gestützte Abrechnungsverhalten
Wenn die Antwort von der tatsächlichen Implementierung abhängt, überprüfen Sie den Codepfad:
- Kasse
- Preisseite
- Berechtigungsberechnung
- Verwaltung von Lizenzen oder Kontingenten
- Logik für Installation vs. Nutzernutzung
- Abrechnungsportal oder Selbstverwaltungs-Support
4. Schließen Sie mit einer Entscheidung und einer Produktlücke ab
Bericht:
- Umsatzübersicht
- Problemdiagnose
- Produkt-Echtbild
- Empfohlene Maßnahmen für den Betreiber
- Produkt- oder Backlog-Lücke
Ausgabeformat
ÜBERBLICK
– Zeitstempel
– Umsatz / Abonnements / Anomalien
AUSWIRKUNGEN AUF KUNDEN
– Wer ist betroffen?
– Was ist passiert?
PRODUKT-FAKTEN
– Was macht der Code tatsächlich?
– Was wird auf der Website oder in den Verkaufstexten behauptet?
ENTSCHEIDUNG
– Rückerstattung / Beibehaltung / Umwandlung / keine Maßnahme
PRODUKTLÜCKE
– Genauer Folgeschritt, der umgesetzt oder behoben werden muss
Fallstricke
- Verwechseln Sie fehlgeschlagene Versuche nicht mit dem Nettoumsatz
- Leiten Sie keine Rückschlüsse auf die Abrechnung des Teams allein aus der Marketing-Sprache ab
- Vergleichen Sie die Preise der Wettbewerber nicht aus dem Gedächtnis, wenn aktuelle Belege vorliegen
- Springen Sie nicht direkt von der Diagnose zur Rückerstattung, ohne das Problem zuvor einzustufen
Überprüfung
- Die Antwort enthält eine Angabe zu Echtzeitdaten oder einen Zeitstempel für einen Momentaufnahme-Snapshot
- Angaben zur Produktwahrheit sind durch Code belegt
- Auswirkungen auf den Kunden und allgemeinere Schlussfolgerungen zu Preisgestaltung und Produkt werden klar voneinander getrennt
---
name: finance-billing-ops
description: Provides evidence-first revenue, pricing, refunds, team-billing, and billing-model truth workflows for sales snapshots, pricing comparisons, duplicate-charge diagnosis, or code-backed billing reality.
---
# Finance Billing Ops
Use this when the user wants to understand money, pricing, refunds, team-seat logic, or whether the product actually behaves the way the website and sales copy imply.
This is broader than `customer-billing-ops`. That skill is for customer remediation. This skill is for operator truth: revenue state, pricing decisions, team billing, and code-backed billing behavior.
## Skill Stack
Pull these ECC-native skills into the workflow when relevant:
- `customer-billing-ops` for customer-specific remediation and follow-up
- `research-ops` when competitor pricing or current market evidence matters
- `market-research` when the answer should end in a pricing recommendation
- `github-ops` when the billing truth depends on code, backlog, or release state in sibling repos
- `verification-loop` when the answer depends on proving checkout, seat handling, or entitlement behavior
## When to Use
- user asks for Stripe sales, refunds, MRR, or recent customer activity
- user asks whether team billing, per-seat billing, or quota stacking is real in code
- user wants competitor pricing comparisons or pricing-model benchmarks
- the question mixes revenue facts with product implementation truth
## Guardrails
- distinguish live data from saved snapshots
- separate:
- revenue fact
- customer impact
- code-backed product truth
- recommendation
- do not say "per seat" unless the actual entitlement path enforces it
- do not assume duplicate subscriptions imply duplicate value
## Workflow
### 1. Start from the freshest billing evidence
Prefer live billing data. If the data is not live, state the snapshot timestamp explicitly.
Normalize the picture:
- paid sales
- active subscriptions
- failed or incomplete checkouts
- refunds
- disputes
- duplicate subscriptions
### 2. Separate customer incidents from product truth
If the question is customer-specific, classify first:
- duplicate checkout
- real team intent
- broken self-serve controls
- unmet product value
- failed payment or incomplete setup
Then separate that from the broader product question:
- does team billing really exist?
- are seats actually counted?
- does checkout quantity change entitlement?
- does the site overstate current behavior?
### 3. Inspect code-backed billing behavior
If the answer depends on implementation truth, inspect the code path:
- checkout
- pricing page
- entitlement calculation
- seat or quota handling
- installation vs user usage logic
- billing portal or self-serve management support
### 4. End with a decision and product gap
Report:
- sales snapshot
- issue diagnosis
- product truth
- recommended operator action
- product or backlog gap
## Output Format
```text
SNAPSHOT
- timestamp
- revenue / subscriptions / anomalies
CUSTOMER IMPACT
- who is affected
- what happened
PRODUCT TRUTH
- what the code actually does
- what the website or sales copy claims
DECISION
- refund / preserve / convert / no-op
PRODUCT GAP
- exact follow-up item to build or fix
```
## Pitfalls
- do not conflate failed attempts with net revenue
- do not infer team billing from marketing language alone
- do not compare competitor pricing from memory when current evidence is available
- do not jump from diagnosis straight to refund without classifying the issue
## Verification
- the answer includes a live-data statement or snapshot timestamp
- product-truth claims are code-backed
- customer-impact and broader pricing/product conclusions are separated cleanly
Alle Dateien
1 Dateienfinance-billing-ops installieren
Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihr Verzeichnis „.claude/skills/“.
ZIP herunterladenKlonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.
git clone https://github.com/affaan-m/ECC/tree/main/skills/finance-billing-ops # Copy SKILL.md to your .claude/skills/ directory
Kopieren





Heim
