Update Annex AO/IC ATLAS-CMS

Document outlining the process governed through ATLAS and our Compliance Management System (CMS).

Introduction
Abbreviations
Terminal Management System

Fundamentals
Business process
Parcel administration

Compliance management

Customs Procedure Operation
Business rules
Customs declarations or records

Reporting

Monitoring licenses
Bill of Discharge
Detailed Stock Management
Audit file

Technical specifications

Main communication Source system to CMS - Transaction JSON
Business rules to determine customs declarations required for all Products involved in the Activity
Business rules overview CMS
Transaction Request

Introduction

This document describes the Functional setup of our Terminal Management System (TMS) called ATLAS and its working in conjunction with our Compliance Managements System (CMS). With CMS, we implement processes and measures of internal controls to ensure compliance with the relevant legal requirements and updated systems on the side of the relevant authorities.

CMS is a an autonomous module/system built using the same standards as ATLAS (i.e. Oracle APEX). In the intermediate period, where Tomcat is still in production, CMS will be linked to Tomcat as source system. As Tomcat is phased out gradually, CMS is now also linked to ATLAS as the source system.

CMS will only be used by Terminals that offer Compliance services, such as Customs and Global Trade (CGT) services to their clients. Examples are lodging customs declarations, issuing customs documents such as customs transport documents or origin documents.

All Terminals globally have to deal with compliance requirements, but where the Terminal does not perform actual services in this matter, it merely keeps record of data relevant to the goods we handle. This is covered by the source system and is not in scope of CMS. Think of data around the goods we handle, such as:

Commodity code;
Customs status;
Origin (preferential and non-preferential); and
Reference numbers / cargo document data, among which customs documents.

With ATLAS in combination with CMS, customs processes are automated as much as possible.

Abbreviations

AO/IC	Document describing the Administrative Organization and Measures of Internal Control, to which this document is an annex.
CGT	Customs and Global Trade.
CS	Customer Services team.
CMS	Compliance Management System.
CPM	Commercial Policy Measures
DMS	Customs Management System of the Dutch Customs authorities used for lodging customs declarations and messages.
EIDR	Entry Into the Declarants Records
NoP	Notification of Presentation message to present goods to Customs.
MAB	Notice Expiration of Payment Term.
OPS	Operations team.
SKU	Stock Keeping Unit
TMS	Terminal Management System.
TSD	Temporary Storage Declaration (i.e. practically the customs declaration done by the agent on behalf of our customers, prior to the goods arriving at our terminal).

Terminal Management System

In this Chapter we focus on the role that our TMS - ATLAS plays in the process of governance. ATLAS is where data is received from in the CMS and where a User is informed on the outcome of the Customs processes.

Terminal Management System

Fundamentals

Overview

Below is an overview of the physical flows relevant to the Terminal. The philosophy applied is the What You See IS What You Get principle. The record keeping and inventory is built on the concepts as explained under "Business process".

Part of ATLAS is the CMS. The purpose of CMS is to evaluate and validate the input data it receives from ATLAS and manage the compliance process. It is aimed at providing feedback to the Users on the basis of analysis performed and to lodge customs declarations timely and correct.

Core System Concepts

The system is based on a set of core concepts that together represent the physical and administrative handling of Product within terminal operations.

Visit – Represents a Means of Transport (MOT) and its time of arrival. A single MOT may execute multiple Visits over time. Visits form the temporal and operational entry point for incoming or outgoing Product flows.
Product – Represents the physical substance (molecules) being handled, such as bulk liquids. Product is the base physical entity on which all operational and administrative processes are applied.
Storage Unit – Represents a physically segregated storage entity for Product. Storage Units ensure physical separation of Product and define how it is stored. Examples include:
- A Tank, which is a single Storage Unit;
- A Vessel, which may contain multiple segregated Storage Units;
- A Train, where wagons function as individual Storage Units;
- A Truck, where separate compartments can each represent distinct Storage Units containing different Products.
Location – Defines where Activities are executed. Locations are relevant for operational control and for compliance with applicable licenses and regulatory requirements.
Activity – Represents all operational actions performed on Product within the system. Activities include all forms of handling, transformation, movement, storage, or processing of Product across Visits, Storage Units, and Locations.

Together, these concepts form the foundational structure for representing physical flows and their administrative and compliance-related processing within the system.

Activities

For each Activity, whether a Movement or a Service, ATLAS provides information on all Products involved. In the case of Services, where no physical transfer of goods takes place between locations, the data relates to Parcel information within a Storage Unit (for example, a Tank or a Vessel). In the case of a Movement, at least two Storage Units are involved, and ATLAS provides Parcel data for all Products participating in the transfer between these Storage Units.

As further described under “Business Process”, the following list of Activities is used to support the record-keeping requirements from a customs compliance perspective:

Movement;
Services:
- Take in quantity;
- Rebrand;
- Import;
- Administrative Stock Transfer;
- Shifting service;
- Commodity code correction;
- Departure.

Terminal Management System

Business process

General

The Activities executed require formalities towards Customs based on our type of operation, i.e., Movements of Product, and based on Services we provide, such as blending or importation (i.e., release for free circulation). These Activities are governed through our TMS, ATLAS, whereby executing such Activities include a mandatory or automated step to ensure compliance.

In ATLAS, these Activities are initiated through:

Movements. Which concerns physical movement of goods; and/or
Services. Basically any activity that is not a Movement.

An Activity is either a Movement or a Service. Whenever it does not concern a physical Movement of goods, it concerns a Service.

Product registration

As soon as a Product is registered by means of a Parcel, compliance checks are performed to:

validate if the concerned Product falls within the scope of our licenses;
check if certain prohibitions / restrictions apply;
what documents can be expected; and
if the Product may be eligible for a Preferential rate.

The goods are accompanied by various documents, such as one or more bill of lading(s), customs transport documents such as a Transit document and/or e-AD, and other documents, such as origin documents. All documents are stored in our Document Management System with reference to the respective Activity. When data from documents or incoming messages is needed in our business process, this data is registered by means of Cargo Documents. This data is stored with the Parcel.

The Cargo Document functionality enables the capture and recording of data from physical documents or incoming electronic messages required to support business processes from a compliance perspective, with the source document serving as the basis for all entered information.

Movements

When a Movement is planned, the Activity is Released to Ops, triggering validation checks to confirm that all prerequisites for execution, including customs formalities, are in place. Upon this Release to Ops, all customs-relevant Movement data—comprising Parcel data related to the product in the source of the Movement and Parcel data related to the Product in the destination of the Movement —is transmitted to CMS, where the data is validated and subjected to checks. At this stage, the Movement is not yet executed. The checks performed are based on the information available at the time of release to OPS and may differ from the situation at the moment of actual execution. This functionality is therefore purely informative and is intended to highlight any relevant consequences requiring attention prior to execution.

Checks at Release to OPS are based on current data and are informational only, as actual execution may differ, and any resulting consequences requiring attention are highlighted at this stage.

Check at Release to OPS yet to be developed for ETA go-live

When receiving and handling goods at the terminal, the physical flow of goods is done by the start of pumping. Before doing so a mandatory step in the process is the so-called Pre-Check. The Pre-check is the final check done to validate all is in place to allow for the start of an operation, including customs formalities. As soon as this Pre-check is initiated, all data relevant to the Movement from a Customs perspective is send through to CMS via a so-called Transaction. CMS will validate the data, process it and produce all relevant customs declarations and/or records. In response to the Pre-check, CMS will inform the User in ATLAS that the Pre-check is approved and that, from a customs compliance point of view, the operation can commence.

From the Approved status, or any other status, the User can access the CMS page showing the relevant steps. In case of an Error, the User can identify where the error comes from and contact the customs colleagues to resolve any issue.

Services

