一、第一次行级选择，会约束后续信用单
信用单用于减少发票金额，不会像修订发票那样作废并替换原发票。[1] Stripe 支持对原发票行抵减固定金额、抵减数量，或者添加自定义折让行。[1] 但对真实发票行而言，数量与金额不是之后可以任意互换的两种输入方式。
某行一旦按数量抵减，未来针对同一行的信用单也只能按数量抵减；先按金额抵减，后续也只能按金额。[1] 规则约束的是具体发票行，不能扩大理解为整张发票统一锁定。编辑建议：开具前先查历史信用单，并把原行标识、已选模式与本次原因一起留档，避免下一位操作员按另一种模式设计后续方案。
二、先明确纠错对象，再进入开具页面
编辑建议：先核对原行、差错原因、历史抵减，以及本次究竟是少交付数量还是价格调整。尽可能关联真实发票行；Stripe 也推荐这样做，因为自定义行不关联真实发票行，会增加报告与追踪难度。[1] 不要只看客户希望减少的总金额，就跳过原行核对。
假设示例：不含折扣与税的某行按每件20美元计费，共五件，实际只交付三件。按数量抵减两件，依数量乘单价的规则得到40美元。[1] 之后即使团队把另一笔补偿描述成现金金额，对该行仍只能使用数量模式。[1] 若第一次选金额模式，后续则只能继续按金额。[1] 编辑建议：预先讨论可能的二次纠错，不把首次开具当成可以随意撤销的试操作。
三、按折扣后的行金额核算，不按标价承诺
发票折扣按比例分摊至各行。[1] 原文百分比折扣示例是十行、每行10美元，整单打五折后，每行变成5美元，因此抵减一行只减少5美元，并非10美元。[1] 固定折扣同理：十个等额10美元行分摊10美元折扣，每行分到1美元，折后为9美元，抵减一行也只减少9美元。[1]
原文允许通过增加1美元的自定义折让行，把后一示例的抵减补足到原价10美元。[1] 但是否能采用这一办法，还要检查下一节的自动计税限制。编辑建议：审批时写清目标是退还折后行价值，还是额外让利至原价。否则系统计算即使正确，也可能低于对客户的承诺，继而引出模式不兼容或无法使用自定义行的补救请求。
四、自动计税不是自定义行的例外通道
启用 automatic tax 时，信用单不能添加自定义行，应使用原发票行抵减。[1] 原因是自定义行未关联特定原行；当原发票各行税务处理不同，Stripe 无法判断应适用哪种处理。[1] 因此，前述补足折扣差额的示例不能覆盖这一限制，更不应承诺所有发票都能这样补足。
通过 API 使用 custom_line_item 时，必须提供 unit_amount 或 unit_amount_decimal 以及 quantity，不能直接提供一个总额；tax_rates 与 tax_amounts 不能同时使用。[1] 自定义信用单行也不能抵减负数金额。[1] 负数抵减仅支持关联原发票行的信用单行，且需遵守负数行限制，包括信用单总额必须为正数。[1] 编辑建议：不要为了凑总额临时编造自定义平衡行。
五、提交之前，确认资格与作废边界
在 Dashboard 选中 open 或 paid 发票，经 More → Issue a credit note 进入，选择原因，修改符合条件的数量或金额，再提交。[1] open 发票若存在 pending payment_intent，就不能开具信用单。[1] 同一发票所有信用单合计不得超过发票总额；对于 paid 发票，退款、账户入账及 Stripe 外退款金额之和必须等于信用单总额。[1]
只有信用单所关联的发票为 open 时才能作废信用单；作废会撤销抵减，并按信用单金额增加应付金额。[1] 信用单若把 open 发票减至零，发票会变为 paid，但并不记录一笔付款。[1] 因此不要把“归零后再作废”作为预定补救方案。原文也没有说明作废会重置行级数量／金额锁定，不能向客户或同事保证这条恢复路径。
六、验收清单
以下为编辑建议的验收清单：确认发票状态和待处理付款资格；匹配原始行及历史抵减模式；核对折后行金额与累计信用单上限；排除自动计税下的自定义行及其他不允许的输入；核对 paid 发票金额分配；保存原因与开具结果。任一检查未通过，应在提交前暂停。开具后再将实际结果与获批纠错方案逐项比对，不能只凭提交成功就认定已兑现商业承诺。建议复核人明确记录本次抵减覆盖哪些交付差错、是否还有后续补偿，以及剩余方案是否仍符合原行模式；这些是内部操作建议，不代表 Stripe 自动完成了审批或业务核对。
来源与日期
以下为 Stripe 官方英文文档。未注明发布或更新日期；抓取核验日期为 2026-09-21，不把抓取日当成来源发布日期。本文为编辑研究，不代表 PayIn 产品能力、账户资格验证或法律意见。
- [1] Issue credit notes · 核验 2026-09-21；原文日期未注明。