库存协同 · 销售与仓库 · 账实差异

库存不准，
先崩的是销售

中小企业仓库与销售配合的五个断点，与一份可落地的修复协议

销售在系统里看到库存 200 个，打电话给仓库说"发 150 个"，仓库说"哪有 200 个，只有 130 个"。差的 70 个没被偷——50 个是已发货但出库单没录，20 个是 A 仓调到 B 仓但调拨单没确认。

多数老板把这个场景归档为"仓库管理问题"。归错档，就修不好它：仓库主管货架在手边，永远知道真实数字；先被坑的，是拿着系统数字对客户做承诺的销售。本文把销售与仓库的配合拆成五个断点，算清三本账，给出一份用超兔一体云落地的修复协议——把两个部门之间的"电话协议"换成"单据协议"。

先发后录已订未发单据协议日清库存台账3.0

超兔一体云 · 产品团队 / 22 年企业数智化一线观察 · 技术和场景系列

发布时间：2026-08-28 14:15

01现场：发货日的三个尴尬

一个工贸企业的周三上午，销售接到客户电话，要 150 个某型号产品。打开超兔 CRM 的库存查询，显示该产品库存 200 个。销售给仓库打电话："发 150 个，客户急用。"

仓库那边沉默了三秒，然后说："哪有 200 个，只有 130 个。"

差的 70 个去了哪里？仓库主管翻了半天，找到三个原因。

尴尬一：50 个已经发了，出库单没录

上周五发了一批货给另一个客户，实物出库了，出库单还没录进系统。系统里这 50 个还在"账上库存"里，货架上已经没有了。销售看到的是账面库存，仓库看到的是实物库存，两个数字的差，就是出库延迟的时间差。

尴尬二：20 个在 A 仓调到 B 仓的路上

这 20 个从 A 仓调拨到 B 仓，A 仓已经出库，B 仓还没入库确认，调拨单处于在途状态。实物在搬运途中，按总量查数字没错，按仓库查两边都对不上。

尴尬三：系统里有个负数

某个产品先录了出库单（销售催得急），后录入库单（采购到货还没验收），系统库存短暂出现过 -5。实物还没到，账上已经扣了。负库存是录入顺序和实物动作顺序不一致的信号。

数字错误的真实成本，在接下来的一小时里才逐步展开。

销售挂掉仓库的电话，回拨客户："我下午给您答复。"客户在那头等。仓库主管放下正在拣的另外三张单，带人到货架数了二十分钟，确认不是自己记错，又去翻上周五的发货记录追那 50 个的去向。老板被拉进一个三人群，三个人在问同一句话：到底有多少货？一个数字错了，三个人的上午没了。

老板的结论是"仓库管理有问题"。仓库主管的申辩在理：货到的时候在卸车，卸完在验收，验完在上架，等打开电脑录单，两个小时过去了——录入永远跟不上实物。两个人都对，两个人的方案都没用：这个场景里，被坑的从来不只是仓库，也不只是那 70 个货。

02库存数字：谁生产，谁消费

仓库是库存数字的生产者，销售是库存数字的消费者。这个分工天然埋着一个问题：消费者拿到的，永远是旧数据。

系统库存的本质，是"最后一次录入时刻的快照"。货可以先到，单可以后录；货可以先发，单可以后补。所有影响库存变化的操作——入库、出库、调拨、盘点——都会自动记录进入库存流水账^[1]，但流水账记的是"已发生的操作"，不是"正在发生的操作"。实物动作和单据录入之间的时间差，单个操作只有几十分钟到几小时；一天几十上百个操作叠加，快照和实际之间的漂移就大到影响业务。

关键在漂移的方向性伤害。系统偏高（出库没录），货没了系统以为有——拿着这个数字承诺客户的销售，会超卖、违约、赔钱；系统偏低（入库没录），货在架上系统不知道——拿着这个数字的销售，会丢单、不敢报价、把客户让给竞品。两个方向，挨打的都是销售。仓库主管从不需要"查询库存"，货架就在他手边，实物永远比数字准。

于是销售进化出一套生存策略：不管系统显示多少，打电话问仓库。这套策略有个别名，叫系统失效。每一通库存电话，都是销售对系统数字投出的不信任票。电话打顺了，系统就成了摆设——钱花了，系统上了，查库存还是靠嘴。

