档口供应链对账笔记

guozi

在农产品批发市场的凌晨档口，对账是供应链中最混乱也最被忽视的环节。本文从常驻市场的产品经理视角，拆解一套农批对账系统从0到1的设计全过程：6大差异类型、三层架构、自动对账双模式，以及1.2万差异如何自动排查的实战案例。不讲概念，只讲实战。



我是一名B2B平台的产品经理，常驻过农产品一级批发市场。在凌晨3点的档口里，我见过最真实的交易场景：7个采购方同时下单、过磅排长队、临时欠款”先欠着一起付”——这种混乱，是任何PRD模板都覆盖不了的。

也是在档口里，我发现了一个被99%的产品经理忽略的问题：对账。

对账不是”应收减实收”这么简单。在一个日均3000笔交易、4种支付方式、6种差异类型的场景里，对账是整个供应链最容易出问题、却最没人愿意碰的环节。

这篇文章，我从一个”常驻档口”的产品经理视角，拆解一套农批对账系统是怎么从0到1设计出来的——包括问题拆解、系统架构、关键设计决策，以及踩过的坑。不讲概念，只讲实战。
一、痛点：为什么对账是供应链的”隐形黑洞”
先说场景。农产品一级批发市场的交易模式是这样的：

• 凌晨2点开市，8点收市，高峰期3:00-6:00产生全天70%的交易
• 4种支付方式混用：微信、支付宝、银行卡、现金
• 2种结算模式并存：日清日结（现款现货）+ 月结（赊账，月底统一对账）
• 临时欠款常态化：采购方”先欠着，一起付”是常态


在这种场景下，对账的痛点有三个层次：

第一层：对账慢

财务每天下午开始对账，3000多笔交易逐笔核对，日均耗时4-6小时。高峰期（节假日前后）甚至要1-2天才能出对账单。老板不知道今天到底赚了多少、谁还欠钱、哪些账对不上。

第二层：差异多

对账差异率长期在12%-15%之间——也就是说，每100笔交易有12-15笔对不上。差异的原因五花八门：过磅重量和开单量不一致、扣杂标准不统一、同一笔重复记账、价格调整后没同步……

第三层：风控缺

月结模式下，信用额度是各档口独立管理的。一个采购方在A档口赊账到了上限，转头去B档口继续赊——跨档口信用没有全局视图，坏账从”事后发现”变成”事后都发现不了”。

这三个痛点指向同一个问题：没有系统化的对账能力，供应链的财务就是一本糊涂账。
二、拆解：把”对不上”拆成6种类型
做对账系统的第一步，不是写代码，是把”对不上”这件事分类。我在档口蹲了2个月，把所有见过的差异场景归成了6大类型：



产品经理的关键洞察：这6种差异类型不是拍脑袋分的，是从档口实际交易里长出来的。类型不同，处理策略不同——临时欠款要催款，过磅差异要校准扣杂率，跨档口信用要全局锁定。不能一个”对账差异”标签糊到底。
三、架构：采集层、匹配层、处理层
把差异类型定义清楚后，系统架构就自然了——三层分工：

采集层：把4个数据源归拢到一张表

• 开单系统：拉应收数据（该收多少）
• 过磅系统：拉实际称重（扣杂基准）
• 支付网关：拉4种渠道的实收流水（微信/支付宝API + 银行银企直连 + 现金收银台录入）
• 信用系统：拉赊账记录和额度使用情况


关键设计：统一字段。不管哪个渠道进来的数据，统一成5个字段——交易编号、金额、时间、支付方式、状态。这样匹配层不用关心数据来源，只管按交易编号配对。

匹配层：5步撮合引擎

这是对账系统的”心脏”。核心逻辑是分层匹配，精确先吃掉大部分：



为什么分层匹配是核心设计？如果全量人工逐笔对，3000笔要看3000次。但精确匹配自动对平85%，模糊匹配再捞回10-15%，真正需要人看的只剩5%以内。人从”逐笔对”解放到”只看异常”，这就是效率提升8-12倍的本质。

处理层：差异自动处置

匹配完不是结束，差异要有人处理。处理层的作用是按差异类型自动触发动作：

