Cash Revenue recognition

Problem Statement 1 — Eligibility

Revenue should only be recognized for invoices that have been successfully fully paid (or partially paid, TBD); unpaid or failed invoices must not contribute to recognized revenue.

Problem Statement 2 — Timing

Revenue recognition must begin on the invoice payment date, not on the invoice creation date, when payment succeeds after an initial failure.

Problem Statement 3 — Subscription Access & Term Alignment

Subscription access and the subscription term must begin on the payment success date; if payment succeeds after the initial subscription attempt, the subscription start and renewal dates should shift to align with the payment date.

User Story 1 — Revenue Eligibility

As a finance user, I want revenue to be recognized only for invoices that are paid, so that unpaid or failed invoices do not count toward recognized revenue.

User Story 2 — Revenue Timing

As a finance user, I want revenue recognition to start on the invoice payment date, not the invoice creation date, so that revenue timing reflects when payment actually succeeds.

User Story 3 — Subscription Access & Term Start

As a subscriber, I want my subscription access and renewal period to begin when my payment succeeds, so that my access duration aligns with when I actually paid.

Solution 1: Revenue recognition (Problem 1)

Revenue is recognized only for invoices with status = paid (Partial payments: TBD). No revenue is recognized for unpaid or failed invoices, and no revenue is backdated to periods before payment.

Solution 2: Subscription term alignment (Problem 2)

On the first successful payment, the subscription term is anchored to the payment date by setting invoice.current_period_start = invoice.paid_at and invoice.current_period_end = invoice.paid_at + plan_interval, and copying these values to the subscription. This ensures access starts when the user actually pays and renewals align to that date (e.g., Jan 7 → Feb 7).

Solution 3: Subscription activation & access (Problem 3)

When a subscription is created, payment is attempted immediately, but the subscription remains incomplete and grants no access until the first payment succeeds. If payment fails, the subscription stays pending. When payment succeeds (invoice.paid_at), the subscription becomes active.

Definition of Done — Product-level Revenue Recognition Strategy

Configuration

1. A new product-level dropdown labeled “Revenue recognition strategy” exists on the Product configuration page.

2. The dropdown has two options:

3. Invoice-creation-based (default) — preserves existing behavior.

4. Invoice-payment-based — enables payment-anchored behavior.

5. All existing products default to Invoice-creation-based with no behavior change.

Invoice creation date (Default)

1. Revenue recognition behavior remains unchanged.

2. Unpaid or failed invoices continue to be treated according to current logic.

3. Subscription activation, access, and term dates behave exactly as today.

Payment creation date (New)

1. Only invoices with status = paid are included in revenue recognition.

2. Unpaid or failed invoices are automatically excluded from revenue reports.

3. Revenue recognition starts at invoice.current_period_start.

4. invoice.current_period_start is set to invoice.paid_at.

5. invoice.current_period_end is set to invoice.paid_at + plan_interval.

6. Subscription activation occurs only after the first invoice is paid.

7. Subscription current_period_start and current_period_end match the invoice period.

8. Subscriber access begins at current_period_start.

Backward Compatibility

1. No breaking changes are introduced.

2. Existing products and subscriptions continue to use Invoice-based behavior unless explicitly updated.

Acceptance Criteria

1. Switching a product to Invoice-payment-based immediately enforces payment-anchored access, term dates, and revenue filtering.

2. Revenue reports correctly exclude unpaid invoices for Payment-based products.

3. Revenue reports remain unchanged for Invoice-based products.