Key Takeaways
- NCTS6 is live in the UK: HMRC’s Common Transit Convention Traders roadmap says Phase 6 is now in production, after the UK Phase 2 go-live on 1 June 2026.
- Your readiness check should cover API connectivity, departure and arrival workflows, message retrieval, error handling, print output for the Transit Accompanying Document, and fallback procedures.
- The UK opted out of Transit Security Accompanying Documents at the first stage of NCTS6, so GB and NI operators should not build operating assumptions around IE117 or IE058 for domestic UK transit flows.
- Software providers still need to account for the wider Common Transit Convention environment, because movements can involve EU systems and other contracting parties.
- Treat NCTS6 as an operational control issue, not only an IT upgrade: authorisations, guarantees, master reference numbers, office codes, seals, and arrival processes all need to match the live declaration workflow.
NCTS6 readiness is now a live-service discipline, not a future migration project. HMRC’s Developer Hub says the Common Transit Convention Traders API is in production for NCTS Phase 6, and trade bodies reported the UK Phase 2 go-live date as 1 June 2026. If your transit declarations depend on third-party software, the practical question is no longer whether the new phase is coming. It is whether your software, staff, and fallback controls can handle a live T1 or T2 movement without a manual scramble.
The upgrade matters because transit is unforgiving. A declaration that fails before departure can stop a trailer at the depot. A message that is not retrieved after release can leave planners working from stale status information. NCTS6 adds more structured data and a changed message environment, so “the provider says it is ready” is not enough evidence on its own.
This checklist is written for UK freight forwarders, customs agents, hauliers, importers, exporters, and software owners who use NCTS for Common Transit Convention movements. It focuses on what to ask, what to test, and what to document before you rely on the system for live traffic. If you are also reviewing wider customs systems, keep this alongside your checks for CDS declarations, customs guarantees, and GVMS-linked ferry freight.
What NCTS6 Changes For UK Operators
NCTS is the digital system used for Common Transit Convention movements, including T1 and T2 declarations. It supports the departure, control, and discharge of goods moving under transit, so duty and import VAT are suspended until the goods reach the correct destination or another customs procedure. The convention covers the EU as a contracting party, plus Iceland, North Macedonia, Norway, Serbia, Switzerland, Turkiye, Ukraine, and the United Kingdom.
NCTS6 is the latest phase of that system. Strong & Herd described the UK implementation as a two-step rollout, with a Phase 1 “Migration Pathway” on 1 September 2025 and Phase 2 on 1 June 2026. The second date is the one that matters for live NCTS6 readiness, because it is when the UK moved to the Phase 6 service rather than only applying the earlier transition fixes.
The operational change is not just a new screen layout. NCTS6 aligns the transit process more closely with newer European safety and security data models, including the EU Import Control System 2 environment. That does not mean every UK movement now needs an ICS2-style security filing inside NCTS, but your software must handle current validations and message logic.
For traders, the risk is usually hidden inside the supplier chain. A broker may rely on one customs platform, a haulier on another transport-management system, and a warehouse on emailed PDFs or portal notifications. If those systems do not agree on the movement reference, office status, guarantee use, and arrival actions, the failure appears in operations long after the software release note has been signed off.
The UK TSAD Position
The UK opted out of Transit Security Accompanying Documents at the first stage of NCTS6 implementation. Strong & Herd’s NCTS6 update says the UK chose not to connect to ICS2 through the Transit ENS Data Processing Bridge at that point. That detail matters because it changes which message flows UK operators should expect to use.
Three TSAD-related transit messages are commonly discussed with NCTS6: IE117, IE058, and IE119. IE117 is the Notification of Presentation of Goods at Office of Transit. IE058 is the rejection of IE117. IE119 is the rejection of goods crossing the frontier. In the UK context described in the research notes, IE117 and IE058 are not used for GB or NI transit movements, while IE119 is not used in the same way because GB and NI border processes use the Goods Vehicle Movement Service.
This does not mean your provider can ignore the wider message environment. If your traffic enters or crosses other Common Transit Convention countries, the software may still need to recognise messages from other administrations. A UK operator may not originate a TSAD workflow, but still needs a clean explanation of what a received transit message means.
Ask providers to state their TSAD position in plain language. The answer should separate UK usage from wider CTC compatibility, and it should name the message types rather than saying only that the software is “NCTS6 compliant”. That is the difference between a release headline and an operating control.
HMRC API Readiness Checklist
The first technical check is endpoint separation. The HMRC API catalogue for Common Transit Convention Traders lists the sandbox host as https://test-api.service.hmrc.gov.uk and the production host as https://api.service.hmrc.gov.uk. Your provider should be able to show which environment each tenant, client ID, certificate, or integration credential uses, and how it prevents test credentials or test message handling from leaking into live work.
The second check is full journey coverage. The API is used to send departure and arrival movement notifications to NCTS and retrieve messages from offices of departure and destination, according to the HMRC API catalogue. A system that can submit a departure declaration but cannot show release, control, arrival, or rejection messages in a usable queue is not operationally ready.
The third check is validation before submission. NCTS6 failures should be caught as early as possible, with field-level prompts for missing or inconsistent data. Office codes, guarantee references, previous documents, consignor and consignee data, seals, transport equipment, routing, and goods item detail should be checked before the declaration reaches HMRC.
The fourth check is error handling. Your staff need to see HMRC response messages in business language, with enough technical detail for support teams to diagnose the failure. A generic “submission failed” message is not enough. The system should preserve the original request, the response, the user, the timestamp, and any subsequent correction so that you can prove what happened during audit or dispute review.
The fifth check is document output. NCTS movements still need the right operational paperwork, including the Transit Accompanying Document where applicable. Software should generate the TAD cleanly, with the master reference number, barcode or reference detail, office information, goods data, and routing details matching the accepted declaration. Staff should know which version is valid if a declaration is amended.
Questions To Ask Your Software Provider
Start with a direct version question: “Which NCTS6 release is deployed in our live environment, and when was it certified or tested against HMRC’s production service?” The answer should include a date, an environment, and a clear scope. A statement about development completion does not prove your tenant is using the live-ready build.
Then ask for evidence of end-to-end test cases. You want examples covering standard T1 and T2 departures, arrival notifications, rejected submissions, amendment or correction flows where supported, message retrieval, and user permissions. If your business handles groupage, authorised consignor or consignee workflows, multiple offices, or guarantee-heavy traffic, the test cases should reflect those patterns rather than a single ideal movement.
Ask how the software handles HMRC downtime and local system outages. The Institute of Export and trade advisers highlighted NCTS downtime around the implementation period, and future outages remain a normal operational risk. Your provider should explain queueing, retry behaviour, manual fallback, status reconciliation, and how users can tell whether a message has been submitted, accepted, rejected, or is still waiting locally.
Ask what support team sees when you raise a live incident. The answer should cover logs, correlation IDs, HMRC response payloads, tenant configuration, and user actions. In a live transit issue, you want the provider to trace the declaration state from job creation to the latest HMRC message.
Finally, ask what has not changed. Some providers focus release notes on new NCTS6 capability but leave customers unsure about old features: templates, commodity data, customer master data, guarantee libraries, office favourites, document print settings, and reporting exports. Confirm which existing fields and workflows remain valid, which ones were mapped to new structures, and which ones require user review.
Internal Operational Controls
Your own controls should start with ownership. Name one person or team responsible for NCTS6 readiness, and give them authority to stop live use if evidence is weak. Transit work often spans customs, transport planning, finance, warehouse operations, and customer service. Without a single owner, each team assumes another team has checked the software.
Create a small live-readiness file for each platform or provider. It should record the provider’s NCTS6 confirmation, release date, HMRC environment status, support contacts, known limitations, tested movement types, fallback process, and review date. HMRC’s API catalogue lists SDSTeam@hmrc.gov.uk as the developer contact for the CTC Traders API, but most traders should still route day-to-day software problems through their provider.
Run staff through the live workflow before you need it under pressure. A useful drill is simple: create a representative movement, check the data, submit it in the appropriate environment, retrieve the response, print or view the TAD, identify the MRN, simulate a rejection, and document the correction route. Repeat the drill for export transit, import arrival, groupage, and ferry-linked movements.
Tie NCTS6 checks to guarantee monitoring. Transit errors can create guarantee exposure, especially if movements are not discharged cleanly. Your customs or finance team should be able to reconcile open movements, guarantee references, office status, and expected discharge dates. If your guarantee controls are already being reviewed, use the same evidence discipline described in our customs guarantee guide.
Do not treat GVMS as separate from transit in ro-ro operations. Where a movement depends on ferry timing, haulier instructions, goods movement references, and customs status, a failure in one system can look like a failure in another. Make sure planners know whether they are waiting for NCTS acceptance, GVMS readiness, carrier cut-off, or a broker action.
A Practical Go-Live Test Plan
The minimum useful test pack has five scenarios. Test one standard T1 departure, one T2 movement if your business uses Union goods transit, one arrival at office of destination, one rejected declaration, and one outage or delayed-response scenario. Each scenario should produce evidence: screenshots or exports, message references, timestamps, user names, and the provider support route if something fails.
For each scenario, define what “pass” means before testing starts. A standard departure test should show that the declaration can be created, validated, submitted, accepted, assigned a master reference number, printed or viewed as a TAD, and monitored afterwards. A rejection test should show that the user can correct the failed field and retain the audit trail.
Use real operating patterns, not only clean master data. If your team frequently handles multi-item consignments, several consignors, seals, changed vehicle details, or late customer paperwork, include those details in the test pack. Software that passes with a single-line training example may still fail when the warehouse adds three pallets and a new trailer registration 20 minutes before cut-off.
Retest after provider releases. NCTS6 readiness is not a one-off project if your software supplier keeps shipping fixes. Keep a short release log showing what changed, who reviewed it, and whether any live workflow needs a staff briefing.
Common Failure Points
The most common failure is assuming that API connectivity equals readiness. A connected system can still fail if the user journey is incomplete, validation is weak, master data is stale, or support cannot read the live message trail. Treat the API as one control inside a wider transit process.
Another failure is vague supplier assurance. “NCTS6 ready” should trigger follow-up questions, not close the file. Ask which HMRC service was tested, which message types are supported, which workflows remain limited, and what customers must configure themselves.
Master data is a quieter risk. Office codes, customer records, guarantee references, authorisation numbers, consignor details, consignee details, and goods descriptions may have been copied from old jobs for years. NCTS6 validation can expose poor data discipline that was already present, so cleanse high-use templates before live traffic depends on them.
The last failure is weak exception ownership. Someone must decide what happens when a declaration is rejected, a message is delayed, a TAD cannot be printed, or a port deadline is at risk. Write that decision tree before the exception happens, and make sure it names roles rather than individuals who may be off shift.
Frequently Asked Questions
Is NCTS6 live in the UK?
Yes. HMRC’s Common Transit Convention Traders roadmap says NCTS Phase 6 is now in production and live, and trade updates reported the UK Phase 2 go-live date as 1 June 2026. Do not treat NCTS6 as a future upgrade if you are making UK transit declarations now. Your focus should be live-service assurance, provider evidence, and staff readiness.
Do I need new transit software for NCTS6?
You need software that supports the live NCTS6 requirements, but that does not always mean replacing your platform. Some providers upgraded existing products, while others require configuration changes, tenant migration, or user retraining. Ask for written confirmation of your live environment, not just a general product announcement.
What are the HMRC API endpoints?
The HMRC API catalogue lists the Common Transit Convention Traders sandbox at https://test-api.service.hmrc.gov.uk and production at https://api.service.hmrc.gov.uk. Your software supplier should manage those connections, credentials, and environment settings in a controlled way. Users should still understand which environment they are viewing when testing or diagnosing an issue.
Are IE117, IE058, and IE119 used for UK movements?
The UK opted out of TSAD connection at the first stage of NCTS6, so IE117 and IE058 are not used for GB or NI transit movements in the way TSAD-connected administrations use them. IE119 is also not used in the same way for GB and NI because GVMS is part of the UK border model. Providers should still explain how they handle any wider CTC messages that may affect cross-border movements.
What evidence should I keep for audit?
Keep provider readiness confirmations, release notes, test results, user permissions, declaration references, HMRC response messages, TAD output, incident logs, and fallback decisions. The aim is to show that you controlled the process, not only that a supplier told you the product was ready. This evidence also helps when reconciling open transit movements and guarantee exposure.