验收摘要
配送结算对账要先对齐骑手、商家、平台（含加盟/分站）三类费用节点：流水可查、分润可追溯、提现可核对。本文给出可打印核对项，帮助财务与运营按系统能力验收，而不是只盯日单量。
很多团队对账卡在「业务说已送达、财务说余额对不上」。根因常是费用节点未进入同一账户体系，或退款调整只在表格里手工冲。云虎配送宝用于配置订单、调度、运力、商家与结算等链路，是企业级同城/即时配送系统软件；用于搭建与交付客户自用系统，不自营、不运营运力平台，也不代替客户做资金托管、支付通道运营或收益承诺。系统可按客户规则配置账户流水、分润与提现查询；业务规则与合规结论由客户自行确定。选型仍先分清买系统与买运力。
图注｜先对齐三类角色费用节点，再谈月结习惯
一、配送结算对账：先列费用节点
建议至少拆清：订单配送费与分账、商家充值或余额支付、骑手收入与可提现、加盟商或分站分润、退款与调整流水。任一节点只在聊天记录里「口头对齐」，都不算系统侧对账完成。订单详情里通常能看到费用分账、取送信息与配送站/骑手归属，这是追溯的起点；财务流水则回答「钱进出账户后落在哪一类变动」。
☐ 订单完成后费用是否回写到可查询流水
☐ 商家、骑手、加盟商账户是否分角色可见
☐ 退款/调整是否能关联原单或原流水
☐ 试点单从下单到流水变动是否可一人独立复盘
图注｜财务流水：支付退款调整与余额变动可检索
二、分润、提现与对账中心怎么核对
业务规则与分佣可按加盟商/分站配置，并支持复制同步到同类组织（以当期后台为准）。财务侧可见骑手、商家、加盟商、连锁店等对账与提现、流水查询入口。验收时不要只截「有菜单」的图，而要跑通：生成一笔试点单 → 看各方流水变动 → 核对分润是否按生效规则计算 → 发起或模拟提现规则 → 核对状态与备注。充值设置、履约金规则、提现规则应与现场制度一致；支付、短信等为基础应用接入，勿写成云虎自营支付通道。
☐ 分佣规则变更后新单是否按新规则计费，旧单边界是否约定
☐ 骑手/商家提现规则与履约金等设置是否与现场制度一致
☐ 对账中心角色维度是否覆盖试点组织树
☐ 总公司与加盟商资金权限是否隔离、无串账
图注｜按角色打开对账视图，避免只导出一张总表
三、文档字段表：试点对账齐套检查
把下列字段当成试点签字前的齐套检查，而不是上线后补救清单。缺一项，月结时就容易回到 Excel 对赌。
| 字段 | 是否齐套 | 备注 |
|---|---|---|
| 订单→流水映射 | □ | 试点单可追溯 |
| 分润规则版本 | □ | 变更有生效边界 |
| 提现状态闭环 | □ | 申请/处理/驳回可查 |
| 退款关联原单 | □ | 避免口头冲账 |
| 角色资金权限 | □ | 不串加盟/分站 |
验收结论：当骑手、商家、平台费用能在同一套账户与对账视图里对齐试点单时，才算配送结算对账跑通；系统不替代客户财务制度与资金合规，也不承诺收益百分比。
月结前建议固定一次「三角核对」：抽 3～5 笔已完成订单，分别从订单详情、骑手流水、商家或加盟流水各走一遍，确认金额、时间与状态能对上。发现差异时，先区分是规则版本问题、退款未回写，还是权限导致某角色看不到完整字段。三角核对通过后，再扩大到按日或按站汇总。若长期依赖导出总表手工匹配，说明费用节点仍未在系统内闭环。
配送结算对账还要与运力组织、订单接入联动理解：没有清晰的站点与骑手归属，分润对象会飘；多平台订单未进同一主账，退款与评价更容易丢。系统侧能做的是提供可配置的账户、分润、提现与对账视图；客户侧仍需明确财务制度、发票与资金合规。不把对账能力写成收益承诺，也不把支付接入写成自营通道，正文才经得起复核。
对财务新人，可用「一单一账一角色」训练：任意抽一单，说出商家付了什么、骑手应得什么、平台或加盟留了什么，并在系统里指出对应流水入口。说不清的环节，就是下一周配置重点。对运营新人，强调不要用日单量替代对账：单量只说明履约次数，对账说明费用归属是否正确。两边口径统一后，月结会议才会从「对骂」变成「对表」。若存在连锁店或加盟多层，先在试点组织树跑通，再复制规则，切忌一上来全网同步未验证的分佣。
最后提醒：配送结算对账服务的是客户自有经营闭环，不是替客户承诺收益或垫资。系统提供查询与规则配置能力；资金合规、发票与合同条款由客户与其顾问自行把握。把边界写进验收纪要，后续争议会少很多。
若试点阶段暂不开放提现，也应先跑通「应付金额可查询 + 状态可解释」，把提现开关留到规则与合规材料齐套之后。顺序颠倒，容易在真实资金动作上返工。
