Portal
Also known as: customs portal, declaration portal
A customs portal is the operational shell in which you collect consignments, complete them and push them into the Dutch declaration systems. It replaces loose spreadsheets and talks to DMS, DVA and CLIENT PD.
What does a customs portal do in the chain?
A portal is the layer between operations and the Dutch authorities. On one side consignments come in from a TMS, a warehouse, a customer API or a mailbox of pdfs. On the other side declarations go out to DMS, DVA and CLIENT PD, and MRNs, inspection codes and rejections come back. Without that layer you key data into a spreadsheet and then again into the declaration system. That double entry is the classic source of errors: a container number that is right in Excel and differs in DMS, a weight that is different on the T1 from the IMA. The portal centralises the file: a header (container, consignee, importer) with item lines beneath. Every next declaration in the chain reads from the same file, instead of from a new sheet. That sounds like administration. It is the only way to keep a T1, an IMA and an inspection declaration on the same figures when three teams work the same consignment, each in their own rhythm.
Where does this come from in Dutch practice?
A portal often arises because two departments, work preparation and transport, each have their own Excel. Those sheets crash, and the same data is then copied by hand into two declaration systems. The portal is in essence an online sheet that takes that double entry out. That history is familiar at many Dutch freight forwarders. Customs asks for DMS and DVA. The terminal asks for Portbase. The inspection asks for CLIENT PD. None of those systems is a working environment for a team that has to complete fifty consignments a day. The portal is that working environment. It is not a replacement for DMS. It is the place where the consignment is declared complete before a message goes to Customs. New requirements belong in that same shell, not in an extra sheet beside it. Every sheet beside it is the old situation, back. The portal earns its place only once it is the only working environment for completing and approving.
Which declarations does a portal push through?
In a Dutch import flow those are typically the inspection declaration via CLIENT PD, DVA departure for the T1, DVA arrival for the unloading permission, DMS storage for the warehouse and DMS import for free circulation. Export and e-Cert for phyto sit in the same shell if the flow asks for it. Not every file has every step. A consignment cleared at the terminal has no T1. A consignment going to the warehouse has no IMA at that moment. The portal chooses the chain on the basis of the order, not the declarant per message. What the portal deliberately does not do is warehouse stock keeping. The placement declaration and the removal go through it. How many pieces lie in between is the responsibility of the authorisation holder, not of the declaration layer. The choice per consignment belongs in the order, not with the declarant at the moment of filing. A portal that asks which declaration every time is a menu. A portal that knows the chain is a chain.
How does the data enter the portal?
Three routes. A customer API supplies the consignment in structured form. A mailbox supplies pdfs, invoices, B/Ls and packing lists, which are read. Manual entry catches the rest. After that the portal enriches with vessel times and terminal status from Portbase and MyTerminal, and checks EORI, VAT number and goods code. Approval is the gate. Nothing goes to DMS or DVA until the consignment stands on complete and approved. A robot or rule check of the documents against the file data catches what a person has left standing. That gate is the difference from filing directly. A message that goes to Customs too early yields a rejection that you have to pull back in DMS. A portal holds the message until the chain is ready for it. OCR on the documents catches what the API does not supply: a VIN on a bill of sale, a weight on a packing list, an MRN on a previous document. Those fields stay source-labelled, so a check can see where the figure came from.
How does the portal relate to SKAI and to DMS?
DMS is the system of Dutch Customs. The portal is the freight forwarder's. SKAI is a declaration platform that puts the messages to DMS, DVA and CLIENT PD itself, so that no separate declaration system needs to sit in between. As long as that intervening system is still there, the portal is the collection layer and the declaration system is the letterbox. Once the connection is direct, collecting, checking and approving stay in the portal, and only the sending changes. For the declarant the Customs side does not change. IMA remains IMA, T1 remains T1. What changes is whether you key the same data twice, or push one file through the chain. For the knowledge base that distinction is enough. The portal is operations. DMS is Customs. Anyone who mixes them up looks for a rejection in the wrong screen and calls the wrong helpdesk.
What goes wrong without a portal?
The T1 goes out with a different value from the IMA, because two people have updated two sheets. The MRN lands in the mailbox and not at the terminal. The inspection code sits in a second inbox. The consignment is in order in customs terms and operationally lost. For vehicles that is visible per VIN. Each chassis number has its own documents: bill of sale, authorisation, identity document. Without a portal the status per car is a tab. With a portal the status per VIN is a line in the same container file. The portal does not solve the customs law. It solves the fact that the law has to land in four systems at once, with the same figures. Anyone who skips that layer pays it in rejections, open T1s and containers that stand still while each loose message is right. Measure the portal on open T1s, rejected IMAs and containers stuck with a valid MRN. If those three fall, the shell is doing its work. If they stay the same, there is still a sheet beside it somewhere.