Unlike Movements, Services are effectively administrative handlings. Because there is no physical pumping, the starting point is not a Pre-check, but the saving of the Service. As soon as a User saves the Service, a message is send to CMS in a similar fashion as the pre-check. In case of error, the Service will not save.

The following Services available in ATLAS relate to Customs compliance:

Take in quantity

When we want to take in a quantity while still on the MoT but at our facility (e.g., Vessel berthed at one of our licensed locations, truck or train available on our fenced facility), as soon as this Service is saved, the Parcel information is sent to CMS and the customs compliance handling is done. CMS will inform the User in ATLAS whether it is Approved yes or no. This way of processing applies to all Services.

Rebrand

This is the registration of a new Product, resulting from a blend process.

Import

This is the Release for Free Circulation.

Administrative Stock Transfer

The application of accounting segregation of our stock on the basis of origin and customs status.

Shifting Service

The moving of a MoT from one location within our Terminal locations to another. All locations are included in our customs licenses, such as jetties by virtue of our address and cadastral information and remote Buoys and/or jetties.

Commodity code correction

In practice there are situations that the sampling of Product result in a different Commodity code that should be used going forward. This is very exceptional, but it does happen. Examples are:

It concerns Products classified mainly on the basis of their aromatic content. Different approved methods apply, whereby the results can be different. We have seen some instances where the different methods lead to slightly different results, but with a difference that does matter for the classification;
Lines are never completely empty. Sometimes this can lead to slight changes in sulphur content for example, where again these minimal changes are decisive for classification purposes.

Hence, this Service allows for the correction and identification at all times.

Departure

When a MoT is loaded and all operations are completed, the MoT is ready to depart. The Departure Service includes the Declare goods to Customs whereby the relevant Parcel details are communicated to CMS and CMS informs the User in ATLAS on approval. When approved, relevant documents such as an Export declaration, Transit document and/or e-AD can be printed, including the emergency procedure versions.

editor_199_5_fa2346f6-ee72-4c7f-9eb5-9af50c6d80f7_rte_image_11.png

The Departure Service includes the Declare goods to Customs whereby the relevant Parcel details are communicated to CMS and CMS informs the User in ATLAS on approval.

editor_199_5_20b9234f-ed9f-473b-9a7a-2ee8f4288326_rte_image_14.png

When approved, relevant documents such as an Export declaration, Transit document and/or e-AD can be printed, including the emergency procedure versions.

editor_199_5_8d7cb060-a804-4106-90aa-222e85135e6a_rte_image_25.png

Terminal Management System

Parcel administration

The parcel administration model distinguishes between three separate business concepts: Product, Parcel, and Stock Keeping Unit (SKU). Although a Parcel may in some situations correspond to a single SKU, these concepts are fundamentally different and can not be treated as interchangeable within the system.

The three layers are defined as follows:

Product – The physical commodity handled at the terminal, such as gas oil, gasoline, or naphtha.
Parcel – The administrative representation of a physical product. A Parcel records characteristics such as commodity code, customs status, origin, cargo documents and, where applicable, consignor or consignee information.
Stock Keeping Unit (SKU) – An administrative unit used for inventory management and record-keeping purposes. SKUs support stock administration but do not define the legal or logistical identity of a Parcel.

Parcel creation for incoming products

For incoming products, the User registers the received physical product by creating one or more Parcels. Each Parcel serves as an administrative reflection of the product and captures attributes such as the commodity code, customs status, and origin.

These attributes alone do not determine the number of Parcels that must be created. Even where multiple quantities of product share identical administrative characteristics, the User may decide to register them as separate Parcels. Consequently, the creation and granularity of Parcels for incoming receipts are driven by the User's administrative requirements rather than solely by the product characteristics.

Parcel creation for outgoing products

The same principle applies to the dispatch of goods. When product is loaded for shipment, the User creates one or more Parcels to represent the administrative distribution of the physical product.

For example, 15,000 MT of gasoline with a T1 (non-Union) customs status may be loaded, with 5,000 MT destined for one terminal and 10,000 MT destined for another. Although both quantities have the same commodity code, customs status, and origin, separate Parcels are created because they are intended for different consignees or destinations and are accompanied by different transport or customs documentation. The User determines the required Parcel structure based on the operational and documentary requirements of the shipment.

The Parcel is defined when Products are registered by the User as these are carried by the Means of Transport including administrative characteristics such as Commodity code, customs status, origin, cargo documents, consignee, etc.

Parcel Administration During Product Movements

For product handling, the creation and movement of Parcels is driven by the physical product being processed and its customs status. In these scenarios, the IT system determines the Parcels based on the administrative composition of the stock being moved.

For example, a Vessel or a tank containing 7,000 MT of gasoil may consist of 3,000 MT with T1 customs status and 4,000 MT with T2 customs status. When more than 4,000 MT is moved, the operation results in the movement of two separate Parcels, reflecting the two different customs statuses.

Where a Parcel contains multiple underlying SKUs, such as SKUs with different origins, the associated SKUs follow the Parcel movement according to the First In, First Out (FIFO) allocation methodology. As a result, the Parcel defines the administrative movement of the product, while the SKUs are allocated within that Parcel in FIFO order to maintain accurate inventory records and traceability.

The administration of Parcels for liquid bulk operations requires a dynamic approach because the physical quantity moved during an operation is not known until the operation has been completed. At the same time, customs legislation requires that goods are declared and presented before the operation takes place, as subsequent blending or commingling may make it impossible to distinguish the originally declared goods.

Initial Parcel determination

Prior to the start of a movement, the IT system determines the Product and the corresponding Parcel or Parcels based on the planned quantity. The determination is performed using the inventory position as it exists immediately before the operation commences.

At this point, the system queries the record keeping to identify all relevant Parcels and their administrative characteristics, including customs status. Based on this assessment, the required customs declarations can be prepared and lodged before the physical movement starts.

The quantity used during this initial assessment is an estimated or planned quantity. The actual transferred quantity cannot yet be established.

Determination of the actual quantity

In liquid bulk operations, the actual moved quantity is established only after completion of the physical operation. The quantity may be determined through:

Tank measurements before and after the operation;
Flow meter readings; or
Weighbridge measurements.

Only after these measurements have been completed can the definitive quantity of Product and the corresponding Parcel allocation be determined.

Retrospective Parcel validation

Once the actual moved quantity is known, the IT system performs a retrospective validation of the Parcel administration. This validation reassesses which Parcels should have been moved based on the inventory situation that existed immediately before the operation started, rather than the inventory situation at the time the reassessment is executed.

This temporal consistency is essential because customs declarations are based on the goods that were presented immediately prior to the operation. Consequently, the reassessment must use the same point-in-time inventory snapshot as the initial determination.

In practice, the Product already present in the receiving tank is treated as a fixed condition that existed before the movement and therefore remains unchanged for purposes of the reassessment.

Once the moved quantity has been measured, the final quantity is established and the circumstances of the Activity are reassessed retrospectively based on the situation as it existed at the start of execution.

Parcel identity and corrections

Each Parcel must have a unique reference that identifies the represented Product and its associated customs status. This unique reference should remain unchanged between the initial assessment before the operation and the retrospective validation after completion.

In most cases, the retrospective validation will confirm the initial Parcel determination, with only the moved quantity requiring adjustment. In exceptional circumstances, however, the final measured quantity may lead to a different Parcel composition than originally anticipated. For example, an operation initially expected to involve a single Parcel may ultimately require two Parcels because the final quantity spans different customs status boundaries, or vice versa. As a result, customs declarations may in some cases not be lodged prior to the start of the operation, or may in hindsight have been created when they were not required.

In such cases, the IT system must correct the Parcel administration and any associated customs declarations while preserving the original assessment timestamp representing the moment immediately before the operation commenced. This ensures both an accurate inventory administration and a legally consistent customs audit trail.

