轻易云首个对账计划：5 步完成收入对账

摘要：已经把京东 POP 账户流水上传到对账系统、解析也跑完了，下一步「对账」应该怎么点？本文用 5 步走完新用户的第一个收入对账计划——从「找到入口」到「整体确认 + 推送转换单据」，每个步骤都对应一个真实的按钮、一段可见的状态变化。读完这篇，你就能把一张 600 单的京东 POP 账户流水从「解析完成」变成「对账成功、推送到金蝶」，并掌握 7 态状态机、23 个 diffReason 业务标签码、整体确认与转换单据的协作方式。

关键词：轻易云、首个对账计划、5 步、收入对账、7 态状态机、双码匹配、23 个 diffReason、3 步向导、整体确认

第 0 分钟｜为什么是「5 步」

如果你已经按 9.1.3《首张账单导入：京东 POP 资金流水》走完了「后台导出 → 系统上传 → 异步解析 → 异常处理 → 沙箱试跑」，你的 220 行账户流水已经变成数据库里 220 条带业务订单号 + 核算项目 + 带符号净额的标准 BillRow。接下来要做的，就是把这 220 条 BillRow 与供应链订单按业务订单号逐单匹配、识别差异、打上 23 个 diffReason 业务标签码——这就是收入对账。

新手听到「收入对账」最容易怕的是两件事：

• 「我没写过对账脚本、对账逻辑怎么定？」
• 「对账失败怎么办？是不是要查 220 行原始 Excel？」

答案分别是：第一，这套系统内置 7 套默认对账脚本（京东 v3.4.6 / 抖店 v3.6.5 / 支付宝 v3.6.8 / 拼多多 v3.5.1 / 亚马逊 v2.0 / 视频号 v1.0.0 / 兜底 v1.4.0），覆盖了你 99% 的场景，新用户不用写一行代码；第二，对账失败不会被「重置回 0」，失败行会被 23 个业务标签码分类打标（MISSING_SUPPLY 缺单 / AMOUNT_DIFF 金额差异 / REFUND_ONLY 仅退款 / INSTANT_REFUND 极速退款 等），看一眼标签码就知道这笔订单该怎么处理。

下文 5 步走完你的第一个对账计划，每一步配一张真实截图。如果你正在打开系统，建议同步点击——5 步完成收入对账，真的就是字面意义的 5 步。

第 1 步｜找到入口：进入「收入对账管理」页

首登后系统路由到主页 /，按 9.1.2 / 9.1.3 走完「首登改密 + 首张账单导入 + 解析 100%」之后，左侧导航栏找到「对账管理」→「收入对账管理」，点进去就进入了对账计划的世界。

下面是 2026 年 9 月一份真实的列表页截图：

新用户打开这张列表时需要抓住 3 个关键信号：

1. 每条计划的命名规则都是 IRP-<平台>-<年月>-<序号>——这是 IncomeReconciliationPlan 的简称。新建计划时系统会自动按这套规则生成编号。
2. 每条计划都有 3 个核心数字：订单数（如 600 单）+ 收入合计（如 98,837.12 元）+ 差异金额（如 0.00 元）。差异金额 ≠ 0 就需要查标签码；差异 = 0 表示完美对账。
3. 右上角有一个青绿色的「开始收入对账」按钮——这是创建第一条对账计划的入口。点它弹出 3 步向导，第 2 步会细讲。

反直觉干货：列表里那些「已对账」状态（不是「已确认」），含义是「沙箱已经跑完、自动匹配完成、差异已经分类打标」，但财务还没人工确认。只有「已确认」状态（reconcile_status = CONFIRMED）才能真正锁定、推 ERP。新用户常见的误区是看到「已对账」以为完事了——其实**「对账成功」到「对账确认」之间还有第 5 步的整体确认**。

B 级干货 1｜IRP 命名规则的工程价值：IRP-<平台>-<年月>-<序号> 看似是简单的字符串拼接，实际上序号在月底会自动归零——每月 1 号创建的第一条计划永远是 IRP-JD_POP-YYYYMM-0001。这条命名规则带来的工程好处是：单凭 IRP 编号就能判断它是哪个月、哪个平台的第几条计划，对账师交接工作时看一眼编号就能拿到完整上下文（来源：轻易云 v3 重构后定稿的对账计划命名规范）。

第 2 步｜3 步向导：创建你的第一条收入对账计划

