Extracting Declared Value and Duty Fields From a Customs Form

“Declared value” is not a quantity you can extract on its own. It is a quantity defined by a three-letter code somewhere else on the form, and reading one without the other produces a number that is confidently wrong by the cost of the freight.

The delivery term is part of the value

The three-letter codes on a purchase order or commercial invoice — EXW, FCA, FOB, CIF, DAP, DDP and the rest — are Incoterms rules, published by the International Chamber of Commerce. There are eleven in the current revision. Seven apply to any mode of transport (EXW, FCA, CPT, CIP, DAP, DPU, DDP) and four apply only to sea and inland waterway carriage (FAS, FOB, CFR, CIF). They allocate cost and risk between seller and buyer, and the allocation of cost is what makes them part of the value field: an invoice on CIF terms has international freight and insurance inside the invoice total, and an invoice on FOB terms does not.

The rules are revised, and the revision is part of the term. Incoterms 2020 is the current publication and it is not backward-compatible in vocabulary: the 2010 term DAT, delivered at terminal, was replaced in 2020 by DPU, delivered at place unloaded, which applies to any place rather than only a terminal. So a document reading “DAT” is either citing the 2010 rules or has copied a term that no longer exists in the revision it names. Extracting delivery_terms: "DAT" with no revision field records neither possibility.

Extract the term and the cited revision as two fields, and treat a bare term with no revision as incomplete rather than as the current one. A contract may legitimately incorporate Incoterms 2010 or an earlier edition; the parties choose. There is also a genuinely different meaning in play for one term — “FOB” in United States domestic practice descends from the Uniform Commercial Code and is not the ICC rule of the same name.

Two countries, two bases, one invoice

The customs value is not simply the invoice total. Under the WTO Agreement on Implementation of Article VII of the GATT, the primary method is transaction value — the price actually paid or payable for the goods, with specified additions and deductions. What administrations differ on is whether international freight and insurance are inside that figure. The European Union assesses on a CIF basis, so carriage and insurance to the frontier are in the customs value. The United States generally appraises on an FOB basis, excluding international freight and insurance.

Same invoice, same Incoterm, two different declared values depending on where the goods land. An extraction pipeline that normalises every declaration into a single customs_value field and then compares across countries is comparing two different quantities.

The arithmetic check on the duty line

Where the form shows both a value and a duty, they constrain each other. For an ad valorem rate the relationship is simply value times rate, and that is enough to catch a value read from the wrong column. Worked on assumed inputs — an invoice of 48,000 units of currency on CIF terms, of which 3,200 is freight and 300 is insurance, and an assumed ad valorem rate of 4.4% taken from a tariff schedule rather than from the document:

invoice (CIF)                       48,000.00
  less freight                       3,200.00
  less insurance                       300.00
FOB-basis value                     44,500.00

duty at an assumed 4.4% ad valorem
  on FOB basis   44,500.00 x 0.044 =  1,958.00
  on CIF basis   48,000.00 x 0.044 =  2,112.00

difference                             154.00

If the form states a duty of 1,958.00 then the value being taxed is the FOB figure, and an extraction that returned 48,000 as the declared value took the wrong number. The check runs the other way too: given a stated value and a stated duty, dividing gives an implied rate, and an implied rate that is not a plausible tariff rate means one of the two fields is misread.

The rate and the invoice split above are labelled assumptions used to show the arithmetic. Real rates come from the tariff schedule for the classification and origin, which is why this page and the tariff code page are two halves of one problem.

Three things break the multiplication, and all three are ordinary rather than exotic. A specific duty is charged per unit of quantity — per kilogram, per litre, per dozen — so the value does not enter the calculation at all and the implied-rate check will produce nonsense. A compound duty is both, an ad valorem component plus a specific one. And a preferential rate under a trade agreement replaces the general rate entirely when a certificate of origin is presented, so the duty can be zero against a non-zero value with nothing wrong anywhere. Treat a failed check as a flag for review, not as a rejection.

Currency, rate and date

The invoice currency and the declaration currency are frequently different, and the conversion is not done at today’s rate. Customs administrations publish an exchange rate that applies for a period — typically a quarter or a week depending on the jurisdiction — and the rate that governs is the one in force on the relevant date for the entry, not the date you run the extraction.

So there are four fields where a careless schema has one: invoice amount, invoice currency, converted amount, and the rate with its effective date. If the form shows three of the four, derive the fourth and check it against any printed value. A converted amount that does not follow from the printed rate is the cheapest possible signal that a digit was dropped.

Currency symbols are their own hazard. $ is at least a dozen currencies, and the ISO 4217 code beside it is the field that means something. Where only a symbol is printed, the country of the declaring office usually resolves it, but record that you inferred it rather than read it.

The failures this check will not catch

• Negative numbers in parentheses. Credits, adjustments and rebates on an invoice are frequently printed as (1,250.00). Parsed as a positive, the total stops footing; parsed as text, it disappears. Handle the accounting convention explicitly.
• The decimal comma. A currency amount validation rule has to settle this. 48.000,00 and 48,000.00 are the same amount written in two conventions, and 48.000 alone is genuinely ambiguous. The safest disambiguation is the document’s own other amounts: a form that shows any value with two digits after a separator has told you which separator is decimal.
• The same field twice, differing. Value appears on the invoice, on the packing list and on the declaration, and they can legitimately differ because they are different bases. Record the source of each rather than picking one and discarding the rest.
• Value per line versus value per entry. A multi-line entry has a total that should equal the sum of the lines, which is a cross-field amount validation rule. When it does not, the usual cause is an extracted line count that is short, which is the same running-total problem the manifest page is built around.