A Stripe invoice preview is missing from the invoice list because it was never issued

A customer-support screenshot may show an invoice-shaped object, a total and line items, yet no matching invoice appears in the billing list. Start by identifying whether the system created an invoice or calculated a preview. Reissuing the charge before answering that question can turn an understandable missing-record investigation into an unintended customer bill.

Stripe's create-preview operation calculates an upcoming invoice or the effect of a proposed subscription change. The documentation states that this preview has not created an invoice, does not appear in invoice-list calls and cannot be paid or edited as an issued invoice through the API. Its familiar fields do not make it an ordinary billing record.

Ask the person who supplied the screenshot for the workflow used and the time of the calculation. A saved estimate, support note or API response can be useful evidence of what was discussed. Label it according to that role rather than forcing it into the invoice register simply because it resembles the format of a later bill.

Search for the actual customer and subscription in the correct account and environment. Check whether an invoice was subsequently created through the normal billing process and whether it covers the period described in the preview. Match the source records by their role and references, not just by a similar amount or the customer's display name.

Suppose a fictional customer was shown an estimated next bill of $840 on Monday. On Wednesday, the finance team cannot locate an $840 invoice. The first question is whether Monday's action was only a calculation. If no invoice was created, there is no missing issued invoice to recreate from that evidence alone. The business still needs to determine when and through which approved process the customer should actually be billed.

If an actual invoice exists for a different amount, retain both records and investigate the difference. Do not overwrite the preview to make the earlier customer conversation disappear. The preview may explain an expectation that needs to be addressed even though it was never itself a payable invoice. Commercial communication and the billing register serve different purposes here.

Record the proposed items, quantities, effective time and relevant discount or credit assumptions alongside the preview. Identify whether it represents the next bill or a different estimation mode. Without those details, a total copied into a customer message becomes difficult to explain once the underlying account changes.

Use a simple illustrative bridge: a preview contains a $750 recurring charge and a $90 one-time item, totaling $840 before any other applicable amounts. If an authorized $40 item is added before the actual invoice is created, an $880 total has a specific explanation under these assumptions. The $40 difference should be traced to that item rather than treated as an unexplained failure of the preview calculation.

Stripe notes that currency-conversion rates can differ between preview and invoice creation. For an account involving conversion, preserve the currencies and calculation timing so the reviewer can separate changed inputs from a processing error. Do not promise that every estimate is a guaranteed final amount unless the business has independently made and approved that commercial commitment.

Review where the integration obtains its records. A service that saves every invoice-shaped API response to one table can mix estimates with created billing records. Ask the developer to identify the operation and provenance associated with each stored object. A status field or familiar object label may be insufficient to classify a preview correctly.

Define separate uses for estimation data and the invoice register. A sales or support view may need the latest calculation, while a receivables reconciliation needs the actual records within its defined scope. Preserve an explicit relationship when a later invoice corresponds to an earlier estimate, but do not count both as two charges merely because each has a saved response.

For a controlled test, save one preview and then create the intended invoice through the supported test workflow. Confirm that the issued-invoice population contains the created invoice once. The estimate should remain available only where the design intends to use it. Check the report after a refresh so a correction to the visible table does not conceal an ingestion rule that will reintroduce the preview.

When reviewing the final invoice, compare quantities, service periods, adjustments, discounts and other relevant line details before comparing only the grand total. Two invoices can have equal totals with different service coverage. An estimate can also become stale because a proposed amendment was never applied, even though the original calculation was internally consistent.

Have the technical owner preserve any timing input required by the supported preview-and-update flow when checking prorations. Stripe documents using the corresponding proration date to align a preview with the actual subscription update. That is a technical condition to validate, not a reason for finance to assume every customer adjustment uses the same date or policy.

Resolve customer expectations separately when the final bill legitimately differs. Explain the changed input or approved action in ordinary terms and retain any agreed concession. A correction to a reporting pipeline does not itself settle a disagreement about the amount the customer understood they would pay. Give that conversation to the person authorized to make the commercial decision.

The completed investigation should identify the preview as an estimate, the actual invoice as the billing record if one exists, and any unresolved billing action as a separate task. Record why the original search found nothing and whether an integration or interface label contributed to the confusion. This makes the absence explainable without inventing a lost invoice.

Use wording in internal screens and exports that reflects these roles. A visible preview label and the calculation time can prevent support from calling an estimate a sent bill. Retain the estimate when it supports an important customer agreement, while ensuring that invoice counts and downstream financial work use the population they claim to represent.