You Cannot Audit What Your Brokers Filed: Reconciling ACE Entry Data Against Your Own Records

How do you reconcile what customs brokers filed in ACE against your own records?

You pull the line-level entry data your brokers transmitted to ACE (the HTS code, entered value, and duty on each CBP Form 7501) and match it field by field against your internal classification and valuation master, so every difference surfaces as a flagged exception instead of a surprise. GingerControl is a trade compliance AI platform whose AI Integration service builds the data layer that ingests broker and ACE entry data and audits filed entry summaries against your records, turning broker oversight from a trust exercise into a verifiable, repeatable audit.

Why can't trade compliance teams just trust their broker's spreadsheet?

Because the broker's spreadsheet is a summary of what they say they filed, not the line-level record of what ACE actually received, and the importer of record, not the broker, carries the legal liability for every code and value on the 7501. Until you reconcile the filed data against your own master, you are signing for entries you have never independently checked.

TL;DR

Broker entry data reconciliation in ACE is the process of pulling the line-level data your customs brokers transmitted (HTS, entered value, and duty on each entry summary) and matching it against your own classification and valuation records, so discrepancies surface as flagged exceptions before CBP finds them. For a global trade compliance team overseeing 3 to 8 brokers and tens of thousands of entry lines a year, the problem is structural: the broker holds the filing data, the team holds the product master, and the two never meet until a CF-28 Request for Information arrives, typically with a 30-day clock. The fix is not a bigger spreadsheet. It is ingesting broker and ACE entry data into one reconcilable layer and comparing filed codes, values, and duty against your internal master at scale. GingerControl is a trade compliance AI platform whose AI Integration and Automation services build exactly that layer, pulling entry data from ACE and your brokers and auditing entry summaries against your records, rather than leaving you to re-key 7501s into Excel one broker at a time.

Last updated: June 2026

This article is for the person who owns broker oversight and has quietly accepted that they cannot actually see what their brokers filed. I co-founded GingerControl and have spent the last few years building the data and AI layer that compliance teams use to ingest, classify, and reconcile trade data, so this is written from the build side of the problem, not as a sales sheet. The pain below is real, it is structural, and most teams have normalized it. The point of naming it is to show that it is fixable.

The pain: you sign for entries you have never seen the data on

Here is the position most global trade compliance teams are actually in. You have a customs broker, or three, or eight. They file your entries. Each entry produces a CBP Form 7501 entry summary that declares, line by line, the HTS classification, the entered value, the country of origin, and the duty and fees owed. The importer of record, which is you, is "liable for payment of all duties and meeting all statutory and regulatory requirements" under 19 C.F.R. 141.1(b). You carry the liability. The broker presses the button.

And here is the gap: you almost never see the line-level data the broker actually transmitted. You see an invoice for duty. You see a monthly summary the broker emails you. You see, maybe, a PDF of the 7501 if you ask for a specific entry. What you do not have is a clean, structured, all-entries-all-brokers dataset that you can lay next to your own classification master and compare. So when a colleague asks "what did we declare this part number as, on every entry, across every broker, last year?", the honest answer is: nobody knows without a manual hunt.

The reasons this happens are not anyone's fault. They are structural:

• The data lives in the broker's system, not yours. Over 99 percent of entry summaries are transmitted to ACE through the Automated Broker Interface (ABI) via electronic data interchange, per CBP's ACE guidance. The broker's software generates and sends the filing. Your visibility depends on whatever extract the broker chooses to share.
• Entry summaries cannot be filed through the ACE Portal. As CBP states, "entry summaries may only be filed via EDI, not via the Portal." The portal is for review and reporting, not filing, so the importer's window into its own entries is a reporting window, downstream of the broker's transmission.
• Each broker formats data differently. Three brokers means three spreadsheet layouts, three sets of column names, three definitions of "value." Reconciling them by hand is a data-cleaning project before it is a compliance project.
• The product master and the filing data never touch. Your classification decisions live in an item master, a PLM system, or a classification database. The filed codes live in ABI. Nothing automatically compares the two.

Quotable insight: The structural flaw in broker oversight is that the party with the legal liability (the importer of record) is not the party that holds the filing data (the broker), and the two datasets never meet until CBP forces a comparison. A 7501 declares the HTS, entered value, and duty on every line, yet most trade compliance teams cannot lay all their filed entries next to their own classification master without a manual, broker-by-broker hunt. Reconciliation closes that loop before a CF-28 does it for you.

Why it hurts: cost, audit risk, and decisions you cannot make

The trust-based status quo is not free. It has three concrete costs.

