先确定谁共用序列，再选择编号前缀
一则历史开发者提问指出：如果需要连续发票编号，难道必须遍历每位客户的发票，或者重新开发整个计费系统吗？[4] 这反映了真实的操作困惑，但提问中的法律判断和旧版框架行为不能直接当作当前产品规则。实际配置前，应分别回答三个问题：哪个范围共用一个计数器、编号使用什么前缀，以及本次操作是在修改未来默认值，还是修改某张草稿发票。
Stripe 支持客户级编号：每位客户拥有独立前缀与自己的连续序列；也支持账户级编号：所有客户共用前缀，并在整个账户范围内连续编号。[1] 应先由计费负责人批准编号政策，再选择配置。不能因为某种方案是账户默认值，就认定它满足当地法律。本文仅解释文档所述的配置方式，不提供法定发票编号建议，不保证任何国家或地区的合规结果。
修改默认值，不等于重写已有发票
Stripe 明确说明，切换编号方案或修改前缀只影响未来发票，不影响已有发票。[1] 因此，更换品牌前缀不是批量重新编号。建议在操作前记录当前方案、前缀、对应的下一个序号、执行人以及切换计划。这些是编辑建议的变更记录，并非 Stripe 强制要求的字段。
客户级前缀可以在控制台的客户页面设置；对于使用 Customer 对象的集成，也可以使用 invoice_prefix 参数。[1] 当前官方指南规定，前缀由一至十二个大写字母或数字组成，不能与其他客户的前缀相同，包括已经停用的前缀。[1] 不要因为某位客户不再购买，就把其旧代码分配给新客户。停用与可重复使用是不同概念。
账户级前缀在发票设置中修改；文档要求账户的默认接口版本至少为 2020-03-02。[1] 当前指南同样规定一至十二个大写字母或数字，并禁止与客户前缀冲突，包括已停用的客户前缀。[1] 如果界面没有相应设置，请让集成负责人核对默认接口版本和升级影响，不要为了显示一个开关而未经评审直接升级。
延续旧序号，而不是尝试倒退计数器
Stripe 默认从 0001 开始编号，并允许迁移时设置更晚的起始值。[1] 对于采用客户级编号的 Customer 对象，可以在客户详情页设置，或使用 next_invoice_sequence；账户级编号则在发票设置中的下一张发票序号字段设置。[1] 修改数字部分的起点，与修改前缀，是两项独立决定。
下一个序号只能设置为大于已在发票上使用过的数字，允许的最大值为 1,000,000,000。[1] 如果业务提出“重新从一开始”，应单独审查编号政策，而不是把它视为普通重置。建议先盘点旧系统与 Stripe 已开具的编号，明确切换期间由哪个系统负责开票，再批准新的起始值。接口接受了配置，也不代表多个系统共同使用的编号规则已经通过法律审查。
还应为切换安排明确的负责人。不要让一个团队继续在旧系统开票，另一个团队同时根据过时的最后序号设置新系统。建议保存切换前的最后一张已发行记录、获批的下一个值，以及实际切换后的首张记录。这里描述的是操作控制设计，不是声称 Stripe 会自动检查企业的其他开票系统。
把单张编号决定留在草稿阶段完成
更新发票接口说明草稿发票可完整编辑，并提供单张发票的 number 参数；如果没有编号，Stripe 会在发票最终确认时自动分配。[2] 显式指定完整编号的长度上限是二十六个字符。[2] 这不是客户前缀，也不是账户的下一个序号。不要把前缀长度限制错误地套在完整自定义编号上。
如果需要在最终确认前保留人工检查窗口，文档说明 auto_advance=false 会停止自动最终确认，以及计费引擎的其他动作，例如重试付款和发送提醒。[2] 因为影响不止编号，应先与计费负责人确认是否适合暂停。建议在真正最终确认前重新核对当前状态、目标编号、客户资料、金额及收款方式，不要把几小时前的草稿截图当作当前仍可编辑的证据。
最终确认之后，大部分发票详情不能再修改，包括与金额及客户相关的字段；更新接口也明确指出金额字段和 collection_method 不再可编辑。[2][3] 因而应在草稿阶段完成编号决策，而不是承诺已最终确认的文件都能随时改版。已最终确认发票的更正应进入另行批准的处理流程，不应由改前缀脚本自动处理。
示意迁移：两位客户共用一个账户序列
以下是示意方案，并非真实账户测试。假设企业已经批准账户级编号，旧系统最后一张编号是 SHOP-0123。在确认前缀及下一个值可用后，操作员将账户前缀设为 SHOP，下一个序号设为 124。按照文档中的共享序列模型，随后给两位不同客户开的发票会使用连续编号，例如 SHOP-0124 和 SHOP-0125。[1] 这些是用于解释规则的假设结果，不是观察到的接口响应。
另一个独立的客户级示例是 ALPHA-0001 与 BETA-0001：数字部分相同，但对应不同客户的序列，并不是完整编号重复。[1] 建议用两位客户演练两种方案，让评审者明确看到哪个计数器会增加。还应覆盖前缀冲突、试图调低序号、单张草稿自定义编号，以及不应改变的历史发票。这些只是建议的验收用例，不能写成已经执行通过的测试。
以实际记录结束变更，而不是凭设置截图判断成功
建议保留获批配置、实际开出的首批编号、对应发票标识及未改变的历史记录，并核对客户看到的文件与系统记录是否一致。若使用 on_behalf_of 开票，Stripe 指南另行说明：序列由交易登记商户决定，不同关联账户可能出现相同的前缀与数字组合。[1] 因此，涉及关联账户的平台需要单独检查账户范围，不能假设整个平台只有一个全局计数器。
本文来源核对日期为 2026-09-23，属于公开文档研究，不是实际付款测试，也不表示 PayIn 已实现 Stripe 的编号功能。具体账户配置及可用性需要另外核实。涉及法律、税务或保存原始发票的要求，应咨询具备资格的专业人士。
来源与日期
官方来源用于核实产品行为；历史社区提问仅说明需求。未明确提供的发布与更新日期均视为未知，抓取日期不代表发布日期。
- [1] 自定义发票 — 发布及更新日期未注明；核对日期：2026-09-23。
- [2] 更新发票 — 发布及更新日期未注明；核对日期：2026-09-23。
- [3] 发票状态转换 — 发布及更新日期未注明；核对日期：2026-09-23。
- [4] 使用 Laravel Cashier 与 Stripe 时如何生成发票编号 — 发布于 2017-04-13；更新日期未注明；核对日期：2026-09-23。