• 临时欠款 → 自动发催款通知（短信/企微）
• 过磅差异 → 自动计算扣杂率偏差，推给档口确认
• 跨档口信用超标 → 全局锁定该客户赊账权限
• 重复记账 → 自动去重，标记一条为无效
• 价格未同步 → 推给业务方确认价格变更

四、自动对账怎么跑：日清日结 + 月结双模式
架构讲完了，很多人会问：系统每天到底怎么自动跑的？ 这才是对账系统的核心。我们设计了两种自动对账模式，分别对应两种业务场景。

模式一：日清日结自动对账（每天跑）

日清日结是农批市场最主流的结算方式——当天的交易当天对完，不留隔夜账。系统的自动对账流程是这样的：



关键设计：对账不是”一次性跑完”，是”分层漏斗”。3000笔交易进来，精确匹配自动对平2500笔（不用人管），模糊匹配再捞回400笔（不用人管），真正需要人看的只剩100笔以内。财务从”逐笔对3000笔”变成”只看100笔异常”，4-6小时压到30分钟。

模式二：月结自动对账（每月跑）

月结客户（如XX餐饮这种长期合作的采购方）是另一套流程，核心是信用额度管理 + 月度汇总对账：



对账状态机：8个状态的流转

每笔交易在对账系统里都有自己的生命周期，从”待对账”到”已关闭”，一共8个状态：



为什么要设计”驳回”状态？因为差异分类不是100%准确的。系统可能把”价格未同步”误判成”过磅差异”——财务看到后觉得不对，可以驳回，让系统重新分类。这个回路让对账系统越用越准：驳回的案例会反馈到规则库，优化后续分类逻辑。

实战案例：1.2万差异怎么自动排查

说个真实场景。某天系统跑完日对账，显示总差异12,000元——应收和实收差了1.2万。如果没有系统，财务要逐笔翻3000条记录找。系统的处理流程：

第一步：按支付渠道拆分。系统自动把1.2万拆成4个渠道——微信3,200 + 支付宝2,800 + 现金4,500 + 银行卡1,500。现金差异最大，优先排查。

第二步：撮合引擎自动对平。4个渠道各自跑精确+模糊匹配，微信/支付宝/银行卡大部分自动对平（T+1到账延迟导致的”假差异”），剩余真实差异600元。

第三步：6大差异分类。600元自动归到6个类型：临时欠款210 + 过磅差异150 + 扣杂不一90 + 跨档口60 + 重复记账60 + 价格30。

第四步：自动生成工单。每个差异条目生成一个处理工单，推给对应负责人。临时欠款→自动发催款通知，过磅差异→推给档口确认扣杂率，跨档口信用→自动锁定。

结果：1.2万的差异，系统自动对平了11,400元（95%），真正需要人看的只有600元。而且这600元已经按类型分好类、生成好工单了，财务只需要逐条确认就行。从”找1.2万”变成”看600元”，这就是自动对账的价值。

底层逻辑：付款和退款怎么分开核对

讲完流程和案例，有人会问一个核心问题：微信对账单里付款和退款是混在一起的，系统怎么区分？又是根据什么去核对的？

这是对账系统设计里最容易被忽略、却最关键的细节。拆开讲。

问题1：根据什么核对？

很多人以为对账是”猜”的——其实不是。微信支付调API下单时，你的系统会把订单号传给微信（字段叫 out_trade_no，即商户订单号）。微信对账单里自带这个号，所以匹配键是现成的：



但金额为什么也要校验？因为可能订单号一样但金额被改过——开单时¥1,800，议价后改成¥1,750但系统没同步，微信那边付的还是¥1,800。所以编号一致但金额不一致 → 标记为”价格未同步”差异，不能只看编号就判对平。

问题2：付款和退款怎么分开？

微信对账单CSV里，付款和退款是同一个文件里的不同行，靠”交易状态”字段区分：



系统读进来后，一个if判断就分开了：

if 交易状态 == “SUCCESS” → 进付款表

if 交易状态 == “REFUND” → 进退款表

分开之后，两批数据各自走自己的匹配流程，互不干扰。

问题3：两轮匹配怎么跑？
第一轮：付款匹配。拿付款表和系统应收表配对——精确匹配（订单号+金额一致）对平80%+，模糊匹配（金额差

--------------------------------------------------
本文转载自：https://www.woshipm.com/pd/6446477.html