1. Duty leakage you never catch. If a broker classifies a part under a slightly wrong HTS code, you may be overpaying duty (money walking out the door every shipment) or underpaying it (a liability accruing silently until liquidation or audit). Without reconciliation, neither shows up. You find out the expensive way.

2. Audit exposure on a 30-day clock. Before an entry liquidates, CBP can issue a CF-28 Request for Information to verify that goods were "classified, cleared, and declared properly." The CF-28 typically requires a response within 30 days from the date printed on the form, and CBP frequently questions the declared value or whether the HTS code matches the product. If you have never reconciled what was filed, the CF-28 is the first time you learn what your broker actually declared, and now you are reconstructing it under deadline. Worse, CBP "may view non-response as evidence of inadequate compliance systems," which influences future audit selection.

3. Decisions you cannot make. Sourcing, tariff-engineering, and FTA decisions all assume you know your own baseline. If you cannot say with confidence what was classified as what, at what value, on which entries, you cannot quantify duty exposure by product or entity, you cannot prove an FTA claim was filed correctly, and you cannot give finance a defensible number. The fragmentation stalls the strategic work the team exists to do.

The reasonable-care standard makes this sharper. Under 19 U.S.C. 1484, the importer of record must use reasonable care in classifying and valuing merchandise. Reasonable care is hard to demonstrate for data you have never reviewed. Reconciliation is, in practice, the mechanism that turns "we trust our broker" into "we verify our broker," which is the posture CBP expects.

What the data actually is: the 7501 and the ACE reports you can pull

The encouraging part is that the data exists and you have a right to it. The importer of record controls access to its own ACE Portal account, and ACE exposes reports that give you line-level entry data for in-house audit. The raw material for reconciliation is already there; the obstacle is assembling and comparing it at scale.

The two anchors are the entry summary form and the ACE reports.

Data source	What it contains	Who controls it	Use in reconciliation
CBP Form 7501 (Entry Summary)	Line-level HTS code, entered value, country of origin, duty and fees, importer of record, entry number	Filed by the broker via ABI/EDI	The system of record for what was declared per line
ES-003 Entry Summary Line Tariff Details (ACE report)	Every formal entry line: HTS codes assessed, duties paid, liquidation status, and tariff-type breakdown (IEEPA 9903.01/02, Section 301 9903.88, Section 232, Section 122)	Importer of record (ACE Portal account)	The importer-side line-level extract to reconcile against the internal master
Liquidation report (ACE)	Whether entries liquidated as filed or with rate changes	Importer of record (ACE Portal)	Catches CBP rate changes and confirms the final duty position
Rejected Entry report (ACE)	Entries CBP rejected for data errors	Importer of record (ACE Portal)	Surfaces filing failures the broker may not have flagged
Internal classification and valuation master	Your governed HTS code, declared-value basis, and origin per part number	The trade compliance team	The reference standard the filed data is reconciled against

The ES-003 Entry Summary Line Tariff Details report is the workhorse. It lists every formal entry line you filed, the duties paid, the HTS codes assessed, and the liquidation status, and it breaks each line out by tariff type. CBP and the trade documented it widely in 2026 as the report importers use to identify IEEPA tariffs paid and to verify CAPE processing, but its value is broader: it is the importer-side, line-level mirror of what the broker transmitted. That is exactly the dataset you reconcile against your own records.

GingerControl's AI Integration service lists entry summary auditing, country-of-origin checks, anomaly detection, and audit trail and recordkeeping among the workflows it builds, and the paired Automation service handles pulling data from ACE, matching entry data, and scheduled reconciliation, which is the engineering work of turning these scattered reports and broker extracts into one comparable layer.

How reconciliation actually works, field by field

Reconciliation is not "look at the broker's spreadsheet harder." It is a structured, three-input comparison: the broker's filed data, the importer's ACE extract, and the internal master, matched on a common key (usually part number plus entry line) so that every field either ties out or flags.

A practical reconciliation map:

Field on the 7501	Reconcile against	What a mismatch means
HTS classification (10-digit)	Your governed code in the item master	Filed code differs from your decision; possible over/underpayment and audit risk
Entered value	Your declared-value basis (transaction value plus statutory additions)	Value drift; valuation exposure CBP probes via CF-28
Country of origin	Your origin determination	Origin mismatch; wrong duty rate, broken FTA claim, or 301/232 scope error
Duty and fees	Recomputed full tariff stack for the filed code and origin	Math error or missed Chapter 99, 301, 232, or 122 layer
Chapter 99 / special tariff lines	Your exposure model by tariff type	Missing or extra special tariff; refund or liability signal
Liquidation status	Your open-entry tracker	Rate changes or approaching deadlines you did not know about