Customs compliance risk is controlled at Product entry (license validation), while operational accuracy is ensured retrospectively through measured quantities and Parcel reconciliation.

In the near future it is expected that declarations for certain Products must be declared real-time via the Normal procedure instead of by means of Entry Into the Declarants Record (EIDR). In that case correction will be more cumbersome!

Customs declaration validation

During the preparation of an Activity, the system determines the customs obligations associated with the identified Parcel(s). This includes identifying the required customs procedure based on the Product characteristics, including commodity code and customs status.

As part of this process, the system validates whether the Parcel(s) involved in the Activity have already been declared under the required customs procedure. If a Parcel has already been covered by an existing declaration for the applicable procedure, no new declaration is created for that Parcel within the scope of the Activity.

This validation ensures that customs declarations are only created where necessary and prevents duplication of declarations for Parcels that have already been correctly declared under the relevant customs regime.

Compliance management

Outlining the principles and the working of the CMS.

Compliance management

Customs Procedure Operation

Each Parcel may require a different customs treatment, depending on the type of Operation performed. For that purpose, the first assessment done by CMS is determining the Customs procedure applicable to the Operation. This is done on the following basis:

Basically, when two Products mix, a distinction is made between Blends that involve Bonded goods and Blends that don't.

Blends not involving Bonded Product

In this case, the determination of whether the Operation concerns a Blend depends on whether or not the 8-digit Commodity Code of the products involved is the same. If yes, then the Operation relates to manufacturing. The type of manufacturing is dependent on the Customs status / Type of goods, where, when it involves Excise controlled Product, it is considered Manufacturing under Excise warehouse. When it involves only Domestic (i.e. not Excise controlled) Product then it is considered manufacturing under Free warehouse.

Upon registration of the Blend, the Customs status / Type of goods of the end Product determine the qualification of Manufactured under Excise warehouse for Excise controlled or Manufactured under Free warehouse for Domestic.

Blends including Bonded product

When a Blend does involve Bonded product, a check is done on the Commodity code on a 9-digit level. The reason for looking at the first 9 digits is that this relates to physical characteristics of Products that say something about the quality. For example, 2710 1948 10 versus 2710 1948 90 is different on the basis of sulphur content. 2710 1942 21 versus 2710 1942 29 is, respectively, "Consigned from Canada" and "other". Both paraffinic gas oils. Hence, the 10th digit relates to statistical information and not the physical characteristics.

When the Commodity codes are not the same on a 9-digit level, the Customs Procedure Operation is Inward processing, or, in specific cases a Usual Form of Handling. A Usual Form of Handling requires both the base Product and the Additive to be marked in the product database of CMS as Usual form of Handling.

When the 9-digit Commodity codes are the same, it could still be that the products involved are considered Products of a different quality. This is identified by Quality groups assigned to Products in the Product database in CMS. These quality groups are indicated by the Customer, the owner of the product, having extensive knowledge on quality. In case there are Quality groups assigned to the Parcels involved, then in case they are different, the result is a Blend and the customs procedure Inward Processing applies. In case no Quality Groups are available, the distinction is made on the basis of the (commercial / operational) Product name.

In case the Commodity code on 9-digit level is the same AND the Quality Groups (or Product names) of the Parcels are the same, then, in principle, the result is the Customs procedure Storage for the Operation. An exception to this rule is when it concerns both Bonded and non-Bonded / Union (i.e., Excise controlled or Domestic) Products AND the Bonded Products are subject to preliminary or definitive Anti-Dumping or Countervailing duties. In that case the Products, by law, may not be considered the same Commercial quality and hence it results in a Blend. As a result, the customs procedure Inward processing applies.

In any case, where the result of the assessment is a Customs Blend, where it involves both Bonded and non-Bonded, the User is informed that the operation will result in all Union goods becoming Bonded and the User must actively confirm its intentions.

Compliance management

Business rules

Before starting an operation, the Products involved are declared when required. The determination on what Customs declaration(s) or records are required is based on implemented business rules. For each Transaction coming from ATLAS, the analysis and execution is made available to the user via a screen as included below (Transaction details). Here the User can see what happened from a Customs point of view and find information relating to the Results.

Business rules

In the example above, the Product received is of the Bonded Customs status, discharged into a Tank containing the same Product. Therefore, the result is Storage. The applicable business rule in this case reads as follows:

editor_199_5_ebe077ca-0ed9-49fa-958f-9a2ec60d3bfa_rte_image_461.png

The first condition relates to the assessment of the Customs procedure for the operation. In this example, all Parcels are of the same Commodity code AND have the same Quality group "High aromatic oils" not Bonded Product subject to CPM. Hence, the result for the Customs Procedure Operation is Storage;
The Product declared is of the T1 - Bonded Customs status;
It is the first time the product on board of the Vessel arrives at the Terminal. This is recognized by the System on the basis of the Parcel not having a Parent reference. In case a parcel has a Parent reference, that means the Parcel comes from another Parcel we have registered before and hence, it is not the first time arrival;
The Activity type is a Movement.

For the Product on board of the Vessel, all of the above conditions required are met and hence the goods are declared for Customs warehouse via EIDR. As required in relation to the EIDR, a NoP is send.

For the Product in tank, the criteria of "First time arrival" is not met and hence, the business rule does not apply. In the above example, the Parcels have already undergone this process at an earlier stage and are currently under Customs warehouse already for the Bonded Parcels and Free warehouse for the non Bonded Parcels.

Compliance management

Customs declarations or records

The outcome of the business rules define what customs declarations are lodged or what records are recorded. In terms of declarations for the application of customs procedures, the main rule is that declarations are done by means of EIDR. Exceptions to this main rule are:

Export declarations (B1 and B4). These are done via the normal procedure; and
In case preferred or required by law the Import declaration (H1).

Simplified Declarations (I1)

Any declaration for the application of customs procedures, excluding Export, is done simplified, regardless of the way the declaration is done (i.e. via EIDR or normal procedure). Inherent to the nature of our business is that at the moment of declaring the goods, only planned quantities are known.

Supplementary Declarations (H.)

Any simplified declaration goes into our supplementary declaration process after entry into the record. Once the quantities are measured and final, ATLAS sends through the ACTUAL figures, and the supplementary declaration is created. The supplementary declarations for Inward processing and Release for Free Circulation are automatically sent in within 10 days after the entry. Below an example of the Processed Supplementary Declaration page:

editor_199_5_09e4326f-a798-4d2d-b393-c6282c5ac113_rte_image_634.png

All Declarations are available content wise from the Transaction Details page, the Declaration overview Page and the Supplementary declaration page. This includes an overview of the messaging and options for a User to utilize with regards to the specific Declaration. Below an example of the part of the Transaction Details Page where the Declarations are listed.

editor_199_5_0351481c-20ae-457d-9efd-4f92f859fd36_rte_image_586.png

The Declarations can be selected to go to the Declaration details page.

editor_199_5_cc907227-a26f-4b18-8d90-f99e79504f7d_rte_image_591.png

Content declarations

The content of the declarations is determined on the basis of:

Input from the User on the basis of information received from the Customer via the Nomination. Such as the Product and its Commodity Code, the Customs status, the origin, the customs value, etc.;
The application of business rules. For example, in case of a Release for Free Circulation the procedure codes are determined on the basis of certain parameters. Below we have included an example where the Current Procedure Code is dictated by the fact that it concerns Excise controlled goods and the Previous Customs Code is based on the fact that it concerns goods coming from IP.
Defaults for Measure Types. Below some examples of default values for Measure Types, used in the event such Measure Type is applicable for the product declared.

editor_199_5_649e9067-d248-4bef-a7ac-1b6c8c702136_rte_image_624.png

Reporting

This Chapter provides an overview of the primary reporting in CMS.

Reporting

Monitoring licenses

