多店铺多平台对账:统一账单模型设计

为什么需要统一账单模型

15 个平台就有 15 套账单格式:列名不同、费用叫法不同、结算粒度不同(按单、按行、按周期汇总)。如果每个平台的对账逻辑都各自写一套,平台数乘以店铺数,规则数量会指数爆炸,且无法横向汇总分析。统一账单模型的目标是:任何平台的账单进来,都变成同一种结构;对账逻辑只写一遍,对所有平台生效。

三层模型

第一层:原始层(Raw Layer)

原样保存平台账单,一行不落、一列不改,连表头行、合计行、空行都保留。原始层的意义是"呈堂证供":任何争议、任何审计,都要能拿出平台当时给的原貌。实现上,原始行以 JSON 快照(rawData)挂在事实行上,文件本体归档存储。

第二层:标准事实层(Fact Layer)

每个平台 × 每种账单类型一张事实表,字段统一。核心字段规范:

第三层:对账层(Reconciliation Layer)

对账结果不改动事实层,而是独立存:对账计划、对账明细(匹配状态、差异金额、差异原因)、分摊明细。事实层与对账层之间用最小桥表关联——桥表只存双方主键、匹配方式、匹配时间等 5 个左右字段,任何对账结果都能经桥表反查到原始账单行。

核算项目字典:统一口径的关键

各平台费用项必须映射到统一的核算项目字典,例如:

1. GOODS_PAYMENT 货款;
2. PLATFORM_SERVICE_FEE 平台技术服务费(抖店技术服务费、拼多多基础技术服务费归入此项);
3. COMMISSION 佣金(京东运营支持服务费、亚马逊 referral fee、抖店达人佣金);
4. AD_FEE 广告推广费(京准通、直通车、Amazon Ads);
5. LOGISTICS_FEE 物流与仓储费(含 FBA 履约费);
6. INSURANCE 运费险;
7. REFUND_DEDUCTION 退款扣回;
8. ADJUSTMENT 其他调整。

字典要预留扩展位:新平台带来新费用项时,优先归入已有项目,确实无法归类的才新增,并记录映射理由。

落地要点

• 店铺主数据先行:平台店铺编码、ERP 组织/部门编码必须先建映射,否则账单进来无处挂;
• 解析规则脚本化:每个平台的"原始层 → 事实层"转换由可测试、可版本化的解析脚本完成,平台改版只改脚本不动模型;
• 金额全程 Decimal:任何环节禁止 float,金额 (20,4)、单价 (20,6) 是底线;
• 对账层只增不改:差异处理通过新增状态与处理记录表达,不更新历史对账明细,保证审计可重放。

统一账单模型一旦建立,多平台对账就从"N 套规则"变成"一套规则 + N 个解析脚本",这是规模化的唯一路径。