验证机制解析:每一个导出数字背后的核查

董事会材料中的一个数字，只有在有人质疑时你能拿出依据，它才算真正站得住脚。多数 AI 工具会跳过这一步，它们能流畅地讲出一个数字，却从不检查这个数字是否与模型中的其他内容相符。Rexfin 的验证器正是为了补上这个缺口:在一个数字被导出之前，系统会用精确算术(而非近似值)来核查它是否满足必须成立的会计恒等式。

每个数字都要先被锚定

在核查任何恒等式之前，每一项数字主张都必须能追溯到一个具体来源。Rexfin 称之为锚定:一个数字要按数值、所代表的含义，以及所适用的期间和主体，与其背后的事实相匹配，这个事实正是溯源记录中引用的来源。两个数值恰好相同的科目并不会因为数字对上了就自动交叉匹配。如果一个数字无法匹配到任何来源，它会被标记为无法验证，在生成答案时这是一个硬性阻断:相关语句会被拒绝，而不是照常输出，这与数据摄取的运作方式采取同样的立场，只是深入到了算术层面。此外，一个数字还需要来自源页面的多次独立读取的相互印证才能被直接引用;仅有一次读取匹配的结果会以较低置信度展示，单独一次匹配不足以通过硬性核查。

两类数字，两种失败方式

数字锚定完成后，验证环节会核查那些理应成立的会计恒等式是否真的成立:资产是否等于负债加所有者权益，经营、投资、融资现金流加上汇率影响之和是否等于现金的实际变动额。这些都不是新的核查项，而是每个会计人员早已知道必须成立的恒等式。新的地方在于,Rexfin 会在每一个相关期间真正执行这些核查，而不是让它停留在一句没人真正落实的口号上。

结果取决于数字的来源。如果每一个运算项都能追溯到申报文件中的实际数字，那么核查失败就被视为真实问题并会阻断导出:你无法交付一份资产负债表都不平的董事会材料。如果任一运算项是模型测算或预测数字，那么核查失败只会作为提示。预测本来就允许出现预测特有的误差，但经审计的实际数字不允许。

精确数学，而非浮点近似

财务报表打印时是经过四舍五入的，精确到千位，有时甚至精确到百万位。一个要求精确相等的验证器会让每一份编制正确的报表都核查失败，而使用普通浮点运算的验证器在对大量大数字求和时也可能引入自身的微小误差。Rexfin 用精确有理数而非浮点数进行计算，并采用随报表规模和四舍五入方式变化的容差，而非一个固定数值。一份经千位四舍五入且正确的资产负债表能够通过核查;一份存在真实偏差的资产负债表会核查失败，并附带精确的报告差异。这也让核查具有确定性，同一组数字运行两次会得出完全相同的结果，这正是一个数字能被称为可复现，而不只是看起来合理的原因。

无法判断时，它会说明，而不是猜测

集团申报文件常常会在不止一个口径下呈现数字，母公司口径和合并口径，把二者混用会产生一个看起来正确、实则错误的自信答案。如果某项核查所需的数字只存在于其中一个口径，该项核查会被标记为无法确定，而不会用手边现有的数字随意填补。一个错误但看起来自信的结论，比诚实地说“这项无法核查”更糟糕，因为它会被当作正确性的证明而被引用，尽管它是错的。

同样的严谨也体现在定义的选择上:资产负债表核查中的所有者权益包含少数股东权益，因为若排除在外，任何存在部分持股子公司、本身完全正确的集团申报文件都会核查失败;现金流核查则包含汇率变动对现金的影响，因为若舍去它，任何在多种货币下经营的公司都无法对平，这些选择符合 IFRS 数字的实际运作方式，而不是教科书式的简化处理。

每一次核查都附带完整轨迹

无论一项恒等式核查通过还是失败，结果都会带着回溯到源头的轨迹:每一个数字都可以对应到它来自的确切页面。对于通过的核查而言，这只是形式;对于失败的核查而言，这正是关键所在，单说“资产负债表对不平”没有多大用处，但“资产负债表对不平，以下是四个数字及其源页面”则是审阅者可以据此行动的信息。这与贯穿平台每一项重大操作的审计日志机制一致，只是应用在了算术层面。

谁需要这项能力

如果你曾遇到某个 AI 工具给出一个自信的数字却无从核查，或者眼看一张表格“平衡”只是因为有人把差额塞进了一个待处理科目，验证机制正是为了悄无声息地阻止这类情况发生而设计的。它能让 CFO 在董事会、贷款方或审计师面前拿出一个数字，不只是说“这是我们的数字”,而是说“以下是它必须正确的理由”。了解它所依托的标准原子存储,查看平台其他部分的主题总览,或预约演示现场观看一份刻意设置错误的申报文件被当场抓获。