Green freight truck on a winding highway heading toward the Canada border

ACI eManifest Errors Explained: How Highway Carriers Fix Rejected CBSA Messages

Justin K
Justin K
Operations & Content Manager
BorderPrint — Cross-border shipping documents & compliance supplies for highway carriers and brokers.
Photo: Jan Baborák (Unsplash)

Every eManifest clerk who has worked a highway desk for more than a month has lived this moment: the trip you filed an hour ago comes back with a red status instead of green. The driver is already rolling, dispatch is texting "are we good?", and the History tab is showing a wall of CBSA response text that doesn't explain itself in plain English. This post is about that moment — not the general "what is ACI" primer, but the actual troubleshooting work of decoding a rejected ACI eManifest message, fixing the root cause, and getting the trip re-accepted before the driver is standing at primary with nothing to show.

The good news is that CBSA's ACI eManifest reject messages are more formulaic than they feel at 6 a.m. Once you've seen "Shipment Linked to Another Trip" or "Duplicate" a few dozen times, you start reading them the way a mechanic reads a check-engine code — annoying, but diagnosable. The goal of this post is to get you there faster: what each common reject actually means, the specific fix, and a repeatable workflow so you're not reinventing the process every time a trip bounces back.

Quick takeaway: A rejected ACI eManifest is not a filing — it's a draft with a problem attached. The one-hour clock only starts once CBSA returns an ACCEPTED status, so every minute spent guessing instead of reading the actual CBSA response in History/Status Messages is a minute you're not getting back. Fix the exact thing the message names, resync or resend, and confirm acceptance before the driver is close to the port.

1) Why ACI eManifests get rejected in the first place

Before you can fix a reject, it helps to understand why CBSA's system generates one at all. The ACI eManifest process is really two datasets that have to agree: the carrier's primary cargo and conveyance data, and the broker's secondary data on the same shipment. When the trip number, cargo control number, port code, or shipment linkage on one side doesn't match what's already on file on the other side — or doesn't match what CBSA's validation rules expect — the system kicks it back rather than silently accepting mismatched information.

In practice, most rejects trace back to a short list of causes: a cargo control number that's still tied up on an earlier trip, a trip number or CCN that's been reused, a request that doesn't match the record's current state, a port code that doesn't line up between the trip and its shipments, or a shipment that simply isn't on file yet when the trip tries to reference it. None of these are exotic. They're the everyday friction of a fast-moving dispatch operation where trip numbers get recycled, trailers get reassigned, and paperwork gets typed under time pressure.

The dispatch-desk reality

It's worth saying plainly: rejects are not a sign that your team is bad at this. They're a sign that highway freight moves faster than paperwork naturally wants to. A load gets rebooked, a broker updates an entry, a trailer swap happens at the yard — and the eManifest data doesn't automatically follow along. The fix isn't to slow down; it's to know exactly where to look when the system tells you something doesn't match.

Working assumption: Treat every reject as a data-integrity question, not a compliance failure. Something the trip references — a CCN, a trip number, a port code — doesn't match what CBSA expects right now. Your job is to find that one thing.

2) Read the status, not your gut — the CBSA status flow

The single most useful habit for anyone troubleshooting ACI eManifest rejects is this: stop guessing and go read the actual CBSA response text. Every trip and shipment record carries a History or Status Messages section, and that section holds the literal language CBSA sent back. That text is your starting point for any fix — not the trip number, not what you remember from last week's similar reject, not a hunch.

The key statuses you'll see on a highway trip are worth memorizing because they tell you which stage of the process you're actually in:

  • Transmitted to CBSA — sent, waiting on a response. Not accepted yet, don't treat it as filed.
  • CBSA Returned Error — rejected. Something needs to be corrected and resynced before this trip is usable.
  • On File / Accepted — the only status that actually satisfies the pre-arrival requirement.
  • Arrival Reported at Border — the driver has reported and the system has logged the arrival event.
  • Rejected after Arrival at Border — the officer at the booth rejected something after the driver already reported. This needs a correction and an Amendment transmission, not a fresh resend.

