CAPE Declaration Rejected? Top 10 IEEPA Refund Validation Failures and How to Fix Them (May 2026)

CAPE Declaration Rejected? Top 10 IEEPA Refund Validation Failures and How to Fix Them (May 2026)

CBP's Consolidated Administration and Processing of Entries (CAPE) tool went live in ACE on April 20, 2026, opening the IEEPA refund pipeline that thousands of importers and brokers have been waiting on since the Supreme Court's ruling in late 2025. The early data is sobering. By April 26 — six days after launch — importers and brokers had submitted approximately 75,300 CAPE Declarations covering more than 11.2 million individual entries. CBP had cleared roughly 1.74 million of those entries through all validation steps. That is a 15.5% pass rate. The remaining 84.5% were either rejected outright at the file level, kicked back at the entry level for correction, or held pending compliance review.

If your CAPE Declaration came back rejected, you are not alone — and the good news is that almost every rejection reason is mechanical, fixable, and resubmittable. CBP designed the CAPE schema as a series of automated validation gates rather than a single discretionary review, which means most failures point you directly at the field that broke the submission. The fix is usually a one-line correction, a re-export from ACE, or a small structural change to the file.

This guide breaks down the top ten validation failures CBP is rejecting in the first month of CAPE operations, the exact error code or rejection message you will see in ACE, the underlying root cause, and the step-by-step fix to get the entry back on the next Declaration. We also cover the resubmission playbook — what to delete, what to resubmit, what to leave alone, and how to track partial rejections so a 9,999-entry Declaration does not bog down because of forty bad rows.

If you have not yet filed a CAPE Declaration, start with our CAPE Declaration Filing Checklist and the broader Complete IEEPA Refund Guide — those pieces walk through filer eligibility, ACH enrollment, and the underlying refund eligibility rules. This article assumes you already submitted at least one Declaration and need to fix what came back broken.

How CAPE Validation Actually Works

Before walking through the specific failure modes, it helps to understand the two-tier validation architecture CBP built into CAPE. File-level validation runs first. It checks the structural integrity of the entire CAPE Declaration submission: the file format, the header row, the submitter identity, and the basic completeness of the entry list. If any file-level check fails, the entire Declaration is rejected and you have to resubmit the corrected file from scratch. No partial credit, no salvage of the good rows — the file is treated as unprocessable until you fix the structural issue and re-upload.

Entry-level validation runs second, on Declarations that passed file-level checks. Each entry number on the Declaration is then evaluated individually against a series of automated rules: format, status, control flags, prior-Declaration history, and IEEPA HTS code presence. If an entry fails any entry-level check, only that specific entry is rejected. The Declaration itself remains accepted, and the surviving entries continue down the processing pipeline toward liquidation or reliquidation and ultimately refund issuance. Rejected entries can be added to a new CAPE Declaration after the underlying problem is corrected.

The distinction matters for triage. A file-level rejection is a stop-everything event — nothing in that Declaration is moving until you re-upload. An entry-level rejection is a targeted cleanup task that runs in parallel with the rest of the refund pipeline. Most filers in the first week of CAPE who reported "rejections" were actually seeing entry-level rejections on a subset of their entries while the bulk of their Declaration continued processing normally.

The CAPE rejection messages in ACE are structured so the failure type — file or entry — is identifiable from the response code. If your broker or in-house ACE team is not sorting rejections by type before triage, that is the first process improvement to make. File-level rejections cannot wait. Entry-level rejections can be batched and resubmitted on the next Declaration cycle.

The Top 10 CAPE Validation Failures

1. Submitter Identity Mismatch (File-Level)

Error pattern: "Filer is not authorized to submit a CAPE Declaration for the listed entries."

Root cause: CBP only accepts a CAPE Declaration from one of two parties for a given entry: (1) the Importer of Record (IOR) on the entry summary, or (2) the licensed customs broker who filed the entry summary on the IOR's behalf. Anyone else — a downstream broker, a freight forwarder, a parent company that is not the named IOR, a customs consultant — cannot submit a CAPE Declaration for those entries, even with a valid power of attorney. Several large 3PLs were caught by this in the first week because their internal trade compliance team is structured separately from the licensed broker entity that actually filed entries.

