40 家 SPV 共用一个已核对模型:面向 2030 愿景巨型项目的多主体合并

一位项目总监在例会上提出一个听起来很简单的问题:“我们整个项目的承诺资本总额是多少，已提取了多少?”三个人打开了三份不同的文件，数字之间相差约 4%,却没有人能说清哪个才是对的。会议照常推进，而这个差异就悄悄成了下一轮预测的基准。

这一幕在海湾地区最大的建设项目中反复上演。沙特阿拉伯的巨型项目从来不是以单一法律主体运作。仅 NEOM 一个项目，就通过一整套子公司体系运作:作为主开发商的 NEOM 公司、负责能源与水务的 ENOWA、作为联合投资入口的 NEOM 投资基金，还有多家合资企业，例如与 ACWA Power 和 Air Products 合资、估值约 84 亿美元的绿氢公司，以及 DSV 持股 49% 的物流合资企业。五家旗舰巨型项目公司,NEOM、红海全球(Red Sea Global)、Qiddiya、Diriyah 和 ROSHN,均由公共投资基金全资拥有，并各自在其下孵化出自己的项目公司和特殊目的实体(SPV)。PPP 和建设运营移交(BOT)结构又增加了更多层次:每一个特许经营项目都是一个独立的 SPV,拥有自己的贷款方、自己的担保结构和自己的报告日历。

所以当有人说起“项目的财务状况”时，指的其实是数十张资产负债表，而这些资产负债表必须汇总成一个统一视图。而这正是 AI 现在被寄予厚望的地方，也恰恰是如果跳过某一步,AI 就会崩坏的地方。

合并问题比 AI 出现得更早

多主体合并从来都不容易，原因与技术无关。SPV 与其母公司之间的公司间贷款必须予以抵销，否则就会重复计入债务。一家按 51% 并表的合资企业，与一家按 30% 权益法核算的合资企业，处理方式必须不同。伊斯兰债券(Sukuk)和伊智拉(Ijara)融资在账面上的处理方式，与传统定期贷款也不相同。以美元计价的资本、以里亚尔结算的合同、以欧元开票的设备，全都必须统一折算成一种列报币种，使用同一套汇率，截止到同一个结账日。

只要其中任何一环出错，合并后的数字就会出错，而且不是舍入误差那种小错，而是被抵销的公司间余额那种量级的错误，在巨型项目上这可能高达数十亿美元。财务团队深知这一点，这也是为什么在一个涉及 40 家主体的项目中，月结账要花上数周时间，也是为什么合并工作表是整栋大楼里最脆弱、防守最严的文件。

现在再把 AI 叠加进来。这个设想很诱人:让项目总监输入“按主体展示净债务”或“我们在各个 PPP 特许经营项目中的综合资本成本是多少”,然后立即得到答案。问题在于 AI 所读取的数据本身。

为什么直接把 AI 接入原始主体数据会让情况更糟

如果你把一个语言模型直接连接到 40 张试算平衡表，接下来会发生什么呢?模型从每个主体中检索数字，然后尝试相加、抵销公司间往来项目、套用持股比例、进行币种换算，而这一切都是以概率性的文本预测方式完成的。它并没有在执行一次真正的合并，而是在逐个词元地猜测一次合并结果“大概应该是什么样子”。

由此产生两种失败模式，且性质各不相同。

第一种是检索漂移。同一个跨主体问题问两次，你可能得到两个不同的总数，因为模型每次抓取的源数据行略有不同。在基于真实财务备案文件构建的基准测试中，即便只针对单一份干净的文档，前沿模型也只能正确回答约一半的实际数字查找问题。把这个问题拉伸到 40 份科目结构各不相同的文档上，误差面就会成倍放大。

第二种是推理错误，这一种更危险，因为输入本身是对的。模型正确读取了每个主体的债务数字，却忘记抵销公司间贷款，或者把 51% 的并表系数套用到本应按 100% 处理的科目上，又或者对某个合资企业的轧差方向搞反了。生成的数字看起来很合理，却对不上任何账。财务总监无法在上面签字，审计师也不会接受，尤其是在海湾地区监管机构如今要求每一个报告数字都能追溯到经审计来源的背景下，例如阿联酋要求在期末后九个月内提供经审计的财务报表。

靠更好的提示词是解决不了这个问题的，要解决它，必须改变模型底层所依赖的东西。

先核对，再让 AI 提问

这篇文章中最重要的一点就是顺序。已核对的模型必须先于 AI 触碰数据而存在。

这意味着要把每个主体的账本，无论它存放在 SAP、Oracle、NetSuite、本地会计软件，还是以上传报表的形式，都接入一个统一模型，在其中合并逻辑只需编码一次，并以确定性方式应用。公司间抵销是规则，不是猜测;持股比例按主体存储;汇率折算基于一张在特定日期生效的既定汇率表运行;每一个合并后的数字都能逐行追溯到它所来源的主体。这是一个统一的、已核对的真相来源，而不是 40 张恰好大多数时候能对上的电子表格。

一旦这一层建立起来,AI 的任务就彻底变了。它不再执行合并计算，而是从一个已经合并、已经核对好的模型中检索数据，而任何它需要的计算，比如综合资本成本、跨特许经营项目的偿债覆盖率、延迟提款的假设分析，都通过一个确定性引擎运行，而不是依赖模型自身的算术。语言模型负责语言部分:理解问题、组织答案、解释驱动因素;数学则留在数学应该在的地方。

真正的检验标准是:两个人在同一天问同一个问题，是否得到同一个数字，以及这个数字是否能追溯到源头。在已核对的数据层上，答案是肯定的;而在原始主体数据上，无论模型多么优秀，都做不到这一点。

这为巨型项目财务团队带来了什么

速度，而且是站得住脚的速度。项目总监在几秒钟内就能得到跨主体答案，而不用等三个人各自打开一份文件。财务总监可以向审计师准确展示每一行数据来自哪个主体。监督机构，而 2030 愿景系列项目从来不缺监督机构，看到的是一套一致的数字，而不是需要逐一追查的差异。

它还能把你真正需要看见的漏洞暴露出来。当每个主体都汇入同一个已核对的模型时，一个尚未结账的主体、一个轧不平的公司间余额、一个年中变更的合资持股比例，就不再能藏身于某份手工工作表之中。核对这一步让差异变得可见，而不是任其传导进下一轮预测。

这一切都不会取代财务总监的角色。核对规则、持股处理方式、抵销逻辑，这些都是专业判断，应当由掌管结账工作的人来制定和审核。这一层所去除的，是那种悄无声息的算术错误，以及“到底哪份文件是对的”这个问题本身。

诚实地说，这比在你的 ERP 上直接接一个聊天机器人要难搭建得多。以确定性方式编码合并逻辑需要实实在在的工作量，还依赖底层账本能够被接入。但正是这份工作量，决定了一个项目总监能否在董事会面前复述 AI 给出的答案，还是那个答案每次被问到时都在悄悄漂移 4%。

如果你正在管理数十家 SPV 的合并工作，想看看针对一个已核对模型提出跨主体问题实际会是什么样子，欢迎预约演示。想了解这背后更广的监管背景，可以从这一支柱内容开始:为海湾地区 AI 构建可信数字层;关于审计师现在要求的可追溯标准，请参见你的 AI 能否让每个数字都追溯到审计与为什么 IFRS 18 下调整后 EBITDA 的计算不能靠即兴发挥。