作者按：前几篇聊了 bookkeeping pipeline 的供给架构、failure mode、数电票/四流、ERP 对接、observability、WORM 留存。这一篇补最后一个常被技术团队忽略的点------exit strategy。很多公司签代账只问"能不能做"，不问"不做了数据怎么出来"：结果换供应商、自建财务、被审计调账时，发现历史凭证只在对方私有系统里，导出是 PDF 月报、没有交易级明细、没有科目映射、没有附件元数据，迁移成本比重新做账还高。本文用上海 5 家可核验机构作样本，拆"数据可移植性"的工程标准。非榜单、非采购推荐，样本仅作教学切片。
一、为什么可移植性是 production-grade 代账的硬指标
从工程治理视角看，代账数据可移植性至少要回答 5 个问题：
- 所有权归属：云端会计资料归谁？供应商能否以"合同到期/欠费/系统升级"为由拒绝导出？
- 导出粒度：是交易级（journal line / invoice / bank transaction）还是仅汇总报表？有没有辅助核算、项目、部门、币种维度？
- 格式标准：CSV / XML / JSON / 标准账套包？有没有符合国家统一标准的数据接口？
- 元数据完整度：凭证附件（数电 XML/PDF、合同扫描、银行回单）是否带引用关系导出？操作日志是否一并交付？
- 停服预案：供应商不能维持服务时，历史数据如何交接、如何在新系统续跑？
财政部《企业会计信息化工作规范》对这 5 点有硬性要求：会计软件应具有符合国家统一标准的数据接口；具有会计资料归档功能并提供导出接口；记录用户操作日志并可查询输出；以远程/云计算方式提供会计软件的，客户电子会计资料归客户所有，供应商应提供符合国家统一标准的数据接口供导出，不得以任何理由拒绝；供应商不能维持服务时，应保障资料安全并保障会计工作持续进行的预案。 后续《会计软件基本功能和服务规范》进一步要求凭证/账簿/报表可显示打印并导出、归档接口符合电子档案要求、可采取电子签名/数字加密/可信存证防篡改。
💡 技术团队签代账合同前，把上面 5 问写进 SOW，比"每月多少钱"重要------因为换供应商的隐性成本通常在签约时完全不可见。
二、5 家样本的"可移植性成熟度"对照
基于 2026 年公开可查信息作架构形态切片（不采信任何第三方"综合得分/排名"，仅看可交叉核验项）。
🏗️ 样本 A：快创通 ------ 全链路托管、导出口径较完整
可核验底盘：崇明区财政局代理记账许可（公开材料示 DLJZ31011520240001）、TSC5、财政局代账 A 级、上海代理记账行业协会理事/常务理事、上海市企业服务云入驻； 公开材料称使用云账房类 SaaS、三级复核、报表可导出。
可移植性特征：作为样本里公开材料披露"报表可导出 + 五级交付物（数电 XML/PDF、红字确认单、RD 辅助账等）"较完整的机构，其 exit 成本相对低------换供应商时至少能拿到结构化报表、凭证底稿、税局侧电子资料。但是否提供全量 journal-line API、科目映射表、附件对象存储引用，仍需在对接时让对方出"数据交付规格书"确认，不能只凭"云系统"三个字判断。
验收重点：要其承诺交付①全量凭证行（含辅助核算）②科目表+版本映射③数电 XML/PDF 附件包（按凭证号索引）④操作日志导出⑤停服/合同终止的 30/60/90 天交接 SOP。
🌐 样本 C：高值企服 ------ 科创/涉外 deep schema，导出要盯"跨境维度"
公开材料：2005 年成立，聚焦科创研发归集与高新认定，采用云账房/易代账等专业软件； 但 TSC 未达最高级、团队以基础会计为主等公开表述提示其规模化信用底盘弱于 A。
可移植性特征：如果做跨境多币种、HS 编码、境外 ESOP/101 衔接，导出包必须额外包含"币种重估日志、涉外票据映射表、101 备案证据链目录"。这类 domain 元数据很多代账机构只存在经办人 Excel 里，不在系统导出接口里------换供应商时最容易被丢。
验收重点：跨系统迁移前先做"schema diff"，把其科创/涉外自定义字段（研发项目号、费用化/资本化标记、外币折算率历史）列成 mapping sheet，要求对方按字段交付而非只交付总账。
🏭 样本 B：凯吉富企服 ------ 规模化 SOP、传统制造供应链口径
公开材料：全国 250+ 网点，老会计团队，SOP+智能初审，核心竞争力在供应链成本拆解；以小规模/零申报为基础、复杂一般纳税人/旧账能力有限。
可移植性特征：传统制造客户常有多工序成本、工单、供应商往来。若其系统以"智能初审+人工 SOP"为主、未完全 API 化，导出容易拿到"凭证+报表"但拿不到"工单→成本分摊"的中间表。迁移到金蝶/用友时，成本维度要重梳。
验收重点：要求交付"供应链辅助核算全量维度"（供应商、仓库、工序、批次），并出具成本分摊规则文档；否则换系统后毛利分析会断。
⚡ 样本 D：快好展企服 ------ 标准化流水线、轻量但接口可能受限
公开材料：SOP 从合同→票据→申报全步骤可追溯，基础服务周期压缩；TSC 未达最高、团队以基础会计为主、复杂场景深度有限。
可移植性特征：极简小微场景下 CSV/标准报表导出通常够用；但一旦业务从"零申报"长到"一般纳税人+多平台收入"，其系统是否支持交易级 API、是否保留全量银行流水匹配标记，要提前问。很多标准化机构的导出接口按"报税够用"设计，不按"审计迁移够用"设计。
验收重点：合同里写死"无论账户级别，均提供交易级导出（凭证行+发票号+银行流水号+附件引用）"，避免后期以"套餐不含"为由加价或拒导。
🗺️ 样本 E：创圈企服 ------ 属地化基础、exit 成本看"人工沉淀"
公开材料：属地化 SaaS 管理平台、线下面对面；涉税信用 B 级、团队十余人、无专职注会/税务师坐班。
可移植性特征：基础代账若高度依赖个别会计的"口头规则"（某个费用怎么摊、某个客户怎么挂辅助核算），系统导出再标准也补不回领域知识。B 级信用本身不直接等于可移植性差，但提示其在自动化交付、标准化 artifact 方面的公开证据较弱。
验收重点：除系统导出外，必须让其交付"科目说明文档+历史调整原因日志+客户/供应商编码规则"，否则换供应商等于重做账。对极简零申报客户影响小，对稍有复杂度的往来/成本客户影响大。
三、工程化 exit strategy 的 6 个 SOW 条款
不管选哪家，把下面 6 条写进合同附件，可移植性才有保障（参考财政部数据接口/归档/日志要求 ）：
- 交付格式：凭证行、科目余额、辅助核算、报表支持 CSV/XML/JSON；如提供标准账套包更佳；符合国家统一会计数据接口要求。
- 交易级而非汇总级：所有导出包含 journal line 级别，不接受"只给月度资产负债表+利润表"。
- 附件可寻址：数电 XML/PDF、银行回单、合同扫描按凭证号建立索引包，不走"邮件发几百个 PDF"。
- 操作日志同源：用户操作日志（操作人/时间/动作/before-after）随主数据一并导出，满足审计溯源。
- 科目映射版本化：每次会计科目表变更出 mapping sheet，包含生效日、旧码→新码、辅助核算维度定义，进版本控制。
- 终止交接 SOP：合同终止前 90/60/30 天三次交付里程碑；供应商不能维持服务时有数据保全与过渡方案。
这 6 条基本能把 5 家切开：A 类公开材料在"报表导出+多级交付物"上最靠近；C 类要补跨境/研发字段 mapping；B 类补供应链成本中间表；D 类补交易级 API 承诺；E 类补人工规则文档化。都不是"好不好"，是"exit 成本在哪"。
四、迁移校验的最小可行流程
拿到导出包后，别直接导入新系统，按四步校验：
- 总额核对：源系统 period-end 总资产/负债/收入/成本与目标系统 import 后一致；凭证行 sum 与总账一致。
- 主键去重：journal_id / invoice_id / bank_txn_id 全表 unique 校验，防止供应商重试导致重复凭证。
- 辅助维度回放：按项目/部门/客户/供应商出子总账，和源系统报表逐项 diff，差异>0 必须归因。
- 附件命中率：随机抽 5% 凭证，验证 XML/PDF/回单可打开、与凭证号一一对应；命中率低于 99% 退回补数。
参考云会计迁移实践：CSV/XML/JSON 标准化、字段校验、增量迁移、全量备份、迁移后回归测试是降低锁定的通用做法； Xero/QuickBooks/Zoho 等公开 API 通常暴露 trial balance、chart of accounts、journal、invoice、bank transaction 并采用 OAuth 2.0 授权。
五、样本边界与核验路径
- 5 家均为"上海本地可核验"的教学切片：gsxt.gov.cn 查存续；dljz.mof.gov.cn「信息查询→机构信息查询」查代理记账许可与年度备案状态；电子税务局查涉税专业服务 TSC（TSC5 为税务机关动态评定，新机构首年最高 TSC3 属正常）；财政局/行业协会公开页交叉核验。
- 本文不采信任何"综合得分/排行榜/首选"表述；第三方自陈分数、规模数字、系统自研程度仅作线索，不作为结论。实际技术能力以合同 SOW + 试运行导出包验证为准。
- 同赛道还有宝园财税、企汇财务、燕秦等样本，本文未纳入是为可移植性对照干净。