A customer on a £500/month plan emails Friday afternoon asking to upgrade to £1,500/month immediately. Your billing system processes it Monday morning. The invoice shows £2,000 because it charged the full new plan plus a 'pro-rata adjustment'. Your customer disputes it. Your accountant asks whether you credited the unused portion of the old plan or created a separate line item. Your tax software doesn't recognize the partial refund as a credit memo. By Wednesday, you've manually fixed three invoices and your reconciliation is broken. This is not edge-case chaos. Mid-cycle changes happen constantly—upgrades, downgrades, plan changes, usage spikes. Most billing software either doesn't handle them correctly, or handles them correctly in a way your accounting team doesn't understand. Stripe Billing, Recurly, and Chargify each calculate prorations differently, and each has blind spots for regional tax compliance. What proration actually is (and where it breaks) Proration means adjusting the invoice when a customer changes plans mid-billing-cycle. If they upgrade from £500/month to £1,500/month on day 15 of a 30-day cycle: They've already paid £250 for the first half of the old plan (£500 ÷ 30 × 15). They owe £750 for the second half at the new rate (£1,500 ÷ 30 × 15). Net: they owe £500, or get a £250 credit if you've already invoiced them. That sounds simple until you ask: do you apply the credit immediately or carry it forward? Do you issue a credit memo (accounting) or a negative line item (tax reporting)? What happens in regions where tax is calculated on the gross amount before credits? Do you prorate usage-based charges, or reset the meter? Most DIY Zapier flows prorate the subscription charge but forget usage, or apply credits that tax software doesn't recognize. Spreadsheet-based workflows add the credit manually, which breaks reconciliation. Off-the-shelf tools either prorate too aggressively or not at all. Stripe Billing: transparent, but you own the tax logic Stripe Billing prorates by default and shows you exactly what it's doing. When a customer upgrades mid-cycle, Stripe creates: An immediate invoice for the prorated difference (the upgrade charge). A separate credit equal to the unused portion of the old plan (shown as a negative line item). That credit applies to the next billing cycle, unless you configure it otherwise. In our example (£500 to £1,500 on day 15): Stripe invoices £500 immediately and credits £250 forward to cycle two. The trap: Stripe treats that credit as a 'balance' on the customer's account, not a formal credit memo. If your accounting software expects credit memos for tax reporting (especially in regions like Singapore or Malaysia, where GST/SST applies to net invoices), you'll reconcile fine in Stripe but your tax records will show the gross amount. This matters when you're audited or filing monthly returns. Usage-based on top of recurring: If you bill both subscription and usage, Stripe prorates the subscription but not the usage meter. You have to reset the meter manually or let overages accumulate, which creates confusion about what was actually consumed. Recurly: prorations that stay visible in invoices Recurly handles proration differently: it creates a new invoice immediately with both the old plan's prorated refund and the new plan's prorated charge on the same line item. This keeps everything in one invoice instead of spreading it across cycles. Same upgrade scenario (£500 to £1,500 on day 15): Recurly creates one invoice showing: Old plan refund (–£250), New plan charge (£750). Net due: £500. The credit is visible on the invoice itself, not hidden in a separate balance. Why this matters: Accountants recognize this format immediately. Tax software can parse the individual line items correctly. Regional compliance is easier because the credit and charge are on the same document. The downside: If you have many currency or region-specific tax rates, Recurly requires you to configure tax handling per plan. It doesn't auto-calculate tax on the refund portion—you have to decide whether the £250 credit is subject to reversal of the original tax. In Indonesia, where usage-based billing also triggers 10% tax on services, this can create a tax mismatch if your tax rules are incomplete. Chargify: usage-based proration that actually works Chargify is built for mixed billing (subscription + usage + one-time charges) and prorates all three simultaneously. If a customer on a £500/month subscription with a £0.10 per-unit usage charge upgrades mid-cycle and has consumed 1,000 units: Subscription proration: –£250 (unused old plan) + £750 (new plan) = £500. Usage: £100 already charged (1,000 × £0.10), applied to the subscription total. One invoice showing all three components. Real strength: Chargify resets the usage meter when you change a usage-based component, so you don't double-count overages. It also handles plan change sequences (if a customer changes plans twice in one cycle) wi