For the Customs warehouse and Inward processing license, the quantities and amounts licenses are monitored automatically. Each time a declaration is done under the respective procedure, the quantities and amounts are set off against the licensed quantity.

Customs warehouse monitoring

editor_199_5_752514db-7877-44e9-9116-ff39141976ab_rte_image_661.png

Inward Processing monitoring

Reporting

Bill of Discharge

For Inward Processing the discharge of the procedure is always by means of a Customs warehouse declaration. Each Inward Processing declaration is monitored via the Bill of discharge screen where the Product declared for Inward Processing is matched with the same Parcel(s) being, subsequently, declared for Customs warehouse. As it can very well be that T2 Products are used in an Inward Processing blend, not requiring an Inward Processing license, the full quantity of the specific Customs warehouse declaration may exceed the quantity of an Inward processing declaration. It could also be that multiple Inward processing declarations are discharged by the same Customs warehouse declaration. Below an example of the Bill of discharge screen.

editor_199_5_859249e6-e23f-475b-a1da-41f20161fa29_rte_image_703.png

Reporting

Detailed Stock Management

For internal audit purposes we have developed the so-called Detailed Stock Management (DSM) report. The DSM report shows all relevant data related to the Products we handle and the Declarations we have lodged. The data set is a combination of data coming from CMS, which relates to all Transactions communicated by ATLAS to CMS, and data coming from ATLAS. This concerns data that is not part of the data set communicated via the Transactions from ATLAS, such as stock density corrections, opening and closing balance, etc.

editor_199_5_503878fd-9be2-4492-8d63-af8e5945fece_rte_image_724.png

Business rules and mutations

Apart from the physical Movements, the data set also includes the accounting for the goods under the various customs procedures / regimes. For this purpose, each business rule includes Mutations. Below we have included an example of a discharge that leads to the placing of the goods under the Customs warehouse procedure, directly followed by the placing under the Inward Processing procedure. This means a physical Movement leads to a + in the Customs warehouse, which is directly depleted (-) and followed by a + under Inward Processing.

editor_199_5_8d043583-33b6-4d21-8fbe-536b6e414022_rte_image_753.png

When such blend would be completed and registered by means of a Rebrand Service (i.e. registration of the blend), it would result in the placing of the End product under the Customs warehouse procedure again, coming from the Inward Processing procedure. Mutation wise this means the depletion (-) of the components and a + for the newly registered product as processed good under Inward Processing, which subsequently is depleted (-) under Inward Processing and placed under the Customs warehouse procedure (+).

editor_199_5_a89f2c39-bb8c-4f2b-821d-2c377d6cef82_rte_image_754.png

These mutations can be summarized in the following overview.

The DSM report forms the 'single version of the truth, where all other reporting is always based on the data showing in the DSM. In the event that any report requested should include data not included in the DSM, then it will be added to the DSM first and from there added to any subsequent report.

Reporting

Audit file

The Audit File Voorraad is a report required by the Dutch Customs authorities, in which all relevant information in relation to the inventory and customs declarations is listed in a specific format as specified in the MIG. Effectively, the Audit File is a translation of the data coming from our DSM report into a specific format.

With the available test environments, proper testing of the Audit File was not possible. Furthermore, we started with CMS (V1) connected to our legacy TMS Tomcat. As the building of Audit File is quite substantial and given the dependency on the source system, we have a agreed with Customs to not invest in developing Audit File under Tomcat - CMS V1 as Tomcat is shortly being discontinued. Under Tomcat-V1 we still have the GPA available safeguarding the record keeping requirements.

ATLAS has only gone live since the 1st of December 2025. It is since then that we could properly test the data becoming available in the Audit File report. Although the Audit File report has been available from a technical point of view, we are currently finalizing the population of the various tables with the correct data. Below we have include the current status and the parts that we are working on.

Completed

Full Technical report - To be validated by the Customs authorities;
All data related to discharges and loads;
Transaction Associated Documents. All documents for the declaration systems DMS, NCTS, and EMCS are included in the audit file.

From the Audit File report page the Audit file can be generated for a specific month.

editor_199_5_35404b1a-94d0-4c09-91d1-7959e11ba276_rte_image_288.png

Once created, the report becomes available in draft.

editor_199_5_23e47663-5af1-4990-8630-ff7aad206036_rte_image_297.png

Under the three dots the report can be finalized, after which the period will also be blocked. under Downloads the file can be downloaded to share with the Customs authorities.

editor_199_5_e48a2f93-5b8c-4e7c-a843-53baabc8946e_rte_image_311.png

To be completed

Balance data (inv_period_balance)

Records with location type INLAND_WATER. This concerns vessels that have been loaded or discharged at our site. In these cases there is no opening or closing stock (beginning_quantity and ending_quantity). The question is whether we should include received and dispatched quantities. From the terminal’s perspective, this is a kind of storage location. We will report Product as stock in cases where, in case of incoming, we have declared goods on board without a movement. The same principle applies to loads as long as there is no completed Departure. We assume in other cases, where we have not taken any responsibility for the products (yet) no reporting is required?
For trains, blending takes place on the wagon. The wagon receives base product and additive, after which the end product is dispatched. The additional rows (mutations) that are required to track the transfer between procedures (USF – usual form of handling) still require implementation in Audit File.
Inventory should reconcile per row (ending_quantity = beginning_quantity + received_quantity – dispatched_quantity). This currently not yet the case. For cust_transfers (production (ETW), inward processing, and usual form of handling), the additional rows (mutations) that are required to track the transfer between procedures needs implementation in the audit file. The data required for this is already available in our detailed_stock_movements_cu table. This concerns movements between procedures.
Movements between tanks (tank-to-tank transfers) are not fully completed yet. Also here the mutations need implemetation into the Audit File.

Transactions (inv_transaction and inv_transaction_char)

Tank-to-tank movements have not yet been included in the audit file. The required setup in the business rule mutation configuration has not yet been added to Audit File.
Due to the missing setup of the mutations, the chain that allows goods to be traced from CPW to IPR, IPR production, and back to CPW is not yet fully implemented. This also applies to USF (usual form of handling).
In the case of a density correction, we set the value CT in the characteristic NL_CUST_TRANSFER. However, this does not correspond to the description (“correction due to temperature difference”). The code CT seemed the most appropriate to us.

Products (inv_product and inv_product_char)

New goods that are created through blending require implementation of the mutations (see comment under Transactions regarding IPR and USF).

Transaction Associated Documents

The other documents mentioned in code list 6 (codelist trans.submsyst) and code list 6 (codelist document code) are still being reviewed by us to determine whether they are applicable to our situation.

Points of attention

The specifications mention a number of columns and characteristics required to track goods with regard to movements (between procedures). We are testing whether this works correctly in all cases. The plan is to create an automated check for this in the future.
During the Deloitte GTA session on Thursday, 20 November, Customs indicated in their presentation what types of validations/checks they perform on the submitted data. Building similar checks is on our roadmap.

Technical specifications

To include

Technical specifications

Main communication Source system to CMS - Transaction JSON

The Transaction JSON is the standardized interface used by the source system to communicate business and operational data to the customs management system. It contains all relevant information relating to a logistics activity, such as the movement of goods, transport details, involved parties, storage locations, and the products or parcels that are part of the transaction.

The information contained in the Transaction JSON serves as the primary input for the creation of customs declarations and other compliance-related processes. Each message must accurately represent the underlying business transaction and include all data required to determine the correct customs treatment of the goods.

The quality, completeness, and timeliness of the data provided are critical. Incorrect, incomplete, or delayed information may result in inaccurate customs declarations, non-compliance with customs legislation, delays in the supply chain, financial penalties, or increased audit risks.

It is therefore the responsibility of the source system and the data provider to ensure that:

all mandatory data elements are populated correctly;
the information reflects the actual business transaction and physical movement of the goods;
product and parcel details, including commodity classifications, origin, quantities, and supporting documents, are accurate and up to date;
changes affecting the transaction are communicated promptly to the customs management system.