Fix: Confirm the filer code on each entry summary and submit the Declaration from the authorized party only. If your organization has a licensed broker entity and a separate consulting entity, the Declaration must come from the broker entity. If you switched brokers mid-2025 and want to include entries filed by the prior broker, the prior broker must submit those entries on their own Declaration — you cannot consolidate prior-broker entries onto your current-broker Declaration. The only workaround for switched-broker situations is for the IOR itself to submit, which an IOR can do but requires the importer to take direct ACE submission responsibility.

2. Missing or Malformed Header Row (File-Level)

Error pattern: "Unable to parse file. Header row missing or invalid."

Root cause: CAPE Declarations are submitted as structured files (CSV or the CAPE XML schema) with a required header row defining the column layout. CBP's parser is strict about the header — the column order, naming, and casing must exactly match the published CAPE schema. Common causes include exporting from a custom Excel template that adds blank rows at the top, copy-pasting entry numbers without the header row, using legacy ACE field names that have been renamed in the CAPE schema, or saving the file as .xls when CAPE only accepts .csv or .xml.

Fix: Pull the current CAPE schema directly from CBP's CSMS 68340863 deployment notice and use the published template as your starting point. If you are exporting from a broker management system, configure the export profile to the official CAPE field names — do not rely on field labels carried over from your internal ACE reports. Open the file in a plain-text editor (not Excel) before submission to confirm the first line of the file is the header row with no leading blank lines, BOM characters, or stray whitespace.

3. Invalid Entry Number Format (Entry-Level)

Error pattern: "Entry number format invalid. Expected 11 alphanumeric characters."

Root cause: Entry numbers in CAPE must be exactly 11 alphanumeric characters. Dashes are tolerated and stripped before validation, but other special characters — spaces, slashes, dots, parentheses, leading apostrophes added by Excel — cause an immediate format rejection. The most common offender is the Excel apostrophe added when a numeric-looking entry number is formatted as text, which is invisible in the spreadsheet view but present in the underlying file and breaks the parser.

Fix: Run a format-cleanup pass on the entry-number column before export. The canonical approach is to load the data into Python or a similar scripting environment and apply a regex strip of non-alphanumeric characters, then verify each cleaned value is exactly 11 characters long. Re-add a dash separator only if your broker management system requires it for internal tracking — CAPE itself accepts both formats. Reject any entry-number value that is not 11 characters after cleanup, because it cannot be a valid ACE entry number and including it on the Declaration will trigger this error.

4. Duplicate Entry Numbers Within the Same Declaration (Entry-Level)

Error pattern: "Duplicate entry number detected within CAPE Declaration."

Root cause: A single CAPE Declaration may not contain the same entry number twice. This sounds obvious but breaks under two common workflows. First, importers who source the entry list from multiple monthly ACE reports often introduce overlap at the report boundaries — an entry summary that was unliquidated on March 31 and liquidated on April 1 may appear on both the March and April reports. Second, brokers who consolidate entry lists from multiple internal teams or sub-brokers can pick up duplicates if the source lists are not deduplicated before consolidation.

Fix: Run a deduplication pass on the entry-number column before submission. A simple Excel duplicate-removal filter catches the majority. For larger files, scripted deduplication with a hash check on the normalized 11-character entry number is more reliable. After deduplication, the surviving entry list is what gets submitted. If two duplicate entries had different metadata (different IOR codes, different release dates), investigate the discrepancy — one of them is likely a typo in the source data and should be corrected before submission rather than just deduplicated.

5. Entry Summary Status Is Not "Accepted" (Entry-Level)

Error pattern: "Entry summary status must be Accepted. Current status: [Filed / Hold / Rejected / etc.]."

