Can lot traceability hold up under a product recall?

How lot traceability holds up a product recall

When a product recall begins, lot traceability is the path that connects a finished code to the raw materials that entered production and to the customers who received that goods. It must be reconstructed within a few hours, using already archived documents, not from memory. If a single link is missing, a recipient cannot be ruled out and the recall expands. What matters is that the delivery note, the production sheet, and the management system all say the same thing: three conflicting records do not close the case.

In a small or medium enterprise, the lot often originates in production and the customer originates in administration. The code is written on the box, the delivery note lists the packages, the invoice names the recipient, a message confirms a substitution. None of these pieces, on its own, answers the recall question. A document crawler, or a person opening folders one by one, finds files, not a chain. The explicit link between the raw material lot, the production order, the finished lot, and the shipping document is usually missing. Without that link, the recall becomes a hunt, and every hour lost expands the list of those who must be notified as a precaution.

The recall starts and the lots do not respond

If you do not know which lots are involved, the product recall has no perimeter and ends up covering everything you cannot rule out.

The supplier's phone call or email names a raw material lot, a delivery date, or a code that in your facility has already been renamed. In the warehouse, that code may have been split across multiple production runs, or mixed with a nearby lot because the container was nearly empty. The person who packaged it remembers last week. The person who shipped two months ago is not on shift. The recall requires a list, not a recollection.

Obligations vary by sector, whether food, cosmetics, or other, and the legal perimeter must be verified with a consultant or the competent authority. On the operational level the question is always the same: given this code, who received it and where did it come from. If the answer is not in a single register, a broader set of people than necessary is notified, or there is a risk of leaving out someone who actually received the goods.

Companies that produce and deliver to a few direct customers

Here the recipient's name exists, often on the invoice. The bridge to the lot is missing. A delivery note says "12 packages" and does not say which codes were in the packages. The direct customer can be called, but it is not known whether the goods they have on hand belong to the flagged lot or to the previous week's batch. Without that detail, the call is a generic alert, not a targeted withdrawal.

Companies that sell through distributors

The wholesaler appears in the master data. The shop or laboratory that subsequently collected the goods does not. Supply chain traceability, in this case, stops at the first step if you have not asked the distributor to return the lots received and, where the sector requires it, the subsequent recipients. The SME's software cannot invent names that were never recorded: it can only make immediately accessible what was written at the time of shipment, and show the gap where the data is absent.

Where lot traceability breaks down in an SME

The chain breaks every time a lot changes medium without carrying with it the code from the previous step.

The production spreadsheet is convenient on Monday and unreadable on the day of the recall. Rows get overwritten, a filter hides closed lots, two people use two copies. The PDF delivery note has the document number and the address, almost never the lot for each line. Messages cover exceptions: a partial return, a replaced package, a lot opened ahead of schedule. The exception is precisely the case the recall must find.

• The supplier lot is on the incoming document and is not copied onto the production order.
• The production run mixes two lots and the sheet cites only one, the "main" one.
• The finished lot is on the label and not on the delivery note line.
• A return comes back into the warehouse without the code it left with.
• An urgent substitution exists only in a message, not in the management system.
• The same code is written in different ways: with zeros, without zeros, with a date in place of the lot.

None of these gaps are visible on a normal working day, because the goods ship anyway. They become visible when a path must be demonstrated in reverse. An archive of commercial documents scattered across emails and folders makes the search slower, not safer: finding the PDF does not mean finding the lot.

A lot that cannot be ruled out must be treated as involved, until the records prove otherwise.

What needs to be known within a few hours, from lot to customer

Within a few hours, three consistent lists are needed: raw materials that entered that lot, production runs that used it, customers who received it.

The backward direction starts from the finished lot and traces back to the incoming materials. The forward direction starts from the lot flagged by the supplier and traces down to the shipments. The two directions must meet. If the backward trace says "raw material A, lot 14" and the forward trace, from that same lot 14, finds no production run, one of the two records is incomplete. This is not a formal detail: it is the point at which the recall stops.

It is worth testing the path on an already closed lot, not on today's lot that everyone remembers. A code from a few months ago is chosen and someone who was not involved in that order is asked to reconstruct it using only the documents. If it is necessary to call the person who was there that day, the traceability does not hold up in a recall.

1. Given a finished lot, which supplier lots and which incoming documents went into it?
2. Given a raw material lot, which production runs used it, even in partial quantities?
3. Which delivery notes or invoices shipped that finished lot, and to which registered parties?
4. If two lots were mixed, does the record say so, or does it show only the main code?
5. Do returns and substitutions update the same chain, or do they remain outside it?

Companies that manage the warehouse on a spreadsheet and delivery notes in PDF

The spreadsheet can be sufficient as long as a single person updates it and does not overwrite it. In a recall, a snapshot fixed in time is needed: the row as it was on the day of shipment, not the row as it is today after three corrections. The PDF delivery note must be linked to that row by document number, not matched "by eye" using the date. Without the link, the entire month is reprinted and one hopes to recognise the package.

Companies that mix multiple lots in the same production run

The blend is the case that simple sheets simplify and that a recall does not forgive. If two codes go into the mixer, both must appear on the finished lot, with the quantity used if you track it. Otherwise a recall on the minor lot forces a block on production runs that never used that lot, because you cannot prove it. Writing it down at the time costs little. Reconstructing it afterwards is an estimate, and an estimate is not a record.

