一家平台和联营商家约好月底结算。运营从商城导出“本月成交额”，发现里面有平台自营商品、另一家商家的商品、一笔未送达子单和一笔已退款订单；财务按导出总额乘扣点比例，商家则拿自己发货清单核对，双方一开会就对不上。争议并非计算器出了错，而是从第一步就没有说清“哪一笔业务是这个商家本期可结的业务”。周期结算要从商家子单的真实履约结果起算，沿退货、合同扣点、返点、已付款和银行打款逐步核，不能把客户支付或下单金额直接搬进商家应付款。
以下是一组演示算例，不是系统真实订单：某商家在截至 9 月 30 日的结算周期有两笔已完成子单，供货额分别为 600 元和 400 元；另有一笔 300 元未完成、一笔 200 元已取消。已完成子单中，本期确认了一笔按供货口径计的 100 元退货。合同假定在净供货额上扣 5% 平台服务费，另给平台 2% 阶段返点，且两项可并行；此前已向商家预付 300 元。这个假设只用来讲清算式，实际合同是否允许两项同时扣、以哪个金额为基数、税费和发票如何处理，应由双方合同与财务复核确定，不能按示例自动套用。
合作开始前写清结算口径
谈合作时至少写清六件事：谁是付款与收款主体，按客户主单还是商家子单核算，采用客户售价、商家供货价还是约定佣金作为基数，什么状态叫“可结”，退货在本期还是下期冲回，扣点与返点各由谁承担。商家发货与平台代发还会改变仓配费用和破损责任；如果平台代发需要另计仓储与配送，费用项目不能藏进一个笼统“扣点”。账期也要写完成后的可结天数、对账日、审批人和约定打款日。合同变更时保留生效日期，旧订单依当时有效条款核，不因新合同启用就重算已完成周期。
“返点”和“扣点”尤其容易被说混。扣点可能是平台就商家商品收取的服务费，返点可能是商家达到销量条件后向平台返还的金额，也可能反过来是平台给商家的激励。方向、基数、门槛和结算时点不同，算式就不同。本例明确两项都由商家让利给平台，扣点 5%、返点 2% 都以扣除本期退货后的 900 元供货额为基数，且合同允许叠加。若合同只允许二选一，就不能照此再扣两次；若返点必须跨季度达标才确认，本月不能提前减少商家应付款。合作资料中可以记录履约方式与约定比例，但页面保存成功不等于这些条款已被双方确认。
图1：真实后台显示联营履约方式等配置入口；服务费和返点的合同含义仍须双方另行明确。
运营整理本期可结订单
平台主单可能同时含自营商品和不同商家的商品。结算某一商家时，应以归属于该商家的子单为最小核算对象，逐笔核商家身份、合同版本、履约状态、完成时间和是否曾进入其他结算单。上面的 300 元未完成子单与 200 元已取消子单，都不进入本期 1000 元已完成供货额；若某笔完成于 10 月 1 日，即便客户 9 月 30 日已经下单，也应按约定完成时点进入下一期。跨期判断要统一时区与截点，不能一个部门按下单日、另一个按签收日。
系统的联营订单列表能提供主单、子单与状态的查询入口，但结算清单应导出或保存到子单行，标明选入与排除原因。对“已发货但客户签收有差异”的子单，先核实送数量与客户确认结果，不能直接按原订数量结。被排除的单仍要留在例外清单里，交给运营跟进，不是为提高可结准确率就从业务视野里消失。系统截图中的一笔演示订单只证明列表字段与查询入口存在，不代表本文 600、400 等演示金额已经真实发生。
图2：用真实订单列表核商家子单、完成状态和时间，再形成带选入理由的本期清单。
图3：先按商家、状态、期间和唯一性过滤；客户主单合计不能直接成为某商家的应结基数。
财务逐项核对退货和扣点
运营提交的有效清单进入财务核算时，财务应从商家子单逐行看商品、供货单价、实际可结数量和金额。系统子单明细能展示这些字段，适合与仓配实发、客户签收及售后处理记录逐项对照。演示算例里两笔已完成供货额是 600+400=1000 元；一笔本期确认退货对应供货退价 100 元，因此可结净供货额为 900 元。若客户退款按客户零售价 130 元发生，商家侧仍应按双方约定的供货退价和责任费用处理，不把 130 元直接冲减供货额，也不能忘记另行核平台承担的差额。
图4：真实子单明细用于核对供货价格与数量口径；本文演示金额另按合同假设计算。
按已约定两项可叠加的算例，900 元净供货额乘 5% 扣点是 45 元，乘 2% 返点是 18 元，商家本期应付为 900－45－18＝837 元。此前预付 300 元仍须有付款凭证和归属期间，当前待打款为 537 元。若存在商家赔付、平台代发运费或保证金抵扣，应另列合同依据、原单与金额，不在 537 元上口头加减。结算单应能从每一个扣减项追到原退货、订单和合作条款，最好让商家看到按子单汇总的明细，而非只有一个“应结总数”。
图5：演示算式把未完成单排除在外，再依次核本期退货、合同扣点、返点和预付款。
两类边界必须单独处理。第一，9 月 30 日前已完成、10 月 3 日才退货的商品，如果 9 月结算已确认并打款，应在下期建立可追的退货调整，关联原子单与原结算单，不静默改写上期已付金额。第二，扣点与返点门槛若跨多个周期累计，财务应保留累计依据，达到条件后再确认，不把预计返点当作已确定付款扣项。合同里未写明的费用争议先冻结该项金额，能核实的无争议款按双方约定继续处理；不能为了结束对账，把争议成本随意塞到“其他扣款”。
双方确认结算单再安排付款
结算草案给商家时，至少附子单号、完成日期、供货金额、退货与扣减凭证、合同条款、已付金额和本期待打款额。商家若说有一笔送货未被计入，运营回子单查完成状态与截点；若说 100 元退货不是本期，客服与财务回原售后记录查客户确认、实物退回和双方责任；若说返点不应叠加，回合同版本核生效条件。争议处理应留下提出人、证据、处理动作和双方最终确认，不靠电话里一句“下次再说”改变清单。
审核顺序可以是运营编制、财务复核、商家确认、负责人批准、出纳执行付款。每个状态含义不同：财务复核只说明算式通过，商家确认说明对账口径一致，负责人批准才是付款授权，出纳实际银行付款才是资金流出。系统若显示待审核、待打款、已打款等状态，应核实际配置和操作权限，不能凭状态名称推断银行已成功入账。账户名称或收款账号变更时更要按企业既定核验方式复核，不仅依据聊天消息修改；含敏感银行信息的原始凭证只在受控财务系统保存，知识文章和验收截图不展示。
老板用付款和余额确认收尾
假设双方确认待打款 537 元，付款指令也批准 537 元，但银行当天只成功支付 500 元。老板在报表里应看到本期结算应付 837 元、此前已付 300 元、本次实际支付 500 元、尚欠 37 元；若只把结算状态改成“已打款”，剩余 37 元会在下一期对账时突然出现。银行流水与付款回单应能对应商家、结算单号、付款日期和金额，商家确认收款后关闭已付部分，未付余额留在往来账继续追。若银行失败或款项退回，应把失败原因与重新支付时间记在同一结算链上。
图6：审批额与银行实付额分开记；537 元批准、500 元到账时仍有 37 元余额。
经营负责人每期不应只问“这家商家卖了多少”，还要看未完成子单为何久拖、退货供价与客户退款差多少、异常扣款占供货额比例、实际打款是否落在承诺日期、未付余额是否跨期增长。这些指标能指出合作模式是否可持续：若商家交付不稳而平台一直垫退款，扣点收益可能被售后和占款吃掉。下一期对账把上期 37 元余额作为独立期初事项列示，与新周期有效子单区分，防止历史欠款在新销售中被掩盖。
让一笔钱始终找得到它对应的业务
周期结算真正可靠，靠的是从资金结果逆向找到业务依据。商家问少付了多少，财务能从银行实付回到结算单，从结算单回到扣点、返点和退货，从退货回到客户订单与实际履约。老板看见一个“可结”金额，也能解释哪些订单被排除、哪些款项先付、哪些差异留待下一期。为检验这条链，首期不要一次纳入所有商家；选一家合同条款清楚、子单量可抽查的商家，准备一笔正常完成、一笔未完成、一笔本期退货和一笔跨期退货，实际跑完清单、双方确认和付款核对。再用同一口径扩到不同履约方式的商家，比较平台代发费用是否被单列、商家直送签收证据是否齐全。
商猫云链系统可以把联营合作、商家子单、供货价与结算状态放在可查询的业务链上，但系统字段不会自行决定合同解释，也不能以“已审核”代替银行流水。把有效单筛选、金额核算、差异确认和实际付款分成独立但可追溯的步骤，平台才能让商家愿意继续供货，自己也能看清扣点收入、退货成本与资金占用，而不是每个月重演一次“双方各有一张表”的争论。