AI 做财务分析，先把千万行明细变成可追溯的结论

月结后的第三个工作日，管理层问了一句：“收入涨了，为什么现金还更紧？”财务分析人员通常要先核对收入确认，再拆应收账龄、客户回款、预收和存货占用。数据分散在总账、销售、合同、资金和供应链系统里，表名、字段和口径又不一样。一轮分析做完，半天甚至一天就过去了。

如果大模型能够理解这个问题，自动生成受控 SQL 查询数仓，发现应收和库存的异常，再读取合同与业务说明继续追原因，这件事当然有价值。但价值不在让模型快速写一段“受市场环境影响”的总结，而在于把几百万、几千万行明细压缩成十几个值得追问的问题，并且每个问题都能回到客户、订单、发票和凭证。

一条财务结论如果不能回到原始单据，它只是措辞流畅的猜测。

一、先把问题说窄：本月到底哪里出了偏差

“分析公司经营情况”不是一个可以直接交给系统的任务。范围太大，模型只能复述同比、环比和预算完成率。真正可执行的问题应当带着指标、时间、对象和比较基准，例如：

• 本月毛利率下降 1.8 个百分点，主要来自哪些产品、客户和订单？
• 收入同比增长 12%，经营性现金净流入为什么反而下降？
• 销售费用超过预算 320 万，哪些费用是业务增长带来的，哪些是一次性或记账错位？
• 逾期 90 天以上的应收新增多少，是否集中在少数客户或区域？

问题一旦写到这个颗粒度，所需数据和分析路径也清楚了。毛利要下钻到订单行，现金要连接发票与回款，费用要识别科目、部门、项目和供应商。大数据解决的是跨系统明细的连接与计算，AI 解决的是异常排序、文本材料整理和追问辅助。两者不是一回事。

二、先争取老板支持：不要卖 AI 平台，要解决经营问题

这类系统只靠财务或 IT 部门很难推下去。客户主数据归销售，采购条款归供应链，库存原因在业务部门，指标定义又需要财务拍板。没有高层明确责任，项目最后往往变成技术团队不停接表、财务团队不停核数。

向老板申请支持时，不要先讲模型参数、向量库和智能体。先拿三个月的真实记录说明：月度分析用了多少人天，管理层的问题平均多久才能回答，有多少时间花在找数和对口径上，又有多少异常因为发现太晚失去处理窗口。

项目目标也要换成经营语言。例如“关账后 24 小时内给出前十大偏差及明细”“逾期应收从月底发现改为每日发现”“毛利异常定位从 4 小时缩短到 20 分钟”。老板能判断这些目标值不值得做，也能看到项目是否兑现。

高层支持不是会上说一句“大家配合”，而是明确谁定口径、谁补数据、谁解释异常、逾期如何升级。最好由 CFO 或经营负责人每两周看一次试点结果，只讨论三件事：节省了多少时间、抓到了什么问题、哪些跨部门障碍需要裁决。

三、大数据底座先解决四件基础工作

很多项目一开始就建设“企业级智能分析平台”，最后却卡在客户编码对不上、历史组织架构没保留、同一个收入指标有三种算法。对财务场景来说，主数据、明细粒度、指标口径和时间关系比模型选型更先决定成败。

主数据要有统一身份

同一家客户在 CRM、ERP 和资金系统里可能有三个编码，产品也可能经历改名、合并和分类调整。要建立客户、产品、组织、供应商和项目的统一主键，并保留旧编码映射。组织调整不能直接覆盖历史记录，否则去年华东区的数据会被算进今年的新区域。

明细粒度要能对上

总账按凭证行记录，销售系统按订单行记录，资金系统按流水记录。三张表不能靠月份和金额强行拼接。应当保留订单号、发票号、凭证号、核销单号等业务键，并建立明确的映射关系。实在无法一一对应，也要标记分摊规则和不可匹配金额，不能悄悄平均掉。

指标口径要变成可执行规则

