Norway phases in mandatory Digitoll digital customs from 15 September

The Analysis

From 15 September the paper has to arrive before the goods do. That is the whole change, and it is a bigger change than it sounds. Norway starts phasing in Digitoll, its mandatory digital customs system, on 15 September 2026, and the requirement is that customs data is submitted before goods reach the border. Full enforcement across all transport modes is set for 1 March 2027. What has the trade worried in the run-up is not the rule itself. It is the adoption. Uptake among air, sea and rail shipments has been low, and a system that everybody will eventually have to use and few people have actually tested is exactly how clearance delays happen in the first few weeks of a go-live.

I have two weeks. That is not much time to rebuild a document flow, and I am not going to pretend otherwise. What two weeks buys is the parts you control from your own side: the template, the lane list, the instructions to suppliers, and one dry run. What it does not buy is a fix for suppliers who have never been able to return a usable tariff number. Those need an owner, a date, and a weekly review, and they need to be finished well before 1 March 2027, because that is the day enforcement covers every mode and the tolerance for an unprepared file goes to zero.

So what follows is how I would spend the fortnight, written from the document side rather than the policy side. Which categories enter the phase-in first, what the transition actually obliges a party to do, and where the exceptions sit are not things I will characterise from a trade-press summary. Dr. Ingrid Voss works from the instruments themselves. What I can talk about is what has to be in the file on the morning of the fifteenth, and who has to be holding it.

Assume one Norway-bound consignment: twelve pallets, moving by sea into a Norwegian port with a road leg on the end. Under the current flow the data gets assembled after the goods have sailed, often when the forwarder asks for it, and it reaches the customs side somewhere between a day before arrival and a day after. Under Digitoll that sequence is inverted. The data has to be lodged before the goods reach the border. The physical movement is unchanged; the position of the paperwork relative to it is not.

Here is where the pieces sit on a file like this, and why the adoption figures matter. The commercial data, meaning description, quantity, value, origin and tariff number, originates with the seller or the exporter abroad. The transport data, meaning what is carrying it, when, and where it crosses, sits with the carrier or the forwarder. The party who has to lodge the customs data in Norway is on the Norwegian side, and in most operations I look at that is either the importer or a representative acting for the importer. Those are three different organisations on three different clocks, and the new requirement pulls the whole thing earlier than any of them is used to. When uptake is low across air, sea and rail, what that usually means in practice is that the Norwegian side has not yet got a reliable pipe from the other two.

Classification is still where I start. The tariff number decides the duty rate, it decides whether any relief or preference applies to that line, and it decides whether anything beyond customs has an interest in the goods. In a pre-arrival system this matters more rather than less, because a classification that gets questioned after the data is lodged is not a conversation at a desk, it is a hold on goods that are already at the border. Getting the number right before submission is cheaper than getting it right after arrival, and the gap between those two costs is what the next six months will be spent discovering.

Three things break on files like this. The tariff number is either missing or copied from whatever the seller put on the last one. The origin statement does not match where the goods were actually made, which for anything routed through more than one country is a real problem rather than a clerical one. And the timing: the data is complete, but it is complete four hours too late, which under a pre-arrival rule is the same as not being complete at all. As for whether you get an hour or a day to fix it once the goods are at the border without usable data, that depends on the entry point and on what else that office is handling that week, and I am not going to pretend there is one number for it.

The field list is boring and it is where this gets decided. On a Norway-bound file I want the commercial invoice to carry the seller's legal name and address, the buyer's legal name and address, a description a stranger could actually classify, a quantity in the same unit the packing list uses, the currency, the value, the country of origin, the tariff number, and the transport reference that ties the invoice back to the booking. Most mid-size invoices I see carry about half of those. The ones that get held are the ones where the missing half is the tariff number or the origin, because those are the two fields nobody downstream can fill in on your behalf. A carrier can weigh a pallet. Nobody can guess where the goods were made.

