A customs code looks like a side issue: eight or ten digits in a field that sales rarely opens. As soon as a consignment crosses a border, that single field decides the rate of duty, licensing requirements, the statistical declaration and whether the customer receives a preference proof. In a B2B shop two more points come with it: the catalogue displays the number, and the order data hand it on to the ERP system. This article describes how commodity code, origin and supplier declaration are set up as maintained product data, which deadlines the Union Customs Code sets, and where the maintenance tends to break down in practice.
Key takeaways
- The commodity code is product data, not shipping data. The first six digits come from the Harmonised System, the seventh and eighth subdivide the Combined Nomenclature, the ninth and tenth come from TARIC (Regulation 2658/87).
- Origin exists twice and means two different things: non-preferential origin follows the last substantial processing (Union Customs Code), preferential origin depends on the individual agreement and lives on a proof.
- A long-term supplier declaration may be valid for up to two years from the date of issue and may be made out up to one year retroactively (Implementing Regulation 2015/2447). Without an expiry date in the master record, the end passes unnoticed.
- The Combined Nomenclature is republished every year, no later than 31 October, and applies from 1 January (Regulation 2658/87). A catalogue without an annual reconciliation carries outdated codes from January onwards.
- The Intrastat reporting thresholds have been 1 million euros for dispatches and 3 million euros for arrivals since the January 2025 reference month (Federal Statistical Office). Around 43,800 companies were subject to reporting.
Why the commodity code is product data
The article master record holds dimensions, weight, material and drawing number. The commodity code belongs in the same row: it describes what the product is, not where it is going. That is precisely why it is often maintained in the wrong place, namely in the shipping department once the consignment is already packed. The number then sits in a forwarding order, but not in the catalogue, not in the quotation and not in the file the buyer imports into their own system. Anyone who has once set up product data and data quality in the B2B shop knows the effect: a field only one department sees goes stale faster than one shown in the catalogue.
The consequences are not theoretical. An incorrect code shifts the rate of duty, can conceal a licensing requirement and produces figures in the statistical declaration that can no longer be explained afterwards. It is also tied to checks that run before dispatch: sanctions screening and export control in the B2B shop draws on the same master data, and a dual-use list number rarely comes into being independently of the commodity code. Where one is missing, experience shows the other is usually unmaintained as well.
Three numbers, one field
How the code number is built
The structure is laid down in the Regulation on the tariff and statistical nomenclature and fits into one sentence: every digit has a sender. The first six digits come from the globally agreed Harmonised System, the seventh and eighth are the European subdivision, the ninth and tenth come from TARIC and carry the trade policy measures (Regulation 2658/87). Knowing that origin also tells you which digits a supplier can realistically deliver at all.
- Digits 1 to 6 - Harmonised System. Globally agreed and therefore the only level a supplier outside the EU can usually provide (Regulation 2658/87).
- Digits 7 and 8 - Combined Nomenclature. The European subdivision; only with it does the six-digit Harmonised System number become the eight-digit Combined Nomenclature code (Regulation 2658/87).
- Digits 9 and 10 - TARIC. Duty rates, quotas, anti-dumping measures and licensing requirements on import (Regulation 2658/87).
- Further digits - national additional codes. Member States may add subheadings or additional codes that meet national requirements (Regulation 2658/87).
For the shop this yields a practical rule: the catalogue keeps the eight-digit Combined Nomenclature code as its basis and derives the ten-digit TARIC view from it where that view is needed. Which level an individual declaration calls for is not set out in the nomenclature regulation but in customs and statistics law; that is settled with the customs service provider, not in the shop. How such country-dependent views can be separated technically is covered in country-specific shops in B2B trade.
Each CN subheading shall have an eight digit code number: (a) the first six digits shall be the code numbers relating to the headings and subheadings of the harmonized system nomenclature; (b) the seventh and eighth digits shall identify the CN subheadings.
The code alone does not determine the amount of duty. The customs value is added to it, and depending on the delivery term that value also absorbs freight and insurance elements. Anyone calculating shipping costs and freight in the B2B shop is therefore working further along the same chain: commodity code, origin, delivery term and freight together produce the charge that falls due at the consignee. A shop that maintains the code cleanly but leaves the delivery term open answers the buyer's question only halfway.
Keep additional codes out of the same field
Two origins, two purposes
In customs law, origin is an umbrella term for two pieces of information that differ in purpose, rulebook and proof. Non-preferential origin answers the question which country a product comes from in trade policy terms; it governs anti-dumping duties, quotas and origin markings. Preferential origin decides whether a free trade agreement applies and the customer receives a reduced rate of duty. In shops both tend to end up in one field - with the same result as with VAT in the B2B shop, where the country of establishment and the country of supply are not the same thing either.
For non-preferential origin a general rule applies: goods whose production involved more than one country originate in the country of the last substantial, economically justified processing or working (Union Customs Code). For a traded article that is assembled and passed on, that is frequently not the country the invoice comes from. A field labelled country of origin is filled in incorrectly for exactly this reason: purchasing enters the country of supply, because that is what appears on the paperwork at hand.
Goods the production of which involves more than one country or territory shall be deemed to originate in the country or territory where they underwent their last, substantial, economically-justified processing or working, in an undertaking equipped for that purpose, resulting in the manufacture of a new product or representing an important stage of manufacture.
The difference in one sentence
The supplier declaration as a data object
Preferential origin does not arise in the shop but at the upstream supplier. Its proof is the supplier declaration: a declaration on the invoice, on a delivery note or on any other commercial document describing the goods in sufficient detail to enable them to be identified (Implementing Regulation 2015/2447). That makes it not a document sitting in a folder but a data record with a subject, a scope and an expiry date - much like the digital instructions under the Machinery Regulation, which also become manageable only as a data object.
Declaration per consignment
The supplier includes it on the invoice, on a delivery note or on another commercial document describing the goods in enough detail to identify them (Implementing Regulation 2015/2447).
Long-term declaration
It may be made out for a validity period of up to two years from the date of issue and up to one year retroactively; in that case the period ends on the date the declaration was made out (Implementing Regulation 2015/2447).
Signature or written undertaking
It is signed by hand; where declaration and invoice are produced electronically, electronic authentication or a written undertaking by the supplier accepting full responsibility is provided for (Implementing Regulation 2015/2447).
Proof via INF 4
The customs authorities may request the exporter to obtain an Information Certificate INF 4 from the supplier certifying the accuracy and authenticity of the declaration (Implementing Regulation 2015/2447).
These four points imply a data model, not a filing system. Every declaration belongs to a supplier, covers a set of articles, applies to one agreement or a group of agreements and has a date on which it ends. A product information system maps exactly this structure; where one exists, the preference view belongs there and is mirrored into the shop through the PIM integration. Where none exists, the ERP system takes the role - the error only starts where both systems maintain the same statement independently of each other.
| Feature | Declaration per consignment | Long-term supplier declaration |
|---|---|---|
| Scope | A single consignment | All consignments in the validity period |
| Carrier | Invoice, delivery note or other commercial document | Separate letter to the customer |
| Validity | The consignment concerned | Up to two years from the date of issue |
| Retroactivity | Not provided for | Up to one year before the date of issue |
| Master record handling | Document per order | Expiry date per supplier and article group |
| Typical failure | Declaration missing from the document archive | Expiry passes unnoticed, the status still looks valid |
Which fields the article master record should carry
The field list can stay short as long as every entry has a clear sender. What matters is which system takes the lead: as a rule the ERP system is where the commodity code originates, because purchasing, production and shipping meet there. The shop takes it over and does not write it back. How to fix and monitor that direction technically is described in the article on ERP integration in B2B e-commerce.
- Commodity code, eight digits - without spaces or dots, kept as a string so that leading zeros survive.
- TARIC code, ten digits - only where an import view is needed, derived from the eight-digit code.
- Nomenclature version - the year the code comes from. Without it, you cannot later tell whether a code is old or simply wrong.
- Non-preferential origin - the country of the last substantial processing, explicitly not the country of supply.
- Preference status per agreement - originating status, the corresponding declaration, valid-until date.
- Source and status date - who supplied the information and when it was last confirmed.
A tick box is not enough
Between ERP, product information system and shop sits a handover, and it decides whether the customs data arrive at all. Two points come up regularly: leading zeros are lost as soon as the commodity code is treated as a number on the way, and an expiry date loses its purpose when only the derived state is transferred. Both are a question of field types in the integration, not of data maintenance - and both only surface when an article with the code 03089000 suddenly appears as 3089000 in the catalogue.
{
"artikelnummer": "PN-4711",
"warennummer_kn8": "84818079",
"codenummer_taric10": "8481807910",
"nomenklaturfassung": "2026",
"ursprung_nichtpraeferenziell": "DE",
"praeferenzursprung": [
{
"abkommen": "CH",
"status": "nachgewiesen",
"erklaerung": "langzeit",
"gueltig_bis": "2027-03-31"
},
{
"abkommen": "UK",
"status": "nachweis_abgelaufen",
"erklaerung": "langzeit",
"gueltig_bis": "2026-06-30"
},
{
"abkommen": "KR",
"status": "nicht_geprueft",
"erklaerung": null,
"gueltig_bis": null
}
],
"quelle": "ERP",
"stand": "2026-09-01"
}The excerpt shows three states side by side, and that is the point: an article can be proven for one agreement, expired for the next and unchecked for a third. A single flag does not capture that. The same structure of feature, proof and validity turns up elsewhere as well, for instance in the digital product passport under the Ecodesign Regulation. Once it exists, it can be reused for further proof obligations instead of inventing a new field for each one.
Intrastat: who reports and from when
The commodity code leaves the company not only with the goods but also with the statistics. Within the EU that means the intra-EU trade statistics. Higher reporting thresholds have applied since the January 2025 reference month: 1 million euros for dispatches to other Member States and 3 million euros for arrivals, previously 500,000 euros and 800,000 euros (Federal Statistical Office). For smaller suppliers the declaration falls away; those above the threshold report monthly. Anyone who also supplies public sector buyers through the B2B shop knows the effort such recurring obligations create, and their tendency to snag on poorly maintained master data.
- 40 per cent fewer reporting companies. In 2025, 29,400 fewer companies in Germany were subject to intra-EU trade statistics reporting than in 2021 (Federal Statistical Office).
- One company in twenty. Of 803,900 companies active in foreign trade, around 43,800 were subject to reporting, that is 5.4 per cent after 8.3 per cent in 2021 (Federal Statistical Office).
- Coverage stays high. More than 90 per cent of the value of goods imported into Germany from the EU is still recorded through primary statistics (Federal Statistical Office).
- The master record stays the same. Statistical declaration and export declaration draw on the same commodity code; maintaining it separately in two systems produces discrepancies that only surface during an audit.
For a shop operator these figures say one thing above all: the reporting obligation is not a constant. It can arise with growth and fall away again with a changed threshold. Anyone who starts maintaining the commodity code when the declaration is already due begins the work under time pressure and retroactively for a longer period. Conversely, a maintained field in the master record costs little while it is not needed - and it is there at the moment the threshold is crossed.
The annual change of the nomenclature
The Combined Nomenclature is not a fixed list. The Commission publishes a complete version every year, no later than 31 October, and that version applies from 1 January of the following year (Regulation 2658/87). Headings are merged, split or recut. For the catalogue this means there is a window of roughly two months between the autumn publication and the turn of the year in which the reconciliation can take place without anyone working against a deadline.
The Commission shall adopt each year, a regulation reproducing the complete version of the Combined Nomenclature, together with the rates of duty in accordance with Article 1, as resulting from measures adopted by the Council or the Commission. The said Regulation shall be published not later than 31 October in the Official Journal of the European Communities and it shall apply from 1 January of the following year.
The reconciliation itself is routine work and can be wired into the shop system: read in the version, check the catalogue codes against it, output the articles without a counterpart. In Shopware development we set up a dedicated console command for this that runs without a user interface and writes its output to a log file - a run without output would have no signal by which a silent failure could be noticed.
Display, documents and catalogue output
Once maintenance is settled, the question of output arises. The commodity code belongs on the article page, in the data sheets, in the order documents and in every export file a buyer downloads. The print catalogue and price list from shop data run off the same source; separate lists for print and shop are the shortest route to two different codes for the same article.
- Article page - commodity code and non-preferential origin visible, together with the nomenclature version.
- Data sheet and quotation - the same values produced from the same source, each with the status date.
- Export files - output the commodity code as text, not as a number, so that leading zeros survive.
- Preference statement - show it only where a valid declaration exists, and name the agreement it refers to.
- Expired proofs - do not present them as preferential goods in the catalogue; report them internally for follow-up.
How we set this up
The build usually follows the same order. First it is settled which system leads the customs data and which merely displays them. Then the fields are created: commodity code, version, origin, preference state per agreement, source, status date. Next comes the reconciliation with the annual version, and finally the output in the catalogue and in the documents. In a B2B portal a customer view is usually attached to it: anyone shipping regularly into an agreement country wants to see the preference status in the basket rather than first on the invoice.
The effort rarely lies in the technology but in the question of who owns the information. That is why an e-commerce consulting engagement starts at this point with an inventory: how many articles carry a commodity code, how many of those come from the current version, how many supplier declarations are older than two years. Experience shows the gap is not with the main articles but with accessories, spare parts and merchandise that moves rarely - precisely where a single consignment puts the whole chain to the test.
Sources for this article
Related Articles
Where Order Documents Live and How Long They Stay
Order confirmation, delivery note, invoice and price list in the customer account: which retention period applies, when it starts and where the files may sit.
Showing Declarations of Performance Before Checkout
Regulation (EU) 2024/3110: how the declaration of performance and conformity, CE details and safety information become visible in the shop before the contract binds.
WEEE Duties When You List Electricals in a B2B Shop
The registration number as an item field, a block for unregistered manufacturers, output on quote and invoice, and a take-back duty measured by storage and dispatch space.