By providing reliable and timely Transaction JSON messages, organizations can support compliant customs processes, minimize operational risks, and ensure efficient processing of import, export, transit, and storage activities.

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`sourceApplication`	Source System	System from which the data originates.	Yes	Internal integration	ATLAS
`terminal`	Terminal	Terminal or operational location where the goods are handled.	Yes	Terminal Operator / WMS	ETT
`reference`	Movement Reference	Unique reference for the movement or customs transaction.	Yes	ERP / WMS	PR_ACTI_AC10007466
`displayReference`	Display Reference	Human-readable reference shown to users.	Yes	ERP	AC 007 466
`taxCountry`	Customs Country	Country where the customs process takes place.	Yes	ERP	NL
`cmsReference`	CMS Reference	Internal customs management reference.	Yes	Internal system	530E2446-…
`overrideCheckAlert`	Override Indicator	Indicates whether validation warnings have been overridden.	Yes	Internal system	Y
`presentationDateTime`	Presentation Date & Time	Date and time when goods are presented to Customs.	Yes	Terminal / WMS	2026-05-30T20:59:17Z

Activity

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`activities.reference`	Activity Reference	Unique identifier of the activity.	Yes	ERP	PR_ACTI_AC10007466
`activities.displayReference`	Activity Display Reference	User-friendly activity number.	Yes	ERP	AC 007 466
`activities.activityType`	Activity Type	Type of activity. Movement or Service.	Yes	ERP	MOVEMENT
`activities.nominationReference`	Nomination Reference	Unique identifier of the activity nomination.	Conditional	Scheduling system	NM 004 824
`activities.relatedReference`	Related Reference	Reference to a related movement.	No	ERP	—

Storage Unit / Transport

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`medium.type`	Movement Direction	Indicates source or destination storage.	Yes	WMS	FROM_STORAGE_UNIT
`storageUnit.storageUnitReference`	Storage Unit Reference	Identifier of the storage location.	Yes	WMS	VS10003221:1
`visit.visitReference`	Visit Reference	Identifier of terminal visit of the means of transport.	Conditional	Terminal system	VS 003 221
`visit.transportMeansReference`	Transport Means Name	Name of vessel or vehicle.	Yes	Shipping documents	MARAN WIND
`visit.transportMeansTypeCode`	Transport Means Type	Mode of transport code.	Yes	Shipping documents	VES
`visit.transportMeansNationalityCode`	Transport Means Nationality	Registration or flag country.	Conditional	Shipping documents	BS
`tank.tankName`	Tank Name	Receiving or storage tank identifier.	Conditional	Terminal / WMS	T08

Goods Item (Parcel)

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`parcels.reference`	Goods Item Reference	Unique goods item identifier.	Yes	ERP	2605/SKU20:59…
`parcels.parentReference`	Parent Reference	Parent goods item reference.	No	ERP	2605/SKU08:07…
`parcels.firstTimeArrival`	First Arrival in EU	Indicates first arrival into the EU customs territory.	Conditional	Customs process	Y
`parcels.inwardProcessingFlag`	Inward Processing	Indicates Inward Processing procedure.	Conditional	Customs department	N
`parcels.commercialPolicyMeasureFlag`	Commercial Policy Measure	Indicates trade policy measures apply.	Conditional	Customs department	N
`parcels.exceptionDocument`	Exception Document	Supporting exemption document reference.	Conditional	Compliance	—

Customer Information

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`parties.customer.reference`	Customer Code	Internal customer identifier.	No	ERP	COMP
`parties.customer.name`	Customer Name	Name of importer/exporter.	Yes	Master data	Company A
`parties.customer.eori`	EORI Number	EORI registration number.	Yes	Master data	NLXXX
`parties.customer.vatNumber`	VAT Number	VAT registration number.	Conditional	Master data	NLXXX
`parties.customer.language`	Preferred Language	Customer language.	No	Master data	NL
`parties.customer.address.streetName`	Street	Customer street name.	Yes	Master data	Weena
`parties.customer.address.houseNumber`	House Number	Customer house number.	Yes	Master data	690
`parties.customer.address.postalCode`	Postal Code	Customer postal code.	Yes	Master data	3012CN
`parties.customer.address.cityName`	City	Customer city.	Yes	Master data	Rotterdam
`parties.customer.address.countryCode`	Country	Customer country.	Yes	Master data	NL
`parties.customer.cbsCode`	Statistical Code	Statistical reporting code.	No	Master data	49933
`parties.customer.locationName`	Location Name	Named business location.	No	Master data	—

Goods Location

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`location.address.streetName`	Goods Location Street	Street where goods are located.	Yes	WMS	Moezelweg
`location.address.houseNumber`	Goods Location House Number	House number.	Yes	WMS	151
`location.address.postalCode`	Goods Location Postal Code	Postal code.	Yes	WMS	3198 LS
`location.address.cityName`	Goods Location City	City of storage.	Yes	WMS	Europoort Rotterdam
`location.address.countryCode`	Goods Location Country	Country where goods are stored.	Yes	WMS	NL
`location.cbsCode`	Goods Location Statistical Code	Statistical location code.	No	WMS	325
`location.locationName`	Goods Location Name	Name of warehouse or facility.	No	WMS	—

Country Information

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`destinationCountryCode`	Country of Destination	Final destination country.	Yes	Commercial documents	NL
`dispatchCountryCode`	Country of Dispatch	Country from which goods are dispatched.	Yes	Commercial documents	GB
`origin.type=NON-PREFERENTIAL.countryCode`	Non-Preferential Origin	Customs country of origin.	Yes	Supplier declaration	GB
`origin.type=PREFERENTIAL.countryCode`	Preferential Origin	Preferential origin under trade agreement.	Conditional	Origin certificate	—

Commodity Information

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`commodity.code`	Commodity Code	HS/CN/TARIC classification.	Yes	Product master	2709009000
`commodity.description`	Commodity Description	Commercial description of goods.	Yes	Product master	Kraken Crude Oil
`commodity.reference`	Product Reference	Internal product identifier.	No	Product master	—
`customsStatus`	Customs Status	Customs status of the goods.	Yes	Customs/WMS	BONDED

Supporting Documents

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`cargoDocuments.type`	Document Type	Type of supporting document.	Conditional	Shipping documents	B_L
`cargoDocuments.reference`	Document Reference	Reference number of the document.	Conditional	Shipping documents	003 221
`cargoDocuments.quantities.kgv`	Document Gross Weight	Gross weight on document.	Conditional	Bill of Lading	33,000,000
`cargoDocuments.quantities.l15`	Document Volume @15°C	Standard volume on document.	Conditional	Bill of Lading	33,863,520
`cargoDocuments.quantities.mtv`	Manifest Quantity	Quantity from manifest.	Conditional	Cargo manifest	33,000,000

Quantity Information

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`quantities.type`	Quantity Type	Actual or estimated quantity.	Yes	Measurement system	ACTUAL
`quantities.kgv`	Gross Weight (kg)	Gross weight including packaging.	Yes	Weighbridge / WMS	5,501,823
`quantities.kga`	Net Weight (kg)	Net weight excluding packaging.	Yes	Weighbridge / WMS	5,495,622
`quantities.gmv`	Gross Mass Volume	Gross mass volume, where applicable.	Conditional	Measurement system	—
`quantities.gma`	Actual Gross Mass	Measured gross mass.	Conditional	Measurement system	—
`quantities.l15`	Volume @15°C	Volume corrected to 15°C.	Conditional	Metering system	5,636,892
`quantities.l20`	Volume @20°C	Volume corrected to 20°C.	Conditional	Metering system	5,655,158
`quantities.ml5`	Alcohol Volume @5°C	Alcohol volume at 5°C.	Conditional	Laboratory	—
`quantities.alcPerc`	Alcohol Percentage	Alcohol strength by volume.	Conditional	Laboratory	—

