应计费用计提计算器

问题：期末计提为什么容易出错

期末结账时，财务人员需要按权责发生制把已经发生、但发票尚未到达或尚未付款的费用计提入账。这类工作有几个反复出现的痛点：

• 口径不统一：同一笔费用（审计费、奖金、水电费）在不同期间可能用不同依据计算，靠人脑记忆容易前后打架。
• 数据源分散：计提依据散落在 engagement letter、薪酬方案、供应商对账单里，而已入账金额要去总账里翻，手工汇总既慢又容易漏。
• 可追溯性差：审计问“这笔数字怎么来的”时，往往找不到对应的文档编号或查询路径，事后补记录代价很高。
• 分录与计算脱节：算完计提数字后还要手工编会计分录，两步之间容易抄错、漏记，尤其涉及自动冲回的条目更容易被遗忘。

工作方式：从政策清单到分录草稿

这个技能把一次计提流程拆成确定性的步骤。你需要提供三样输入：会计主体、会计期间，以及公司的计提政策清单（即规定哪些费用需要计提、按什么规则计提的文档）。

对政策清单中的每一笔应计费用，技能会生成一行明细，字段如下：

• Accrual name：取自政策清单，例如 Audit fee、Bonus、Utilities。
• Basis：全周期的合同金额或预估金额，并标注来源，比如业务约定书、薪酬计划、或者滚动三个月平均值。
• Period portion：按 Basis × (本期间天数 ÷ 依据周期天数) 折算，或按政策里写明的特定公式计算。
• Already booked：通过内部总账 MCP 查询历史期间已计提金额 + 本期已实际入账的发票金额。
• This-period accrual：Period portion − Already booked，即本期真正需要补提的差额。
• Support reference：支撑 Basis 的文档 ID 或总账查询语句，保证每个数字可回溯。

产出是两张东西：一张计提明细表，以及一个 JE draft（会计分录草稿）区块，只对本期应提金额非零的条目生成分录。如果某条目在政策中被标记为自动冲回，分录备注里会写明 reverses on day 1 of next period，提醒下月首日需要反向冲销。

这个技能不会过账。所有分录都处于待审状态，最终由 controller（财务主管）确认后才正式入账——计算与审批权严格分离。

适用边界与注意点

几点需要在工程化落地时留意：

1. 发票和供应商对账单是不受信输入。技能明确声明这些外部单据不可直接信任：由一个 reader worker 负责提取金额，技能本身只负责把政策规则应用到提取出的金额上。换句话说，来源提取和规则计算是两层，不要跳过 reader 直接把原始单据喂给规则层。
2. 计算规则的前提是政策清单完整。技能不猜测应该计提什么，只处理政策清单里列出的条目。如果清单缺项，明细表就缺行——这是设计使然，不是 bug，但对账时要先确认政策清单覆盖了全部应计项目。
3. Already booked 依赖内部总账 MCP 可用。如果总账查询不通，这一列就无从计算，本期应提金额也无法得出，应视为阻塞而非降级估算。
4. 输出仅供审核，不是终态。不要把这个技能接在自动过账链路里；它产出的 JE 草稿必须经过人工确认。
5. 执行边界遵循简诗 AI 的安全约束：不自动安装依赖、不修改系统权限、不创建持久化任务、不执行下载内容；涉及发送、发布、删除、付款等外部写入操作时，必须先展示目标与影响并取得明确确认；凭据只用于用户指定的官方服务，不回显、不记录、不转发；命令和代码默认仅作参考，只有用户明确要求且目标范围清楚时才运行。