The handover is where data dies, and it is worth naming the exact points. Between the seller's order system and the commercial invoice, descriptions get abbreviated. Between the invoice and the forwarder's booking, references get replaced with the forwarder's own numbers. Between the booking and the Norwegian-side lodgement, whatever survived gets retyped by somebody who has never seen the goods. Each of those steps is perfectly reasonable for the party doing it, and each one can quietly remove a field the entry needs. The fix is not a new system. It is one reference number that survives all three steps and one template nobody is allowed to abbreviate.

The clock is what I would plan around. Assume the seller needs a working day to answer a question about classification. Assume the Norwegian-side filer needs half a day to check and lodge once it has everything. Assume the transit is four days. Then the data package has to be complete and correct no later than the day of dispatch, and realistically the day before, because the first version is never the version that gets lodged. Anything that goes wrong after dispatch is being fixed against a border that is already in the way.

There are three windows for changing something and they are not the same size. Before lodgement, a wrong piece of data is a corrected spreadsheet and an email, and that window costs hours. After lodgement but before the goods reach the border, it is an amendment to a submission that has already been made, and whether that amendment is quick depends on the state of the system and the volume going through it; plan in hours to a day. After the goods have reached the border without usable data, you are in a different process altogether, because the shipment is waiting on something that should have happened before it arrived, and the time now belongs to the border rather than to you. That is the window measured in days, and it is the one the low adoption numbers point straight at.

There is also the question of what you do once it has already gone wrong, because some of it will. If a shipment is at the border without usable data, the job is to get one complete and consistent package to the party who can lodge it, and to get it there fast: invoice, packing list, tariff number, origin, transport reference, and the name of the importer, all saying the same thing. Sending it in four emails across two days is how a hold becomes a week. I would also name one person who owns the chase, because when three people each assume somebody else is doing it, nobody is. And I would keep the timestamp on every message in that chase, because the record of when the data actually arrived is the only thing that will settle the argument about who caused the delay.

The dry run is worth describing properly, because most people skip it and then find the gap on the day. Take twenty-five real shipments rather than invented ones. Run them through the template before dispatch, lodge the data the way you would lodge it after go-live, and record two timestamps per shipment: when the data went in and when the goods reached the border. The number you are after is not how many succeeded. It is the spread of the gap between those two timestamps, because that tells you how much buffer you really have and which suppliers consume most of it. If a third of the sample ends up with less than twelve hours of margin, the template is not the problem; the supplier instructions are.

Put one shipment on a line. Assume a day before dispatch to assemble and check the data package, dispatch, four days of transit with the data lodged somewhere in the first of them, then arrival and release, or arrival, a hold of eight hours while the missing data is chased, and then release. On those assumptions the gap between the good case and the bad case on one shipment is under a calendar day. On a weekly programme of twenty-five shipments into Norway, if even a third of them hit the bad case, that is eight shipments a week each losing most of a working day, and the loss does not spread evenly. It lands on the same customers, on the same delivery appointments, and on the same drivers.

Let me price it, with the assumptions written out. Assume twenty-five Norway-bound shipments a week, about a hundred and eight a month. Assume that today thirty per cent of them already travel with a data package that would satisfy a pre-arrival requirement and seventy per cent would not. Assume that at the start of the phase-in a shipment arriving without usable pre-border data loses an average of two and a half hours of clearance time. Assume each hour of that delay costs thirty-eight euros in handling, waiting time and rebooking the delivery slot. Seventeen point five shipments times two and a half hours times thirty-eight euros is about one thousand six hundred and sixty euros a week, or roughly seven thousand two hundred euros a month.

Now the fix. Assume that once a template exists, preparing the pre-arrival data takes twelve minutes a shipment. Twenty-five shipments is five hours a week, and at thirty euros an hour loaded that is a hundred and fifty euros a week, about six hundred and fifty euros a month. On these assumptions the preparation costs under a tenth of the delay it removes. Move any of the numbers, the adoption rate, the hours lost, the hourly cost, and the ratio moves with them, which is why I have put them on the page instead of quoting a clean saving.

