Skip to main content

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.

No Comments
Back to top