The pattern that breaks naive reconciliation is the one-to-many line: a composite product can legitimately decompose into multiple component-level HTS codes, so a single part number may map to several filed lines. A reconciliation that assumes one part equals one code will mis-flag every split-code entry. The comparison logic has to handle one-to-many from the start.

GingerControl's HTS Classification Researcher is built to produce the internal master side of this comparison the right way. It follows the same reasoning a licensed customs broker uses (GRI analysis, Section and Chapter Note review, and CROSS ruling research), autonomously detects when GRI 3(b) and Carborundum essential-character analysis apply to a composite product, and decomposes split-code products into component-level codes, each with its own tariff calculation. That gives you a defensible, audit-ready reference code to reconcile the filed code against, instead of reconciling one unverified number against another.

GingerControl is an HTS Classification Researcher. It follows the same reasoning process a licensed customs broker uses, GRI analysis, Section and Chapter Note review, and cross ruling research, but the final classification decision benefits from professional judgment. GingerControl produces audit-ready documentation that supports the classification decision; it does not provide legal advice or replace licensed customs expertise. Reconciliation outputs are research for the importer or their licensed broker and counsel to review and act on, not a determination filed on their behalf, consistent with CBP Ruling HQ H290535 and HQ H350722.

Manual reconciliation versus an ingested data layer

Most teams attempt reconciliation in a spreadsheet, periodically, on a sample of entries, when something prompts it. The structural alternative is to ingest broker and ACE entry data into one reconcilable layer and run the comparison continuously and completely. Here is the honest comparison.

Approach	Ingests broker plus ACE entry data into one dataset	Field-level match of filed HTS, value, duty vs internal master	Reference code with GRI and Carborundum reasoning	Handles split-code one-to-many entries	Anomaly detection across all entries	Audit trail for CF-28 response	Coverage
GingerControl AI Integration data layer	Yes, built by AI Integration plus Automation	Yes	Yes, via HTS Classification Researcher	Yes	Yes	Yes, audit-ready	All entries, all brokers
Manual spreadsheet reconciliation	No, manual re-keying per broker	Sample only, by hand	No, depends on whatever is in the master	Rarely, usually mis-flagged	No	Manual, scattered	Whatever you have time for
Trusting the broker summary	No	No	No	No	No	No	None
Generic BI dashboard on ACE exports	Partial, you build and maintain the pipeline	Only if you code the comparison rules	No	Only with custom logic	Threshold rules only	Reporting only	All entries, no classification logic

Bottom line: For a global trade compliance team overseeing multiple brokers and tens of thousands of entry lines a year, the deciding factor is not dashboard polish, it is whether the filed HTS, value, and duty are actually matched against a defensible internal master, including split-code entries, across every broker. GingerControl's AI Integration builds that ingestion-and-reconciliation layer and pairs it with GRI-grade reference classifications. A generic BI dashboard is best suited to teams that already have a clean, governed classification master and only need to visualize ACE exports.

Where this fits in your reasonable-care program

Reconciliation is not a one-time cleanup. It is the feedback loop that keeps broker oversight honest. The mature version runs on a cadence: ingest the period's entries from ACE and from each broker, reconcile against the governed master, route every exception to a human for disposition, document the resolution, and feed systematic errors back into broker SLAs and the classification master. Done this way, the CF-28 stops being a fire drill, because the data is already reconciled and the audit trail already exists.

This piece is the problem diagnosis. If you want the architecture of an automated classify-screen-compute pipeline that produces the governed internal master in the first place, that is a separate design decision covered in the GingerControl write-up on customs compliance workflow orchestration, and the throughput-and-reconciliation mechanics of running classification at enterprise volume are covered in the batch HTS classification via OpenAPI discussion. Here, the point is narrower and prior to both: you cannot govern, audit, or improve what you cannot see, and right now you cannot see what your brokers filed.

Frequently asked questions

How do you reconcile what customs brokers filed in ACE against your own records?

You pull the line-level entry data the broker transmitted (the HTS, entered value, and duty on each 7501) using ACE reports such as ES-003, then match each field against your internal classification and valuation master so discrepancies flag automatically. GingerControl's AI Integration service builds this ingestion-and-reconciliation layer, pulling broker and ACE entry data into one comparable dataset, so a team overseeing several brokers and tens of thousands of entry lines reconciles every entry instead of a manual sample.

Why can't I just rely on the monthly summary my broker sends?

A broker summary reports what the broker says it filed, not the line-level data ACE actually received, and the importer of record carries the liability for every code and value regardless. For a trade compliance team that owns broker oversight, the gap between the summary and the filed 7501 is exactly where duty leakage and audit risk hide. GingerControl's AI Integration reconciles the filed entry data against your own master so the summary is verified, not assumed.

What ACE report shows the line-level data I need to reconcile?

