The Transit Declaration Was Rejected: Is the Guarantee Reference or the Filing Record Wrong?
Replay an NCTS Phase 5 rejection from the submitted declaration through the guarantee holder, GRN, access code, amount and customs response.
Signals to watch
- The rejected declaration and official response can be tied to one submission timestamp and office of departure
- The guarantee holder, GRN, access code and reference amount have identifiable source owners
- A controlled replay shows whether the same source values fail before an MRN is issued
An NCTS rejection should be replayed from the official response, not diagnosed from a copied error banner. Recover the submitted declaration, office and timestamp; then compare the guarantee holder, trader identifier, Guarantee Reference Number, access code and reference amount with their source records. If the declaration was never accepted, do not search for a Movement Reference Number that was never issued.
This is written for a customs-software sales engineer reviewing authorised customs-broker, freight-forwarder, guarantee-provider and transit-operations Telegram groups. The commercial Signal is a repeatable rejection with a named filing owner and a recoverable response. Seeing it a day late can miss the planned departure or leave the declarant preparing another blind retry while the guarantee owner is offline.
An illustrative, incomplete fragment could say:
“P5 kicked it back again. GRN is the one we always use. Truck tomorrow morning—anyone seen this after changing declarant?”
This is a composite example, not a real declaration or customer result. The country, procedure, declaration identifier, office, principal or holder, Guarantee Reference Number (GRN), access code, amount, goods, response message, software version and retry history are unknown.
First decide whether there is an accepted movement
The New Computerised Transit System (NCTS) is the electronic system used to manage and control goods moving under Union and Common Transit. A trader submits a transit declaration to the office of departure. Once accepted, the movement receives a Movement Reference Number (MRN).
That sequence creates the first diagnostic split:
- No MRN: work from the declaration submission and rejection or validation response.
- MRN exists: the declaration was accepted; later guarantee, release, incident, arrival or discharge questions belong to the movement record.
A GRN is not an MRN. The GRN identifies a guarantee that can cover potential customs debt while duties are suspended in transit. The MRN identifies the accepted transit movement. A screenshot headed “guarantee error” without either identifier cannot show which state failed.
The European Commission’s NCTS page and Transit Manual 2026 are the starting sources for Union and Common Transit. National NCTS guidance and the actual customs response remain necessary because message handling and support ownership are country-specific.
Replay the exact declaration that customs evaluated
Export the declaration payload or human-readable submission as it was sent. Do not rebuild it from the current screen: a later edit may hide the original defect. Preserve the local submission ID, timestamp, office of departure, declarant and representative roles, holder of the transit procedure, guarantee type, GRN, declared amount, response and application version.
Then put the values into one replay record:
| Record | Source owner | Value received by NCTS |
|---|---|---|
| Holder or principal identifier | Transit authorisation / guarantee owner | Exact identifier in declaration |
| Guarantee type | Transit and guarantee decision | Code in declaration |
| GRN | Guarantee evidence | Full reference as transmitted |
| Access code or permission | Guarantee holder | Value or permission used for this declarant |
| Reference amount | Goods and duties calculation | Amount and currency representation sent |
| Customs result | National NCTS | Full response, timestamp and correlation ID |
This table is not a substitute for a country’s declaration specification. Its purpose is to expose who owns each source value. If the spreadsheet shows a new GRN but the transmitted message still contains the old one, the first break is the export or mapping. If the transmitted value matches the source and customs rejects it, move to guarantee validation evidence.
Check ownership before checking character format
The phrase “the GRN is correct” usually means only that its characters match a familiar reference. A valid-looking reference can still be paired with the wrong holder, trader identifier or access permission.
HM Revenue & Customs’ NCTS guarantees guidance provides a concrete national example: UK NCTS checks the quoted GRN against the principal’s trader identifier and the declared access code. If validation fails, the declaration is rejected. When a declarant has permission to use somebody else’s guarantee, the guidance requires the principal’s identifier, that principal’s GRN and an access code arranged for that use.
That UK rule is useful diagnostic evidence, not proof of another country’s exact response. For an EU Member State filing, recover the applicable national rule and message. In every case, ask the guarantee holder—not the last person editing the declaration—to confirm the reference, authorised user and effective status.
Keep identity validation and guarantee capacity separate
A matching holder, GRN and access code do not prove that sufficient guarantee is available for a new movement. Open movements can consume capacity until they are closed and the amount is released. The declared reference amount can also be missing or inconsistent with national rules.
The HMRC guidance says all declarations in its NCTS 5 implementation require the appropriate guarantee amount in the guarantee reference field. It also says NCTS tracks guarantee used by open movements and prevents new movements when the limit is reached until capacity is released or increased. Those are UK operational statements aligned to the Common Transit Convention; do not copy their wording into another national filing without checking local guidance.
Record identity/access and amount/capacity as two tests:
- Does this holder and declarant have the right reference and access data?
- Does the guarantee evidence support the amount required for this movement at the filing time?
Changing a GRN will not repair an amount calculation. Increasing capacity will not repair a trader-identifier mismatch.
Compare one failed submission with one controlled case
Use the same national NCTS environment and office. Change only one authorised variable at a time. A useful sequence is:
- resend the affected declaration only after correcting the first evidenced mismatch;
- test the same guarantee with another permitted declaration if the holder authorises it; or
- test the affected declaration with another permitted guarantee if procedure and owner allow it.
Never manufacture a customs movement merely to test software. Use the test environment or a legitimate declaration under the responsible declarant’s control.
Read the result as evidence:
- rejection moves with the source GRN: inspect guarantee identity, access, status or capacity;
- rejection stays with the declaration: inspect holder role, guarantee type, amount and message mapping;
- local software says “sent” but no matching national response exists: inspect transport, correlation and acknowledgement;
- customs accepts the declaration and issues an MRN: the initial rejection is resolved, but release and discharge remain separate stages.
For an entry-summary rejection, use the ICS2 ENS response-routing article. ICS2 and NCTS handle different declarations; an ICS2 error pattern is not NCTS guarantee evidence. The eFTI platform readiness test concerns regulatory freight information platforms, not customs guarantees.
When the rejection supports a software opportunity
Return to the composite fragment. “After changing declarant” is a useful lead only after the submitted message shows which holder and trader identifiers changed, the guarantee owner confirms permission, and the national response identifies validation failure. A controlled replay that repeatedly exports a stale identifier or omits the required amount supports software work. One rejection caused by an expired permission or exhausted capacity does not.
TOP Prospect can connect an initial rejection fragment with a later GRN-owner or response fragment across Telegram groups the user intentionally connects, preserve the original messages and rank the combination for human review. It cannot access NCTS, see a guarantee, calculate customs debt, submit a declaration, contact the author or promise release. The product access options describe the discovery boundary.
The quote-ready note names the filing country, declaration, office, submission time, holder, guarantee source, first mismatched record, customs response, owner and authorised replay.
FAQ
What is a Guarantee Reference Number?
It identifies a transit guarantee used to cover potential customs debt. It must be paired with the correct holder and access information for the declaration.
Is a GRN the same as an MRN?
No. The GRN identifies the guarantee. The MRN identifies an accepted transit movement. A rejected declaration may never receive an MRN.
Can an access-code mismatch cause rejection?
Yes in the cited UK guidance: NCTS checks the quoted GRN against the principal identifier and access code and rejects failed validation. Check the relevant national evidence for other filings.
Does a rejection prove a software defect?
No. It may come from source identity, access, guarantee status or capacity, the declared amount, message mapping or national-system validation.
Frequently asked questions
What is a Guarantee Reference Number in NCTS?
A Guarantee Reference Number identifies a transit guarantee used to cover potential customs debt. It must be associated with the correct holder and access data for the declaration.
Is a Guarantee Reference Number the same as an MRN?
No. The GRN identifies the guarantee. The Movement Reference Number identifies an accepted transit movement; a rejected declaration may never receive an MRN.
Can an access-code mismatch reject a declaration?
Yes in the UK NCTS guidance cited here: NCTS checks the quoted GRN against the principal trader identifier and declared access code, and rejects the declaration if validation fails. National implementation evidence must be checked for the filing country.
Does every guarantee rejection prove a software defect?
No. The source can be the holder or trader identifier, GRN, access permission, guarantee amount or capacity, declaration mapping, national validation or a stale retry.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
