The entry summary came back rejected and the reflex in the office is to resubmit it with a field nudged and fingers crossed. Stop there. The rejection code names a specific mismatch between what was filed and what CBP's system expected, and resubmitting without reading it just starts the clock over with the same error inside.
In ACE, a rejection means the entry summary data failed a validation or disagreed with data already on file: a tariff line that does not accept the reported value, a missing partner agency flag, a manufacturer code that does not resolve. Sandler, Travis and Rosenberg's trade reporting returns to this point often: the system is literal. It is not judging your product, your broker, or your intentions. It is comparing fields.
That literal quality is useful. The code plus the line reference narrows the fault to a small set of fields, and CBP's ACE guidance documents the common validations in advance. Teams that keep a local log, code, cause, fix, build a diagnostic table from their own history within a quarter, because most importers reject on the same handful of causes repeatedly.
Stale reference data leads: an HTS line amended since the worksheet was built, a Chapter 99 line that no longer pairs with the base subheading, a special programme indicator claimed without the supporting flag. Next come quantity mismatches, where the second quantity a heading requires, kilograms alongside pieces, is blank or in the wrong unit. Then party data: importer number formatting, a mid code built from the wrong manufacturer details.
Each has a different fix and a different owner. Reference data belongs to whoever maintains the classification file. Quantities belong to the commercial invoice and packing data. Party data belongs to the master records. Routing the rejection to the wrong owner is how a one hour correction becomes a three day thread while the container sits.
Every rejection has two fixes available: patch this entry, or patch the record that produced it. Patching only the entry wins the release and guarantees an encore on the next shipment of the same product. The worksheet, the supplier master, or the invoice template that generated the bad field is still in place, still wrong, and already loaded into next month's filing.
Keep the fix boring and written down. Rejection log entry, source record corrected, initials, date. When the same code appears twice in a month, the log shows whether the source fix happened or only the entry patch did. In most offices the honest answer explains the recurrence.
Occasionally the system is not wrong and neither is the filer: the data is inconsistent because the underlying classification is unsettled, and two defensible readings of the product produce two different data sets. That is no longer a rejection to patch. That is a ruling question, or at minimum a broker review with the product file open, because filing forward on a coin flip builds a history CBP can read later as a pattern.
Draw that line explicitly in the log. Mark the rejection as data error or as classification open, and do not let an open classification ride from entry to entry on whichever reading the filer preferred that week. Reasonable care, the standard the customs law actually applies, is mostly this: knowing which of your filings rest on settled ground and which do not.
Keep reading: USMCA claims live or die on the supplier declaration you kept, Post summary corrections and protests: which clock is your entry on.
That the filed data failed a validation or disagreed with data CBP already holds: a tariff line mismatch, a missing required quantity, a party code that does not resolve. It is a diagnosis of the filing, not a judgement on the goods, and the code plus line reference points at the fields involved.
Because the entry gets patched and the source record does not. The classification worksheet, supplier master, or invoice template that produced the bad field stays in place and generates the same error on the next shipment. Logging code, cause, and the source fix, and checking the log monthly, is what breaks the cycle.
Whoever owns the record at fault. Reference and tariff data sits with the classification file owner, quantities with the invoice and packing data, party details with master records. Sending every rejection to the broker by default misroutes two thirds of them and stretches a short correction into days.
When the data is inconsistent because the classification itself is unsettled and two defensible readings produce different filings. That needs a broker review or a ruling request, not another patch. Mark it as classification open in the log so it does not quietly repeat across entries.