We check our duty math against CBP's final answer

Every refund estimate on our platform is, at bottom, a duty recomputation: what an entry should have been assessed under the tariff schedule and every applicable program, versus what was paid. For entries CBP has finally liquidated, there is a ground truth for that arithmetic: the final duty total CBP itself posted when it closed the entry. We run that comparison continuously, entry by entry, and we publish the method, the numbers, and the limitations.

To our knowledge (as of July 2026, re-checked at publication), no other tariff analytics product publishes a validation of its duty computation against ACE liquidation outcomes. Accuracy claims are common in this industry; published, reproducible validation methods are not. We publish ours (including the parts that are not yet flattering) because a refund claim is only as strong as the arithmetic behind it.

Why this matters for a refund claim

A refund vehicle (a CAPE declaration, a post-summary correction, a protest) asks CBP to agree that the duty on an entry should have been X, not the Y that was paid. The number X comes out of a computation engine.

Most tariff software is checked, at best, against published rate tables. But assessment behavior lives in the details those tables don't settle by themselves: effective-date boundaries, Chapter 99 routing, program stacking, country scope. Liquidation is CBP's own final computation on a real entry: the same authority that will adjudicate your claim, doing the same arithmetic your claim depends on. It is the strictest oracle available, so it is the one we test against.

The method, in plain language

Our customers upload their own ACE entry summary data. For every entry in that corpus that CBP has actually liquidated, we compare three entry-level duty totals:

1. Liquidated: CBP's final total duty from the ACE entry summary;
2. Filed: the duty declared at entry, summed across the entry's lines at program grain (MFN / Section 232 / Section 301 / Section 122 / IEEPA);
3. Engine: a rates-only re-simulation of each line (HTS-10, origin, entry date, SPI) through the CustomsGenius tariff engine.

Two totals agree when they differ by at most $1 absolute or 0.5% relative, whichever is larger. Those tolerances are constants imported from the engine codebase (the same values the product uses), not thresholds tuned per report.

Every comparable entry is then classified into exactly one agreement class:

Entries that cannot be compared honestly are excluded before classification: no liquidation data, not yet liquidated, or "incomparable" (duty outside the covered program grain, a non-ad-valorem MFN rate, or the partial-knowledge case below). Exclusions are never counted as agreement.

Results are persisted at cluster grain (HTS × month × class) with no customer entry numbers: the validation ledger carries no customer-identifying data.

The precise rules we hold ourselves to

These are the rules exactly as implemented; they are what keep the numbers below honest.

• Entry-grain rule. CBP's liquidated total exists only at entry-summary grain, so filed and engine totals are summed to entry grain before comparison. This is an entry-total validation, not a per-line one: offsetting per-line errors that net to the same entry total are invisible here.
• Partial-knowledge comparability rule. Some ACE report layouts omit program duty columns entirely (an absent column is a format gap, not $0), so the filed total can be a known-programs subset of the true filing. Absent columns can only make the true filing larger, so: liq ≈ filed(known) classifies normally; liq < filed(known) is a real reduction and stays classifiable on the engine axis; liq > filed(known) is ambiguous (a CBP correction and invisible column money are indistinguishable), and is excluded, never counted as agreement.
• Boundary-precision rule (engine axis, past months). The engine's Chapter 99 rate history replays the full 2016–2026 USITC revision archive (156 revisions, backfilled 2026-07-17), so past entry months replay against real per-revision history. Effective dates for windows opened by pre-2020 revisions are publication-date approximations (curated overrides pin the researched legal boundaries), so entries within a few days of an era boundary can classify against the neighboring window. And where the archive's grain differs from filing practice (for example, granted exclusion take-up that entry data does not carry), a residual "CBP liquidated as filed but the engine differs" share persists. That residual signals a comparison limit, not necessarily filing errors and not necessarily engine errors, and we publish it rather than net it away.
• Tolerance rule. $1 absolute or 0.5% relative, whichever is larger: cent rounding, one rule everywhere.

Current numbers

All tables on this page are machine-generated from the production validation ledger and dated. Nothing here is hand-computed.

Three-way liquidation comparison · regenerated 2026-07-18 · corpus: 7 entry months (2019-06, 2020-09, 2020-11, 2021-06, 2022-06, 2022-11, 2023-06), replay runs through 2026-07-17

Read those two axes correctly. The filed axis says CBP overwhelmingly liquidated these classified entries at the filed amount: a statement about CBP's outcomes versus the filings, and about the integrity of the comparison pipeline; it is not a claim about our engine. The engine axis is the claim about our engine: on 8,519 of 14,659 classified entries, CBP's final liquidated total lands within tolerance of our independent recomputation, including 149 entries where CBP corrected the duty at liquidation and the corrected amount matched our engine rather than the original filing.

