Day 02 · 2026-08-21 · 系统设计
四个系统怎么串，以及能预测什么
稽查这件事没办法只接一个系统来做。「该付多少」和「实际付了多少」永远在两个不同的地方 —— 把它们放在同一轮里比对，才是稽查层真正在做的事。这一页写清楚接法、每日记录的固定格式，以及用现在手上的资料能预测到什么程度。
01 · 接法
两端对比，不是四个系统各看各的
为什么必须四个都通：只有薪资系统，你只知道付了多少，不知道该付多少；只有激励工具，你不知道客户的钱到底收到了没有；只有专案系统，你不知道最后有没有真的付对人；只有报销汇总，你看不到某个人的表根本没进汇总。今天最重的三条 —— 付错人、无凭证、事后被改 —— 没有一条是单看一个系统能发现的。
系统 01 · 应付端既有看板
专案管理系统
提成不是按业绩直接算的，它取决于哪些客户款项真的进来了、哪些专案里程碑到了、以及几个资格条件满不满足。十一个看板提供这些条件与专案进度 —— 以前是人工从不规则的还款记录里拼出来的。
这个月哪些专案达到发放条件了？客户款项收到了没有，收了多少？哪些人挂在这个专案下、各自该分多少？
系统 02 · 应付端内部工具 + 后台
激励制度记录
十三套制度、四种发放节奏（T+0 / T+1 / T+2 / 季度）。提成类在工具里按发放月份分桶并把算式摊开，所以每月的工作从「重建一次计算」变成「读一张卡」。内容激励走另一个后台，发放时差是版本化的 —— 规则改了，计算跟着改，而不是靠人记得。
这一层就是 B-03 那条发现的对策：五条规则改过、文件上还有两条是旧的。把规则钉进带版本的登记表、让计算直接读它，才能挡住「一次政策调整，三个月后变成一笔薪资错误」。
这个月该发的是哪一个月赚到的？这条规则的现行版本是什么？上一版什么时候换的？已经确认、但还没到发放月的金额有多少？
系统 03 · 实付端HRMS Open API
薪资系统
84 名员工，每月的津贴、提成、报销、加班、无薪假逐项可查。这是「实际付出去多少」的那一端 —— 稽查要做的，就是拿它去对系统 01 + 02 算出来的「应该付多少」。
逐人逐项拉一次，是 84 人 × 六类项目 × N 个月的查询量。人不会做这件事，机器会。这本身就是稽查层能存在的原因：以前不是不想核，是核不动。
每个人这个月实际拿到的每一项是多少？有没有哪一项在应付端不存在？有没有哪一项在应付端有、实付端没有？
系统 04 · 实付端个人账本 + 全公司汇总
报销系统
每个人的 claim folder、全公司每月的 Claim Summary，加上一本带 dedup key 的交易账本。收据、分类、期间、重复，全部在这一层比对。
这一层同时承担四种检查：表单总额对汇总（抓 A-04 付错人）、逐项对收据（抓 A-03 无凭证）、对完整历史去重（抓 A-08 重复申报）、对经常性收费登记表做差集（抓漏掉的固定订阅与 A-09 发票断号）。
这个人报的，跟汇总上记的，是同一个数字吗？每一笔有没有收据？日期在期间内吗？这笔以前报过吗？该来的固定收费，这个月来了吗？
02 · 每日记录固定成三段，才累积得起来
格式不固定，记录就会变成流水账，第二个月就没人看了。
① 三个关键数据五秒钟看懂当天最值得说的三个数字，每个都是「之前 → 之后」加一句人话。挑三个，不是列全部。
② 发生的事情三个数字的来处当天全部发现的完整清单。挑出去放首页的那三条，在这里也看得到全貌。
③ 我们设计的系统下个月还能再跑这些数字是靠什么跑出来的、接了哪些系统、哪些已定哪些待定。没有这一段，前两段就只是一次性的表演。
每条数字都要标等级。实测＝能在工具、日志或账单里直接指出来；推算＝由实测数据推导，方法写在条目里；观察＝看到了但还没量化。推算和观察都不当数据引用 —— 这条规矩比任何单一数字都重要，因为它决定了整份记录能不能被信任。
03 · 预测接下来两三个月，钱会花在哪
这是把系统串起来之后才做得到的事 —— 不是因为算法多聪明，而是因为终于有一份连续、可比、带节奏的历史。
可以直接排进未来两三个月的（确定）
项目月度基数依据与注意
薪资RM 135,30584 人的固定基数。人数变动才会动，属于可预告的变动。
固定订阅登记表 15 项每一项都记着扣款日与服务期间规则，所以不只知道金额，还知道哪一天扣。
水电 + 杂费RM 2,700–3,100六月 RM 2,677.29、七月 RM 3,061.25。项目固定，波动来自用量。
外包 / 实习RM 5,200–5,500每月固定六张 voucher。六月 RM 5,215.70、七月 RM 5,480.00。
创作者付款RM 2,830七月 16 人。人数由 PIC 每月提供，属于可提前问到的数字。
有节奏但金额浮动的（区间）
项目预测区间方法
员工与董事报销RM 35,800–40,900七个月月均 RM 38,357.51，标准差 RM 2,552.79。区间取 ±1 个标准差。实际七个月的最低 RM 35,450、最高 RM 41,210，跟区间吻合。
预扣税代垫额 × 8%四月 RM 4,741.89（代垫 RM 59,273.58）、五月 RM 2,574.20。先问到当月代垫额，税就是确定的 —— 不确定的是代垫额本身。
已经知道、但还没发生的（这是预测最值钱的部分）
事件什么时候为什么现在就知道
季度激励11 月季度制，Q3 落在 11 月。不是预测，是制度本身写好的日程。
内容激励T+2现在做的内容，两个月后才付。所以未来两个月的这一项，今天已经是既成事实，只是还没到日子。
提成类T+1 / T+2同理。已经确认的激励金额，其实就是未来一到两个月的应付表 —— 只要有人去读它。
年费型支出一次性七月那笔年费 RM 3,346.66 是一次性的，不剔掉会把整条基线拉高。七月报销比六月高 143.6%，主因就是它加上跨期收据。
还不能算的，就不算：
· 广告代垫金额本身 —— 取决于客户当月投放，只能给区间，不能给点估计。
· 新增订阅的跳变 —— D-02 那个从 RM 184 涨到 RM 1,578.50 的例子，事前没有任何讯号。预测抓不到它，但稽查可以在它发生的当月抓到，这就是两件事的分工。
· 供应商应付那一端 —— 账务系统需要在公司网络内才连得上，今天不在网内。接上之后，月结付款的预测才算完整。
为什么这在 AI 进来之前做不到：预测需要的不是模型，是一份连续、可比、带节奏的历史。七个月的报销必须口径一致才能算标准差；十三套激励制度必须知道各自的发放时差，才能把「已确认」翻译成「未来两个月要付」；固定订阅必须有一份带扣款日的登记表，才能排到日。
这三件事以前都不存在 —— 不是因为难，是因为没有人有时间每个月把它们整理成同一个格式。稽查层每月跑一次的副产品，正好就是这份历史。