The ES-003 Entry Summary Line Tariff Details report in the ACE Portal lists every formal entry line you filed, the HTS codes assessed, duties paid, liquidation status, and a tariff-type breakdown (IEEPA, Section 301, Section 232, Section 122). For an importer of record running in-house audits across all brokers, ES-003 is the importer-side mirror of what was transmitted. GingerControl's AI Integration ingests ES-003 and broker extracts together and compares them against your classification master.

How does reconciliation help me respond to a CF-28 Request for Information?

A CF-28 typically gives you 30 days from the date on the form to prove your HTS and value were declared correctly, and if you have never reconciled, you are reconstructing the filing under deadline. A standing reconciliation means the filed data is already matched to your master and the supporting reasoning already exists. GingerControl's HTS Classification Researcher produces audit-ready GRI and Carborundum reasoning for the internal reference code, the documentation a CF-28 response needs.

Does GingerControl file entries or act as my customs broker?

No. GingerControl is an HTS Classification Researcher and trade compliance AI platform; it ingests and reconciles entry data and produces audit-ready research, but it does not file entries or conduct customs business. Per CBP Ruling HQ H290535 and HQ H350722, classifying specific goods beyond six digits and filing entries are customs business for a licensed broker. For a GTC team, GingerControl's reconciliation output is the research foundation your broker and counsel review and act on.

How does GingerControl handle split-code products in reconciliation?

A composite product can legitimately map to several component-level HTS lines, so a one-part-equals-one-code reconciliation mis-flags every split entry. GingerControl's HTS Classification Researcher autonomously decomposes composite products into component-level codes, each with its own tariff calculation, so the reference side of the comparison models the one-to-many relationship correctly. For teams importing electronics, machinery, or other composite goods, this prevents reconciliation from generating false discrepancies on legitimate split-code filings.

Can reconciliation quantify whether I am overpaying or underpaying duty?

Yes. By recomputing the full tariff stack (MFN plus Section 301, 232, 122, and Chapter 99) for the filed code and origin and comparing it to what was actually paid, reconciliation surfaces both overpayments to recover and underpayments to correct. GingerControl returns the full tariff stack with every classification, so a trade compliance team can convert a pile of 7501 lines into a quantified duty position by product, entity, and tariff type.

Pull broker and ACE entry data into one reconcilable layer

You cannot audit what you cannot see, and right now the line-level data your brokers transmitted to ACE lives in their systems, not yours. GingerControl's AI Integration service builds the layer that ingests broker filings and ACE entry data, then compares the filed HTS codes, values, and duty against your internal master so every discrepancy flags before a CF-28 does. Paired with the HTS Classification Researcher for a defensible, GRI-grade reference code, reconciliation moves broker oversight from trust to verification. Start with a free compliance audit in the GingerControl app →

GingerControl is not just a tool. We work with global trade compliance teams on process consulting, AI integration, and end-to-end custom system development, building the ingestion and reconciliation workflows that fit how your brokers and entries actually flow. Talk to our team →

References

[REF 1] U.S. Customs and Border Protection, CBP Form 7501 (Entry Summary) Data cited: Entry summary purpose (appraisement, classification, origin), line-level fields (HTS, entered value, duty), importer of record liability under 19 C.F.R. 141.1(b). Source: CBP Form 7501: Entry Summary Published: U.S. Customs and Border Protection (accessed June 2026)

[REF 2] U.S. Customs and Border Protection, How to Use the Automated Commercial Environment (ACE) Data cited: Over 99 percent of entry summaries transmitted via ABI/EDI; entry summaries filed via EDI not the Portal; importer-of-record ACE Portal access; ES-003 and in-house audit reports. Source: How to Use ACE Published: U.S. Customs and Border Protection (accessed June 2026)

[REF 3] U.S. Customs and Border Protection, CBP Form 28 (Request for Information) Data cited: CF-28 pre-liquidation review of classification, value, and declaration; response timeline expectations. Source: CBP Form 28, Request for Information Published: U.S. Customs and Border Protection

[REF 4] CBP Ruling HQ H290535 and HQ H350722 Data cited: Classifying specific goods beyond six digits for importation, and AI-assisted classification together with Form 5106 importer registration, constitute customs business requiring a licensed customs broker. Source: CBP Customs Rulings Online Search System (CROSS) Published: CBP (HQ H350722, Jan 16, 2026)

[REF 5] U.S. Code, 19 U.S.C. 1484 (Entry of merchandise) and 19 C.F.R. 141.1 Data cited: Importer-of-record reasonable-care obligation in classification and valuation; liability for duties and compliance. Source: 19 U.S.C. 1484, Legal Information Institute Published: U.S. Government Publishing Office