客户预存款与返款余额：变动查询和资金核对｜云上订货系统
云上订货 · 更新于 2026-10-02
客户问“账户还剩多少钱”，先确认问的是预存款、返款，还是扣除订单应付款后的结余。财务需要解释金额由哪些原业务形成，业务员需要知道能否用于本次订货，客户需要核自己的账户明细。这三种问题不能只报一个余额解决。本文沿原客户两类账户、充值扣款审批和逐笔变动展开，历史例子为预存增加1000、扣减120后余880、返款为0；原值用于说明核对关系，当前操作应查本店最新记录。
先分清两类余额和账户结余
预存款与返款是同一客户下分别维护的账户余额。预存款用于店铺允许的后续订货或抵款；返款承接相关业务产生或维护的返款资金，可否用于当前订单仍受支付方式和交易条件限制。返款不是业务员佣金，也不能把退货已提交等同于返款已经增加，应查原退货、付款或余额变动结果。
手机商城的账户结余按页面组成核算：预存款余额加返款余额，加退货待退款，再减订单应付款。这是净额关系，不是可提现余额。比如预存880、返款0、订单应付200、退货待退款50，结余为730；可用预存仍为880，退货待退款50也不等于已进银行。四个组成各有业务对象，不能为了把结余变回880就改客户余额。
图1：历史手机商城显示预存880、返款0、订单应付0和退货待付款0，因此结余880；组成变动后结余不一定仍等于预存。
图2：余额、待退资金与订单应付分别有原来源；示例880加0加50减200为730，净结余不代可提现金额。
在PC端按客户查看资金
管理端进入客户资金，按本店客户名称和档案定位，分别看预存款、返款，再打开对应明细。列表可按客户类型或余额类型筛选，顶部汇总反映当前查询范围；即使搜索只出现一家店，也先核具体客户行，不能把搜索结果汇总当成任意门店的余额。不同客户、不同币种的数额不直接互抵。
充值、扣款、预存款明细和返款明细各有权限。需要看逐笔来源应进明细，周期统计则统一客户范围和期间；某个按钮没出现先核权限和当前条件，不另建客户绕开。门店改名或联系人更换，不意味着资金要迁到另一个相似名称档案，回原客户身份及历史业务核对。
图3：历史PC搜索范围的预存汇总880、返款汇总0；这张图只显示汇总区域，具体客户归属仍应进入原客户行和明细核对。
充值时核对账户类型和来源
从目标客户行进入充值，确认账户类型、真实来源、金额与备注，再提交。店铺固定预存账户时不要假定能自由改成返款；允许选择时也应按原业务归类。客户已经付过一笔订货款，不能同时把全额记在订单收款和预存充值中，除非核清实际用途及对应处理关系，否则账户看起来有余额而原款已被重复计算。
现金与银行转账对应的单据链路不同。银行路径按入口补账户等资料并生成关联收款记录，现金路径不能视作银行已联网确认到账。充值前先查原交易是否已有申请、收款或余额变动；业务员代录和财务补录是同一笔钱的协作，不是两次充值。示例输入1000只是原充值金额，保存提示还需区分申请与已生效结果。
图4：历史PC原客户预存充值1000、现金方式与来源备注；表单填写本身不证明余额已生效或银行到账。
手机管理端充值金额要求正数、最多两位小数，提交时要有附件；备注按该入口限制填写，不把订单收款备注规则套过来。附件应能说明本次真实来源与用途，而不是随便上传一张图满足必填。资料缺失只表示未达到提交条件，客户真实付款是否发生仍回原交易核实。
图5：现金与银行路径、是否启用充值扣款审核分别决定后续记录；同一原交易只接续一次，申请、关联收款与余额分别回查。
扣款不能超过本账户余额
扣款前核原客户、账户类型、当前可扣余额及原因。PC按所选预存或返款账户校验额度，不将另一类账户或另一客户余额凑进来。历史预存1000时填1200被拦截，说明该账户额度不足；当前余额可能已被其他业务使用，不能凭昨天截图重新提交旧额度。提示数据已变更时先刷新明细和余额。
扣款金额仍填真实正数，由扣款操作表达减少，不能填负数当充值。人工调整120后余额880，要保留调整依据和原业务，而不是只写“平账”。需要抵订单款时走实际允许的抵用或核销关系；需要将钱退给客户时核付款及实际转回结果，余额减少120并不自动证明订单已收120或银行已经退120。
图6：历史原账户扣款1200提示不能大于可扣款金额；这是校验失败，不能据此认定已经扣除或已经退款。
扣减与实际资金支出还有不同记录路径，按真实来源选择方式，并查相关付款或余额明细。不能为让表单通过临时充值一笔无来源的款，随后再扣掉；这样会新增两笔假变动，原来余额为何不够仍没有解释。错客户或错账户先停追加，交原记录给财务判断允许的纠错方式。
启用审批时等待审核生效
本店开启充值扣款审核后，提交先形成对应申请，提示“提交充值申请成功”或“提交扣款申请成功”。先在该客户申请记录查状态，再看审核后余额和关联单据，不能把申请金额加进已生效余额。未开启审核的路径也应核最新余额明细，不只停留在保存成功提示。
PC充值与扣款分别有审批列表。待审申请在权限允许时可审核或驳回，充值审核与扣款审核的制审分离条件按对应收款或付款设置处理；制单人被拦截，就由另一位有权人员沿原申请接续。充值审核启用流水查重时查同账户原记录，不能改真实号码绕过。被驳回先看原因和原申请，不另交同额申请制造多个待办。
纠错条件也不相同。现金充值记录在完成且权限允许等条件下可有作废入口，银行转账生成的记录不能套现金充值作废方式；扣款列表不能默认也有相同作废按钮。系统提示拦截时交财务查原链路，不能直接改余额消除差异。网络未知先查原申请及关联单据，确认未生效后才按最新条件接续。
在明细中解释880元怎样形成
预存款明细核类型、变动金额、支付时间、变动后余额、备注、附件及创建信息；返款明细同样按自己的记录核来源。每一行“余额”是该次操作后结果，不是这一行新收到的钱。历史两行分别为充值1000后余1000、扣款120后余880，不能将1000和880两个行后余额相加，报成客户有1880。
图7：历史预存变动为加1000、减120，各自行后余额为1000和880；余额列不再累加。
周期核对用同一账户的期初余额，加本期已生效增加，减本期已生效减少得到期末余额。例子期初为0且本期只有两笔有效变动，才是0加1000减120等于880。筛选只留“充值”会漏扣款，列表只加载第一页会漏旧记录，申请待审也不能算进已生效金额；先补齐同一期间完整变动，再与最新余额比较。
图8：期初0、本期有效增加1000、有效减少120，期末880；申请金额和各行后余额都不重复加入。
余额抵订货款时回原订单看实际抵用，退货或作废产生返款时回原退货及原款核结果。PC预存明细的有关备注可承接原订单或退货，其他类型未必都有同样跳转。找不到原记录先核类型、期间、已加载页和账户，不只挑一个同金额流水解释。手动调整与业务自动变动分开留依据，才能说明为什么少了这一百二十。
手机端查看两类资金与明细
手机管理端从客户资金定位原客户，分别查看预存款与返款明细。现场只需回答余额来源时先查明细，不顺手再做充值扣款。历史手机两条记录与PC的增加1000、减少120一致，说明两端展示的是同一变动链；不能因业务员用手机、财务用PC，就把同一原交易各登一次。
图9：历史手机预存明细显示扣款120后余880与充值1000后余1000；返款应切到另一明细核查。
两端不一致先刷新并统一本店、原客户、账户类型、币种和期间，查看申请是否已审及记录是否加载完整。手机看不到管理操作或客户商城没有审核按钮，是身份和权限边界问题，不能重建客户或借普通客户账号管理资金。原客户身份核清后仍有差异，交财务原记录逐笔查。
让客户在手机商城自行查看来源
客户登录本店手机商城，从“我的”账户结余打开组成，点击预存款或返款余额进入对应明细；订单应付款和退货待付款另回相关订单或退货。商城明细支持刷新与继续加载，别把只显示的两条记录当所有历史。先确认当前登录对应哪家门店客户档案，换了店铺或子账号不要混用旧截图。
图10：历史手机商城预存余额880，列出扣款120与充值1000的来源备注；客户查看自己的记录，不代管理端审批。
向客户交接应明确两类余额、未审核申请及本次实际抵用，而不是说“账户里有钱就不用付款”。余额可见不代当前订单已抵用，结余为正不代所有订单结清，退货待退款不代银行已退。说明原交易时间、变动原因和订单关系，客户能自己回查，也能知道仍须由财务处理的环节。
图11：先查身份账户、审批、期间和完整明细，再分辨抵款与退款；不为对齐显示而人工修改余额。
常见问题
预存880元，结余为何可能是730元？
例如返款0、退货待退款50、订单应付200，结余按组成得730。预存880仍是独立账户余额，先查对应原订单和退货，不把差额150当成新扣款。
客户已经转账，充值申请待审，能否再充一次？
先查原交易是否已有申请与关联收款，由财务核到账并接续原申请。待审不说明没付钱，重复充值会造成余额和到账不对应。
扣款120后余额880，为何客户没收到退款？
余额扣减只证明账户变动，实际退款要查付款或原渠道结果；订单抵款也另查原订单。把三个结果分开核，才能确定下一步应处理哪一环。