finance-billing-ops

Use it when:: You want a sales or refund snapshot, a pricing comparison, or proof of whether team billing, seats or quota stacking work in code.
It does:: Starts from live billing data or a dated snapshot, separates customer incidents from product questions, and reads the checkout, pricing and entitlement code.
You get:: A snapshot, the customer impact, what the code does against what the website claims, a decision and the product gap to fix.
Unlike customer-billing-ops:: That one, from the same repo, fixes one customer's billing; this one is about revenue and what the product really does.
Pulls in:: Other ECC skills when relevant, such as customer-billing-ops, market-research, github-ops and verification-loop.

TL;DR

An evidence-first workflow for operators asking about money: sales, refunds, MRR, pricing, or whether the product does what the sales copy says. It keeps four things apart: revenue facts, customer impact, code-backed product truth and the recommendation. It prefers live billing data, such as Stripe, and states the snapshot time when the data isn't live, then lays out paid sales, active subscriptions, failed checkouts, refunds, disputes and duplicates. Customer-specific questions are classified first, as duplicate checkout, real team intent, broken self-serve controls, unmet value or failed payment, before the broader product question. When the answer depends on implementation, it inspects the checkout, pricing page, entitlement calculation, seat or quota handling and billing portal support in the code. It won't call billing per seat unless the entitlement path enforces it, won't count failed attempts as revenue, and won't compare competitor pricing from memory when current evidence exists. It was written as ECC's own billing workflow and names other ECC skills to pull in, such as research-ops.

Summarizes the skill at d2ef268.

npx skills add https://github.com/affaan-m/ecc --skill finance-billing-ops

skills.sh page Source on GitHub All skills from affaan-m/ecc

Weekly Downloads week to Nov 9, 2026

445

+72% in 8 weeks

More weekly downloads than 59% of skills

Weekly values

Week to	Installs
Sep 21	258
Sep 28	160
Oct 5	142
Oct 12	232
Oct 19	413
Oct 26	403
Nov 2	474
Nov 9	445

Total Downloads on skills.sh

5,400

Fewer downloads than 87% of skills

Repo stars affaan-m/ecc

299,776

More stars than 97% of repos

Age published May 19, 2026

5 months

Newer than 66% of skills

Category	category:science category:business Research reproduction, financial data, charts and diagrams. Run a company outside its code and marketing: strategy, sales, finance, operations, legal, management and hiring.
Type	type:workflow A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect	effect:none Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code.
Needs	needs:account An account, API key or paid plan with an outside service.
Publisher	by:community Everyone else. Unverified vendor claims default to community.
Topics	finance payments
Stack	stack:stripe

SKILL.md

From affaan-m/ecc at d2ef268. Checked daily, last changed Nov 6, 2026.

Frontmatter

name: finance-billing-ops
description: 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.
metadata:
  origin: ECC

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

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