店铺商家结算：审核、扣点、分账和实际打款｜云上订货系统
云上订货 · 更新于 2026-10-08
先核本平台原店铺结算，按订单结算价、原退货及扣点分开分账和剩余应付，再沿原收付款与支付流水核资金结果。
1. 先确认店铺商家结算与原平台范围
在平台管理端进入“商家店铺结算”，先确认当前平台、原商家店铺和结算编号，再看单据状态。列表能按商家店铺或状态筛选，关键字查结算单号及店铺名称；点击原单号进入结算单详情和订单明细。不要只凭同名商家认单，也不要把联营商家的一张结算单直接当作店铺商家结算。
本页显示结算金额、扣点金额、应付金额、实际打款和单据状态，分账列或按钮还受版本与应用条件影响。待审核、待打款及已打款汇总对应当前查询范围，其中前两项用应付金额，已打款用完成单的实付记录；三项不是同一数字换名称。核对时保存筛选条件和原单，不能用某个汇总代每笔资金去向。
历史应用中心曾分别列“店铺商家平台”和“自动分账结算”，只能说明应用对象不同，不证明当前企业已开通、后台已运行或钱已到账。业务图只说明结算关系与计算算例；当前部署菜单、岗位权限和同一结算单实际结果仍需核，银行到账必须继续取得原资金结果。
图1：历史应用中心分别列店铺商家平台与自动分账，不证明本企业已执行结算
图2：店铺结算、分账处理与银行结果分别核
2. 按原订单完成条件核可结日期和生成结果
进入结算范围的基础是有效且已完成、原结算标记仍未结算的店铺订单，并有对应平台及有效商家关系。不能仅凭客户已下单或平台已收款，就认定店铺订单已经具备结算条件；部分交付或未完成订单应回原订单状态核，不能通过改列表筛选把它变成可结订单。
自动生成还按订单完成时间加店铺等待天数，随后核日、周或月的配置时点。等待天数与下单日期不同：示意订单周一提交、周三完成，等待条件应从原完成时间继续核，不按周一直接计算。自动生成由定时任务处理，实际执行记录和生成结果仍需核对，不能承诺客户完成收货后马上出现结算单。
结算列表的制单时间和详情的结算时间显示生成时点，不是所有原订单的完成时间。找不到单时先核原订单完成及未结算标记、店铺周期和已存在结算编号，再核实际生成结果。后台有手动处理路径不代表本页提供普通用户可用的生成按钮，不应让财务人员随意调用接口或复制结算单来补空列表。
图3：原订单可结时间和结算生成时间分开
3. 对照原数量、结算价与订单保存扣点
订单明细分别显示销售价、结算价、原数量、单位、小计和订单状态，核金额要按同一原规格逐行进行。小计按原数量乘结算价，不能拿销售价或商品今天的目录价直接替代。示意两箱、每箱结算价一百元，货款二百元；即使每箱有二十四瓶，也不再给已按箱计价的货款乘一次瓶数。
店铺新订单会保存其下单时对应的扣点比例，结算还可能采用已有分账记录中的扣点金额。因此商家今天把比例改为另一数值，不代表全部旧订单立即按新比例重算。审核应同时保原订单、原规格价格、保存的比例和已有扣点记录，不能只用商家资料上的当前比例反推所有结算明细。
原订单行、生成后的结算主单及商家主档是不同对象。明细可用原单号、商品名称、规格或编号定位并导出相应字段，但实际文件仍要同当前筛选核对，不能把导出小计当作银行收款。生成后金额已经保存，后续改主档或订单资料是否影响该单，应回本结算原结果检查，不承诺自动更新全部历史结算。
图4：销售价、结算价和原订单扣点分别核
4. 核结算金额、退货记录、分账和应付算例
生成结算时，以子单原数量乘结算价汇总货款，再减原订单已记退货额，并加原运费得到结算金额。扣点金额优先使用已有相应记录；没有该金额时，按扣减后的货款与原订单保存比例计算。应付金额再由结算金额减扣点金额、减分账金额，因此不能把客户销售总额直接当商家待打款。
示意没有已保存扣点记录的原货款一千元、已记原退货一百元、运费二十元，净货款九百元，结算金额九百二十元。原订单扣点比例百分之五时，这个算例扣点四十五元；若分账额二百元，应付为六百七十五元。已有扣点记录时应采用实际记录核，不把此算例或当前平台费率套在任何单上。
退货申请、已财务处理的原退货与已经支付的退款各有状态。已记原退货额有其原单维护路径，结算生成前后也不同；本页并没有由所有联营退货申请自动汇入付款弹窗的可用查询链。退货发生后应核它是否关联这张原订单、何时进入原退货额，以及本结算单保存金额，不能凭一张申请承诺该单已扣款或银行已退款。
图5：原退货、运费、扣点与分账的应付算例
5. 分开审核、驳回、零额完结与收款资料
待审核原结算单可审核通过或驳回，先核结算明细、应付、分账及收款资料，再保存审核备注和明确结果。通过通常转为待打款；驳回会将关联原订单的结算标记回待结算，之后能否按下一周期生成仍需核实际条件，不代表原订单被删除或旧结算记录消失。
零额有独立边界：应付金额与分账金额合计为零时，审核处理可能直接完结，应回查实际单据状态及原订单标记，而不是坚持任何审核选择都一定停在待打款或驳回。系统完结也不代表发生了零额以外的银行转账，不能由“已结算”三个字推断商家账户已经收到现金。
详情中的开户名称、开户行、银行账号及支付宝是本结算资料，允许编辑的状态与已完成或取消状态不同。需要更正时先核本单及当前资料版本；旧资料已变化会提示刷新，不以旧弹窗反复确认。填写或编辑银行字段只是保存资料，不是账户认证，也不是已经发起支付；生成时复制的收款资料仍要与实际付款依据核对。
图6：审核驳回、零额完结与收款资料分开
6. 完成分账后逐笔核成功金额和失败反馈
有自动分账金额且相应应用可用时，待打款页提供“完成分账”。普通完成打款入口会先检查分账处理标记，未完成时提示先处理分账。仍应保原结算、原订单及其待确认分账明细，区分分账额和剩余普通应付，不能把已扣的分账额再当额外线下款重复支付。
实际分账按明细逐笔处理，通道成功会记录成功金额与相关原收付款；失败保反馈并可能继续处理其他明细。这样一批结果可能部分成功、部分失败，汇总已处理标记不能单独证明所有原订单都成功。应核每笔状态、分账成功金额及原交易流水，再判断还需要追查哪笔，不按一个汇总按钮结束整批资金核对。
若普通应付为零，处理分账后可将结算标为完成，但这仍不替代失败明细或银行结果。若普通应付还有余额，分账处理与剩余打款分别核；不要因为已完成分账就再次把整张结算金额填入普通付款。当前通道配置、账户和同数据处理结果需核，不能因一项失败就认定全部处理都已撤回，也不能在原结果未核清时重复付款。
图7：逐笔分账结果和处理汇总标记分开
7. 完成打款沿平台付款与店铺收款核账
“完成打款”表单要求实际打款、付款时间和付款账户，界面将金额限定为正额且不高于应付。先取得实际支付依据，再把金额与本结算编号对应，避免把另一店铺的银行回单登记到这张单上。表单默认金额和实际转出金额不同，确认前必须逐项核，不以默认数字代真实资金结果。
后台会重查原结算存在及当前待打款状态，沿本单推出平台付款单，并更新相应账面；商家侧另生成关联同一结算编号的收款单。普通路径若没有指定商家收款账户，会取该店铺有效线下银行资金账户中的原默认选择结果，应核实际生成账户，不仅看结算详情所填写的银行文字。
付款完成回写本次实际打款并可将结算置为已完成、更新关联订单的结算标记，不应自行推成支持任意分期且自动累计待付余款。金额不一致时回平台原付款、商家原收款、账面流水及支付凭据核，不能为凑应付数连续重复登记。完成打款在此建立的是业务与账面记录，实际银行是否已到账仍需原收款结果证明。
图8：完成打款沿平台付款与店铺收款核账
8. 线上转账核通道条件、原流水与到账结果
“线上转账”是另一条路径，只在原单待打款、应付为正，并具备相应平台支付服务、有效平台通道账户和店铺通道资料时显示或允许处理。弹窗还核通道可用余额和实际金额；这与填开户名称后登记线下付款不同，不能向没有相应服务的企业承诺点击完成打款必定自动转账。
通道明确成功后，系统继续生成关联原结算的付款与店铺收款并保存交易流水；明确失败会反馈错误，未取得明确成功时先核原单和原支付流水，避免重新打款。未取得明确成功结果时，不能把没有明确失败当成已经成功，页面一次“操作成功”或仍显示旧状态，也不够证明钱已转出或银行可用余额已经增加。
保存原结算编号、店铺、应付和本次金额、通道交易号、发生时点、实际反馈，以及双方原收付款单状态。资料已变化、当前状态不允许、缺有效通道账户或分账明细缺失分别处理，不删除重建绕过原结果。当前完整权限、并发和跨通道资金结果仍需同数据核；银行到账与系统已结算分开，结果未知先追原链而非再次转款。
图9：线上转账的通道返回与银行结果分开
下一步学习
- 联营结算闭环：周期生成、返点扣点、审核与打款核对｜云上订货系统
- 店铺商家商品审核：销售价格、商品状态与上架结果｜云上订货系统