ACE does not read an entry summary the way a person does. It validates line by line against programmed rules, and the flags it raises are specific. An HTS code whose validity dates do not cover the line action date comes back as INVALID HTS. A Chapter 99 code that requires a corresponding code, where the partner code is missing, comes back as an HTS relationship mismatch. A Chapter 99 additional duty code filed without its base Chapter 1 to 97 classification underdeclares duty even when every number on the line is internally consistent. CBP has been narrowing and splitting these validations through Cargo Systems Messaging Service notices, breaking broad error messages into specific ones and removing validations that caught valid entries. The practical lesson is unglamorous: read the exact error text, fix the exact field, and where the underlying HTS has been end-dated and replaced, file a post-summary correction to swap the code before resubmitting.
End-dated codes are the quiet repeat offender
The HTSUS changes constantly, and codes get end-dated and replaced between the day a purchase order is cut and the day the entry is filed. A filer working from last quarter's classification worksheet can file a code that was valid when the worksheet was written and invalid on the entry date. ACE catches it. The fix is a post-summary correction replacing the expired code with its replacement, then resubmission, but the durable fix sits upstream: classification data needs a validity check against the current schedule at filing time, not at worksheet time.
Related reading on this site: LandedWatch and LandedWatch cover the neighbouring problems in more depth.
Chapter 99 codes travel in sets
Additional duties live in Chapter 99, and many of those codes are defined in relation to others: a derived or additional duty code expects its corresponding base or partner code on the same line, in the reporting order CBP publishes. File one half of a pair and the line fails validation, or worse, passes with duty understated. Brokers who build the Chapter 99 set from the product's action list, Section 301 first, then Section 232, then other programs in the published sequence, get fewer relationship flags than brokers who append codes as they remember them.
When CBP splits a broad validation into narrower ones, resubmitted entries that failed under the old message may now pass, or may fail with a more specific message that names the actual problem. A resubmission after a CSMS validation update is not gaming the system. It is the procedure CBP itself describes in the notice.
Keep the error log, it is your audit trail
Every ACE flag on your entries belongs in a log with the entry number, the error text, the fix, and the resubmission date. Patterns in that log are a reasonable care file in miniature: three INVALID HTS flags on one supplier's product line is a classification review waiting to be scheduled, and the log is how you prove you scheduled it.
Frequently asked questions
What does an INVALID HTS error in ACE mean?
It generally means the HTS code on the line is not valid for the line action date, often because the code was end-dated and replaced after the classification was first assigned. The usual fix is a post-summary correction substituting the current replacement code.
Why do Chapter 99 codes trigger relationship errors?
Many Chapter 99 additional duty codes are defined alongside corresponding codes that must also appear on the line. If the partner code is missing, ACE raises a relationship mismatch and the entry cannot proceed until the set is complete.
Can an entry rejected by a validation be resubmitted?
Yes. After correcting the underlying data, including a post-summary correction where the filed code itself has changed, the entry can be resubmitted. CBP notices on validation updates often direct filers to resubmit entries caught by the older, broader checks.
What is a post-summary correction used for?
A post-summary correction amends fields on a filed entry summary before liquidation, including classification, value, and origin in most cases. It is the standard tool for fixing line data that ACE validation or a later review shows to be wrong.