·10 min read
Why declarations stall
A declaration that stalls does not cost minutes, it costs days, and the bill rarely lands with the party that made the mistake. This piece is about where files actually get stuck, why the quietest kind of stall is the most expensive one, and what changes when you validate before filing instead of after a rejection.
What categories does a stalled declaration fall into?
Ask ten declarants where their files get stuck and you get ten stories, but the causes come down to six categories. A document that is missing or wrong: no EUR.1 while the preference has been claimed, a health certificate that belongs to a different consignment, an invoice without an incoterm. Master data that does not hold up: an EORI number that is no longer active, a commodity code that lapsed at the January change, an address behind a VAT number that differs from the one on the invoice. A licence that does not line up with the declaration. A customs system that is unavailable for a while. A control that was assigned. And sixth: a notification that was simply never made. Those six do not behave the same way, so they do not deserve the same attention either. The first three produce a rejection with a code under it, and a rejection is annoying but visible. Someone sees it sitting there, someone picks it up, and the file moves again. The fourth and the fifth are waiting on something outside your reach, with a status that is at least on screen. The sixth is the only one where nobody notices anything, and that is exactly why it costs the most.
Which master data stops holding up?
Master data does not fail at the moment you need it. It expires somewhere in between, on a day when nobody was looking at it. The EORI number of a client that changed its legal form still sits in your system the way it was set up last year. The EU register says something else, and DMS goes by the register, not by your entry. The commodity code is the same story with a fixed date attached. On 1 January the combined nomenclature shifts: codes lapse, get split, or pick up a different measure underneath them. A code that ran through the declaration every week in December no longer exists in January. The article has not changed, the client has done nothing, and the declaration still comes back. Licences are the third group. An article 23 licence, a warehouse authorisation or an authorisation for entry in the declarant's records sits on one EORI number, has a validity period and a description of what falls under it. If the declaration does not line up with that, the DMS message is technically correct and tells you nothing: it says the licence does not match, not what it fails to match on.
Why is the notification that was never made the most expensive?
In the first five categories something is visibly wrong. There is a rejection, an outage message or a control instruction, and as long as something is on screen, somebody is looking at it. In the sixth there is nothing. The file is complete, the declaration is accepted, the MRN is in it, and in the system everything looks finished. Except the notification to the terminal was never made, or the MRN was never linked to the container number, or the release was never passed on to the party that needed it. The container then sits there as though a declaration is still to come. Nobody gets an error, because there is no error. There is an action that was not carried out, and an action that was not carried out has no response message. So this category is almost always discovered by somebody else. By the driver standing at a closed gate, by the client calling because their customer is calling, or by a carrier invoice that comes in higher than anyone expected. By then the time has already passed, and time is exactly what you cannot buy back afterwards.
What does a day of standing still cost on a container?
The clock runs in several places at once, and it pauses in none of them because you are searching through a portal. Demurrage starts running as soon as the free days at the terminal are used up. Detention keeps running for as long as the container is not back empty with the carrier. Both are charged per container per day and both are tiered, so the second day rarely costs the same as the first. On a reefer, power is added to that. As long as the container is on the plug it is charged per day, and that plug does not come out because the declaration is not finished. On fresh produce, shelf life keeps running as well. A pallet that stands two days longer at the terminal reaches the receiver with two days less shelf life, and that loss appears on no customs invoice at all. And then there is other people's diary. An inspection slot at the inspection body or a place at the scan is not always available again the same day. Miss it and you do not move an hour, you move to the next day with room, and the transport planned behind it moves with you.
Why do rejections come in waves, around January and around releases?
Rejections are not spread evenly across the year. The first working week of January is the busiest one every year, and the reason is administrative rather than operational. The combined nomenclature changes on 1 January, measures in TARIC expire or start, and tariff quotas open again. Everything that piled up over the Christmas weeks is filed in that same week, with codes that come from the old year. The second wave hangs off the systems themselves. Around a DMS or NCTS release something changes in the validations, in the code lists, or in the way a message is interpreted. Declarations that went through without comment the week before come back with a message nobody has seen before. In the first days after a release it is not immediately clear whether the problem is in your file or on the customs side. Both waves can be seen coming. The January change is fixed well in advance and releases are announced. The difference is what you do with that: run through your master data before the turn of the year, or find out file by file in the first week of January which codes lapsed while the containers are already in.
What changes when you validate before filing instead of after a rejection?
A rejection is an expensive way to discover a mistake. In between sits a filing, a waiting time, a response in a code list that does not name the cause, a correction and a second filing. During all of that the file is already attached to a container and the clock keeps running. Validating before filing pulls most of these categories forward. The commodity code against the national tariff database and EU TARIC, including the measures under it and the document codes those measures make mandatory. The VAT number through VIES and the EORI number against the EU register. The licence against the EORI number it sits on. Invoice, packing list and bill of lading side by side on value, weight and quantities. Certificates on validity, origin and signature. What you gain is not that nothing ever goes wrong again. You cannot validate away a control instruction, and you cannot validate away a customs outage either. What you gain is that the mistakes you can fix yourself become visible while fixing them still costs nothing: before the file leaves, and before there is a container attached to it that costs money per day.
How do you make a stalled file visible without opening three portals?
The problem with the quiet category is not that the information is missing. The customs status is in DMS, the container status is at Portbase, the release is on the terminal portal, and with enough time you can check all three. But nobody checks three portals for a file that looks like nothing is wrong with it, and that is precisely the file that is stuck. What does help is one view per file with the customs status and the terminal status next to each other. On one side: accepted or rejected, MRN assigned, released or under control. On the other side: was the notification made, is the MRN linked to the container number, is the container free at the terminal. Once both sides sit in the same screen, the combination that used to be invisible reads at a glance: declaration fine, container not. SKAI connects to Portbase and to the Rotterdam terminals for that and puts the terminal status next to the customs status in the same file. A file that has been standing still longer than it should then stands out because it is standing still, and not because somebody calls at the end of the week.
