月底关账，薪酬核对这道关最磨人的不是数据量，是数据乱、出处不清、异常说不明。
薪酬核算本就有HRIS与成体系的流程，真正的缺口在另一层：总数平了，老板未必点头，他真正要的是一张每一笔变动凭什么、从哪来的可解释清单。为了交出这张清单，跨HRIS、考勤、外包结算和各实体账套的异构数据，仍得靠人把规则从制度文档和自己的经验里一条条捞出来，对着表手动比对。工号口径在各系统不一致，外包币种税率不同，离职补发与跨月请假扣减缠成一团。这些不是处理不了，是每次都得从头处理一遍，还落不成一个别人接手就能直接跑的资产。正是数据乱、出处不清，才让每一笔异常都说不明。
很多人能把总数算平，却交不出那张每一笔变动凭什么、从哪来的可解释清单。薪酬核对真正的价值，从来不是算出一个数，而是把这个数变成一条带追溯凭证的待核清册。每一笔变动都有据可查，拿不准的明晃晃交回来。再往前走一步，是把一次成功的核对，封装成团队可复用的 Skill 资产，让护栏把关从某个 HR 的个人手艺，变成组织可继承的对价能力。
这件事在 WorkBuddy 里能完整跑通。下面按真实的制造业多实体薪酬对账，把从底表到资产的每一步拆开。
图1·本地工作区结构
一、先理清底表与权限，让模型见到的世界干净且合规
跨系统的原始表天然带着异构。员工工号在考勤表是 E1003，在外包表是 1003，在请假单里只有中文名。存在离职月与发放月重叠，或者上月漏发的奖金在当月补发。金额列也常混着货币符号、合并单元格和隐藏列。
这种脏数据直接喂给大模型，结果必然报错。薪酬表含身份证号、银行卡号和实发工资，明文出域就踩公司合规红线。
稳妥的第一步不在分析，是在 WorkBuddy 本地 Python 沙箱里做代码硬清洗与脱敏。
建立标准目录。input 放原始考勤表、薪酬发放表、外包结算单。reference 放公司的薪酬扣款字典、职级系数、加班对折规则。output 放自动生成的凭证化对账日志与待核清册。
给 WorkBuddy 的第一道指令，是写代码清洗，不是分析业务。
请读取 input 目录下的所有 Excel 文件，在 WorkBuddy 本地 Python 环境中编写并执行脚本。取消所有合并单元格，将员工工号归一化为唯一主键，无工号的通过姓名加部门自动补全并标记。清理金额列中的货币符号与千分位，转换为浮点数。对员工身份证、银行卡等敏感字段做HMAC 本地掩码脱敏，数据不出本机。生成干净的 UTF-8 中间表，损坏数据打标后绝不擅自更改或编造。
敏感数据留在本地，异构数据被硬性规整。模型见到的世界是干净的，错才不会被混进入口。
二、调起专家先核完整性，再谈分析
底表干净后，第一句指令不要急着做报告。先用一个已完成核算的月份试跑，限定在授权人员可查看的数据范围内，做完整性核对。
请先检查本次薪酬数据的完整性。按员工编号和薪酬所属月份，检查重复记录、关键字段缺失、员工档案匹配失败，以及应发、扣减、实发之间的勾稽关系。列出具体记录、问题字段和待补资料。先不分析薪酬高低，不修改原始数据。
这一步看起来普通，却非常关键。同一个员工有两条工资记录，究竟是重复导入，还是正常工资和补发工资分开登记。某个人绩效为空，究竟是本月没有绩效，还是数据还没交。空白不等于零，两条记录也不一定就是重复发薪。先把这些问题弄清楚，再往下分析，才能避免一份看起来专业的报告从第一步就算错。
图2·完整性核对清单
三、差异落到具体项目，做月度薪酬变动表
数据核对完成后，再让专家做第一张真正有用的表，月度薪酬变动表。
请对比本月与上月薪酬，分别分析同一批员工的金额变化，以及新增、离职人员带来的变化。按员工列出上月金额、本月金额、差额、变动项目和对应依据。优先展示变动金额大的记录。没有依据的原因标记为待核实。
为什么要把同一批员工和人员增减拆开。因为部门工资总额上涨，可能是原有员工调薪，也可能只是多招了两个人。不拆开，人事很容易拿工资涨了去解释人数增加了。
这张表出来，HR 的处理顺序就清楚了。有记录的可解释，缺依据的找对应负责人确认。薪酬分析的价值，就在于把这个数字不对劲，变成这条记录需要查什么。
图3·月度薪酬变动表
四、发薪前把疑点筛成清册，每条带追溯凭证
第二张表是发薪前的核对清单，重点看几类情况。同一员工同一月份疑似重复核算。薪酬调整已生效但工资项目没有同步变化。一次性奖金连续出现需核对是否重复计入。补发补扣缺少所属期间或审批依据。应发扣减和实发之间存在金额差异。
对应的指令可以这样写。
请检查本月薪酬明细中的上述疑点，逐项输出员工编号、涉及金额、触发依据、需查验的记录和建议复核顺序。将已确认差错与待核实事项分开，不自行推断缺失规则，不直接修改薪酬。
这里有一道关键动作，是普通 prompt 写法容易漏掉的。每一条判断，都要挂载一列追溯凭证，写明依据的是哪张表第几行加哪条规则。置信度低于阈值的推断，统一标记为待人工复核，交回给 HR 确认。
这一道动作，正是 C\&B 第一性原理的落点。薪酬绩效的对价，早就该从工时和过程动作，挪到判断力和风险兜底上。你付高价买的，是有人对每一行变动负责、对拿不准的项兜底。每一行变动有据可查，拿不准的明晃晃交回来，这才是HR 敢签字、财务愿看的结果。
图4·薪酬核验与待处理清册
五、部门层面看钱花在哪，区分正常与非经常
个人明细核对完，还要往部门层面看，但只做部门工资总额排名用处有限。销售部和行政部人数不同、岗位不同，直接比总额说明不了什么。
更值得做的是同一个部门本月和上月到底发生了什么变化。
请按部门汇总本月与上月应发薪酬，拆分人数变化、同一批员工固定薪酬变化、绩效奖金变化，以及一次性补发补扣的影响。区分正常月度项目和非经常性项目，列出无法解释的差额及缺失数据。
假设某部门应发总额增加了五万元，核对后发现新增人员增加三万元，项目奖金增加一万五千，固定薪酬调整增加五千，这就比本月薪酬增长百分之二十有用得多。主管能继续判断哪些变化下个月还会持续，哪些只是当月发生。
图5·部门变动汇总
六、四个现实约束，避开核对翻车
方法跑通之前，有几个地方一定会绊倒人，提前说清楚。
1.脱敏必须在上传任何云端之前完成。先传后脱敏等于没脱敏，明文已经出域。
1.规则字典不全就别让模型推断。离职补发要不要核对审批件、跨月请假工时归属哪一月、外包结算单币种怎么折算，这些规则不写进 reference，模型只会给可能是考勤变化的废话。
1.工号归一化漏标会串户。只靠姓名匹配，同名、改名、多一个空格都可能把甲的工资算到乙头上。
1.置信度阈值设太高会把真异常放过去。宁可多交几条待核实，也别让模型替你拍板。
七、从一次成功到永久资产，封装成 Skill
如果你做完上面这些，下个月还要重新输一遍指令，那你依然只是在用工具。
WorkBuddy 支持技能封装。我们直接在 WorkBuddy 里把这套清洗、字典比对、凭证生成的流程，封装成一个可沉淀的 Skill。
在技能配置中定义好三件事。输入规范，固定读取 input 里的薪酬与考勤表。处理逻辑，调用本地 Python 预处理脚本，引用 reference 规则字典。输出规范，固定生成带有凭证列的 CSV 或 Excel 待核清册。
下个月算薪时，C\&B 专员只需要把最新的表格往 input 文件夹一拖，在 WorkBuddy 里点一下运行薪酬考勤透视 Skill，三分钟内就能拿到全套合规对账日志。换个 HRBP 也能一键运行，不需要重新调试 prompt。
这一步把一次性的调试，变成可沉淀、可继承、可跨团队复用的数字资产。组织真正留下的，是这套护栏流程此后每个月的持续运转。某个人那个月多算了几个表，随项目结项就散了，这套流程留下来，下个月还在。
它对应的，正是 C\&B 支第一性原理里那句，为判断力和风险兜底付对价，工时不再是对价单位。
稳定跑通之后，还可以进一步接 MCP 连接器，直接读取 Core HR 数据库做定时对账，那是后话。
图6·Skill 资产封装结构
结语
回到开头那句话。薪酬核对最磨人的，是每一笔变动凭什么、从哪来却说不清、道不明。总数算不平，反而是最不难的一关。
一张经得起追问的薪酬表，背后是三样东西。每笔钱的依据。每次变化的解释。每个问题的处理结果。
WorkBuddy 在这件事里的角色，是桌面 Agent 工作台，把原本靠人肉重捞、不可溯源的核对过程，变成带追溯凭证的白盒结果，再把一次成功的流程封装成团队可复用的 Skill 资产。至于怎么落到你自己的薪酬周期里，从哪一格开始拖第一张表，是你比谁都清楚的事。
关联阅读：
如何用WorkBuddy手搓一个AI招聘工作台？
HR如何用WorkBuddy做人效分析？
如何用WorkBuddy搭AI工作台，把HRBP工作做成资产
HR 如何借助WorkBuddy资料库沉淀项目资产？
建议收藏｜HR × WorkBuddy 提示词实战手册：72 场景全景版
从入门到精通：HRBP的Workbuddy实践指南
如何用WorkBuddy跑通HR自动化流程？
