TCC26-0077 背后：CBSA 系统积压的真实代价

要点速览

• TCC26-0077 公告说的延迟时间太乐观，现场实际等了快七小时。
• EDI 回执和 RNS 通知一积压，货就卡住，仓储费、司机等待费全来了。
• CBSA 系统一堵，我们经纪人再有本事也放不了行。
• 进口商得在预算里给 CBSA 的技术问题留点应急钱。

现场到底什么情况

4 月 16 号东部时间 10:15，TCC26-0077 公告出来了，还是那套话：处理量高，出站 EDI 和 eManifest 消息延迟，预计 3–5 小时。结果呢？一直拖到 17:35 才恢复。前后超过七小时。

如果你上午用 PARS 报了一票货，指望中午前拿到 RNS 通知司机提货，那你得等到下午甚至傍晚。如果你在等一条拒绝消息，好改单重报，那半天时间就白白耗掉了。

这不是系统完全宕机。你的申报报文其实发出去了，只是堵在 CBSA 的队列里。确认消息、放行通知、拒绝消息、CARM 的会计完整性通知……全都延迟。用 eManifest 门户的也一样。ACI 状态更新也跟不上。要是承运人等着 A8A 或 X70 消息去港口提柜，那卡车就只能原地干等。

公告里说“出站消息”延迟。意思是，你的申报可能没问题，但 CBSA 那边发不出确认和 RNS，你这边就没法进行下一步。如果你做的是准时制供应链，或者承诺当日送达，这七小时可不是个小数目。

钱从哪儿开始烧

先放后税（RPP）的客户最吃亏。 你用 PARS 申报，必须拿到 RNS 才能动货。RNS 延迟五小时，卡车司机可能就错过交货时段，收货方关门了。结果就是滞留费或者二次配送费，看承运人和城市，150 到 300 加元跑不掉。要是赶上周五下午，延迟拖过营业时间，货就得在 CFS 或码头仓库里过周末——这又是实打实的仓储费。

对 CARM 下自己申报的客户，打击方式不一样。 你传了 G1，等着完整性通知或者 CARM 客户端门户更新。如果这个延迟了，你就没法确认付款到期日，没法核对 GL 代码，财务团队催你要数据你也给不了。RPP 的保证金责任在你申报那一刻就生效了，但你看不到确认消息，就不知道风险敞口到底有多大。如果你管的是大进口商，每周 RPP 结算额几十万上百万，这事儿就更头疼。

最糟的是拒绝消息延迟。 HS 编码或者 CARM 账号敲错了，系统拒绝，你改完重报。正常情况下 20 分钟搞定。要是拒绝消息本身延迟三小时才发到你手上，整个下午就报销了。如果货是易腐品或者高价值货物，停在皮尔逊（YYZ）或太平洋门户（YVR）这种地方，每一分钟的延迟成本都在放大。冷链可不等人。

为什么总堵车？以后还会堵吗？

CBSA 不公布实时吞吐量数据，但我们能猜个大概。四月中是复活节后，夏季的货开始到了，加上有些进口商担心 CPTPP 或 CUSMA 有变数，提前发货。再叠加上 CARM 上线后的磨合期——商业会计申报变多，门户活动变多，G1 替代旧 CAD 的工作流——这就是结构性流量增长碰上了季节性波动。

eManifest 那边更简单：货多了，ACI 申报就多。如果 CBSA 的基础设施还是按 2023 年的流量规模建的，现在跑的是 2026 年的货量，系统升级又总是慢半拍，那这种公告就会成为常态。算不上灾难，但也不少见。过去 18 个月，类似的 TCC 公告我们至少见过十几次。

说句实话：这就是新常态。 CARM 增加了复杂度。门户在某些方面比老的 CADEX 系统好，另一些方面则更麻烦。EDI 消息流更细了，对审计是好事，但对吞吐量就是压力。CBSA 心里明白。他们不会在公告里写“我们容量建少了”，但规律就摆在那儿。

你该怎么做？

第一，给时间敏感的放行留足缓冲。 如果你需要下午 3 点前送到，别指望下午 1 点报关来得及。上午 10 点就报。如果你用的清关经纪服务承诺当日交付，确保他们留的余量包含了 CBSA 可能延迟的时间，而不只是他们自己的处理时间。

第二，如果你在 CARM 下自己申报，别光等邮件。 系统正常的时候邮件提醒都可能滞后。时间紧的话，手动登录 CARM 客户端门户查状态，更靠谱。

第三，跟承运人和仓库商量费用宽限。 很多卡车公司和码头，如果你能出示 CBSA 的延迟公告（比如 TCC26-0077）和你申报的时间戳证明，他们会免掉滞留费或仓储费。不是所有人都会同意，但值得一试，能省一点是一点。

第四，如果你跑 RPP，盯紧保证金额度。 七小时的延迟，意味着你的保证金要多“悬空”七小时，才能看到最终会计数据。如果你额度卡得紧，接近上限，新申报就可能被系统自动暂停，直到额度释放出来。算法不讲情面：假设你每周进口 200 万加元，按 10% 的保证金覆盖率，你需要始终有 20 万加元的可用额度。如果因为处理延迟，有 15 万被未确认的申报占住了，那你只剩 5 万空间，一票大货就报不了了。确保你的经纪人或贸易合规团队能实时追踪这些未完成的放行。

长远看，问题没解决

TCC26-0077 是解决了，系统赶上了。但根子上的问题——CBSA 的基础设施应对不了现在的流量——不会消失。以后还会有 TCC26-008X、009X……延迟时间可能 90 分钟，也可能过夜。

关键就在于，你的运营有没有足够的弹性来吸收这种冲击。还是说你卡得太死，三小时的延迟就会像多米诺骨牌一样，引发罚金、错过交货窗口和客户投诉？

如果你还把 CBSA 的处理速度当成当日保证，是时候调整预期了。如果你建的供应链时间线，还假设 RNS 是即时的，那你肯定会吃亏。这不是悲观，而是面对现实——我们得根据现有的系统来规划，而不是我们希望有的那个系统。

如果你现在的经纪人，没法让你实时看到申报状态、识别确认延迟，那这个信息缺口值得补上。联系我们，我们可以给你看看我们这边的实时追踪是怎么做的。

来源: CSCB