先做好数据接入，再谈连接器数量:Rexfin 为何不急于搭建 200 个连接器

看看大多数财务软件是如何被推销的，你会发现几乎每份演示文稿里都有同一张幻灯片:满墙的品牌标志。QuickBooks、Xero、NetSuite、Sage、Plaid、Snowflake,还有几十个别的名字，仿佛连接的广度本身就是产品。这个故事很好讲，但维持这个故事的代价很高:每新增一个标志，就多一个要维护的 API、多一套要照看的鉴权流程、多一种该系统标注科目表方式带来的边界情况。我们连接了当前对客户最重要的主流会计平台、银行数据源和数据仓库。我们不会去追求那份完整清单，也不认为你应该希望我们这么做。

护城河不在于连接器数量

一个连接器的标志不会告诉你这件事:从 API 中取出数据是容易的部分。QuickBooks 会毫无怨言地把试算平衡表交给你。真正困难、真正决定模型中的数字能否与账本对上的，是数据到达之后发生的事情:把一家公司常常独特的科目标签映射到统一结构上，发现无法交叉核对的合计数，识别一个文件以千为单位、另一个文件以整数为单位的量纲错位，并把任何有歧义的地方留给人工确认后才当作事实处理。

无论原始数据是通过实时的 QuickBooks 连接进来，还是通过邮件发来的 Excel 工作簿，或是来自我们从未见过的系统的 CSV 导出文件，这套映射和校验层都是一样的。所以我们把精力放在了这里:一套标准化的数据摄取与映射流水线，无论数据从哪扇门进来，都能可靠地把你带到一个已核对的模型。相关结构参见数据摄取的工作原理和标准化原子存储。

上传功能始终可用，它不是备选方案

这是大多数供应商悄悄当作降级方案对待的部分:当你还没搭建好实时连接时会发生什么。对我们来说，这不是一种次等模式。放入一份 Excel 工作簿、实际数字的 CSV,或一份 PDF 财务报表，同样的核对逻辑会运行:交叉核对合计数、检查期间是否合理、标记任何看起来不对的地方，然后数据才会进入你的模型。你今天就可以用手头已有的东西开始建模，无需任何人先去碰 API 密钥。

这不仅仅是便利性的问题。实时连接器默认另一个系统就是事实来源，并且始终如此。而实际情况是，许多财务团队仍然在一张没人真正“系统化”的电子表格上完成大部分规划工作，或者需要在本季度账本导出准备好之前就先做出上季度的董事会材料。把上传当作一等公民而非权宜之计，意味着模型不必等 IT 部门配置好连接才能派上用场。

我们同样不追求通用的文档解析能力

换个方向来承诺“第一天就能解析任何公司任何格式的任何财务文档”会很有诱惑力。我们不做这个承诺。构建一套能可靠处理任意报表全部复杂性的抽取引擎，包括每个发行人独特的版式、每个地区的惯例，是一项真正庞大的工程，过度宣传只会让我们落入与连接器高墙同样的陷阱:技术上成立但实际上不可靠的能力。引导式映射从财务团队已经拥有的格式开始，即电子表格和导出文件，报表解析能力会随着我们不断加固而逐步扩展。

在数字进入你的模型之前拦截错误导入的那些确定性检查，与模型中其他环节拦截错误计算的检查是同一套，参见为什么要用确定性计算。而且由于每一次映射决策和修正都被记录下来，我们每接入一个新工作区，本体就会变得更精细，这是连接器数量无法复制的复利资产。

如果你正在评估我们，这意味着什么

如果你的第一个问题是“你们有多少个集成”,请再问第二个问题:数字到达之后会发生什么。一份看似很长的连接器清单，背后如果只有一层浅薄的核对逻辑，给你的只是一个看起来接好了线、却依然对不上账本的模型。我们宁愿你从一份自己已经信任的电子表格出发，得到一个能核对一致的模型，也不愿你从一条实时数据流出发，六个月后才悄悄发现某条映射规则已经跑偏了。如果你正在带一个新团队上手,入职，第一周会带你走一遍首次导入的样子，更广泛的深入了解 Rexfin 平台专栏涵盖其余内容。

连接器会持续增加，我们会在真实客户需求足以证明维护成本合理时才添加，而不是提前添加。不会改变的是顺序:先做好从你已有系统中可靠摄取数据，再谈连接器广度。