Why this matters more than it sounds like it should

It's tempting, especially when dispatch is under pressure, to see any status that isn't obviously red and assume it's fine. "Transmitted" sounds like it's done. It isn't. CBSA requires the eManifest on file and accepted with CBSA at least one hour before the driver arrives at the border — a filed-but-not-accepted manifest does not satisfy that rule. So the habit to build is: don't tell the driver to proceed, and don't consider the trip "filed," until you've actually seen an accepted status, not just a transmitted one.

Common mistake: Reading "Transmitted to CBSA" as good news and moving on to the next trip. Transmitted just means CBSA has your data and is validating it — it says nothing about whether the data will pass.

3) The one-hour clock and why "accepted" is the only status that counts

For highway carriers, the rule is simple to state and easy to get wrong under pressure: the complete ACI eManifest — trip and shipments together — has to be on file and accepted with CBSA at least one hour before the driver arrives at the border. Miss that window with an accepted record, and you're looking at possible refused entry, a delay at primary while things get sorted out, or an AMPS penalty, depending on how the situation plays out.

The part that trips people up is that the clock doesn't start when you hit send. It starts when CBSA returns an accepted status. If your first submission gets rejected at minute 58 before arrival, you haven't "filed with one minute to spare" — you have an unfiled trip and a driver getting closer to the border. That's exactly why reading and fixing a reject quickly isn't just good practice, it's the difference between a compliant trip and a non-compliant one.

PARS shipments add a second clock

If the load is riding on a PARS release, there's a second acceptance to track. The one-hour clock for a PARS shipment on the manifest only really starts once both the eManifest and the broker's entry are accepted — so the safe habit is to wait for a status like "On File With Transaction Number(s)" before you tell the driver they're clear to proceed. Treating the eManifest acceptance alone as the green light, while the broker's side is still pending, is a common way PARS trips end up flagged at the booth even though "the manifest was fine."

Practical rule for dispatch: Build your buffer around the accept, not the send. If your target is one hour before arrival, aim to have the trip submitted with enough runway that a first-pass reject still leaves time to fix it and get re-accepted before the deadline.

4) "Shipment Linked to Another Trip"

This is one of the most common rejects highway carriers see, and it almost always means exactly what it says: the cargo control number you're trying to use on this trip is still attached to an earlier trip in CBSA's system. CBSA won't let the same CCN live on two active trips at once, so the new trip bounces.

The fix

Start with the original trip. If it's still active and just needs to be updated, sync it so the shipment gets released from it, then go back and Sync with CBSA on the new trip. If the original trip has already arrived or been released and can't be reopened, don't fight it — assign a brand-new cargo control number, send it as a new shipment, then sync the trip that's waiting on it.

Where this usually comes from: A load gets rebooked onto a different trip after the CCN was already used once, or a trailer swap happens and someone reuses the old shipment record instead of creating a fresh one. Either way, the fix is the same — free up the old link or issue a new number.

5) "Duplicate" trip number or CCN

A "Duplicate" reject means CBSA's system has already seen this exact trip number or cargo control number and won't accept it a second time. This is almost never a system glitch — it's almost always a reused identifier. The most frequent version of this is reusing an old PAPS or trip number that was already submitted on a prior run, which is an easy trap when dispatch is copying a template from last week's paperwork.

The fix

Change the trip number or CCN to something genuinely new and unique, then Sync or Send New Shipment Request as appropriate. If your team recycles trip numbers by habit — say, using the same base number with a letter suffix — this is the reject that will eventually catch you. Build a numbering convention that guarantees uniqueness across trips, not just across the week.

Dispatch tip: If your booking software auto-generates trip numbers, double-check that the auto-generation isn't resetting or cycling in a way that produces repeats during high-volume weeks.

6) "Invalid Status of Request"