点「开始收入对账」按钮，弹出 3 步向导（基础信息 → 账期 → 预览）。下面是 2026 年 9 月一份真实的向导截图——京东 POP 某店铺、2026-07 账期、5 张数据源账单的可视化状态：

把 3 步向导拆开讲，新用户每个字段都需要填对：

第 2.1 步｜基础信息：4 个字段

填完 4 个字段点「下一步」。

第 2.2 步｜账期：YYYY-MM 单月选择

账期选择器只允许选自然月——比如 2026-07 或 2026-08，不能跨月。新用户最容易卡的是「我 7 月 25 号下的单能不能算 7 月账期？」——不能。账期对应账单月（不是订单月），由账单上的「账单日期」决定。

第 2.3 步｜预览：4 个数字决定是否继续

向导第 3 步会给你看 4 个聚合数字，这 4 个数字决定你能不能提交：

如果 4 个数字与原始账单的总计对得上，就放心点「提交」。对不上——比如「收入合计」比原始账单多了几千块——通常是「数据源账单」选多了或选少了，回到第 1 步调整。

新手冷知识：3 步向导的「下一步」按钮不会立刻触发对账任务——它只是把 IncomePlan 记录创建出来（status = PENDING），同时启动异步任务生成体行。体行生成完成后，状态自动迁移到 READY。这意味着点完「提交」之后你应该去「任务总览」看一眼，确认体行生成成功，再开始第 3 步。

第 3 步｜开始对账：7 态状态机自动迁移

向导提交完 30-60 秒，体行生成完成，状态机自动从 PENDING 迁移到 READY。这时你有两个选择：

• 直接点列表页的「开始对账」按钮（最快路径）
• 进计划详情页（推荐，能看到更多上下文）

点「开始对账」，系统做 3 件事：

1. 状态机迁移：READY → RECONCILING，触发 JobTask(type=INCOME_RECONCILE)，入 BullMQ（实现见 apps/api/src/queue/queue.constants.ts 的 income-reconcile 队列，并发数=2 避免大文件撞队列）。
2. 沙箱执行对账脚本：按平台的默认脚本（如京东 POP 用 京东 POP 收入对账 v3.4.6 默认版）跑 reconcile(input)，输入是「本计划全部 IncomePlanItem」，输出是「每条 item 的 reconcileResult（SUCCESS / FAILURE）+ diffReason（23 个业务标签码）+ diffAmount（带符号差额）」。
3. 写回双码匹配：每个 IncomePlanItem.businessOrderNo 与 SupplyOrder.businessOrderNo 匹配——命中供应链订单的成功路径写 IncomePlanMaterialItem（物料明细）+ 反向写 BillRow.reconcileStatus = RECONCILED。

下面这张状态机图把 7 态的全部迁移路径画得清清楚楚：

把图里 7 个状态拆开看，对应到新用户的实际操作：

B 级干货 2｜7 态状态机为什么这么设计：电商对账的状态比传统 ERP 多 3 个——RECONCILING（对账中）让用户看到「正在跑、不阻塞浏览器」，FAILED → RECONCILING 让失败可重跑（不丢历史），CANCELLED 让用户主动放弃并清理状态。状态机有 7 态而不是 3 态、5 态的原因是：电商对账是异步任务 + 用户确认的双阶段流程，每一步失败模式都需要单独的「可观测态」——对账师看到 RECONCILING 就知道「系统在跑，不要点」；看到 FAILED 就知道「脚本报错，要查」；看到 CONFIRMED 就知道「已锁定，不要再动」（来源：轻易云 v3 重构后定稿的 IncomePlan 7 态状态机规范）。

新用户等待沙箱跑完的 30 秒到 2 分钟是「耐心时间窗」——不要刷新页面、不要重复点「开始对账」。如果你 5 分钟后状态还在 RECONCILING，去「任务总览」查 JobTask(type=INCOME_RECONCILE) 的 status——是 RUNNING 就是在跑，是 FAILED 就是脚本报错。

第 4 步｜看对账结果：双码匹配 + 23 个 diffReason

沙箱跑完，状态迁移到 RECONCILED。这时你应该进计划详情页——这里是「对账成果可视化」的主战场。

下面是京东 POP 某店铺 2026-07 账期 600 单 / 98,837.12 元的真实详情页截图：

把这张图拆成 3 块给新用户讲：

4.1｜顶部 4 个按钮

详情页顶部的 4 个按钮对应了状态机的下一步动作：

