A SaaS upgrade is unpaid: reconcile payment, billing and product access

When an upgrade payment fails, inspect the subscription, invoice and product access separately. The customer may have requested a larger plan without receiving it, or the product may already have granted additional capacity. Record the old plan, requested plan, effective date and current entitlements before sending a collection message or changing a revenue metric.

Use the system identifiers to connect the records. A sales opportunity marked won may describe an accepted commercial request, while a billing event describes a payment attempt. Neither alone proves that the intended subscription change completed. Give the customer one clear status that reflects the actual service and payment state.

Stripe documents that ordinary subscription updates can apply even when payment fails, whereas its pending-update feature generally waits for successful payment before applying eligible changes. It also documents exceptions and eligibility conditions. The finance review therefore needs the configured behavior, not an assumption that every failed charge automatically reverses an upgrade.

Ask the system owner to identify the resulting invoice and the pending change, if one exists. Confirm whether further customer authentication is required, the payment is still processing or the attempt has failed. A pending record can reflect unfinished processing rather than a final refusal. Assign the next action to the team that can actually resolve that state.

Before an agent retries the process, check whether the original request is still active and whether payment can be completed against the existing invoice. Creating a fresh upgrade can produce an additional charge, a different proration or competing service changes. Record the original request reference in the support case so another team member can continue it safely.

If the customer no longer wants the upgrade, document the accepted cancellation and the approved handling of any access already provided. Review unresolved charges through the billing platform's supported process. Where the contract permits billing for service already delivered, accounting and the commercial owner should assess that evidence together rather than treating a technical rollback as a complete settlement.

Ask the account owner what should happen if the customer never completes the upgrade payment. Identify the plan the customer should retain, any temporary access already granted and the status of the original invoice. The resolution should be explicit rather than leaving the account between an old commercial agreement and a partially applied new one.

Test that scenario alongside successful payment. In a hypothetical upgrade request, the customer might open an authentication screen and then decide to keep the existing plan. The test should demonstrate the intended final entitlement and billing state, with no unexplained extra subscription. Keep any approved service already delivered during the pending interval visible for the commercial and accounting review.

A resolved case should explain the final plan, the final invoice balance and the final product access. If payment succeeded, confirm the service change was applied. If the request expired or was abandoned, confirm that temporary access and pending billing records were handled as intended. Retain any credit or refund reference with the original upgrade.

Report expansion only under the company's documented metric definition. An unpaid request, an active billed upgrade and cash collected are different populations. At close, give accounting the service dates and collectability evidence needed for the applicable reporting policy. Review repeat failures by cause, such as authentication friction or an integration that grants access before confirming the update, and assign a specific correction to the system owner.