03五个断点：配合在哪里断的

从销售对客户做承诺，到货发出去、账对上，中间有五个信息断点。拿这五个断点去自己的公司对号入座，比笼统地查"库存准不准"有用——每个断点对应一个具体环节，也就对应一个具体的修法。

断点一 · 承诺：账面数不是可发数

销售查到库存 200，里面可能躺着 150 个已订未发——其他销售的订单已经开了，货还没出。账面 200，可发的可能只有 50。两个销售先后看中最后 50 个货，先后对客户做了承诺，撞单就发生了。销售承诺的依据是账面库存，客户要的是可发库存，这两个数字之间隔着一道没人看的缝。

伤的是谁：做承诺的那个销售，和最终发不出货的那个销售。

断点二 · 查询：电话成了系统

承诺之前先打一通电话，是中小企业的标准动作。代价被普遍低估：仓库被打断手头的拣货，要去货架现场数；销售在工位上等回电；客户在电话那头等销售的回电。一通电话十五分钟起步，一天几十通，两边最忙的人，时间都耗在确认一个本该一眼看到的数字上。

伤的是谁：销售、仓库、客户三方的时间，没有人对此记账。

断点三 · 发货：先发后录

销售催得急，仓库先发货后录单，这是业务节奏决定的常态——没有人能要求仓库"录完单再发货"。但出库单不落地，账面就虚高，下一个查这个数字的销售就会被骗。先发后录是断点一的燃料：每延迟录一张单，就给下一个销售埋一颗雷。

伤的是谁：下一个基于错误数字做承诺的销售。

断点四 · 调拨：在途悬空

A 仓调到 B 仓，A 仓出了库，B 仓没入库，这批货在系统里两边都不算。按总量查数字对，按仓库查两边错。客户要的货显示"在 B 仓"，其实在路上。多仓库企业按仓划分销售区域时，这个断点直接决定区域销售敢不敢对客户做承诺。

伤的是谁：负责 B 仓区域的销售，和被反复调度的仓库。

断点五 · 对账：月底罗生门

月底盘点，账实差了 300 个。销售说"我这单上周就发货了"，仓库说"你的出库单呢"。没有流水证据的时候，对账靠回忆和嗓门，最后老板仲裁，两边各挨五十大板。差异原因查不清，下个月原样再来一遍。

伤的是谁：被迫当裁判的老板，和被各打五十大板的两边。

04三本账：数据不准的真实代价

把账实不符的成本理解成"数据不准"，是小看它。真实代价分三层，一层比一层贵。

账一 · 直接亏损，写在报表上

系统偏高，销售超卖：客户交期违约，赔款或者流失。系统偏低，有货不敢卖：订单流向竞品，丢单连数字都留不下。分仓不准，重复采购：B 仓其实有货，又下了一单采购，库存积压吃掉现金流。

账二 · 时间亏损，写在人的疲惫里

中小企业最贵的资源是那几个关键人的时间。销售的下午从"跟客户、拿订单"变成"打电话、找货、协调仓库"；仓库主管从"发货"变成"接电话、数货、翻记录"；老板从"做决策"变成"当销售和仓库之间的仲裁接口"。这些时间不出现在任何报表上，但每天都在发生。

账三 · 信任亏损，写在系统的闲置里

最隐蔽的一本。库存数字不准几次之后，销售形成条件反射：不信系统，信电话。习惯一旦形成，系统的库存功能形同虚设。数据可以一次盘点修平，信任要几个月的持续准确才能重建——重建期间，电话照打，系统照闲。

05修复协议：把电话协议换成单据协议

修复的方向，是给销售和仓库之间换一套协作协议。两套协议的差别，先摆清楚：

总原则只有一条：让每一次实物动作，都有一个同时发生的单据动作。不是"尽快录"，是"同时录"——把录单嵌进发货动作里，与发货同步发生。

协议一 · 开单即派单：销售开单，仓库见单

销售订单在 CRM 里落地，同步到仓库，自动锁库、生成出库任务^[2]——仓库看单作业，不再等电话。订单和出库挂上钩之后，"已订未发"从一道缝变成一个看得见的状态：第二个销售开单之前，能看到这批货有多少已经被前面的订单占着，撞单在源头被掐断。仓库的作业队列也从此有了排序依据——先到先得，单据就是排队凭证。

