TSS Portal validation rules are deterministic checks that confirm a customs declaration's structure: required fields are present, codes exist, formats match and references resolve. They cannot test semantic correctness. A valid commodity code can still be the wrong code for the goods, which is why a content validation layer before the Portal matters.
How the Portal's rules are layered
Validation runs at two scopes:
- Field level: some checks fire as each field is filled in.
- Declaration level: others run across the whole declaration before submission. The rule set covers six types: format and completeness, goods-line business rules, consignment-level checks, item-level controlled goods, CERTEX certificate matching, and scheme and authorisation checks.
What a rule can and can't assert
A rule can assert presence, existence, format and reference. It can't assert truth, which is why three classes of error pass the TSS Portal validation rules untouched.
| Error | Why the rule passes it |
|---|---|
| Wrong commodity code for the goods | The code exists and is current |
| Certificate that doesn't cover the consignment | The reference matches the expected format |
| Description too vague to classify | The field is complete |
Adding a content validation layer
Think of the workflow as a pipeline with two validation stages:
declaration
-> content validation (before the Portal)
commodity code vs goods description
certificate ref vs certificate data
preference claim vs evidence on file
-> TSS Portal rules
format, completeness, goods-line, consignment,
controlled goods, CERTEX, scheme/authorisation
-> submission
AI-powered validation handles the first stage by reading content instead of checking format. The Portal then handles the second.
Why order matters
Automating submission without validating first produces wrong declarations faster. Catching an error upstream costs less than handling a rejection downstream.
Want to see a content validation layer running ahead of TSS? Watch a demo.
Top comments (0)