去年双十一复盘的时候，我团队一个运营主管盯着系统数据跟我说：“不可能，我们海外仓明明还有3800件货，为什么报表显示在途只有120件？”后来拉了物流详情一比对，发现那批货船运走了33天，系统里早就被自动置为“已完成”，根本没挂在途标记。财务按系统报表做了应付账款冲销，结果供应商催款电话打到了老板那里。整个链条上没人做错任何事，采购下单了，仓库点货了，物流发走了，系统也跑完逻辑了。但“在途库存”这四个字，像一道谁都看见了、但谁也不管的裂缝，硬生生把公司账面扯出近四十万的差异。
这件事之后我花了大量时间去复盘和修正，带着IT、财务、仓库一起把近三年的在途数据全量盘了一遍。后来我陆续又帮几家年GMV在五千万到十亿级别的消费品牌做过类似的数据治理项目，发现了一个非常普遍但极少被认真写清楚的事实：大多数公司在途库存不准，问题不出在某个系统功能缺失，而出在整个组织对“在途”这个状态的认知不一致、管理边界不清晰、修正流程没有分级处理能力。
这篇文章我从头讲起：在途库存差异的本质是什么、为什么会反复出现、诊断应该从哪里下手、不同严重程度的差异该用什么样的修正方案、修正完怎么防止下次复发。每一个判断都来自我亲身踩过的坑和实际跑通的项目流程，不是百科整理，也不是产品说明书。
这是我在给几个品牌做完数据诊断之后反复验证的一条判断：绝大多数在途库存差异，根源不在系统，而在于业务流程中“谁负责维护在途状态”这件事没有明确的单一责任人。
很多公司采购部认为自己下完单就完事了，仓库认为没收到货就跟自己没关系，财务只认单据状态，物流只认运单号。结果没有任何一个岗位真正对“下单后、入库前”这段时间内的库存状态负责。系统能做的只是按规则跑数据，规则本身就是靠人工配置和人工触发来维护的，一旦上游某个环节没触发、或者触发错了，后面的数据链就会产生系统性偏差。
举一个非常典型的链条断裂模型：
三个月后，这笔采购订单在ERP里仍然挂着2000件的在途数量，而实际货物早在仓里出库了好几轮。这个差异一旦累积到季末盘点，经常会让管理层对库存周转率、资金占用这些核心指标产生严重误判。
所以我的第一个核心结论很直接：在途库存不准的本质是组织协作问题，系统只是这个问题的最终显现层。如果你打算彻底修正，必须先解决“谁对在途数据的准确性负责”这个管理问题，否则任何系统层面的操作都是暂时性的。
当时我排查的第一步不是改系统，而是先把近一年所有“在途数量大于零但超过30天”的采购单全部拉出来。结果3000多行数据里，超过40%属于异常在途，所谓异常，就是这批货实际上已经入库、甚至已经出货，只是因为各种原因系统侧的状态没关。
我带着这些数据去找三个部门分别对表，发现了几类非常典型的差异成因，我在这里列出来，因为这本身就是一套诊断框架，读者可以直接拿去对照自己的ERP数据：
ERP里允许一张采购单分多次收货，但很多培训不到位的情况下，仓库在收完最后一批货之后，并不会去系统里手工关闭采购单行。系统逻辑默认采购单行“无限制等待”，只要没关，它就永远挂着在途。
尤其在使用第三方物流平台的情况下，签收状态回传经常会有24-72小时的延迟。对于周转速度快的品类，比如社区团购、生鲜、快消品，这种延迟就意味着在你还没收到签收回传的时候，货物已经分拣出库了，系统里的在途数据永远是滞后的。
财务按供应商对账单确认应付，这个动作在很多公司并不会触发系统在途状态的更新。也就是说，财务系统认为“已结算”，但库存系统认为“还在路上”。两个系统的口径不一致，管理层看报表的时候两边数据打架。
这是很多中小公司完全没意识到的问题。A仓调拨到B仓时，如果出库仓做了出库、入库仓没有及时做入库确认，系统会同时存在A仓的调拨出库在途和B仓的调拨入库在途，表面数量看起来没少，实际上其中一笔已经是废数据。
这四种情况在不同的行业里权重不同：电商品牌更多出在物流回传上，零售连锁更多出在调拨场景，制造业更多出在采购分批到货上。但底层逻辑完全一致，只要系统里存在一条未关闭、且无人认领的在途记录，它最终都会成为报表上的偏差。
很多管理者发现在途库存不准之后第一反应是“调系统”，但这恰恰是最容易踩的坑。因为在没有搞清楚差异究竟是一般性延迟、流程性遗漏还是系统性逻辑错误之前，盲目调整很可能造成二次污染。
我自己的操作流程是一个三步诊断框架，适用于ERP环境下的全量在途数据排查：
从ERP导出所有当前在途数量大于零的单据，字段至少包括：单据号、创建日期、最后操作日期、在途数量、供应商/仓别、单据类型（采购在途/调拨在途/销售退货在途）。然后给每条记录打上“在途天数”标签，在途天数超过该业务场景正常周期上限的，标记为“异常在途”。
拿着异常在途清单，逐条到仓库做实物核查。这一步极其繁琐但不可或缺。因为你必须确认：这批货到底在不在仓库里？如果不在，是还在路上、还是已经丢了？如果在，是忘记做入库确认、还是状态挂错了？实物验证的结果直接决定了你下一步是用系统调整还是用财务处理。
我把所有验证后的异常在途归类成三种类型，每种类型的处理方法完全不同：
| 差异类型 | 定义 | 典型场景 | 建议修正方向 |
|---|---|---|---|
| 流程性差异 | 实物已入库但系统状态未更新 | 仓库忘做收货确认、物流回传延迟 | 补单修正、系统对冲、无需财务调整 |
| 数据性差异 | 实物与系统数量不符但单据路径可追溯 | 分批到货、部分退货、调拨中途差异 | 系统冲销加调整单、需部门会签 |
| 系统性差异 | 系统逻辑错误导致的批量偏差 | 自动对冲规则失效、接口数据漏传 | IT主导回刷、需回归测试和审批 |
关键原则：绝不在实物盘点完成之前修改系统数据。这么做看似慢，实际上是最快的方式。因为一旦你改了系统数据又发现实物对不上，回滚的成本远高于先盘一遍的成本。
类型: 流程图
标题: 在途库存差异诊断与分类决策路径
插入位置: 本段之后
说明: 该流程从"拉全量在途清单→打异常标签→实物验证→三类差异归类→选择对应修正方案"完整展示了诊断到行动的决策路径，帮助读者在实操中按步执行而非凭直觉调账。
这是我在第一次做在途清理时犯过的错误。当时发现系统中有一万多条在途记录存在差异，我试图一次性全部修正，结果耗时三个多月，中间反复拉扯审批、跨部门沟通、系统调试，最后财务还不敢认调整后的报表，因为跨度太长、中间又发生了新的业务数据。
后来我建立了一套分级处理的标准，效果明显提升。核心逻辑就一条：按差异金额和业务影响面把修正任务分成三级，每一级对应不同的处理深度和审批流程。
这类差异单笔金额小、笔数多、原因明确。一般是日常操作中的零星遗漏，比如仓库漏做了一两次到货确认、物流回传延迟了几天。修正方式我建议做月度批量对冲：IT每个月跑一次异常在途报表，确认实物已到货的直接批量关闭在途状态，生成系统调整单，部门负责人月度签字确认即可，不用逐单审批。
这类差异单笔金额在部门审批权限范围内，但涉及跨部门协作。比如一笔调拨单在出库仓显示已完成、入库仓一直未确认，金额20万左右。这类情况需要仓库主管+财务主管+供应链主管三方会签，在确认实物归属后做系统冲销并生成正式调整凭证。
单笔差异金额大到影响当期财务报表、或者涉及外部供应商纠纷的，必须走专项流程。这类差异不要直接在系统里冲销，而是先在财务侧做预提/暂估处理，等调查清楚之后再由财务主导做系统冲销和凭证调整。这类差异的修正必须留下完整的审计证据链。
很多公司在这一步犯的错误是：把所有差异都按L3的规格去处理，结果流程冗长、管理层精力耗尽、一线人员疲惫，最后项目不了了之。正确的做法永远是用最低成本解决最大体量的问题，把精兵强将留给真正高风险的部分。
本小节的设定是假设你已经完成了前面说的实物盘点和分类诊断，下面进入系统操作层面。我先坦白说：我不是技术开发出身，但我全程主导过多个ERP/WMS在途修正项目的需求定义和上线验收，我在这里讲的每一种方案都是我在实际项目中看到并验证过效果的，同时也标注了每种方案的风险。
直接在系统里创建库存调整单，把在途数量调到零或者调到与实物一致，同时生成财务凭证。这是所有方案里安全性最高的，因为每一步都有人工确认和审批留痕。但问题也很明显：当异常在途数量超过几百条时，手工处理效率极低，而且极易因为仓库和财务对调整口径理解不一致而陷入推诿。适用于差异笔数少、金额敏感的场景。
IT直接从数据库层面写SQL，把满足条件的在途记录批量关闭或更新。这种方式五分钟内可以处理完手工三个月的工作量，但风险极大。即使SQL逻辑写得没问题，一旦实务上还有争议，系统数据一改就不可逆。我在实操中采用的方式是：先做备份表、跑模拟结果、相关业务负责人签字确认模拟结果、然后在测试环境验证、最后才在生产环境执行。每一步都有回滚预案。
这是我个人最推荐的一种方案，但它不是一次性的修正动作，而是对系统逻辑的优化。核心思路是：在ERP主表和物流实际状态表之间建立一个“在途缓冲池”，所有在途数据默认先进入缓冲池，等物流实际状态回传之后再自动从缓冲池冲销并转入正式库存。如果物流状态长时间不回传，缓冲池里的数据会自动触发预警推送给仓库主管。
这个方案的好处是从架构上解决了“物流数据漏传导致在途永远挂着”的问题。代价是需要一定的系统开发和测试投入，尤其对数据量大的业务场景，缓冲池的计算性能需要专门做压力测试。如果你的在途差异问题频繁复发且GTV规模较大，建议优先走这条路。
修正动作做完之后，大部分团队会松一口气，觉得“终于搞完了”。但是如果你不在这个节点把发现的问题固化成系统规则或操作SOP，半年之后你会发现同样的差异又慢慢积累回来了。这不是危言耸听，我在两家规模过十亿的零售企业都看过一模一样的曲线：大盘修复后管三个月，第四个月异常率开始爬升，半年后又回到修正前的水平。
所以修正完成之后，必须紧跟着做三件事，这三件事我把它叫做“关门动作”：
比如“采购单行超过30天未关闭的，系统自动预警推送仓库主管”，或者“物流签收回传超过48小时未写入ERP的，系统自动生成异常工单”。这些规则不是锦上添花，而是防止下次复发的第一道防波堤。
明确一个岗位对在途库存数据的准确性负责。这个岗位通常建议设在供应链计划部门或仓储部门，而不是IT或财务。因为IT有能力改数据但不知道业务上下文，财务关注的是核算结果而非过程状态。让最贴近实物流动的部门来Owner在途数据，是最合理的选择。
每个月固定拉出在途库存健康度指标，核心就三个：异常在途占比（超过合理周期的在途数量/总在途数量）、在途关闭延迟中位数（天）、未冲销调整单数量。这三个指标我放在管理者月度经营分析会的固定议程里，五分钟过一遍，持续关注三个月之后整个组织对在途库存的敏感度就会明显提升。
前面大部分内容以采购在途为主要场景，但在实际业务中，调拨在途和退货在途的差异处理有明显的特殊性，而且这两种场景在主流BI和ERP的报表体系里经常被忽略。
跨仓调拨最容易出问题的情况是：出库仓在系统里做了“已出库”，入库仓迟迟不确认“已入库”。系统里会出现一个诡异状态：A仓库存减少了，B仓库存没增加，中间的在途量理论上是一一对应的，但实际上库存总账面的数量是对的。很多公司因为总数量没差异就忽略了这部分的异常。
最危险的后果是：运营和库存在做分仓补货决策时，基于错误的分仓库存数据做调拨计划，导致一仓爆仓、另一仓缺货。这种情况在电商大促前尤其致命。
解决思路的核心不是技术，而是操作规范：出库仓在做调拨出库之前，必须先和入库仓确认仓位能力和接收窗口。入库仓在收到实物之后必须在24小时内完成系统确认。超过24小时未确认的调拨单自动升级为异常工单，抄送双方负责人。
退货在途的麻烦在于：客户已经申请退货，物流已经取走，但退货仓还没有收到或者还没有质检入库。这个过程中系统里的退货在途数量很可能与实际情况不一致。更麻烦的是，财务核算上可能已经把退货金额从应收里扣掉了，但库存系统还没入库，导致库存价值和应收余额同时失真。
对于退货在途的修正，我一直坚持一个原则：以物流签收为退货在途关闭的唯一节点，不允许以客户申请退货的时间作为系统状态变更的依据。也就是说，在退货仓完成实物签收和质检之前，系统不允许关闭退货在途。这会在报表上暂时保留一笔负向库存，但它比虚假的库存数据安全得多。
我不希望读者看完这篇文章之后觉得“说得对但不知道从哪下手”。这里给一个最小可执行方案，按周度推进：
从ERP里导出所有在途数量大于零的单据，限定近12个月，加一个条件：在途天数大于该业务场景正常周期的。比如采购在途超过30天、调拨在途超过7天、退货在途超过15天的，全部标记为疑异。这张表就是你的排查范围。
把疑异清单分给对应的仓库或区域负责人，要求一周之内完成实物盘点并反馈结果。反馈格式统一为：实物是否已在仓、如果不在，最后一次追踪到的物流状态是什么、建议处理方式。
汇总盘点结果，按前面讲的三类差异分组。L1的直接出批量修正清单让IT执行，L2的排出逐单处理时间表，L3的启动专项流程。这个过程必须有一份书面的修正方案，包含每类差异预计的处理周期、审批路径和负责人。
修正执行的同时，把月度的在途健康度报表搭建好，岗位职责更新到对应岗位的考核指标里，系统硬约束的预警规则提交开发排期。所有这些做完，你才算真正完成了从修正到预防的闭环。
这套方案在第一家公司跑下来，从拉数据到全部修正上线用了五周半，第二家公司因为有经验沉淀了，三周内完成。速度取决于组织响应能力和IT配合效率，但推进框架是可以直接复用的。
做了这么多在途库存的排查和修正项目之后，我最深的感触是：在途库存的准确性是一个组织数据成熟度的照妖镜。它能照出你公司的跨部门协作到底有多顺畅、数据治理意识到底在哪个水平、系统设计的时候有没有真正考虑过业务的完整性。
一个在途库存长期不准的公司，往往不只是库存管理有问题。你会发现它的采购执行和财务核算之间存在巨大的信息断层，它的物流管理和仓储管理之间缺乏有效的交接机制，它的管理者在看报表的时候只关注大的金额和数量，却很少有人去问那百分之几的差异到底从何而来。
所以如果你现在正在面对在途库存不准的问题，请不要把它看成一个简单的“系统bug”或者“操作失误”。它是一个管理问题、一个流程问题、一个组织对齐问题。系统修正只是最后一公里的执行动作，真正重要的、真正管用的，是前面那九公里的诊断、共识和机制建设。
修完数据不难，难的是修完三个月之后它没有再乱。这个结果，只有管理动作能给你。
我是公司ERP管理员，今天发现采购在途库存多出了500件，财务催着要调平。我想直接update数据库表里的在途字段，但同事说不能这么干。请问为什么不能直接改？有没有快速修复的方法？
直接修改数据库字段是极其危险的操作，因为这会导致会计分录不平、历史追溯失效、后续MRP计算全面出错。我曾在一个中型制造业工厂吃过这个亏：当时为了省事，直接UPDATE了「采购在途数量」表，结果财务月底对账发现应付账款和库存金额差了几十万，最后花了一周时间用反审核流程才勉强拉回来。
真正正确的做法是：生成「红字采购入库单」或「采购退货单」来冲销虚拟在途，或者使用系统内置的「库存调整单」（如金蝶的红蓝字入库单、SAP的561/562移动类型）。具体操作时，你需要先确认差异来源，如果是供应商发错货但系统已经做了收货，那就走退货流程；
如果是系统重复生成了采购单，则要取消或关闭对应的单据。永远不要绕过业务单据去动底层数据，这是ERP的铁律。对比一下：直接改数据库就像在账本上涂改数字，而走业务单据则留下了完整的审计线索。
我们公司同时用金蝶ERP和第三方WMS，每天都要人工核对在途差异。最头疼的是ERP显示采购在途还有200件没到，但WMS签收记录显示那批货早就入库了。到底哪个系统可信？怎么快速找出这200件的真实状态？
这是一个典型的「跨系统数据接力棒掉地」问题。我服务过的一家跨境电商客户，每月光在途差异对账就要花3天。核心原因是：ERP的「在途」状态是由采购单关闭到收货单生成之间的时间差决定的，而WMS的「在途」是以物理签收回传为准。两者的时间戳逻辑不同。
我的建议做法：第一步，从两个系统分别导出「在途明细表」（ERP按采购单号+物料号，WMS按物流单号+SKU），用Excel的VLOOKUP或Power Query进行左连接匹配。第二步，标记出不匹配的记录，大概率发现两类情况：①WMS已签收但ERP未做收货确认（操作延迟）；
②ERP已关闭采购单但WMS未发货（虚拟在途）。针对第①类，只需在ERP中补做「收货单」；针对第②类，要在ERP中重新打开采购单并做「关闭取消」。为了根治，我推荐建立一个「在途缓冲池表」，每天凌晨定时抽取两个系统的数据，生成差异报告自动推送责任人。
这套方案帮那家客户把对账时间从3天压缩到30分钟，差异准确率提升至99.5%。
我们做快消品的，经常遇到供应商发货后物流走了7天，但系统采购单一直显示在途状态，直到财务做完付款才自动冲销。这期间可用库存虚高，导致重复下单。有没有办法让系统自动识别安全在途时间并提前修正？
你提到的现象本质上是「系统时间窗与物理时间窗不匹配」。我曾在某连锁零售企业设计过一个方案：在ERP中为每个物料设定「标准在途天数」（比如某供应商正常物流7天），然后开发一个「在途预警与自动冲销触发器」。
逻辑是：当采购单创建后超过标准天数+1天仍未收到任何物流确认信息时，系统自动生成一个「暂估在途差异单」，将该笔在途数量从「可用库存」中剥离，放入「待确认在途」虚拟库位。同时，设置「安全在途时间窗口」：比如允许7天内自然流转，超过15天则触发强制冲销（生成红字入库单）。这个机制避免了手动修正的滞后性。
当然，关键前提是你要跟供应商打通物流状态接口，否则只能依赖定期人工核对。实施后，该企业的在途虚高库存率从8%降到了0.5%。对比传统的每月一次人工盘点调整，这种自动化机制将响应速度从周级提升到分钟级，且彻底杜绝了重复下单。
年底盘库，发现仓库里堆了100台某型号扫描仪，但ERP系统里既没有采购在途记录也没有库存账面数。问了一圈说是供应商送的样机，但采购单根本没录入。我该怎么把这一批货正确纳入系统中？直接做盘盈入库会不会导致税务问题？
这是典型的「无单货物」问题，很多企业采用「先盘盈入库，再补单据」的粗放做法，极易引发税务和财务风险。我处理过的最极端案例：某电子工厂仓库发现3000个电容，财务直接做了盘盈入库，结果次月供应商拿着采购合同来对账，才发现是采购单被误删但实物已到，导致应付账款虚增。
正确流程应该是：第一步，先确定货物归属，是供应商多发的（需要补采购单）、是其他仓库调拨漏单的（补调拨单）、还是赠品样机（走「赠品入库单」）。第二步，根据来源选择对应单据类型：如果是供应商多发货，优先联系供应商退回或补开采购订单；如果是内部调拨漏单，补调拨入库单；
只有确定是「无主资产」且公司决定接收时，才使用「盘盈入库」（但需要财务和老板签批，且涉及所得税调增）。具体操作到系统层面：在库存管理模块中找到「其他入库单」或「盘盈单」，录入物料、数量、库位，备注清楚来源依据。同时，财务需要做「待处理财产损溢」科目过渡，不可直接冲减成本。
对比一下：走盘盈入库最快但风险最高；补采购单最合规但需要供应商配合。我的建议是：对于金额超过5000元的无单货物，一定要找到原始单据来源再入账，否则审计时会被认定为虚增库存。
读者评论
作为供应链总监，这篇文章戳到了最痛的点，“状态管理断层”。我们公司之前也是各个部门各自为政，采购以为下单就完事，仓库觉得没收货不关己，结果每次盘点都在途库存对不上。后来我们强制指定了供应链部门作为在途数据的单一责任主体，每周一开跨部门在途清理会，才把差异率从12%降到2%。文章里那个“帕累托图”的数据很实在，分批到货未关行确实是大头，强烈建议同行先拿这个框架做一轮自查。
财务视角来看，文章里提到的“财务对账未关在途”太真实了。我们月结时经常发现应付账款和库存系统打架，根源就是对账逻辑脱节，财务认供应商账单，库存系统还在途挂着。去年按作者的思路，把财务对账后的状态联动写入了ERP冲销规则，再配上L1/L2/L3分级处理，现在每月底差异清理只需要半天。尤其认同“大额差异必须留审计证据链”这句话，不然审计问起来根本说不清。
作为IT负责人，这篇文章对技术路径的对比非常实用。之前业务部门一发现差异就让我后台跑SQL批量修，我每次都提心吊胆。后来参考了“缓冲池机制”的思路，在ERP和TMS之间加了一层中间表，所有在途先进入缓冲池，等物流签收回传再自动冲销。虽然开发花了两周，但上线后异常在途减少了80%，再也不用频繁手工调数据了。强烈建议有频繁在途差异的公司优先考虑这个架构优化。