What Does Finance Look Like When It Runs on Snowflake’s Data Platform?当财务部门运行在 Snowflake 数据平台上时，会呈现出怎样的面貌？
First in a series on the future of finance at Snowflake. We start with a concrete example: how our Office of the CFO turned cash application from a multi-day manual grind into a same-day, automated, fully auditable process and reclaimed 250+ hours a month.这是 Snowflake 财务未来系列文章的第一篇。我们从一个具体的例子开始：我们的 CFO 办公室如何将现金核销流程从耗时数天的手工苦差事，转变为当天完成、自动化且完全可审计的流程，并每月节省了 250 多个小时。
The Future of Finance Is One Governed Platform财务的未来在于统一的治理平台
For most of finance’s history, the function has been organised around hand-offs. Planning data lives in one system, the ledger in another, the bank feed in a third, collections in a spreadsheet, and reconciliation in whatever tool happens to be open. Every month, teams spend their best hours moving data between these systems, reconciling the copies, and arguing over which one is the source of truth. By the time the numbers are trustworthy, the moment they described has already passed.在财务职能的大部分历史中，其运作方式都是围绕着工作交接展开的。规划数据存在一个系统中，总账在另一个系统中，银行流水在第三个系统中，催收在电子表格中，而对账则是在当时打开的任何工具中进行。每个月，团队都要花费最宝贵的时间在这些系统之间迁移数据、核对副本，并争论哪一个才是事实来源。当数字终于变得可信时，它们所描述的时刻早已过去。
We think the future looks different. When every finance team like FP&A, accounting, treasury, collections, reconciliation, cash application runs on a single governed data platform, the function stops reporting on the past and starts acting in real time. The data that powers a report is the same data that powers an automation, with no copies to sync and no hand-offs to break. Building an operational app stops being a heavy engineering project and becomes an extension of the analysis analysts already do in SQL.我们认为未来将大不相同。当财务规划与分析 (FP&A)、会计、财务管理、催收、对账、现金核销等所有财务团队都运行在同一个受治理的数据平台上时，该职能将不再仅仅是报告过去，而是开始实时行动。支持报表的数据与支持自动化的数据是同一份数据，无需同步副本，也不会出现交接中断。构建运营应用程序不再是繁重的工程项目，而成为了分析师在 SQL 中日常分析工作的延伸。
That shift is what we’ve been building toward inside Snowflake’s own Office of the CFO. The rest of this post is a concrete example of it in action.这种转变正是我们一直在 Snowflake 内部 CFO 办公室所构建的目标。本文的其余部分将展示这一实践的具体案例。
A Concrete Example: Cash Application具体案例：现金核销
For most of my career as a data analyst supporting finance teams, cash application was treated as a lagging indicator. Payments landed in the bank, and only then did the manual grind begin: pulling bank feeds, cross-referencing open invoices, chasing down mismatched records, and keying entries into our ERP. By the time cash was finally recognized, days had passed and the business had already moved on.在我作为支持财务团队的数据分析师的大部分职业生涯中，现金核销一直被视为滞后指标。款项进入银行后，繁琐的手工工作才开始：拉取银行流水、交叉核对未结发票、追踪不匹配的记录，并将条目录入我们的 ERP。当现金最终被确认时，几天时间已经过去，业务也已经进入下一阶段了。
That always struck me as backwards. Cash is one of the most real-time operational signals a company has. Cash application is where the bank feed meets the rest of finance: until a payment is matched and applied, treasury can’t see the cash, collections can’t trust the customer’s balance, and the month-end close can’t reconcile it. Speeding it up doesn’t just save analyst hours — it connects those dots in real time.这在我看来总是本末倒置。现金是公司拥有的最实时的运营信号之一。现金核销是银行流水与财务其余部分对接的地方：在付款被匹配和核销之前，财务部门看不到现金，催收部门无法信任客户余额，月底结账也无法完成对账。加快这一流程不仅节省了分析师的时间，更实现了这些节点的实时连接。
What changed for us wasn’t new headcount or a new policy. It was getting finance deeply connected to the Snowflake Data Cloud, building the matching logic out of the analysts’ own manual process, and handing that process back to them to refine.对我们而言，改变的并非是增加人手或制定新政策，而是让财务部门与 Snowflake 数据云深度连接，将分析师自身的手工流程转化为匹配逻辑，并将其交还给他们进行优化。
First, four terms:首先，定义四个术语：
- Cash Application: The business process of applying payments to open invoices so revenue can be recognised.现金核销：将付款应用于未结发票以便确认收入的业务流程。
- Payment Matching: The background algorithms that link incoming transactions to our open invoices.付款匹配：将收款交易与我们未结发票进行关联的后台算法。
- Invoice Mapping: The data logic that bridges mismatched identifiers (e.g., linking a partner’s internal billing ID to our own).发票映射：弥合不匹配标识符的数据逻辑（例如，将合作伙伴的内部账单 ID 与我们自己的 ID 相关联）。
- Cash Application Workbench (CAW): The analyst-facing front end tool, built entirely on Streamlit in Snowflake, that ties this ecosystem together.现金核销工作台 (CAW)：完全基于 Streamlit in Snowflake 构建的面向分析师的前端工具，将整个生态系统连接在一起。
Why Cash Application Was Our Breaking Point为什么现金核销曾是我们的瓶颈
At Snowflake’s scale, our finance team processes more than 10,000 bank payments every month across 8 legal entities and 6+ currencies. Before automation, manually matching these transactions consumed over 200 hours of analyst time each month. Two distinct challenges made it painful.在 Snowflake 的规模下，我们的财务团队每月处理超过 10,000 笔银行付款，涉及 8 个法人实体和 6 种以上货币。在自动化之前，手动匹配这些交易每月消耗分析师 200 多个小时。两个突出的挑战让这项工作变得痛苦。
- The Marketplace Problem (Many-to-Many Complexity). Our largest cloud marketplace partner consolidates hundreds of customer payments into a single bulk disbursement and uses its own proprietary invoice numbering, that shares no direct relationship with our ERP numbers. Historically, matching one bulk payment meant cross-referencing marketplace billing reports, CRM contracts, and ERP invoices by hand, consuming upwards of 45 minutes per disbursement, with an automated match rate of effectively 0%. The real hurdle wasn’t mismatched text strings; it was structural cardinality. One marketplace agreement generates many marketplace invoices, which map to many ERP invoices. Any naive data join on that many-to-many relationship produced a cascade of false positives.市场问题（多对多复杂性）。我们最大的云市场合作伙伴将数百笔客户付款合并为一笔大额支出，并使用其专有的发票编号，这与我们的 ERP 编号没有任何直接关系。过去，匹配一笔大额付款意味着需要手工交叉核对市场账单报告、CRM 合同和 ERP 发票，每笔支出耗时超过 45 分钟，自动匹配率实际上为 0%。真正的障碍不在于不匹配的文本字符串，而在于结构上的基数关系。一份市场协议会生成多份市场发票，进而对应多份 ERP 发票。任何对这种多对多关系进行简单的连接都会产生大量假阳性结果。
- The “Haystack” Problem (Cryptic Bank Feeds). For standard enterprise transactions like ACH, wire, EFT credits — the bank feed arrives with heavily truncated, cryptic descriptions, and has to be downloaded manually. Sometimes an invoice number is buried in the text; sometimes it’s a random customer reference; often it’s blank. Legacy automation tools cleared only about 30% of these payments. The remaining 70% sat in an exception queue, forcing analysts to hunt through six or more source systems to resolve a single transaction.
Finance teams have tolerated this friction for decades because the alternative — building custom data pipelines, managing infrastructure, and deploying standalone apps — was too heavy an engineering lift.“大海捞针”问题（晦涩的银行流水）。对于 ACH、电汇、EFT 转账等标准企业交易，银行流水提供的描述信息往往被严重截断且晦涩难懂，必须手动下载。有时发票号码隐藏在文本中；有时是随机的客户参考号；通常则是空白。传统的自动化工具只能处理约 30% 的付款。剩下的 70% 进入异常队列，迫使分析师在六个或更多的源系统中搜寻以解决单笔交易。财务团队几十年来一直容忍这种摩擦，因为替代方案——构建自定义数据管道、管理基础设施和部署独立应用程序——工程负担太重了。
The Breakthrough: Building Solutions Where the Data Lives突破：在数据所在之处构建解决方案
That heavy lift is exactly what a single platform removes. The entire cash application pipeline runs as SQL on Snowflake, productionised via dbt, and surfaced through an app built with Streamlit in Snowflake. No external compute, no machine learning infrastructure, no middleware.统一平台正好解决了这一沉重的负担。整个现金核销管道作为 Snowflake 上的 SQL 运行，通过 dbt 实现生产化，并通过使用 Streamlit in Snowflake 构建的应用程序呈现。无需外部计算、无需机器学习基础设施、无需中间件。
The secret weapon is data proximity. Because our bank feeds, ERP data, CRM contracts, and marketplace reports already live inside Snowflake, the matching logic runs directly alongside the data it needs — executing in under 60 seconds with no ETL lag, no synchronization delays, and no debate over the source of truth. Removing data movement between third-party systems eliminates the latency, reliability, and security risks that come with it. The single, unified platform is the entire game.秘诀在于数据邻近性。由于我们的银行流水、ERP 数据、CRM 合同和市场报告已经存在于 Snowflake 中，匹配逻辑直接在所需数据旁边运行——在 60 秒内执行，没有 ETL 延迟，没有同步滞后，也不会对事实来源产生争议。消除第三方系统之间的数据移动，消除了随之而来的延迟、可靠性和安全风险。单一的统一平台是解决问题的关键。
The Architecture: Dual-Track Automation架构：双轨自动化
We engineered two parallel automation tracks. Both were designed to be explainable, overridable, and audit-compliant. Every match is fully traceable. Analysts can correct errors via the UI without touching code我们设计了两条并行的自动化轨道。两者都被设计为可解释、可覆盖且符合审计要求。每一项匹配都是完全可追溯的。分析师可以通过 UI 纠正错误，而无需触及代码。
Track 1: A Mapping Algorithm Built From Scratch轨道 1：从零构建的映射算法
To solve the marketplace problem, we built a 5-step pipeline that constructs a clean, deterministic mapping between marketplace IDs and ERP IDs straight from the data with no shared key required.为了解决市场问题，我们构建了一个 5 步管道，直接从数据中构建了市场 ID 和 ERP ID 之间清晰、确定性的映射，无需共享键。
Here’s the trick in one picture: a single bulk wire arrives bundling hundreds of payments under the partner’s own invoice IDs. We line those invoices up against our open ERP invoices and rebuild the link by agreement, date order, and amount so the bulk payment ties back, invoice by invoice.诀窍用一张图即可说明：一笔大额电汇到达，将数百笔付款捆绑在合作伙伴自己的发票 ID 下。我们将这些发票与我们的未结 ERP 发票对齐，并按协议、日期顺序和金额重建链接，从而将大额付款逐笔对应回发票。
This mapping feeds our core payment matching engine, which handles disbursement-level anomalies. A disbursement is primarily identified by its bank trace ID; if that’s missing, the system dynamically falls back to analysing split disbursement amounts.这种映射为我们的核心付款匹配引擎提供支持，该引擎处理支出层面的异常情况。支出主要通过银行追踪 ID 识别；如果缺少该 ID，系统会动态回退到分析拆分的支出金额。
The result: the automated match rate jumped from 0% to 95%+, unlocking same-day cash application and reclaiming 60 hours a month.结果是：自动匹配率从 0% 跃升至 95% 以上，实现了当天现金核销，每月节省了 60 小时。
Track 2: The 7-Algorithm Waterfall Cascade轨道 2：7 级算法瀑布流
For standard enterprise payments, the ingestion layer first standardizes and enriches raw bank data across all eight legal entities, then runs transactions through seven distinct matching algorithms in strict priority order.对于标准企业付款，摄取层首先标准化并丰富所有八个法人实体的原始银行数据，然后按严格的优先级顺序通过七种不同的匹配算法运行交易。
The example below shows the idea: messy bank text enters on the left, and each line is caught by the first rule that fits like — an exact invoice number, a customer prefix, a smart amount apply — and anything left over routes to the analyst review queue.下例展示了这一理念：凌乱的银行文本从左侧进入，每一行都被第一个符合规则的算法捕获（如精确发票编号、客户前缀、智能金额应用等），而剩下的任何内容则路由到分析师审核队列。
Each algorithm strips out its successful matches before the next tier runs. This waterfall approach eliminates double-matching and ensures only the highest-probability candidates move forward. Every matched payment is stamped with metadata identifying the exact algorithm that cleared it, providing an instant audit trail.每种算法在下一层运行之前会剔除其成功的匹配项。这种瀑布式方法消除了重复匹配，并确保只有最高概率的候选者进入下一阶段。每笔匹配的付款都带有标识其清除算法的元数据，提供即时的审计追踪。
The Analyst Interface: Cash Application Workbench分析师界面：现金核销工作台
To catch late-arriving transactions, the pipeline uses a rolling 2-day execution window. Technology doesn’t replace the human element; it empowers it. We surface the entire pipeline to our team through the Cash Application Workbench (CAW), built with Streamlit and running natively inside Snowflake.为了捕获延迟到达的交易，管道使用了滚动 2 天的执行窗口。技术不会取代人为因素，而是赋能于人。我们通过现金核销工作台 (CAW) 向团队呈现整个管道，该工作台使用 Streamlit 构建，并在 Snowflake 内部原生运行。
Because the CAW lives inside Snowflake, there’s no separate web hosting, no API management, and no external security perimeter to defend. The app inherits Snowflake’s role-gated data governance out of the box. Analysts can review exceptions, confirm true positives, and flag false positives, while only authorised users can trigger final payment execution back into our ERP.由于 CAW 存在于 Snowflake 内部，因此无需单独的 Web 托管、无需 API 管理，也没有需要防御的外部安全边界。该应用程序直接继承了 Snowflake 基于角色的数据治理功能。分析师可以审查异常、确认真阳性并标记假阳性，同时只有授权用户才能触发最终的付款执行并回写到我们的 ERP 中。
The Results: Scaling Operations Without Scaling Headcount结果：在不增加人手的情况下扩展运营
Connecting the Cash-Flow Dots连接现金流节点
Faster matching isn’t the point — it’s the enabler. Because cash application is the hinge between the bank feed and the rest of finance, collapsing the cycle from 24–48 hours to same-day pays off well beyond the analyst team:更快的匹配不是目的，而是手段。由于现金核销是银行流水与财务其余部分之间的枢纽，将周期从 24-48 小时缩短到当天完成，其收益远不止于分析师团队：
- Quicker cash recognition, quicker cash management. When 95%+ of payments are matched and applied the same day, the treasury sees an accurate, attributed cash position immediately. Cash you can’t see is cash you can’t deploy. Same-day recognition sharpens liquidity visibility, forecasting, and working-capital decisions.更快的现金确认，更快的现金管理。当 95% 以上的付款在当天匹配并核销时，财务部门能立即看到准确的、已归属的现金状况。看不见的现金就是无法调配的现金。当天确认提高了流动性可见性、预测准确度和营运资金决策水平。
- Real-time account accuracy. Balances post as payments are clear, so customer accounts reflect reality. Collections work the right accounts instead of chasing invoices that are already paid (which used to create customer satisfaction issues). Wrongful dunning falls, and DSO improves on cleaner data rather than more follow-up.实时的账户准确性。余额随付款清算而过账，因此客户账户反映了真实情况。催收部门处理的是正确的账户，而不是追逐已经支付的发票（这过去曾导致客户满意度问题）。错误的催收减少了，DSO（应收账款周转天数）也因更清洁的数据而非更多的跟进工作而改善。
- Daily reconciliation instead of a month-end scramble. Open receivables reconcile every day, so the close no longer starts with a backlog of unapplied cash. The work that used to pile up for the final week is already done.每日对账，而非月底冲刺。未结应收账款每天对账，因此结账不再以未核销现金的积压开始。过去堆积到最后一周的工作现在已经完成了。
Because the entire chain lives in one governed place — SQL, dbt, and a Streamlit app on Snowflake — this real-time flow is configuration, not a re-architecture. The same data that powers the match also powers the reporting.由于整个链条都存在于一个受治理的地方——Snowflake 上的 SQL、dbt 和 Streamlit 应用程序——这种实时流是配置的结果，而非重新架构。支持匹配的相同数据也支持报表生成。
One Tight Takeaway一个核心要点
The lesson generalizes well past cash application: problems that look like complex workflow friction are usually data alignment problems in disguise. Payment matching isn’t fundamentally an AI/ML problem; it’s a data architecture problem. Once your data is joined in one governed space, clean structures, robust fallback logic, and a secure human-in-the-loop interface routinely outperform opaque models that can’t be audited or explained. You likely already own the hardest part of the puzzle: the data. The win comes from running your automation and your app exactly where that data and its permissions already live.这一经验可以推广到现金核销之外：看起来像复杂工作流摩擦的问题，通常本质上是数据对齐问题。付款匹配从根本上不是 AI/ML 问题，而是数据架构问题。一旦数据在受治理的空间中连接起来，清晰的结构、稳健的回退逻辑和安全的“人在回路”界面，通常会优于无法审计或解释的不透明模型。你可能已经拥有了难题中最困难的部分：数据。获胜的关键在于，在你数据及其权限所在的地方运行你的自动化程序和应用程序。
Written by Harshit Garg, Analyst, Finance Analytics作者：Harshit Garg，财务分析师，财务分析部门
