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.

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 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

finance-billing-ops