OKFDE｜AI核对了发票，为什么还不能直接打款？【Research #002】
跟着一笔跨期结算，看清资金流转要守住的工程边界。
OKFDE RESEARCH · SCENARIO STUDY #002 · 场景研究笔记
本文涉及的情节、对白、数据及项目过程均为基于工程现实的示意创作，不对应真实客户，亦不代表 OKFDE 已完成的项目能力。
01 / RESEARCH NOTES 研究笔记
这笔款，怎么差了三分钱？
上一篇的采购单批完了，接下来要给供应商结尾款。付款申请里附着三张发票和对应的入库单，还要扣掉上个月已经付过的预付款。
小王把大模型接进财务工作台，让它核对附件，算出尾款，生成待付凭单。王姐负责整理这批采购的付款材料，她点开凭单，发票号码和入库数量都对上了，金额却比自己的表格少了三分钱。
她先停住，把计算结果发给财务负责人老周。
小王查了输出记录，发现模型列出的几笔含税金额换算，保留的小数位数不一致。他觉得差额很小，几万元的货款，只差三分钱。
老周让他把每一步怎么算的列出来。哪一步取整，预付款扣了几次，单据上都得说清楚。这笔差额还没解释，付款申请先退回去。
三分钱有可能来自舍入，也可能暴露了一笔漏扣的预付款。财务要先核实原因，再按确认过的办法处理。仅凭误差率低，小王还不能让程序替出纳按下提交。
02 / RESEARCH NOTES 研究笔记
小王需要拆开的那道算术题
原来的设计让模型从图片里认字，再直接给出最终金额。小王现在把这两件事拆开。
模型先提取发票金额、税率和预付款记录，每个字段都附上原文件的页码与位置。王姐可以点回原件，检查它有没有把数字读错，或者把另一批货的预付款算进来。缺少依据、记录对不上，单子就交给人核实。
核对过的字段再送进计算程序。财务先确认本笔业务的计算顺序，明确中间步骤保留几位、在哪里舍入，以及尾差怎样处理。程序按这个版本计算，留下输入和逐步结果。不能把三分钱藏进一个只显示两位小数的界面里。
这类计算可以使用十进制数值类型，并明确设置精度和舍入方式。
Python 的 decimal 文档就说明了十进制表示与舍入控制，以及它在要求严格相等的会计应用中的用途。[1]
用了这种数值类型，仍然需要把公式和业务规则写对。模型读错一位数，程序也会照着错误输入往下算。原件核验和计算测试得分别做，问题才查得清。
重新打开凭单时，王姐左边看到原文字段，右边能展开公式。三分钱落在哪一步，终于可以逐项核对。若结果仍与供应商的结算要求不同，系统保留差额和原因，等待财务确认。
03 / RESEARCH NOTES 研究笔记
谁能动那把网银密钥
金额核对完，付款还要经过授权。上一篇批准的是采购价格，这次则要确认付给谁、付多少，两次同意各有自己的范围。
这里假设企业采用制单与复核分开的流程。王姐把材料交给出纳，出纳准备付款草稿，有权限的财务主管另行复核。AI 服务能整理材料和生成草稿，拿不到银行签名私钥，也不能单独发出付款指令。
生成草稿前，系统把收款人、开户行和账号，与财务已核准的供应商主数据核对。账号里的展示空格可以按事先约定的格式规则处理，实际号码有变化，就转入账户变更核验，不能直接用发票或聊天截图里的新账号覆盖原记录。
白名单本身也要有人维护。谁批准了新账户、依据是什么，都得留下记录，否则系统只是把一份未经核实的名单反复查了一遍。
在本文的参考设计里，复核人使用银行认可的硬件密钥签名。具体怎样制单、怎样复核，要按企业授权制度和所接银行的流程实现，本文不把这一种方式当成所有银行接口的统一要求。
签名前，主管应能看到本次收款账户和金额。签完以后，如果有人修改了付款内容，原来的审批和签名就不能直接沿用，必须重新核验授权是否有效。
小王还需要把这份付款版本保存下来。以后核对一笔交易，可以从凭单找到原件和计算记录，再看到谁批准了哪一版内容，最后对应到银行回执。
04 / RESEARCH NOTES 研究笔记
银行接口超时了，钱到底划出去没有？
主管签了字，受控的执行程序发送付款指令。几秒钟后，页面显示超时。
王姐看到付款结果没有更新，问出纳要不要再提交一次。出纳先打开了这笔指令的记录。
超时只说明企业没有及时收到答复。银行可能没收到请求，也可能已经受理，回执却没传回来。此时再发一笔新指令，就有重复付款的风险。
幂等机制可以帮助处理重复请求。以 Stripe 为例，它的接口用调用方提供的幂等键识别同一请求的重试，并对参数、保存期限等条件作出约定。[2] 这能解释机制怎样工作，具体银行是否支持、支持到哪一步，还要查接入协议并测试。
小王不能只在请求里加一串编号，就认定银行会替他去重。用于标识同一笔操作的编号要保留，重试时不能随意换成新号。AWS 的安全重试说明也强调，请求标识需要与服务端处理机制配合，超时后的原请求仍可能迟到。[3]
本文的设计先把付款转入“银行状态待查”。页面暂停提交，后台执行程序也检查这笔业务的状态，避免另一个进程或接口调用绕过页面，再发一次。
随后，程序按银行协议查询原指令结果。明确成功的，记录回执并进入后续对账；仍在处理或无法确认的，继续待查，由指定人员跟进。
查询暂时没有记录，也不足以证明原指令未执行。只有按银行协议确认原指令未受理或已终止，并满足安全重试条件，才进入后续处理。重试仍要遵守该接口对原编号和参数的约定，不能把锁定解除就当作付款完成。
这笔单子可能因此多等一会儿。出纳需要知道去哪里核对流水，遇到争议找谁处理。队列里只有“待查”两个字，没有人负责，系统仍然帮不上忙。
05 / RESEARCH NOTES 研究笔记
Zoe 会怎样看这个项目
我会先看王姐少做了哪些工作。原件能直接打开，计算过程能逐项核对，这些设计有机会省下找附件和复算的时间。是否省事，还得请业务人员在测试环境里走一遍。
测试材料需要经过授权处理，由财务先核定预期结果。可以从跨期结算和部分退货里挑样本，再加入红字发票、重复预付款记录等情况。模型抽取了什么，程序怎么算，分别检查。不能只看最后的金额碰巧对了。
接着修改收款信息。把测试附件里的银行账号换掉，检查系统会不会擅自更新主数据。付款已经批准后，再改一次金额，看看后台是否要求重新核验授权。
网络故障要专门演练。让模拟银行已经受理付款，却不返回答复；再让查询接口暂时查不到结果。测试人员重复点击，另一个进程也尝试提交，检查系统能否保留原请求，并让这笔业务继续待查。
整个演练使用隔离环境和模拟资金。需要核对目标端实际受理了几笔，不能只凭页面按钮变灰，就判定防重复机制有效。任何一次多发指令，都要留下原始记录，修正后重跑同一组测试。
还有一些问题需要另开场景。跨币种付款的汇率取值时点、中间行手续费，以及允许的尾差，都要由财务明确处理规则。工程师不能为了减少拦截，自己加一个几分钱的容差。
如果这些规则还没定好，我会让这类付款继续走原有人工流程。测试版先保留计算明细和待核实事项，等财务给出处理办法，再补进程序和测试样本里。
关于 OKFDE
我们关注 FDE，更关注 AI 真正落地之后发生的真实事件。
如果你也关注AI，关注产业，欢迎建联。
微信：okai-leo
公众号：OKFDE-AI不止Demo
参考材料 / REFERENCES
1. Python 官方文档，decimal 十进制算术。参考其中的数值表示、精度与舍入控制。
2. Stripe，幂等请求说明。参考其对重复请求标识、参数一致性及幂等记录期限的约定。
3. Amazon Builders’ Library，安全重试与幂等接口。参考请求标识复用与延迟请求处理。
⬆Zoe：你们猜小王昨天喝了几杯咖啡？ (´•̥̥̥ω•̥̥̥)