
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.
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.
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.
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."
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.
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.
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.
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.
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.
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.
- Open the rejected trip or shipment in your eManifest software, EDI tool, or the CBSA Portal.
- Read the most recent CBSA Response in the History / Status Messages section — not last week's message, the current one.
- Identify the exact phrase CBSA returned (Shipment Linked to Another Trip, Duplicate, Invalid Status of Request, port mismatch, Not on File, etc.).
- Fix the specific trip, shipment, or number that the response actually names — resist the urge to change unrelated fields "just in case."
- Retransmit correctly: use Sync with CBSA for trip-level changes, and Send New Shipment Request for shipment-level corrections.
- 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.
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.

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.
Related reading:
- ACI eManifest Lead Sheets Explained: How Highway Carriers Keep CBSA eManifest Smooth
- ACE eManifest Timing Explained: How Highway Carriers Avoid CBP Filing Errors
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.