What happens if you do not have this conversation with your software supplier?
If you do not have the conversation with your software supplier about the digital tyre passport in time, you risk that your systems are not ready when the obligation takes effect. This does not automatically mean a fine or a problem with a supervisory authority, but it does mean that you will have to collect, link and publish data under time pressure that should have been properly structured long ago.
The core of the problem is simple: the tyre passport requests data from different systems simultaneously, such as your inventory management, your purchasing administration and possibly a separate platform for product information. Software suppliers do not adapt their systems overnight. Those who postpone this conversation until the obligation is imminent often end up in a queue of companies facing the same problem at the same time.
Why this conversation does not happen automatically
Many entrepreneurs assume that their software supplier will simply take this on, because it is part of the system after all. In practice, it works the other way around: suppliers build functionality for customers who ask for it. If that request does not come, the tyre passport simply does not rank high on your supplier's development agenda, even as the obligation draws nearer.
Added to this is the fact that the exact date on which the obligation takes effect has not yet been determined. The European Commission's work plan mentions a delegated act expected to be published in 2027, followed by a transition period. This makes it tempting to wait until everything is certain. The disadvantage is that the technology, the data structure and the links often take more time than the text of the regulation itself.
The risks in the short term
In the short term, it is mainly about practical delays. A link between your current system and a passport platform must be built, tested and populated with correct data per tyre model. Those who start this process only when the obligation takes effect often discover that the lead time at the software supplier is longer than expected, especially if multiple customers contact them at the same time.
Data management itself also becomes rushed. Data that would normally be built up gradually must then be collected in a short time from invoices, technical specifications and manufacturer documentation. This increases the risk of errors, and errors in a product passport are more difficult to correct than errors in internal administration, because the passport is visible to third parties.
The risks in the longer term
In the longer term, another point comes into play: contracts. Those who do not involve their software supplier in time risk that the current agreement does not contain provisions about who is responsible for keeping passport data up to date, who is liable for incorrect data, and what happens if you switch suppliers. These are not questions you can easily resolve afterwards, especially if the relationship with the supplier has been running for years on the basis of an older contract.
There is also the question of supervision. In the case of product regulations, supervisory authorities generally look at whether the correct information is available and up to date at the time of inspection, not at the intention to arrange it at some point. An incomplete or non-functioning passport at the time of an inspection is a different situation from a passport that has been built up in a timely and careful manner.
How this relates to your role in the supply chain
Whether and how heavily these consequences weigh on your business depends largely on your role in the tire supply chain. An importer who first places the tire on the European market has different obligations than a wholesaler who only resells tires. This distinction also determines which data you must supply yourself to your software supplier, and which data have already been recorded by an earlier party in the chain. Without a clear understanding of this distinction, conversations with your software supplier often proceed based on an incomplete picture of what is actually needed.
The overlap with existing legislation also plays a role here. Data you already collect for product safety or for your current tire label can be partially reused for the product passport. This is something to discuss early in the conversation with your software supplier, not only after the system has already been set up.
What you can do with this information now
Postponing this conversation is not a violation in itself, but it is a choice that increases the turnaround time and error risk once the obligation becomes concrete. A good time to start is not the moment the delegated act is published, but the moment you have clarity on which data you already have and which are still missing.
On looked into what is relevant for your situation per subject there is an overview of the individual building blocks of the product passport, so you do not have to understand the entire process at once. Those who prefer to get a general picture first can get an initial indication in a few questions from where your business currently stands. And before you start the conversation with your software supplier, it is often useful to first know where the data for the product passport come from exactly, so you can ask your supplier specifically what they already support.
For your specific situation, with all the details of your contract and your role in the chain, it remains advisable to consult a legal expert or the competent supervisory authority alongside this general information. If you would first like to get an overview without taking immediate steps, you will find on answers to questions that other entrepreneurs are also asking and you can review the free quick-scan without obligation.