EUROPEAN COMMISSION
DIRECTORATE-GENERAL
TAXATION AND CUSTOMS UNION
Customs Policy
Customs Processes and Project Management
Brussels, xx xx 2015
Taxud.a.3 (2015) xxxxxx
PROOF OF UNION STATUS (POUS) SYSTEM
CLARIFICATION OF PROCESSES
1
INTRODUCTION
An informal meeting dedicated to discuss and clarify the processes related to the Proof of Union Status
(PoUS) system was organised by the COM and held on 10 February 2015 in Brussels.
The representatives of six Member States (FI, FR, IE, PT, DE, UK) and three members of the Trade
Contact Group (WSC, IPSCA, CLECAT) were attending the meeting.
The meeting discussions were mainly based on the scenario where Union goods are loaded at the port of
departure in the EU – then transported by calling at an intermediate third country port – and unloaded at
the port of re-entry into the EU.
The clarification given in this document also provides the summary of the informal meeting discussion.
2
SYSTEM SCOPE
The system scope refers to the means of proof of the customs status of Union goods provided for in:
 Article IA-1-08 (1) (b) - proof in the form of a T2L or T2LF document;
 Article IA-1-08 (1) (c) – proof in the form of a customs goods manifest.
As set out in the Article DA-V-1-09, the proof in the form of a customs goods manifest established by the
authorised issuer is not in the scope of the PoUS system. In this case no proof registration will be
required at the competent customs office of the country of departure where the Unions goods are loaded.
The customs status of Union goods will be indicated in the manifest of the carrier,, provided that such
manifest contains all the information required for customs goods manifest as it is defined in Annex B of
UCC DA/IA.
This will be under the competence of the presentation customs office to verify whether the customs status
of Union goods is established correctly, including the authorisation verification; the verification
procedure as well as monitoring of the use of proof shall be defined by the national customs
administrations.
The remaining text in this document refers only to the PoUS system functionality and does not cover
cases where the proof in the form of a customs goods manifest established by the authorised issuer is
used.
3
SYSTEM PROCESSES AND FUNCTIONALITY
The PoUS system processes and functionality are exclusively based on the legal provisions defined in the
UCC DA/IA (articles DA-V-1-06, DA-V-1-09, IA-V-1-00, IA-V-I-10, IA-V-1-10a, IA-V-1-11) and do
not go beyond what is required by the legislation.
3.1. General rules
The customs status of Union goods shall be established before the goods leave the customs territory of the
EU.
The proof in the form of a T2L, T2LF document or a customs goods manifest shall be endorsed and
registered by the competent customs office after which a Master Reference Number (MRN) is issued.
The proof in the form of a T2L or T2LF document established by the authorised issuer shall be registered
by the competent customs office specified in the authorisation after which an MRN is issued.
The proof shall be valid for 90 days from the date of registration. At the request of the person concerned
the customs office may set a longer period of validity. In this case the requested validity period should be
indicated and communicated to the competent customs office by the means of an
'Endorsement/Registration request' message.
Each T2L, T2LF document or customs goods manifest shall be identified by its MRN considering that:

in the T2L or T2LF document the customs status of Union goods is indicated at the header level
and applies to all goods items;

