什么是支付对账？将 PSP 结算款与总账进行匹配
为什么 Stripe 结算款永远对不上发票、如何将一笔结算款拆解为销售额、手续费和退款，以及总账分录的实际运作原理。
支付对账是将支付服务提供商（PSP）实际支付给您的款项与客户实际欠您的金额进行核对的过程。这与银行对账是不同的问题，而且要复杂得多，因为一笔 PSP 结算款从来都不是针对一张发票的单一付款。
典型的症状是：您销售了 10,000 欧元，而银行账户收到了 9,712.40 欧元。这两个数字都是正确的。介于两者之间的所有差异，正是本对账指南所要解释的内容。
为什么结算款永远对不上销售额
单一的 Stripe、Adyen 或 PayPal 结算款是一个净额批次（net batch）。在客户付款与资金到账之间，PSP 经过了以下处理：
- 汇总了结算周期内的许多收费，
- 扣除了按交易计算的手续费，
- 扣除了在同一时间窗口内发生的退款和拒付（chargeback），
- 可能扣留了一部分保证金（reserve），
- 并在几天后通过单次转账支付剩余金额。
因此，银行对账单显示为一行（9,712.40 欧元），而总账中有数十张发票，没有一张与之相等。直接将结算款与发票进行匹配是不可能的；必须首先对结算款进行拆解（decomposition）。
拆解过程
结算批次可以细分为不同的类别，每个类别在总账中具有不同的含义：
| 类别 | 解释 | 总账影响 |
|---|---|---|
| 收费（Charges） | 客户付款 | 结清应收款 |
| 退款（Refunds） | 退还给客户的资金 | 冲销已结清的应收款 |
| 手续费（Fees） | PSP 的佣金 | 一项费用 |
| 拒付（Chargebacks） | 争议款项追回 | 重新打开应收款，并产生一笔手续费 |
| 调整 / 保证金（Adjustments / reserves） | 时间差和风险留存 | PSP 欠下的余额 |
必须成立的恒等式：
总收费额 − 退款 − 手续费 − 拒付 ± 调整 = 净结算额
如果不成立，说明导入的批次不完整，而这项检查比任何单笔匹配都更有价值，因为它证明了没有任何数据在悄无声息中丢失。
会计分录
入账一个包含 10,000 欧元总收费、250 欧元手续费、37.60 欧元退款的结算批次：
| 科目 | 借方 | 贷方 |
|---|---|---|
| 2710 银行存款 | 9,712.40 | |
| 6800 财务费用（PSP 手续费） | 250.00 | |
| 5000 收入 / 应收款冲销（退款） | 37.60 | |
| 2410 应收账款 | 10,000.00 |
其含义为：客户的 10,000 欧元债务已清偿，PSP 扣留了 250 欧元，37.60 欧元退还给客户，9,712.40 欧元到达银行。手续费是一项真实的费用，从未出现在任何客户发票上，这正是总收入与银行存款产生分歧的原因，也是为什么仅凭银行流水对账会悄无声息地低估收入和成本。
对于多边市场平台（marketplaces），还有多一层逻辑。如果结算款中包含属于卖家的资金，平台的收入仅仅是其佣金；其余部分则是负债。Nordlet 的入账规则通过专用键（settlements.fees、settlements.commissionRevenue、settlements.sellerPayable 和 settlements.suspense）涵盖了这一点，因此拆分结算会将佣金计入收入，将卖家的份额计入应付款，而不会虚增平台收入。
Nordlet 的处理方式
整个流程包含三个端点：
- 导入（Import）。
POST /v1/bank/settlements/import读取 Stripe 结算对账报告，并创建一个结算批次（包含提供商、结算 ID、币种、总额、手续费和净额），每行对应底层的一笔交易，并带有各自的类别。批次按提供商和结算 ID 唯一标识，因此重复导入相同的报告不会导致重复计算。 - 匹配（Match）。
POST /v1/bank/settlements/match将收费和退款行链接到它们所属的销售发票。交易行带有匹配状态：unmatched（未匹配）、matched（根据报告中的订单或发票引用自动解析）或manual（人工判定）。手续费和调整行按设计无法与发票匹配，系统会拒绝此类尝试，而不是进行猜测。 - 入账（Post）。
POST /v1/bank/settlements/post通过上述入账规则为整个批次写入总账分录，并将批次状态从imported变为posted。未匹配的收款将记入暂记账户（suspense account），而不是被强行关联到发票上，这在解决之前是可见的且刻意不适的。
非公司本位币的结算款无需人工处理即可入账。日记账以本位币记账：批次按其入账日期的汇率进行换算，应收款按每张发票开具时的汇率进行冲销，这两种汇率之间的残差作为实现的汇兑损益入账。唯一仍然会被拒绝的情况是单笔结算款的明细行混合了多种币种。
已入账的批次与真实银行账户中的入账银行流水行进行关联。在“银行 → 匹配”规则（Bank → Match rules）下，您可以描述结算款在对账单上的显示方式：流水行始终包含的文本，以及其中结算 ID 的可选前缀。导入对账单时，符合规则的行将通过结算 ID 附着到其批次，或者通过在您设置的时间窗口内匹配批次净总额来实现。随后，银行流水行将承载结算的日记账分录，而无需等待第二次重复入账，并且 POST /v1/bank/settlements/link 和 /unlink 可以手动设置或更正链接。
最佳实践
- 按结算批次对账，而不是按月对账。 结算款是天然的单元；在对账前聚合一个月的结算款会破坏使错误易于发现的恒等检查。
- 切勿将净额作为收入入账。 这是平台会计中最常见的错误：将 9,712.40 欧元的收入入账会同时低估销售额和费用、破坏毛利率，通常还会低估增值税，因为增值税是按客户支付的总额计算的，而不是按 PSP 转发的金额计算的。
- 注意时间差。 6 月 30 日收取的款项于 7 月 3 日结清，属于 6 月的收入和 7 月的现金。在期末，差额表现为对 PSP 的应收款，这是在他方账户中的真实资金。
- 将退款与原始销售进行对账。 未能追溯链接的退款会使已结清的发票看起来已支付，并导致收入被高估。
FAQ
支付对账和银行对账有什么区别？
银行对账是将总账与银行对账单进行逐行比对。支付对账则提前了一个层级：它将单笔 PSP 结算款拆解为背后的多笔收费、退款和手续费，从而使这些银行流水行能够得到解释。
为什么我的 Stripe 结算款对不上销售额？
因为结算款是一个净额批次：总收费减去手续费、退款、拒付以及任何保证金，并按照 PSP 的时间表而不是发票的日期进行结算。必须对其中的每一个组成部分进行单独核算，这两个数字才能相符。
PSP 手续费应该从收入中抵扣吗？
不应该。收入是客户支付的总金额；PSP 手续费是收取该款项的费用。将它们抵扣会同时低估收入和成本、扭曲利润率，并且通常会导致增值税处理错误。
如何处理多边市场的分润？
平台的收入是其佣金；卖者的份额在结清之前属于负债。将整个结算款作为收入入账会极大地虚增平台的收入，设置佣金收入和卖家应付款的独立入账规则正是为了将它们分离开来。
未匹配的结算行会怎样？
它们会记入暂记账户（suspense account），而不是被强行关联到发票上。这可以保持总账平衡并使问题可见；暂记账户余额是一个待办清单，应当在期末结账前清零。