Handling Missing Information and Exceptions in TSS Declarations

Exceptions Are Normal, Not Failure

An automated TSS workflow that never raises an exception is either running on trivial volumes or is not really validating. Missing details, unclassified products and unusual movements are part of the working day. What matters is how cleanly they are handled.

Common Exception Types

• Missing field: a required value has not been extracted or supplied.
• Cross-document mismatch: weights or values do not agree across documents.
• Unknown product: a good has never been classified before.
• Rejection on submission: TSS returns an error that needs investigation. Each type has its own owner and its own resolution path. See how the loop is designed in Managing Automated TSS Declaration Workflows.

Design Choices That Help

• Present the exception with all surrounding context, not just a code.
• Route by type to the person or team best placed to resolve it.
• Track ageing so nothing quietly sits past a deadline.

• Feed resolutions back so recurring exceptions become rules.

  What Not to Do

• Do not silently retry rejections.

• Do not hide missing information behind default values.

• Do not treat exception handling as an afterthought designed only after go-live.

See exception routing built into a live TSS workflow and Watch a demo of iCustoms.