Product Characteristics

JSON Field	Business Name	Description	Mandatory	Customer Data Source	Example Value
`density.value`	Density	Measured product density.	Conditional	Laboratory	0.845
`density.uom`	Density Reference	Reference basis for density measurement.	Conditional	Laboratory	D15
`unNumber`	UN Number	Dangerous goods UN classification number.	Conditional	Safety Data Sheet (SDS)	1203

Example JSON structure

{
"sourceApplication": "ATLAS",
"terminal": "ETT",
"reference": "MVM000012345",
"displayReference": "MVM 012 345",
"taxCountry": "NL",
"cmsReference": "12345678-ABCD-1234-EFGH-987654321000",
"overrideCheckAlert": "N",
"presentationDateTime": "2026-01-15T10:30:00Z",
"activities": [
{
"reference": "MVM000012345",
"displayReference": "MVM 012 345",
"activityType": "MOVEMENT",
"nominationReference": "NOM00056789",
"relatedReference": null,
"medium": [
{
"type": "FROM_STORAGE_UNIT",
"storageUnit": {
"storageUnitReference": "STORAGE_A01",
"visit": {
"visitReference": "VISIT001234",
"transportMeansReference": "MV EXAMPLE STAR",
"transportMeansTypeCode": "VES",
"transportMeansNationalityCode": "NL",
"changedTransportArrangement": null
}
},
"parcels": [
{
"reference": "PARCEL000001",
"parentReference": null,
"firstTimeArrival": "Y",
"inwardProcessingFlag": "N",
"commercialPolicyMeasureFlag": "N",
"exceptionDocument": null,
"parties": {
"customer": {
"reference": "CUST001",
"name": "Example Trading B.V.",
"eori": "NL123456789000",
"vatNumber": "NL123456789B01",
"language": "EN",
"address": {
"cityName": "Rotterdam",
"countryCode": "NL",
"streetName": "Example Street",
"postalCode": "3011AA",
"houseNumber": "100"
},
"cbsCode": "12345",
"locationName": "Head Office"
}
},
"location": {
"language": "EN",
"address": {
"cityName": "Rotterdam",
"countryCode": "NL",
"streetName": "Harbour Road",
"postalCode": "3199AA",
"houseNumber": "1"
},
"cbsCode": "325",
"locationName": "Tank Farm A"
},
"destinationCountryCode": "NL",
"dispatchCountryCode": "US",
"origin": [
{
"type": "NON-PREFERENTIAL",
"countryCode": "US"
},
{
"type": "PREFERENTIAL",
"countryCode": null
}
],
"commodity": {
"code": "2709009000",
"description": "Crude Petroleum Oil",
"reference": "MAT-0001"
},
"customsStatus": "BONDED",
"cargoDocuments": [
{
"type": "B_L",
"reference": "BL123456789",
"quantities": [
{
"kgv": 1000000,
"l15": 1185000
}
]
},
{
"type": "MANIFEST_INFO",
"reference": "MANIFEST001",
"quantities": [
{
"mtv": 1185000
}
]
}
],
"unNumber": "1267",
"quantities": [
{
"kgv": 1000000,
"kga": 995000,
"gmv": null,
"gma": null,
"l15": 1185000,
"l20": 1192000,
"ml5": null,
"alcPerc": null,
"type": "ACTUAL"
}
],
"density": {
"value": 0.840,
"uom": "D15"
}
}
]
},
{
"type": "TO_STORAGE_UNIT",
"storageUnit": {
"storageUnitReference": "TANK_101",
"tank": {
"tankName": "Tank 101"
}
},
"parcels": [
{
"reference": "PARCEL000002",
"parentReference": "PARCEL000001",
"firstTimeArrival": "N",
"inwardProcessingFlag": "N",
"commercialPolicyMeasureFlag": "N",
"exceptionDocument": null,
"parties": {
"customer": {
"reference": "CUST001",
"name": "Example Trading B.V.",
"eori": "NL123456789000",
"vatNumber": "NL123456789B01",
"language": "EN",
"address": {
"cityName": "Rotterdam",
"countryCode": "NL",
"streetName": "Example Street",
"postalCode": "3011AA",
"houseNumber": "100"
},
"cbsCode": "12345",
"locationName": "Head Office"
}
},
"location": {
"language": "EN",
"address": {
"cityName": "Rotterdam",
"countryCode": "NL",
"streetName": "Harbour Road",
"postalCode": "3199AA",
"houseNumber": "1"
},
"cbsCode": "325",
"locationName": "Tank Farm A"
},
"destinationCountryCode": "NL",
"dispatchCountryCode": "US",
"origin": [
{
"type": "NON-PREFERENTIAL",
"countryCode": "US"
},
{
"type": "PREFERENTIAL",
"countryCode": null
}
],
"commodity": {
"code": "2710194300",
"description": "Gas Oil",
"reference": "MAT-0002"
},
"customsStatus": "BONDED",
"cargoDocuments": [],
"unNumber": "1202",
"quantities": [
{
"kgv": 500000,
"kga": 497500,
"gmv": null,
"gma": null,
"l15": 595000,
"l20": 598000,
"ml5": null,
"alcPerc": null,
"type": "ACTUAL"
}
],
"density": {
"value": 0.835,
"uom": "D15"
}
}
]
}
]
}
]
}

Technical specifications

Business rules to determine customs declarations required for all Products involved in the Activity

1. Overall Structure of the Rules

All business rules follow a consistent pattern:

Rule Logic

Each rule is evaluated using:

IF → starting condition
AND / OR → additional conditions
Conditions are based on:
- Customs status (e.g. BONDED, EXCISE_CONTROLLED, DOMESTIC)
- Destination (EU, EFTA, non-EU, special territories)
- Activity type (MOVEMENT, TAKE_IN, DEPARTURE, etc.)
- Procedure (EXPORT, RE-EXPORT, STORAGE, INWARD_PROCESSING, etc.)
- Flags (e.g. first arrival, monthly approval)

Rule Outcome

Each rule determines:

Required customs procedure
Required documents
Required system message / record
Final warehouse or closing process

2. Export Rules (Functional Description)

Export rules are primarily driven by:

Customs status of goods
Destination
Transport specifics
Excise applicability

2.1 Excise-Controlled Goods (AAD)

Scenario

Goods are under excise suspension and must remain controlled during movement.

Functional Logic

IF goods are excise controlled
AND movement is export
THEN apply excise + customs requirements depending on destination

Outcomes by Destination

A. Export to Non‑EU

Documents:
- e-AD (excise)
- Export declaration (EX A - B1)
Logic:
- e-AD is discharged by export declaration
- Export declaration is discharged by confirmation of exit
Purpose:
- Maintain excise suspension until exit

B. Export to EFTA+

If no transit possible (sea-only routes):
- Same as non-EU export
If transit required (crossing EU):
- Add Transit document (T2)
- Export → Transit sequence

C. Export to Special Territories (Customs / VAT Exceptions)

Different combinations lead to B4 declarations:

Territory Type	Outcome
Customs territory only	Export (B4) + T2LF
Customs + Excise	Export (B4) + T2LF
Customs + Excise + VAT	No export declaration

D. Movement within EU

Standard case:
- e-AD required
Exception (VAG):
- Monthly declaration replaces e-AD

E. Pipeline Transport (Excise Goods)

If monthly approval:
- VAGD (monthly declaration)
- No e-AD

2.2 Domestic (Free Circulation) Goods

Scenario

Goods are not subject to excise.

Functional Logic

IF goods are DOMESTIC
AND movement is export

Outcomes

A. Export to Non‑EU

Document: Export declaration (B1)
No e-AD required
Proof of exit discharges liability

B. Export to EFTA+

