Stripe Connect 市场平台会计工作流
一本面向实务操作人员的指南，教你如何将收款、手续费、转账、退款、争议和准备金记入能够清晰对账的市场平台总账中。
大多数市场平台会计问题的根源都在于同一个错误：把 Stripe 银行打款（payout）当作收入来处理。打款金额是由几十笔独立的经济活动轧差后净得的余额，如果把它作为单一收入科目入账，就会抹去平台的佣金、卖家的应付款项，以及夹杂其中的各项手续费和争议款。正确的业务流程应当在任何款项触及总账之前，先将打款拆解还原。
本指南将各个 Stripe Connect 余额交易（balance-transaction）类别归入其对应的会计科目：应收款项、佣金收入、卖家负债、处理费用和暂记科目（suspense）。它以 Nordlet 有据可查的导入和结算端点作为记账机制，包含一个完整的结算示例，并在文末提供了一份可在每次结账前运行的对账检查清单。
在设计任何方案前先确定 Connect 收款模型
在明确每个支付流程采用哪种收款模型之前，会计规则是无法编写的。该模型决定了哪一方的 Stripe 余额承载收款、哪一方承担手续费，以及退款和争议最先冲击哪里。
| Connect 模型 | 收款创建方 | 承担 Stripe 手续费 | 退款/争议冲减对象 | 会计后果 |
|---|---|---|---|---|
| 直连收款 (Direct charges) | 关联账户 | 各方可配置 | 关联账户余额 | 平台将应用费（application fee）记录为收入；卖家的收款活动主要记在关联账户总账上 |
| 目标收款 (Destination charges) | 平台，并立即转账到一个关联账户 | 平台 | 平台 | 平台记录客户应收款和 Stripe 手续费；卖家份额属于应付款而非收入 |
| 独立收款与转账 (Separate charges and transfers) | 平台收款，随后进行一次或多次独立转账 | 平台 | 平台 | 收款和卖家转账是独立事件；卖家负债独立于客户收款进行跟踪 |
Stripe 关于 Connect 集成中收款运作方式的官方指南证实，对于目标收款以及独立收款与转账，平台余额承载支付手续费、退款和退单（chargeback）。对于直连收款，关联账户接收收款，手续费可以从任一方扣除。
实务原则：在写清各个流程的收款模型之前，切勿妄下定论说“Stripe 打款就是卖家收入”或“卖家支付手续费”。将该模型与每笔交易一并存储。在统一的记账规则下混用直连收款和目标收款，是导致收入和负债错报的最快途径。
本指南假定采用目标收款或独立收款与转账，因为这两种模式下平台余额承担主要的会计权重，也是绝大多数市场平台总账的构建基础。
在导入单行数据前先绘制资金流向图
在触碰任何导入操作之前，为每个流程绘制一张单页交易图：
客户付款
-> Stripe 收款 / 支付余额交易
-> Stripe 手续费
-> 平台应用费（佣金）
-> 转账至关联账户
-> 退款或争议（如适用）
-> Stripe 打款
-> 银行收款
每一个箭头都是一笔独立的余额交易，拥有自己的 ID、类别、金额和日期。应当将 Stripe 余额视为一个类似银行的清算账户（clearing account）：收款流入，手续费和转账流出，打款则将剩余资金转移到真实的银行账户中。Nordlet 的银行与支付导入文档针对常规的 Stripe 活动正是推荐这种处理方式。
选择正确的 Stripe 源报表
对于自动打款结算批次，请使用 Stripe 的打款对账明细（Payout reconciliation, itemized）报表。它为每笔余额交易提供一行数据，按 reporting_category 对行进行分组，将每行与一个 automatic_payout_id 关联，并提供总额、手续费和净额合计。Stripe 的报表选择指南记录了该报表，并确认 charge_id、connected_account_id 和 destination_payment_id 是可用的 Connect 字段。
在未启用自动打款的场景下（某些手动打款安排），请改用余额（Balance）报表。不要将仪表盘（Dashboard）的打款汇总视为入账的充分证据。汇总只能证明批次总额；唯有明细报表才能解释其组成部分。
Stripe 建议按 reporting_category（报告类别）而不是较旧的 type（类型）字段进行分类，并且每行都带有链接到底层对象的 source ID。请注意时间约束：Stripe 声明日常报表数据通常在次日中午前可用，且即时打款无法清晰分配到单笔交易，因此需要进行单独的交易历史对账。
按类别对每笔余额交易进行分类
将 reporting_category 作为主要分类依据，随后检查 source_id、charge_id 和描述。核心映射关系如下：
| Stripe 活动 | 报告类别 (reporting_category) | 会计解读 |
|---|---|---|
| 客户收款、银行卡或本地支付方式 | charge |
客户出资的应收款或销售结算 |
| 退款 | refund |
冲销原客户付款 |
| Stripe 扣留的处理费 | fee |
支付处理费用 |
| 平台应用费 | platform_earning |
佣金收入 |
| 退还的应用费 | platform_earning_refund |
冲减佣金收入 |
| 转账至关联账户 | transfer |
冲减卖家负债 |
| 冲销转账 | transfer_reversal |
从关联账户追回资金 |
| 退单 | dispute |
退单损失；检查源争议对象 |
| 退单胜诉或冲销 | dispute_reversal |
收回先前已入账的退单 |
| 打款至银行 | payout |
银行资金变动，非收入 |
| 冲销打款 | payout_reversal |
资金退回 Stripe 余额 |
| 扣留准备金 | connect_reserved_funds / risk_reserved_funds |
受限制资金，默认情况下不是费用 |
| 长期未结清的负余额追收 | connect_collection_transfer |
需要风险政策支持的资金注入或追回事件 |
术语警示：较旧的余额交易 type 字段对相同的事件使用不同的标签，其中包括 payment、application_fee 和 adjustment。Stripe 的余额交易类型文档列出了这两种词汇体系。切勿将 type 值混入 reporting_category 规则中，也不要凭空发明 Stripe 未导出的类别（例如 dispute_loss）。如果导出的数据带有你不认识的标签，请保留导出的值，并针对源对象进行核实。
将正常的市场平台活动记入总账
对于采用目标收款或独立收款与转账的平台而言，概念上的分录如下。
客户收款（客户资金进入 Stripe 清算余额）：
借：Stripe 清算账户 客户收款总额
贷：应收账款 客户收款总额
Stripe 处理费：
借：Stripe 手续费支出 Stripe 手续费
贷：Stripe 清算账户 Stripe 手续费
除非你的会计政策明确要求并支持净额列报，否则切勿将 Stripe 手续费与收入进行净额抵扣。
平台佣金（你的收入，从本应属于卖家的款项中扣除）：
借：应付卖家款项 佣金金额
贷：佣金收入 佣金金额
卖家转账（结算应付款项，而非费用）：
借：应付卖家款项 转账金额
贷：Stripe 清算账户 转账金额
转账绝不会自动成为费用。当收款落地时，卖家的份额即转化为负债，而转账则清偿了该负债。Nordlet 的结算记账规则遵循此逻辑：platform_earning 行记入佣金收入，而 transfer 行冲减卖家负债。文档记录的默认记账键为 settlements.commissionRevenue（默认 5001）、settlements.sellerPayable（默认 4499）、settlements.fees（默认 6800）和 settlements.suspense（默认 4440），每个公司均可通过 Nordlet API 中的记账规则进行覆盖。
处理退款应针对原始销售，而非作为零散的银行项目
退款链接到原始收款或发票。从概念上讲：
借：退款 / 销售冲销 退款金额
贷：应收账款 退款金额
实际的分录取决于销售是否已确认、是否必须冲销税款，以及是否退还了平台应用费。单笔退款可能会产生应收款冲销、税款冲销、应用费退还、转账冲销或卖家应付款减少，以及必须核对而非假设的 Stripe 手续费影响。
时间陷阱：退款通常在比原始收款更晚的打款批次中结算。相比于从收款级别导出数据再综合生成的退款，更宜采用明细打款对账报表。Nordlet 的文档明确警告称，当退款在后期结算时，从支付（Payments) 导出数据合成的退款只是一种近似值。结算导入程序可以提取退款行，将其与原始销售进行匹配，并在批次过账时冲销应收款。
将争议与退款分开处理
争议是持卡人或发卡行的索赔，Stripe 可能会在裁决前同时扣除争议金额和争议处理费。对于目标收款以及独立收款与转账，Stripe 会根据其退款与争议指南从平台余额中扣除这两笔款项。平台可以通过冲销卖家转账来尝试追回资金。
从平台的角度来看，败诉的争议分录：
借：退单损失 / 重开应收款 争议金额
借：争议手续费支出 争议手续费
贷：Stripe 清算账户 合并金额
如果由卖家承担损失且追回已确认：
借：应付卖家款项 / 追回账户 可追回金额
贷：退单追回收入 可追回金额
切勿仅仅因为请求了转账冲销就盲目记账卖家追回。必须核实该冲销已经创建、成功执行，并出现在 Stripe 余额中。如果争议胜诉，Stripe 会通过 dispute_reversal 行退还争议金额；此时应冲销退单损失，并单独处理 Stripe 未退还的任何争议手续费。Nordlet 会使用先前已匹配的同文件或更早导入的收款的 charge_id 来匹配退单行。
结算工作示例
以一个自动打款批次为例。明细报表包含：
- 一行
charge：总额 100.00，Stripe 手续费 3.20，净额 96.80 - 一行
platform_earning：15.00，平台佣金 - 一行
transfer：81.80 至关联卖家 - 一行来自早期销售的
refund：总额 20.00，在本批次中结算 - 一行
payout：转入银行的批次总额
根据 Stripe 的结算恒等式，打款构成如下：
收款总额 100.00
- 退款 20.00
- Stripe 手续费 3.20
- 转账 81.80
= 平台余额净额 -5.00
platform_earning 行不会二次转移资金。它标明了在扣除手续费和卖家转账后，留在平台余额中的 15.00 金额，从而使平台能够确认佣金收入，而不是靠推测得出。
在此示例中，卖家转账加上退款超过了净收款活动，因此批次合计为微小的负数，并会缩减下一次打款或动用余额。已过账的凭证冲销了退还的应收款、确认了 15.00 的佣金收入、记录了 3.20 的手续费支出、通过转账金额减少了卖家应付款，并记入了退款冲销。银行账单行与到达账户的净额相吻合。没有任何单一数字等于“收入”，这正是核心所在。
通过 Nordlet 的结算端点导入并过账
对于打款级别的对账，请使用：
POST /v1/bank/settlements/import
传入 Stripe 提供程序和明细 CSV。Nordlet 按 automatic_payout_id 对行进行分组，将每次打款转化为包含总额、手续费和净额合计的结算批次，跳过已过账打款的重复导入，从结算构成中跳过 payout 行，并使用订单、发票、PaymentIntent、charge、source 或 metadata 引用自动匹配收款、退款和争议行。Stripe 会将明细报表拆分为每个部分一个文件，因此请将收款、退款和手续费文件一起导入：属于已导入但尚未过账的打款的行将合并到现有批次中。这是一个由文件和结算端点驱动的导入并过账工作流，而非实时的 Stripe 连接器；功能页面列出了银行和结算端所涵盖的内容。
按此顺序匹配：将收款匹配至发票、将退款匹配至原收款、将争议匹配至原收款、将佣金行匹配至佣金处理逻辑。将 Stripe 手续费、调整项、准备金和打款行排除在发票匹配之外。Nordlet 的支付对账词汇表指出，费率和调整行设计上无法与发票相匹配；请将未解析的含金钱项目路由至暂记科目。手动更正则使用 bank/settlements/match { lineId, invoiceId }, 传入 null 的 invoiceId 则可取消匹配。
随后过账一个平衡的批次：
POST /v1/bank/settlements/post
这会创建一个平衡的凭证、结算已匹配的发票、借记银行账户的 ledger 账户以记录净打款额、借记手续费、贷记收款的应收款、为退款和退单冲销应收款、在提供 commissionPercent 时将未匹配的市场平台收款拆分在佣金收入与应付卖家款项之间，并将未解析的金额发送至暂记科目。它无法识别的任何类别也会落入暂记科目，且响应会在警告中列出这些类别，而不是默默吞掉它们。
对账检查清单
在每次结账前运行以下断言验证：
- 没有重复的
balance_transaction_id - 没有重复的
(provider, payout_id)结算批次 - 行
net的总和等于批次净额 - 批次净额等于银行打款额（受时间和汇率政策约束）
- 每笔退款都有原收款或已记录的例外情况
- 每笔争议都有争议或退单引用
- 每笔转账都有关联账户 ID
- 每笔
platform_earning行都有明确的佣金处理方式 - 暂记科目为零或经过充分审查，包括过账警告中指出的任何无法识别的类别
- 在没有批准的垫支或追回政策的情况下，卖家应付款不应为负数
- 已过账的批次不能被默默地重复导入或重复过账
- 非公司本位币的打款按打款日汇率进行折算，与每张发票自身汇率的差额计入已实现汇兑损益；混合多种货币的打款将在导入时被拒绝
在三个级别进行对账：行级（每笔交易都有保留的 ID、类别、金额、货币、来源）、打款级（明细净额等于 Stripe 打款和银行收款）以及总账级（已过账的凭证保持平衡，并产生预期的收入、手续费、应收款、卖家负债和暂记科目仓位）。特别针对卖家余额，应核实期初卖家应付款加上新增卖家份额，减去转账和有效的冲销后，等于期末卖家应付款。
所有市场平台总账中反复出现的失败都是同一个：将结构化的打款折叠成单一数字。保持组件分离，将每个组件锚定到一个稳定的 Stripe 标识符，并让暂记科目容纳任何你尚无法解释的内容。干净的结账结果才是审计人员信赖的基石。
FAQ
Stripe 打款是平台的收入吗？
不是。打款是恰好在同一批次中结算的收款、退款、处理费、卖家转账、争议和调整项的净额。把它作为单一的收入科目入账，会抹去其中的卖家负债和处理费用。对于代理制市场平台，收入是佣金，这由 platform_earning 行来标识。
我应该与哪份 Stripe 报表进行对账？
应当使用打款对账明细（Payout reconciliation, itemized）报表，因为它为每笔余额交易提供了一行数据，包含 reporting_category、automatic_payout_id 以及总额、手续费和净额。仪表盘打款汇总只能证明批次总额。在未启用自动打款的地方，请改用余额报表。
转账给卖家的款项应该记为费用吗？
不应该。当客户收款落地时，卖家的份额即转化为负债，而转账则清偿了该负债。将转账记为费用会重复计算成本，并导致卖家应付款被永久高估。
导入程序无法识别类别的 Stripe 行会怎样？
它会过账到结算暂记科目（默认 4440），并且过账响应会返回警告，列出流向该处的类别。准备金和不寻常的调整通常会以这种方式落入其中，这是刻意为之的：资金保持可见，凭证保持平衡，直到有人决定它到底属于哪里。
在后续打款批次中结算的退款如何处理？
它们作为 refund 行出现在后期打款的明细报表中，并通过先前已匹配收款的 charge_id 追溯匹配回原始收款。在这种情况下，从收款级别支付导出数据合成的退款只是一种近似值，因此明细报表是更安全的来源。