财务对账

几万行流水里，能对上的占绝大多数。财务真正需要动脑的是对不上的那几十笔——为什么差、差在哪个环节、该怎么调。

但为了找出这几十笔，得先把三方数据拉到一张表上，对科目、对期间、对币种。月末最忙的那几天做这件事，恰恰也是最容易出错的时候。

业务系统、财务账套用数据库节点连接，配置 SELECT 查询按期间取数；银行流水若只有文件形式，作为任务输入材料上传。

数据库节点本身只支持 SELECT。对账场景接的是账务数据，这一点需要在方案评审时向财务和审计明确说明：这条链路在机制上不具备修改账务数据的能力。财务系统的评审通常卡在这里，把它讲清楚比讲效率有用。

业务口径与财务科目的对应关系、币种换算规则、期间划分口径整理成表，导入结构化知识库按字段查询。

这张表独立维护，业务新增品类、调整科目时只需补表，不动流程。把映射写死在代码里，是这类项目第一年就会后悔的决定。

逐笔匹配全部写在代码执行节点里：按单号精确匹配、按金额加日期容差匹配、按多对一拆分匹配，规则分层，逐层降级。

财务对账对确定性的要求是所有场景里最高的——同样的输入必须得到同样的输出，而且审计师要能看懂匹配规则并独立复算。这个环节完全不能有生成式的不确定性。

模型在这里只做一件事：拿到未达账项之后，结合业务规则给出可能成因的分类（时间性差异、手续费扣减、退款未同步、跨期确认等）和核实路径。给线索，不下结论。

结束节点输出可直接用于账务处理的调节表，以及需人工核实的差异清单。

配定时任务在每个账期结束后自动跑。财务上班时拿到的是已经收敛到几十笔的待办，而不是几万行原始数据——这才是这个场景真正省下来的东西。