2023 年旺季前两周，我帮一个做家居收纳的卖家做账号体检。他找我的原因很直接：主打链接突然被下架，后台提示”商品信息不一致，需要提供有效 GTIN 证明”。他第一时间怀疑是竞品恶搞，我让他把过去两年的 UPC 台账调出来，结果问题根本不在竞品身上，他累计用了 1.1 万个 UPC 码，其中约 3400 个在后台处于”已绑定、商品已删除”的悬空状态，另有 600 多个码同时挂在两个不同店铺、两个不同 SKU 上。
这两个数字放在一起，就是一份现成的”账号风险自白书”。
UPC 这件事，绝大多数卖家把它当成人人都能填的一格表单。填进去，后台不报错，就当它落地了。但真正决定账号安全的，从来不是那 12 位数字本身，而是编码、商品、店铺账号这三者之间的绑定关系能不能被自证。编码错了，改一下就行；绑定关系乱了，平台审你的时候你连自己都解释不清楚。
这篇文章不讲 UPC 是什么，那个百度百科比我写得好。我讲的是我实际做过的事：怎么把 UPC 从一个”填表动作”变成一套可追溯的落地流程，以及在这套流程里，哪几个环节一旦出事就会直接牵连账号安全。文中数据来自我 2022 至 2024 年接触的 60 多个跨境店铺账号的诊断记录，经过脱敏和区间化处理，属于经验样本，不是行业统计口径，请按这个前提阅读。
如果你只记一句话，记这句：UPC 落地的成功标准不是”上架成功”，而是”任何时间点都能用一套材料证明这个码属于这个商品、这个商品属于这个店铺”。前者是操作标准，后者是合规标准。平台给账号做审查时，用的是后者。
我把 UPC 相关的问题分成两类。第一类是编码本身有问题，比如校验位算错、格式不符、码段被占用，这类问题通常在上传阶段就会被系统挡下来，处理起来很快。
第二类是编码合法但绑定关系混乱，比如同一个码给了两个 SKU、码的归属方和商品的实际品牌方对不上、码是从第三方批量买来但拿不出授权链路。这类问题上传阶段不报错，往往在半年甚至一年后，在账号审查、品牌备案复核、恶意跟卖申诉的时候集中爆发。
我统计过手上的样本：触发账号层面审查的 UPC 问题里，约八成属于第二类。也就是说，绝大多数人不会栽在”不会算校验位”上，而会栽在”不知道自己那个码到底是谁的、给过谁”。
有个判断我反复跟卖家讲：平台的审核逻辑不是”证明你有罪”，而是”要求你自证”。它给你 72 小时，要你提供 GS1 证书、品牌授权、采购发票、商品与编码的对应关系。你能不能在这 72 小时内交出一套自洽的材料，直接决定结果是”警告”还是”冻结”。
我见过两个卖家遇到几乎一模一样的下架通知。A 卖家两小时内交出了编码台账：UPC 码、GS1 证书编号、品牌授权文件、对应 ASIN、上架时间，一条线拉下来，第二天恢复。B 卖家翻了两天 Excel，交出去的表格里有两个码找不到归属，最后账户被审查了 21 天，旺季彻底错过。
差别不在于谁更冤，在于谁能自证。
很多人的操作顺序是反的：先在店铺后台上架，上架时随手填一个码，卖起来之后再回头补台账。这个顺序在单店铺、单 SKU 阶段看不出问题，一旦到了多店铺、多 SKU、多平台，就是在给自己埋雷。
我坚持的顺序是三步：先把码的所有权和状态确定下来，再把码和商品做一对一锁定，最后才把商品分配到具体店铺。这个顺序的核心价值是让每一层都有独立的校验依据，任何一层出问题都能被及时发现，而不是等到最后一起爆炸。
这个数字是我的经验值，不是实验室结论。我跟踪过几个卖家用纯人工方式管理编码，在前 100 到 200 个 SKU 范围内，人工查重的准确率还能维持在 95% 以上；超过 200 个 SKU，尤其是同时有多个店铺、多人协作的时候，漏检率会明显上升。
原因不复杂：人工查重依赖”我记得”，而人的短期记忆容量有限，跨表格、跨人员、跨时间的比对几乎必然出错。所以我的建议很直接，SKU 数超过 200、或者店铺数超过 2 个，就必须上系统化的台账管理，靠人盯是盯不住的。
要理解这件事，得先分清几个经常被混用的编码概念。很多卖家跟我说”UPC 不就是条码吗”，然后在实际操作中把 UPC、EAN、GTIN 当成同一个东西来用，这一步就埋下了后面的混乱。
UPC-A 是北美体系，12 位数字；EAN-13 是欧洲体系，13 位数字；GTIN 是一个统称，涵盖 GTIN-8、GTIN-12、GTIN-13、GTIN-14 四种长度。亚马逊后台要的”GTIN”通常接受 UPC 或 EAN，但不同站点、不同类目对长度和前缀的要求并不完全一致。
更关键的是数字系统字符这一位。UPC-A 的第一位是有含义的：0、1、6、7、8 用于常规商品，2 表示随机重量商品，3 表示药品，4 表示店内码，5 表示优惠券。我见过有卖家从第三方买了一批量以 2 开头的码，用在普通家居品上，上传时不报错，等平台做类目核对时被判定为”编码与商品属性不匹配”。
| 编码类型 | 位数 | 主要使用区域 | 首位含义 | 常见踩坑点 |
|---|---|---|---|---|
| UPC-A | 12 位 | 北美 | 数字系统字符 | 首位为 2/3/4/5 的码用在普通商品上 |
| EAN-13 | 13 位 | 欧洲、亚太 | GS1 国家/地区前缀 | 前缀与销售站点不匹配，被要求补充证明 |
| GTIN-14 | 14 位 | 箱规、批发 | 包装指示符 + 13 位编码 | 把箱码当单品码上传，导致父子体关系错乱 |
| GTIN 豁免 | 无码 | 品牌备案卖家自有品牌 | 不适用 | 豁免后仍上传第三方 UPC，造成权属冲突 |
我一般建议卖家把这张表打印出来贴在运营工位上。编码类型选错不是技术问题，是权属问题，因为不同类型背后对应的是不同的授权链路和不同的证明文件。
铺货型卖家的典型操作是：一次采购几千个 UPC，做成 Excel，用批量上传表格把商品铺出去。这个模式在早期效率极高，问题出在两个地方。
第一，采购来的码往往没有独立的权属凭证。卖家手上的”凭证”通常是一封邮件或者一张订单截图，平台审查时不认。第二，批量表格里的码和 SKU 是一一对应的，但一旦某个 SKU 被删除、被合并、被迁移到另一个店铺，这个对应关系就断了，而 Excel 不会自动更新。
我诊断过一个铺货卖家，他的表格里同一个 UPC 出现在三行，分别对应三个 SKU。问他是故意的还是手误，他说不知道，因为表格是三个人先后维护的。多人协作 + Excel 手工维护，几乎必然产生重复绑定。
精品卖家的问题不一样。他们通常用品牌方提供的 GS1 编码，或者走 GTIN 豁免，编码本身的合规性没问题。风险在于授权变更时的编码交接。
我遇到过一家做小家电的，原先的品牌授权在 A 公司名下，后来业务调整，商品转到 B 公司名下继续卖，但 UPC 码还是原来那批。平台在做品牌与编码归属核验时，发现编码的 GS1 注册主体和商品的品牌备案主体不一致，触发了商品真实性审核。他们花了两周时间补交材料才恢复。
这个坑的特点是：业务上完全合理，合规上却是断链的。换主体时，编码要么一起迁移并留下正式文件，要么重新申请，不能”沿用着卖”。Windows 系统
这是我在样本里见到的最普遍、也最危险的做法。卖家开了两三个店铺，卖的是同一批货，为了省成本，直接用同一批 UPC 上架。
短期看没问题，因为码是合法的、商品也是真的。但从平台视角看，同一个 GTIN 出现在不同店铺的不同账号下，是典型的关联信号。一旦其中一个店铺因为任何原因被审查，另外几个店铺会被顺带排查。
我手上有个案例：一个卖家三个店铺共用 400 多个 UPC，其中一个店铺因为侵权投诉被暂停，三天内另外两个店铺先后收到”账户信息核验”通知。共用 UPC 等于给自己装了一根看不见的引线，平时不显形，出事时一起烧。
品牌备案通过后，卖家可以申请 GTIN 豁免，不再需要 UPC。很多人在这一步会犯两个错：一是豁免通过后，之前上传的第三方 UPC 没有清理，新旧并存；二是豁免后新上架的商品用了豁免，但老商品还在用买来的码，后台数据里同品牌下存在两种编码来源。
我建议的处理方式是：品牌备案生效后，做一次全量编码盘点，把历史遗留的第三方码标记出来，能替换的替换，不能替换的至少要在台账里标注来源和授权情况，确保随时可解释。
Excel 能撑到 200 个 SKU，再往上就不行了。我现在给客户搭编码台账，会用专门的跨境商品与编码管理工具，比如数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys），把 UPC 码、商品、店铺账号放在同一套数据结构里做关联，而不是靠三张表互相 vlookup。
核心差别在于关系的单向绑定和冲突检测。一个 UPC 只能绑一个 SKU，一个 SKU 只能绑一个 UPC，任何一端出现第二次绑定，系统会直接报冲突。这件事 Excel 做不了，因为它没有”唯一性约束”这个概念。
我通常用它做三件事：一是编码入库时做批量查重和校验位验证；二是商品上架前生成绑定关系清单，作为审核时的自证材料；三是每次店铺调整、SKU 变更后留一次变更记录，形成时间线。第三条尤其重要，因为平台审查时问的往往是”这个变更是什么时候发生的、为什么发生”。
下面这六条，是我在诊断过程中反复听到的说法。它们有一个共同特征：在某个阶段是对的，但被过度推广之后就成了风险源。
说这话的卖家，通常只经历过”填了就能上”的阶段。上架确实需要它，但它同时还是权属凭证、品牌关联线索和店铺审核的比对依据。
我一般会反问一句：如果 UPC 只是必填项，为什么平台在你申诉时会要求提供 GS1 证书或者品牌授权？因为这个码在平台的数据库里不是孤立字段，它挂着一串关联信息。把它当表单字段的人，会在需要解释它的那一刻才发现自己解释不了。
第三方批量售卖的 UPC 码，来源通常是已注销公司的剩余码段或者批量转售的码段。短期能上架，长期有三个风险：码段可能在某个时间点被原持有方重新激活或申诉；第三方无法提供平台认可的授权文件；同一批码被卖给多个买家，导致同码出现在不同卖家店铺。
我在样本里观察到，第三方码相关的审核触发，往往集中在上架后 6 到 18 个月这个区间。这个滞后性很要命，因为那时候你已经卖了很久，链接权重很高，一旦被要求下架，损失远超当初省下的那点采购成本。
这是最常见的严重错误。用过的 UPC 在平台数据库里已经和某个 ASIN、某段历史销售记录绑定了。你把它回收给新品，平台看到的是”同一个编码对应了两个不同的商品主体”，直接结果可能是父子体错乱、评价串号，严重时触发商品真实性审核。
我的处理原则很简单：UPC 是一次性资源，绑定过就不再复用。老 SKU 下架，码也一起封存，在台账里标注状态为”已停用”，而不是”可复用”。
后台的校验主要覆盖格式、长度、校验位这些表层规则，它无法校验”这个码是不是真的是你的”。格式合法但权属不清的码，上传时会显示成功。
所以我判断绑定是否成功，看四个条件，而不是看后台提示：码的权属凭证是否齐全、码与 SKU 是否一对一、该码在系统内是否存在其他活跃绑定、变更记录是否完整。四个条件全部满足，才算真正落地。
绩效指标是结果，编码和商品信息的一致性才是底层输入。我做过一个粗略的对照：在出现过账号审查的店铺里，绩效指标本身已经触红线的不到三成，其余七成在事发前的绩效表现是正常的，问题都埋在商品信息层。
这个观察对我的意义是：账号体检如果只看绩效后台，会漏掉大部分真实风险。编码台账应该被纳入定期体检范围，和广告、库存放在同一个层级上看。
有些卖家默认”工具会帮我处理”。工具能做的是一致的规则校验和冲突提示，做不了的是判断这个码的权属是不是真的属于你。
我使用的做法是：系统负责发现冲突和缺失，人工负责解释和补证。系统报出”UPC-XXX 存在两处绑定”之后，接下来要做的判断是，哪个绑定是历史遗留、哪个是当前有效、需不需要向平台主动报备。这部分只能靠人，而且要留下书面判断依据。
前面讲的是问题，这一节讲我实际用的方法。这套方法不复杂，关键是每一层都有独立的判断依据，不依赖任何人的记忆。
编码主表记录的是码本身的属性，一个码一行，不允许重复。字段包括：UPC 码值、编码类型、来源渠道、获取日期、权属凭证编号、当前状态、备注。
状态字段是这张表的核心。我给状态定义五个值：待用、已绑定、已停用、争议中、已废弃。所有码必须有且只有一个状态，没有状态就是台账不合格。争议中这个状态尤其重要，用来标记那些来源存疑、正在和供应方核实归属的码，避免被误用到新品上。
这张表记录码和商品的对应关系，一个 UPC 一行，一个 SKU 也只能出现一次。字段包括：UPC 码值、SKU、商品名称、品牌、类目、绑定日期、绑定人、当前是否有效。
我在这里设了一条硬规则：同一个 UPC 值在主表存在，且在绑定表只有一行有效记录。任何违反这条规则的行，都必须带着解释才能保留。这条规则在 Excel 里只能靠人工核，在具备唯一性约束的工具里是自动拦截的。
这张表记录商品归属哪个店铺、哪个站点。字段包括：SKU、店铺代号、站点、上架日期、下架日期、关联店铺标识。
这张表的作用是暴露跨店共用。我会定期跑一次检查：同一个 UPC 是否出现在两个以上店铺的有效记录里。如果出现，就必须给出商业理由并留下书面说明，否则视为风险项处理。
校验按顺序执行，前一层不过，后一层不做。这个顺序能显著减少无效工作量。
第三和第四层是人工高发错误区。第一、二层完全可以交给代码，这也是为什么我坚持把校验位验证写成脚本跑，而不是靠肉眼。
def calc_check_digit(prefix_11: str) -> int:
"""
计算 UPC-A 的校验位。
prefix_11: 前 11 位数字字符串
规则: 奇数位求和 ×3 + 偶数位求和，取模 10 后补足
"""
if len(prefix_11) != 11 or not prefix_11.isdigit():
raise ValueError("需要 11 位数字")
odd_sum = sum(int(prefix_11[i]) for i in range(0, 11, 2))
even_sum = sum(int(prefix_11[i]) for i in range(1, 11, 2))
total = odd_sum * 3 + even_sum
return (10 – total % 10) % 10
def verify_upc_a(code_12: str) -> bool:
"""验证完整的 12 位 UPC-A 编码"""
if len(code_12) != 12 or not code_12.isdigit():
return False
return int(code_12[-1]) == calc_check_digit(code_12[:11])
if __name__ == "__main__":samples = [
"012345678905",
"036000291452",
"036000291453",
]
for s in samples:
print(s, verify_upc_a(s))
这段脚本我一般建议卖家在采购入库时跑一次。它能拦掉的不是主要风险，但能拦掉那些因为手工录入导致的低级错误，而低级错误往往是最容易被平台判定为”信息不实”的，因为对方看到的是一个根本无法通过校验的编码。
三张表加四个校验是执行层，风险分级是决策层。我按处理优先级把 UPC 问题分成三级。
| 风险等级 | 判定条件 | 典型表现 | 建议处理时限 |
|---|---|---|---|
| 高 | 一码多品且跨店铺；权属凭证完全缺失 | 同码出现在两个以上活跃店铺，或无法提供任何来源文件 | 48 小时内完成隔离与说明 |
| 中 | 一码多品但同店铺；变更记录缺失 | 同一店铺内重复绑定，或关键变更无时间戳 | 两周内完成清理与补录 |
| 低 | 格式类问题、状态字段缺失 | 校验位错误、状态未标注 | 纳入下次例行盘点 |
分级的意义在于，很多卖家一发现问题就全面停摆，结果把正常经营也搭进去。我的经验是高危项立即隔离，中低危项走例行清理，不要因为几个校验位错误就冻结整个店铺的上新节奏。
我给客户定的停机线有两条。第一条，同一 UPC 出现在两个以上活跃店铺，且这两个店铺属于同一主体或存在关联迹象。第二条，收到的审核通知里明确提到 GTIN 或商品真实性问题。
触碰这两条，我的建议是暂停该编码相关商品的上新和广告投放，集中资源做材料准备。继续跑量只会让问题变复杂，因为每多一笔订单就多一条需要解释的交易记录。
这一节讲一个完整案例。卖家做宠物用品，两个店铺，合计 3800 个 SKU，历史采购过 5200 个 UPC，其中约 1400 个来自第三方批量采购。他找我的起因是其中一个店铺收到了商品真实性核验通知。
我们花了三天做全量导出，把两个店铺的在售、停售、已删除商品的编码全部拉出来，和采购记录做交叉比对。结果如下：活跃绑定的码 3100 个，其中 380 个对应的是已删除商品；有 96 个码在两个店铺同时存在有效绑定；有 512 个码完全找不到采购来源记录。
这 512 个无来源码是最危险的。我们逐个回溯，最后确认其中 431 个来自一笔 2021 年的第三方采购，当时的付款记录还在，但没有授权文件；另外 81 个连付款记录都找不到。这 81 个码只能直接废弃。
96 个跨店共用的码，我建议全部做隔离处理。具体做法是把其中一个店铺的商品下架，用新码重新上架，保留历史评价的部分通过变体方式处理。这个动作直接损失了大约两周的上新节奏，但把关联风险切断了。
431 个有付款记录但无授权的码，我们选择保留但标注”权属待确认”，同时向原采购方发函索取授权证明。后来拿到了部分证明，剩下的一批在三个月内逐步替换。替换节奏我建议拉长到季度维度，避免集中操作引起平台注意。
整改完成后，我们把编码主表、绑定表、店铺分配表固化下来，并用数跨境做日常维护。上架流程里加了一道前置动作：新 SKU 必须先领码，领码时系统自动查重并记录领取人和时间，然后才能上传。
这个流程刚推的时候运营有抵触，觉得多了一步。三个月后他们的反馈变了，因为素材准备时间从原来的大半天压缩到十几分钟，日常只需要维护状态字段。
整改过程中有个现象让我印象很深：这位卖家最担心的 96 个跨店共用码，实际处理起来反而最快，因为问题定义清晰，方案明确。真正耗时间的是那 512 个无来源码，因为它们需要一条一条回溯历史，翻邮件、翻付款记录、联系旧供应商，平均每个码的处理时间是共用码的四倍以上。
这给了我一个持续沿用的判断：编码问题的处理成本，和它的定义清晰度成反比。所以整改的第一件事不是解决问题，而是把所有问题定义清楚、归类明确。这一点比任何工具都重要。
方法要分场景。下面按四类典型卖家给出具体动作，你可以对号入座。
你的重点不是工具，是把三张表建起来。哪怕先用一张工作表、三个页签，只要能保证 UPC 和 SKU 一对一、每个码有来源和状态，就已经合格。
建议动作：第一，把所有在售商品的 UPC 导出，逐个标注来源和状态；第二，找出所有找不到来源的码，向供应方索取证明或列入替换计划；第三，建立”领码”规则，新 SKU 上架前必须先在台账登记。这三步做完，账号安全的基础就打好了。
你的核心风险是跨店共用和历史遗留。建议动作：第一，做一次跨店铺的 UPC 交叉比对，找出所有共用码并做隔离；第二，对第三方采购的码做分批替换计划，按季度推进；第三，上系统化台账工具，把唯一性约束交给系统而不是人。
替换节奏上，我的建议是每个季度替换总量的 15% 到 25%，不要一次全换。全换的操作量太大，而且集中变更本身会留下异常痕迹。
你有 GTIN 豁免这条路径，但不能因此忽略历史编码。建议动作：第一，盘点品牌备案生效前使用的所有第三方码，标注为历史遗留；第二，新上架商品统一走豁免或自有 GS1 编码，不再混用；第三，把编码来源作为品牌资料的一部分做归档，方便品牌复核时调用。
特别提醒一点：品牌备案主体和编码注册主体必须一致。如果品牌在 A 公司名下，编码却来自 B 公司的 GS1 授权，这个不一致在复核时会被追问。
你的情况更复杂，因为码的归属可能分散在多个客户主体名下。建议动作：第一，为每个客户建立独立的编码空间，物理隔离，不做跨客户复用；第二，客户交接时必须有完整的编码交接清单，双方签字确认；第三，服务合同里明确编码权属归客户，避免争议。
我见过代运营把不同客户的 UPC 混在同一张表里管理，后来其中一个客户解约时要带走数据，扯了很久。隔离做得越早，交接成本越低。
每个方案都有代价，我不主张非黑即白。下面四组取舍是我在实际项目里反复遇到的。
自购 GS1 编码的成本是年度费用制，对中小卖家来说是一笔持续支出，但换来的是明确的权属和随时可出具的主体证明。第三方码便宜、上手快，但权属链路不完整。
我的判断标准是看你是否计划长期经营同一品牌。如果打算做三年以上的品牌化经营，自购 GS1 是更优解，因为它把编码风险从”可能爆发”变成”结构上不存在”。如果是测试型铺货、商品生命周期短，第三方码在控制数量的前提下可以接受，但必须建台账、控规模。
集中管理的好处是能发现跨店冲突，坏处是流程多一步、响应慢一些。分散管理响应快，但几乎必然产生冲突。
我的建议是编码层集中、运营层分散。编码的分配和登记集中在一个地方，日常上下架操作由各店铺自行完成，但所有变更必须回写台账。这个折中方案在多店卖家那里执行效果最好。
Excel 的优势是零成本和极高的灵活性，劣势是没有唯一性约束、没有变更审计。工具的优势正好相反。
我给出的分界线是：SKU 超过 200 个，或者店铺超过 2 个，或者有多人协作，满足任何一条就上工具。在这条线以下，Excel 完全够用，不必为了工具而工具。
立即整改能最快消除风险，但会打断正常经营，尤其是跨店共用码的隔离，几乎必然影响上新节奏。分批推进保留了经营节奏，但风险敞口会在整改期内持续存在。
我的取舍逻辑是按风险等级分批：高危项（跨店共用、权属完全缺失）立即处理，中低危项按季度推进。这个方案的实际执行效果，比”全停整改”和”先放着不管”都更好，因为它把有限的精力集中在真正会引起账号事故的部分。
回到开头那个家居卖家的案例。他的问题最终解决了，方式是提交了完整的编码台账、采购凭证和商品对应清单，两周后链接恢复。但他付出的代价是错过了整个旺季的前半段。
这件事让我更坚定一个判断：UPC 落地的价值不在于让商品上架，而在于让商品在被质疑时有据可依。上架是运营动作，可自证是合规能力，两者不在同一个层级上。
我见过太多卖家把账号安全理解成”不刷单、不侵权、绩效别飘红”，这三条当然对，但它们覆盖的是显性风险。编码、商品信息、权属凭证这些隐性风险平时不出声，一旦出声就是账户级别的问题，而且留给你的响应时间通常只有 48 到 72 小时。
另一个我想强调的观点是：编码管理的投入产出，不体现在采购单价上，而体现在排查、自证和盘点这三类隐性人工成本上。我在样本里看到的情况是，台账化之后编码入库耗时降到原来的五分之一，一码多品排查耗时降到二十分之一，而审查材料准备时间从二十多小时压缩到三小时以内。这些数字背后的意义是，你在危机发生时的响应速度被结构性提升了。
最后一个常被忽略的点：UPC 不是一次性工程。SKU 会增减，供应商会更换，品牌授权会调整，店铺会新开或关闭。每一个变化都会让之前的绑定关系失效一部分。所以台账必须跟着业务变，而不是建完就锁进抽屉。
这三件事不需要采购任何工具，也不需要停业，一个下午就能启动。它们的共同作用是把编码从一个模糊的表单字段，变成一条清晰可查的记录。
当你发现自己在 Excel 里用条件格式标重复、用 vlookup 交叉两张表、或者需要反复问同事”这个码是不是用过了”的时候，就是该换方式的信号。
这时候可以看看数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）这类把商品、编码、店铺放在同一套结构里的做法，重点是它的唯一性约束和变更留痕能力，而不是它有多少个功能菜单。工具选型看的是它能不能替代你最容易出错的那一步，而不是功能数量。
UPC 这件事没有捷径，但它有一个好处：只要流程建对了，它会一直替你挡在前面。等到下一次审核通知来的时候，你能不能在两小时内交出一份说得清的材料，答案其实在几个月前就已经写好了。
读者评论
铺货那段说到我了，早期也是三个人轮流维护一张 Excel，同一个码挂两个 SKU，原因就是删了链接没删记录。不过多店共用 UPC 会被关联这点，我们两年了没触发，感觉跟类目、销量权重有关系，希望口径能再细一点，别一刀切。
换主体那段挺有共鸣。我们是品牌授权从 A 公司转到 B 公司，UPC 沿用没换，结果备案主体和 GS1 注册主体对不上，被要求补材料。想问下这种情况除了重新申请码，有没有成本低些的过渡办法，比如授权链文件能不能覆盖过去。
个 SKU 这个经验值感觉偏保守，我们 500 多个 SKU，人工加脚本查重也没出过大问题，关键还是流程定死。另外靠系统做唯一性约束确实比 Excel 稳，但录入如果还是手填，脏数据照样进得去，工具只是兜底不是根治。