Custom software keeps purchasing, production, and shipping together

Software that is useful in a recall is not an additional archive: it is the point at which purchasing, production, and shipping reference each other using the same lot code.

A management system already in use often has the item master data and the delivery notes, but lacks the supply chain link that your production process requires. An off-the-shelf module assumes a way of producing that is not yours: lots that do not mix, a single warehouse, no contract manufacturing. When the process does not fit the module, people go back to the spreadsheet and the chain breaks again. We also discuss this in relation to custom software for manufacturing SMEs, when off-the-shelf modules slow things down.

A system built around the process records the lot where the event originates. At goods receipt, the supplier lot is linked to the document. In production, the lots consumed and the lot produced are declared, including blends. In shipping, the delivery note line carries the finished lot, not just the item. A return comes back in under the same code it left with. The three events remain queryable together: from the lot you reach the customer, from the customer you return to the lot.

This is software automation, not plant automation. It is not about in-line sensors or factory robots. It is about removing manual re-entry between systems that currently do not communicate: management system, spreadsheets, emails, PDFs. If the management system exists and the process has grown around it, the question is when the management system no longer follows the actual work, not how many modules to add to the catalogue.

Document text and management system data work together: the recall closes only when they match, line by line.

Which controls remain human, and how to test the recall in advance

The recall decision, the list of recipients, and the customer notification remain human confirmations: the software prepares the path, it does not sign it on your behalf.

An agent searching through documents can speed up the collection, if it works on your data and under supervision. It must not declare a lot as involved on its own, nor send notifications. Those actions are irreversible or nearly so: a recall email cannot be withdrawn with a silent correction. A confirmation from the person who knows the process makes sense, based on a list that can be reviewed.

The test is done when nothing is at stake. A closed lot is selected, the three lists are reconstructed, and the points where the path breaks are noted. The interruption is the work to be fixed, not a failure to hide. The test is repeated after the link between documents has been built into the system, on the same lot, to see whether the gap has closed. The lists of customers who received a lot are personal data: the perimeter of who can read them must be agreed upon and the processing follows the GDPR. What your sector requires you to retain, and for how long, is confirmed by a professional, not by the software.

How Leomat builds the connection on your records

Leomat designs software around the process you already have, connecting the systems that currently do not pass the lot to each other, without offering a ready-made recall module.

It is a software engineering firm based in Naples, and it works with companies across Italy. It builds complete web applications and custom management systems, together with the environment in which they run: database, interface, infrastructure, deployment, security hardening, and monitoring. The first step is understanding the process as it is: who writes the lot, on which document, where it gets lost. If a part of it is not worth bringing into the software, that is said upfront.

Integrations concern systems that do not communicate, such as management systems, spreadsheets, emails, and documents. On sensitive actions, a human confirmation remains in place. What the system does remains tracked and readable. Security is designed from the start, on recognised frameworks, beginning with access control. Data stays within the agreed perimeter. This is not industrial automation and it is not a training course: it is software designed to go into production, with backup and recovery under control. The recall obligations for your sector remain to be verified with a professional. The starting point is describing the process: in response, an approach, an architecture, and a realistic estimate are provided. The way of working is described on the Leomat website.

Frequently asked questions about recalls and lots

What is meant by lot traceability in a product recall?

It is the ability to trace back from a finished lot to the raw materials that went into it and, in the other direction, to the customers who received that goods. In a recall, it is not enough to know that the code exists in the master data. The intermediate steps are needed: incoming receipt, production, any blending, shipment, and return. If a step is not recorded, that branch cannot be ruled out. The precise obligations depend on the sector and must be confirmed with a consultant or the competent authority.

Is a spreadsheet enough to hold up a recall?

It can be sufficient only if it is the sole record, if it is never overwritten, and if every row references the previous lot and the outgoing document. In practice, the spreadsheet coexists with PDF delivery notes and with messages that record exceptions. Those exceptions are the cases the recall must find. A spreadsheet that is useful in a recall is a snapshot fixed in time, not today's version with cells already changed. If reconstructing a closed lot requires the memory of the person who was there, the spreadsheet does not hold up.

How far must the lot chain extend?

On the operational level, it must extend one step back, toward whoever supplied you with the goods or raw material, and one step forward, toward whoever received your lot. If you sell to a distributor, the forward step is that distributor, unless the sector imposes different obligations that a professional can indicate. You cannot invent subsequent recipients if they were never recorded. You can, however, immediately see the gap and ask, before a real recall, what data is missing from the agreements with whoever resells.

Can the software decide on a recall by itself?

No. It can prepare the lists and show where the chain breaks. The decision to involve a lot, the notification to customers, and the closure of the case remain confirmations made by a person. An agent searching through documents, if present, works under supervision and does not send communications on its own. A generated list and a verified list are not the same thing: the recall rests on the second, because a mistaken email cannot be undone with a correction in the management system.

Where do you start if the management system, spreadsheets, and delivery notes do not communicate?

You start with an already closed lot and write down, by hand, the path you currently follow to reconstruct it. The points at which you open another folder or call a colleague are the missing connections. Then you decide what to record at incoming receipt, in production, and at shipment, using the same code. There is no need to commit to digitalising the entire history at once. What matters is that the next lot is born already linked, and that a test recall on an old code shows which gaps remain open.

This post was created with AI