直接出库（不关联订单，新建出库单直接扣减^[1]）留给真正的临时场景：样品、赠品、急件补发。它不应该成为常态——常态化的直接出库，等于绕过销售订单做库存扣减，账实差异的口子从这里撕开。

协议二 · 确认即扣减：拣货确认的时刻，就是扣减的时刻

出库单嵌在拣货流程里：拣货员按单取货，取完确认，出库生效，库存同步扣减。仓库的动作从"事后回办公室录单"变成"当场在流程里确认"——录单不再是发货之后的第二份工作，是发货本身的一部分。

入库同理：验收通过的同时录入库单。系统支持直接入库和采购入库两种方式^[1]，验收现场就能完成，不用回办公室。

协议三 · 调拨当日闭环

调出库管和调入库管分别确认——超兔调拨单的信息流是双向独立的，确保调拨过程可追溯^[1]。规则加一条：当天发起的调拨，当天完成入库确认，不过夜。过夜的调拨单就是"中间态"的来源，A 仓的数字和实物的距离，一个晚上就足够拉出一条没人能解释的缝。

协议四 · 日清：当天的单据当天清零

单据协议的兜底机制。每天下班前，仓库留出三十分钟做日清：在出入库流水里筛出今天创建但未确认的单据，逐张处理——发完没确认的确认，调拨在途的催入库，异常的挂出来明天优先。当日事当日毕落到操作上，就是这三十分钟。日清做不到 100% 没关系，做到 90%，月底的罗生门就少九成。

协议五 · 信任分批重建：从 20 个 SKU 开始

最反直觉的一条。修复信任，不要从"把全仓库存做准"开始——全仓做准要全员盘点、老板督办，中小企业耗不起，也坚持不了。换一个打法：

选销售最常卖的 20-30 个 SKU（高频、高价值、客户常催的），只对这一批执行最严格的单据协议——开单即派单、确认即扣减、每周小盘。连续四周，抽盘差异控制在 1% 以内。然后正式通知销售：这 20 个 SKU 的库存数字可以直接用，电话可以停了。

销售对这 20 个 SKU 的信任建立之后，第二批、第三批跟上。信任是 SKU 粒度重建的，不是全仓粒度的——"库存已经准了"这种宣布没人信，"这 20 个货号准了，你试试"这种承诺可以被验证。

06一个下午的体检：四步排查

协议是长期功课，排查是眼前止血。四个动作，用系统已有的功能，一个下午做完，把账实差异定位到"哪个产品、哪个仓、断在哪个环节"。这张清单就是修复协议的起点。

第一步 · 出入库流水比对：查时间倒挂

所有影响库存变化的操作都自动记录进入库存流水账^[1]。导出最近一周流水按时间排序，看出库单时间早于入库单时间的记录——每一条时间倒挂，都是一次"先出后入"的漂移证据。这一步查的是录入时序。

第二步 · 库存台账核对：查算不算得平

库存台账反映某一阶段的库存期初值、期末值，以及期间的入库和出库合计^[1]。挑高频产品，核对"期初 + 入库 − 出库 = 期末"是否成立。公式不平的产品，中间一定有操作没进系统——该入库的没入，该出库的没出。

第三步 · 负库存扫描：找最严重的先出后入

导出全部产品当前库存，筛出负数。负库存是录入顺序和实物动作顺序不一致的信号——负多少、负了多久，就是漂移有多大、持续多久。这些产品是最需要优先堵的口子。

第四步 · 抽样盘点：用实物校验系统

盘点清点实时仓库库存与系统库存是否一致，不一致时通过盘点差异使之一致^[1]。不用全仓盘点：挑 20 个高价值或高周转 SKU 实地数一遍，和系统数字对比，差异超过 5% 的就是重灾区。抽样盘点一个下午能做完，成本比全仓盘点低一个量级。

07什么算修好了：看行为，不看数字

判断配合修没修好，标准不在库存准确率上——没有中小企业能做到 100%，也不需要。看四个行为信号，它们比数字诚实：

回到开头那个销售。下次客户打电话要 150 个，他打开系统，看到的不再是一个"最后一次录入时刻的快照"，而是可发库存、在途调拨、未确认单据都在眼前的作业视图。他敢不敢直接对客户说"有，明天发"——他对这个问题有把握的时候，系统才算真的上线了。