Root cause: CAPE only processes entries whose ACE entry summary status is "Accepted" and whose Control Status is "CBP." Entries that are still in "Filed" status (submitted but not yet accepted by CBP), in "Hold" status (held by CBP for review), in "Rejected" status (rejected by CBP for a separate reason), or with Control Status set to "Filer" instead of "CBP" will fail this validation. The Control Status flag in particular catches a lot of brokers because it does not appear in standard entry-summary reports — you have to pull it specifically.

Fix: Filter your source entry list to only include entries with Status = "Accepted" and Control Status = "CBP" before generating the CAPE Declaration. Entries in other statuses need their underlying issue resolved first — work the filer-Control-Status flip with your broker liaison, work the Hold or Rejected status with the entry-summary team, and re-file as necessary. Once the status is corrected to "Accepted" and Control Status is "CBP," the entry can be added to the next CAPE Declaration cycle.

6. Filer Code Mismatch on Entry Number Prefix (Entry-Level)

Error pattern: "First three characters of entry number do not match filer account."

Root cause: The first three characters of every ACE entry number are the filer code of the broker who filed the entry. For broker-submitted CAPE Declarations, every entry on the Declaration must start with the broker's own filer code — the system rejects any entry where the prefix does not match. This catches brokers who acquired entry lists from sub-brokers or affiliated entities without verifying that the filing entity matches. For IOR-submitted CAPE Declarations (where the importer files directly without a broker), this validation runs differently — the importer's IOR number is checked against the entry's IOR field rather than the filer-code prefix.

Fix: For broker submissions, filter your entry list to only entries with a prefix matching your filer code, and route any non-matching entries back to the original filer for inclusion on their own Declaration. For multi-entity broker groups, run a separate Declaration per filer code rather than trying to consolidate across entities. For IOR submissions, confirm the IOR number on each entry matches the submitting IOR — entries filed under a related-party IOR cannot be consolidated onto a parent IOR's Declaration without separately filing as that related party.

7. Disallowed Entry Type (Entry-Level)

Error pattern: "Entry type [08 / 09 / 23 / 47] is not eligible for CAPE processing."

Root cause: Four entry types are categorically excluded from CAPE: Duty Deferral entries (Type 08), Reconciliation entries (Type 09), Temporary Importation under Bond (Type 23), and Drawback entries (Type 47). These entry types operate under separate accounting and refund mechanisms that CBP did not want to entangle with the IEEPA refund flow. Including any of these entry types in a CAPE Declaration triggers an automatic rejection of those specific lines.

Fix: Run an entry-type filter on your source list before Declaration generation, excluding all rows where Entry Type is 08, 09, 23, or 47. For IEEPA-affected entries that happen to be classified as one of these types, the refund pathway is different — Reconciliation entries are refunded through the existing Reconciliation flow on the underlying entry, TIB entries that have IEEPA exposure should be addressed at TIB closeout, and Drawback entries require coordination with the Drawback Center rather than CAPE. Duty Deferral entries are the most complex case and typically require a manual ticket with the assigned CBP center.

8. Entry Already Submitted on a Prior Declaration (Entry-Level)

Error pattern: "Entry number was included on a previously submitted CAPE Declaration."

Root cause: CAPE keeps a running ledger of every entry submitted on any prior Declaration by any filer. An entry can only appear on one accepted Declaration in its lifetime. If the prior Declaration was accepted (even if the underlying entry was subsequently rejected at the entry-level), the entry is locked out of new Declarations until the prior submission is unwound. This catches brokers who resubmitted an entire Declaration after a partial rejection without removing the previously-accepted entries from the new submission.

Fix: Maintain a clean ledger of which entries have been submitted on which Declarations and use that ledger as the exclusion list when generating new Declarations. If you have entries that were submitted on a prior Declaration but failed entry-level validation, the proper path is to wait for the rejection to be finalized in ACE, then resubmit only those rejected entries on a new Declaration — not the entire prior list. CBP has indicated they will publish a "Submitted Entry Lookup" tool in a future ACE deployment, but as of May 2026 filers must maintain their own ledger.