• 【整体对账确认】：把状态从 RECONCILED 推到 CONFIRMED（终态），反向写所有 BillRow 的 reconcileStatus = CONFIRMED。
• 【重新生成转换单据】：把对账结果生成金蝶云星空的应收单（暂估应收→财务应收下推）。
• 【重新对账】：把状态从 RECONCILED 拉回 RECONCILING，沙箱重跑、diffReason 重算。重新对账会清空之前的人工处理建议字段（diffDisposalSuggestion）——这是 v3 状态机设计的安全闸。
• 【取消计划】：把状态推到 CANCELLED（终态），清理桥表 plan_source_relations、反向重置 BillRow 状态。慎用。

4.2｜聚合统计：3 个数字决定能不能确认

详情页正中央有 3 个数字：

截图里京东 POP 600 单「成 600 / 败 0 / 差异 0」——这是教科书级别的完美对账。但这只是特例，不是常态。

4.3｜体行表格 + 23 个 diffReason 速查

每行体行展示 7 列：业务订单号、本期发生金额、订单费用、公摊费用、供应金额、差异金额、对账结果（SUCCESS / FAILURE）+ 差异原因。差异原因是最关键的字段——23 个标签码让你不查代码就知道这行为什么失败。

下面是 23 个核心标签码的速查（详细解读见 9.2.4 与 2.2.8）：

B 级干货 3｜23 个 diffReason 的机读 + 人读双轨设计：每个标签码都对应「机器可识别的差异原因 + 业务可读的处理建议」。比如 MARKETING_COUPON_DIFF 的差异金额 = 自营合计 − 立减合计的差值，机器直接调转换规则出费用应收单；业务人员看到标签就知道「这行差异来自券」。23 个标签码让 AI Agent 可以直接消费差异字段——AI 不需要理解每一笔订单的来龙去脉，只需要解析标签码就能决定怎么推 ERP（来源：轻易云 v3 重构后定稿的 diffReason 业务标签码体系）。

新手最容易忽略的是重新对账后的判定分布变化——比如京东 v3.4.6 新增的 R6-b 极速退款子档，实证 3602487005895701 这条负行从 AMOUNT_DIFF 翻成 INSTANT_REFUND、正向行 SUCCESS 正常下推——同一笔订单、对账脚本升级前后判定的差异可能就是 0.01 元。不要看到差异 ≠ 0 就立刻重对账，先看标签码。

第 5 步｜整体确认 + 推送转换单据

体行全部 SUCCESS 后，第 5 步就是「整体对账确认 + 推 ERP」——对账师的人工兜底动作。

5.1｜整体确认：状态机终态化

点详情页顶部的【整体对账确认】按钮，系统做 3 件事：

1. 状态机迁移：RECONCILILED → CONFIRMED（终态，不能再改）。
2. 反向写 BillRow：把本计划所有 BillRow 的 reconcileStatus 从 RECONCILED 推到 CONFIRMED，写 confirmedAt 时间戳。
3. 清理撤销权限：CONFIRMED 后【重新对账】按钮变成「重新对账会清空人工处理建议」，需要二次确认。

整体确认是个不可逆操作——除非先点【取消计划】把状态拉回 CANCELLED，否则对账师没办法回到 RECONCILED 状态重新调整。新手首次点确认前，建议先看一眼「处理建议」字段（diffDisposalSuggestion）是不是合理——这个字段是 2026-08-19 新增的纯文本字段，对账师可以手工补录/修改/清空，但重跑脚本只覆盖脚本返回的值，人工修改不被清空。

5.2｜推送转换单据：把对账结果推到金蝶云星空

整体确认完成后，点【重新生成转换单据】按钮，系统会按平台 + 集成方案做 3 件事：

1. 生成转换单据头 + 体行：按 IRP 编号建 1 张或多张 transform_documents，体行按核算项目 + 业务聚合拆分。
2. 推送到金蝶云星空：走集成中心 9 个 handler 中的 ar_receivable.push / ar_fin_receivable.push 等，按单据类型自动路由。
3. 回填金蝶外部单号：推送成功后，金蝶返回的 FBillNo（如 AR26091600001）回写到 transform_documents.externalBillNo。

