嵌入式会计：平台的自研与采购抉择
功能范围清单、包含明确假设的成本模型，以及各类方案成立的具体条件。
任何平台最终都会自研总账系统。唯一的区别在于，它是作为一套带有管控机制的系统被刻意设计出来的，还是在三个服务同时读写、谁也无法完全信任的一个 balance（余额）字段中偶然拼凑出来的。
本文旨在帮助你理性做出这个选择。其中将涵盖实际开发所包含的工作内容、不自我欺骗的成本核算方法，以及自研确实是正确选择的特定条件——因为有时自研确实合情合理。
此处“嵌入式会计”的定义
嵌入式会计意味着账目直接存在于你的产品内部，而非某个需要单独打开的外部应用程序中。当业务事件发生时，你的软件会自动记录分录，用户通过你的界面查看所需内容，且月末时无需导出电子表格交给簿记员。
对于平台而言，这至少涵盖：收到的买家付款、应付给卖家的金额、赚取的佣金、支付处理费用、你收取的费用以及底层商品供应涉及的增值税、退款、拒付（chargeback）、保证金、出金（payout），以及所有这些与银行或支付服务商的对账。
自研的实际工作量
总账本身只占很小一部分。各团队往往只为第一项做好了规划，随后才发现后面还有一长串工作。
| 组件 | 涉及内容 |
|---|---|
| 日记账与科目 | 借贷平衡的分录、科目表、科目类型、期初余额 |
| 不可变性 | 仅追加（append-only）存储、冲销与更正工作流、禁止原地修改（in-place edits） |
| 期间控制 | 结账、锁定、拒绝逾期过账、带审计记录的受控重新开启 |
| 幂等性 | 键（keys）、先前响应的存储、针对变更载荷的冲突检测 |
| 金额处理 | 精确的小数或最小货币单位算术、货币代码、汇率及其来源、舍入科目 |
| 增值税引擎 | 具生效日期的各国家/地区税率、供应地、反向征税（reverse charge）、视同供应商规则、免税 |
| 增值税号验证 | 对照官方注册库进行验证、缓存、时间戳、请求标识符、失败时的手动复核队列 |
| 单据 | 发票、贷方通知单、按系列和年份连续无间隙编号、PDF 渲染、交付 |
| 电子发票 | 结构化格式（如 EN 16931 UBL），以及各强制要求的国家/地区本土格式 |
| 银行数据导入 | 对账单导入或授权的银行连接、已导入交易的去重 |
| 对账 | 匹配规则、评分、部分匹配、可由人工处理的异常 |
| 出金 | 支付文件生成、出金批处理、将出金与底层交易项目进行匹配 |
| 报表 | 试算平衡表、资产负债表、利润表、现金流量表、增值税汇总表、账龄分析 |
| 税务登记簿与申报表 | 当局接受的格式所要求的各国家/地区报表 |
| 审计 | 每次变更的操作人、操作、实体及变更内容，支持查询 |
| 保留与导出 | OSS 记录的十年保留期、完整数据导出、可抗辩的归档 |
当大多数团队说“我们要自研一个总账”时，他们脑海中想象的其实大约只是这十七行中的两行。
诚实地核算成本
此处的具体数字取决于你的团队，因此请将以下内容视为一种方法论而非报价。对照上面的组件，根据你团队自身的开发速度为每个组件估算所需的人周（engineer-weeks），然后套用常规估算容易遗漏的三项修正。
修正一：合规组件并非一劳永逸。 税率会变、门槛会变、格式会变，欧盟的“数字时代的增值税”（VAT in the Digital Age）一揽子计划更是带来了具有时间节点的要求：2027年1月1日起生效的 OSS 和 IOSS 变更、2028年7月1日起扩大的平台规则、2030年7月1日起实施的跨境数字报告。选择自研意味着你必须承担每一次迁移。
修正二：正确性维护的工作量远超功能开发。 第一个版本只处理快乐路径（happy path）。长尾场景包括出金后的退款、部分退款、数周后才到达的拒付、货币舍入、重复的 Webhook，以及与你的记录不符的结算文件。日历时间往往就在这些地方悄然耗尽。
修正三：会计师是利益相关者，而非评审员。 财务专业人士不愿签字的账目就是未完成的，而这种反馈往往在开发后期才到来。
一个实用的合理性检查方法是：对最小可行自研版进行定价——包括总账、更正、期间锁定、幂等性、金额处理、单一国家的增值税、发票、银行导入、匹配以及基础报表集，并将其与按量计费服务的一年费用进行比较。Nordlet 的公开定价方案起步价为每月 10 欧元（包含 3,000 次请求），最高为每月 300 欧元（包含 200,000 次请求）。如果自研的成本仅占单个工程师年薪的一小部分，那么自研确实有理可依；如果成本需要耗费几个工程师年外加持续不断的维护，两者的性价比便毫无悬念，并且规则每变一年，这种差距就会进一步拉大。
什么时候自研确实是正确的
存在三种真正合乎情理的情况。
你的总账就是你的产品。 如果你正在构建支付平台、银行产品或钱包，且并发情况下的余额行为是你的核心差异点，那么总账就是核心资产，应当掌握在自己手中。此时应考虑总账基础设施产品，而不是从零开始构建，并保持法定会计的独立性。
你的商业模式不适合任何现有会计系统。 某些平台具有真正独特的结算结构——具有条件释放的多方分账、带分阶段里程碑的托管（escrow）、复杂的保证金政策。如果没有现成产品能够模拟且变通方案比自研更糟糕，那就选择自研。
你的交易量使得按量定价不再划算。 在极端高的交易速率下，按请求计费的模式将失去吸引力。在下结论前务必用实际数据进行建模，因为此处的“极端”比大多数平台实际达到的量级要高得多。
什么时候采购是正确的
当会计工作是必需的但又无法带来差异化时，采购就成了赢家——这也是最常见的情况。没有人会因为你的日记账分录写得优雅而选择你的平台。他们只有在账目出错时才会注意到这一点。
当你的业务义务涉及多个国家时，采购同样是正确的选择。各国的增值税规则、凭证保留以及电子发票强制要求是一项长期的持续维护工作，而供应商能够将这项工作的工作量分摊到每一位客户身上。Nordlet 将支持 VIES 验证的各国家/地区欧盟增值税、OSS 和 IOSS 申报计算、i.SAF 登记簿以及用于 Peppol 的 EN 16931 UBL 作为产品本身交付，而不是作为一个需要排期的项目。
大多数团队最终选择的中间道路
实际的答案通常并非二选一，而是：采购总账，自研工作流。
会计后端负责分录、税务处理、单据、期末结账和审计追踪。你的产品负责用户看到的一切以及平台特有的业务规则——何时释放资金、保证金政策为何、如何处理争议、卖家后台展示什么。你在资金承诺的时刻调用会计 API，并保留那些真正属于你自己的业务逻辑。
与其它替代方案相比，这条边界也能更好地适应未来的变革。新国家/地区的加入变成了配置工作，而不是一个新项目。新的出金政策由你的代码控制，而无需向供应商提交功能请求。
做出承诺前需要决定的事项
- 你的总账是差异化优势还是法定义务？ 请诚实面对；绝大多数都是义务。
- 涉及多少个国家，每个国家的要求是什么？ 仅包含税率、还是包含申报表、登记簿或提交功能？
- 你的更正机制是怎样的？ 出金后的退款和延迟的拒付往往是暴露出设计缺陷的场景。
- 谁来在账目上签字？ 在设计敲定前让该人员参与进来，而不是事后。
- 十年的保留计划是什么？ OSS 记录必须从交易发生当年结束之日起保留十年，而归档是一套系统，而非简单的备份。
- 三年后的迁移会是什么样？ 双向皆是如此。在第一天就构建好测试导出功能并确保其持续可用。
FAQ
构建一个平台总账需要多长时间？
发布能够过账平衡分录的首个版本可能只需几周时间。但要构建一个能够处理出金后退款、延迟拒付、多币种舍入、重复服务商 Webhook、期末结账以及会计师认可的审计功能的版本，则需要花费相当长的时间，而且维护工作永无止境。请按照后者的标准进行估算，因为这才是生产环境的真正含义。
我们可以先用一个 balance 字段，以后再迁移吗？
你可以这样做，许多团队也确实这么做了，但请做好准备，迁移的难度将超过最初的自研。要想从一个可变的余额中重建历史记录，前提是你保留了改变该余额的每一个事件——也就是说，这前提是你本来就已经拥有了一个总账。
嵌入式会计 API 能取代我们的财务团队吗？
不能。它消除了手动记账和对账的工作。仍然需要有人来执行月末结账、复核异常、做出业务判断以及提交申报表。
如果总账是不可变的，GDPR 问题该如何解决？
将货币事实和化名引用保留在不可变记录中，将个人详细信息保存在具有自身保留和删除流程的独立系统中。不可变性适用于财务事件，而非附加其上的每一个属性。
开源会计软件是折中的中间方案吗？
这是一个现实的选项，但它改变了成本的形态而非消除了成本：你需要自行承担托管、升级、各国家/地区的本地化以及合规更新。在将节省的许可证费用视为全部收益之前，请先对这些成本进行估算。