Key takeaway
An active subscription does not prove every invoice is paid or every feature is entitled. Keep billing evidence, feature entitlement and observed application access separate.
Ask which feature the customer could actually use
A support archive contains a customer row marked active and a separate complaint that reporting was unavailable. A later analyst treats active as both proof of payment and proof of feature access. That single label can conceal several different states: the subscription lifecycle, a particular invoice, the feature entitlement and the access the application actually provisioned.
Stripe’s subscription documentation explicitly says active does not necessarily mean all associated outstanding invoices are paid. Collection method and configured status resolution affect the result. Its Entitlements documentation separately maps customers to product features and describes provisioning in the application. These product-specific meanings should survive an export instead of being collapsed into one account_active field.
Reconstruct three fictional accounts without inventing payment
Hypothetical example: assume the following three invented account records are observed at one declared cutoff. The entitlement evidence is stipulated complete for the named reporting feature, and the local access observations are also stipulated accurate. These are illustrative states, not a query of Stripe or any customer system. No subscription, invoice or access setting was changed.
A has an active send-invoice subscription with an open first invoice; its reporting entitlement and application grant agree. B has a paid invoice and an active subscription, but the named feature is absent from its established entitlement state while the application still allows it. C has a paid historical invoice but a canceled subscription, no reporting entitlement and a lingering application grant.
| Fictional account | Billing evidence | Reporting entitlement | Application access | Review finding |
|---|---|---|---|---|
| A | Active; send_invoice; first invoice open | Present | Allowed | Access agrees; invoice remains unpaid |
| B | Active; specified invoice paid | Absent | Allowed | Investigate unsupported local feature grant |
| C | Canceled; historical invoice paid | Absent | Allowed | Investigate stale access; past payment does not establish current entitlement |
An invoice answers an invoice question
For A, unpaid is a statement about the identified invoice. It is not automatically a statement that the application should revoke access under every commercial arrangement. Stripe documents that a send-invoice subscription without a trial can initially be active while the first invoice remains unpaid. Keep the agreed credit/access policy and its version with the operational review.
For B and C, the retained payment evidence does not create the missing current reporting entitlement. Investigate the feature mapping, actual subscription coverage and local grant reason. A manual exception might explain access if it has its own authority and duration; an unexplained boolean cannot supply that explanation. Preserve the observed state while recording the discrepancy separately.
Product mapping is not the same as effective customer access
Stripe’s API-variant guide says that changing product features for existing subscriptions creates the related active entitlements at the next billing period’s start. A current product catalog therefore cannot automatically reconstruct which features a customer held at an earlier instant. Keep the mapping version, relevant period boundary and customer entitlement evidence linked.
The guide also describes application-side provisioning from entitlement changes and a direct current-entitlement lookup. That distinction is central to the archive: entitlement evidence explains what access should follow the configured mapping; a local application record explains what was actually enabled. Recording the provider’s event does not prove that the application applied the corresponding feature change successfully.
Keep a feature-level history with a bounded finding
For each reviewed case, retain the customer/subscription relationship, collection method, invoice identifiers and statuses, relevant status-resolution configuration, feature key, entitlement state, observation time and application-grant reason. Preserve test versus live environment identity. Missing historical settings should remain unresolved rather than being filled from today’s account configuration.
The completed fictional review identifies A’s unpaid invoice separately and assigns B/C’s feature-access discrepancies for investigation. It does not declare lost revenue, customer misuse or a billing defect. It also leaves event completeness and delivery mechanics to their own checks. Inventory can describe this state history without exporting customer payment details; Readiness can assign the missing mapping or grant evidence before a recipient relies on it.