9月18日起，美国海关会按 CBP Form 5106 的六项必填字段核进口商身份，字段不准确或不完整，编号当场作废。这篇把六项字段、六类不被接受的地址，以及官网侧要同步改的地方一次写清。
先把结论说清楚
公告本身不长，但下面几个点决定了它为什么必须在本周处理完。
- 发布主体：美国海关与边境保护局（CBP）。2026年8月19日刊登于《联邦公报》，编号 91 FR 53627，文件号 2026-16911，案卷号 USCBP-2026-1024。
- 生效日：2026年9月18日。
- 覆盖范围：所有在册的进口商记录编号，不只针对新提交的备案。
- 判定后果：编号被认定为不准确或不完整，CBP 立即作废，公告原文的表述是作废后"不再具备任何用途，包括把货物进口到美国"。
- 程序特征：没有警告函，没有补正期，不按企业规模分批执行。
- 法律依据：2026年6月3日签署的第14411号行政令《加强海关执法》第2(e)节。登记义务的旧条文是 19 U.S.C. 1484 与 19 CFR 24.5，条文本身没变，变的是执行姿态。
顺序上还有一个容易被忽略的细节，公告写的是机制先作废、再发书面通知，通知发到备案表最新留存的那个邮箱。也就是说，货物先停在港口，你后知道。
Form 5106 六项必填字段对照表
六项必填字段在公告里列得很具体，下面这张表按"字段 / CBP 要求 / 最常见的不合格情形"排列，可以对照自己的备案表逐行看。
| 序号 | 字段 | CBP 要求 | 常见不合格情形 |
|---|---|---|---|
| 1 | 进口商名称（Importer name） | 须与税务登记记录上的一致，也就是法律主体全称 | 用商号、简称或品牌名备案 |
| 2 | 税号（EIN / SSN / CBP 分配号） | 有效且在册的纳税识别号 | 主体已注销，股东变更后沿用旧号 |
| 3 | 邮寄地址（Mailing address） | 当前的营业通讯地址 | 沿用早已搬离的旧址 |
| 4 | 实际经营地址（Physical location address） | 业务或个人的实际所在地 | 填报关行、货代、注册代理人、邮政信箱、虚拟办公室或他人的地址 |
| 5 | 电话（Phone number） | 能直通进口商本身的号码 | 填报关行或货代的总机 |
| 6 | 邮箱（Email address） | 有效且属于进口商 | 填货代或报关行的邮箱 |
公告聚焦的是这六项必填字段。表单里还有三项可选内容，分别是企业结构、实益所有权与公司高管。可选不等于不看，公告同时写明 CBP 可以视情况采取其他执法动作，所以这三项长期放着不管也不是好习惯。
六类不被接受的地址
实际经营地址是本次核查里问题最集中的一项。公告明确列出六类一律不被接受的地址。
- 注册代理人地址
- 报关行地址
- 货运代理地址
- 邮政信箱
- 商务服务中心或虚拟办公室
- 其他个人或实体的地址
六类放在一起读，判定标准其实只有一条，这个地址必须属于进口商自己。
公告的脚注给了一条宽松口径，企业主体的实际经营地址可以是主要负责人的住宅地址。个人独资的进口商拿自己家备案是允许的，特拉华州那种只有注册代理人地址的公司架构则不属于这一类。
一个被广泛传错的点
这一周流传最广的解读是"没有美国实体办公室的卖家会被清理"。这个说法不准确。
CBP 的程序接受境外地址，不会仅因为进口商在美国以外就作废编号。判定的关键是地址归属，不是地址所在国。
对应的实操结论是，不必为了这条新规去租一个用不上的美国办公室。真实且属于本公司的信息，哪怕全部在境外，也是有效备案。把钱花在这里，属于对新规的误读。
技术侧：把主体信息做成单一事实来源
海关核的是你提交的信息能不能互相咬合。官网、结构化数据、发票抬头各写一套，是最常见的咬合失败来源。下面三段可以直接拿去改。片段在 WordPress 6.x 配 PHP 7.4 以上可用，Python 部分在 3.8 以上可用。
1. 一处定义驱动全站
主体信息散落在页脚、联系页、关于页的时候，改一处漏三处几乎必然发生。把六项字段收进一个数组，页面只调用变量。
add_action('init', function () {
$GLOBALS['entity_profile'] = [
'legal_name' => 'Shenzhen Example Trading Co., Ltd.',
'reg_number' => '91440300XXXXXXXXXX',
'address' => 'Room 1201, Building 3, XX Road, Shenzhen, Guangdong, China',
'phone' => '+86 755 0000 0000',
'email' => 'trade@example.com',
];
});
add_shortcode('entity', function ($atts) {
$atts = shortcode_atts(['field' => 'legal_name'], $atts);
$profile = $GLOBALS['entity_profile'];
return esc_html($profile[$atts['field']] ?? '');
});页面里写 entity field="address" 就能取到地址。以后主体信息变更，只改这一个数组，全站同步。
2. 结构化数据：让主体信息机器可读
JSON-LD 里的 Organization 节点可以承载主体名称、税号、地址、电话与邮箱。它和备案表用的是同源资料，采购商搜品牌、AI 抓取站点信息时读的也是这一段。注意写在页面模板里的时候要做实体转义。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Shenzhen Example Trading Co., Ltd.",
"legalName": "Shenzhen Example Trading Co., Ltd.",
"taxID": "91440300XXXXXXXXXX",
"address": {
"@type": "PostalAddress",
"streetAddress": "Room 1201, Building 3, XX Road",
"addressLocality": "Shenzhen",
"addressCountry": "CN"
},
"contactPoint": [{
"@type": "ContactPoint",
"telephone": "+86 755 0000 0000",
"email": "trade@example.com",
"contactType": "sales"
}]
}
</script>3. 一个比对脚本：备案数据与官网公开信息逐字段对照
人工核对容易漏项，尤其是搬过办公室、换过邮箱的公司。把两边导成 JSON，让脚本输出差异更省事。
import json
import sys
FIELDS = ['legal_name', 'tax_id', 'mailing_address', 'physical_address', 'phone', 'email']
def norm(value):
return str(value or '').strip().lower().replace(' ', '')
def diff(filed, site):
rows = []
for field in FIELDS:
a = norm(filed.get(field))
b = norm(site.get(field))
if a != b:
rows.append((field, filed.get(field), site.get(field)))
return rows
def main(filed_path, site_path):
with open(filed_path, encoding='utf-8') as f:
filed = json.load(f)
with open(site_path, encoding='utf-8') as f:
site = json.load(f)
rows = diff(filed, site)
if not rows:
print('OK no divergence')
return
for field, a, b in rows:
print('DIFF {0} filed={1} site={2}'.format(field, a, b))
if __name__ == '__main__':
main(sys.argv[1], sys.argv[2])运行方式是 python diff_entity.py filed.json site.json。输出的每一行 DIFF 就是需要人工确认的字段，filed 是备案数据，site 是官网公开信息。
官网侧要改的位置
网站上的主体信息通常不止一处，下面这张表按位置列了应该对齐的内容。
| 位置 | 应一致的内容 | 说明 |
|---|---|---|
| 页脚 | 公司全称、注册编号、办公地址 | 多数模板把它做成全局区块，改一次全站生效 |
| 联系页 | 电话、邮箱、地址 | 邮箱须为公司自有可收信邮箱，不能挂第三方 |
| 关于页 | 主体全称与经营地 | 与备案表的法律主体名称保持一致 |
| 结构化数据 | Organization 节点全部字段 | 与备案同源，别手写第三套 |
| 发票抬头与邮件签名 | 公司全称、税号、地址 | 采购商与海关两头都会看这两处 |
全流程自查清单
按顺序做完这六步，覆盖面基本够了。
- 书面向货代或报关行索取你名下每一个进口编号当前的备案数据。不要默认它是对的，这是最常见的盲区。
- 把六项必填字段逐条核对，重点看实际经营地址的归属，以及电话与邮箱是不是第三方在用自己的信息。
- 确认备案表留存的邮箱由本公司掌握并且每天有人看。作废通知只发到这个邮箱，同时抄送最后代为申报的报关行。
- 确认海关授权书由进口商与持牌报关行直接签署，没有经货代或境外代理转手。
- 把同样的问题问一遍你的官网，页脚、联系页、关于页、结构化数据里的主体信息是否同源。
- 走 DDP 条款采购的，把上面五条发给供应商。他的编号作废，你的柜子一样停在港口。
公告点到的处罚条款包括 18 U.S.C. § 1001、虚假申报法 31 U.S.C. § 3729，以及针对报关行的 19 U.S.C. § 1641。填错的风险高于不填，这一点值得写进内部流程文件。
后面还有节点
这次执行的是第14411号行政令的第一步，时间表里还排着后续动作。
| 节点 | 日期 | 内容 |
|---|---|---|
| Day 45 | 2026年7月18日 | 国土安全部向国会提交加强海关执法的立法建议 |
| Day 90 | 2026年9月1日 | 简化货物追踪、快速扣押、主动放弃与加速没收流程 |
| 本次核查 | 2026年9月18日 | Form 5106 准确性核查启动，编号可被立即作废 |
| Day 180 | 2026年11月30日 | 新的进口商资格规则、注册信息清理、风险分级、最低境内资产或担保要求 |
11月30日这一步的影响面大于本次。现在因为一个过期的电话就能作废编号，到那个节点，判定口径只会更细。
这件事和外贸独立站的关系
两个动作共用一套事实基础。CBP 核的是公司名、税号、地址、电话、邮箱能不能互相咬合，海外采购商背调你官网时核的是同一组信息。
买家的路径比较固定，先在 AI 里问一轮供应商，再去搜索品牌，然后打开官网核实主体。官网上公司名和营业执照不一致、地址换个页面就变、联系方式只剩一个社交主页，这些都会在对方那里被记一笔。
所以做外贸独立站运营，页面视觉排在后面，主体信息自洽排在前面。独立站SEO也遵循同一个顺序，先把主体信息统一，再谈收录与排名。外贸独立站获客的第一步不是投广告，是让搜到你的人能在几分钟内确认你是一家真实存在的公司。
我自己的做法是，任何对外公开的主体信息先核对三处来源再写上去。用 AI建站平台 搭站的时候，主体资料一次定稿、全站调用，改一处全站同步，能省掉逐页核对的时间。
我手头是在 NEOGRESS AI 这类平台上做的，顺序是把主体信息先定稿，再铺内容，颠倒过来会返工。
需要标一下边界。这类工具解决的是信息一致性的效率问题，不解决合规判断。官网信息规范是配合动作，不替代法务与报关行的专业意见，具体清关安排、合同条款与税务处理请以你的报关行或律师的答复为准。
一点补充
以上是我基于公开公告和几个实操案例整理的字段口径。具体到每家企业情况差别不小，自有主体和 DDP 两种结构的处理方式并不一样。
如果你手上的进口编号是自有的，或者走 DDP 由供应商做进口商，你打算怎么处理？欢迎在评论区说说你的做法，有不同判断也请直接指出。