How to Automate TSS Declarations: A Practical Guide
- John Hall
- Customs Specialist at iCustoms.ai
You automate TSS declarations by connecting the systems that already hold your trade data to the submission channel TSS provides, and putting extraction, validation and exception handling in between. The government service stays exactly where it is. What changes is that nobody retypes a commercial invoice into a portal.
This guide walks the full TSS submission workflow, stage by stage, and is equally clear about the parts that cannot be automated. Those parts matter, because pretending otherwise is how automation projects lose the trust of the people who have to live with them.
What automating a declaration actually means
Start by narrowing the claim, because the phrase gets used loosely.
You are not replacing TSS. You are not changing what the customs rules require. You are not removing anyone’s legal responsibility. The declaration still has to contain the same information, the deadlines are identical, and the trader still answers for accuracy.
What you are automating is the movement of information: getting data out of documents and systems, checking it, structuring it correctly and submitting it without a person typing each field. That is a narrower claim than most marketing makes, and it is the one that survives contact with a real operation.
The honest scope
Automation changes how the data gets to TSS. It does not change what the data has to be, when it is due, or who is accountable if it is wrong. Anyone telling you otherwise is selling something they cannot deliver.
Where the time actually goes today
Before designing anything, count what a single consignment costs you now. Most teams have never done this, and the answer usually reorders their priorities.
Take one routine movement and track it:
- How many separate documents arrive, from how many senders, in how many formats?
- How many times is the same fact typed? A weight typically appears on the packing list, in the declaration and again on a movement record.
- How many people touch it before submission?
- How many times does someone stop to look something up, chase a missing certificate or ask a supplier what an item actually is?
- How long between the documents arriving and the declaration being ready?
Do that for five consignments and the pattern is usually obvious. Automating Northern Ireland customs declarations pays back where the same fact is retyped repeatedly and where waiting for missing information dominates the elapsed time. It pays back far less where every consignment is genuinely different.
This baseline also gives you something to measure against later, which matters more than it sounds. Without it, any claim about improvement is unprovable, including your own.
The automated declaration workflow, stage by stage
Six stages. The document to declaration workflow runs top to bottom, and each stage feeds the next.
1. DOCUMENTS AND DATA IN
Invoices, packing lists, transport docs, ERP, WMS, TMS
↓
2. EXTRACTION
Read the documents, pull out the fields
↓
3. VALIDATION
Completeness, consistency, format, rules
↓
4. ENRICHMENT
Codes, weights, parties, references
↓
5. SUBMISSION
Structured data sent to TSS
↓
6. STATUS AND EXCEPTIONS
Accepted, rejected, routed to a person
Stage 1: Documents and data in
Customs data arrives in two very different shapes. Structured data sits in your ERP, WMS or TMS, already in fields. Unstructured data arrives as commercial invoices, packing lists and transport documents, usually as PDFs or scans attached to emails.
Most operations have both, and the unstructured half is where the manual hours go. A system that only reads your ERP solves the easier problem.
Stage 2: Extraction
Reading the documents and pulling out the fields a declaration needs: parties, goods lines, quantities, weights, values, currency, origin, references.
This is the stage that has changed most in recent years. It is also the stage where accuracy expectations need to be realistic. Extraction should be measured, checked and corrected, not assumed.
Our work on intelligent document processing covers how extraction handles the variation between one supplier’s invoice layout and another’s.
Stage 3: Validation
The stage that earns its place. Validation asks whether the data is usable before anything is submitted:
- Is every mandatory field present for the declaration type being used?
- Is the commodity code valid, and does it have the right number of digits for the goods category?
- Do the weights and quantities reconcile across the document set?
- Is the goods description specific enough to identify the goods?
- Where Category 2 goods are involved, is the required licence or certificate declared?
- Do the parties and their identifiers match the records held?
Catching a problem here costs minutes. Catching it after submission costs a rejection, and catching it at the port costs a sailing.
Stage 4: Enrichment
Filling in what the source documents do not carry. A supplier’s invoice rarely includes a commodity code, and it never includes your authorisation numbers.
Enrichment draws on what you already know: previously used codes for the same product, party records, standing references. Where you move the same goods repeatedly, the goods profile TSS holds can pre-populate a good deal of this.
Stage 5: Submission
Structured, validated data goes to TSS. The API accepts declaration data and returns confirmation or errors in JSON, which is what makes this stage unattended rather than merely quicker.
A useful detail here: submissions can be built progressively. A system can send what it has, stop, and add more later, which matches how real consignments come together as details firm up through the week.
The technical picture, including access, the test environment and what the interface actually accepts, is in our guide to the TSS API.
Stage 6: Status and exceptions
The stage most first attempts underestimate.
Every submission returns an outcome. Accepted ones need recording. Rejected ones need routing to a person who can act, with enough context that they are not starting from scratch. Anything sitting unresolved needs to be visible before a deadline turns it into a problem.
An automation that files cleanly but handles rejections badly is worse than a careful manual process, because the failures are quieter.
What can be automated, and what cannot
| Task | Automatable | Why |
|---|---|---|
| Reading a commercial invoice | Yes | Extraction handles repeated document shapes well |
| Reconciling weights across documents | Yes | A rules check, not a judgement |
| Reusing a commodity code for a known product | Yes | Look-up against your own history |
| Choosing a code for a genuinely new product | Assisted, not automated | Classification is an interpretive decision with liability attached |
| Deciding whether goods are at risk | No | A commercial and legal judgement resting on evidence you hold |
| Submitting the declaration | Yes | The channel exists and is documented |
| Handling a rejection | Partly | Route and explain automatically, decide manually |
| Answering for accuracy | No | Responsibility does not transfer to software |
The two rows marked no are not technology limitations that will disappear next year. They are decisions with legal consequences, and they belong to a person.
A realistic sequence for getting there
Businesses that succeed at TSS declaration automation rarely do it in one step. The pattern that works:
- Fix the data question first. Decide where the authoritative commodity code lives, who owns party records, and which document is the source of truth for weights. Skip this and everything downstream inherits the ambiguity.
- Automate one lane. Pick your highest-volume, most repetitive customer or product line. Prove the workflow on something that repeats.
- Run parallel. For a period, produce declarations both ways and compare. It is the only honest way to find out what the automation gets wrong.
- Design the exception path before you scale. Who sees a rejection, within what time, and with what authority to fix it.
- Widen lane by lane. Each new one surfaces its own edge cases.
- Measure and keep measuring. Acceptance rates drift when suppliers change document formats.
How long does it take?
Honestly, it depends far more on your data than on the technology.
A business with clean product records, a stable supplier base and consistent document formats moves quickly. A business where commodity codes live in three spreadsheets and one person’s memory will spend most of the project on that problem, whatever software they buy. The integration is rarely the long pole.
How to tell whether it worked
Pick measures that would embarrass you if they went the wrong way.
- First-time acceptance rate. What proportion of submissions are accepted without amendment?
- Touch count. How many human interventions does an average declaration need?
- Time from document received to submission ready.
- Exception ageing. How long do rejections sit before someone acts?
- Deadline performance. What proportion of supplementary declarations are filed well before the tenth of the following month, rather than on it?
- Volume per person. The measure that tells you whether you can take on more work without hiring.
Avoid headline percentages you cannot reconstruct. If you cannot explain how a number was calculated, it will not survive its first challenge from finance.
Where automation projects fail
Automating a broken process
If the manual process produces errors, automating it produces the same errors faster and in greater volume. Fix the process first.
No owner for exceptions
Rejections need a named person and a time limit. Without both, they accumulate.
Trusting extraction without validation
Extraction is a reading step, not a checking step. The two are different jobs and both are needed.
Skipping the parallel run
Going straight to live means discovering the failure modes in production, on real deadlines.
Treating it as an IT project
The hard decisions here are customs decisions. If the customs team is not driving it, the result will be technically sound and operationally wrong.
Many of these show up first as recurring mistakes in manual entry. We look at that pattern separately in reduce TSS data-entry errors, and at the data groundwork in preparing customs data for TSS.
Build, buy, or neither
Three routes to an automated customs workflow, and volume usually decides which is right.
- Neither. Low volume, stable, no real pain. The portal is free and adequate. Do not automate for the sake of it.
- Build. You have development capability, unusual requirements and the appetite to maintain it as the guidance changes. Remember that maintenance is the commitment, not the build.
- Buy. Most businesses. Someone else keeps pace with the reference documents and the regulatory changes, and you keep your people on customs decisions.
If you are weighing the options, our overview of Northern Ireland customs automation sets out how the layer in front of TSS fits together, and where AI reduces manual declaration work covers what the newer techniques genuinely change.
Frequently Asked Questions
You may also like:
Struggling to Extract, Catagorise & Validate Your Documents?
Capture & Upload Data in Seconds with AI & Machine Learning
Subscribe to our Newsletter
About iCustoms
iCustoms is an all-in-one solution helping businesses automate customs processes more efficiently. With AI-powered and machine-learning capabilities, iCustoms is designed to streamline your all customs procedures in a few minutes, cut additional costs and save time.
Struggling to Extract, Catagorise & Validate Your Documents?
Capture & Upload Data in Seconds with AI & Machine Learning