TSS API or Manual Portal Entry: Which Is Better?
- John Hall
- Customs Specialist at iCustoms.ai
Neither is better in the abstract. The portal is free, needs no development capability and is entirely adequate at low volume. The API removes manual entry and makes unattended processing possible, but it assumes real IT capability and clean data. Volume, repetition and the state of your product records decide it, not preference.
Most people searching TSS API vs manual entry have already sensed they are on the wrong side of the line and want confirmation. This comparison is written to help you rule one out, which is more useful than being told that both have merits.
The honest answer, up front
Most articles on this subject are written by software companies and conclude that you need software. Here is the version that survives contact with a real operation.
If you file a handful of declarations a month, with a product range that barely changes, manual TSS entry is the right answer. The portal costs nothing, TSS provides guidance and training around it, and an integration project would cost more than it saves. Do not let anyone talk you out of that.
If you file at volume, for multiple customers, with the same facts retyped repeatedly, the portal becomes the constraint on how much work you can take on. At that point the question is not whether to move but when.
The interesting cases sit between those two, and the rest of this article is about how to place yourself.
Side by side
The TSS portal vs API question comes down to eleven practical differences. Cost of the route is the one people get wrong most often.
| Manual portal entry | The API route | |
|---|---|---|
| Cost of the route | Free. TSS is free to use | Also free. TSS does not charge for API access |
| What it costs you | Staff time, per declaration | Development or software, up front and ongoing |
| Capability needed | Customs knowledge | Customs knowledge plus an experienced IT function |
| Speed per declaration | Depends on the person and the day | Consistent once built |
| Data entry | Someone types it | Sent from systems that already hold it |
| Error profile | Transcription errors, varying by workload | Systematic. Right for everything, or wrong for everything |
| Peak handling | Degrades under month-end pressure | Unaffected by workload |
| Unattended running | No | Yes. Responses come back in JSON for your system to act on |
| Time to start | Same day | Weeks to months, mostly spent on data |
| Acting for clients | Yes | Yes. Agents can submit for the traders they represent |
Neither option costs more in fees TSS is free to use, and that includes the API. When people say the API is expensive they mean the build, the software or the internal time, not a charge from the service. Keep those two things separate when you build a business case. |
Where the portal genuinely wins
Any honest comparison of portal entry vs API has to start here, because the portal is the right answer more often than software vendors admit.
Four situations where staying manual is the better commercial decision.
Low or irregular volume
If declarations are occasional, the fixed cost of an integration never amortises. A person doing something twenty times a month is cheaper than a project.
Every movement is different
Automation pays back on repetition. A business where each consignment involves new products, new suppliers and new documents gets far less benefit, because the judgement calls remain wherever the data comes from.
No development capability
Access is aimed at organisations with an experienced IT department. If you have none, and no budget for software that integrates on your behalf, the API is not realistically available to you. That is a legitimate answer, not a failure.
Your data is not ready
This is the one people skip. If your commodity codes live in three spreadsheets and one colleague’s memory, an integration will faithfully transmit that confusion at speed. Fix the product records first, and you may find the manual process becomes tolerable anyway.
Where the API genuinely wins
The same facts, over and over
Repetition is what the API removes. A recurring customer ordering a stable product range is the clearest case, because the data already exists in your systems and a person is copying it across.
Month-end concentration
Supplementary declarations for a whole month are due by the tenth calendar day of the following month. That creates a spike regardless of your average volume, and it lands at the point where careful manual work is hardest. A route that is indifferent to workload has an obvious advantage there.
Unattended processing
Responses come back in JSON, so your system can read the outcome and act on it. That is what makes overnight and out-of-hours processing possible. Nobody has to watch a screen to find out whether a submission landed.
Progressive assembly
The API mirrors the portal in one useful respect: you do not have to send everything at once. A system can add information, stop, and come back and add more. That matches how consignments actually come together, with the invoice on Monday and the weights confirmed on Wednesday.
Acting for many clients
Agents and intermediaries can create, edit and submit declarations on behalf of the traders they represent. If you carry that pattern at scale, doing it by hand across many customers is where the model breaks.
How many declarations justify it?
There is no honest universal number, and anyone quoting one is guessing at your business. Work it out instead.
- Time one declaration end to end, from documents arriving to submission ready. Use a typical one, not your best.
- Multiply by your monthly volume. That is your current cost in hours.
- Estimate what proportion of that time is retyping facts that already exist somewhere. This is the part automation addresses.
- Add the cost of rework: rejections, chasing, and the month-end scramble.
- Compare against the total cost of the alternative, including implementation, integration, training and running parallel.
Two businesses filing the same number of declarations can land on opposite answers, because one has forty products and stable suppliers while the other has four hundred products and documents that arrive in a different shape every week.
The measure that matters most Touches per declaration. Count how many separate human interventions an average movement needs today. If it is one or two, the portal is fine. If it is six, you are paying for the same information to be handled six times, and that is what the comparison is really about. |
Can I use the portal and the API together?
Yes, and plenty of businesses do. Framing API versus portal declarations as a binary choice is the commonest analytical mistake in the whole subject.
Sensible hybrid patterns:
- High-volume recurring customers go through the API; occasional or unusual movements stay in the portal
- Standard goods automated; controlled goods handled by a person
- Everything automated, with exceptions routed to the portal for a human to resolve
- A phased migration, one lane at a time, with both running during the transition
The last one is not a compromise. It is how a competent migration is done. Running parallel is the only reliable way to discover what your automation gets wrong before it matters.
What switching actually involves
Switching from the TSS portal is less of a technical project than people expect, and more of a data one. Worth knowing the shape before you commit.
- Register for access through your TSS company profile.
- Work out where each required field lives in your existing systems. This is the long pole, and it is a customs job rather than a technical one.
- Map your data to the specification.
- Build and test. There is a dedicated test environment, with separate credentials for test and production, so you can iterate before anything is live.
- Test the failures, not just the successes. A test cycle that only exercises clean data tells you nothing about how the system behaves at four in the afternoon before a sailing.
- Design who handles rejections, within what time, with what authority.
- Run parallel, compare, then migrate lane by lane.
Note how little of that is code. Steps two and six decide whether the project succeeds, and neither is a development task.
The technical detail sits in our guide to how the TSS API works in practice, including what it accepts, the item limit per declaration and how access is granted.
What neither option changes
Worth stating plainly, because it is where both sides of this argument tend to overclaim.
- The rules are identical. The same information is required either way.
- The deadlines are identical. Supplementary declarations are still due by the tenth of the following month, however they are produced.
- Accountability is identical. The trader answers for the accuracy of what is declared.
- The judgement calls remain. Classifying a genuinely new product and deciding whether goods are at risk are decisions, not data entry.
The choice is about how information travels, not about what it has to be or who is responsible for it.
The decision, in five questions
- Is the same information being retyped more than twice per movement?
- Does your volume concentrate around the tenth of the month?
- Is your product and party data in one authoritative place?
- Do you have development capability, or budget for software that integrates for you?
- Is declaration throughput limiting the work you can accept?
Three or more yes answers, and the API route is worth costing properly. Fewer than three, and your effort is better spent on data quality and process than on integration.
A no to question three with yes to everything else is the most common position, and the answer there is to fix the data first. It is the cheapest work available and it improves the manual process immediately, whatever you decide later.
If you decide to move
Building it yourself and buying something that already integrates are different projects with different risks. a buyer checklist for customs automation sets out what to ask vendors, and what automation actually changes walks through the workflow either route produces.
If manual entry is currently costing you in rejections rather than hours, common TSS data entry errors is the better starting point, because validation fixes that faster than a change of channel. Intermediaries handling many clients have their own version of this decision, covered in scaling declarations as an intermediary.
Our overview of Northern Ireland customs automation covers how the preparation layer sits in front of whichever route you choose.
Frequently Asked Questions
You may also like:
Ready to Move Beyond Manual TSS Entry?
Reduce repetitive declaration work with iCustoms automation.
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.
Explore a Smarter Way to Manage TSS Declarations
Streamline customs processing while keeping people in control.