Same as export to non-EU
Transit applies if crossing EU:
- Add T2 transit document

C. Export to Special Territories

Use B4 declaration
Add T2LF or T2L to prove Union status

D. Movement within EU

No customs declaration
Goods remain in free circulation

E. Pipeline Transport

No customs requirements

2.3 Bonded Goods (T1 – Non-Union)

Scenario

Goods are not in free circulation and require customs supervision.

Functional Logic

IF goods are BONDED
AND procedure is RE-EXPORT or movement

Outcomes

A. Re-export to Non‑EU

Document: Re-export declaration (B1)
Confirmation of exit required

B. Re-export to EFTA+

Without transit → same as above
With EU crossing:
- Add Transit document (T1)

C. Movement within EU

Transit procedure (T1) mandatory

D. Internal Movement (VAG Exception)

No transit declaration
Use VAG document

E. Pipeline Transport

Considered automatically under transit
No T1 document required

3. Import Rules (Functional Description)

Import rules are driven by:

Customs procedure
Customs status
First arrival vs subsequent movements
Operational activity (storage, blending, processing)

3.1 First Arrival of Bonded Goods

A. Storage (No processing)

Condition:
- First arrival = YES
- No blending
Outcome:
- Entry into Customs Warehouse
- Notification of Presentation

B. Usual Forms of Handling (UFH)

Condition:
- Blending allowed under warehouse rules
Outcome:
- Remains under Customs Warehouse
- Classified as UFH

C. Inward Processing

Condition:
- Blending requiring processing license
Outcome:
- Customs Warehouse → Inward Processing
- Requires additional declaration

3.2 Subsequent Movements (After First Arrival)

A. Inward Processing

Applies when:
- Goods are blended with other qualities
Outcome:
- Declared under Inward Processing

B. Usual Forms of Handling

Applies when:
- Blending fits UFH criteria
Outcome:
- Remains within Customs Warehouse

3.3 Administrative Stock Transfers

Purpose

Avoid physical segregation using accounting reallocation.

Logic

IF activity = Administrative Stock Transfer
AND target status includes BONDED

Outcome

Reallocation of customs status:
- From Bonded → Excise or Domestic (or vice versa)
No physical movement required

3.4 Release for Free Circulation (General Concept)

Converts T1 (non-Union) → T2 (Union goods)
May:
- Trigger customs debt
- Transfer goods into:
  - Free warehouse
  - Excise warehouse

3.5 Excise Warehouse Handling

For excise-controlled goods:
- Entry into excise warehouse
- Possible:
  - Storage
  - Manufacturing
  - Blending

3.6 Internal Activities

A. Shifting

Internal movement within same warehouse
No customs impact

B. Rebranding

Creates new product identity
Typically remains under same procedure

C. Commodity Code Correction

Administrative correction
May impact:
- Customs classification
- Warehouse allocation

4. Key Concepts Across All Rules

Customs Status Types

BONDED (T1): Non-Union goods
EXCISE_CONTROLLED: Goods under excise suspension
DOMESTIC (FRE): Union goods in free circulation

Core Procedures

Export / Re-export
Transit (T1 / T2)
Customs Warehouse
Excise Warehouse
Inward Processing
Usual Forms of Handling

Exception Mechanisms

VAG / VAGD: Monthly declarations replacing standard documents
Pipeline transport: Simplified treatment
Administrative stock transfer: Accounting-based status change

Document Types

e-AD: Excise movement
EX A (B1/B4): Export declaration
T1 / T2: Transit
T2L / T2LF: Proof of Union status
VAG / VAGD: Monthly declaration

5. Simplified Rule Classification

Category	Key Driver	Outcome
Export	Destination + status	Export / Transit / e-AD
Import	Procedure + activity	Warehouse / Processing
Exception	Approval flags	Simplified procedure
Internal	Activity type	No declaration or reassignment

6. Key Takeaway

The entire rule engine can be summarized as:

Determine the customs status + movement type + destination → select the correct procedure → generate the required documents → ensure proper discharge (exit, transit, or warehouse accounting).

Technical specifications

Business rules overview CMS

Code	Title	Result	(Customs) procedure result (Closing record)	Conditions
IMP_BR01	Bonded goods – First arrival, storage in Customs Warehouse	NOP:IE507	CUSTOMS_WAREHOUSE	• Customs procedure operation = STORAGE • Status = BONDED • First arrival flag = Y • Activity type = MOVEMENT / TAKE_IN
IMP_BR02	Bonded goods – First arrival with UFH	NOP:IE507 + CW:UFH	USUAL_FORMS_OF_HANDLING	• Customs procedure operation = USUAL_FORMS_OF_HANDLING • Status = BONDED • First arrival flag = Y • Activity type = MOVEMENT
IMP_BR03	Bonded goods – First arrival with Inward Processing	NOP:IE507 + IP:IE015	INWARD_PROCESSING	• Customs procedure operation = INWARD_PROCESSING • Status = BONDED • First arrival flag = Y • Activity type = MOVEMENT
IMP_BR04	Administrative stock transfer – Excise controlled goods to Bonded	ADMIN (No message)	N/A	• Activity type = ADMINISTRATIVE_STOCK_TRANSFER • Status = EXCISE_CONTROLLED • Transferred customs status contains BONDED
IMP_BR05	Administrative stock transfer – Domestic goods to Bonded	ADMIN (No message)	N/A	• Activity type = ADMINISTRATIVE_STOCK_TRANSFER • Status = DOMESTIC • Transferred customs status contains BONDED
IMP_BR06	Bonded → Inward Processing (to storage unit)	IP:IE015	INWARD_PROCESSING	• Customs procedure operation = INWARD_PROCESSING • Status = BONDED • First arrival flag = N • Previous closing record ≠ INWARD_PROCESSING • Activity type = MOVEMENT • Medium type = TO_STORAGE_UNIT
IMP_BR06A	Bonded → Inward Processing (from storage)	IP:IE015	INWARD_PROCESSING	• Customs procedure operation = INWARD_PROCESSING • Status = BONDED • First arrival flag = N • Previous closing record ≠ INWARD_PROCESSING • Activity type = MOVEMENT • Medium type = FROM_STORAGE_UNIT
IMP_BR07	Bonded goods – UFH (subsequent movement)	CW:UFH	USUAL_FORMS_OF_HANDLING	• Customs procedure operation = USUAL_FORMS_OF_HANDLING • Status = BONDED • First arrival flag = N • Previous closing record ≠ USUAL_FORMS_OF_HANDLING • Activity type = MOVEMENT • Medium type = TO_STORAGE_UNIT
IMP_BR07A	Rebrand after UFH	CW (update)	CUSTOMS_WAREHOUSE	• Customs procedure operation = USUAL_FORMS_OF_HANDLING • Activity type = REBRAND

Technical specifications

Transaction Request

transaction_response_json_schema.md

The request expected by CMS to create a transaction

Schema Version: https://json-schema.org/draft/2020-12/schema

Properties

sourceApplication (required)

Type: string Description: The unique identifier of the source application Allowed values: ATLAS, CTA

terminal (required)

Type: string Description: The unique identifier for a terminal

reference (required)

Type: string Description: The unique local reference for the request to do a declaration for a specific terminal

displayReference

Type: string Description: The display value for the unique local reference for the request to do a declaration for a specific terminal

taxCountry

Type: string Description: The countrycode for the country where we have to pay national tax for in this case. CMS provides the possible values in an LOV API

cmsReference

Type: string Description: The unique cms reference so you can relate to a previous transaction

overrideCheckAlert

Type: string Description: Ability to override (ignore) the check alert warning when applicable, so declarations are created. Allowed values: Y, N

userId

Type: string Description: User that called the transaction rest service.

presentationDateTime

Type: string Description: Timestamp transaction CMS. Standardized to UTC time format Format: date-time Pattern: ^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$

