How does subscription billing work end-to-end for a SaaS finance team?

A subscription ties a customer to a recurring price; the billing platform auto-generates an invoice each cycle, attempts payment, and if it fails, moves to past_due and runs a retry schedule before giving up. Revenue recognition is a separate final step: once invoiced, ASC 606 determines when that amount is actually allowed to hit revenue — usually not the moment the invoice was generated.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 16, 2026Last reviewed September 16, 2026Editorial policy

Part of the subscription and usage billing guide.

What a subscription actually is	A customer tied to one or more recurring prices, not a single standalone transaction
Invoice states	created (drafted) → finalized (locked, payment about to be attempted) → payment_succeeded or payment_failed
On payment failure	Subscription moves to past_due status; a retry schedule (Stripe calls this Smart Retries) attempts collection again before giving up
Reported recovery rate	Businesses using Stripe's recovery tools recover 55% of failed payments on average
Billing vs. recognition	Invoicing determines what's charged and when; recognition (ASC 606) determines when that amount is allowed to hit revenue — often a different period

What a subscription actually consists of

A subscription isn't a single transaction — it's a standing relationship between a customer and one or more recurring prices, set up once and then generating billing activity on its own schedule going forward. Stripe's own model, common across billing platforms generally, ties a Customer object to a Price (which itself belongs to a Product), and the platform handles generating the recurring invoices from that relationship rather than requiring a new invoice to be manually created every cycle.

What happens automatically each billing cycle

Each cycle, the platform generates an invoice (initially in a created/draft state), finalizes it (locking the amount and triggering a payment attempt), and then records the outcome — payment_succeeded if the charge went through, payment_failed if it didn't. This sequence repeats on its own for every billing period the subscription remains active, which is the core mechanical difference between subscription billing and one-off invoicing: the recurrence is built into the system, not re-triggered manually each time.

What happens when a payment fails

A failed payment doesn't immediately cancel the subscription — it moves to past_due status and enters a retry sequence, attempting collection again on a schedule rather than giving up after one failure. Stripe's own reported figure is that businesses using its recovery tools (retries, card updater, cancellation surveys) recover 55% of failed payments on average — meaning a meaningful share of what initially looks like churn is actually a recoverable, temporary payment failure (an expired card, a temporary insufficient-funds situation) rather than a genuine cancellation.

Why invoicing and revenue recognition are separate steps

Everything described so far is the billing side — it determines what the customer is charged and when. It does not determine when that amount is allowed to be recognized as revenue. A subscription invoiced annually up front still has its revenue recognized ratably over the twelve months of service under ASC 606, not all at once when the invoice is paid. This is the same billing-versus-recognition distinction covered on this cluster's hub page, and it's the reason a finance team can't read "invoiced revenue" off the billing system and treat it as GAAP revenue without applying recognition rules on top.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Field mapping

One subscription's cycle, stage by stage, with what each stage actually determines

Stage	What happens	What it determines
Invoice created	Draft invoice generated for the new billing period	The amount that will be charged, pending finalization
Invoice finalized	Amount locked; payment attempt about to trigger	What the customer will actually be charged
Payment succeeded / failed	Charge attempted against the customer's payment method	Whether cash was actually collected this cycle
Revenue recognized	ASC 606 rules applied to the invoiced amount, separately from billing	Which period(s) the amount actually counts as revenue in

An annual subscription invoiced and paid in January moves through the first three stages entirely in January — the cash and the invoice are both January events. The fourth stage, revenue recognition, spreads that same amount ratably across all twelve months of the service period, meaning only 1/12th of it counts as January revenue even though 100% of the cash and the invoice happened that month.

Frequently Asked Questions

The exact status names vary by platform, but the underlying stages — a draft period, a locked/finalized amount, and a payment outcome — are common across subscription billing platforms generally, since they reflect the actual sequence of events any recurring-charge system has to go through.

If collection is never successful, the invoiced amount generally shouldn't be recognized as revenue at all, or needs to be reversed if it was already recognized — recognized revenue is meant to reflect consideration the company is entitled to and expects to collect, not simply what was invoiced regardless of collectibility.

Typically yes, structurally — a trial is usually modeled as a subscription with a delayed first invoice date, using the same underlying created/finalized/payment-attempt mechanism once the trial period ends and billing actually begins.

Sources

How-to

How do I automate dunning and collections reminders?

Schedule reminders relative to the due date (a few days before, then at set intervals after), with escalating tone and channel, and add a suppression check before each send confirming the invoice is still genuinely open and undisputed. Most accounting systems support scheduling this natively; the suppression check is what prevents the most damaging automation failure.

Topic

Subscription & Usage Billing

This cluster covers how recurring and usage-based charges get billed, and how that billing connects to revenue recognition once the invoice is issued. It sits next to the Revenue Recognition cluster r…

Diagnostic

How do I meter and reconcile usage-based billing accurately?

Assume usage events can arrive more than once — retries, network issues, and reprocessing all produce duplicates in at-least-once delivery systems — and deduplicate on a unique event ID before counting. Reconciliation means confirming the invoiced usage total traces back to a specific, replayable set of deduplicated events, not just that the final number looks plausible.

Comparison

What subscription billing software integrates with my ERP?

The platform name matters less than what data it actually exports: whether invoice-level detail includes what your ERP needs for ASC 606 allocation (service period dates, per-line SSP basis), whether proration and mid-term changes are represented explicitly rather than netted into one number, and whether multi-currency and dunning events are exposed as data, not just dashboard-only features.