KORA Inventory: batch-to-batch traceability in the finished product warehouse

The brand demands the recall. A batch of knit fabric with a dyeing defect, caught in the customer's final inspection at Inditex. A simple question: which pallets of finished product contain that fabric batch, and where have they already been dispatched to? In a warehouse with traceability only down to SKU level, the answer takes two days and involves three people cross-checking paper packing lists. With well-built batch-by-batch traceability, the answer comes out in four minutes from a terminal. In this article, that difference is resolved in technical detail — from data modelling to the scan at the loading bay.

The thesis of this article is uncomfortable for anyone who bought a WMS off the catalogue: batch traceability is not won in the software, it is won in the capture. The ERP that stores the "batch" field in the document line is of no use if the loading bay operator confirms the whole pallet with a single SKU scan. The batch is born or dies at the moment of the physical movement — and that is where most projects fail, not in the relational model.

This was already framed at the conceptual level in KORA Inventory in the warehouse: configuring zones, batches and traceability. Here we come down to the concrete floor.

Before we get into the model, it is worth situating why this conversation stopped being technical and became commercial. Portuguese garment manufacturing lives largely on subcontracting for international parent houses — Inditex, Decathlon, Mango, Tom Tailor, Lacoste. Those brands have built traceability into their specifications. It is no longer a "nice to have" that the production director weighs up in next year's budget: it is a condition of qualifying as a supplier. The EU Strategy for Sustainable and Circular Textiles, published by the European Commission in 2022, and Regulation (EU) 2024/1781 on ecodesign with the digital product passport, push the requirement up a level — it is no longer enough to know the fabric batch, you need to know the composition, the origin and the journey. Anyone who does not have the backbone of traceability in place when the digital product passport becomes mandatory for textiles will discover that the conversation is not about internal efficiency, it is about commercial survival.

1. Recommended architecture

Batch-by-batch traceability of finished product rests on three layers that must not be mixed: the identity model (what a batch is), the position model (where it is) and the movement record (who moved it, when, from where to where). Whoever merges position and movement into a single table pays the bill at the first stocktake.

The temptation to simplify is understandable. A generalist WMS vendor shows you a screen where the pallet has a "location" field and a "last movement" field, and it looks like everything is there. It is, until the day you need to reconstruct the history of a pallet that passed through seven positions in four days. If position and movement are the same column, you only have the last one. The genealogy of the movement has vanished. Separate the three layers from day one — the cost of separating them later is rewriting the model with real data in production, which no one does without pain.

The batch as a first-class entity

In the correct model, the batch is not an attribute of the order line. It is an entity with its own identity, parent and children. A finished-product batch inherits genealogy: fabric batch → cutting batch → make-up order → finished-product batch. That tree is what allows the recall to be answered in four minutes and not in two days.

The practical difference between treating the batch as an attribute and as an entity is brutal when the time for the split comes. A pallet of 48 boxes may carry two different fabric batches — because the cutting order consumed the end of one roll and the start of another. If the batch is an attribute of the line, each box has to duplicate information and consistency is at the mercy of fragile triggers. If the batch is an entity, the pallet simply points to two batches with partial quantities, and the tree remains intact. In footwear, where a dispatch box routinely mixes sizes and colours of the same reference, this modelling stops being an architect's preference and becomes a functional requirement.

Each physical storage unit — the pallet, the master box, the roll — receives a logistics identifier. In Portuguese practice, this means an SSCC (Serial Shipping Container Code) on a GS1-128 label, which binds SKU + batch + quantity + position. The SSCC is the number the operator reads. Everything else is resolved behind the scenes.

The SSCC is an 18-digit number, structured according to the GS1 specification: an extension digit, the GS1 company prefix (which identifies your company uniquely worldwide), a serial number assigned by you, and a calculated check digit. The part that matters operationally is this: the SSCC is non-repeatable. A pallet dispatched today from Famalicão shares no identifier with any other pallet on the planet. This allows the brand, the carrier and your warehouse to speak of the same physical unit without ambiguity — and it is exactly what is missing when you try to trace with "pallet 14 of aisle B".

