建对账计划时随手填的那几栏，两个月后会变成查不出来的差异

摘要：建对账计划的三步向导，走完不到一分钟。两个月后有人问这个店的数为什么对不上、差异单在哪，现场没人答得上来。讲向导三步与后端真正强校验四栏的差别、四个关键口径为什么不在建档页上、随手填客户编码和账期范围要付的代价、确认完为什么还有失败行躺在池里，以及怎么证明建对了。 关键词：对账计划、建档口径、账期范围、核算项目、计划状态、失败行结转

一、随手勾一下账期，两个月后没人说得清

对账计划建的时候通常是这样过去的：有人被拉进一个三步向导，填平台、选店铺、勾账单、拉账期、点创建，不到一分钟。然后是两个月后。

出月报那天，有人问某个店：这个月对不上，差异单在哪、为什么没有。现场没人能回答——不是数据丢了，也不是谁改坏配置，是两个月前那张表上没人做过判断。

对账计划不是一次填表，是把口径提前两个月固化下来的动作。 系统不会为随手填的字段报错：账期填窄了，订单躺在聚合池外面；客户编码填成占位串，整店匹配率归零，每行都判"缺供应链"。这些错不会当场冒出来，会攒着，等你要用那笔数时一次性讨债。

这段话里藏着三个问题：向导让你以为必填的栏，和后端真正强校验的栏不是同一批；四个关键口径根本不在建档页上；"确认"不等于"封存"，失败行还挂在池里。

二、向导三步，后端真正强校验的只有四栏

真正会被后端强校验的只有四栏：店铺、平台、账期起、账期止。 数据源账单和备注是可选的——你以为必填的未必必填：只要那四栏齐了，计划就能建出来。

另一层更要紧：可选不等于不要紧。可选项的问题不是填错，是没填，而且没人会因为没填而被拦下来。 账单不勾，系统不报错；备注不写，也没人提醒你。两个月后你拿着一份"完全合规"的计划解释差异，翻遍记录也找不到谁动的。

一是结束账期的联动：结束账期如果没被显式改过，它会自动跟随起始账期。 你只填一个起始账期，界面不拦你，但这个计划的实际范围只有一个月；而下个月你没打算放进同一个计划，于是那个月的行永远取不到。二是账期粒度是月。

编号规则：收入侧是 IRP-{平台}-{YYYYMMDD}-{序号}（如 IRP-SPH-20261008-0003、IRP-XHS-20260922-0001），费用侧是 ERP-{店铺}-{YYYYMMDD}-{序号}。两个前缀不一样的收入计划，不是重复建档，是平台选错。

这张界面图里最容易看错的是第 1 步数据源账单的多选框。它看着像少勾几项只是少对几类账单，实际决定了这次建档取不取得到那批分段账单；第 3 步那四张统计卡是唯一的预警位，命中行数为 0 时按钮禁用。

这四栏填完，计划就成了一份口径快照：账期取哪几个月、这个店跟哪些账单对，都写在这条记录里。轻易云在建计划时就把账期与数据源账单的选择记成口径记录，后续取行按它走，口径不必靠人记。

三、四个关键口径，根本不在建档页上

建档时最容易有的误解是：我在建计划的时候把口径定死了。 这句话是错的。准确说法是：建档时你只是被继承，或者被卡住。

归属期是算法给的。 规则直取源字符串的北京墙钟年月。例外四条：视频号按货款结算月、沃尔玛按放款入账月、亚马逊结算滞后 1 到 2 个月且跨期退款单列、小红书按自然月；京东三张账单各取不同时间列。"建的是 9 月的计划"和"订单落在 9 月"是两件事，建档页不提示。

这些口径的前置条件不在建档页上，而在店铺主数据里：客户编码、供应商编码、收款银行账号、付款单位类型、付款单位、品牌部编码、归属部门、币别、费用项目内外销。那四栏填得再齐也替代不了它们。

反直觉的结论：你以为建档是在定口径，其实是在给口径发通行证。 脚本挂对了核算项目，客户编码是占位串，行照样匹配不上。该做的不是"定口径"，是"确认前置条件齐不齐"。

四、随手填的五个代价，和一个更贵的错

代价一：客户编码填成店铺名或占位串，整店对账全变缺单。 不报错。实证：某欧洲站用占位编码（示例代号 4002）建的计划，首轮匹配率 0%，全判"缺供应链"；换成真实编码后升到 64.98%。某美国站同样。

还有个更阴的：编码末尾多一个空格，全店 0 行匹配。 界面上没区别，匹配结果完全另一个样子，现场很容易当成"客户没开单"。

代价二：账期填窄了，订单永远躺在池外。 被排除的行不会进任何计划或聚合池，账面表现是"这段时间没生意"。视频号还有三个月窗口——结束账期往前推两个月，前两月的结转行漏取会整批判成缺单。

代价三：数据源账单漏选，同账期的分段账单会漏。 聚合的准入规则是：成功行独占原计划，不再进新计划；失败行留在池里，下一期同店同平台的计划会自动复活重对。 漏选的后果不是"少了几行"，而是账期被切成两段。

举个具体的：计划 1 只选账单 A，失败 5 条；计划 2 只选账单 B。结果计划 2 取到 B 的当期行，加上 A 那 5 条失败行。A 的成功行已在计划 1 里锁住，失败行才在计划 2 里出现。 你以为在看 B，其实是 B 加 A 的尾巴。

