账单出了，钱还没到：平台在途资金的 4 个时间点与 3 张表

摘要：月底对完账，数字都对，可银行账户里的钱还没到。老板问「这个月到底能付多少工资」，财务答不上来——因为账单总额、本月收入、本月可用现金是三个不同的数，混成一个数就必然吵架。这篇把平台的钱拆成 4 个时间点、3 张表，讲清每个时间点该记什么、账期按哪个日期归属、提现划转为什么不该进对账，以及暂估应收与财务应收为什么必须分成两张。 关键词：资金在途、账期归属、结算周期、暂估应收、失败行结转、多表勾稽

一、账单总额、本月收入、本月可用现金

一个很常见的场景：财务把 15 个平台的账单都对完了，差异几乎为零，报告发给老板。老板回了一句「那这个月我能付多少工资」。

财务愣住了。账单总额能算出来，本月收入能算出来，但「本月可用现金」算不出来——因为平台的钱还在路上。

问题出在把三个数当成一个数：

前两个数是「权」，第三个数是「钱」。它们既不相等，也没有固定比例。跨境平台隔着一层汇率和提现通道，国内平台扣着结算周期，一笔货从卖出去到现金落袋，中间要穿过四个时间点。

时间点一，业务发生。 买家下单、平台收款、货发出去。这是业务事实，财务开始挂应收。

时间点二，平台结算。 平台把这一轮该结的钱算完，锁定结算金额。这一刻金额才最终确定，才谈得上账期归属。

时间点三，账单出具。 平台把结算结果以表格形式给商家。这一刻你才拿到原始凭证。

时间点四，资金到账。 钱从平台账户转到你的银行账户，跨境还要再经过换汇与提现通道。

四个时间点之间可以差一天，也可以差一个多月。平台结算周期长、跨境回款慢、提现通道拥堵，都会把这段拉长。财务的难处不在算钱，在于这四个时间点分属四套记录：业务系统一套、平台账单一套、ERP 一套、银行一套。

二、3 张表，各管一段

把四个时间点映射到账上，通常是三张表。

应收表记的是「已经发生、但钱还没结算」。它由业务事实和暂估应收构成，金额来自平台账单里的结算额，或者尚未出账时的估算额。

在途表记的是「平台已经结算、但钱还没到你账上」。这一段最容易被忽略，因为平台账单里这一行通常长得像费用——提现、转账、保证金划扣。实际上它是资金位置的变化，不是损益。抖店的提现按出账记在费用侧，支付宝账户流水里的记账本转账、保证金出账缴存则按财务手工口径记成负收入，代表数是 −185.07、−1,212.57、−2,481.83。

这一段最关键的一条纪律是：资金划转不进对账。一旦让提现进了收入或费用对账，同一笔钱会在平台侧被算一次、在你这边被算一次，差异凭空冒出来，而且两边都觉得是对方错了。判断依据是业务类型：转账、提现、保证金这类行，业务类型归到「其他」，不进任何一份对账计划。

在轻易云的口径里，这类行的归属是写死的：转账、提现、保证金归「其他」，利息收入也在解析侧就挂到「其他」，不进费用聚合；佣金、平台服务费、物流费这类带订单号的才是订单费用，营销、广告、仓储这类没订单号的才进费用池分摊。规则一旦定死，跨平台搬过来的新场景才有地方放，财务要讨论的就不再是「这行算不算费用」，而是「它归哪个池子」。

已收表记的是银行流水，和应收表一比就知道还差多少。这张表的价值不在记账，在于回答「我这笔钱什么时候能动用」。

三张表的关系是：应收减去在途，等于已收加未收。一家做 15 个平台的公司，任何一个平台的任一店铺都能单独跑出这三条线，才谈得上资金头寸。

三、账期到底按哪一天

既然有四个时间点，「这笔钱算哪个月」就必须有明确答案。答案不是记账月，也不是订单日期，而是平台结算的时间。

微信小店（视频号）的规则最典型：货款在平台结算后才入账，归属期不能只看记账月。系统用第二张账单——订单流水——作为结算状态的快照维表，这张表金额恒为零、对账状态恒为「无需参与」，专门用来回答「这单结算了没有、什么时候结算的」。

归属规则是四支：

• 已结算、部分结算、待结算 → 按商家货款结算时间所在月归属。
• 无需结算 → 归属期置空，不入账。典型场景是结算前已全额退款、货款收付互抵。
• 查不到这单、也没有结算时间 → 归属期置空，不入账。
• 达人佣金、技术服务费、运费险、提现这几类 → 按记账月直接归属，不参与快照判定。

「归属期置空不入账」这一条，是很多团队对不上的根源：钱明明在账单里，就是不进账。不是漏了，是按规则这一笔本期不该进。

还有一类差异来自账单到晚了。上期有一批单，平台账单这个月才出，对账时它不在上期的账单范围里。处理办法不是硬塞进上期，而是走失败行结转：跨期结转的判定条件是这一行的归属期早于本期计划的起始账期；同账期内，本期选了某些账单、没选某些账单，未选中账单里的失败行同样可以结转过来。

