一物多码的代价，比想象中大
同一个供应商，在报销系统叫全称、在业务系统叫简称、在档案系统又多一个编码，带来的不只是查询麻烦：往来对账要人工合并、应付账龄失真、历史询价断裂、审计要逐笔解释差异来源。《会计信息化工作规范》（财会〔2024〕11号）第十三条要求单位加强会计信息化建设、消除内部数据孤岛，实现会计信息系统与业务系统之间的数据共享与协同——而主数据正是把孤岛连起来的那根线。线本身理不顺，接口开得越多，脏数据流动得越快。
方法论上可以对照国家标准《数据管理能力成熟度评估模型》（GB/T 36073-2018，2018年3月15日发布、2018年10月1日实施）。该标准将数据管理划分为数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准、数据生存周期八个能力域，其中数据标准域下专门设有「参考数据和主数据」过程域，把主数据的唯一性、准确性、一致性作为可评估的管理对象。企业不必为了评估而评估，但这套框架可以直接拿来当治理自查表用。
供应商主数据：申请、查重、审批三道关
把住供应商入库的三道关
- 申请关：业务部门按模板提交全称、统一社会信用代码、开户行账号、开票信息，字段不齐不予受理
- 查重关：以统一社会信用代码做精确匹配，叠加名称模糊匹配，命中即提示合并而非允许新建
- 审批关：财务复核开票信息与合同签约主体的一致性，防止付款账户与签约主体分离
三道关里最容易流于形式的是查重。精确匹配用统一社会信用代码即可，难点在模糊匹配的阈值：太松误报一片，太严漏掉简称变体。务实的做法是把模糊命中的候选结果强制展示给录入人，要求其逐条确认「不是同一家」并填写理由，把仲裁记录与审批单一并留档。审计问起「为什么同一供应商存在两个编码」时，拿得出当时的判断依据。
科目主数据：变更的红线
科目一旦被凭证引用，就进入「历史数据引用」状态，任何变更都可能波及已有账簿。处理原则按变更类型分四种。
| 变更情形 | 允许的操作 | 对历史凭证的影响 |
|---|---|---|
| 名称规范调整 | 允许，仅改显示名称 | 无影响，编码与层级不动 |
| 辅助核算维度调整 | 允许新增维度，谨慎删除 | 新维度只对未来单据生效 |
| 科目停用 | 允许，余额先清零 | 历史凭证保留原科目记录 |
| 科目合并 | 通过结转凭证处理余额后停用旧科目 | 需保留新旧编码映射表 |
核心红线有三条：不改已使用科目的编码与层级；停用优先于删除；合并通过结转凭证处理余额而不是直接删行。此外，财会〔2024〕11号第十七条要求自动审核规则的设立与变更应当履行审签程序并留档备查——费用类型到科目的映射规则属于此类，每次调整都应走审批并留存版本记录，否则凭证映射口径的变化将无从追溯。
治理组织：让每类主数据有唯一责任人
主数据项目烂尾的常见原因不是技术，而是没人负责。建议按数据域指定唯一责任人：供应商由采购与财务共管、科目归口财务、部门与成本中心由人事与财务共管，每类数据的字段标准、审批流程、质量指标都有明确归口，出了问题知道找谁。考核可以从数据质量域借鉴完整性、唯一性、一致性、准确性四个维度分域打分，按季度通报。
治理落地的三个抓手
- 新增通道唯一化：所有系统的主数据新增必须走统一审批流，堵住各系统内私建的口子
- 变更留痕：主数据变更记录版本与生效日期，历史单据显示当时的值而非最新值
- 定期体检：每季度跑一轮重复检测与休眠数据清理，两年无交易的供应商转入休眠状态而非直接删除
本地化部署的主数据平台有一个天然优势：数据全部落在企业自己的环境里，治理规则、查重算法、变更历史都可以按企业自己的制度定制并完整留存，不必迁就外部平台的通用模型。这也意味着治理责任完全在企业自己——制度不落地，工具再好也只是个录入界面。
存量脏数据：治理绕不开的第一场硬仗
新制度只管得住增量，管不住存量。上线主数据流程之前，先要回答「现在系统里到底有多少重复编码」。建议按三步走：第一步全量扫描，以统一社会信用代码和名称相似度做两两比对，输出疑似重复清单；第二步人工仲裁，由业务与财务共同确认哪些是同一家、哪些是同名不同家，仲裁结论留档；第三步合并切换，把保留方与停用方的映射关系写入系统，历史单据按映射自动归并到保留编码下。
合并的顺序有讲究：先停用、后合并、再清理。停用后该编码不能再被新单据引用，但历史数据照常可查；等应收应付全部结清、报表按新口径稳定跑过至少一个期间，再做物理清理。跳过稳定期直接删数据，是主数据治理翻车的最常见原因——一旦下游某个报表还在引用旧编码，删掉的就是报表的一角。
资料来源：《会计信息化工作规范》（财会〔2024〕11号）；《数据管理能力成熟度评估模型》（GB/T 36073-2018）