9. Missing IEEPA Chapter 99 HTS Code (Entry-Level)

Error pattern: "Entry does not contain a dutiable IEEPA Chapter 99 provision."

Root cause: CAPE only processes entries that actually paid an IEEPA-based duty. The validation looks for at least one Chapter 99 IEEPA-related HTS provision on the entry summary with a non-zero duty amount. Entries that had IEEPA provisions present but for $0.00 duty (because of an exclusion, exemption, or zero-rate transition period) are not eligible — there is no duty to refund. Entries that were affected by IEEPA policy but never had the Chapter 99 line added to the summary (because the broker filed before the IEEPA provisions took effect, or filed using only Chapter 1–97 lines) likewise fail.

Fix: Run a Chapter 99 audit on your source entry list before Declaration generation. Each entry should have at least one of the IEEPA-related Chapter 99 codes (9903.01.XX series for the universal reciprocal tariff, plus the country-specific add-ons for China, Canada, and Mexico). Entries without the Chapter 99 line need a post-summary correction filed first to add the missing provision and the corresponding duty, after which CAPE can process the refund on the corrected entry. Entries with the Chapter 99 line but $0.00 duty have no refund to claim and should be excluded from the Declaration entirely.

10. ACH Refund Account Not Enrolled (Refund-Level)

Error pattern: Appears on the REV-613 ACH Rejected Refunds report rather than as a CAPE Declaration rejection.

Root cause: The CAPE Declaration itself was accepted and processed, but when CBP went to issue the refund, the recipient party — either the IOR directly or the broker-designated party from CBP Form 4811 — was not enrolled in ACH refunds in ACE. CBP no longer issues paper refund checks for IEEPA refunds; ACH enrollment is mandatory. The refund stays in CBP's queue until the recipient enrolls, after which it is reissued automatically.

Fix: Enroll the refund-receiving party in ACH through ACE Portal before submitting the CAPE Declaration. The enrollment process takes 7–10 business days, so plan accordingly. For brokers receiving consolidated refunds on behalf of multiple IORs, the broker entity itself must be ACH-enrolled — the underlying IOR enrollments are not used. If you have already filed a CAPE Declaration and your refund is sitting on the REV-613 report, complete ACH enrollment promptly and the refund will be reissued in the next ACH cycle (typically weekly).

The CAPE Resubmission Playbook

Most importers who saw rejections in the first month of CAPE operations made the same recovery mistake: they resubmitted the entire original Declaration after correcting the rejected rows, rather than submitting only the corrected rows on a new Declaration. This compounds the problem in two ways. First, every entry that was accepted on the original Declaration is now flagged as a duplicate on the resubmission, triggering Error #8 above on every line that previously processed cleanly. Second, the resubmission goes back through file-level validation as a fresh Declaration, so if you fixed an entry-level issue but the file structure still has an artifact from the original submission, you can introduce a brand-new file-level rejection that takes down everything.

The correct resubmission pattern is:

Step 1. Pull the ACE response file for the original Declaration. Identify which entries were accepted, which were rejected at the entry level, and the rejection reason for each. CBP returns this as a structured response keyed to the entry numbers on the submission.

Step 2. Build a corrective worklist of only the rejected entries plus the rejection reason for each. Group corrections by failure type — all the format issues together, all the status issues together, all the filer-code mismatches together — because the fix workflow is different for each.

Step 3. Apply the appropriate fix to each rejection group. Format issues get cleaned in the source file. Status issues get worked through the entry-summary team. Filer-code mismatches get routed to the originating broker. IEEPA HTS code issues get a post-summary correction filed first.

Step 4. Build a new CAPE Declaration containing only the corrected entries. Do not include any entry that was already accepted on the original Declaration — those are already in process and will trigger duplicate rejections if resubmitted. Submit the corrected-only Declaration on the next available CAPE submission cycle.

Step 5. Track both the original and the corrected Declaration through to refund issuance. Refunds from accepted entries on the original Declaration may issue while the corrected Declaration is still in validation, so reconcile the receipts as they arrive against the originating Declaration rather than waiting for everything to finish before tying out the numbers.

