去年冬天，我帮一个做家居收纳类目的卖家复盘一次不太愉快的经历：他们有一批价值约 37 万元人民币的补货，从宁波出、走海外仓，货已经上架卖了两个多月。问题出在季度对账时，财务发现 ERP 里这批货的采购入库金额是 31.6 万，供应商开的发票是 34.2 万，而报关单上的申报价值又是另一个数。三份数字，三个口径。财务问采购，采购说"按实际付款记的"；采购问运营，运营说"系统里就这么多"；
运营问货代，货代说"当时按你们给的表报的"。最后谁都没错，但这批货的完整链路，他们花了将近三周才拼回来。
这件事让我确认了一个判断：采购补货环节的合规风险，绝大多数不是"做错了什么"，而是"说不清做过什么"。ERP 在这里承担的从来不是"帮你合规"的角色，而是"让你在需要解释的时候，能拿出成体系的证据"。
这篇内容不打算重复"跨境电商要重视合规"这类正确的废话。我想把采购补货这条链路拆开，从供应商准入、下单、付款、头程清关、入库、调拨、补货到退货处置，逐段讲清楚：坑在哪里、为什么是坑、ERP 里该建什么字段和审批、被追问时拿什么自证。中间会用一个我实际接触过的跨境 ERP 工具"数跨境"（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;
_plan=est&utm;_unit=gys）作为落地样本，说明数据模型该怎么搭。
很多卖家对合规的理解停留在两个动作上：注册 VAT、找个报关行。这两件事都重要，但都属于"入场券"级别，真正决定你在被税局、海关、平台或支付机构追问时能不能过关的，是采购补货这条链路上的数据一致性。
我见过太多卖家在上 ERP 之前抱有一个预期："上了系统，数据就规范了，合规问题就解决了。"这个预期本身是错的。ERP 能做的是记录、校验、审批、追溯；它不能替你做税务判断、不能替你确定 HS 编码、不能替你决定一笔关联交易是否合理。
系统解决的是"信息是否完整、是否可追溯"，人解决的是"信息是否真实、是否合理"。把这两件事混为一谈，是最常见的认知错位。一个配置再完善的 ERP，如果采购员录入的供应商主体从一开始就是错的，这套系统只能更高效地帮你留下一套错误的证据链。
我把采购补货的合规判断压缩成三条底线，你可以直接拿去对照自己的流程。
这三条听起来抽象，但落到实操上非常具体。比如"可匹配"，不是要求四个数字完全相等，而是要求差异有据。运费、关税、汇兑损益本来就会造成差异，问题不在于有差异，而在于差异无法归因。
我在做流程梳理时习惯先画一张责任边界表，避免团队把该人做的事推给系统。
| 环节 | ERP 应承担 | ERP 不能替代 |
|---|---|---|
| 供应商准入 | 记录主体信息、证件有效期、审批留痕、到期提醒 | 核实受益人真实性、制裁名单筛查的法律判断 |
| 商品档案 | 保存 HS 编码、原产地、认证文件、适用市场 | 编码归类准确性的最终责任、认证有效性判断 |
| 采购执行 | 订单与发票匹配、审批流、多币种与汇率记录 | 关联交易定价是否公允的税务判断 |
| 头程与清关 | 关联报关单号、申报要素、批次 | 申报价值是否合规的法律责任 |
| 库存与调拨 | 批次追踪、调拨单据、盘点差异记录 | 跨境调拨的税务定性 |
这张表的价值在于：它把"系统责任"和"专业责任"分开。团队不会因为上了系统就误以为自己已经安全，也不会因为系统做不到就放弃留痕。
抽象讲合规很难记住，讲时刻就容易记。我把采购补货链路里风险集中爆发的四个时间点列出来，你可以对照自己团队最近三个月有没有发生过。
这个坑极常见，尤其在产业带集中采购的场景。谈的时候是 A 工厂，签合同的时候对方说"我们走 B 公司开票"，付款的时候又给了一个 C 公司的账户，最后报关单上写的是 A 工厂的中文名。
平时没事，一旦被追问"这批货到底向谁采购的、钱付给了谁、发票谁开的"，你就会发现法律主体、票据主体、资金主体三张皮。这种情况在关联交易审查、出口退税核查、以及平台供应链审核里都很难解释。
我在一个做户外用品的卖家那里见过更麻烦的版本：他们连续两年向同一个"供应商"采购，付款走的却是三家不同的公司，理由是"老板是同一个，走哪个公司方便走哪个"。等到要做融资尽调时，这份采购历史基本无法被第三方采信。
采购在 ERP 里建的商品叫"收纳盒 B 款大号"，报关单上写的是"塑料制品"，货代拿到的是运营给的一份 Excel，上面写的是"Storage Box"。三份资料，三个描述层级。
这个问题在查验率上升的时候会集中暴露。清关资料和商品主数据脱节，本质上是商品档案没有成为唯一数据源。如果 HS 编码、中英文品名、材质、用途、原产地在 ERP 的商品档案里只是一次性填的备注，而不是一个受管控的字段，那它一定会漂移。
补货不是一批一批清清楚楚进来的。现实是：一批货可能分两个柜走，一个柜又混了三批采购单，到了海外仓再拆成多个 FBA 货件。如果没有批次概念，等到某批货出现质量问题时，你根本不知道问题货来自哪一次采购、哪一张报关单。
反过来，当平台或监管方要求你说明"某个时间段的某类商品从哪来"时，批次就是唯一能把库存和采购、清关串起来的线。没有批次追踪的库存数据，只是一堆数量，不是证据。
这是我开头那个 37 万案例的本质。他们的 ERP 记录很完整，采购单、入库单、付款单都有，数量也对得上。但每一张单据都是"结果"，没有"依据"：价格为什么是这个价？发票为什么比订单高？这笔差价是什么费用？谁来批的？
外部专业人士或监管方看你的数据，看的是逻辑闭环，不是数据条数。一条没有依据字段的数据，和一个空格在审查意义上差别不大。
下面这六条，每一条我都见过真实代价。我不打算写得温和，因为它们确实会让人付出代价。
VAT 是税务登记，不是业务合规证明。很多卖家在欧盟注册了 VAT，就觉得"我这块合规了"，但采购补货环节的四流一致性和 VAT 注册完全是两件事。税务机关看的不只是你有没有注册，而是你的申报数据能不能和你的业务数据对上。
库存数据、销售额、进口记录三者之间的逻辑关系，才是审查的重点。注册 VAT 只是让你有资格申报，不解决申报数据能不能自洽。
"双清包税"在实操中意味着物流商替你完成出口报关和进口清关，并且把税负打包成一个价格。听起来很方便，但你需要问自己一个问题：报关单上的申报主体是谁？
如果申报主体不是你，那这批货在法律意义上的进口记录就不在你名下，你在目的国的库存来源就缺少合法链条；如果申报价值被压低，风险最终落在货权方身上。我不建议在这里下绝对结论，因为不同市场、不同品类、不同时期的处理方式差异很大，但至少要向服务商问清楚：申报主体、申报价值、单据是否给你、你能否拿到完整的进口凭证。拿不到，就要评估这中间的风险敞口。
我前面说过，这里再说一遍，因为它值得重复。ERP 是容器，不是判官。系统能把你的流程固化下来，但固化的可能是一套错误的流程。我看到过配置很完整的系统，供应商主数据里存着一堆已经注销的公司，只是因为没人设置有效期提醒。
发票齐只是票据流的一环。业务流（为什么买）、资金流（钱付给谁）、库存物流流（货怎么来的）如果对不上，发票再齐也只是孤证。
我在一个做宠物用品的卖家那里见过：发票一张不缺，但同一批货的采购订单被拆成了三张，分别对应三个不同的采购申请人，而这三个人属于同一个部门、同一个审批人。这种"形式合规、内控失效"的组合，在舞弊审查和税务审查里都很敏感。
大部分卖家的补货公式是：日均销量 × 备货周期 + 安全库存 − 在途库存。这个公式没错，但它漏掉了三个变量：清关时效波动、认证周期、以及合规成本对毛利的影响。
举个具体场景：某个品类在旺季前需要一项额外的合规认证，认证周期 6 周。如果你的补货模型只看物流时效，就会在旺季前刚好卡在认证没下来的时间点，货到了却不能上架。这不是物流问题，是把合规周期排除在补货模型之外的必然结果。
盘点差异、调拨差异、退货损耗，很多团队的处理方式是直接在系统里做一笔调整单，把它"调平"。账是平了，但差异的原因被抹掉了。
问题是：差异原因一旦被抹掉，就无法重建。等到需要解释"为什么这个 SKU 的库存变动和申报数据不一致"时，你手上只剩下一个结果数字，没有过程记录。我的建议是，任何超过设定阈值的调整，都要强制填写原因字段并附上依据文件，哪怕只是一句说明加一张截图。
"四流一致"这个词被讲烂了，但大多数讲法停在概念层。我把它拆成 ERP 里能落地的字段和单据，你才能判断自己的系统够不够用。
业务流要回答的是"为什么买"。这条链路上容易被忽略的是需求来源。补货需求是人工提的、系统按补货点自动生成的、还是运营为了冲活动临时加的？这三种来源的审批逻辑完全不同。
我建议在采购订单上至少保留这几个字段：需求来源、关联的补货计划编号、申请人、审批人、审批时间、预计到仓时间。这些字段平时没用，出问题时能快速定位责任和时间线。
票据流的关键不是"有没有发票"，而是"发票和订单能否对上，差异有没有说明"。我习惯在系统里设置三档匹配容差：数量差在 2% 以内的自动通过；2% 到 5% 的需人工确认并填写原因；超过 5% 的必须走审批。
金额维度同理，但要额外处理一类情况：运费、关税、保险等附加费用是含在发票里还是单独开票。这两种处理方式对成本核算和后续申报的影响不同，必须在系统里有明确区分，不能靠人工记忆。
资金流最容易出问题的地方是主体一致性。合同主体、开票主体、收款主体三者不一致时，必须有一份书面的说明文件挂在付款单据上。这不是形式主义，而是你在半年后被问起时唯一能拿出来的东西。
多币种场景还要处理汇率问题。我的做法是记录三个汇率：下单日汇率、付款日汇率、以及实际结算汇率，并在系统里保留汇兑差异的计算结果。差异本身不是问题，无法解释差异才是。
这是四条流里最弱的一环，因为大部分 ERP 的采购模块和物流模块是割裂的。采购看到的是采购单，物流看到的是货件，两者之间没有强关联。
我建议的做法是引入"批次"作为桥梁：一次采购单可以对应多个批次，一个批次可以对应多个货件，一个货件可以拆到多个仓库。批次是唯一能让你在事后把库存和采购、清关串起来的结构。
把上面四条流映射成可检查的对照关系，会更实用。
| 检查点 | 应匹配的两端 | 常见差异 | 处理方式 |
|---|---|---|---|
| 主体一致性 | 合同主体 ↔ 开票主体 ↔ 收款主体 | 同一集团不同公司 | 附书面说明并留档 |
| 数量一致性 | 采购订单 ↔ 入库数量 ↔ 报关数量 | 运输损耗、拆柜 | 设定容差阈值 + 原因字段 |
| 金额一致性 | 订单金额 ↔ 发票金额 ↔ 付款金额 | 运费、关税、汇兑差 | 费用分摊规则前置定义 |
| 时间一致性 | 下单日 ↔ 付款日 ↔ 报关日 ↔ 入库日 | 预付、月结、清关延迟 | 保留计划日与实际日两个字段 |
| 商品一致性 | 商品档案 ↔ 报关品名 ↔ 平台 Listing | 中英文描述层级不同 | 商品档案作为唯一数据源 |
讲完逻辑，我用一个具体工具做落地演示。我接触过不少跨境 ERP，选数跨境来举例的原因是它的数据模型比较适合做证据链，不是因为它功能最多，而是因为它的主数据和单据结构相对清晰，方便讲清"字段该建在哪一层"。（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）
需要先说明：下面的配置思路是通用的，任何一个结构完整的跨境 ERP 都可以参考，不作为选型唯一标准。真正重要的是思路，不是品牌。
卖家选 ERP 时最容易犯的错，是对着功能清单打勾。功能清单回答的是"能不能做"，数据模型回答的是"做得对不对"。一个没有批次概念的 ERP，哪怕有 200 个功能，也帮不了你处理调拨追溯。
我的判断顺序是：主数据层（供应商、商品、仓库）→ 单据层（采购、入库、调拨、退货）→ 关联层（批次、货件、单据号）→ 控制层（审批、权限、日志）→ 报表层。前四层不成立，报表层做出来也只是一堆好看的数字。
供应商主数据要存的不只是名称和联系方式，还包括：注册主体全称、注册号、所在地区、收款账户主体、证件扫描件、证件有效期、结算币种与账期。其中证件有效期是必须做提醒的字段，因为最常见的合规漏洞不是没有资料，而是资料过期了没人更新。
商品主数据要存：中英文品名、HS 编码及版本日期、原产地、材质与用途、适用市场、所需认证及有效期、是否含电池或液体等特殊属性。这些字段一旦成为唯一数据源，运营、采购、物流、报关都用同一套描述，口径漂移的概率会大幅下降。
采购订单上应该关联的东西，我整理成一个字段清单，你可以直接拿去对照自己的系统配置。
采购订单（PO）字段配置示例
─────────────────────────────
基础信息
po_no 采购单号（唯一）
supplier_id 供应商ID（外键，指向主数据）
contract_entity 合同主体全称
payee_entity 收款主体全称
currency 结算币种
fx_rate_ordered 下单日汇率
商品明细
sku_id SKU ID（外键，指向商品主数据）
hs_code HS编码（取自商品档案，不可手填）
origin_country 原产地
qty_ordered 订购数量
unit_price 单价
qty_tolerance 数量容差（%）
费用拆分
freight_cost 运费（单独字段，不并入单价）
duty_cost 关税预估
insurance_cost 保险
other_cost 其他附加费用
关联与留痕
batch_id 批次号
shipment_ids 关联货件号（可多个）
customs_decl_no 报关单号
demand_source 需求来源（计划补货/人工/活动）
approval_flow 审批流实例号
attachments 附件（合同、发票、说明、付款水单）
这份清单里，我认为最关键的是三个字段：hs_code 不可手填、freight_cost 独立于单价、batch_id 必须生成。第一个防止口径漂移，第二个防止成本核算混乱，第三个让事后追溯成为可能。
多币种是跨境采购绕不开的。我的处理原则是：以本币记账，但保留原币金额和两个汇率。汇兑差异单独记录，不并入采购成本，避免后续成本分析被汇率波动污染。
这里有个容易忽略的细节：如果一批货分三次付款，每次付款汇率不同，那这笔采购的实际成本应该按加权平均计算，而不是按第一次付款的汇率。系统如果只存一个汇率字段，这个计算就做不了。
补货链路的后半段最容易被系统忽略。跨境调拨、换标、退货、翻新、销毁，这些动作在业务上真实发生，但在系统里往往没有对应单据。
内控上有一条基本原则：提出采购的人、审批采购的人、执行付款的人，不应该集中在同一个人身上。我见过规模不大但风险很高的团队，一个人从询价到付款全包，理由是"效率高"。
ERP 里至少要能做到三件事：按金额分级审批、按角色限制字段可见性、以及记录每一次关键操作的日志（谁、什么时候、改了什么、改前改后）。第三点尤其重要，因为在争议场景下，"谁改的这个数字"往往比"这个数字是多少"更关键。
前面讲的都是通用逻辑，但不同阶段的卖家，优先级完全不同。硬套一套方案，要么浪费钱，要么抓不住重点。
这个阶段的卖家不必上重型 ERP，但有三件事必须从第一天就做对。
这个阶段最大的风险是"先跑起来再说"。业务早期确实要快，但这三件事的成本极低，补起来的成本却极高。
到这个阶段，Excel 就不够了。你需要的是把采购、库存、物流打通，而不是各管一段。
这个阶段是"系统化收益最高"的阶段：业务复杂度已经超过人工处理能力的上限，而组织规模还没有到需要多层审批的程度。
这一阶段的重点从"效率"转向"可解释性"。多主体意味着关联交易，关联交易意味着定价合理性、单据一致性、以及跨境资金流的合规问题都会成为审查重点。
我建议这个阶段做三件事：第一，建立集团层面的主体关系图谱，明确每个主体的职能和交易类型；第二，所有关联交易都有书面定价依据；第三，系统里能按主体维度出具完整的采购与库存报表。
如果已经发生过这类情况，优先级要倒过来。先做数据重建，再做流程优化。
顺序很重要。很多团队一被问就先去改流程，结果历史数据还是拼不起来，再次被问时依然被动。
合规从来不是"越多越好"。它是一个成本与风险之间的平衡，关键是要清楚自己在拿什么换什么。
增加审批节点一定会牺牲速度。在补货节奏紧张的旺季，多两级审批可能意味着错过一个销售窗口。
我的建议是按金额和风险分层。低金额、常规品类的采购走快速通道，只在事后抽查；高金额、新品、新供应商、特殊品类的采购走完整审批。把所有采购都塞进同一套审批，是最容易导致流程被绕过的做法。因为业务等不起，就会想办法绕开系统。
不是所有环节都值得系统化。比如供应商的制裁名单筛查，早期用人工加外部工具查是可行的；但当供应商数量超过一定规模后，人工就不可靠了。
判断标准是"出错后的后果严重程度 × 出错频率"。后果严重且频率高的环节必须系统化；后果严重但频率极低的，可以人工加清单；后果不严重且频率高的，可以考虑简化处理。
多主体架构在税务规划上有其价值，但代价是管理复杂度成倍上升。每增加一个主体，就多一套单据流、多一条资金流、多一层关联交易需要解释。
| 架构选择 | 优势 | 代价 | 适用情形 |
|---|---|---|---|
| 单一主体 | 单据简单、资金流清晰、管理成本低 | 税务与风险隔离能力弱 | 规模较小、市场集中 |
| 双主体（境内外各一） | 兼顾资金通道与业务隔离 | 需要维护关联交易文档 | 成长期、有跨境资金需求 |
| 多主体矩阵 | 税务与风险隔离能力强 | 单据流、定价依据、报表维度复杂度高 | 成熟期、多市场多品类 |
铺货型卖家追求 SKU 数量，合规深度必然受限；精品型卖家 SKU 少，可以做深。这两条路没有对错，但要清楚代价。
铺货模式的合规风险集中在两点：一是商品档案粗放导致申报口径不一致，二是 SKU 太多导致认证管理失控。铺货模式不是不能合规，而是必须用更强的系统约束来弥补人工精力的不足。
精品模式的代价是单 SKU 的合规投入更高，但好处是每个 SKU 的合规档案可以做得很扎实，抗审查能力强。
如果你只想要一个可执行的东西，用下面这 10 个问题过一遍。任何一个答"不确定"，就是需要优先处理的地方。
这 10 个问题看起来简单，但我在实际陪卖家过一遍的时候，能全部答"是"的团队不到三分之一。而答"不确定"最多的，通常集中在第 4、6、8 三条，也就是申报口径、费用拆分和库存处置这三块。
写到这里，我想回到开头那个 37 万的案例。他们最后并没有被处罚，因为问题本身并不严重，只是数字口径不一致。但他们花掉的三周时间和由此产生的不信任，成本远高于那笔差额。
我对采购补货合规的理解，一句话概括：不是让你的流程变得更复杂，而是让每一批货在需要的时候都能自己说话。单据编号、批次、字段、审批、日志，这些东西的价值不在于平时，而在于出事的那一天。
也有一个反常识的判断我想留给你：合规做得好的团队，日常反而更省事。因为补货决策有数据支撑，对账不用反复确认，异常一出现就能定位。合规成本和运营效率并非此消彼长，在链路设计合理的前提下，两者是同向的。
如果你现在要做一件事，我建议从第 8 节的 10 个问题开始。挑最近一批补货，按 10 个问题过一遍，把答"不确定"的记下来。这比看任何一份 ERP 功能清单都更有用。
等你把缺口摸清楚了，再决定要不要上系统、上到什么程度。这个顺序不能反，先知道自己缺什么，再去选工具。如果你需要一份更结构化的参考，可以从数跨境的公开资料看它的数据模型和单据结构（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys），重点看它的供应商主数据、商品档案、批次与单据关联这几块怎么设计，然后拿去和自己现在的做法对照，对照本身，就是最有价值的一步。
最后提醒一句：本文涉及的政策、税率、认证要求和平台规则都会变化，任何具体判断都应结合你所在市场的最新官方口径和专业人士意见。文章提供的是流程框架和自查方法，不构成税务、法律或报关建议。
我之前一直以为合规就是注册好VAT、报关的时候别报错就行，直到去年被税局追问过一批货的资金去向，才发现光有报关单根本说不清楚。身边也有同行被平台查过库存和申报数据对不上，搞得我有点慌，但一直没搞明白到底要'对'哪些东西。
四流指的是业务流、票据流、资金流、库存/物流流。业务流是采购订单、合同、验收记录，证明这笔生意真实发生；票据流是供应商发票、报关单、物流单据，证明货和钱有凭证；资金流是付款申请、银行流水、外汇记录，证明钱确实付给了合同主体；
库存/物流流是入库单、调拨单、盘点记录、尾程派送单，证明货真的到了该到的地方。判断合规不看单点，而是看这四条线能不能互相解释：一笔采购订单能不能对应到一张发票、一笔付款、一批入库。ERP的作用就是把这些字段和单据串起来，让每一批货都能被追溯，但它记录的是事实，不替代你对税务和关务的专业判断。
我以前选供应商基本就是看价格和交期，谁便宜、谁发货快就用谁，合同也是随便签个模板。后来听说有卖家因为供应商在制裁名单上被银行冻结了货款，还有因为发票主体和合同主体不一致导致无法抵扣，我才意识到前端没做好，后面全是坑。
供应商准入最容易踩的坑有三个：一是没做KYC/KYB，不知道对方实际控制人和受益人是谁，可能踩到制裁名单或黑名单；二是合同主体、发票主体、收款主体三者不一致，导致付款和抵扣出问题；三是资质文件过期或缺失，比如出口资质、认证文件。
ERP里建议把供应商主数据建全：营业执照、受益人信息、制裁/黑名单筛查记录、合同扫描件、资质文件及有效期、收款账户信息、贸易条款。同时设置准入审批流，新供应商必须走完审核才能下单，资质到期前自动提醒更新。这些字段不是为了好看，而是出事时你能拿出来证明自己尽到了审查义务。
我们补货一直是用销量预测加安全库存那套公式，觉得算得挺准的。但去年有几批货因为认证没办下来卡在海关，还有因为清关慢导致断货，损失比多备货的库存成本还高。我就想知道，补货模型里到底要不要把这些合规相关的周期和成本也算进去。
只算销量和安全库存不够，补货模型至少要加入三类合规变量。第一是交期变量：清关时效、认证办理周期、头程运输波动，这些会直接拉长你的实际到货时间，安全库存要覆盖的是这个'合规交期'而不是工厂发货到入库的理想时间。
第二是成本变量：关税、增值税、认证费用、可能的查验和滞港费用，要摊进单件成本，否则你算的毛利是虚的。第三是资金变量：预付比例、账期、汇率波动会占用现金流，补货节奏要和资金安排匹配。
具体公式因企业而异，没有标准答案，但判断依据是：如果一个补货决策没考虑清关和认证周期，它大概率会在某个环节断货或被成本反噬。
我们同时做亚马逊、独立站和TikTok Shop，货在FBA和海外仓之间调来调去，还有退货换标重新上架的情况。平时觉得这些都是常规操作，但真要被税务或平台问起来，我发现很多调拨和换标根本没有完整单据，库存数据和申报数据也对不上，心里很没底。
这类场景的核心是批次追踪和单据闭环。第一，调拨要有调拨单，记录从哪个仓到哪个仓、数量、时间、批次号，FBA和海外仓之间的移动也要有对应记录。第二，退货换标要有退货单、质检记录、换标操作记录，如果涉及翻新或销毁，要有翻新记录或销毁凭证，证明这批货的最终去向。
第三，库存数据要和申报数据能对上，差异要能解释，比如在途、待检、已销毁分别对应什么状态。ERP里建议启用批次或序列号管理，所有调拨、退货、换标、销毁动作都挂上附件和操作日志，权限分离，谁操作谁负责。这样被追问时，你能拿出从入库到最终处置的完整链条，而不是一句'大概是这么走的'。
读者评论
我们去年也遇到过类似情况，采购单、发票、付款金额三边对不上，财务查了半个月。文章说的'可解释性'很到位，但小卖家真要做到批次追踪和四单匹配，人力成本不低，得看规模。
双清包税那段提醒了我。之前只关心价格和时效，从没问过报关单申报主体是谁、单据能不能给我们。看完去翻了旧记录，果然拿不到完整进口凭证，这个风险敞口确实存在。
批次追踪这个点太真实了。我们海外仓经常拆柜换标，系统里只有数量没有批次，上次一批货出质量问题，根本查不到是哪张采购单进的，只能整批处理，损失不小。
文章对ERP的定位说得比较客观，它是证据容器不是合规护身符。但落地时最大的阻力还是人，采购嫌填字段麻烦，运营只管销量，最后系统配置再好也白搭。