Shopee、TikTok Shop 与 Stripe 净额结算银行对账：MDR 手续费与入账延迟处理指南

先拆销售总额与银行净额，不要硬找一对一交易

Shopee、TikTok Shop 或 Stripe 的结算通常是批次对账，不是在银行流水中寻找一笔金额相同的订单。财会人员必须根据平台或支付网关的正式报表证明以下公式：

批次销售总额
− 客户退款与冲销
− MDR、网关、佣金及其他有报表依据的费用
± 有报表依据的调整
= 银行收到的净额

MDR 是商家折扣率或收单手续费，属于商业收费，并非马来西亚法定费率。不能沿用上一个批次的百分比，也不能因为差额看起来像手续费就自行补数；每次都应采用该结算报表实际列明的金额。Shopee、TikTok Shop 与 Stripe 的报表格式和交易标签可能不同，企业可以建立统一的内部对账表，但不能假设三个平台的原始栏位完全一样。

假设一个结算批次有 RM10,000 销售，没有退款，平台报表列明 RM300 手续费，银行最终收到 RM9,700：

批次项目	金额（RM）	核对证据
销售总额	10,000.00	与批次相连的订单明细合计
减：MDR 或网关手续费	(300.00)	结算报表的实际费用行
银行净额	9,700.00	出款报表与银行贷记

RM300 不是客户少付，也不是不明差额，而是平台在汇款前代扣的费用。若银行对账只寻找 RM10,000，这笔净额永远无法匹配；若直接把 RM9,700 当销售收入，则会同时低估销售和手续费。

净额结算应该怎样做复式分录？

正确分录取决于销售总额是否已经入账。GetPay 预设账目表内，与这个流程有关的惯例包括：

• 1200 Accounts Receivable，应收账款；
• 4200 Sales Revenue，销售收入；
• 6100 Bank Charges，BANK_FEE 类别会映射至这个费用科目；以及
• 已映射的银行科目，例如 1110 Public Bank、1120 UOB、1130 Maybank、1140 BSN 或 1150 CIMB。

若订单或发票在结算前已经确认销售，第一笔分录是：

总账科目	借记（RM）	贷记（RM）
1200 Accounts Receivable	10,000.00	—
4200 Sales Revenue	—	10,000.00

当 RM9,700 真正进入银行，而且结算报表证明 RM300 是手续费，就以总额清掉应收：

总账科目	借记（RM）	贷记（RM）
对应银行科目	9,700.00	—
6100 Bank Charges	300.00	—
1200 Accounts Receivable	—	10,000.00
合计	10,000.00	10,000.00

这个做法保留完整销售额，让手续费在损益表中清楚呈现，同时清掉销售时产生的同一笔总额应收。

如果企业没有在订单层面记录收入，有些账务流程会采用合并分录：

借：银行（净额）
借：手续费费用
    贷：销售收入（总额）

只有在这项做法符合企业收入确认政策，而且不会与订单层面的销售重复时才可采用。若订单已贷记 4200，出款时再次贷记销售会导致收入重复。企业若需要专用的平台清算科目，应在自己的账目表中正式建立并记录政策；本次核对的 GetPay 程序文件没有定义 Shopee、TikTok Shop、Stripe 或通用“支付网关清算”科目代码，因此不能虚构一个号码。

为什么多张订单最后只形成一笔银行入账？

电商平台或支付网关在一个结算周期内收取多名客户的款项，再把应付商家的余额合并汇出。批次可能横跨不同订单日，平台完成结算后，银行也可能隔几天才显示款项。实际关系通常是一对多：

一笔银行贷记
      ↓
一个出款或结算批次
      ↓
多张订单、退款、手续费与调整

银行流水是最终现金证据，却不是完整销售明细。它可以证明价值日、金额、参考资料和交易说明，但单凭一行银行资料，无法证明批次包含哪些订单、退款和费用。

内部标准化的批次表至少应有：

• batch_id：平台或网关可长期追踪的出款编号；
• order_id：纳入该批次的每张订单或每笔交易；
• transaction_type：销售、退款、费用、拒付、暂扣或调整，但只能采用报表确实支持的分类；
• order_date、settlement_date、payout_date 与 bank_value_date；
• gross_sales、refunds、fees、adjustments 与 net_payout；
• currency；以及
• 原始文件名称或报表期间。

这些是企业自行控制的对账栏位，不代表三个服务商都会输出同名标题。标准化之后仍须保存原始报表，确保下一位会计人员能够从源文件重做每一步转换。

电商结算报表应该按什么步骤核对？

1. 先冻结同一批报表

下载同一范围的订单或余额活动明细，以及结算或出款报表。记录导出时间、商家账号、币种、期间和文件名称。不能一边更新订单报表，一边拿旧版本出款报表对账，否则新增交易会令两边人口范围不同。

2. 先找批次编号，再看银行金额

优先使用服务商提供的 payout、settlement 或 transfer 编号，把相关销售、退款、费用和调整归入同一批。若交易尚未取得最终出款编号，就把它列入未结算滚存表，不要自行编造批次身份。

3. 只统一一次正负号

一种清楚做法是：销售总额存正数，退款和费用存为正数扣减栏，其他调整则采用一个有说明的正负规则：

gross_sales - refunds - fees + signed_adjustments = net_payout

若平台原始文件把手续费显示为负数，可以全程保留原始符号，也可以转换成正数扣减栏，但只能转换一次。先保留负数、计算时又再减一次，会令批次差额刚好变成手续费的两倍。

4. 先证明订单明细等于批次销售总额

把分配至该批次的订单行加总，再与报表的销售总额比较。差异可能来自重复订单、已取消订单、部分退款、币种不同或筛选期间不一致。银行净额不能当作填平差额的倒算数字。

5. 每项扣减都要有报表证据