The throughput penalty of working corrections through a second Declaration is small — CBP is processing CAPE submissions on a continuous cycle rather than weekly batches — but the throughput penalty of incorrectly resubmitting the entire original Declaration is large because of cascading duplicate errors. Get the corrected-only resubmission pattern right and a partial rejection turns into a 2–4 week delay on the rejected entries while the bulk of the refund moves forward on the original timeline.

When to Escalate Beyond Self-Service

Most CAPE rejections resolve through the file-correction and resubmission flow above. A small minority require escalation to CBP directly or to your assigned port of entry's CBP Center of Excellence and Expertise (CEE).

Cases warranting escalation include: persistent file-level rejections after multiple corrected submissions where the rejection message does not match any of the documented validation rules; entry summary status flags that the entry-summary team cannot resolve through ACE (such as a "Hold" status with no visible hold reason in ACE); filer-code conflicts where the original filing broker has ceased operations and cannot submit a Declaration on the affected entries; and ACH refund-issuance failures where the recipient is properly enrolled but the refund still appears on the REV-613 report after two cycles.

For escalation, the appropriate contact is your assigned CEE based on the industry of the underlying imported goods. CEE contact rosters are published on CBP's website. Do not escalate routine rejections to CEEs — they do not have visibility into the CAPE submission queue and will redirect routine cases back to the standard error-correction flow. Save CEE engagement for genuine policy or system-level blockers.

What This Means for Your IEEPA Refund Timeline

The 15.5% Phase-1 pass rate on first submissions is troubling on its face but largely correctable. Of the 84.5% of entries that rejected, the failure analysis CBP shared informally with major filers indicates that roughly 60% were file-level format issues, 25% were entry-level status or eligibility issues, and 15% were the more complex IEEPA HTS code or filer-code mismatches. The first bucket resolves on a same-day resubmission. The second bucket resolves on a 1–3 week cycle as status flags clear. The third bucket resolves on a 2–6 week cycle as post-summary corrections and filer escalations work through.

Net of all rejection cycles, importers and brokers who built a clean resubmission process should see 90%+ of their initially-rejected entries land on an accepted Declaration within 4–6 weeks of the original submission, and the corresponding refunds typically issue 60–90 days after final acceptance. The compound effect for a clean shop is a refund landing approximately 90–120 days after the first CAPE submission, even with partial first-round rejections.

For importers whose entries fall entirely outside CAPE Phase 1 (entries liquidated more than 80 days before submission, deferred to Phase 2), the rejection pattern in this article does not apply — those entries need a different recovery pathway entirely. See our IEEPA Refund Options Beyond CAPE Phase 1 for the protest-and-CIT playbook on liquidated entries.

Action Checklist

Before resubmitting any rejected entries, walk through this checklist:

1. Identify whether your rejection was file-level or entry-level (different recovery workflows). 2. For file-level rejections, validate header row, file format, and submitter identity before any other fixes. 3. For entry-level rejections, sort by rejection code and group corrections by failure type. 4. Verify ACH enrollment is complete on the refund-receiving party before resubmitting. 5. Build a corrected-only Declaration containing only the rejected entries, not the previously-accepted entries. 6. Maintain a ledger of which entries are on which Declaration to avoid duplicate-submission rejections. 7. Calendar a 60–90 day refund window from final Declaration acceptance. 8. Reserve CEE escalation for genuinely stuck cases — most rejections clear on the standard resubmission cycle.

The IEEPA refund pipeline is moving, even if the first month's rejection rate suggests otherwise. The validation gates are mechanical, the rejection reasons are documented, and the resubmission cycle is fast. Importers who treat the rejection messages as cleanup tasks rather than denials get their refunds within the standard CAPE timeline.

Related Tools

Need help applying these concepts to your operation?

Our tools and insights help logistics professionals optimize freight, warehouse, and duty costs.
All free. No signup required.

Related Articles