If the loading bay operator has to type the batch number into the terminal, the project has already failed. The batch has to be on the label, and the label has to be readable from a metre away with gloves on.

Capture at the movement, not at the reconciliation

The golden rule: the batch is bound to the position at the moment of putaway, not at dispatch. Whoever tries to reconstruct the batch at the moment of dispatch — because "there was no time at receipt" — ends up with finished product in stock with no known batch, and at that point traceability is accounting fiction.

There is a psychological reason for this rule that no technical manual explains. At receipt, the operator has time and context: the pallet has just arrived, the origin label is in front of them, the production order is fresh. At dispatch, they are under pressure — the loading convoy is waiting, the driver is complaining, it is 5:30 pm on a Friday at month-end. Asking them to reconstruct genealogy at that moment is asking for an error. Capture has to happen where there is cognitive slack, not where there is stress. Whoever designs the flow against the human nature of the loading bay is programming failure.

The KORA Inventory Suite captures the batch at the industrial terminal on every state transition: receipt from production, putaway in position, internal transfer, picking and loading. Each scan generates an immutable record. It is this flow that the ERP layer — typically the ERP MULTI — consolidates for valuation and fiscal document purposes.

The immutable record and why a movement is not edited

A recorded movement is not altered — it is corrected with a movement in the opposite direction. This rule seems bureaucratic until the first audit by the brand. If a putaway movement can be edited after being recorded, the genealogy tree loses the property that makes it trustworthy: that it reflects what happened physically. An operator who gets the destination wrong does not "edit" the movement — they make a correction movement, which stays recorded with user, time and reason. The audit sees the two movements and understands the full story. Systems that allow silent editing produce reports that lie without leaving a trace — exactly what an auditor from an international brand is trained to be suspicious of.

2. Parameters, metrics and thresholds

Numbers that separate a warehouse with real traceability from one with PowerPoint traceability. These values are defensible in finished-product operations for textiles, footwear and distribution; adjust to your volumes.

Why 800 ms is not an engineer's whim

The latency between the scan and the confirmation on the screen seems a minor detail. It is not. The loading bay operator works at a motor rhythm: read, confirm, move to the next. If the confirmation takes more than a second, they lose confidence that the scan went through and fire again. Two scans of the same SSCC generate a duplicate movement, and the duplicate movement generates phantom stock that only appears at the next stocktake. The 800 ms threshold is not about database speed — it is about keeping the operator within their natural rhythm. Above that value, the system starts to fight against the body of whoever uses it, and the body always wins.

The adoption metric matters more than the stock metric

The metric nobody wants to measure but which decides everything is the first-touch scan rate. Below 98%, the warehouse supervisor — the one who will not accept being off the radio for more than two hours — abandons the terminal and goes back to the notebook. And at that point you lose everything. The adoption KPI matters more than any stock dashboard.

There is a cruel asymmetry in this number. A warehouse with 99% first-touch scans has a fluid operation; one with 95% has an operation in silent rebellion. The difference of four percentage points is not linear — it is the point where the operator decides whether to trust the terminal or to bypass it. And when an experienced warehouse supervisor, with fifteen years of business knowledge in their head, decides that the terminal gets in the way of month-end, no training brings them back. You win adoption in the first month or you lose the project. Measuring this rate daily in the first six weeks of rollout is more important than any stock valuation report.

A pretty stock dashboard with 92% terminal adoption is a high-resolution operational lie. Measure first who uses the system; what the system says comes afterwards.

Thresholds by company size

The values in the table above are defensible across the board, but the real requirement varies with size and risk profile. A garment maker of 60 people subcontracting for a single parent brand lives and dies by batch coverage at dispatch — if it fails once in an audit, it loses the customer that is 70% of turnover. A food distribution centre of 30 thousand square metres has batch coverage guaranteed but is obsessed with FEFO enforcement, because an out-of-date batch dispatched is direct legal risk. Adjust the hierarchy of the metrics to what, in your case, kills the business.

