Subscription Accounting for SaaS Companies

Mid-month switches from monthly to annual require a careful transition entry. Most billing systems handle this by crediting the unused days of the current monthly billing period and charging the full annual fee from the switch date. Accounting: credit the unused days as a reduction of the monthly subscription revenue or as a credit against the annual payment (depends on your billing flow). The full annual amount then goes to deferred revenue and releases monthly from the switch date. In practice: if the customer’s monthly billing date was the 1st and they switch on the 15th with 16 days remaining in the cycle, a credit of (16/31) × €199 = €102.71 is issued. This reduces the monthly revenue recognised, and the annual payment creates the deferred revenue balance. Update the MRR waterfall: the upgrade from monthly to annual appears as a change in MRR cadence but not necessarily as expansion MRR (unless the annual rate is higher than monthly × 12, which it usually is if you offer an annual discount).

Stop recognising revenue and make a bad debt provision. Under IFRS 15, revenue can only be recognised when it is highly probable that the consideration will be collected. Three months of failed payments with no recovery strongly indicates that collection is not probable. You should reverse the revenue recognised since the last successful payment, create a bad debt expense equal to the amount written off, and update the MRR waterfall to reflect the churn (typically backdated to the date access was effectively suspended). Going forward: implement a stricter dunning process that suspends access within 14 days of failed payment, preventing the accumulation of uncollected recognised revenue. Some SaaS companies also have a policy of treating subscriptions as cancelled (and revenue reversed) after two consecutive failed billing cycles.

The subscription database (Stripe Billing, ChartMogul, Chargebee) maintains the customer-level MRR record — every subscription, its plan, its value, and all events. For audit purposes, this database should be exportable as a point-in-time snapshot showing each customer’s active subscriptions at the reporting date. The sum of all active subscription monthly values = MRR at that date. The year-end audit typically involves: agreeing the MRR snapshot to recognised revenue in the deferred revenue schedule, sampling individual customer records against the billing system, and confirming that cancelled subscriptions are not included in the closing MRR. Keep exports of the subscription database at each month-end as a permanent record.

During the pause, suspend the monthly deferred revenue release. The deferred balance stays where it is for 2 months — no P&L revenue, no reduction in the liability. When the customer reactivates, resume the monthly release. The effective result is that the subscription term extends by 2 months: a 12-month annual subscription with a 2-month pause becomes a 14-month service period (12 months of active service + 2 months of pause). The total recognised revenue over the full term equals the original contract amount. The deferred revenue balance at each point in time correctly reflects the remaining service obligation.

Our Stripe dashboard shows different revenue from our accounting system. How do we reconcile them?
Stripe and your accounting system recognise revenue on different bases and with potentially different timing. Stripe’s ‘Revenue’ figure in the dashboard is typically cash collected (or net settlement amount). Your accounting system recognises revenue based on IFRS 15 — ratably over the subscription period for annual plans, with deferred revenue movements. To reconcile: (1) Take Stripe’s total monthly charges. (2) Subtract VAT collected (Stripe often shows gross figures). (3) Add/subtract deferred revenue movement (opening balance minus closing balance). (4) Add/subtract other adjustments (refunds, chargebacks). The resulting figure should equal your accounting P&L revenue. If it does not, the difference is usually one of: timing of recognition (annual plans not yet released from deferred), multi-element contract allocation, or transactions that exist in one system but not the other (e.g. manually invoiced enterprise deals not through Stripe).