Snowflake数据平台上的财务：现金应用自动化

关于Snowflake财务未来的系列文章第一篇。我们从一具体案例开始：我们的CFO办公室如何将现金核销从耗时数日的手工苦差转变为当天完成、自动化、可完全审计的流程，每月节省250多小时。

财务的未来是一个统一治理的平台

在财务史的大部分时间里，该职能都是围绕交接来组织的。计划数据在一个系统里，总账在另一个系统里，银行流水在第三个系统里，催收在电子表格里，对账则在随手打开的某个工具里。每个月，团队都把最好的时间花在在这些系统之间搬运数据、核对副本，并争论哪个才是真相来源。等到数字可信时，它们所描述的时刻早已过去。

我们认为未来会有所不同。当每个财务团队，如FP&A、会计、资金、催收、对账、现金核销，运行在单一治理数据平台上时，该职能就不再报告过去，而是开始实时行动。驱动报告的数据与驱自动化的数据是同一份数据，没有需要同步的副本，也没有会断裂的交接。构建运营应用不再是繁重的工程项目，而成为分析师已经在SQL中所做分析的延伸。

这一转变正是我们在Snowflake自己的CFO办公室内部一直努力构建的方向。本文余下部分就是这一转变落地的一个具体案例。

一个具体案例：现金核销

在我作为支持财务团队的数据分析师的职业生涯大部分时间里，现金核销都被视为滞后指标。款项到账后，手工苦差才开始：拉取银行流水、交叉比对未结发票、追查不匹配记录，并将分录录入我们的ERP。等到现金终于被确认时，已经过去了好几天，业务早已继续向前。

这一直让我觉得本末倒置。现金是公司拥有的最实时的运营信号之一。现金核销是银行流水与其他财务职能交汇之处：在一笔付款被匹配并核销之前，资金部门看不到现金，催收部门无法信任客户余额，月末结账也无法对其对账。加快这一过程不仅能节省分析师时间——它还能实时把这些点连接起来。

对我们而言，改变并非来自新增人手或新政策。而是让财务深度接入Snowflake Data Cloud，从分析师自己的手工流程中构建出匹配逻辑，并将该流程交回给他们去完善。

首先是四个术语：

• 现金核销： 将付款核销至未结发票，以便确认收入的业务流程。
• 付款匹配： 将入账交易关联到我们未结发票的后台算法。
• 发票映射： 用于桥接不匹配标识符的数据逻辑（例如，将合作伙伴的内部账单ID关联到我们自己的ID）。
• 现金核销工作台（CAW）： 面向前端分析师、完全构建在Snowflake中的Streamlit上的工具，将这一生态系统连接在一起。

为什么现金核销是我们的临界点

在Snowflake的规模下，我们的财务团队每月在8个法律实体和6种以上货币中处理超过10,000笔银行付款。在自动化之前，手工匹配这些交易每月消耗分析师超过200小时。两个截然不同的挑战让它变得痛苦。

1. 市场平台问题（多对多复杂性）。 我们最大的云市场平台合作伙伴将数百笔客户付款合并为一笔批量付款，并使用其自己的专有发票编号，这些编号与我们的ERP编号没有直接关系。过去，匹配一笔批量付款意味着手工交叉比对市场平台账单报告、CRM合同和ERP发票，每笔付款耗费高达45分钟，自动匹配率实际上为0%。真正的障碍不是文本字符串不匹配；而是结构基数。一份市场平台协议会生成许多市场平台发票，而这些发票又映射到许多ERP发票。在这种多对多关系上进行任何简单数据连接都会产生一连串误报。
2. “大海捞针”问题（晦涩的银行流水）。 对于ACH、电汇、EFT入账等标准企业交易，银行流水到达时描述被严重截断且晦涩难懂，且必须手工下载。有时发票号埋在文本中；有时是随机客户参考号；很多时候则是空白。传统自动化工具只能清理约30%的这些付款。剩余70%滞留在异常队列中，迫使分析师在六个或更多源系统中搜寻以解决单笔交易。财务团队数十年来一直忍受这种摩擦，因为替代方案——构建自定义数据管道、管理基础设施并部署独立应用——工程量过于沉重。

突破：在数据所在之处构建解决方案

这种沉重工程正是单一平台所能消除的。整个现金核销管道作为Snowflake上的SQL运行，通过dbt投入生产，并通过使用Snowflake中的Streamlit构建的应用呈现。没有外部计算、没有机器学习基础设施、没有中间件。

秘密武器是数据邻近性。因为我们的银行流水、ERP数据、CRM合同和市场平台报告已经存在于Snowflake中，匹配逻辑直接在它所需要的数据旁运行——在60秒内执行完成，没有ETL延迟、没有同步延迟，也没有关于真相来源的争论。消除第三方系统之间的数据移动，也就消除了随之而来的延迟、可靠性和安全风险。单一统一平台就是全部关键。

