# Reporting
This Chapter provides an overview of the primary reporting in CMS.
# 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**
**Inward Processing monitoring**
# 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.
# 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.
**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.
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 (+).
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.
# 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.
Once created, the report becomes available in draft.
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.
##
## 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), t
he 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.