The remaining engine-axis gap is dominated by the "CBP liquidated as filed but the engine differs" class (6,047 entries): the boundary-precision and exclusion-take-up limits described above, plus the Section 232 content-basis uncertainty listed under limitations. Under those rules a large share of that residual is a limit of what entry data can express, not a measured engine error, but we cannot cleanly separate the two from this data alone, so we publish the whole classified universe, per month, rather than a curated subset:

Per entry month · same generation (2026-07-18) · counts derived from the per-class table of the same run

2019-06 and 2020-09 are small months (8 and 12 classified entries); they are shown because the rule here is the whole classified universe, not the months that look best.

The wider evidence ledger

The three-way comparison is one oracle among several we run against the same engine. The evidence ledger sweeps the engine's whole answer surface and classifies every cell by the strongest evidence touching it:

Evidence ledger · generated 2026-07-17

That 91.17% is an evidence-coverage number, not an accuracy number: it measures how much of the answer surface is supported by something other than our own code, never how often we are right. The engine's answer surface is swept exhaustively (23,782 HTS-10 codes × 102 country equivalence classes × 1,127 effective-date boundaries back to 2018), and each cell is classified by the strongest evidence touching it, with open disputes counted and listed, not netted away. Quote it only next to its companion: excluding tracked open disputes, the share is 73.02%.

What this does, and does not, claim

It claims exactly this: within the classified universe described above, CBP's final liquidated entry totals agree or disagree with the filed and engine totals per the class table, within the stated tolerance. Where the liquidated total matches the engine total, the engine's entry-total duty computation is corroborated by CBP's own final assessment.

It does not claim:

• per-line or per-program validation: the comparison is at entry-total grain only;
• anything about excluded entries: exclusions are not agreement;
• coverage of duty programs outside the compared grain (AD/CVD, Section 201, Russia column 2, Chapter 98, other Chapter 99 families): entries carrying such duty are excluded where detectable, and where a report layout hides them they can only surface as disagreement, never as agreement;
• reconciliation of liquidated fees (duty only);
• that the corpus is a representative sample of U.S. entries: it is customer-uploaded ACE data;
• exact legal boundary dates for rate windows opened by pre-2020 revisions (the boundary-precision rule above);
• and never, anywhere, perfect accuracy.

Honest limitations

• The corpus is what our customers upload. It skews toward the trade lanes and programs our customers file in; an "entry" is a (customer account, entry number) pair, so an entry uploaded by two accounts counts once per account.
• Section 232 comparisons carry content-basis uncertainty: derivative lines assess on metal content value that entry data does not carry, so the replay prices full value; affected clusters are flagged rather than suppressed. CA/MX IEEPA / Section 122 entries carry USMCA-qualification uncertainty, flagged the same way.
• A $0 liquidation is ambiguous in ACE exports, and non-final statuses are simply not done; both are set aside, counted in neither direction.
• An oracle point confirms a dated cell, not an era. In the evidence ledger, a confirmation attaches to the specific (code, country, date) it tested; the surrounding stable period rests on the sweep's change-point analysis, and no cell yet carries confirmations from two independent oracles. We track that distinction explicitly.
• Zero-duty agreements count as agreements. A filer declaring $0 for a program the engine also prices at $0 confirms the engine's no-duty answer; much of real traffic is exactly that. The tolerance still applies.

How to audit us

The methodology is reproducible, and that is deliberate.

• The numbers are generated, not typed. Every table above is produced by scripts from the production validation tables; nothing on this page was hand-computed. Each regeneration is dated in place, and the evidence ledger records the as-of date of every oracle input it used.
• The tolerances live in the engine's code, as named constants (LIQ_AGREE_ABS_USD, LIQ_AGREE_REL), imported by the validation pipeline: the report cannot quietly loosen them.
• The classified engine build is pinned. The evidence ledger records the exact answer-surface fingerprint of the engine build it classified: sha-256 manifest 706cd88570d6f63be0f769b5a16a3fcd97ae268e1ea4996e5b3a72d8367a8b4f (blessed 2026-07-17), so the claims attach to a specific, identified version of our code, not "the engine, generally."
• Disagreements are enumerated. Open disputes (places where an authority source, a replayed entry, or an external rules mirror disagrees with the engine) are tracked as first-class items with counts published above, not resolved by deletion.

Numbers on this page are regenerated from production validation data at publication and dated in place. Last regeneration: 2026-07-18.