3. Practical configuration

Three configurations that make or break traceability. Illustrative snippets — adapt to your instance.

Mandatory batch capture rule

# Capture policy: batch mandatory at receipt from production
Prevents putaway without an associated batch — fails fast at the terminal
captura_lote:
  evento: putaway_producao
  lote_obrigatorio: true
  validacao: genealogia_existe   # batch must have a known parent
  bloqueio_sem_lote: true        # does not allow movement confirmation
  etiqueta: SSCC_GS1-128         # logistics label format
  reimpressao: permitida_com_log # reprinting records user + reason

The design principle behind this configuration is fail fast. The system refuses the movement the instant the batch is missing, at the terminal, with the operator still in front of the pallet. The alternative — accepting the movement and marking the record as "pending batch" to correct later — is the gateway to stock with no genealogy. "Later" never comes. Always prefer the hard block at the moment to the deferred correction that no one makes. The operator complains in the first week and is grateful at the first recall.

Recall query — from batch to the list of dispatches

-- Given a compromised fabric batch, return customers and delivery notes
-- Traverses the genealogy: fabric -> cutting -> FP -> dispatch
SELECT e.cliente, e.guia_remessa, e.data_carga, m.quantidade
FROM lote_genealogia g
JOIN movimento_expedicao m ON m.lote_pa = g.lote_filho
JOIN expedicao e          ON e.id = m.expedicao_id
WHERE g.lote_raiz = :lote_tecido_comprometido
ORDER BY e.data_carga;
-- Operational objective: result in under 5 minutes

This query looks trivial because the upstream modelling did the heavy lifting. When the genealogy is materialised in a closure table — where each parent-child relationship is pre-calculated, including the indirect jumps — the recall is resolved with a single JOIN. Whoever did not materialise the genealogy and tries to traverse the tree recursively at runtime discovers, at the worst possible moment, that the query takes minutes to run in a warehouse with half a million movements. The cost of materialisation pays for itself the day the brand is on the phone waiting for the list. Invest in the structure, not in the cleverness of the query.

FEFO enforcement in food distribution

# Picking blocks out-of-order-by-expiry batch (FEFO)
picking_regra:
  estrategia: FEFO              # First Expired, First Out
  tolerancia_dias: 0           # zero deviation in food
  override: supervisor_apenas  # only supervisor with PIN breaks the rule
  log_override: obrigatorio    # GDPR audit + traceability

The FEFO configuration ties in with the management of expiry dates in food distribution — where the batch is not only traceability, it is prevention of the illegal dispatch of out-of-date product.

The override and its audit trail

Every blocking rule needs an escape valve, or the warehouse stops at the first legitimate exception. But the valve has to leave a trail. The supervisor PIN override does not exist to be convenient — it exists so that, when a batch goes out of order, there is a name, a time and a reason associated with the decision. This serves the accountability traceability required by the GDPR as to who did what, and it serves the company's defence if a product dispatched out of order causes a problem. A silent override is worse than having no rule at all: it gives the illusion of control without the substance.

4. Integrations and dependencies

Batch traceability does not live in isolation. It depends on who writes upstream and serves whoever reads downstream. The classic blind spot is the production–warehouse boundary: if the finished-product batch is born in shop-floor capture but does not reach warehouse receipt with the same identifier, the genealogy breaks exactly where it hurts most.

The production–warehouse boundary is where the chain breaks

It is worth insisting on this point because it is what we see going wrong most often. In a textile factory with production capture on the shop floor, the finished-product batch is born at the make-up line terminal. If that batch travels to the warehouse on a piece of paper that the operator transcribes — or worse, if the warehouse assigns a new batch at receipt because "it didn't know the production one" — the genealogy tree gains an orphan node. The warehouse batch exists, but does not point to the make-up order, which in turn pointed to the cutting batch and the fabric batch. The recall stops delimiting upstream at the exact point where the chain was stitched. The integration between KORA Productivity and KORA Inventory exists precisely so that this batch crosses the boundary without human transcription.