“收入”究竟是开票收入、会计确认收入还是订单收入？“毛利”是否包含运费、返利和存货跌价？指标表至少要记录中文名称、业务含义、计算公式、数据来源、过滤条件、负责人、生效日期和适用组织。口径不能只躺在 Word 文档里，还要固化到指标服务或公共 SQL 模型中，供 BI、接口和大模型调用同一份定义。

时间要按业务事实还原

财务分析经常同时面对订单日期、出库日期、开票日期、确认收入日期和回款日期。只留一个“月份”字段，会把因果关系切断。数据仓库应保留这些时间点，并按业务需要形成订单周期、开票周期和回款周期。

四、大模型联动的大数据系统，应该怎么搭

把一份几十万行的 Excel 直接交给大模型，让它“找出所有异常”，听上去省事，实际有三个问题：输入放不下、计算不稳定、结果难复核。更不能让模型拿着生产库账号自由查询。稳妥的做法，是把它放在数据语义层之后，作为分析的规划者和工具调用者。

ERP / CRM / 资金 / 供应链 / 预算 / 合同
  → 批量同步或 CDC，保留源字段与更新时间
  → 明细数据层：订单、收入、成本、发票、回款、库存
  → 公共汇总层：客户利润、产品毛利、应收账龄、现金转换周期
  → 指标语义层：统一名称、公式、维度、权限与版本
  → 大模型编排层
       ├─ 指标 API：优先读取已有指标
       ├─ SQL Agent：遇到新问题时生成受控查询
       ├─ 统计工具：做贡献拆解、异常检测和预测回测
       ├─ 文档检索：读取合同、制度和业务说明
       └─ 工作流：向责任人追问并收集确认
  → 证据包、分析结论、行动项与审计日志

模型收到“为什么本月经营现金流下降”后，先把问题拆成应收、存货、应付和其他经营项目，不是马上写结论。它先调用指标 API 看总量和趋势；发现应收异常后，再让 SQL Agent 下钻客户和账龄；需要判断是否超期时，调用合同检索读取信用期限；最后把数字、条款和业务回复装进同一个证据包。

这里的关键是让大模型决定“下一步调用什么工具”，而不是让它亲自心算。同比下降多少、前十客户贡献多少、金额是否勾稽，都由 SQL 或统计引擎完成。模型负责提出查询、检查返回结果、继续追问和组织证据。即使以后更换模型，底层指标、权限和分析记录仍然可以保留。

五、让大模型自动写 SQL，但不能让它“裸奔”

自动写 SQL 是这套系统最实用的能力之一。财务人员不必记住数仓表名，可以直接问：“本月华东区毛利率下降主要由哪些客户和产品造成？”模型根据指标定义、表结构、字段说明和示例查询生成 SQL，再交给查询网关执行。

但 Text-to-SQL 的准确率不能只靠提示词。模型必须知道哪些表可以用、字段代表什么、表之间如何连接、金额单位是什么，以及哪些过滤条件是指标口径的一部分。最有效的上下文通常不是整本数据字典，而是与当前问题相关的语义模型、经过验证的 SQL 示例和少量表关系。

用户问题
  → 识别指标：会计收入、订单完全成本、毛利率
  → 识别范围：本月、华东区、客户和产品维度
  → 从语义层取得指标公式与允许使用的字段
  → 生成 SQL
  → 静态检查：仅允许 SELECT，禁止越权字段和跨域查询
  → EXPLAIN 检查：扫描量、分区条件、连接方式、超时风险
  → 在只读计算集群执行，限制行数、时长和资源消耗
  → 校验：明细汇总与指标总额是否一致
  → 返回结果、SQL、口径版本、数据批次与明细入口

例如模型可以生成一段按客户、产品拆解毛利变化的查询，但其中的“会计收入”和“完全成本”应引用语义层已认证的字段，不能临时猜一套公式：

SELECT
  customer_name,
  product_name,
  SUM(accounting_revenue) AS revenue,
  SUM(full_cost) AS cost,
  SUM(accounting_revenue - full_cost) AS gross_profit