逐项核对费用、退款、拒付、暂扣、物流相关款项、费用税或其他调整。不是每个平台、每个批次都会出现所有项目；同时，空白栏也不一定代表零，必须确认报表没有被筛选、分页遗漏或截短。

6. 公式平衡后才匹配银行

只有当销售总额转净额的公式完全成立，才把 net_payout 与银行贷记核对。检查金额、币种、银行价值日、交易说明、参考号码和一般到账时差。日期不同可能只是时间差；金额不同则必须有报表支持的解释。

7. 入账并保留双向审计轨迹

分录只记一次，并把批次表和源文件连接至该银行交易。复核者应能从银行贷记追到批次和订单，也能从任何订单反向追到批次与最终银行入账。

GetPay 实际会提出和确认什么？

GetPay 目前的结算匹配器读取银行交易的真实字段：date、amount、ref、description、bank 和 txn_type。系统用这些资料比较仍未收清的发票字段：invoice_id、invoice_number、customer_name、total、outstanding 和 status。

只有明确标记为贷记的银行行才会进入应收匹配。借记、空白 txn_type 或无法识别的方向都会被跳过，系统不会把不确定交易擅自当作客户付款。匹配器按照证据强弱提出三种候选：

匹配层级	程序实际检查	分数
exact_ref	ref 或 description 出现完整发票号码，并防止号码尾端误碰	1.0
amount_party	银行金额等于发票未收余额，并与客户名称至少一个有效词相符	0.7
amount_only	银行金额等于发票未收余额，但没有客户名称佐证	0.4

无论分数多高，结果都只是建议。这个纯匹配程序不会自动写入总账，也不会自动把发票标成已付款。

确认时必须提供 candidate_id、正整数 expected_version 和非空白的 adjudicated_by；也可用 bank_account_id 明确指定收款银行。若银行账户无法确认，或该账户被标记为跨实体账户，确认流程会拒绝入账。程序也会检查付款日是否落在开放会计期间。

若候选只有一张发票，记录金额最多只能达到该发票的未收余额，不能制造超额付款。若候选有多张发票，它们的 outstanding 合计必须在半仙误差范围内等于银行贷记，否则系统会把它视为含糊分配并拒绝确认。付款一律通过正式的发票付款路线记录，并使用可重复计算的幂等键，避免重试时有意外的第二笔结算。

这项限制正是净额电商对账的重点。若发票总额是 RM10,000，而平台扣除 RM300 后银行只收到 RM9,700，目前的多发票确认流程不会猜测 RM300 是手续费。财会人员必须先完成总额转净额的拆解，并采用有依据的费用处理；不能修改发票余额，只为了让候选通过。

月底尚未到账的结算批次怎样处理？

必须分开保存四个日期：

日期	回答的会计问题
订单日或销售日	按企业会计政策，基础交易在什么时候发生？
结算日	平台何时把相关活动组成应付商家的批次？
出款日	平台何时发起或申报转账？
银行价值日	现金何时真正出现在企业银行账户？

例如，符合收入确认政策的 RM10,000 八月份销售已经在 8 月 31 日前发生，平台于 9 月 1 日完成结算，RM9,700 则在 9 月 3 日进入银行。八月份不能因为九月才收款就漏记销售；相关平台应收或清算余额必须跨月保留。

月底应编制滚存表：

期初未结算平台应收
+ 本期已确认销售总额
− 本期已确认退款与费用扣减
− 银行已收到的出款
± 有依据的调整
= 期末未结算平台应收

另外按批次编号列出在途项目、币种、金额、结算状态和预计收款银行。下个月只能根据实际银行贷记和正式结算报表清掉余额。迟到的出款属于时间差；无法解释的金额则是对账异常，两者不能混为一谈。

哪些异常绝对不能强行对平？

银行净额低于出款报表

检查币种转换、分拆出款、银行费用、暂扣，以及所用报表是否已经最终确定。只有可靠证据列明的项目才能入账，不能随意建立一行“MDR”来填平批次。

两个批次金额完全相同

金额不是长期身份。应结合批次编号、银行参考、日期、服务商账号和币种。GetPay 的 amount_only 层级分数较低，而且仍须人工或已确认代理人审核，就是因为相同金额本身不足以证明交易身份。

退款出现在后一个批次

原销售和后续退款应分别保留在各自批次的轨迹。不能因为本月报表出现冲销，就擅自改动上个月已经平衡并已出款的批次。

一笔银行入账涵盖多张发票，却扣除了手续费

多张发票未收余额会高于银行净额，因此 GetPay 目前的一对多分配理应拒绝。正确做法是根据报表记录费用并清掉总额应收，而不是修改银行金额、隐藏部分销售或把手续费当坏账。

收款银行无法确定

GetPay 会采取保守拒绝，因为系统无法确定款项是否跨越不同法律实体。应先选择已登记的收款银行，或修正银行账户设定；绝不能把一个实体收到的款项，当成另一个实体的普通客户付款来结算发票。

月底净额结算检查清单

• 把订单明细加总至批次销售总额，并抽查真实订单值，不只比较行数。
• 把退款、手续费和其他每项扣减连接至明确报表行。
• 先证明总额转净额公式，再匹配银行。
• 核对净额、币种、批次编号和到账时间是否对应同一笔银行贷记。
• 确认收入没有在订单层面和出款层面重复记录。
• 只有企业账目表和证据支持 BANK_FEE 处理时，才采用 6100。
• 月底未收到的出款继续列在应收或正式记录的清算余额。
• 从期初未结算项目滚存至期末，并调查金额内容，不能只做笔数核对。
• 保存原始报表、标准化批次表、银行行、分录和审核决定。
• 在 GetPay 中把候选视为建议；总额与净额的会计差异解决后，才进行结算确认。