The delivery note has to carry the batch

• The electronic delivery note has to carry the batch — not just the SKU — so that traceability survives leaving the warehouse (DL 28/2019, with ATCUD and monthly SAF-T communication under the terms of Ordinance 195/2020).
• Whoever runs a MES without connecting it to the ERP loses the genealogy at the production–warehouse jump. The cost of this is detailed in MES without ERP integration: the hidden cost the COO does not see.
• The warehouse network is a critical dependency: Wi-Fi with coverage gaps between shelves generates lost scans. Validate roaming before the rollout, not after.
• Remote access of terminals and integrations goes through a segmented VPN — a requirement reinforced by NIS2 (EU Directive 2022/2555, transposed by DL 65/2025).

The network is not an IT detail — it is the floor of the operation

The point about Wi-Fi coverage deserves more than a line in a list. A finished-product textile warehouse has five-metre metal shelves loaded with rolls — a hostile environment for radio. Between two aisles there may be a dead zone where the terminal loses signal and the scan stays in local buffer. If the terminal does not have robust offline management — recording locally and syncing when signal recovers — that scan is lost and a phantom movement is born. Validating roaming coverage aisle by aisle, with the warehouse full and not empty, is part of the implementation. A network survey done with the warehouse at half capacity lies about the dead zones that appear when the shelves fill up. Test in the worst case, not the comfortable one.

Perfect genealogy in the software and a Wi-Fi dead zone in aisle F produce the same result: a pallet that came in and no one ever knew where it ended up.

5. Operational pitfalls

Eight failures we have seen in production, anonymised. None is in the vendor's manual.

1. The pallet scan that confirms the SKU, not the batch

At a garment unit in the Vale do Ave, the operator read the SKU label and confirmed the whole pallet. The batch was left "blank" and the system inherited the last batch put away — wrong. Fix: SSCC label at pallet level, with batch embedded, and blocking of confirmation without an SSCC read. The symptom that exposed the problem was perverse: the stock reports tallied in quantity, only the genealogy was systematically wrong. No one noticed until the first recall, when the list of affected customers came back with names that had never bought the batch in question.

2. Reprinting labels without a log

Torn label, operator reprints — and creates a second SSCC for the same physical pallet. Two identifiers, one pallet, phantom stock. Fix: reprinting only with user and reason recorded, and invalidation of the previous SSCC. The detail that distinguishes a good correction from a bad one is the invalidation: reprinting without killing the old SSCC leaves two numbers alive for the same unit, and the pallet ends up counting twice in the inventory. Reprinting is the most innocent movement in the warehouse and one of those that generates the most phantom stock.

3. The partial batch at picking

The order takes half a pallet of one batch and half of another. If the system does not support partial batch picking with automatic split, the operator "rounds up" and the genealogy of the dispatched box mixes batches with no record. Fix: mandatory batch split at the picking movement. In footwear, where an order for one reference crosses sizing from two production batches in the same box, the partial split is not an exception — it is the normal case. A system that does not model it natively forces the operator to lie to the terminal dozens of times a day.

4. Internal transfer without tracking

Moving a pallet from the quarantine zone to the dispatch zone "to free up space", without a scan. Result: blocked product goes out as if it were approved. Fix: every transfer between zones generates a movement with a scan — no exception, not even "just this once". The transfer without a scan is the most treacherous because it is the most reasonable: the operator is helping, organising, freeing up space. The good intention is precisely what makes it dangerous — no one records it as an error because no one perceives it as an error.

5. Annual stocktake instead of cycle counting

Whoever counts only once a year discovers the drift when they already have 1.5% accumulated error — and by then picking is already failing. Fix: ABC cycle counting, A batches counted weekly, accuracy kept above 99.5%. The annual stocktake also has the defect of stopping the warehouse for two days and giving a number that is already outdated the next day. Cycle counting distributes the effort, keeps the system always close to the truth, and turns error correction into a continuous adjustment rather than an annual shock.