normalProcedure

Type: string Description: Indicates if the (Customs) Normal Procedure must be applied for declarations derived from this transaction. Default N. Allowed values: Y, N

customsProduct

Type: object Description: Combines information about the parcels

customsValue

Type: object Description: The customs value of the combined parcels

invoice

**Type:** `object`
**Description:** Filled if the customs value is based on an invoice

reference

  **Type:** `string`
  **Description:** the number / name of the invoice

amount

  **Type:** `number`
  **Description:** the amount of money invoiced

currency

  **Type:** `string`
  **Description:** the currency in which the amount is expressed, for now always use USD
  **Allowed values:** `USD`, `EUR`, Null

incotermCode

  **Type:** `string`
  **Description:** Applicable Incoterm, such as CIF or FOB. Default CIF
  **Allowed values:** `CIF`, `FOB`

elementsToInclude

  **Type:** `object`
  **Description:** Parts of the invoice which are important to determine customs value

####### freightCostsAmount Type: number Description: In case seperately indicated, the cost of freight

####### insuranceCostsAmount Type: number Description: In case seperately indicated, the cost of insurance

marketValue

**Type:** `object`
**Description:** Filled if the customs value is not based on an invoice

amount

  **Type:** `number`
  **Description:** Value of the goods according to current market situation

currency

  **Type:** `string`
  **Description:** the currency in which the amount is expressed, for now always use USD
  **Allowed values:** `USD`, `EUR`, Null

commodity

Type: object Description: Information about the (end)product used for rebrand

code

**Type:** `string`
**Description:** The 10-digit taric code of the product

description

**Type:** `string`
**Description:** Commercial name of the product coming from the Source system

reference

**Type:** `string`
**Description:** Unique external reference of the product

activities

Type: array of object Description: An array with the activity for which the transaction is sent and any activities which might run in parallel

Array Items

reference

Type: string Description: The unique local reference to the activity

displayReference

Type: string Description: The display value for the unique local reference to the activity

activityType

Type: string Description: The type of the activity Allowed values: MOVEMENT, SERVICE

serviceType

Type: string Description: The type of service. Filled when the activityType is SERVICE Allowed values: IMPORT, REBRAND, RENAME, DEPARTURE, ADMINISTRATIVE_STOCK_TRANSFER, TAKE_IN, SHIFTING, COMMODITY_CODE_CORRECTION

relatedReference

Type: string Description: Filled if it concerns a parallel activity. It holds the unique reference of the activity for which the transaction is sent

executedByExternalCustomsBroker

Type: string Description: Shows if customs import is done by External broker. By default N.

medium

Type: array of object Description: An array of parcels for the activities

Array Items

type

**Type:** `string`
**Description:** Holds information about the side of the activity. If it concerns a service it will be inStorageUnit
**Allowed values:** `FROM_STORAGE_UNIT`, `TO_STORAGE_UNIT`, `IN_STORAGE_UNIT`

storageUnit

**Type:** `object`
**Description:** Information about the storage unit

storageUnitReference

  **Type:** `string`
  **Description:** the reference of the storage unit

visit

  **Type:** `object`
  **Description:** used if the storage unit is for a visit

####### visitReference Type: string Description: the local reference of the visit

####### transportMeansReference Type: string Description: How the visit is identified. In case of vessel/barge is the name, in case of truck its the license plate number

####### transportMeansTypeCode Type: string Description: The manner in which the transport means is identified, for example via license plate or via barge name. Allowed values: RA, RO, VES, BAR, PI, TANK, Null

####### transportMeansNationalityCode Type: string Description: The nationality of the means of transport

####### changedTransportArrangement Type: string Description: ?

tank

  **Type:** `object`
  **Description:** used if the storage unit is for a tank

####### tankName Type: string Description: the name of the tank

parcels

  **Type:** `array of object`
  **Description:** An array of parcels and their properties

####### Array Items ####### reference Type: string Description: The unique reference of the parcel

####### parentReference Type: string Description: The unique reference of the parcel from which the current parcel has been made

####### firstTimeArrival Type: string Description: Did this parcel arrive for the first time, or was it already under our license Allowed values: Y, N

####### inwardProcessingFlag Type: string Description: Has this parcel ever been subject to Inward Processing Allowed values: Y, N

####### commercialPolicyMeasureFlag Type: string Description: Is this parcel subjected to Commercial Policy Measures (CPM) Allowed values: Y, N

####### exceptionDocument Type: string Description: Are there any exception document to take into account Allowed values: VAG

####### parties Type: object

######## customer Type: object Description: Information about the Customer

######### reference Type: string Description: Unique identifier for CMS

######### name Type: string Description: The name/description

######### language Type: string Description: The language

######### eori Type: string Description: The unique registration number with EU customs

######### vatNumber Type: string Description: The identifier used for tax purposes

######### cbsCode Type: string Description: The code for this party for CBS (Centraal Bureau voor de Statistiek)

######### address Type: object Description: Address information

########## cityName Type: string Description: City name

########## countryCode Type: string Description: Country code in CMS

########## streetName Type: string Description: Street name

########## postalCode Type: string Description: Postal code

########## houseNumber Type: string Description: House number

######## consignee Type: object Description: Information about the Consignee, the receiver of a shipment

######### reference Type: string Description: Unique identifier for CMS

######### name Type: string Description: The name/description

######### eori Type: string Description: The unique registration number with EU customs

######### language Type: string Description: The language

######### exciseNumber Type: string Description: Valid SEED registration number of the authorised warehousekeeper or registered consignee

######### registeredConsigneeFlag Type: string Description: This indicates if the consignee is a registered consignee or not Allowed values: Y, N

######### cbsCode Type: string Description: The code for this party for CBS (Centraal Bureau voor de Statistiek)

######### monthlyStatementApproval Type: string Description: Indicates if the consignee makes use of monthly statement approval Allowed values: Y, N

######### address Type: object Description: Address information

########## cityName Type: string Description: City name

########## countryCode Type: string Description: Country code in CMS

########## streetName Type: string Description: Street name

########## postalCode Type: string Description: Postal code

########## houseNumber Type: string Description: House number

######## consignor Type: object Description: Information about the Consignor, the sender of a shipment. Not required. If empty, it will be derived from terminal address data

######### reference Type: string Description: Unique identifier for CMS

######### name Type: string Description: The name/description

######### eori Type: string Description: The unique registration number with EU customs

######### language Type: string Description: The language

######### exciseNumber Type: string Description: Valid SEED registration number of the authorised warehousekeeper or registered consignor

######### cbsCode Type: string Description: The code for this party for CBS (Centraal Bureau voor de Statistiek)

######### address Type: object Description: Address information

########## cityName Type: string Description: City name

########## countryCode Type: string Description: Country code in CMS

########## streetName Type: string Description: Street name

########## postalCode Type: string Description: Postal code

########## houseNumber Type: string Description: House number

######## placeOfDispatchTrader Type: object Description: Information about the party dispatching goods. Not required. If empty, it will be derived from terminal address data.

######### reference Type: string Description: Unique identifier for CMS

######### name Type: string Description: The name/description

######### eori Type: string Description: The unique registration number with EU customs

######### language Type: string Description: The language

######### referenceOfTaxWarehouse Type: string Description: Valid SEED registration number of the tax warehouse.

######### locationName Type: string Description: Name of the physical location at the terminal. Used for SHIFTING service.

######### cbsCode Type: string Description: The code for this party for CBS (Centraal Bureau voor de Statistiek)

######### address Type: object Description: Address information

########## cityName Type: string Description: City name

########## countryCode Type: string Description: Country code in CMS

########## streetName Type: string Description: Street name

########## postalCode Type: string Description: Postal code

########## houseNumber Type: string Description: House number

######## deliveryPlaceTrader Type: object Description: Information about the delivery place trader