Two documents, one shipment
A customs entry summary and a commercial invoice describe the same underlying transaction from two different vantage points — one built by your broker for filing purposes, one written by your supplier for commercial purposes. They're supposed to agree, but nothing forces them to be checked against each other automatically.
This page describes how those two documents are read and matched line by line, no matter how many other shipments sit alongside them — the same logic described more broadly in customs and import documentation, applied here specifically to the comparison between what was declared and what was invoiced.
This distinction between trusting an entry and verifying it against source paperwork sounds obvious once stated, but it's exactly what gets skipped in a manual process — an entry filed correctly by the broker's own logic, never actually checked against the invoice it was supposed to be based on.
Why this isn't trivial
The problem isn't checking one shipment in isolation — that's straightforward. The problem is dozens of shipments a month, each with its own invoice and entry summary in a different format, where a value drifting by a small percentage doesn't show up unless every line is actually compared.
Treating the entry summary's total as sufficient on its own misses exactly the failure mode that matters most: a per-line value that shifted somewhere between the invoice and the filing, hidden inside a total that still looks broadly correct.
What gets read from each side
| Field | From the entry | From the invoice |
|---|---|---|
| Declared value | Per line, as filed | Per line, as billed |
| HS code | As classified for filing | As stated, if present |
| Country of origin | As declared | As stated on the invoice |
| Quantity | As entered | As invoiced |
Four fields, read from both sides independently and then compared — not a single total checked against another total, but each field anchored to its own line and its own source document on both sides of the comparison.
Where this shows up in practice
| Situation | What changes |
|---|---|
| Freight allocated inconsistently between the two documents | Distinguished by comparing the Incoterm-adjusted values, not raw totals |
| A currency conversion applied at slightly different rates | Flagged if the resulting variance exceeds a reasonable rounding tolerance |
| An entry summary in an unfamiliar broker's export format | Read the same way, based on structure rather than a known layout |
| A shipment split across two partial entries | Each entry matched against its own portion of the invoice |
Four common situations, none requiring separate configuration — the same method applies to all of them, because it reads document structure and context rather than recognizing a fixed list of expected cases in advance.
From reading to matched lines
Once both documents are read, each entry line is evaluated against the candidate invoice lines it could plausibly correspond to — not in isolation, but in the context of the whole shipment and, where available, prior shipments from the same supplier.
A line where value, HS code and quantity all align closely earns a high confidence match. A line where only one of those signals lines up is retained rather than matched on presumption alone.
Confidence and what gets flagged
Not every match carries the same certainty, and treating them all the same would hide exactly the lines that deserve a second look. Every candidate match gets a confidence level, and anything below a high threshold is flagged for review rather than accepted silently.
This matters most for the lines that actually cause problems later — a value that's close but not exact, or a line with no clear counterpart on the other document at all. Flagging them explicitly means a person makes the final call, instead of a system silently picking an option that could be wrong.
How it works
Upload the entry and invoice
One shipment's paperwork, or a batch of several shipments at once.
Each document is read
Value, HS code, quantity and country of origin, for each line on both sides.
Lines are matched with a confidence level
Each candidate match evaluated on multiple combined signals.
Export
Excel, CSV or JSON, with matched and flagged lines kept as distinct groups.
A reconciliation, in practice
One customs entry, 24 line items, checked against the supporting commercial invoice.
| Result | Line items |
|---|---|
| Matched, high confidence | 21 |
| Rounding difference, resolved | 2 |
| Genuine mismatch, flagged | 1 |
24 line items, one genuine mismatch — a value roughly 12% higher on the entry than the invoice supported, traced to a freight allocation applied twice. Caught during routine reconciliation, before the duty payment on that entry could be disputed after the fact.
When an entry gets amended after filing
A customs entry isn't always final the day it's filed. A broker may submit a post-entry amendment to correct a value, a classification or a country of origin — sometimes at the importer's request, sometimes because the broker or the customs authority caught something after the fact. Whatever the reason, the reconciliation needs to reflect the entry as amended, not the version that was originally filed.
Treating an amendment as simply a new entry to reconcile from scratch loses the history of what changed and why — which matters if the same question comes up again during a later audit. Keeping both the original filed value and the amended value, with the amendment itself dated and attached, preserves that history instead of overwriting it.
In practice this means a reconciliation record can carry more than one entry-side value for the same invoice line over its lifetime. That's expected, not a sign of an error — the goal isn't a single static match but an accurate record of what was declared, when, and against what supporting value at each point.
Manual vs. automatic
Manual
Someone eyeballs the entry summary's total against the invoice total — fast when they roughly match, a source of missed errors the moment a per-line discrepancy is hiding inside a correct-looking sum.
Automatic
Every line is checked systematically against multiple signals, so no mismatch gets buried inside a total that happens to look correct.
From one entry to a full year
Reconciling one entry against its invoice is quick. Doing it for a full year of shipments, across dozens of suppliers, changes what's actually practical by hand — not because any one shipment is harder, but because trend comparison across the year becomes the real goal, and that comparison requires every entry to have been checked the same way from the start.
A history built entry by entry, with matched lines and confidence levels, makes that comparison possible immediately, instead of becoming a separate project every time finance wants to see whether a supplier's declared values have drifted over time.
Who uses this
Import finance teams
Verify duty paid against invoiced value without reopening every entry by hand.
Customs brokers and their clients
Confirm filed entries against the original invoice before a dispute or audit.
Distributors managing many suppliers
Track whether declared values stay consistent across a large supplier base.
Finance teams preparing for a customs audit
Produce a traceable reconciliation record ahead of time, not during the audit itself.
Four different profiles, but the same underlying need: a reliable, consistent matching that doesn't depend on who reviews the entry or which broker's format the filing happens to use.
Edge cases worth knowing
An entry value that coincidentally matches a different invoice's line at the same amount is exactly the kind of case that can look more difficult than it is — combining value with HS code, quantity and country of origin almost always resolves it, without assuming that a matching value alone designates a match.
A shipment split across two separate customs entries — common with large orders — is never merged or split by assumption. Each entry is matched against its own portion of the invoice, with the split itself flagged for review if it isn't already clearly documented.
When it points to an overpayment
A reconciliation that surfaces an entry declared at a higher value than the invoice supports isn't just a documentation gap — it can mean duty was overpaid on that shipment, which may be recoverable depending on your jurisdiction's rules around duty correction or refund claims.
This reconciliation doesn't determine whether a refund is available or file any claim — that's a question for your customs broker or trade counsel. What it does is surface the discrepancy clearly enough, with the supporting documents attached, that asking the question becomes straightforward rather than a research project on its own.
Why a flagged line beats a guessed one
A view that only shows matched totals, without keeping the reasoning behind each match, is convenient to browse but fragile the moment someone asks why a specific entry line was matched to a specific invoice line. Reconstructing that reasoning later, without it already in place, means reopening the full shipment paperwork and starting over.
Keeping the confidence level from the start — every match knowing whether it rests on a strong or only partial correspondence — turns that reconstruction from a future emergency into a detail already present in the data. The difference shows up at exactly the worst moment to discover it: during a customs audit, when response time is already limited.
This principle doesn't change with scale. Whether it's a single entry or a multi-year archive, the same rule applies without exception: every matched line needs to be able to justify, in a few clicks, the reasoning that produced it.
How long the trail needs to survive
Most jurisdictions give customs authorities a multi-year window to reopen an entry for review — often five years or more from the date of entry, depending on the country. A reconciliation built to answer today's question and then discarded doesn't hold up against that window; the record needs to still be retrievable well after the shipment itself is a distant memory to everyone involved.
That retention requirement is part of why the reconciliation is kept as a structured, exportable record rather than a one-time comparison that exists only inside a review session. A spreadsheet built for last quarter's audit and never touched again is exactly the kind of artifact that's hard to trust three years later — file paths change, the person who built it moves on, and the reasoning behind a specific match is rarely written down anywhere durable.
A record that keeps both sides of every match, the confidence level and a link back to the original source document survives that span without depending on anyone's memory of how it was built.
Comparing this year to last
A single month's reconciliation answers whether this month's entries match this month's invoices. A question that comes up less often but matters more — whether the overall rate of discrepancies is improving, staying flat, or getting worse — needs the same records compared across periods, not just checked one at a time.
That comparison is only possible if every prior month's reconciliation is still sitting somewhere consistent and comparable, in the same structure, rather than scattered across whatever format happened to be convenient at the time. A rising discrepancy rate across several quarters is often the first sign of a supplier relationship or a broker process worth revisiting before it becomes a bigger problem at audit time. A falling rate is worth noticing too — it's the clearest evidence that a process change actually worked, rather than a general impression that things feel more under control lately. Neither reading is available from a folder of individually accurate but disconnected monthly reviews — it takes the same structure repeated consistently, month after month, for the trend itself to become visible rather than staying buried inside twelve separate one-off checks.
What it doesn't do
Doesn't decide a mismatch alone
Identifies the most likely matches and flags ambiguous cases — final confirmation comes from checking against actual shipment records.
Doesn't calculate what duty should have been
Reads the values that were actually filed and invoiced — the correct duty calculation is a broker function.
Doesn't file corrections or refund claims
Surfaces a discrepancy clearly. Acting on it — a correction, a refund claim — stays with your broker or trade counsel.