Choose the sequence before choosing the prefix
A historical developer question asks how to produce sequential invoice numbers without counting every customer's invoices or rebuilding the billing system.[4] That is a useful operational problem, but the question's legal assumptions and older framework behavior are not current product rules. Start with three separate decisions: whose sequence should advance, which prefix should appear, and whether you are changing future defaults or one draft invoice.
Stripe supports customer-level numbering, with a unique prefix and an independent sequence for each customer, and account-level numbering, with a shared prefix and a sequence across customers.[1] Choose between them through an approved billing policy, not by assuming that the default proves legal compliance. This guide describes documented configuration, not legal numbering advice, and makes no country-specific compliance guarantee.
Separate defaults from existing invoice records
Stripe states that switching schemes or updating prefixes affects future invoices, not existing invoices.[1] Consequently, a branding change is not a bulk-renumbering operation. Before making it, record the current scheme, the current prefix, the relevant next sequence, the responsible operator, and the planned cutover. These are recommended change-control records, not mandatory Stripe fields.
For customer-level numbering, use the customer's Dashboard page or, for Customer objects, the invoice_prefix parameter.[1] Stripe's current guide says prefixes must contain between 1 and 12 uppercase letters or numbers and cannot match another customer's prefix, including a retired prefix.[1] Do not recycle an old customer code merely because its owner is no longer active.
For account-level numbering, change the prefix in Invoice settings; Stripe documents a default account API version of at least 2020-03-02 for this control.[1] The current guide gives the same 1–12 uppercase-letter-or-number constraint and prohibits matching customer prefixes, including retired ones.[1] If the control is unavailable, ask the integration owner to review the default API version and upgrade implications rather than making an unreviewed version change.
Continue a sequence without trying to rewind it
Stripe starts numbering at 0001 by default and supports setting a later starting point when migrating from another system.[1] For Customer objects using customer-level numbering, use the Customer details page or next_invoice_sequence; for account-level numbering, use the Next invoice sequence field in Invoice settings.[1] Do not confuse changing the starting suffix with changing the prefix.
The next number must be greater than numbers already used on an invoice, and Stripe documents a maximum of 1,000,000,000.[1] Treat a request to restart an existing sequence as a separate policy review, not a routine reset. Our recommendation is to inventory numbers already issued by both the old system and Stripe, agree on one issuing system during cutover, and document the selected next value. A syntactically accepted setting does not establish that a multi-system numbering policy satisfies local requirements.
Use the draft boundary deliberately
The invoice-update API describes draft invoices as fully editable and accepts a number parameter for an individual invoice; if no number is present, Stripe assigns one automatically when the invoice is finalized.[2] The documented maximum length for an explicitly supplied number is 26 characters.[2] This is a different control from a customer prefix or the account's next sequence. Do not apply the prefix's length limit to the complete custom number.
For a deliberate pre-finalization review, Stripe documents auto_advance=false as stopping its automatic finalization and other Billing-engine actions such as retries and reminders.[2] Coordinate that hold with the billing owner, since it changes more than numbering. Our recommended review checks the draft's current status, intended number, customer details, amounts and collection method immediately before finalization. Do not treat an earlier screenshot as confirmation that the invoice remains a draft.
After finalization, most invoice details, including amount- and customer-related fields, cannot be changed; the update reference specifically makes monetary values and collection_method uneditable.[2][3] Therefore, finish the numbering decision in draft rather than promising that every finalized document can be cosmetically rewritten. An already-finalized correction belongs in a separately approved correction workflow, not an automatic prefix-change script.
Illustrative migration: two customers, one account sequence
This is an illustrative plan, not a live Stripe test. Suppose a business has approved account-level numbering and its old system ended at SHOP-0123. After checking that the selected prefix and next value are eligible, the operator sets the account prefix to SHOP and the next sequence to 124. Under the documented shared-sequence model, the next two invoices to different customers would use successive numbers, such as SHOP-0124 and SHOP-0125.[1] These are hypothetical results, not observed API responses.
In a separate customer-level example, ALPHA-0001 and BETA-0001 represent different customer sequences, not a duplicate complete number.[1] Our recommendation is to rehearse both models with two customers so reviewers can see which counter advances. Also check a prefix collision, an attempted backward sequence change, a custom draft number, and an existing invoice that must remain unchanged. Preserve actual observed results separately from these proposed acceptance cases.
Close the change with evidence, not assumptions
Record the settings approved, the first actual issued numbers, their invoice identifiers and the unchanged historical records. Compare the customer-facing document with the invoice record before declaring the cutover complete. Stripe's guide separately documents that invoices issued with on_behalf_of use the merchant of record's sequence; connected accounts can have matching prefix-and-suffix combinations.[1] A Connect deployment therefore needs a separate account-scope review rather than assuming one platform-wide counter.
Sources were checked on 2026-09-23. This is public-document research, not a live payment test or a claim that PayIn implements Stripe numbering. Account configuration and availability must be checked separately; consult a qualified adviser for legal invoice requirements.
Sources and dates
Official sources support product behavior; the historical community question demonstrates demand only. Publication and update dates are unknown unless stated. Retrieval is not publication.
- [1] Customize invoices — Publication and update dates not stated；Checked 2026-09-23。
- [2] Update an invoice — Publication and update dates not stated；Checked 2026-09-23。
- [3] Invoice workflow transitions — Publication and update dates not stated；Checked 2026-09-23。
- [4] Laravel cashier with Stripe: invoice number — Published 2017-04-13; update date not stated；Checked 2026-09-23。