轻易云 财务经理 5 大常用操作
财务经理的 5 大常用操作：从创建对账到查看报表
摘要：作为财务经理，每月底你需要完成「创建对账计划 → 触发对账 → 整体确认 → 处理差异 → 查看报表」5 大常用操作。本文把这 5 步拆成 5 个动作、每步配真实截图、踩坑提醒与「B 级干货」——让你从「跟着提示点击」升级到「理解每个按钮背后的状态机与契约」。无论你面对的是京东 POP / 抖店 / 亚马逊 / 支付宝 / 拼多多 哪一个平台，这 5 步走完就完成一次完整的月结对账闭环。
关键词：财务经理、5 大常用操作、创建对账计划、触发对账、整体确认、处理差异、查看报表、R1 预设报表、23 个 diffReason
第 0 分钟｜为什么是「5 大常用操作」
财务经理的日常工作里，「对账」从来不是一个动作——它是一组动作。从打开系统到关账，你实际要做的是 5 件事：
| 序号 | 动作 | 你在系统里点哪个按钮 | 状态机迁移 |
|---|---|---|---|
| ① | 创建对账计划 | 「收入对账管理」→「开始收入对账」3 步向导 | → PENDING |
| ② | 触发对账 | 列表 / 详情页「开始对账」按钮 | READY → RECONCILING → RECONCILED |
| ③ | 整体确认 | 详情页「整体对账确认」按钮 | RECONCILILED → CONFIRMED（终态） |
| ④ | 处理差异 | 列表 / 详情页「编辑对账结果」或「重新对账」 | FAILURE → MANUAL_CONFIRM 或 重跑 |
| ⑤ | 查看报表 | 「数据分析 → R1~R6 预设报表」 | 终态数据 → 多维聚合 |
新手最常问的 3 个问题先答掉：
- 「5 步能不能少？」——不能。少了「整体确认」，对账结果推不到 ERP；少了「处理差异」，FAILURE 行卡住整个流程。
- 「5 步顺序能换吗？」——前 3 步严格串行；后 2 步可并行（处理差异 + 查看报表可交错）。
- 「一个月要重复跑几次？」——月底一次完整闭环（5 步全跑）；月中视情况触发 1 次重新对账；其余时间只看报表、不动对账。
下面 5 步走完一遍，每步配真实截图，踩坑与干货交替出现。
第 1 步｜创建对账计划：3 步向导 + 4 字段
进系统的第一件事是「找到入口」。左侧导航栏「对账管理」→「收入对账管理」，点进去你会看到一张列表页——这是所有 IRP-<平台>-<年月>-<序号> 编号计划的家：
看到这张列表时需要抓住 3 个关键信号：
- 每条计划的命名规则都是
IRP-<平台>-<年月>-<序号>。序号在月底会自动归零（每月 1 号创建的第一条计划永远是IRP-JD_POP-YYYYMM-0001）。 - 每条计划都有 3 个核心数字：订单数 + 收入合计 + 差异金额。差异金额 ≠ 0 就需要看差异原因；差异 = 0 表示完美对账。
- 右上角有一个青绿色的「开始收入对账」按钮——这是创建第一条对账计划的入口。
B 级干货 1｜IRP 命名规则 + 序号归零的工程价值：单凭 IRP 编号就能判断它是哪个月、哪个平台的第几条计划——交接工作时看一眼编号就能拿到完整上下文。序号归零机制让你无需记录「上个月最后一条是 0035」，每月 1 号永远从 0001 开始计数，避免人工维护错误（来源：v3 重构后定稿的对账计划命名规范）。
点「开始收入对账」按钮，弹出 3 步向导（基础信息 → 账期 → 预览）。下面是京东 POP 某店铺、2026-07 账期、5 张数据源账单的可视化状态：
把 3 步向导拆开讲，每个字段都需要填对：
第 1.1 步｜基础信息：4 个字段
| 字段 | 填什么 | 财务经理最容易踩的坑 |
|---|---|---|
| 平台 | 下拉选「京东 POP」 | 京东 POP、京东金融、京东联盟是 3 个不同平台 |
| 店铺 | 下拉选你解析完成的店铺 | 选错店铺会让「店铺级核算」全部错位 |
| 数据源账单（可选） | 勾选参与对账的 BillRow 来源 | 不勾 = 账期内该店铺全部已解析账单；勾选 = 仅勾选的几张账单 |
| IRP 编号 | 自动生成（IRP-JD_POP-YYYYMM-NNNN） | 不需要手动改 |
第 1.2 步｜账期：YYYY-MM 单月选择
账期选择器只允许选自然月——比如 2026-07 或 2026-08，不能跨月。财务经理最容易卡的是「我 7 月 25 号下的单能不能算 7 月账期？」——不能。账期对应账单月（不是订单月）。
第 1.3 步｜预览：4 个数字决定是否继续
向导第 3 步会给你看 4 个聚合数字，这 4 个数字决定你能不能提交：
| 预览数字 | 含义 | 期望值 |
|---|---|---|
| 候选行数 | 参与对账的 BillRow 总数（已解析 + 账期内 + 未对账确认） | 与你的账单实际行数一致 |
| 收入合计 | 候选行 incomeAmount 的合计（带符号净额） | 与原始账单的「收入总金额」一致 |
| 费用合计 | 候选行 feeAmount 的合计（带符号净额） | 与原始账单的「支出总金额」一致 |
| 净额合计 | 收入 − 费用（带符号） | 与原始账单的「账户余额」差异 |
如果 4 个数字与原始账单的总计对得上，就放心点「提交」。对不上——通常是「数据源账单」选多了或选少了，回到第 1 步调整。
新手冷知识：3 步向导的「下一步」按钮不会立刻触发对账任务——它只是把
IncomePlan记录创建出来（status = PENDING），同时启动异步任务生成体行。体行生成完成后，状态自动迁移到READY。
第 2 步｜触发对账：沙箱执行 + 7 态状态机
向导提交完 30-60 秒，体行生成完成，状态机自动从 PENDING 迁移到 READY。这时你有两个选择：直接点列表页的「开始对账」按钮（最快路径），或进计划详情页（推荐）。
点「开始对账」，系统做 3 件事：
- 状态机迁移：
READY → RECONCILING，触发JobTask(type=INCOME_RECONCILE)，入 BullMQ。 - 沙箱执行对账脚本：按平台的默认脚本（如京东 POP 用
京东 POP 收入对账 v3.4.6）跑reconcile(input)，输出「每条 item 的reconcileResult（SUCCESS / FAILURE）+diffReason（23 个业务标签码）+diffAmount」。 - 写回双码匹配：每个
IncomePlanItem.businessOrderNo与SupplyOrder.businessOrderNo匹配——命中供应链订单的成功路径写IncomePlanMaterialItem（物料明细）+ 反向写BillRow.reconcileStatus = RECONCILED。
下面这张状态机图把 7 态的全部迁移路径画得清清楚楚：
把图里 7 个状态拆开看，对应到财务经理的实际操作：
| 状态 | 含义 | 财务经理能做什么 | 触发条件 |
|---|---|---|---|
| PENDING | 计划已创建，体行生成中 | 等（通常 30-60 秒） | 向导提交 |
| READY | 体行已生成，待对账 | 点「开始对账」 | 异步体行任务完成 |
| RECONCILING | 对账中（沙箱在跑） | 等（看进度条） | 点「开始对账」 |
| RECONCILED | 对账完成，待确认 | 点「整体对账确认」/ 重新对账 | 沙箱跑完 + diffReason 全部落库 |
| CONFIRMED | 已确认，终态 | 不能改，只能查 | 点「整体对账确认」 |
| FAILED | 对账失败，可重跑 | 点「重新对账」回到 RECONCILING | 沙箱执行异常 |
| CANCELLED | 已取消，终态 | 不能改，只能查 | 点「取消计划」 |
B 级干货 2｜7 态状态机为什么这么设计：电商对账的状态比传统 ERP 多 3 个——
RECONCILING让财务经理看到「正在跑、不阻塞浏览器」，FAILED → RECONCILING让失败可重跑（不丢历史），CANCELLED让用户主动放弃并清理状态。电商对账是异步任务 + 用户确认的双阶段流程，每一步失败模式都需要单独的「可观测态」——对账师看到RECONCILING就知道「系统在跑，不要点」；看到FAILED就知道「脚本报错，要查」；看到CONFIRMED就知道「已锁定，不要再动」（来源：v3 重构后定稿的 IncomePlan 7 态状态机规范）。
财务经理等待沙箱跑完的 30 秒到 2 分钟是「耐心时间窗」——不要刷新页面、不要重复点「开始对账」。如果你 5 分钟后状态还在 RECONCILING，去「任务总览」查 JobTask(type=INCOME_RECONCILE) 的 status——RUNNING 就是在跑，FAILED 就是脚本报错。
第 3 步｜整体确认：CONFIRMED 终态化 + 反向写 BillRow
沙箱跑完，状态迁移到 RECONCILED。这时你应该进计划详情页——这里是「对账成果可视化」的主战场。轻易云智能对账系统的整体确认流程在 v3 重构后定稿，确保从「对账完成」到「推 ERP」的可追溯、可回滚。
下面是京东 POP 某店铺 2026-07 账期 600 单 / 98,837.12 元的真实详情页截图：
把这张图拆成 3 块给财务经理讲：
3.1｜顶部 4 个按钮
详情页顶部的 4 个按钮对应了状态机的下一步动作：
- 【整体对账确认】：把状态从
RECONCILED推到CONFIRMED（终态）。 - 【重新生成转换单据】：把对账结果生成金蝶云星空的应收单。
- 【重新对账】：把状态从
RECONCILED拉回RECONCILING，沙箱重跑、diffReason 重算。重新对账会清空之前的人工处理建议字段——这是 v3 状态机设计的安全闸。 - 【取消计划】：把状态推到
CANCELLED（终态），清理桥表与 BillRow 状态。慎用。
3.2｜聚合统计：3 个数字决定能不能确认
详情页正中央有 3 个数字：
| 数字 | 含义 | 财务经理的判定标准 |
|---|---|---|
| 订单数 + 成 / 败 | 600 / 成 600 / 败 0 | 全部成功 → 直接点确认；有失败行 → 看标签码 |
| 收入合计 | 候选行 incomeAmount 合计（98,837.12 元） | 与原始账单的「收入总金额」对账 |
| 差异金额 | 全部 SUCCESS 行的 diffAmount 合计（0.00 元） | = 0 表示完美对账；≠ 0 看差异行标签 |
截图里京东 POP 600 单「成 600 / 败 0 / 差异 0」——这是教科书级别的完美对账。但这只是特例，不是常态。
3.3｜整体确认按钮的动作分解
点详情页顶部的【整体对账确认】按钮，系统做 3 件事：
- 状态机迁移：
RECONCILILED → CONFIRMED（终态，不能再改）。 - 反向写 BillRow：把本计划所有 BillRow 的
reconcileStatus从RECONCILED推到CONFIRMED。 - 清理撤销权限：CONFIRMED 后【重新对账】需要二次确认。
整体确认是个不可逆操作——除非先点【取消计划】把状态拉回 CANCELLED，否则没办法回到 RECONCILED。首次点确认前，建议先看一眼「处理建议」字段（diffDisposalSuggestion）是不是合理——这个字段是 2026-08-19 新增的纯文本字段，对账师可以手工补录/修改/清空，但重跑脚本只覆盖脚本返回的值。
新手冷知识：财务经理最容易踩的坑是「整体确认前没看清 FAILURE 行」——如果还有 FAILURE 行没处理完，「整体对账确认」按钮是灰色的（前端做了 disabled）。这时你必须先走第 4 步「处理差异」。
第 4 步｜处理差异：23 个 diffReason + 4 步法
整体确认前，但凡体行里有 1 条 FAILURE，确认按钮就是灰色的。处理差异是你每天都要面对的工作——9.2.4《23 业务标签码的最佳实践》已经把 23 个码分成「自动出单 16 个 + 人工兜底 7 个」，本文只讲财务经理视角的 4 步差异处理法。
4.1｜看清机读码（10 秒）
进详情页看到 FAILURE 行时第一件事不是看金额，是看「差异原因」列显示什么码。不同码触发的下一步动作完全不同——AFTER_SALE_SERVICE_DIFF 暗示「账期、扣收、单据」，PRICE_DIFF_ORDER 暗示「聚水潭、配件链接」，MISSING_SUPPLY 暗示「供应链没数据」。
4.2｜双击行看详情：物料明细 + 处理建议
财务经理最难判断的是「这行到底是脚本没识别，还是供应链缺数据」。双击 FAILURE 行弹出体行详情，里面包含 3 类关键信息：
- 物料明细：
IncomePlanMaterialItem[]，告诉你这单对应哪些 SKU、多少数量、什么匹配策略。 - 处理建议：
diffDisposalSuggestion（机器生成的中文提示，30-60 字）。 - 金额拆解：收入 / 订单费 / 公摊费 / 供应钱 / 差异金额 5 个数对照。
下面是「双击行弹出体行详情」的真实截图：
截图里的 diffDisposalSuggestion 一句话告诉你：「差额与营销对账金额一致（¥65.92），判对账成功并保留标签」——不需要去查京东后台就知道这行是什么形态。
4.3｜判断自动还是人工（30 秒）
23 个码落在一个简单的二维网格里：
| 处理方 | 触发条件 | 动作 |
|---|---|---|
| 转换层自动出单 | 码 + sign 命中 transform_rules 四元键 | 系统自动生成费用应收单 |
| 人工兜底 | 转换层无对应规则 / 业务形态特殊 | 财务逐单核查（要么改单、要么打 MANUAL_CONFIRM） |
不需要背「16 自动 / 7 人工」的具体清单——只要规则表里能查到，机器就接管；查不到就一定留给你。
下面这张判定流程图把 23 码的「机读 + 人读双轨」画得一目了然：
4.4｜人工兜底的 3 道边界
人工兜底不是「自动化失败的退路」，是「23 码体系之外的最后一道质量防线」：
| 边界 | 含义 | 处理动作 |
|---|---|---|
| 边界 1：处理到「单据核对完」就算结束 | 人工兜底的产出物只有两种：① 改供应链单据后重新对账；② 勾选「手工确认」打 MANUAL_CONFIRM 标签 | 不要延伸到「补凭证」「改金蝶数据」——出单归转换层 |
| 边界 2：批次级处理 | 一个账期内所有 FAILURE 行集中一次处理完再触发确认 | 不要「边对账边处理」——会反复触发沙箱重跑 |
| 边界 3：差异 > 阈值触发升级 | 单笔差异 > 500 元 或 单账期 FAILURE 行 > 10 条 触发 CFO 升级 | 走「暂停确认 → 邮件知会 CFO → 复核后继续」流程 |
B 级干货 3｜4 步法 + 3 道边界的不分人群 SOP：把这套方法沉淀到产品里，让业务人员用一个弹窗 + 一行处理建议就能把月末差异从 5 天压到 1.5 天——「看清码 → 判自动/人工 → 读处理建议 → 出单或兜底」这套 SOP 写成内置引导。
处理完所有 FAILURE 行后，回到第 3 步点「整体对账确认」就解锁了。
第 5 步｜查看报表：R1~R6 预设报表 + 4 统计卡
整体确认完成后，对账结果就进入了报表体系。左侧导航栏「数据分析」组下挂 6 张系统预设报表——轻易云智能对账系统把这 6 张报表做成「固定接口 + 固定口径」，新用户不用配置数据集：
| 报表 | 名称 | 主要看什么 | 谁最常看 |
|---|---|---|---|
| R1 | 收入对账总览 | 跨平台 × 跨账期的收入合计、订单费用、对账成功率、差异金额 | 财务经理、CFO |
| R2 | 对账差异分析 | 按 23 个 diffReason 分组的差异金额分布 | 财务经理 |
| R3 | 费用汇总 | 跨平台 × 跨账期的费用合计（广告费 / 仓储费 / 物流费等） | 财务经理 |
| R4 | 费用分摊明细 | 按订单 / SKU 拆分的公摊费用明细 | 电商财务核算专员 |
| R5 | 订单利润 | 订单级利润（收入 − 订单费 − 公摊费） | 电商财务核算专员 |
| R6 | SKU 利润 | SKU 级利润（每个商品的真实利润） | 电商财务核算专员 |
财务经理最常用的是 R1（收入对账总览）+ R2（对账差异分析）。
5.1｜进 R1 看 4 张统计卡
进 R1 后，你会看到一张预设报表的标准三段式布局：工具栏平铺 + 筛选 Card + 4 张统计卡 + 折叠图表 + 计划明细表。下面是核算项目汇总报表的真实截图：
把 R1 报表的 4 张统计卡拆开讲——这 4 个数字决定你对「本期收入对账」的总体判定：
| 统计卡 | 含义 | 财务经理的判定标准 |
|---|---|---|
| 收入合计 | Σ IncomePlanItem.incomeAmount（已 CONFIRMED） | 与原始账单的「收入总金额」对账 |
| 订单费用合计 | Σ IncomePlanItem.orderFeeAmount（已 CONFIRMED） | 平台扣点的合计 |
| 对账成功率 | Σ matchedCount / Σ totalCount（%） | = 100% 表示完美对账；< 95% 触发预警 |
| 差异金额合计 | Σ IncomePlanItem.diffAmount（已 CONFIRMED 的 SUCCESS 行） | = 0 表示完美对账；≠ 0 看 R2 差异分析 |
B 级干货 4｜R1 默认只读 CONFIRMED 的工程价值：财务经理看报表的第一反应是「这里面的数能不能信」——能信与否完全取决于「筛选是不是把不该看的瞬态数据过滤掉了」。R1 的状态筛选下拉默认值是
CONFIRMED（已确认终态），瞬态RECONCILING/PENDING/FAILED一律不计入；如果你想看「沙箱跑完但还没财务确认」的数据，可以手动改选RECONCILILED，页面标题区会自动显示一个琥珀色「未确认数据」Badge——这条纪律保证你看到的 4 张统计卡「永远是真相」（来源：v3 重构后定稿的预设报表口径纪律）。
5.2｜R1 报表的双击下钻
R1 报表不是「看完就完事」——它的真正价值是让你能下钻到原始数据。两层抽屉下钻是 R1 的核心交互：
- 点 IRP 编号——新页签打开详情页，避免打断分析流。
- 双击 IRP 行 —— 右侧抽屉加载计划体行（SUCCESS / FAILURE + diffReason）。
- 双击体行 —— 弹窗加载溯源面板（业务订单号 / 物料明细 / 处理建议）。
这种「新页签 + 双层抽屉」的设计让财务经理在 R1 上分析时不会被一次点击就带走整个页面。
下面是 CFO 视角驾驶舱的概念图——R1 报表正是按这个目标设计的：
5.3｜看 R2 做差异分析
如果 R1 的「差异金额合计 ≠ 0」，必看 R2——它按 23 个 diffReason 分组，把差异金额、差异订单数、占比 3 个数字摆出来。财务经理看完 R2 通常能做 3 件事：
- 找规律：某个 diffReason 占比突增 → 跑回平台对账脚本看版本（京东 v3.4.6 比 v3.4.5 多判
INSTANT_REFUND极速退款子档）。 - 找平台：某个平台的差异特别大 → 拉该平台的
IncomePlanItem看失败行。 - 找店铺：某个店铺的差异特别大 → 检查该店铺供应链订单是否同步完整。
R1 + R2 配合起来用，就是财务经理的「月度对账体检表」。
常见问题｜5 大操作最容易踩的 5 个坑
把财务经理跑月结对账时最常见的 5 个问题集中回答一遍：
Q1：向导预览时「候选行数 = 0」——是不是导入失败了？
A：不是导入失败——是导入的账单还没解析完成。向导第 3 步的候选行只取「已解析 + 账期内 + 未对账确认」的 BillRow。回到「原始账单管理」看一眼解析进度——如果进度 100% 但候选行数仍为 0，需要去「任务总览」看 ParseTask 是否成功。
Q2：开始对账后等了 5 分钟还在 RECONCILING——是不是卡住了？
A：是 JobTask(RUNNING) 状态。600 行的京东 POP 计划通常 30 秒到 2 分钟跑完。判断卡死的标志是 JobTask.errorMessage 非空——只要 errorMessage 是空，对账就在跑，不要重复点「开始对账」。
Q3：整体确认按钮是灰色的——是不是权限不够？
A：通常不是权限问题，是**「还有 FAILURE 行没处理完」**。整体确认按钮的逻辑是「所有体行必须 SUCCESS 或 MANUAL_CONFIRM 才能确认」。两种处理路径：① 把 FAILURE 行用人工确认改 SUCCESS；② 重新对账，沙箱会用最新版脚本重跑。
Q4：处理差异时双击行弹窗没有「处理建议」字段——是不是漏配置了？
A：不是漏配置——diffDisposalSuggestion 是 2026-08-19 才新增的字段。重新对账一次就能拿到处理建议。不要手动填这个字段——脚本重跑时会被覆盖。
Q5：R1 报表的「对账成功率」显示 95% 以下——是要报警吗？
A：要看是否 < 90%。90-95% 是正常区间；< 90% 触发预警——大概率是供应链订单同步延迟或 MISSING_SUPPLY 集中爆发。第一动作是看 R2「对账差异分析」按 diffReason 拆开。
收尾｜从「5 大常用操作」到「月底 1 小时关账」
如果你已经按本文走完了一次「京东 POP 2026-07 账期 600 单 → 差异 0 → 整体确认 → 处理差异 0 行 → R1 报表 4 张统计卡 = 0」的完整流程，你已经完成了财务经理日常对账的 5 大常用操作闭环：
| 操作 | 你做了哪个动作 | 状态机迁移 | 你的角色 |
|---|---|---|---|
| ① 创建对账计划 | 3 步向导 | → PENDING → READY | 启动一次对账 |
| ② 触发对账 | 点「开始对账」 | READY → RECONCILING → RECONCILED | 等待沙箱跑 |
| ③ 整体确认 | 点「整体对账确认」 | RECONCILILED → CONFIRMED | 锁定对账结果 |
| ④ 处理差异 | 双击行 + 改 MANUAL_CONFIRM / 重新对账 | FAILURE → SUCCESS | 解决脚本未识别行 |
| ⑤ 查看报表 | R1 + R2 双报表交叉看 | 终态数据 → 多维聚合 | 月度体检 |
财务经理日常做对账，看起来「只是按 5 个按钮、看 1 张报表」，背后是 7 态状态机、23 个 diffReason、双码匹配、整体确认、反向写 BillRow、预设报表 6 张、4 统计卡、双击下钻 8 套机制协同。轻易云智能对账系统把传统对账工具压缩成「5 个按钮 + 1 张报表 + 30 秒到 2 分钟等待」——从「看懂」到「完成月结对账」，新财务经理跟着提示点击 4 篇教程 + 本文，总共不到 2 小时就能上手。
接下来 9.5.2 会带你从「财务经理视角」切到「电商财务核算专员视角」。
面向开发者：本文涉及的 7 态状态机迁移、双码匹配、23 个 diffReason 业务标签码、整体确认的反向写、预设报表三段式的实现细节，可以在项目仓库
.opencode/skills/income-reconciliation-development/SKILL.md（收入对账开发标准）、.opencode/skills/reconciliation-script-development/SKILL.md（对账脚本工程师）、.opencode/skills/preset-report-standards/SKILL.md（系统预设报表三段式规范）三个 SKILL 文档里查完整实现。