This reject is a little more abstract than the first two, but the underlying idea is straightforward: the type of request you sent doesn't match the record's current state in CBSA's system. A classic example is resending an already-accepted manifest as if it were brand new, when CBSA is expecting a change/sync request instead. Another version is trying to modify a record that's already been cancelled.

The fix

The rule of thumb here is to match your action to the record's actual state. Use Sync with CBSA when you're changing something on a record that's already on file — don't resend it as new. If a record has been cancelled, treat it as gone and send the corrected version as a new record rather than trying to edit the cancelled one. When in doubt, check the current status in History before deciding whether you're syncing a change or sending something fresh.

Why this one repeats: Teams that are used to "just resend it" as their default troubleshooting move often trip this reject repeatedly, because resending isn't always the right action — sometimes syncing is, and the two aren't interchangeable.

7) Wrong or mismatched port

Port code mismatches are a quiet but frequent source of rejects. CBSA expects the trip and all of its attached shipments to reference the same port code. If the trip says one port and a shipment on it says another — often because a load got rerouted to a different crossing after the shipment record was created — the system flags it.

The fix

Edit both the trip and every attached shipment to the correct, matching port code, then Sync. One thing worth flagging specifically: don't reach for a legacy "Change Trip Only" option when the shipment-level port also needs to change. That option only touches the trip record, and if the shipments still reference the old port, you'll be back in reject territory on the next sync.

Quick check before you resync: Open every shipment attached to the trip, not just the trip record itself, and confirm the port code matches on each one. A trip that "looks right" at the top level can still have a stray shipment pointed at the old port.

8) "Not on File" and broker/PARS coordination

A "Not on File" reject means the trip is trying to reference a shipment that CBSA doesn't actually have a record of yet. That can happen for a few reasons: the shipment is still sitting in draft and was never transmitted, it was cancelled or rejected on its own and never got resubmitted, or — in a multi-party move — another carrier or the broker was supposed to send that shipment record and hasn't yet.

The fix

Work through it in order. First, check whether the shipment simply needs to be sent — if it's still a draft, send it. If it was rejected, fix that shipment's own reject first, because a broken shipment can't be "on file" until its own issue is resolved. If the record belongs to another carrier or the broker, confirm with them that it was actually transmitted before you keep resyncing your trip against a shipment that isn't there yet. Once the shipment is confirmed on file, go back and sync the trip.

This is also where the carrier/broker handshake matters most. Rejects tied to PARS shipments often aren't really an ACI problem at all — they're a coordination gap where the carrier assumes the broker's entry is in and the broker assumes the eManifest is accepted, and nobody has actually confirmed both sides.

AMPS penalties escalate: CBSA's Administrative Monetary Penalty System applies graduated penalties that increase with severity and with repeat occurrences within the retention window, which typically runs about a year. A "Not on File" or any other reject that isn't caught and fixed before arrival isn't just an inconvenience — repeated misses can move you up the penalty scale. Fixing rejects quickly and filing clean data the first time is the practical way to stay off that escalation path.

9) The universal reject-fix workflow

Almost every reject, regardless of which message it throws, gets resolved by the same sequence of steps. Once your team has this workflow memorized, troubleshooting stops feeling like detective work and starts feeling like a checklist.

  1. Open the rejected trip or shipment in your eManifest software, EDI tool, or the CBSA Portal.
  2. Read the most recent CBSA Response in the History / Status Messages section — not last week's message, the current one.
  3. Identify the exact phrase CBSA returned (Shipment Linked to Another Trip, Duplicate, Invalid Status of Request, port mismatch, Not on File, etc.).
  4. Fix the specific trip, shipment, or number that the response actually names — resist the urge to change unrelated fields "just in case."
  5. Retransmit correctly: use Sync with CBSA for trip-level changes, and Send New Shipment Request for shipment-level corrections.
  6. If a shipment was resent and comes back accepted, return to the trip and sync it too — fixing the shipment alone doesn't automatically update the trip that references it.

