Why Your CAPE Filing Got Rejected: An IEEPA Refund Troubleshooting Guide

Since CAPE Phase 1 went live on April 20, 2026, the customs-broker community has been logging more rejection errors than refund disbursements. That's not a bug in CAPE — it's how a brand-new validation pipeline always behaves in week one. The good news: nearly every rejection comes from one of seven specific error categories, and each has a known fix.

This is the operational troubleshooting guide. Use it when you've submitted a CAPE Declaration, received a rejection or partial-acceptance, and need to figure out exactly what to fix before resubmitting.

Companion guides: If you haven't filed yet, start with the CAPE step-by-step and the Phase 1 launch readiness checklist. This post assumes you've already submitted at least one Declaration.

---

File-level vs. entry-level errors: the most important distinction

CAPE validates submissions in two stages, and which stage rejects you determines what you fix:

Stage	What gets rejected	Where to look	Resubmission required?
File-level	The entire CAPE Declaration	File header, format, structure	Yes, full new Declaration
Entry-level	Only specific entries inside an accepted Declaration	The Validation Result File	No — re-file just the failed entries on a new Declaration

If you got a "Declaration rejected" notification, that's file-level: the entire CSV bounced before CBP looked at any individual entry. If you got an "Entries rejected" notification, the Declaration was accepted but specific rows failed validation. Check the Validation Result File first; it contains the per-entry status codes and error reasons.

---

The 7 most common CAPE rejection errors (and exact fixes)

Error 1 — Missing or malformed CSV header row

What CBP sees: A Declaration without the required header row, or with a header that doesn't match the expected column names exactly, fails the file-level format check immediately.

What you fix:

• Use the exact header row published in the CAPE Trade Information Notice
• Column names are case-sensitive and must be in the prescribed order
• No leading/trailing spaces; no Excel-introduced BOM characters
• Save as UTF-8 CSV (not Excel .xlsx, not UTF-16, not CP-1252)

🛠️ Hidden trap: Excel's "Save As CSV" can introduce a UTF-8 BOM that breaks parsing. Use a text editor or specify encoding=utf-8-sig programmatically only if CBP's spec explicitly accepts it (current spec: plain UTF-8).

Error 2 — Entry doesn't contain IEEPA Chapter 99 codes

What CBP sees: An entry submitted on a CAPE Declaration that doesn't contain at least one IEEPA-related HTSUS Chapter 99 code is automatically rejected at the entry level. CAPE is IEEPA-only in Phase 1; entries with only Section 232, Section 301, or AD/CVD duties don't belong here.

What you fix:

• Pull the entry's full HTS line listing from ACE
• Confirm at least one Chapter 99 IEEPA code appears (the relevant subheadings are listed in the CAPE TIN appendix)
• If the entry has zero IEEPA duties paid, it's not eligible — remove it from your Declaration entirely
• If the entry has IEEPA duties paid but the Chapter 99 code wasn't reported at filing, work with your broker on a Post-Summary Correction (PSC) before re-submitting through CAPE

Error 3 — Entry was on a previous Declaration

What CBP sees: CAPE rejects entries that appear on more than one Declaration to prevent double-claiming. The Validation Result File flags these as "duplicate entry."

What you fix:

• Pull every CAPE Declaration you've submitted in the past
• Cross-reference entry numbers — duplicates can happen when two team members each filed without coordinating, or when a broker re-ran a corrected file without removing already-accepted entries
• If a prior Declaration was partially accepted, the accepted entries cannot be re-submitted; only the rejected ones go on a new Declaration
• Maintain a single source-of-truth log of "filed entries" by date and Declaration ID

Error 4 — Entry outside the 80-day window or already past liquidation