6. FEFO configured but with free override

At a regional food distribution chain, FEFO was active but any operator could ignore it. In three months, they dispatched out-of-order batches out of habit. Fix: override only with supervisor PIN and auditable log — this also meets the accountability traceability requirements of the GDPR as to who did what. The finer lesson here is about behaviour: a rule that anyone can bypass without friction stops being a rule within a few weeks. The friction of the PIN is not bureaucracy — it is what turns the exception into a conscious decision rather than a reflex.

7. The label that does not read with condensation

Product coming from cold storage fogs up the reader and the label. The first-touch scan rate drops to 85%. Fix: labels of suitable material and readers with tolerance to condensation; test in real conditions, not in the office. This is the canonical example of why validation has to be done in the real environment. In the office, at 22 degrees and dry, everything reads on the first touch. At the loading bay, with the pallet sweating after coming out of cold storage, the optical reader sees a smudge. The difference between 98% and 85% first-touch scan is measured in the climate, not in the equipment datasheet.

8. Genealogy that stops at raw material receipt

The fabric batch comes in traced, but the make-up does not bind it to the order. The tree breaks at the first level. Fix: raw material batch capture at production consumption, in KORA Productivity, linked to the order — without this, the recall delimits nothing upstream. This is the most expensive of all because it is the one that invalidates the entire investment: you can have impeccable traceability of finished product and, at the moment of the brand's recall, discover that you cannot say which other orders used the same fabric batch. Downstream traceability without upstream capture is half a chain — and half a chain delimits no recall at all.

Perfect traceability in the ERP and relaxed capture at the loading bay produce the worst of both worlds: a pretty report that lies with confidence.

6. Final technical decision

No hedging. The choice of traceability level depends on size and sector — and on the cost of a poorly delimited recall, which in textiles for an international brand can cost the whole account.

The TCO calculation against the cost of a recall

The underlying decision rule: calculate the TCO of traceability against the expected cost of an extended recall. In textiles and footwear for export, the ROI pays for itself at the first well-delimited recall. The common error in this calculation is comparing the cost of traceability only with the operational efficiency gain — which exists, but is the least important. The real value is in the tail: the rare and expensive recall event that, without delimitation, extends to innocent batches. The brand, faced with uncertainty, imposes the recall on the whole lot, and the difference between recalling three pallets and recalling three hundred is the quarter's bottom line. Traceability is, at heart, an insurance policy that also improves the operation day to day.

What changes with the digital product passport

The calculation above is going to change shape in the coming years. Regulation (EU) 2024/1781 on ecodesign for sustainable products introduces the digital product passport, which for textiles will cease to be optional. When it comes into force for the sector, each item will have to carry information on composition, origin and journey — and that requires exactly the genealogy backbone this article describes, extended upstream to the raw material. Whoever sets up batch-by-batch traceability now, for reasons of recall and supplier qualification, is also building the foundation of the digital passport. Whoever delays will have to build it in a rush when the obligation arrives — and rushing always costs more.

Observed operational gains

In three implementations in the footwear sector, the reduction in picking cycle time with batch by SSCC ranged between 18% and 27% over four months, through the elimination of the double paper check. The mechanism is simple: when the SSCC binds everything in a single touch, the manual check the operator used to do to make sure the right pallet went to the right order disappears. That efficiency gain is what makes adoption easy — the operator quickly realises that the terminal saves them work rather than adding to it, and the first-touch scan rate rises by their own will, not by imposition.

For picking proper, the configuration by voice and batch is detailed in KORA Inventory: configuring voice and batch picking in the warehouse, and the interconnection with distributor orders in KORA B2B: an order portal for customers without a sales force in the field.

7. How INFOS implements it

