Finance playbook · AI Employee: Fin

Customer Invoice & Subscription Change

Subscription changes applied same day

Install this playbookBack to marketplace
The problem

A customer asks for an add-on, an upgrade, a proration, a mid-term reduction, or just a new billing email — every one turns into a three-day back-and-forth between the CSM, the billing team, and the customer's AP. Invoices go out with the wrong quantities, subscriptions get out of sync between the CRM, billing platform, and the accounting system, and revenue recognition breaks in ways nobody notices until the audit. Every customer touch is an entropy event.

At a glance
Trigger
Form
Approvals
Owner approval on non-standard changes
What it does
Writes to your systems
Systems
Chargebee · Zuora · NetSuite
How it feels in production

An hour-by-hour walkthrough.

CSM Kiran messages Fin: "Acme Corp wants to add 25 more seats effective the 15th, and update their billing contact to [email protected]." Fin resolves the account, looks up the current subscription (Growth plan, 150 seats, annual, renews March), and drafts the change: - Add 25 seats effective 2026-09-15 - Proration: 6 months remaining × $60/seat × 25 seats = $9,000 prorated invoice, due 2026-10-15 - Renewal auto-adjusted to 175 seats at renewal date - Billing contact update: [email protected] (verified against Acme's known corporate domain) Kiran reviews. Approves. Fin executes: - Updates the subscription in Stripe / Chargebee / Recurly with effective-dated line-item - Generates the prorated invoice with the correct line items - Updates the CRM opportunity with the expansion event (contributes to NRR / expansion metrics) - Updates the accounting system so revenue recognition schedules correctly - Sends the customer a confirmation email with the invoice attached and the change summary - Updates the billing contact on file (with a 24-hour delay so the old contact sees the change email first) Every system stays in sync. Every downstream metric — MRR, NRR, ARR, revenue recognition — moves as one atomic change rather than three days of drift.
How it works

Step by step.

  1. 01

    Parse the change request + resolve account

    Understand the request (add / remove seats, upgrade tier, change billing contact, apply credit). Resolve account across CRM + billing platform + accounting system. Ambiguity triggers clarification.

    Reasoning · CRM · Billing platform lookup
  2. 02

    Draft the change with proration + downstream impact

    Compute proration per your billing rules (per-day, per-month, on-anniversary). Show impact: prorated invoice amount, renewal-date subscription state, CRM opportunity update, revenue-rec effect.

    Billing platform · Proration engine · Revenue-rec model
  3. 03

    CSM / customer review + approval

    Draft surfaces the change with numbers. CSM approves; customer-facing quote sent if needed (some changes require customer confirmation). Approval + customer confirmation both required for revenue-affecting changes.

    Slack · Teams · Customer portal · DocuSign
  4. 04

    Execute across every system atomically

    Update billing platform (subscription line-items), generate invoice, update CRM (subscription contract), update accounting (revenue schedule), notify customer, update billing contact. Failure at any step rolls back or flags for manual reconciliation.

    Stripe · Chargebee · Recurly · CRM · NetSuite · Email
  5. 05

    Confirm + log for audit

    Customer confirmation email with invoice + change summary. Change event logged to CRM + audit trail. Weekly finance digest surfaces change volume, common change types, revenue impact.

    Email · CRM · Audit log · Analytics
Systems and wiring

What you connect to make this run.

Stripe · Chargebee · Recurly · Zuora

read+write

Subscription source of truth. Read current state; write line-item changes with effective dates + proration. Every change carries CSM identity + audit reason for compliance.

Salesforce · HubSpot

read+write

Subscription contract on the account. Expansion / contraction events feed NRR + expansion metrics. Contract line-items stay in sync with billing platform via bidirectional sync.

NetSuite · Sage · QuickBooks

read+write

Accounting system for revenue recognition. Subscription changes flow to rev-rec schedules; ASC 606 compliance depends on this staying in sync with billing.

Email · Customer portal · DocuSign

read+write

Customer confirmation for revenue-affecting changes. Quote / order-form signature where the customer's contract requires it. Change history visible in customer portal.

What changes

Before and after, honestly.

Time from customer request to change effective
Before
1-5 business days
After
Under 1 hour (routine) to next business day (novel)
Systems out of sync 24 hours post-change
Before
25-45%
After
Under 2%
Invoice error rate on changes
Before
10-20%
After
Under 1%
Billing team hours per change
Before
45-90 minutes
After
5-15 minutes (review only)
Related

Playbooks that pair with this one.

RevOps

Closed-Won Cascade

Initial-order cascade is a special case of this playbook; same mechanism.

Finance

AR Aging & Collections

Clean subscriptions produce clean invoices; fewer disputes reach collections.

RevOps

Expansion Signal Detection

Expansion changes here contribute to NRR + feed the expansion-signal model.

Frequently asked

Answers about this playbook.

What if the customer wants to backdate a change?

Backdating supported for the current period only; earlier backdating requires finance approval (rev-rec restatement). Fin drafts the approval request with the impact; finance decides.

How does it handle mid-term downgrades?

Depends on your contract terms. If mid-term reduction is contractually allowed, Fin executes with proration (credit or reduced-billing). If not (annual contract, no reduction), Fin drafts a customer-facing response explaining and offers alternatives.

What about complex changes (product mix change + term extension + discount)?

Multi-change requests route through the deal-desk flow. Fin surfaces the combined impact + routes approval per the approval matrix. Executes atomically once approved.

How does it work with usage-based billing?

Usage-based components pass through Fin's change logic unchanged — the subscription defines the meter + rate, and usage flows separately. Rate changes and meter additions follow the same effective-date + approval logic.

Can customers self-serve changes?

Yes — customer portal offers self-serve for pre-approved change types (add seats up to a limit, change billing contact). Beyond that, requests still route through the CSM + Fin approval flow.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Finance playbooks