What CBP sees: Phase 1 covers unliquidated entries plus entries inside the 80-day post-liquidation window (within CBP's 90-day voluntary reliquidation authority). Older entries get rejected at the entry level.

What you fix:

• Sort your entry list by liquidation date
• Anything liquidated more than 80 days ago is not a CAPE candidate — it requires a protest under 19 U.S.C. § 1514 within 180 days of liquidation, or a CIT action thereafter
• Move those entries to a separate workflow; do not include them on CAPE Declarations
• For entries that are about to age out (75+ days post-liquidation), prioritize the next Declaration

Error 5 — ACH bank account not enrolled or verified

What CBP sees: The Declaration is accepted, but the refund cannot be paid because the importer's ACH banking details are missing or unverified in ACE. These show up on the REV-613 ACH Rejected Refunds report rather than as a Declaration-level rejection.

What you fix:

• Log into ACE → Importer sub-account → ACH enrollment
• Confirm bank routing and account numbers are correct
• ACH enrollment requires verification — a small test deposit may need to clear before the account is "active"
• Until ACH is active, refunds sit in CBP's pending queue. The Declaration isn't rejected, but no money moves
• Run REV-613 weekly during the first month of CAPE filings

💡 Why this is so common: Many importers had ACH set up for paying CBP but never enabled the receiving direction. They are different toggles.

Error 6 — Liquidation status discrepancy

What CBP sees: An entry that ACE shows as "Final liquidation" but the CAPE module shows as eligible (or vice versa). Reported in r/CustomsBroker on April 20: an entry with a liquidation date 73 days prior was accepted by CAPE despite showing "Final liquidation status" in standard ACE reports.

What you fix:

• This is more often a CAPE bug than a filer error in week one
• Pull the entry's liquidation history from ACE Reports
• If liquidation is truly final (past the 90-day reliquidation window): the entry should not be on a CAPE Declaration; remove it
• If liquidation occurred within the past 80 days but ACE shows "Final": file via CAPE anyway and document the discrepancy. CBP has acknowledged data-sync issues during week one
• Open a CSMS-channel question if your case is unusual; broker forums are surfacing edge cases for CBP to address

Error 7 — CSV row count exceeds the 9,999-entry limit per Declaration

What CBP sees: Declarations larger than 9,999 entries are rejected at the file-level immediately.

What you fix:

• Split the file into chunks of ≤9,999 entries each
• Most SMB importers will never hit this; high-volume importers (large retailers, e-commerce platforms) need a chunking workflow
• File the chunks sequentially, waiting for each Declaration ID before submitting the next — to avoid duplicate-entry confusion if you have to re-run

---

Reading the Validation Result File

After every Declaration submission, CAPE generates a Validation Result File in your ACE inbox. It contains:

• declaration_id — the unique ID for the submission
• entry_no — the specific entry being evaluated
• status — ACCEPTED / REJECTED / PENDING_REVIEW
• error_code — a short identifier (e.g., MISSING_IEEPA_CH99, DUPLICATE_ENTRY, OUT_OF_WINDOW)
• error_detail — human-readable explanation

Always download the file. Don't rely on the on-screen summary; the per-entry detail is in the file. Save each file with the Declaration ID in the filename for audit purposes.

---

The "Phase 1 only" rejection categories

These rejections aren't filer errors — they're scope rejections that you can't fix in Phase 1. Plan for Phase 2 instead:

• Liquidated more than 80 days ago — file a protest (19 U.S.C. § 1514) within the 180-day window
• Section 232/301/AD/CVD-only entries — Phase 2 may add these; meanwhile, no action needed if duties were correctly paid
• Pre-2025 IEEPA entries — outside scope; CIT-level litigation required
• Re-filed entries from a Phase 1 Declaration that was fully accepted — the refund is already in flight; do not re-file

---

Resubmission cadence: how to avoid making things worse

A common pattern: filer gets a rejection, immediately re-files a corrected Declaration, gets another rejection because the original Declaration was actually partially accepted and the new file double-counts. To avoid this:

1. Always download the Validation Result File before re-filing. Identify which entries were accepted (those are now in flight) vs. rejected (those need to be re-filed).
2. New Declaration ID per resubmission. Don't try to amend; CAPE doesn't support amendments yet. File a fresh Declaration containing only the entries that need to go through.
3. Wait for the previous Declaration's full settlement before assuming an entry was rejected silently. CAPE settlement is 45–90 days; an entry that doesn't show as "ACCEPTED" or "REJECTED" within 7 business days is likely under compliance review, not lost.
4. Log everything: Declaration ID, submission timestamp, validation result filename, accepted entry list, rejected entry list. You will be glad you did when finance asks why $80,000 in refunds are still pending.

---

Where TariffCenter can help

• Refund Status Tracker — monitor CBP settlement timelines for accepted Declarations
• Refund Readiness Checklist — pre-flight your data before submitting a Declaration
• Refund Estimator — back-of-envelope estimate of total refund exposure
• CAPE Portal Step-by-Step Guide — the filing-process companion
• CAPE Phase 1 Launch Readiness — the pre-flight checklist
• Why SMBs Are Being Left Out of IEEPA Refunds — structural barriers and how to overcome them
• AI Tariff Assistant — paste your error code and get a fix without waiting for a callback

---

Bottom line

CAPE is working. Most rejections are not "the system is broken" — they're CSV format issues, missing Chapter 99 codes, ACH enrollment gaps, or scope mismatches. Walk the seven-error checklist on every rejection, download every Validation Result File, and keep a per-Declaration log. Within two cycles you'll have a clean filing pipeline.

If your Declaration is sitting in PENDING_REVIEW for more than 14 days, that's the case to escalate. Everything else is fixable on your side.