We implement batch-by-batch traceability from the inside out: we start with capture at the loading bay and on the shop floor — because that is where the chain breaks — and only then do we connect valuation and the fiscal document in the ERP MULTI. The KORA Inventory Suite captures each movement at the industrial terminal, binds the SSCC to the position, and consolidates the genealogy that answers the recall in minutes. We have worked the textile and footwear sector for more than three decades — we know the difference between the model that works in the demo and the one that survives month-end with the warehouse supervisor without leaving the radio.

The implementation order is not negotiable

There is a reason we start with capture and not with the report. The temptation for whoever buys the project is to want to see the pretty dashboard first — the screen where the recall is resolved in minutes. But the dashboard is the last piece, not the first. If we build capture at the loading bay with discipline, the genealogy fills up on its own and the dashboard is almost trivial to set up. If we start with the dashboard and leave capture to the end, we build a sophisticated report fed by data that no one trusts. The order — capture first, consolidation next, report last — is what separates a project that survives the first recall from one that produces only high-resolution accounting fiction.

The first month decides the entire project

The most critical phase of any traceability rollout is not the configuration nor the integration — it is adoption in the first month. It is when the warehouse supervisor decides whether the terminal is an ally or a hindrance. That is why we measure the first-touch scan rate daily in the first weeks, adjust labels, readers and network coverage where the read fails, and are on the shop floor — not in the office — while the operator learns the new gesture. A traceability project is won with hands on the concrete of the warehouse, not with slides in the meeting room.

Sources

• INE — Trade Statistics (trade turnover, number of companies and workers; trade margin in wholesale).
• Decree-Law no. 28/2019 — invoicing regime and ATCUD; Ordinance no. 195/2020 — SAF-T communication.
• Directive (EU) 2022/2555 (NIS2) and Decree-Law no. 65/2025 — cybersecurity requirements for essential and important entities.
• Regulation (EU) 2016/679 (GDPR) and Law no. 58/2019 — data protection and access traceability.
• Regulation (EU) 2024/1781 — ecodesign for sustainable products and digital product passport.
• European Commission — EU Strategy for Sustainable and Circular Textiles (2022).
• GS1 — specification of the Serial Shipping Container Code (SSCC) and GS1-128 symbology.

Frequently asked questions

What is batch-by-batch traceability in the warehouse?

It is the ability to identify and locate each finished-product batch individually in the warehouse, allowing a rapid response to recalls or quality issues. It differs from SKU traceability because it records not only the type of product, but the specific batch, its position and movement history.

Why can the batch not simply be an attribute in the ERP?

Because the batch is born at the moment of the physical movement in the warehouse, not in the software. If the loading bay operator confirms a whole pallet with a single SKU scan, the system never comes to know which batch it is. The ERP that stores the "batch" field in the document line is useless without rigorous capture in the operation.

What is the difference between treating the batch as an attribute and as an entity?

As an attribute, each box duplicates information and consistency becomes fragile. As its own entity, the pallet points to multiple batches with partial quantities, keeping the genealogy tree intact. This is critical when a pallet contains two different batches, as in fabric cutting.

What is the SSCC and what is its function?

The SSCC (Serial Shipping Container Code) is a unique 18-digit number that identifies each physical storage unit — pallet, box or roll. It binds SKU, batch, quantity and position in a GS1-128 label, allowing the brand, carrier and warehouse to speak of the same unit without ambiguity.

When should the batch be captured in the warehouse?

At the moment of putaway, not at dispatch. At receipt, the operator has time and context. At dispatch, they are under pressure and make errors. Trying to reconstruct the batch at the end results in finished product in stock with no known batch, turning traceability into fiction.

Why did traceability stop being technical and become commercial?

Because large international brands — Inditex, Decathlon, Mango — have built traceability into their specifications as a condition of supplier qualification. Regulation (EU) 2024/1781 on the digital product passport will make this mandatory for textiles.

How is the correct data model structured for traceability?

In three separate layers: the identity model (what a batch is), the position model (where it is) and the movement record (who moved it, when, from where to where). Mixing position and movement into a single column prevents reconstructing the history when you need it.