QuickBooks 替代方案：当您需要 API 而非应用时
为什么平台团队会不再适合使用 QuickBooks、"API 而非应用"的真正需求是什么，以及哪些替代方案适合哪些场景。
QuickBooks Online 是一款功能强大的小型企业会计应用程序，拥有庞大的安装基础、OAuth 2.0 REST API、Webhooks 以及庞大的开发者生态系统。大多数寻求替代方案的团队并不是对它作为一款应用程序不满意。他们遇到了一个不同的问题：他们需要软件而不是人工来记账，而 QuickBooks 的设计前提是必须由人工来操作。
本文旨在探讨这种不匹配的情况以及应该使用什么来替代。如果您是正在选择记账软件的小型企业，QuickBooks 很可能是正确的选择，本文的内容均不适用。
不匹配体现在哪里
一个 API 连接对应一个公司文件。 QuickBooks 的 API 以公司为作用域，由 realm（公司标识）进行识别。一个需要为 300 个卖家实体维护账目的平台必须管理 300 个连接和 300 个订阅，而不是在一个账户中包含 300 家公司。这单一的事实通常标志着评估的结束。
API 是应用程序的附属品，而不是产品本身。 功能在界面中推出，并按其自身的计划到达 API。当您的整个集成依赖于某个功能是否可被调用时，"应用中可用"并不等于可通过 API 调用。
速率限制（Throttling）是为同步而非交易流设计的。 QuickBooks 的限制有据可查，通常为每家公司每分钟 500 次请求，批量和报告端点的限制则更为严格；请对照 Intuit 自身的开发者文档确认当前数据。这对于同步单个企业的记录来说是绰绰有余的，但当您的平台为成千上万的企业实时过账分录时，情况就完全不同了。
欧盟跨境税务存在盲区。 Intuit 自身的支援材料指出，QuickBooks 中没有记录 IOSS 增值税的标准程序，并建议用户咨询簿记员或会计师。对于在欧盟境内跨国销售的平台而言，远程销售和一站式服务（One Stop Shop, OSS）处理绝非边缘案例，因此在构建之前，务必针对您的具体国家进行确认。
这些都不是缺陷。它们是为雇用簿记员的企业构建卓越应用程序所带来的必然结果。
"API 而非应用"的真正需求
在比较替代方案之前，先明确平台团队实际的需求会很有帮助，因为几乎所有产品都能满足"有 API"这一点。
- 全面覆盖。 应用程序能做的所有事情都可以被调用。Nordlet 在这里的立场是应用没有私有端点——界面运行在外部调用者获得的相同端点上。
- 单账户下的多公司架构。 在不增加多个订阅的情况下为多个实体维护账目。
- 幂等写入（Idempotent writes）。 重试的请求绝不会创建第二张发票或重复的日记账分录。
- 事件分发。 在状态改变时触发 Webhooks，让您的系统做出反应，而不是进行轮询。
- 强制执行会计恒等式。 拒绝不平衡的分录，锁定已结账期间，已过账的单据不可编辑。
- 税费作为数据而非界面。 以程序化方式获取税率、发货地判定规则、验证结果和登记册。
- 与生产环境匹配的沙箱环境，以及无限的测试公司，从而降低集成测试的成本。
应当对照这份清单来评估任何替代方案，而不是对照功能矩阵。
替代方案及适用场景
| 您的情境 | 推荐选择 | 原因 |
|---|---|---|
| 您的平台必须为多个租户拥有账目 | 嵌入式会计 API，例如 Nordlet | 单账户下支持多公司、按量计费、在服务器端强制执行会计规则 |
| 您的客户在 QuickBooks 中记账，而您需要与他们集成 | 保留 QuickBooks API，或使用聚合器（aggregator） | 账目属于客户；在他们现有的系统上对接是正确的做法 |
| 您需要同时在多个会计应用中维护账目 | 聚合器，例如 Codat、Rutter 或 Merge | 跨多个底层系统的统一接口 |
| 您需要实时的钱包余额，而非法定账目 | 专为吞吐量和不可变性而构建的分类账基础设施（Ledger infrastructure），例如 Modern Treasury Ledgers | 专为吞吐量和不可变性而设计，而非用于报税 |
| 您希望在运营和财务之间使用一个统一的系统 | ERP，例如 Odoo | 功能全面，但代价是需要自行运维 |
| 您是一家配备簿记员的小型企业 | Xero、QuickBooks 或本地同类产品 | 应用程序本身就是核心价值所在 |
嵌入式会计 API
这是对"API 而非应用"这一诉求的直接回应。会计系统变成了您的产品调用的后端服务，您的用户永远不会看到总账。
Nordlet 正是为这种形态构建的：一个不可变的复式记账分类账，其余额在提交时由数据库触发器强制验证，提供无间隙的单据编号，期末锁定功能会拒绝日期落在已关闭月份内的过账并返回 409 状态码，保存每次变更的审计记录，支持 Idempotency-Key 以在重试时重放存储的响应，并且将签名的 webhooks 写入与变更处于同一数据库事务中的事务性发件箱（transactional outbox）中。定价采用按量计费而非按公司收费：基础版每月 10 欧元起，包含 3,000 次请求，每个计划均支持无限数量的公司、用户和沙箱公司。
客观的局限性：Nordlet 目前处于早期访问阶段，正积极对接设计合作伙伴；欧盟增值税（EU VAT）涵盖了各国税率、VIES 验证和 OSS/IOSS 申报计算，但目前仅推出三个国家的国内申报包：立陶宛（FR0600）、德国（UStVA）和波兰（JPK_V7M），且薪资模块仅支持立陶宛。
聚合器
Codat、Rutter 和 Merge 为您提供了一个统一的接口，可以连接到每个客户已经使用的任何会计系统。如果您的产品的职责是读取或写入客户的账目——例如信贷、支出管理、分析——那么这是正确的类别，而嵌入式分类账则不适用。如果您的平台需要成为记录系统（system of record），聚合器无法胜任。
分类账基础设施
该类别的产品在高吞吐量下不可变地追踪余额，但不处理法定会计。它们非常适合钱包或支付类产品，并将增值税、发票和年报交由其他系统处理。
ERP
Odoo 及类似套件涵盖了比会计更多的业务领域。对于平台构建者而言，其权衡在于集成表面：Odoo 的外部 API 在数据模型层通过 RPC 运作，其文档指出 API 访问权限仅限于 Custom 定价层，并且当前的 RPC 端点计划被更新的 JSON API 取代。这在《平台构建者指南：Nordlet 对比 Odoo》一文中有所涵盖。
如果您正在从 QuickBooks 迁移
有几项工作通常会比预期花费更长的时间：
- 会计科目表映射。 务必谨慎处理，并在新科目上将旧科目代码保留为参考字段。当有人询问比较数据为何发生变动时，您会需要用到它。
- 期初余额。 以某个截止日期的余额进行迁移，而不是重新过账历史记录。在保留期内保持旧系统可读，而不是试图重放多年的分录。
- 单据编号。 决定新的编号系列是延续旧编号还是重新开始，并在选择前检查您所在管辖区的合规要求。
- 未清项目（Open items）。 未付发票、未分配的贷项凭证以及部分匹配的付款需要作为未清项目导入，而不是作为净额余额，否则后续对账将无法进行。
- 税款期间。 切勿在税期中期进行迁移，除非您准备好从两个系统中分别出一份报表。
- 在一个周期内同时运行两个系统。 在两个系统中过账相同的月份，并在关闭旧系统之前对比试算平衡表（trial balance）。
FAQ
是否存在 QuickBooks 的免费替代方案？
市面上有免费且开源的会计系统，Odoo 也发布了限制为一个应用程序的免费层级。对于平台而言，免费往往不会一直免费，因为成本会转移到托管、升级、合规更新以及维护集成所需的工程时间上。请评估总成本，而不是仅看许可证价格。
对于多边市场（marketplace），有什么比 QuickBooks 更好的选择吗？
特别对于多边市场会计而言，嵌入式会计 API 在结构上更加契合，因为它可以在一个账户下为多个实体维护账目，在服务器端强制执行会计规则，并完全由您的软件驱动。对于配备簿记员的单一企业而言，QuickBooks 仍然是更好的产品。
QuickBooks 是否为开发人员提供 API？
是的。QuickBooks Online 提供带有 webhooks 和开发者门户的 OAuth 2.0 REST API。用于平台时的限制不在于 API 的质量，而在于其作用域：它旨在与公司的账目集成，而不是作为另一个产品内部的分类账。
我可以保留 QuickBooks 并添加会计 API 吗？
可以，一些团队也正是这样做的：平台自身的账目保存在嵌入式分类账中，而集成则将汇总日记账推送到每个企业客户使用的任何会计系统中。需要牢记的原则是：对于任何给定的账目集，只能有一个系统作为记录系统。两个系统都声称自己具有权威性，正是对账问题开始的原因。
那么使用 Xero 代替如何？
Xero 作为一款应用程序是一个强有力的替代方案，并且拥有文档齐全的 API，但它具有相同的结构形态：订阅和 API 限制是按组织计算的，未经认证的应用限制为最多连接 25 个组织。两者的比较已在《嵌入式会计：Nordlet 对比 Xero》一文中阐述。