--- name: finance-billing-ops description: ECC's proof-first workflow for revenue, prices, refunds, team billing, and billing rules. Use it for sales snapshots, price checks, duplicate charge reviews, or billing answers that must match the code. origin: ECC --- # Finance Billing Ops Use this skill when a user needs to know how money, prices, refunds, team seats, or billing rules work in the real product. This skill is wider than `customer-billing-ops`. That skill helps one customer. This skill helps an operator find the full truth about sales, billing, and product rules. ## Related Skills Use these skills when they fit the task: - `customer-billing-ops` for help with one customer - `research-ops` for current market or rival price facts - `market-research` for a price plan or price advice - `github-ops` when code, issues, or release state matters - `verification-loop` when checkout, seats, limits, or access must be tested If a named skill is not present, do the same checks with the tools you have. ## Use This Skill When - The user asks about sales, refunds, MRR, or recent customer activity. - The user asks if team billing or seat fees work in the code. - The user asks if checkout quantity changes access or limits. - The user wants to compare prices with other products. - The question mixes money facts with product code. - The site says one thing, but the user wants to know what the product does. Do not use this skill for broad money advice that does not depend on product data or code. ## Safety Rules - Say if data is live or saved. - Give the date, time, and time zone for saved data. - Do not show full card data, bank data, secret keys, or private customer data. - Use customer IDs or masked email text when possible. - Do not issue a refund, cancel a plan, or change a price unless the user clearly asks for that action. - Keep facts and advice apart. - Do not call billing "per seat" unless the access code uses the seat count. - Do not assume two plans give twice the value. - Do not treat failed or pending payments as paid sales. - Do not call a trial, coupon, tax, fee, or credit part of base price. ## Workflow ### 1. Set the Scope Write down: - The date range - The currency - The time zone - The product or price - The customer or account, if this is one case - Whether the user wants facts, a fix, or both If the data uses more than one currency, report each currency on its own. Do not add them together without a clear rate and date. ### 2. Start With the Best Billing Proof Use the newest trusted billing data that is already available. Mark it as one of these: - Live data - Saved snapshot - Test data - Unknown source For a saved snapshot, give its date, time, and time zone. If key data is missing, say what is missing. Do not guess. Count these items on their own: - Paid sales - Active plans - Trials - Failed payments - Pending or incomplete checkouts - Refunds - Disputes - Duplicate plans - Coupons and credits - Tax and fees Use net sales only when the math is clear. State what was removed from gross sales. For MRR, state the rule used. Do not mix one-time sales, tax, or yearly cash with monthly plan value unless the rule says to do so. ### 3. Split the Customer Case From the Product Question For one customer, first name the case type: - Duplicate checkout - Real team need - Broken cancel or billing tool - Missing product value - Failed payment - Incomplete setup - Trial changed to paid - Plan change or prorated charge - Tax, fee, coupon, or credit issue - Charge exists, but access is missing - Access exists, but charge is missing Then ask the wider product questions: - Does team billing exist? - Are seats counted? - Does checkout quantity change access? - Does a plan change update limits? - Does canceling stop access at once or at term end? - Can late or repeated events cause two updates? - Does the site match the current product? Keep the customer result and the product result in separate parts of the report. ### 4. Check the Code Path When the answer depends on code, trace the full path: 1. The price page shows a plan or amount. 2. Checkout sends the price, quantity, and account data. 3. Payment state is saved. 4. Payment events update the account. 5. Access rules read the saved state. 6. Seat, quota, install, and user rules apply limits. 7. Cancel, refund, and plan-change paths update access. 8. The billing page lets the user view or change the plan. Check these edge cases: - Quantity is empty, zero, negative, or very large. - Two checkout requests run at the same time. - The same payment event is sent more than once. - Events arrive late or in the wrong order. - A trial ends after a plan change. - A coupon ends. - A plan is changed during a billing term. - A refund is full or partial. - A dispute happens after access was given. - A payment is made, but the access update fails. - The price page and checkout use different price IDs. - Old plans still exist. - Test and live billing data are mixed. - Account email and billing email do not match. A code path is not proof that it works in the live product. Also check that the code is in the active release when release data is available. ### 5. Compare Claims With Facts List each claim from the site or sales text. Match it to billing data and code. Use one of these labels: - Confirmed - Partly confirmed - Not found - False - Unknown Do not fill gaps with memory or sales text. For rival prices, use current dated proof when it is already available. Note taxes, billing term, seat minimums, limits, and special offers. If current proof is not available, say that the comparison may be old. ### 6. Make a Decision Choose a clear next step: - Refund - Partial refund - Keep the plan - Cancel at term end - Cancel now - Merge or remove a duplicate plan - Move to a team plan - Fix access - Fix billing code - Fix site text - No action - More proof needed State who should act and what proof supports the choice. Keep any product fix as a separate task. ## Output Format ```text SNAPSHOT - Source: - Data state: live / saved / test / unknown - Time: - Date range: - Currency: - Paid sales: - Active plans: - Trials: - Failed or pending payments: - Refunds and disputes: - Other odd items: CUSTOMER IMPACT - Account: - Case type: - What happened: - Money impact: - Access impact: PRODUCT TRUTH - What the billing data shows: - What the code does: - What the site says: - Match: confirmed / partly confirmed / not found / false / unknown DECISION - Action: - Reason: - Owner: - Safe next step: PRODUCT GAP - Gap: - Fix: - Test: - Priority: LIMITS - Missing proof: - Open questions: ``` Skip `CUSTOMER IMPACT` when no customer case exists. Skip `PRODUCT GAP` when no gap is found. ## Example User request: ```text A customer was charged twice for five seats. Do we support seat billing, and should we refund one charge? ``` Good result: ```text SNAPSHOT - Source: Saved billing snapshot - Data state: saved - Time: 2026-05-12 10:00 UTC - Date range: 2026-05-01 to 2026-05-12 - Currency: USD - Paid sales: Two paid plans for the same account - Active plans: Two - Refunds and disputes: None CUSTOMER IMPACT - Account: cus_123 - Case type: Duplicate checkout - What happened: Two paid plans began three minutes apart. - Money impact: The customer paid twice. - Access impact: The account still has one shared quota. It did not gain ten seats. PRODUCT TRUTH - What the billing data shows: Each plan has quantity 5. - What the code does: Checkout saves quantity, but the access rule does not read it. - What the site says: The team plan is sold as a per-seat plan. - Match: false DECISION - Action: Refund and cancel the newer duplicate plan. - Reason: The second plan gave no extra access. - Owner: Billing support - Safe next step: Confirm the plan IDs and paid amounts before any refund. PRODUCT GAP - Gap: Seat quantity does not change access. - Fix: Make access rules read the paid seat count, or remove the per-seat claim. - Test: Buy two seats in test mode and confirm that two users can join. - Priority: High LIMITS - Missing proof: No live release record was checked. - Open questions: Is the seat code in a newer release? ``` ## Common Mistakes - Counting failed charges as sales - Counting tax or fees as product sales - Mixing gross sales with net sales - Adding two currencies as if they were the same - Calling a yearly payment MRR without a clear rule - Trusting sales text without checking code - Trusting code without checking the active release - Treating checkout quantity as seat access without proof - Assuming a duplicate plan gave duplicate value - Giving a refund before naming the case type - Hiding missing proof - Mixing one customer's problem with a full price plan choice ## Final Check Before you finish, make sure: - The report says whether data is live, saved, test, or unknown. - Saved data has a date, time, and time zone. - Currency and date range are clear. - Paid, failed, pending, refunded, and disputed amounts are kept apart. - MRR and net sales rules are stated when used. - Product claims are backed by code or marked unknown. - The active release is checked when that proof is available. - Customer impact is separate from product truth. - Facts are separate from advice. - Any money or plan change needs clear user approval.