finance-billing-ops

Original：🇺🇸 English

Translated

Evidence-first revenue, pricing, refunds, team-billing, and billing-model truth workflow for ECC. Use when the user wants a sales snapshot, pricing comparison, duplicate-charge diagnosis, or code-backed billing reality instead of generic payments advice.

2installs

Sourceaffaan-m/everything-claude-code

Added on2026-04-06

NPX Install

npx skill4agent add affaan-m/everything-claude-code finance-billing-ops

SKILL.md Content

View Translation Comparison →

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