Print this list, tape it to the dispatch monitor, whatever works — the point is that six steps, done in order, close out the overwhelming majority of ACI rejects without a phone call to anyone.

Why order matters: Jumping straight to step 5 without doing steps 2–4 is how teams end up resyncing the same broken data over and over. Read first, identify the exact cause, then act.

10) Filing clean the first time — data match and the lead sheet at the booth

The best reject-fix workflow in the world is still slower than not generating the reject at all. Most of the rejects covered above trace back to a handful of preventable data-match issues: the carrier's primary cargo and conveyance data disagreeing with the broker's secondary data, vague or inconsistent commodity descriptions, an incorrect consignee, expired or mistyped carrier codes, and wrong port codes. Cleaning up these habits at the source — consistent trip numbering, a habit of double-checking port codes across trip and shipment records, and a real handshake with the broker before the driver rolls — prevents most of the rejects in this post before they happen.

There's also a presentation-layer piece that's easy to overlook once you're deep in troubleshooting mode: once a trip is actually accepted, the driver still needs to hand the officer something clean at the booth. A scannable ACI eManifest lead sheet gives the officer the trip's Cargo Control Number and Conveyance Reference Number in a consistent, legible format, which reduces the manual-keying mistakes and mismatches that can themselves trigger a reject or a slow secondary referral. To be clear about what this is and isn't: the lead sheet doesn't file anything and isn't a government form — the carrier's eManifest software, EDI connection, or the CBSA Portal is what actually transmits and files the manifest. The lead sheet is the clean presentation copy that carries the accepted data to the booth in a form an officer can scan quickly instead of re-keying.

ACI eManifest Lead Sheet with scannable CRN Trip barcode for CBSA border presentation
ACI eManifest Lead Sheets

A clean, consistent lead sheet for the driver to present once your trip shows an accepted status — built around the same CCN/CRN barcode data CBSA officers scan at the booth.

See the physical lead sheets, or explore the whole ACI eManifest lead sheet collection for format options.

Some fleets run occasional Canada-bound trips and only need to print a sheet now and then; for that use case there's a plain digital download version at /products/aci-emanifest-lead-sheets-digital that you can print on demand once the trip is accepted, rather than keeping physical pads on hand.

Where this sits in the bigger picture

None of this replaces good filing habits. A lead sheet can't fix a "Duplicate" reject or a port mismatch — those still need to be corrected in the eManifest data itself, using the workflow above. What a clean lead sheet does is remove one more variable at the moment the driver is standing at the window: instead of an officer squinting at a handwritten number or re-typing a reference, the barcode does the work, and the accepted data you already fixed gets read cleanly the first time.

Putting it together: Read the actual reject message, fix the specific thing it names, resync or resend correctly, confirm acceptance with real time to spare before the one-hour mark, and hand the driver a lead sheet that presents that accepted data cleanly. That's the whole loop.

Related reading:

FAQ

What does "CBSA Returned Error" mean?

It means the trip or shipment was rejected — CBSA's system found something in the data that doesn't validate, such as a linked shipment, a duplicate number, a mismatched port, or a request type that doesn't match the record's current status. The exact reason is in the History/Status Messages text, and that text tells you exactly what to fix before you resync or resend.

My manifest was rejected at the border — what now?

A rejection that happens after the driver has already reported at the border ("Rejected after Arrival at Border") needs to be handled as a correction followed by an Amendment transmission, not a brand-new submission. Identify the specific issue the officer or system flagged, correct it in the record, and transmit the Amendment so the corrected data is tied to the same trip.

Does refiling reset the one-hour clock?

The one-hour clock runs from the most recent ACCEPT, not from your first submission attempt. If your original filing gets rejected, fixing it and getting it re-accepted starts the clock over from that new acceptance — so the safe practice is to file with enough buffer that a reject-and-fix cycle still lands you an accepted status well before the driver reaches the border.

Regresar al blog