一家食材配送企业与连锁餐饮总部谈妥价格和月结，十家门店每天分别在商城下单，仓库照单送货。月底总部说某门店还没确认实收，要等所有门店对完才付款；门店却说“合同是总部签的，欠款找总部”。如果建档时只把十家门店当作十个普通客户，企业会遇到两类危险：给每店分别设三十万元授信，本想控制总部三十万元风险，却实际放大为三百万元；或者全部记在总部名下，事后找不到是哪家店短送、退货和未确认。解决办法不是选“总部”或“门店”其中之一，而是先分清合同、下单、收货和付款四种角色，再让授信与应收按真实责任主体汇总，让履约差异按门店保留。
第一张图先画清四个角色，不能用品牌名代替责任主体
合同上的买方是谁，谁有权选择商品并下单，谁在现场按实收签收，谁实际付款，未付款时谁承担责任，应在首单前逐项确认。直营连锁可能由总部统一签约与付款、门店只负责订货和收货；加盟连锁虽然挂同一品牌，各加盟商却可能各自签约、自付货款；还有一部分直营店走总部月结、加盟店单独结算的混合模式。客户档案里“属于同一集团”只能说明管理或品牌关系，不能自动证明总部为所有门店订单承担欠款。
将门店地址、收货人、允许采购的商品范围、结算归属、发票信息和业务员负责人写清。若总部统一付款，门店需要知道可以按总部协议价下哪些商品、一次最大订多少、何时截单；财务需要知道这些订单最后归哪份合同和哪一个应收主体。若加盟店自己付款，就应有独立的结算资料和授信审批，不能因为同品牌便让总部额度覆盖其欠款。组织结构改变、门店转加盟或关店时，要用生效日期保存前后关系，不能把过去已交付订单的欠款主体随档案修改一并改掉。
图1：同一单至少涉及签约、下单、收货和付款四种角色；客户层级应服务真实交易关系，不能代替合同。
授信先控制“谁最终付钱”，再给门店分配可用范围
假设总部确为统一付款人，企业批准三十万元共享额度。A店已用十二万元、B店九万元、C店五万元，其他条件不变时剩余四万元。若系统里给每店单独设三十万元且没有总部合并复核，门店实际最多可能合计占用九十万元，远超审批时的三十万元。共享上限也不表示门店想把全部四万元一次买走就一定允许：可以另设门店日采购限制、异常品类复核和总仓可交量，防止某店超量影响其他店的正常供应。
“已用额度”要有一致口径。有的企业仅把已发货未收款算进去，待审核或已接未发的订单被遗漏；有的企业又把已退款或已收款但尚未核销的金额算进去，导致可用额度过低。首单前应与财务约定：待发承诺是否占额、已签收未对账怎样占额、退货何时释放、实际到款何时恢复额度。若系统现有规则无法自动完成跨门店共享计算，企业应在PC管理端订单汇总和财务记录之外建立人工总额复核，不能向业务员宣称“页面显示没超限就一定能接”。
图2：总部共享额度要合并所属门店的真实风险敞口；门店各设同额并相加，可能把原审批上限倍增。
若门店独立承担付款责任，总部只负责采购框架或品牌推荐，则每家店的信用评估、额度和欠款追索要分别处理。不能把一店拖欠的款项直接冲减另一店在总部名下的货款，也不能擅自以总部“控制门店”为由假定其承担保证责任。此处谈的是业务数据与授信管理，具体合同债务和担保安排必须由企业依据已签文件确认；系统配置应反映真实关系，而非创造关系。
门店订单逐笔留痕，总部对账按净额汇总
门店用手机商城或其他授权入口下单时，订单要记下门店、商品规格、数量、实际成交价、预计到货日和所属结算主体。配送时按门店分别装箱、交接、签收；A店实收十箱油、B店实收八箱而有两箱短送，就不能把总部总数十八箱写成“两个门店都已签全”。每家店的差异要能回到原订单和发货记录，客户总部对账时才能知道一笔扣款是价格争议、少送、质量退货，还是尚未付款。
财务按合同约定周期生成总部对账底稿，明细至少能按门店、订单、商品、发货、实收、退货和收款追溯。总部确认无争议货款，但其中一个门店仍在核退货时，可先区分无争议部分和待确认部分，按合同沟通支付安排。不能为“让金额对上”另开一张虚拟订单，把原订单短送和库存差额藏掉。若总部要求一张总发票或各店独立开票，开票和财务归属应与真实交易及企业财务要求一致，不应把“合并对账”误解为能随意改变发票抬头或债务主体。
图3：门店实收差异必须逐单可查，总部对账才有可以解释和追踪的净额。
欠款责任并不因为门店先垫付款就自动改变。若直营门店偶尔现金补付，要记清它是替总部付款还是独立采购；总部统一付款后，门店内部的费用分摊不应反向改变经销商对总部的应收。相反，加盟门店自己与经销商签合同并自付，首页展示同一连锁品牌，也不能把其欠款挪到总部门店汇总里“统一催”。一笔款到账后，应按双方确认的订单或账期核销，无法对应时先标记待核，不要因为月末要出报表就随机冲减旧欠款。
商猫云链中的客户层级，要与价格、权限和单据流一起设置
在PC管理端，先维护总部与各门店的客户资料和关联关系，分别确认合同价适用范围、结算主体、业务员归属、可售商品与配送地址。总部价格不一定适用于加盟门店，促销价也未必覆盖合同指定品；要用一笔样例订单验证不同门店最终看到的价格和计量单位。手机商城是门店下单优先入口，门店应只看到授权货盘、自己的订单及适用价格，不能因为隶属于同一总部就互看其他门店的交易详情。业务员代客下单时同样要选择实际收货门店，保留代客操作记录。
订单进入审核、采购、仓库拣配、发货、签收和售后后，门店维度用于处理真实履约，总部维度用于管理协议与汇总对账。PC端适合财务核跨门店欠款、价格执行与授信总额，手机管理端适合业务员跟进自己负责门店的短送、退货与催收沟通。系统若已支持相关多级客户、授信或数据权限功能，应按当前租户实际版本配置并用样例订单验证；若某一跨店控制没有直接配置入口，就在审批与对账环节设置人工复核。文档不能把“可通过流程衔接”写成“系统自动完成所有合同责任判定”。
合同变更也要测：某店从直营改为加盟时，新订单从生效日按新的结算主体和价格执行，旧订单仍保留原债务与发票记录；门店换收货地址，不能让此前发生的签收证据丢失。停止供货若由欠款触发，先核是总部总额超限还是单店违约，避免一处差异把其他已接订单无故取消。规则改变应在客户可见订单承诺前生效，不能借资料修改倒改原单。
三种连锁结构，验收时分别选一笔正常单和一笔争议单
总部统一结算模式，先选两家门店下正常单，核各店价格、可用货盘、发货签收，再看总部对账能否汇总且保留门店明细；异常单选择某店短送，验证总部应收净额和该店补送责任如何更新。门店分别结算模式，验证A店欠款不会误占B店额度，A店回款也不会被错误核销到总部。混合模式，至少放一笔直营门店和一笔加盟店订单，检查直营走总部合同，加盟按自身合同付款，品牌层面的经营汇总与财务应收两套口径互不混淆。
图4：先核合同与真实付款责任，再选择客户建档、价格适用和授信方式；不能只看品牌是否相同。
完整试跑一个账期后，关注三项结果：已接订单的总风险敞口是否始终在批准范围内；月末对账差异能否逐店逐单解释；实际到账能否核销到正确的应收主体。若订单已经发出，客户还在争论该由总部还是门店付款，问题不在催收话术，而在首单前交易关系没有讲透。业务员、财务和客户各拿同一笔单据验证责任，比继续增加新的门店订单更重要。
判断是否可以扩店：看总风险、单店履约和第一次真实回款
区域扩张时，新门店加入既有连锁合同，企业不能只复制客户档案就放单。总部应确认该门店是否属于合同范围，价格与额度是否沿用，配送地址和交期能否兑现；财务复核当前全集团已用风险，仓配核新地址是否增加路线成本。加盟店新加入更应先核独立结算还是总部担保，不能因为“也是这个品牌”便自动给月结。首月保守开放常用品和可交范围，客户按实际使用复购、门店签收差异关闭、总部第一次按约到账后，再决定开放更多品类或更高额度。
企业最终要得到两层清楚的账：上层能看到合同客户或连锁集团的合计交易、资金占用与价格贡献，下层能找到哪一家门店下了单、收到了多少、为何退货、哪笔款仍有争议。商猫云链提供客户、商品价格、订单、采购发货、收款对账与权限管理的业务记录，合同主体和付款责任仍须由企业按实际协议确认。把授信放在真正承担欠款的层级，把履约差异留在真正收货的门店，才能既争取连锁订单规模，又不让门店数量悄悄放大信用风险。