The wrong technical data sheet doesn't stop at the data sheet. It stops on the production line — when the seamstress has already cut the wrong fabric, when the dyeing batch comes out off-specification, when the German customer returns the order. The problem isn't the data sheet itself: it's that most factories treat the technical data sheet as a filing document rather than a living operational contract. This guide takes a simple position — the technical data sheet only has value when it is linked to the production order, versioned in the system and audited with real non-conformity data. Everything else is managing appearances.
With around two thirds of national textile and clothing production destined for export (source: ATP), and with Germany and France among the four largest markets for the Portuguese textile and clothing industry (INE/ATP, 2025), international buyers do not accept weak documentary traceability. They used to. Not any more.
What you need before you start
Before reviewing any data sheet, confirm that you have these minimum conditions in place. Without them, the following process won't work — and you'll find out the hard way, halfway through the audit.
You need a complete and up-to-date list of all references active in production. You need the non-conformity history for the last 12 months — returns, rework, complaints — because that is where data sheet errors appear disguised as a "sewing problem" or "colour variation". You need to know who approves changes to data sheets: name, not generic role. And you need to confirm how many active SKUs exist in the system and how many have an associated technical data sheet. The difference between those two numbers is your real risk — and in factories with collections of 400 to 800 references, that difference is rarely zero.
One detail the manuals don't mention: ask the production manager and the quality manager to be in the same room for at least two hours. Not in separate meetings. In the same room. The disagreements between what each of them considers "the correct version" of the data sheet are the source of half the errors you're going to find.
Step 1 — Map where the technical data sheets actually live
Most textile factories in the Vale do Ave have data sheets in three places at once: a network folder with Excel files from 2019, an email sent by the customer with the latest version, and the line supervisor's head. None of these three agree with the others. This is not a technology problem — it's a governance problem that technology solves, but only once they acknowledge it.
Carry out this inventory without filters: list all the repositories where technical data sheets exist — ERP, network folder, email, paper, WhatsApp. For each repository, identify who has write access, not just read access. Flag the repositories without version control: those are the active error hotspots. And confirm whether the production system consumes the data sheet directly or whether someone transcribes it manually onto the order.
The manual transcription of technical data sheets onto production orders is the biggest generator of errors in the Portuguese textile industry — and it is also the most avoidable. Every human copying step is an opportunity for divergence.
The standard error we find repeatedly: the factory has the ERP with the correct data sheet, but the line supervisor works from a printout that's three months old because "it's faster". The system is right. Production is wrong. And nobody knows until the return.
Step 2 — Define the mandatory minimum structure of a technical data sheet
An incomplete technical data sheet is worse than a missing one. The missing one stops production. The incomplete one lets it proceed with wrong data.
In INFOS projects with factories in the textile and clothing sectors, we systematically see the same fields missing. The most critical ones aren't the obvious ones — everyone fills in composition and measurements. What's missing is the reference to the approved raw material batch (without it, batch-by-batch traceability is impossible), the explicit sewing tolerances per size (not a generic tolerance for the whole garment), and the exact form of customer approval — date, channel, and who approved on the customer's side. When the German buyer asks for the compliance dossier six months later, "the customer approved by email" isn't enough.
| Field | Mandatory detail | Common error |
|---|---|---|
| Unique reference | Internal code + customer code | Only one of the two present |
| Version and approval date | Digital validation or signature of the responsible person | "v_final" with no date |
| Raw material composition | Exact percentages | "approx. 60% cotton" |
| Dyeing and finishing specifications | Temperature, time, pH, tolerances | Temperature only, no tolerance |
| Measurement table per size | Explicit sewing tolerances per size | Single tolerance for the whole garment |
| Washing and care instructions | Compliant with Regulation (EU) No 1007/2011 | Copied from the previous collection without review |
| Approved raw material batch | Reference to the specific batch | Empty field or "see supplier" |
| Customer approval | Date, channel and name of the approver on the customer's side | "Customer approved" with no record |
Create a template with these fields as mandatory in the system. If the system doesn't prevent saving an incomplete data sheet, the "mandatory" field is just a suggestion — and everyone in the factory knows it.
Step 3 — Implement version control with change traceability
The customer sends a revision of the data sheet. Production has already started. Who knows? Usually, nobody — until the non-conformity appears. This scenario repeats in almost every factory we've audited, regardless of size.
Version control isn't bureaucracy. It's the mechanism that stops a 2mm change to the side seam from reaching cutting three weeks after it was approved by the customer. The rule is simple: each change generates a new numbered version — v1, v2, v3, never "final", "final2", "final_approved". Record who changed it, what, when, and why. Lock the previous version as soon as the new one is approved — don't delete, lock, because historical traceability has legal and commercial value. And automatically notify the production manager when a data sheet for a reference in active production is changed.
The detail that projects teach: define a minimum lead time between approval of the new version and entry into production. Never zero days. In factories with weekly planning, three working days is the reasonable minimum — time for the warehouse to check whether the raw material in stock meets the new specification before cutting begins.
This flow only works consistently when the technical data sheet lives inside the ERP and not outside it. A network folder notifies no one. An email doesn't lock old versions. And the line supervisor's WhatsApp has no audit trail.
- ☐ Numbered version system implemented and in use
- ☐ Automatic notifications configured for changes to active references
- ☐ Old versions locked (not deleted)
- ☐ Minimum lead time defined between approval and production
Step 4 — Link the technical data sheet to the production order
This is the step most factories don't take — and it's the most critical. Having the correct data sheet in the system is worthless if the production order doesn't pull it automatically. It's the equivalent of having the instruction manual in the drawer while the operator works from memory.
When a production order is created, the system should automatically associate the most recent approved version of the technical data sheet with the order — with no manual intervention. The operator cannot change the data sheet directly on the order: only the quality manager can, with a record. Any deviation from the specifications — substituted raw material, adjusted dyeing temperature — is recorded as a non-conformity, not as an "informal adjustment" that disappears at the end of the shift. Batch-by-batch traceability is guaranteed: you know which yarn or fabric batch was used in each order, with which technical data sheet, and who approved it.
This direct link between data sheet and order is exactly what international buyers are starting to require as a condition of supply, in line with the EU Strategy for Sustainable and Circular Textiles. A technical data sheet disconnected from the production order is a compliance risk — not just an operational one.
The MULTI ERP supports this direct link between the technical data sheet and the production order, with batch-by-batch traceability from the raw material, designed from the ground up for the specificities of the Portuguese textile and clothing industry. For real-time monitoring of what happens on the line, KORA Productivity complements this traceability with production capture via industrial terminal.
- ☐ Technical data sheet automatically associated with the production order
- ☐ Changes to the data sheet on the order require explicit authorisation and a record
- ☐ Deviations recorded as non-conformities (not as informal notes)
- ☐ Batch-by-batch traceability active and auditable
Step 5 — Audit regularly with non-conformity data
The technical data sheet is not a static document. It's an operational contract that ages badly if it isn't reviewed with real production data. The review cadence has to be based on evidence, not an arbitrary calendar.
Every month, cross-reference the recorded non-conformities with the associated technical data sheets. If a reference accumulates recurring deviations, the data sheet may be out of date — or may never have been correct from the start. Before each new collection goes into production, audit the data sheets of the carryover references that carry over from the previous collection: they are the most dangerous because everyone assumes they're "already sorted". And when a customer updates their quality or compliance requirements, identify all that customer's active references and review the data sheets as a block — not reference by reference as they enter production.
OEE and quality dashboards — such as those available in Qlik Sense integrated with the ERP — allow you to cross-reference the rework rate per reference with the active technical data sheet version in that period. That is how you distinguish a process problem from a specification problem. They are different diagnoses with different solutions — and confusing them is costly.
- ☐ Monthly review of non-conformities per active reference
- ☐ Audit of carryover data sheets before each new collection
- ☐ Defined process for block updates when a customer revises requirements
- ☐ Quality dashboard per reference available and in use
Audit checklist — 18 points to use in tomorrow's meeting
| Area | Verification point | Status |
|---|---|---|
| Repository | There is a single "master" repository for technical data sheets | ☐ Yes / ☐ No |
| Repository | The repository has defined write access control | ☐ Yes / ☐ No |
| Repository | There are no data sheets in network folders, email or paper as the active version | ☐ Yes / ☐ No |
| Structure | All mandatory fields are defined and locked in the system | ☐ Yes / ☐ No |
| Structure | Raw material composition with exact percentages (not "approx.") | ☐ Yes / ☐ No |
| Structure | Explicit sewing and finishing tolerances per size | ☐ Yes / ☐ No |
| Structure | Customer approval recorded with date, channel and name of approver | ☐ Yes / ☐ No |
| Versions | Numbered version system active (no "final2" or "approved_v") | ☐ Yes / ☐ No |
| Versions | Previous versions locked (not deleted) after approval of a new version | ☐ Yes / ☐ No |
| Versions | Automatic notification to the production manager when an active data sheet is changed | ☐ Yes / ☐ No |
| Versions | Minimum lead time defined between approval and entry into production | ☐ Yes / ☐ No |
| Production | Technical data sheet automatically associated with the production order by the system | ☐ Yes / ☐ No |
| Production | Changes to the data sheet on the order require explicit authorisation with a record | ☐ Yes / ☐ No |
| Production | Deviations from specifications recorded as non-conformities (not informal notes) | ☐ Yes / ☐ No |
| Production | Batch-by-batch traceability active and auditable per order | ☐ Yes / ☐ No |
| Audit | Monthly review of non-conformities cross-referenced with active technical data sheets | ☐ Yes / ☐ No |
| Audit | Carryover data sheets audited before each new collection | ☐ Yes / ☐ No |
| Audit | Quality dashboard per reference available, up to date and in regular use | ☐ Yes / ☐ No |
What this checklist doesn't solve
Eighteen points in green don't guarantee zero returns. They guarantee that, when the return happens, you know exactly where the process failed — and you can prove to the customer that the error was isolated, not systemic. That distinction is worth contracts.
What the checklist doesn't solve is the culture of "informal adjustment" — the line decision that never gets recorded because "it's just this once". That pattern isn't fixed with software. It's fixed when the production manager realises that the record protects him, not just the company. That conversation is harder than any technical implementation — and it's the only one that really matters to have before starting Step 1.
Frequently asked questions
What is an operational technical data sheet and how does it differ from a filing document?
An operational technical data sheet is a living contract linked directly to the production order, versioned in the system and audited with real data. A filing document is static, stored without version control and disconnected from the process. The difference is critical: the operational one prevents errors before production; the filing one only documents what has already happened.
What is the biggest generator of errors in technical data sheets in the Portuguese textile industry?
The manual transcription of technical data sheets onto production orders. Every human copy is an opportunity for divergence. Many factories have the correct data sheet in the ERP but production works from out-of-date printouts because "it's faster", causing non-conformities detected only at the point of return.
How many different repositories hold the technical data sheets in a typical factory?
Usually three or more: a network folder with old Excel files, customer emails with recent versions, and information in the heads of line managers. None of these agree with the others. This is a governance problem, not a technology one — technology solves it once they acknowledge the problem.
What are the most critical fields missing from incomplete technical data sheets?
The reference to the approved raw material batch (traceability is impossible without it), explicit sewing tolerances per size (not generic ones), and documented customer approval with date, channel and name of the approver. "The customer approved by email" does not satisfy international audits.
How can I identify the real risk of missing technical data sheets in my system?
Compare the number of SKUs active in production with the number of SKUs with an associated technical data sheet. The difference is your real risk. In factories with 400 to 800 references, that difference is rarely zero and represents production without documented specifications.
Why is it important to bring production and quality together in the same room during the mapping?
The disagreements between what each department considers "the correct version" of the data sheet are the source of half the errors found. Two hours in the same room reveal inconsistencies that separate meetings never show, exposing the true state of data sheet governance.
What does "version control with change traceability" mean in technical data sheets?
It means that each change generates a documented record — who changed it, when, what and why. It stops customer revisions (such as 2mm on the side seam) from reaching cutting weeks after being approved. Without it, changes get lost between email and production, causing rework.
Sources
- Regulation (EU) No 1007/2011 — Textile fibre names and composition
- Associação Têxtil Portuguesa (ATP) — National textile production and export statistics
- Instituto Nacional de Estatística (INE) — International trade data and destination markets of the Portuguese textile industry
- ISO/IEC 27001 — Information systems management and documentary traceability in production processes