架构：双轨自动化

我们设计了两条并行的自动化轨道。两者都被设计为可解释、可覆盖且符合审计要求。每个匹配都可完全追溯。分析师可以通过UI纠正错误，而无需接触代码

轨道 1：从零构建的映射算法

为解决市场平台问题，我们构建了一个 5 步流水线，直接从数据中构建市场平台 ID 与 ERP ID 之间干净、确定性的映射，无需共享键。

用一张图说明诀窍：一笔批量电汇到达，将数百笔付款捆绑在合作伙伴自己的发票 ID 下。我们将这些发票与我们的未结 ERP 发票进行比对，并依据协议、日期顺序和金额重建关联，使这笔批量付款能够逐张发票地对应回去。

此映射为我们的核心付款匹配引擎提供输入，该引擎处理付款级别的异常。一笔付款主要通过其银行追踪 ID 来识别；如果缺失，系统会动态回退到分析拆分付款金额。

结果：自动匹配率从 0% 跃升至 95%+，实现了当日现金入账，并每月节省 60 小时。

轨道 2：7 算法瀑布级联

对于标准企业付款，摄取层首先对所有八个法律实体的原始银行数据进行标准化和增强，然后按严格的优先级顺序让交易通过七种不同的匹配算法。

下面的示例展示了这一思路：左侧输入杂乱的银行文本，每一行都会被第一条符合条件的规则捕获——例如精确发票号、客户前缀、智能金额应用——任何剩余未匹配的都会路由到分析师审核队列。

每种算法在下一层级运行前都会剥离其成功匹配的记录。这种瀑布式方法消除了重复匹配，并确保只有最高概率的候选记录继续向前推进。每笔匹配成功的付款都会被打上元数据标记，标明是哪一具体算法完成了匹配，从而提供即时审计追踪。

分析师界面：现金入账工作台

为了捕获延迟到达的交易，该流水线使用滚动 2 天的执行窗口。技术不会取代人的作用；它赋予人更大的能力。我们通过现金入账工作台（CAW）向团队展示整个流水线，该工作台使用 Streamlit 构建，并原生运行在 Snowflake 内部。

由于 CAW 运行在 Snowflake 内部，因此无需单独的 Web 托管、无需 API 管理，也无需防御外部安全边界。该应用开箱即用地继承了 Snowflake 基于角色的数据治理。分析师可以审核异常、确认真阳性并标记假阳性，而只有授权用户才能触发最终付款执行并回写到我们的 ERP。

成果：在不增加人手的情况下扩展运营

连接现金流的各个环节

更快的匹配并不是重点——它是使能因素。由于现金入账是银行数据流与财务其余环节之间的枢纽，将周期从 24–48 小时压缩到当日，其收益远超分析师团队本身：

• 更快的现金确认，更快的现金管理。当 95%+ 的付款在当日完成匹配和入账时，资金管理部门可立即看到准确、已归属的现金头寸。看不见的现金就是无法调配的现金。当日确认增强了流动性可见性、预测和营运资金决策。
• 实时账户准确性。付款结清后余额即入账，因此客户账户反映真实情况。催收团队针对正确的账户开展工作，而不是追逐已经支付的发票（这过去会造成客户满意度问题）。错误催收减少，DSO 因更干净的数据而改善，而不是依靠更多跟进。
• 每日对账，而不是月末忙乱。未结应收款每天对账，因此结账不再从一堆未入账现金开始。过去堆积到最后一周的工作已经提前完成。

由于整条链路都存在于一个受治理的地方——SQL、dbt 以及 Snowflake 上的 Streamlit 应用——这种实时流转是配置，而不是重新架构。驱动匹配的同一份数据也驱动报告。

一个精炼的要点

这一经验远不止适用于现金入账：那些看起来像复杂工作流摩擦的问题，通常实际上是伪装的数据对齐问题。付款匹配从根本上说不是 AI/ML 问题；而是数据架构问题。一旦你的数据在一个受治理的空间中完成连接，干净的结构、稳健的回退逻辑以及安全的人在环界面，通常都会胜过无法审计或解释的黑箱模型。你可能已经拥有这个难题中最困难的部分：数据。胜利来自于将自动化和应用恰好运行在这些数据及其权限已经所在的地方。

作者：Harshit Garg，财务分析分析师

当财务运行在 Snowflake 数据平台上时，它会是什么样子？最初发表于Snowflake Builders Blog：数据工程师、应用开发者、AI 与数据科学于 Medium，人们在那里通过突出显示并回应这个故事来继续对话。