FROM finance_semantic.order_profit_detail
WHERE accounting_month = :month
  AND sales_region = :region
GROUP BY customer_name, product_name
ORDER BY gross_profit ASC
LIMIT 100;

查询网关至少要有六道限制：只读账号、行列级权限、敏感字段屏蔽、分区扫描限制、执行超时和完整日志。涉及工资、个人信息、银行账号等数据时，模型在生成 SQL 前就不应看到相关字段。高风险或预计扫描量过大的查询，先让数据人员审核。

还要处理一种常见情况：SQL 能运行，但业务含义是错的。例如订单表与回款表直接连接，可能因为一对多关系把收入重复计算。系统应在执行后做总额勾稽，并用已知样例持续回归测试。生产验收不能只看“SQL 执行成功率”，还要看口径正确率和财务复核通过率。

六、用“规则、对比、模型”三层筛异常

财务异常不是越复杂越好。建议先上简单、可解释的方法，再逐步增加模型。大多数企业第一阶段靠规则和分组对比，就能找出相当一部分问题。

第一层：硬规则

这类异常不需要 AI，例如负毛利订单、信用期外回款、同一发票重复报销、成本中心缺失、收入与出库不匹配。规则明确，命中后直接给出字段、阈值和明细。

第二层：同类对比

某产品毛利率 15% 单看不一定异常，但如果同区域、同渠道、同规格的中位数是 27%，就值得检查。对比组必须控制业务条件，不能把直营与经销、成熟产品与新品放在一起。常见方法包括分位数、标准差、中位数绝对偏差和滚动趋势。

第三层：组合异常

单个指标都正常，组合起来可能有风险。例如某客户收入增长、退货率上升、回款变慢且折扣加大。孤立森林、聚类等算法可以辅助找出少见组合，但模型只负责排序，不直接给出会计结论。排在前面的记录仍需业务事实验证。

异常分数 = 规则命中权重
         + 同类偏离程度
         + 环比突变程度
         + 金额重要性
         + 数据可信度修正

输出：异常对象、影响金额、命中原因、对比基准、明细链接

金额重要性不能忽略。一笔 200 元的极端异常与一笔 200 万元的轻微偏差，处理优先级不同。财务团队应按“可能影响金额 × 发生概率 × 处置紧迫度”排序，而不是只看算法分数。

七、分析原因之前，先让系统准备证据包

以毛利率下降为例，系统先定位到华东区某产品线，再下钻到 37 笔订单。提交给模型的证据包可以包含：

• 本期、上期和预算的收入、成本、销量、单价及毛利率；
• 价格、销量、产品结构和单位成本对毛利变动的拆解结果；
• 偏差最大的订单与客户，以及对应的原始明细链接；
• 合同中的折扣、返利和运费条款；
• 业务负责人已经提交的原因说明。

模型可以沿着“价格、销量、结构、成本”四个方向继续调用查询工具，判断各因素对毛利变化的贡献；也可以检查业务解释是否回答了异常，找出前后矛盾，并把“原材料涨价”继续追问成“哪种材料、何时涨价、影响哪些订单、预计何时恢复”。

原因分析最好区分三个层次：数据已经证明的事实、业务人员确认的原因、模型提出但尚未验证的假设。比如“单位材料成本上升 8%”是事实，“供应商临时调价”需要采购记录或业务确认，“可能由汇率导致”只能放在待验证项中。找不到依据时，正确输出是“待确认”，不是编一个完整故事。

好的分析稿不是把数字翻译成中文，而是说明偏差来自哪里、影响多少、接下来由谁做什么。

八、现金流分析是检验整套系统成色的场景

利润分析相对结构化，现金流则要求跨越更多系统。要回答“收入增长为什么没带来现金”，至少需要把订单、收入确认、发票、回款、预收、采购付款和库存串起来。

一个实用的分析路径是从现金转换周期出发，先看应收周转天数、存货周转天数和应付周转天数的变化，再把变化量折算成资金占用。随后下钻到客户、产品和采购类别，找出占用增加最大的对象。