结转之后，这一行会在新账期里重新出现，归属期统一取本期账期，但原始来源留着。所以到了下个月，你不会看到一笔凭空多出来的收入，只会看到一条从上月带过来的待处理项。轻易云把这套准入规则写成一行硬条件而不是一句建议，是为了避免同一个订单在两期里各挂一次失败——那种重复最容易在月末做汇总时被当成两笔真实的业务。

四、创建对账计划这一步，选错账单就全错

时间点讲完，回到操作层：建一个对账计划的第一步是选数据源账单。选对了，剩下的事情才有意义；选错了，后面全是返工。

一个店铺往往有多张账单。京东 POP 一个店铺要三份——结算账单、账户流水、营销对账，聚合到一个收入对账计划里。支付宝是三类——资金流水、聚合结算账户流水、余利宝明细。亚马逊是交易明细加资金明细两张。速卖通有 6 类账单类型。独立站的收款通道更多，PayPal、Stripe、空中云汇各一张。

所以「多表勾稽」是主流形态而不是特例。它的难处在于：不同账单的行含义不同、金额口径不同、粒度不同，强行拉平就会出现字段缺失和类型不一致。正确的做法是每张表各自解析成标准行，再按业务订单号聚合。

向导里这一格有个容易忽略的语义：不选，等于聚合该店铺本期全部账单。财务赶时间时习惯性跳过，结果把一张本该下期处理的营销对账表拖进本期，账期归属直接错位。选与不选都是动作，区别只在有没有意识到。

容易出错的还有跨周期选账单。选与不选决定了哪些行能进本期、哪些行会以结转的方式进来：归属期早于本期起始账期的失败行会跨期结转，本期选了部分账单时，没被选中账单里的失败行同样会结转；而已对账成功、尚未确认的行不进入任何新计划，成功行独占原计划。规则写死成什么样，取决于你们想让链路是可追溯的单一出处，还是允许同一笔在两期里各出现一次。

五、暂估应收和财务应收，是同一笔钱的两张脸

资金在途这件事落到 ERP 上，会分裂成两张单据，很多团队在这里卡住。

暂估应收发生在业务确认时点：货发了、订单成立了，会计上需要先挂一笔应收，金额是业务口径的结算额。财务应收发生在结算或开票时点，金额是会计口径的金额。两者的差额，就是月末真正要对的东西。

不能合并成一张，合并的后果是：要么丢掉业务时点的确认，要么让会计口径去迁就业务口径。前者影响期间损益，后者影响税务申报。实务里还有一条硬约束——财务应收单不能直接新建保存，账套会拒绝，提示「立账类型财务应收单只能通过暂估应收下推」。立账类型一共三个取值：业务应收、暂估应收、财务应收。

于是流程变成：暂估应收先挂，账单到了、差异归因完了、暂估下推财务应收，两者的差额按差异标签生成费用应收单或应付单。校验标准只有一条，不能松：财务应收加费用应收（带符号）等于账单净额。

但这里埋着一个时差坑：单据审核和入账不是实时的。业务发生、单据生成、财务审核，中间可能隔几小时到几天。如果按「对账当天」去拉，晚到的单据永远漏。解法是给拉取设一个回看窗口，不只看本期，还回看最近一段时间的变动。窗口不是越长越好，太长会带来重复拉取和性能负担。

轻易云在这段的做法是把窗口和去重一起做：拉取时只取已审核状态的单据，回看窗口覆盖最近 72 小时，已下推过的单据按本地标记排除，不会推第二次。窗口、回看范围、排除条件三项写在一起，才不会出现「昨天推过的单子今天又推一遍、账上多出一张应收」这种事。配合去重标记，已经下推过的单据会被排除，不会推第二次。

六、三个出口，把钱送到位

资金在途的账，最容易变成「所有人都知道有问题、但没人动」的状态。原因是没有出口。

实际推进时，一笔暂估到财务应收要走三道闸：出单前可核对单据内容、推送失败可按行重推、已推送的单据可以重开为已确认后重新推送。回写本地净额防重复下推这一步很关键——它保证「同一笔钱只被推一次」，而推送日志保留了每次请求的原始响应和报错原文，出问题时能查到是哪一次、卡在哪一字段。

这三个出口的意义是：资金在途的账不必等到期末才处理。已结算的批次当天推当天走，在途余额随账单更新而更新，账上的钱和银行里的钱之间始终有一条能对上的路径。

七、这个月就能做的三件事

第一，画出你这个月四个时间点的实际间隔。从订单发货到钱到银行，逐个平台写下来。间隔最长的那个平台，就是你资金头寸最紧的地方，也是最该和平台谈账期的那个。

第二，把提现、划转、保证金这些行从对账口径里单拎出来。它们不是费用，是资金搬家。单拎出来，差异率会立刻变得好看，而且好看是真的。

第三，给暂估应收和财务应收各留一列差额。两张单据并排放，差额等于多少，一眼就能看出这个月的结算口径有没有变。别等到凭证生成后才发现差在哪儿。