Where Intrastat comes from
When customs borders disappeared inside the European Union, customs declarations went with them, and so did the source of data on how much merchandise moves between member states. Trade statistics needed a new source, so the reporting duty was shifted onto companies themselves. That is exactly what Intrastat is: a monthly statistical report on the physical movement of goods between EU countries, filed by the party that causes the movement.
One distinction is worth remembering straight away, because most misunderstandings grow out of it. Intrastat is not a tax return and has nothing to do with how much tax you pay. It is a statistical report describing the movement of goods, not the settlement of a transaction. That is why it captures entries you would never look for in a VAT return, such as moving your own stock into your own warehouse in another country, where there is no sale, no invoice and no counterparty, and yet the goods crossed a border.
When an online store falls under the duty
As long as you ship parcels from a single warehouse in your home country, the topic usually does not touch you directly, at least not in the countries you ship to. Things change the moment stock starts sitting abroad. A warehouse in Germany to serve German-speaking customers, a fulfilment centre in France, or using an operator who shifts inventory between countries on your behalf: each of these makes you a party dispatching goods from that country, not merely a seller shipping into it.
The duty is tied to your VAT registration in a given country and to the threshold that country announces. Thresholds are national, set separately for arrivals and dispatches, and they change from year to year, so the only sensible advice is to check the current value with the administration of the state where you are registered, rather than relying on a figure you heard two years ago. How a threshold works is stable, though. Crossing it during the year triggers the duty from the month in which it happened, and normally keeps it in force for the following year as well. It is therefore not a one-off filing but a status you enter, and one you leave formally, after turnover falls back below the threshold.
There is a psychological trap on top of that. The threshold counts the value of goods moved, not your margin or your order count. A store with heavy, low-margin products crosses it far sooner than its financial results would suggest, and usually learns about it from a letter rather than from its own calculations.
In which country you file
This is the question we stumble over most often in client conversations. The declaration is filed in the country the goods leave, as a dispatch report, and in the country they arrive in, as an arrival report, with each side handled by the party registered there. A Polish store shipping parcels from Poland to customers in Germany therefore reports the dispatch in Poland. The same store, if it keeps a warehouse near Berlin and ships from it to Austria or the Netherlands, is a dispatching party on the German side and files a German dispatch declaration there.
The practical consequence is that one company may carry several parallel duties in several countries, each with its own deadline, its own file format and its own administration on the other end. The German Versendung, the French EMEBI, known until recently as DEB, and the Spanish exportación are three different procedures, not three names for the same thing. They differ not only in how you file, but in how mass and value are rounded and which fields are mandatory.
What the declaration demands from your catalogue
The declaration itself is a list of lines, and each line describes goods in a way online stores usually do not describe them. You need an eight-digit CN commodity code from the combined nomenclature, the country of origin understood as where the goods were made rather than where you ship them from, net mass in kilograms, a statistical value, and codes for the nature of the transaction and the country of destination.
This is where the real cost of Intrastat sits. The CN code and the country of origin are not sales data, so a typical catalogue does not hold them, or holds them in a free-text field filled in differently by different people over the last four years. Weight tends to be filled in selectively, because it only ever served to calculate shipping costs and nobody minded when a click-and-collect product had none. Collecting all of this for a few hundred items is a finite, one-off job, but it has to be done properly once, because every later declaration depends on the quality of those fields.
The second part of the puzzle is separating transactions. Intrastat captures the movement of goods, so sales to consumers count too, not only sales to businesses, yet the nature of the transaction may be reported differently, and the counterparty VAT number is the only signal a system can tell them apart by automatically. Returns need separate handling as well, since they reduce the reported value in the month they come back, and so do samples and goods sent free of charge, which remain a movement despite the absence of an invoice.
Where the process usually breaks
The monthly routine looks harmless: gather last period’s orders, attach a classification to them, sum up values and mass, build the file and file it before a deadline that in most countries falls in the first half of the following month. In practice it breaks in three places.
The first is catalogue drift. A report built at the end of the month reaches into product data, but the product may since have changed its CN code, changed its weight, or been deleted along with a whole end-of-season collection. The declaration for a past period then shows figures that cannot be reconciled with anything, and when a correction is needed months later there is nothing left to go back to. The fix is to store the classification at the moment of the order, so the document describes the state on the transaction date rather than the state of the catalogue on the day the file was generated.
The second is the format. Every administration expects a different file and reacts differently to small deviations. Germany and France accept XML in the INSTAT model, but the French DEBWEB2 service has its own variant and its own rounding rules, mass in whole kilograms and amounts in whole euros among them. The Spanish AEAT takes a flat CSV file and publishes no schema you could validate against beforehand, so a wrong column count surfaces only on import, typically on the day of the deadline.
The third is the deadline itself. The declaration is monthly and it does not go away during peak season, holidays or a store migration. If preparing the file means assembling a spreadsheet by hand every time, sooner or later one month gets filed late, or filed with data nobody had time to review.
How to get it off your desk
The order that works in practice is the reverse of the intuitive one. Start with the data, not the file. Establish which countries you genuinely have a duty in, and confirm it with your accountant or adviser, because everything downstream depends on that answer. Then fill in the catalogue: CN code, country of origin and mass for everything that actually sells. Only with that in place should you look at automating the report, because a generator fed incomplete data will merely produce an incorrect declaration faster.
The generating mechanism itself belongs inside the store rather than in a spreadsheet next to it. Our Intrastat module for PrestaShop does exactly that: it reads the CN8 code, country of origin and mass from product features, stores the classification at the moment of the order, builds the file in the format required by Germany, France or Spain, and validates it against the official schema wherever the administration publishes one. A scheduled task prepares the declaration for the previous month and sends it by e-mail, so the deadline stops depending on whether somebody remembered it.
If you run your store on another platform, or your case is more involved than one warehouse and one country, get in touch. We usually start by establishing where the duty lies and what condition your product data is in, because that part decides how much work is actually left.
This article describes how the duty works and how to prepare your data. It is not tax or legal advice, and since every state sets its own thresholds and detailed requirements and revises them from year to year, confirm the scope of your own obligations with your adviser or with the administration of the country where you are registered.