A customer’s finance team emails to say the March usage invoice is 40% higher than February’s and nobody on their side added users. Your collector forwards it to billing. Billing forwards it to product. Two weeks later the invoice is still open, the customer has stopped paying the undisputed subscription line too, and nobody can say how the billed quantity was produced.
That dispute started before the invoice was sent. The fix is a short, charge-specific review that lets billing explain every quantity, date, and rate on the draft.
Know which kind of charge you are checking
A single SaaS invoice can carry several charge types, and each one goes wrong in a different place. Check them separately.
| Charge type | Where it usually goes wrong | Record that settles it |
|---|---|---|
| Recurring subscription | Wrong plan, price, or billing entity after an amendment | Signed order form and latest amendment |
| Usage or metered charge | Late, duplicate, or misattributed events; wrong aggregation | Event totals by customer and period, meter definition |
| Mid-cycle change (proration) | Effective date taken from provisioning instead of the contract | Amendment with its billing start date |
| Renewal true-up | Seats billed twice, once mid-term and again at year-end | Prior invoices and the seat record for the expiring term |
| Implementation milestone | Billed on task completion when the contract requires acceptance | Statement of work and acceptance evidence |
Billing should be able to point to the contract term and source record behind every line. If a line cannot be traced, hold that line.
Usage invoices: trace events to billed units
When a customer challenges a usage charge, billing has to show how it got from the events your product recorded to the quantity on the invoice. Work one customer and one billing period at a time, with the event totals, the pricing terms, and the draft invoice side by side.
| Check | What to compare |
|---|---|
| Customer mapping | The account ID on the events and the customer on the invoice |
| Billing window | Event timestamps, the period cutoff, and the service dates printed on the invoice |
| Duplicate or late events | Event identifiers and ingestion status for retried or delayed records |
| Billed quantity | The meter’s aggregation rule and the quantity in the draft |
| Billed rate | Signed terms, including included units, tiers, and credits |
Check the aggregation rule before adding up rows. A count of API requests and a sum of compute units answer different questions. If the meter definition and the contract wording disagree, the contract wins.
Ingestion timing is a frequent source of noise. If you use Stripe Billing Meters, Stripe documents that events are processed asynchronously and that the meter summary or upcoming invoice may lag recently received usage (Stripe’s guide to recording usage). Confirm processing has finished before you decide an event is missing and resend it, or you create the duplicate you were trying to avoid.
Illustrative example: a tiered usage line
Assume the contract includes 50,000 API calls a month, bills the next 50,000 at $0.002 each, and everything above 100,000 at $0.001. The event log shows 132,400 calls for March. Before checking the price, billing finds 2,400 events with duplicate IDs from a retried ingestion job.
- Valid calls: 132,400 − 2,400 = 130,000
- Tier 1 (included): 50,000 at $0 = $0
- Tier 2: 50,000 × $0.002 = $100
- Tier 3: 30,000 × $0.001 = $30
- Usage charge: $130
Billed on the raw count, tier 3 would have been 32,400 × $0.001 = $32.40, an overcharge of $2.40. Small, but a customer who finds it questions every later usage line.
Test late and duplicate events before you trust the meter
In a billing preview, send one late event and one duplicate. Ask billing to show which period receives the late event and how it can tell whether the duplicate was counted. Keep the original event and the correction together. If the invoice is already finalized, use your approved correction process (credit note and reissue, or an adjustment on the next invoice) and tell the customer which period and charge changed.
Mid-cycle changes: bill from the contract date
Sales signs a seat expansion on Monday. The customer gets access on Wednesday. The amendment says billing starts Friday. If the billing system takes its date from provisioning, the draft charges for two days the customer never agreed to pay for. Store the billing date from the amendment and keep the other dates visible for review.
Proration charges or credits part of a billing period when the subscription changes. Decide what the contract allows first, then configure the billing system to match. Stripe documents that its proration settings determine whether an adjustment is created and whether it is invoiced immediately or added to the next invoice (Stripe’s subscription proration guide).
Illustrative example: six seats added mid-month
A customer adds six seats at $30 per seat per month. The amendment keeps the current renewal date, and the agreement uses a 30-day basis with ten billable days left.
- Proration: 6 × $30 × 10 ÷ 30 = $60 before tax
- Added to each full month going forward: 6 × $30 = $180
Show both amounts in the preview. Then check the date convention, time zone, discount, and rounding; systems that calculate from timestamps can produce a preview that differs from the real change.
Changes that produce the wrong credit
| Change | What billing should check |
|---|---|
| Seats removed now, but the contract changes at renewal | Keep current terms until the agreed effective date |
| Add-on ends on the same date as the main subscription | The add-on’s shortened term and whether the existing discount applies |
| Plan changes while the original invoice is unpaid | The original invoice before granting a credit for unused time |
| Someone already sent a manual invoice for the amendment | Tie it to the change record before creating another adjustment |
The unpaid-invoice case deserves a specific test. Stripe documents that it calculates prorations assuming prior invoices will eventually be paid, which can leave a credit for unused time on a plan the customer has not paid for (Stripe on prorations and unpaid invoices). Have finance decide what happens to the original open invoice before the new one is released.
Renewals and true-ups: two charges, two calculations
An annual renewal can carry two different charges. The true-up settles seats or usage from the term that just ended. The renewal sets the price and quantity for the next term. Calculate each separately before asking anyone to approve the bill.
For the expiring term, read the signed order and every amendment. Identify how seats are measured (peak, average, or a count on a given date) and what price applies above the commitment. Then compare the seat record to charges already issued.
Illustrative example: a true-up that nearly double-billed
The customer committed to 100 seats. The contract counts peak seats and bills overage at $360 per seat for the full term. Peak usage was 120 seats. In month seven, billing already invoiced a 10-seat expansion under an amendment.
- Seats above commitment: 120 − 100 = 20
- Already billed by amendment: 10
- Remaining true-up: 10 × $360 = $3,600
A draft that ignored the amendment would have billed 20 × $360 = $7,200, overcharging by $3,600. Give the approver four numbers: the old commitment, the observed quantity, what was already billed, and what you plan to charge now.
For the renewal line, compare the new order with the draft: start date, quantity, price, currency, billing entity, and any buyer PO requirement. A renewal sent with last year’s PO can be rejected by the customer’s portal while still showing open in your aging. The invoice acceptance guide covers PO and portal checks.
Implementation milestones: bill the trigger in the contract
The implementation team marks a project complete. Billing still needs to know whether the statement of work calls for an invoice at completion, at customer acceptance, or on a fixed date.
| Record | What it tells billing |
|---|---|
| Signed SOW and amendments | The trigger, amount, and the customer responsible for payment |
| Completion or acceptance evidence | When the trigger was met and who confirmed it |
| Customer PO and billing instructions | Where to send the invoice and which references it needs |
| Prior invoices | Whether the milestone was already billed in whole or part |
NetSuite can mark a billing milestone complete when a linked project task finishes (Oracle’s milestone billing schedule guide). Confirm the task represents the event the contract requires; “configuration complete” may still need customer sign-off. If acceptance is missing, send it back to the delivery owner with the exact requirement. Then test a second attempt to bill the same milestone so you know how a duplicate gets caught.
After the invoice: failed payments
A card charge fails. Read the decline reason before scheduling another attempt.
| What happened | What to do |
|---|---|
| Retryable decline | Follow the processor’s retry policy and show the next attempt date to the account owner |
| Hard decline or missing payment method | Ask the customer to update payment details through your approved billing flow |
| Customer questions the invoice | Send the charge to billing and follow your policy for pausing reminders |
| Payment succeeded | Stop the failure sequence and confirm the invoice status |
Stripe documents that its subscription retry workflow prefers the subscription’s default payment method over the customer’s default (Stripe’s payment retry guide). If retries keep hitting an old card, check where the replacement was saved.
After the invoice: disputes and chargebacks
An email about a wrong invoice belongs in a different queue from a card dispute. Both need an owner, but the records and deadlines differ. Check whether a processor dispute is open before you issue a refund or continue collection follow-up, or you can end up refunding a charge the card network is already reversing.
| Customer’s reason | First records to check |
|---|---|
| Wrong price or seat count | Signed order, effective date, and billed quantity |
| Duplicate charge | Invoice history and both payment references |
| Charge after cancellation | Cancellation confirmation, contract terms, and the billed period |
| Cardholder does not recognize the charge | Processor dispute category and transaction details |
For a billing dispute, record the disputed line, who can correct it, and when, and keep collecting the undisputed lines. For a processor dispute, check the deadline and decide whether to accept or contest it. Stripe documents that evidence requirements vary by dispute category (Stripe’s dispute response guide). The deductions and short-pay guide has a resolution workflow you can adapt.
Marketplace and reseller payouts
A marketplace payout can include several sales, deduct a fee, and net off a refund from an earlier period. Start with the settlement detail and build a bridge to the amount that reached the bank.
Illustrative bridge for one payout: gross sales $10,000, less channel fees of $300, less a $500 refund on a sale from the prior month, equals a net deposit of $9,200. Apply $10,000 to the customer invoices, record $300 to the fee account your policy specifies, and tie the $500 refund back to the original sale.
AWS Marketplace’s billing event feed documents a bank trace ID for disbursed transactions and a buyer transaction reference that groups related records (AWS Marketplace billing event feed). Use the first to find the deposit and the second to explain it. If a reseller sends only a payout total, ask for invoice-level remittance; the unapplied cash guide covers holding what you cannot yet allocate.
Keep billing and revenue on separate schedules
A paid annual invoice is closed in AR, but revenue accounting still owes the customer the rest of the term. IFRS 15 ties revenue recognition to satisfying a performance obligation, at a point in time or over time (IFRS 15 overview). The invoice date and bank date alone do not set the schedule. Confirm treatment of your own contracts with your auditors.
Illustrative: a $12,000 annual subscription billed upfront, recognized in 12 equal amounts under the controller’s approved policy. After month one, $1,000 is recognized and $11,000 remains deferred. Payment clears the receivable without changing that schedule. When seats are added, the invoice changes what AR collects; revenue accounting separately decides how the schedule changes. Attach both decisions to the same amendment.
Pre-send checklist
Run this on every draft that contains anything other than an unchanged recurring line:
- Billing entity, currency, and PO match the current order and amendments
- Usage events processed through cutoff; duplicates excluded by event ID
- Proration uses the amendment’s effective date, not the provisioning date
- True-up subtracts seats already billed mid-term
- Milestone has the acceptance evidence the SOW requires and has not been billed before
For the wider AR process, see the AR automation guide and SaaS finance automation.