一、项目背景

我们接手这家本地生活平台的时候，到店团购业务已经跑了快两年，体量不小，平台当月团购交易额已经过亿，每天的核销笔数在十几万的量级。但核销这件事一直是人工在扛。用户在线上买了团购券，到店之后店员要么手输券码、要么拿手机扫一下截图，核销动作和订单系统完全脱钩。财务每个月月底拉两份表，一份是线上支付订单，一份是门店手填的核销记录，两边对不上那是常态。

最开始我们也没当回事，觉得差几个百分点正常。直到有个月一个区域的商户集体来问，说分账金额比他们自己记的少了将近一成，我们才认真去查。一查发现，将近一半的核销记录要么没回传到订单系统，要么回传时券码和订单对不上，分账引擎按订单跑，漏掉的核销自然就没结给商户。这件事之后我们下定决心，把核销和分账做成一条自动链路，而不是靠财务月底拿两张表去凑。

那时我们还顺手统计了一下，财务每个月为了对账要拉三个人做差不多一周，光是人工核对券码和订单的映射就占了大半时间。这个隐性成本之前没人算过，等我们把它量化出来，老板才意识到这不是小钱。

二、落地场景

这个平台接的是连锁餐饮、休闲娱乐、丽人这几类到店业态，每天的团购核销峰值出现在午晚市和周末。我们要解决的核心场景其实就三个。第一是核销动作本身要可信，用户到店出示券码，店员在 POS 或者小程序上核销，这个动作必须实时写回订单系统，不能靠事后补录。第二是核销即分账，一笔核销确认下来，平台抽成、商户结算、推广员佣金这几级比例要立刻算清楚，而不是月底统一算。第三是万一核销出错，要有复核和冲正的能力，不能把错账越滚越大。

商户这端最关心的是到账准不准、快不快。所以我们给每个商户配了结算看板，当天核销的笔数、金额、应结金额、已结金额全都摊开，哪天对不上商户自己一眼就能看出来，反而比之前糊里糊涂地信任我们强。推广员那端也一样，佣金是不是按时结、结多少，看板上一目了然，之前因为分账慢导致的推广员流失也缓解了不少。

三、关键技术挑战与解决思路

第一个坑是核销和支付的幂等。早期我们直接让门店调用核销接口，网络抖动一来，店员多点两下就重复核销，分账也跟着重复结。后来我们给每张券码加了状态机，核销必须是未核销到已核销的单向跃迁，重复请求直接返回原结果，分账侧也按券码做唯一键，重复的不进账。这个状态机上线前我们专门压了一次，模拟同一券码在一秒内并发提交二十次，确认只有一次落账。

第二个难点是多级分账的比例配置。不同业态、不同商户、不同推广渠道的抽成比例都不一样，有的还带阶梯，卖得越多抽成越低。我们把分账规则做成了一套配置，核销事件进来之后先查规则引擎算出每一级的金额，再异步落账。这里有个细节，分账金额必须和实付金额对齐到分，我们用整数分来算，避免浮点误差把账目搞脏。规则引擎那层我们还加了校验，同一笔核销拆出来的各级金额加总必须等于实付，不等就告警不落账。

第三个挑战是异常核销的冲正。门店偶尔会核销错券，或者用户退单。我们的做法是核销记录全部留存流水，冲正时生成一条反向流水，分账跟着回滚，看板上的已结金额会同步扣减，但已经打款给商户的部分要等下一个结算周期抵扣，这条规则一开始没想清楚，财务和商户吵了好几轮才定下来。后来我们干脆把冲正和退款做成两套独立流程，核销错券走冲正、用户退单走退款，避免混在一起算不清。

四、效果数据

上线大概四个月，核销自动化率从原来的不到五成拉到了九成六，剩下那点主要是网络断了门店走离线核销再回传。分账差错率我们从万分之三十压到了万分之一以内，商户纠纷数按月统计降了七成多。对账耗时这块，财务之前月底要花三个人做一周，现在系统自动出对账单，半天就能核完，而且核出来的差异数从之前的上千条降到个位数。

案例片段（已脱敏）： 某区域餐饮商户接入后的一个分账规则片段（yaml 示意）： rule_id: chain_rest_v2 levels:  - role: platform   rate: 0.08  - role: merchant   rate: 0.85  - role: promoter   rate: 0.07 settle_cycle: T+1 上线第二周日志里抓到一条重复核销：同一券码在 12 秒内被门店提交了两次，状态机第二次直接返回「已核销」，分账只落账一次，避免了一次约 198 元的重复结算。同一周还出现一笔退单，退款流程独立回滚了原核销的佣金 13.6 元，未影响平台与商户的已结金额。

文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

到店核销这件事，回头看最大的教训就是别让它和订单脱节。我们一开始觉得先让人核销、月底再对齐也行，结果对账成本全堆在财务身上，商户信任也损耗了。核销动作挂在订单上、核销即分账，这条链路越早打通越省心。

分账一定用整数分来算，别碰浮点。我们早期有一版用浮点累加，跑了两个月没出事，后来一笔大单的尾数对不上，查了半天才定位到是浮点误差，这种坑平时看不见，爆出来就是实打实的差错。

多级分账的比例配置尽量做成规则而不是写死在代码里。业务侧调一次抽成，研发不用改代码发版，财务也能自己核对规则，这件事在后面接新商户时特别明显，配置改一下就能上线，不用每次都走研发排期。

冲正和退款要分开设计，别图省事合成一条。我们最早混在一起，结果一笔退单把平台的抽成也回滚了，财务追了两天才理清，分开之后各自闭环，谁都不用替谁背账。