Most FTZ software submits weekly estimated entries (7501s) to ACE the same way you'd submit a form to a 1998 government website. The user types the values, the system formats the EDI, the system transmits, and the system trusts that whatever ACE says back is fine. There is no real validation in either direction.
We pulled the data on 84 customer zones over four years. The cost of this "fire and forget" pattern, in CF-28 responses, recap adjustments, and audit exposure, is large enough that I'm somewhat shocked it's still the default.
What "blind" means here
A 7501 (entry summary) is the document that tells CBP what you imported, how much it's worth, and how much duty you owe. In an FTZ, you file one weekly, aggregating all the withdrawals from that week.
Filing it "blind" means three things:
- You don't validate the HTS codes on the entry against your master classification list before submission.
- You don't validate the duty rates on the entry against CBP's current published rates before submission.
- You don't reconcile the entry against ACE's accepted version after submission.
You file the entry. ACE accepts it. You move on. Whatever ACE wrote back into the entry summary file is now your system of record. If it doesn't match what you sent, you'll find out months later when CBP follows up.
What we found in the data
Over 84 customer zones and approximately 22,000 weekly estimated entries pre-Mamora, we measured the rate of post-filing adjustments. Here's the breakdown:
- 11.4% of entries had at least one CF-28 (Request for Information) within 24 months of filing.
- 3.2% of entries required a recap adjustment to correct a duty rate, value, or classification.
- 0.8% of entries triggered a CF-29 (Notice of Action), meaning CBP changed something and we had to live with their version.
- Average dollar adjustment per CF-29: $14,200.
For a single customer doing $200M annually, that translates to roughly $480,000 a year in adjustments and recovery work. The interesting thing is that 80% of the adjustments could have been prevented at filing time, because the underlying source data was correct in the operator's master systems. The data just didn't make it to the entry without drift.
The classic failure mode: a senior analyst updates a SKU's classification on Tuesday. The weekly entry job runs Friday using a cached copy of the classification table from Monday. The entry goes out with the old classification. CBP doesn't catch it. The internal classification list and the entry are now diverged. Twelve months later: CF-28.
What bidirectional ACE validation looks like
Bidirectional means three things, in order:
Pre-flight validation, on every entry, before transmission. Before we submit a 7501, we run the entry through a validator that checks: are the HTS codes on the entry the current signed classifications for those SKUs? Are the duty rates the rates we expect, given the entry date? Are the values consistent with the inbound invoice trail? If anything fails, we hold the entry and surface the discrepancy to the compliance team. We don't transmit and hope.
Post-flight reconciliation, after ACE acknowledges. ACE sends back its version of the accepted entry. We diff our submitted version against ACE's accepted version. Any field that differs is an event in the audit trail. The operator can see exactly where ACE re-classified a code, recomputed a duty, or rejected a value, on the entry it relates to, not in a separate report three weeks later.
Standing watch on rate changes. CBP and USTR publish rate updates with effective dates. Our system tracks rate changes against open entries. If a withdrawal date crosses a rate change boundary, we flag it before the entry is built. This is the change that eliminates most of the missed-rate-change adjustments.
What it looks like in practice
For one of our consumer-electronics customers, the entry adjustment rate dropped from approximately 12% of entries (pre-Mamora) to 0.4% of entries (post-Mamora) within four months of go-live. The drop is almost entirely from catching errors pre-flight that previously would have gone out and bounced back.
The customer's compliance team did not get smaller. They just stopped doing recap adjustment work. The two people who used to spend Friday afternoons on adjustments now spend Friday afternoons on duty optimization. Same headcount, dramatically more leverage.
Why most FTZ software doesn't do this
The honest answer is that bidirectional ACE validation is hard. ACE EDI is a difficult interface. The error messages are sparse. Rate-change tracking requires a continuously-updated tariff database. Pre-flight validation requires the system of record for classifications to be the same system that builds the entry, which means a single source of truth across modules.
Most legacy FTZ software was built one module at a time. Inventory was bought, then classification was bolted on, then filings were bolted on. Each module has its own version of the truth, and they reconcile via overnight batch. Building real-time validation across that architecture is essentially a rewrite.
We had the advantage of building from scratch. Our reconciliation post explains the event-sourced model that makes this possible. It's not magic; it's just the right base.
If you want us to look at your last 90 days of weekly entries and tell you what would have been caught by pre-flight validation, we'll do it free. Most customers find at least one CF-28 in flight that we could have prevented.