There is a second number, and it shows up on the balance sheet rather than in the operations budget. Assume a SKU with weekly consumption of seventy units and a landed cost of twenty-two euros. Assume the phase-in adds two days of variability to the clearance time on that lane. Two days of cover at seventy units a week is twenty units, which is four hundred and forty euros of stock held against that one SKU. Assume forty SKUs on the lane and that is about seventeen thousand six hundred euros of one-time working capital, before any carrying cost. Whether that is worth it depends on the margin on the line and on what a missed delivery appointment actually costs you, and both of those are your numbers rather than mine.

I have fourteen days from this landing to the start of the phase-in. The honest split is that fourteen days is enough to get the document side ready and not enough to repair a relationship with a supplier who has never sent a usable classification. So the fortnight goes to what can be controlled from here: the template, the lane list, the supplier instructions, and a dry run. The part that cannot be finished in fourteen days, getting every overseas seller to populate a classification column, needs a date and an owner and a weekly review, and it needs to be finished well before 1 March 2027, because that is when enforcement covers all modes and the tolerance for a file that is not ready goes to zero.

One more thought on the March date, because it is easy to file it as distant and then arrive at it unprepared. Full enforcement across all transport modes is scheduled for 1 March 2027, roughly six months after the phase-in begins. That sounds like plenty of time and it is not, if what you actually need is a behaviour change at several hundred overseas suppliers. Supplier changes run on their own clock: you send the instruction, a quarter of them answer inside a week, another quarter answer after a reminder, and the rest do not answer until a shipment is being held. If full coverage by March is the goal, the instruction goes out in the first weeks of the phase-in, not in February.

On records, I want three things on every Norway file from now on. The lodgement reference and the timestamp showing the data went in before the goods reached the border. The version of the commercial data that was used, with who supplied it and when. And every amendment, with the reason and the time it was made. The timestamp matters more than people expect, because in a pre-arrival regime being able to show when the data was lodged is the difference between a question you answer with a screenshot and a question that turns into an enquiry. I would also keep a short note on who decided the tariff number, because the person who gets asked about it in eighteen months will not be the person who decided it.

The routes around this are fewer than people hope. Routing into Norway through another country does not remove the requirement, because the goods still have to be declared where they enter, and it adds a leg and a handover, and handovers are where data goes missing. Switching from sea to road, or from air to road, changes the mode and therefore the timing pressure on the data, but it does not remove the pre-arrival obligation, and once 1 March 2027 arrives the obligation applies across all modes anyway. Holding more stock inside Norway converts a clearance-timing problem into an inventory problem, which is a legitimate trade if the margin supports it and a bad one if it does not. Consolidating several small consignments into one declaration reduces the number of lodgements and concentrates the risk, because one wrong line now holds goods belonging to several deliveries at once.

The specific traps. Pre-arrival is not the same as pre-departure: the deadline is tied to the goods reaching the border rather than to the goods leaving the shipper, so a faster transit eats the buffer you thought you had. The data has to be usable, not merely sent, because a submission with a blank tariff number or an origin that contradicts the invoice will not behave like a compliant one, and low adoption means there is less institutional muscle to catch it before it becomes a hold.

Free time at the terminal runs from the terminal's own definition of arrival, not from when the missing data was noticed. Any commitment a carrier makes about transit time is a commitment about moving the goods, not about clearing them. And the one that will catch the most people: assuming the party that books the freight is the party lodging the customs data. On Norwegian entries that assumption has already cost people days, and the fix is one question asked in writing before the goods move.

What I tell people on the phone about this is simple and sounds slightly unfair. The risk is not the system, it is the document. Digitoll goes live on 15 September whether or not anybody's data package is ready, and full enforcement lands on 1 March 2027 with or without a dry run. Two weeks is enough to build a template, walk twenty-five shipments through it, and find out which suppliers cannot answer a question about classification. It is not enough to fix those suppliers. Start the supplier conversations this week anyway, because the ones that cannot answer are the ones that will still be holding shipments in March. This one can still be saved, but not if the conversation waits until after the goods have reached the border.

↑ Back to the key points

— By Derek Xu