在大模型编排下，这个过程可以连续完成：先调用现金流指标，再自动生成 SQL 下钻应收客户；随后读取客户合同中的信用期，把“未回款”区分为正常账期和真实逾期；最后按客户负责人创建待确认事项。财务人员看到的不是一张孤立报表，而是分析过程、查询依据和未确认事项。

收入增长但经营现金流下降
  → 应收增加 2,600 万
     → 其中 1,900 万来自 8 家客户
     → 5 家超过合同信用期，3 家为集中开票未到期
  → 存货增加 1,100 万
     → 其中 720 万为两款产品的备货
  → 应付增加 600 万，部分抵消资金占用

结论：重点不是“加强回款”，而是先处理 5 家超期客户，
并复核两款产品的备货计划。

最后这一步很重要。“加强回款管理”没有责任对象，也无法验收。具体到五家客户、金额、合同期限和负责人，分析才进入经营动作。

九、预测不要只给一个数字

AI 财务项目很容易把“预测下季度利润 3,024 万”放在大屏中央，却不说明误差和假设。单点预测看起来干脆，管理上却不够用。

财务预测至少要有基准、乐观和谨慎三种情景，并明确关键变量：销量、价格、汇率、原材料成本、回款周期。每次预测还要保留生成时点和实际结果，按月回测平均绝对百分比误差、方向判断准确率以及区间覆盖率。

如果业务人员临时调整预测，也要记录调整前数值、调整理由和最终结果。时间积累后，团队才能知道模型在哪些业务上可靠，人工判断又在哪些情况下更有价值。

十、上线时重点盯住四条边界

权限跟着原系统走

区域经理只能查看本区域，成本明细只对授权岗位开放。AI 问答不能绕过原有数据权限。模型检索、缓存和日志也要使用同一套权限标识。

敏感字段在进入模型前处理

银行账号、身份证号、个人薪酬、未公开交易等信息应按场景脱敏或排除。是否可以使用外部模型，需要结合公司制度、合同条款和数据部署方式判断。

每个数字都能点回明细

分析页面要同时保存指标版本、数据批次、筛选条件和生成时间。用户点击“应收增加 2,600 万”，应当看到构成这笔金额的客户和单据，而不是只看到一段自然语言解释。

AI 不直接改账

自动生成分析、待办和调整建议没有问题；自动过账、核销、付款或修改信用额度，则必须经过授权审批。模型输出应进入建议区，不能直接覆盖正式财务字段。

十一、从一张月度异常表开始，八周验证价值

不必先做一个覆盖全集团的平台。找一张财务团队每月都在维护的异常表，例如毛利异常、逾期应收或费用超预算，拿它做试点更容易算清收益。试点要同时有业务负责人、财务口径负责人和数据产品负责人，避免最后只有技术团队验收自己。

验收不要看生成了多少份报告，而要看五个指标：从关账到首版分析的时间、定位一项异常所需的人工操作、自动生成 SQL 的复核通过率、被业务确认的有效异常比例、结论回到原始明细的覆盖率。如果报告写得更快，但财务仍要逐条核数，项目还没有真正完成。

试点达标后再向老板申请第二阶段预算，材料也不必厚：旧流程与新流程的耗时对比、发现的真实问题、避免或释放的金额、仍需解决的数据障碍，再加下一阶段要扩展的两个场景。用已经发生的结果争取支持，比用一张宏大的平台蓝图有效得多。

最后

AI、财务分析和大数据放在一起，并不意味着要做一套无所不知的系统。更现实的目标是：老板把经营问题和时效目标定清楚，财务把指标口径定清楚，数据平台把事实算准，大模型受控地写 SQL、调用工具和整理材料，业务负责人对原因和行动负责。

先让一个问题从报表总额顺利走到查询语句、订单、合同和责任人，再扩展到更多指标。这样做出来的不是一篇更漂亮的月报，而是一条能自动运行、经得住追问，也能推动实际动作的分析链。