With a dozen or so products, gaps can still be checked manually. With hundreds of SKUs, the same model leads to duplicates, out-of-date files and decisions that cannot be reproduced. Scaling GPSR documentation is not about creating a bigger spreadsheet. It requires separating shared data, variant data, evidence and tasks.
Start with a reference catalogue
Every product should have a stable internal identifier, name, variant, status and links to the manufacturer, supplier and market. The data should not depend on the listing title, which may change. The SKU is an entry point, but it does not always correspond to one technically distinct product.
Before migration, it is worth detecting duplicates, empty identifiers and records that combine several variants. An import should not automatically treat data as approved. It should create a controlled list of records and flag issues that require a human decision.
Product families without unjustified copying
A family allows genuinely shared data to be reused: the manufacturer, part of the instructions, a report covering a series or a description of the design. At the same time, variant differences must be preserved, such as power, material, dimensions, accessories or user group. The inheritance rule should be visible and justified.
The biggest risk of automation is assigning evidence to a product only because the name looks similar. The system should require the document's scope to be defined and allow a variant to be excluded. Sharing is meant to reduce work, not to hide a missing assessment.
Around 100 SKUs - getting the basics in order
At this level, a company can usually carry out a manual review of each product if it uses a common schema. The priority is completeness of the basic data, separating files from decisions and assigning responsibility. A gap tracker with deadlines and filters by supplier works well.
It is worth starting with actively sold products, higher-risk products and listings that generate the greatest turnover. Archived products should remain available for historical reasons, but they do not have to block work on the current catalogue.
Around 500 SKUs - a process instead of individual messages
At this scale, correspondence with suppliers requires templates, statuses and follow-ups. A request should specify the products and the expected materials. The response must be attached to a specific record, not just to a folder named after the contractor.
User roles and review queues are needed. The person collecting a file does not have to have the authority to approve its significance. Separating receipt, verification and acceptance reduces situations in which an unverified document becomes the basis for publication.
Around 2,000 SKUs - changes and exceptions
With a large catalogue, it is not possible to review all records every day. The system should direct attention to change: a new variant, expiring evidence, a missing language, a change of supplier, an incident or a product without an owner. The completeness report should lead to a specific task.
Bulk versioning and measuring data quality become more important. It is worth knowing how many products have an approved assessment, how many use a document without a defined scope and how many are awaiting a supplier response. However, an indicator cannot automatically declare legal compliance.
A data model that scales better than folders
- product and variant,
- product family,
- entities and their roles,
- market and language,
- instructions and warnings,
- evidence with a defined scope,
- risk assessment and its revision,
- request to the supplier,
- decision with author and date,
- output document preserving the sources.
Separating these elements makes it possible to update shared data without overwriting the product history. It also makes it easier to detect which records actually use a changed source.
Migration in batches
There is no need to migrate the entire catalogue in one day. A pilot on a representative group of products, correction of the model and then import in batches by category or supplier is better. Each batch should have an error report and be repeatable without creating duplicates.
After import, the number of records, relationships, files and statuses must be compared. A template is a starting point, not proof that all data in the source was correct. Therefore, an import should leave a trace and require deliberate approval.
Hard limits and predictable work
If a package specifies a maximum number of active SKUs or users, the limit should be enforced before another record is created. It should not lead to hidden surcharges. The user must be able to see usage and know what can be archived or which package to choose.
GPSR / PPWR supports such a controlled model. The aim is not to issue an automatic verdict, but to organise data, sources and subsequent actions regardless of catalogue size.
The most important thing is to maintain the same logic at every scale: first identification, then sources and assessment, and only at the end an approved document.