DEV Community

Cover image for TSS Declaration Field Validation: A Technical Reference for Ten Common Errors
Kristi Hampson
Kristi Hampson

Posted on

TSS Declaration Field Validation: A Technical Reference for Ten Common Errors

TSS declarations are a structured data problem. Each rejection has a specific field, a specific rule, and a specific validation that would have caught it.

Field-Level Failure Points

Vague goods descriptions fail free-text validation. Entry summary declarations run a stop-word list rejecting values like "goods" and "gifts." Commodity codes at eight or ten digits require an annual freshness check against the current tariff. Document codes at DE 2/3 must be present, unique per record, correctly paired with reference details and status codes, and consistent with the Tariff Requirements for the commodity.

Weight fields — gross mass, net mass, package count, supplementary unit — must reconcile against each other and against the invoice, packing list, and transport document. Currency and value fields require the customs value calculation, not the invoice total. EORI fields need format and check-digit validation to catch transpositions. The TSS data entry errors reference enumerates each field with examples.

What Validation Can and Cannot Do

Automated validation handles the mechanical layer: presence, format, cross-reference, arithmetic, and freshness. It cannot evaluate whether a description is honest, whether a preference claim is substantiated, or whether goods risk classification is correct. The split between mechanical and judgment work drives where automation adds value.

See the validation stack running against live TSS submissions. Watch a demo of iCustoms.

Top comments (0)