代价四：平台选错，聚合取不到行。 聚合没实现的平台，创建计划时直接报错。报错是好事；麻烦的是能建却取不到行的组合。

代价五：备注没写，证据链断在源头。 手工确认必须写备注，系统备份原差异原因；建计划时没写备注，摘要只能"月份 + 店铺 - 手工确认"兜底。到这一步，你已无法证明是谁、因为什么确认。

代价六，也是最贵的一种：静默错比报错贵。 店铺映射字段没维护时，系统会回落实值并放行——挂错客户、挂错部门，流程照样往下走。判失败有人修，静默错走到月结才暴露。

五、确认不是封存：七态、失败行下期复活、重做会抹掉人工痕迹

收入对账计划有七个状态，费用侧只有五个，没有"对账执行中"这一档，只有整体确认。而确认不是封存：确认只锁成功行，失败行留在池里下期自动复活，确认弹窗会提示"N 条失败行将结转下期"。把一个计划确认掉，不代表这个店的账期已经结清。 轻易云把失败行的自动结转做进了计划状态机，而不是靠人记着哪些行还没处理。

合法迁移里有两条容易忽略："对账完成待确认"可以退回"对账执行中"，"失败"也可以直接进"对账执行中"。 后者就是重新对账，可以换脚本——上一版脚本标签口径不合账单格式时不算事故。

手工处理三个出口：对平、手工确认、手工忽略。手工确认必须写备注，系统备份原差异原因；手工忽略永久退出聚合池。

重新对账会清空全部体行结果，包括手工确认的痕迹和忽略标记。 唯一的例外：处理建议在脚本未返回时才保留。你人工填的"这批差异是什么原因"，脚本这轮没回结果就留着；一旦回结果，痕迹归零。

所以顺序有讲究：先确认收入计划。 费用计划先确认，结转行的订单费用会归零，桥表丢掉费用腿——费用还在账上，桥表却不认。

还有一个死计划护栏：体行有数据但桥表为空，说明这些行已被别的计划接管，"开始"和"确认"都会报错，提示改用持有这些行的最新计划。报错是唯一的好消息，它承认了"你的计划不是这些行的主人"。

这张流程图值得盯两处回退箭头：从"对账完成待确认"退回"对账执行中"，从"失败"直接跳进"对账执行中"。确认不是终点。

六、谁建、谁审，以及怎么证明这个计划建对了

系统角色只有三种：管理员、经理、普通用户。但对账计划本身没有建、审、确认的角色分离。 建计划、开始对账、整体确认都是登录用户的动作，确认入口只有一个。唯一有角色闸的是 AI 助手的写类工具，写类要求管理员，派发类同样限管理员。轻易云把口径前置在建档这一步，也把失败行结转做进状态机，让建计划的人替两个月后的人先判断。

真正兜住风险的，是"备注必填 + 守卫"：计划处于已确认、对账执行中、已取消时，禁止再人工裁定。留痕靠规矩，不靠岗位。

还有提示横幅：同店同平台存在非终态计划时，向导会显示"上一期计划尚未确认，其失败行将提前转入本计划"——只提示，不阻断提交，两期会共用一批行。

这张架构图里收入和费用是两条腿，共用同一批账单行。共用意味着顺序敏感：收入侧先确认，结转行才有费用腿可挂；费用侧抢先确认，订单费用归零，桥表少一条腿。两套计划有先后，是两个动作。

怎么证明建对了？两把尺子。

批次侧的尺子是轧平：财务应收加费用应收（带符号）等于账单体行净额，差额必须是 0.00。

计划侧的尺子是逐科目对平。 某视频号计划体行 649 行、总额 39,551.80，与财务手工四个科目逐分位一致。

判定结果是 341 行主匹配、306 行已并入、2 行仅退款，失败 0，差异合计 0。

判定口径也要点明：整单轧差是默认，严格相等、零容差。 旧的"差异绝对值不超过 1 元视为成功"已废止。尾差只作平台特例档：某平台退货差价允许 0 到 0.05 之间的小额，某平台补贴倒挤有不超过 0.02 的红冲守卫——而且差异额仍保留出单，不抹平。

差异标签码是三十多个业务码加一个兜底码，文档里的 18、23、38 都是过时口径。

这张清单图的价值，是把建档动作拆成可勾选项：平台、店铺、账期起止、数据源账单、客户编码、备注。写进检查表，就不再依赖某个人当天有没有想起来。

---

三条今天就能做的动作

第一条，打开最近三个月的收入对账计划，把客户编码和账期范围拉出来对一遍主数据。重点看两处：编码末尾有没有空格、账期范围有没有比账单实际到达的月份窄。 这两个错都不报错，会在某个不该空着的月份上留白。

第二条，挑失败行最多的计划，把失败的行按差异标签码分个类，看失败原因是否集中在某一类上。如果失败行在各期之间大致稳定，说明它是口径问题不是数据问题：口径问题回建档前解决，数据问题才值得逐条查。

第三条，在一个收入计划上做一次逐科目对平：把体行按核算项目分组，和财务手工的科目金额比一遍，差额必须是 0.00。只有这条能证明"这个计划建对了"，其余只能证明"这个计划建完了"。

随手填的那几栏不会在建档那天报错，但会在两个月后变成查不出来的差异。能救你的只有一件事：把核对留到建完当天。