B 级干货 4｜整体确认是「对账 → 转换」的分水岭：很多新用户以为「整体确认」就完事了，其实整体确认只是「锁定对账结果」——真正把数据推 ERP 还要再点一次「重新生成转换单据」。这两个操作分开设计的好处是：对账师可以「先批量确认、再批量推 ERP」——比如月底有 10 条 IRP 计划，可以先全部确认完，再一次性生成 10 张转换批次（每批次一个 TFB-YYYYMMDD-NNNN 编号）。

下面是收入对账完整的 5 步流程图（包含「整体确认 → 转换单据 → 推 ERP」）：

把图里 7 个环节对应到新用户的 5 步操作：

常见问题｜首个对账计划最容易踩的 5 个坑

把新用户跑首个收入对账计划时最常见的 5 个问题集中回答一遍：

Q1：向导预览时「候选行数 = 0」——是不是导入失败了？

A：不是导入失败——是导入的账单还没解析完成。向导第 3 步的候选行只取「已解析（parseStatus = PARSED）+ 账期内 + 未对账确认」的 BillRow。回到「原始账单管理」看一眼解析进度——如果进度 100% 但候选行数仍为 0，需要去「任务总览」看 ParseTask 是否成功。

Q2：开始对账后等了 5 分钟还在 RECONCILING——是不是卡住了？

A：是 JobTask(RUNNING) 状态。600 行的京东 POP 计划通常 30 秒到 2 分钟跑完；如果是 1 万 + 行的抖店或亚马逊计划，可能要 3-5 分钟。判断卡死的标志是 JobTask.errorMessage 非空——只要 errorMessage 是空，对账就在跑，不要重复点「开始对账」。

Q3：对账结果里看到 FAILURE / AMOUNT_DIFF——是不是脚本有问题？

A：不一定是脚本问题。AMOUNT_DIFF 的含义是「金额差异但没有匹配上任何已知形态的证据」——比如账单净额 = 245.04，但供应链正向净额 = 345.04（合并单多发了 100 元），既不是合并单号部分结算、也不是退货、也不是营销券，脚本就会判 AMOUNT_DIFF + FAILURE。这种情况下需要人工核对——可以点该行的【编辑对账结果】改成 SUCCESS + 填处理建议 MANUAL_CONFIRM。

Q4：整体确认按钮是灰色的——是不是权限不够？

A：通常不是权限问题，是**「还有 FAILURE 行没处理完」**。整体确认按钮的逻辑是「所有体行必须 SUCCESS 或 MANUAL_CONFIRM 才能确认」。两种处理路径：① 把 FAILURE 行用人工确认改 SUCCESS；② 重新对账，沙箱会用最新版脚本重跑，可能某些 FAILURE 行会自动转 SUCCESS。

Q5：转换单据推送失败「金蝶侧提示客户编码不存在」——怎么办？

A：是店铺主数据映射缺失。金蝶侧的「客户编码」必须先在「主数据 → 店铺」里维护好 reserved1 字段才能推送成功。解决方案：让管理员在「店铺」配置页补 reserved1 字段，重新推一次即可。这条规则的工程原因是金蝶不允许创建客户时「客户编码为空」——属于金蝶侧的硬约束，不是系统 bug。

收尾｜从「首个对账计划」到「完整月结对账」，你还要走 2 步

如果你已经按本文走完了一次「京东 POP 2026-07 账期 600 单 → 差异 0 → 整体确认 → 推金蝶云星空」的完整流程，你已经完成了新用户从 0 到 1 的入门四连：

首个对账计划这件事，看起来「只是按 5 个按钮」，背后是 7 态状态机、23 个 diffReason、双码匹配、整体确认、转换单据 5 套机制协同。这套产品把传统对账工具的「写 Excel 公式 + 手动勾稽 + 人工推 ERP」压缩成「5 个按钮 + 30 秒到 2 分钟等待」——从「看懂」到「完成第一份对账」，新用户 4 篇教程总共不到 1 小时。

接下来 9.1.5 会带你生成第一份报表——你刚才对账完成的 600 单，会出现在「收入对账总览」里，按平台 + 账期 + 店铺多维度聚合。

面向开发者：本文涉及的 7 态状态机迁移、双码匹配、23 个 diffReason 业务标签码、整体确认的反向写、转换单据推金蝶的实现细节，可以在项目仓库的 income-reconciliation-development / reconciliation-script-development / frontend-ui-standards 三个 SKILL 文档里查完整实现——分别对应「收入对账开发标准」「对账脚本工程师」「收入对账计划前端列表页三段式规范」三个专题。