Glossary
Learn about the concepts that govern how a transit declaration is created.
Consignment data group
The restructuring of the IE015 declaration in NCTS5 provides for greater flexibility of consignor, consignee, and goods related documentation on a hierarchical basis.
The NCTS5 transit declaration introduces the ability to specify either single or multiple consignor information to associated single or multiple consignees.
The basic consignment hierarchy is as follows:
- Consignment
- Consignment > House consignment
- Consignment > House consignment > Consignment item
Consignment
Consignment level provides for master, overarching information about a movement. For example, if there is only one consignor and/or one consignee, it would be declared at this level. Also, any documentation (previous, supporting, transport, and so on) that applies to the movement as a whole may be declared at this level.
House consignment
At least one house consignment level data block must be provided, such as for a single consignor. If a transit movement contains goods from more than one consignor, multiple house consignment data blocks must be used. The same consignor can be used in more than one house consignment block, but at least one of the house consignment blocks must have a different consignor.
Additionally, if there is more than one consignee, house consignment blocks can be used on a per consignee basis to specify individual consignee details only once at this level to cover all the goods in the house consignment block. For example, this would apply if a single consignor is moving goods to multiple consignees. The same consignee can be used in more than one house consignment block, but at least one of the house consignment blocks must have a different consignee.
The benefit of this over current NCTS4 operation is the need to provide the consignee details only once for multiple goods instead of repeating the same data for every goods item entered.
If more than one house consignment block is used, the consignor and/or consignee details at this level must be different to those in at least one other block. In other words, you cannot use two or more house consignment blocks if there is only a single consignor and consignee for the movement, irrespective of whether there are more than 999 items (the limit per house consignment).
The maximum number of house consignments per declaration is 1999.
Consignment item
Consignment Item level is where details of all the goods being moved must be declared insofar as they relate to the consignor and/or consignee declared at the higher consignment or house consignment levels.
Goods must be declared on a line-by-line basis, each with an individual item number, description, packaging details, weight, and commodity code (which is mandatory post-transition) details. Consignee details can be entered per goods item at this level only during the transition period.
Previous document, supporting document, and other supporting documentation can all be declared in the same hierarchal fashion explained above at either consignment, house consignment, or consignment item level depending on the coverage of the documents in relation to the goods items.
Example usage
| Goods being moved on behalf of | Declare consignor(s) at consignment level | Declare consignor(s) at house consignment level | Declare consignee(s) at consignment level | Declare consignee(s) at house consignment level | Maximum total goods items per MRN |
|---|---|---|---|---|---|
| Co. A to Co. B | X | X | 999 | ||
| Co. A to (Co. B, Co. C, and so on) | X | X | 1,999* | ||
| (Co. A + Co. B, and so on) to Co. C | X | X | 1,999* | ||
| Co. A to Co. B and; Co. C to Co. D, and so on | X | X | 1,999* |
Authorisation data group
The Authorisation data group is a new addition to NCTS5. It allows the holder of the transit procedure to indicate which transit simplifications they wish to use for the movement that they have been previously authorised for.
Example authorisations include the following.
| Authorisation | Description |
|---|---|
| ACR | Authorisation for the status of authorised consignor for Union transit (Column 9b, Annex A of Delegated Regulation (EU) 2015/2446) |
| SSE | Authorisation for the use of seals of a special type (Column 9d, Annex A of Delegated Regulation (EU) 2015/2446) |
| TRD | Authorisation to use transit declaration with a reduced dataset (Column 9e, Annex A of Delegated Regulation (EU) 2015/2446) |
| ACE | Authorisation for the status of authorised consignee for Union transit (Column 9c, Annex A of Delegated Regulation (EU) 2015/2446) |
Authorisations can be used individually or combined as appropriate.
For a trader to use any transit simplification that it has been authorised to use, such as Authorised consignor for simplified procedure departure, the correct authorisation details must be present in the Authorisation data group and its usage is validated by NCTS.
Where the declarant wishes to use an Authorisation data block must be created with Authorisation > Type entry as follows.
| Authorisation type | Description |
|---|---|
| C521 | Authorised consignor for simplified departure process (IE015) |
| C522 | Authorised consignee for simplified arrival process (IE007) |
| C523 | Authorised to use seals |
| C524 | Authorised to use reduced dataset |
The trader’s authorisation number must also be given in the data field Authorisation > Reference Number. This will be the reference number given to the trader when they first applied to use simplifications, an example of which may look like AUTH123A.
This should not be confused with the data field Location of Goods > authorisation number that indicates the exact location the movement will be departing from/arriving at when using the simplified procedure.
The Location of Goods data group is used to declare the type and geographical position of the location from which a transit movement is intended to depart. The location types available are the same in NCTS4 and NCTS5, but NCTS5 uses a different naming convention and method for identifying a location type being used.
Location designations have been revised for NCTS5 as follows.
| NCTS4 designation | NCTSS5 designation | NCTS5 identifier |
|---|---|---|
| Customs sub place | Designated location | A |
| Authorised location code | Authorised place | B |
| Agreed location | Approved place | C |
You must provide the location of goods before the release of a transit movement, either in an IE015 message for a standard departure or in an IE170 message for a pre-lodged departure. You must specify both the type of location (using a single alphabetic character as shown in the table), and the qualifier of that location. The location qualifier is the means you will use to provide the exact locations, such as address, UN Locode, and so on.
| Location qualifier | Location type code A | Location type code B | Location type code C | Location type code D |
|---|---|---|---|---|
| T (Postal code) | A + T | B + T | C + T | D + T |
| U (UN/Locode) | A + U | B + U | C + U | D + U |
| V (Customs office identifier) | A + V | B + V | C + V | D + V |
| W (GNSS coordinates) | A + W | B + W | C + W | D + W |
| X (EORI number) | A + X | B + X | C + X | D + X |
| Y (Authorisation number) | A + Y | B + Y | C + Y | D + Y |
| Z (Address) | A + Z | B + Z | C + Z | D + Z |
Although these are all combinations that NCTS5 supports, see the Location of Goods data group in Declaration data for acceptable practical usage in the UK.
You must provide the actual information relating to the chosen qualifier in the appropriate data subgroup within the Location of Goods data group.
The Location Qualifier > Authorisation Number (Y) is correlated with the NCTS4 Authorised Location Code.
A simplified departure procedure declared in NCTS5 must contain the following:
- Authorisation data group: the appropriate Reference number under which the Authorised Consignor status is held, which is an umbrella reference number under which all authorised location codes are contained
- Location of Goods data group: Location Type Code
B(authorised place), Location QualifierY(authorisation number), and the Authorisation Number (NCTS4 authorised location code) in the appropriate data subgroup from which the movement will be started.
If the combination B +Y is used, NCTS validates all authorisation data provided.
Due to the widespread use of data group multiplicity within NCTS5, sequence numbers have been introduced to indicate intended use of the same data group multiple times to convey different data. The sequence number essentially provides an audit number for every reuse of a specific data group that has the capacity to be used more than once.
Generally, a sequence numbers starts at 1 and increase by 1 incrementally for each instance of the same data group. For example, the Guarantee data group can be used up to 9 times allowing multiple different guarantee types to be used to cover the value of the duties at risk during the goods movement. The first guarantee block (for, say, Type 1 guarantees) would have sequence number 1, the second guarantee block would have sequence number 2, and so on.
Note: Although sequence numbers can be entered manually by declarants, it is more efficient to automate them for the traders you serve to prevent unnecessary rejections and to optimise efficiency.
## Amendments and corrections (IE013)Pre-lodged declarations can be corrected as many times as required before a valid IE170 (‘Presentation Notification For The Pre-Lodged Declaration‘) message being accepted by the office of departure and an MRN being allocated by an IE028 (‘MRN Allocated‘) message.
Pre-lodged, simplified, and normal declarations can all be amended after the MRN has been allocated but before the IE029 (‘Release For Transit‘) message. Corrections or amendments are made by submitting an IE013 (‘Declaration Amendment‘) message:
if message is successful, an IE004 (‘Amendment Acceptance‘) message will be received - but additional changes can be made by sending subsequent IE013 messages
if message is unsuccessful and rejected, an IE056 (‘Rejection from Office of Departure‘) message will be received, and no change will be made to the declaration - but further IE013 messages can be used to make corrections or amendments as required before the declaration is either rejected (if it contains errors preventing release) or released (IE029)
The IE013 message type has two variants determined by the IE013 data element Transit Operation > Amendment type flag, which can be 0 or 1.
| Flag type | Usage | Description |
|---|---|---|
1 |
Amendments of only the Guarantee data group | Use this flag type only when a movement has entered state ‘Guarantee under amendment’. This state will be entered before movement release (IE029) as a consequence of an error in the Guarantee data group (in the IE015 message or subsequent IE013 message). Notification of the state will be received by means of an IE055 (Guarantee Not Valid) message, and an IE013 with flag type 1 will be expected to amend the guarantee. If this is not provided before the expiration of the guarantee awaiting amendment timer, the declaration will be rejected. |
0 |
All other amendment or correction attempts | The list of data groups and elements that cannot be modified using an IE013 message can be found in rule R0520. |
Unloading permission (IE043)
In the simplified arrival procedure, the IE043 (‘Unloading Permission‘) message is sent by the office of destination to the authorised consignee automatically after receipt of the IE007 (‘Arrival notification‘) message sent by the authorised consignee (assumption: the IE007 is valid and accepted).
The IE043 message type is used in 2 ways.
| Usage | Purpose | Message contents |
|---|---|---|
| Initial | An initial IE043 message is sent to confirm that unloading can begin. | An initial IE043 message will always include the full payload of consignment details and grant permission to start unloading. |
| Subsequent | If unloading is incomplete (as indicated in the IE044 ‘Unloading Remarks‘ message), at least 1 subsequent IE043 message will be sent to confirm that unloading can continue. | Subsequent IE043 messages will include only ‘confirmation unloading may continue‘ in data element ‘CTL_CONTROL.Continue unloading‘, which will be a number that will increase sequentially for each additional continue unloading IE043 message sent (see rule G0510). |
Unloading remarks (IE044)
After receipt of an initial IE043 (‘Unloading Permission‘) message granting permission to unload, unloading should commence when possible and an IE044 (‘Unloading Remarks‘) message should be sent by the authorised consignee. This IE044 message must confirm whether unloading has been completed or is currently incomplete, and whether the now arrived consignment conforms to the declaration (at the stage of the IE029 ‘Release For Transit‘ message).
At any time, the goods may be selected for control by the office of destination, and release of the goods from the transit procedure can be withheld pending an investigation by customs.
There is no obligation to provide an IE044 message indicating that unloading is not yet complete (indicated by setting data element ‘UNLOADING REMARK.Unloading completion‘ to ‘0‘, see rule G0186). However, at the discretion of the authorised consignee, an IE044 message can be used to notify the office of destination of an interruption or delay to the unloading process.
An IE044 message confirming that unloading is not yet complete will be reviewed by the office of destination, and a subsequent IE043 message with permission to continue unloading will be sent to the authorised consignee. When unloading is finally completed, the authorised consignee should send an IE044 message with data element ‘UNLOADING REMARK.Unloading completion‘ set to ‘1‘.
Reporting no discrepancies
If there are no discrepancies between what has arrived and what was declared (and released to transit after any amendments), the data element ‘UNLOADING REMARK.Conform‘ must be set to ‘1‘ (see rule G0205) to indicate that there are no unloading remarks. If the IE044 message indicates that the goods conform with the declaration, consignment information is not required.
Reporting discrepancies
Discrepancies between what has arrived and what was declared (and released for transit after any amendments) must be reported in the IE044 message. To provide discrepancies information, set the data element ‘UNLOADING REMARK.Conform‘ to ‘0‘ to indicate that there are unloading remarks (see rule G0205).
When providing details about the discrepancies, you must provide consignment information only for those data groups where there has been a change from the initially released declaration (see rule G0360).
Note: When reporting a discrepancy, you must provide the same level of consignment detail as you provided in the IE015 (‘Declaration Data‘) message for the transit movement.
The IE044 message should identify the affected data group when reporting new ‘actual’ consignment details by matching its sequence number; or for consignment items, the ‘goods item number‘, and ‘declaration goods item number‘.
If data or goods items are missing entirely, the sequence number or goods item number and declaration goods item number should be matched as appropriate, but omit any additional data elements.
If consignment information in excess of what was initially declared (and released) is identified during unloading, the sequence number (or ‘goods item number‘ and ‘declaration goods item number‘) should equate to the highest sequence number or declaration goods item number/goods item number +1 for each new data group instance.
For example, if 10 items were initially declared, and an 11th item is identified upon unloading, the consignment item ‘goods item number’ and ‘declaration goods item number’ should equate to the highest existing numbers for the consignment +1. (In this example and during the transition period where multiple house consignments are not used, this would be 11.)
For more information about proper completion of IE044 consignment data groups when discrepancies have been identified, see rules R0054 and R0055.