in the customs goods manifest customs the status of Union goods is indicated at the goods item
level and applies to particular goods.
There is no possibility to amend the T2L, T2LF document or the customs goods manifest after their
registration as there is no legal basis for this. In case of need a new document should be issued on request
of the person concerned.
The T2L or T2LF document can be used only once. If a T2L or T2LF document is used for only a part of
the goods, on request of the person concerned, a new proof shall be established by the competent customs
office for the remaining part of the goods.
A Customs goods manifest can be used more than one time. The information about the previous use of
the customs goods manifest will be stored in the central repository and made available to the presentation
customs office at the time of each subsequent presentation of the same MRN.
3.2. Endorsement request
The endorsement request shall be submitted to the competent customs office. There are two specific
endorsement request messages specified in the PoUS level 4 BPM depending on what mean of proof is
used.
As regards the parties involved, the request for endorsement of T2L or T2LF document will be submitted
by the 'person requesting a proof' or its 'representative'. In terms of system user it may be a consignor,
freight forwarder, carrier, shipping company, etc.
The request for endorsement of customs goods manifest will be submitted by the 'person lodging the
customs goods manifest' or its 'representative'. In terms of system user it will in general be a carrier.
In respect of each endorsement request the competent customs office shall take and register an
endorsement decision; this is a manual task, however the possibility to implement a timer that would
trigger an automatic processing of the endorsement request could also be considered and discussed at the
level of the functional system specification. Depending on the national needs and implementation the risk
analysis process can be integrated at national level in order to facilitate the endorsement decision.
Upon the positive endorsement decision a T2L, T2LF document or a customs goods manifest will be
registered automatically by issuing an MRN; the person concerned will be notified about the proof
registration, the proof details will be stored in the central repository.
3.3. Registration request
The request for registration of a T2L or T2LF document will be submitted by an authorised issuer to the
competent customs office specified in the authorisation; there may be more than one customs office
specified.
The PoUS system will validate the authorisation automatically.
Upon the positive authorisation validation the T2L or T2LF document will be registered automatically by
issuing an MRN; the authorised issuer will be notified about the proof registration, the proof details will
be stored in the central repository.
2
3.4. Presentation of the proof
The T2L, T2LF document or customs goods manifest shall be presented to the presentation
customs office where the goods are presented after re-entering the customs territory of the EU by
submitting the MRN.
As long as the customs status of Union goods is not proven all unloaded goods are deemed to be
non-Union goods. The person concerned will have to submit an MRN in order to prove the
customs status of Union goods. In terms of the system user it may be a consignee, terminal
keeper, freight forwarder, shipping company, etc.
In the PoUS system there is a specific message specified which allows an MRN submission by
means of information exchange. Depending on the national needs and implementation a systemto-system interface can also be implemented at the national level.
On the basis of the submitted MRN the PoUS system will automatically validate whether the
presented proof exists and is valid for use. The proof is considered as not valid for use when the
validity date is expired or, in case of a T2L or T2LF document when it has been already used.
Upon the positive validation the proof details will be made available to the presentation customs
office. In respect of each presented T2L, T2LF document or customs goods manifest the presentation
customs office shall take a decision whether the presented proof can be used for the goods for which it is
presented. If the decision is positive the proof usage information has to be registered in the PoUS system;
this is a the manual task however the possibility to implement a timer that would trigger an automatic
proof usage registration could also be considered and discussed at the level of the system functional
specification.
As far as the standard process is concerned the presentation customs office do not have to verify
whether the customs status of Union goods has been established correctly, including the authorisation
verification. However if the need arises the customs authorities of the MS shall assist each other in
checking the authenticity and accuracy of the T2L, T2LF document or customs goods manifest
by the means other than PoUS system.
4
TECHNICAL ISSUES RELATED TO THE SYSTEM IMPLEMENTATION
Based on the diametrical differences in volumes across the EU (see picture 1), the Business Case
document recommends the design set out in chapter 3.3.3 - the Alternative C Scenario 3 (see
pictures 2 and 3 below). This solution should allow the MSs not having significant volumes of
T2L and T2LF documents and customs goods manifests to rely on the Union central services and
components centrally developed and operated on the EU level.
Those central components, decoupled and offered web services based on the SOA architecture,
will cover the following functionalities and business logic:
 Traders interfaces offering basically:
 electronic lodgement of only structured request messages for endorsement and
registration of the proof as defined in the system functional and technical
specifications;
 authentication of the trader's electronic lodgement (using UMM&DS services
once available also for S2S integration);
 validation of the proof endorsement/registration request messages;
3




notifications to the respective trader that requested the proof;
retrieval of the actual status of the request/proof;
submission of the proof MRN to the presentation customs office;
monitoring capability available only to the traders involved in the business
transaction
as a:
 graphical user interface
 system-to-system interface allowing traders to integrate its IT systems
 Services for customs authorities for:
 endorsement and registration of the proofs and notifications to traders,
 storage of the proofs in the central repository,
 optional integration of national risk analyses at the office of departure and the
office of presentation,
 registration of the use of the proof based on MRN and merging functionality,
Comment: the merging will be based only on MRN, no quantities of goods will
be compared by the IT system.
 and monitoring and reporting based on several criteria.
as a:
 graphical user interface
 system-to-system interface allowing national customs administrations to integrate
its IT systems per a function at the office of departure and/or the office of
presentation
The PoUS system will also support the assessment of the efficiency of the PoUS institute by the
monitoring and reporting tools either on the EU level by DG TAXUD or on the national level.
E.g. the IT system will offer:
 to produce a list of comparisons of registered PoUS being used/presented at the office(s)
of presentation for defined period (from-to)
 to generate a list of non-used PoUSs for a given time period (more detailed filtering of
the report will be possible as well).
 etc.
Using the SOA architecture, the Alternative C Scenario 3 allows MSs to decide either they will
only use Union central component and services offered to customs authorities at MSs, or, based
on the central services specifications:
 partially integrate its nationally developed IT systems e.g. for the registration of
the use of proofs at the office of presentation,
 or fully integrate national IT systems supporting relevant functions at the office
of departure or/and at the office of presentation.
The decision to change the level of integration can be done even after the start of operations of
the PoUS System but the conformance tests are required and a strong change management policy
is necessary. The national implementation must strictly comply with a single set of rules,
processes and data as defined in level 4 BPM for Proof of Union Status and future technical
specifications.
Having covered all required functionalities by the centrally developed components, the PoUS
system can be declared as fully operational at all EU MSs from the date when the central
components are available for operations, irrespective of national delays in the development of
national IT systems and their integration.
4
Picture 1. Estimated number per year (summary of the survey – end 2014)
5
Picture 2. IT functional view
Picture 3. Solution overview
6