AI for stock and inventory management

In stock the most common starting error is to ask AI to predict when to reorder, which is precisely the use case in which it yields less: predictions are a statistical problem, and a well calibrated traditional model usually suffices and is easier to explain to those who use it. The real value lies in interpreting what is misspelled today: catalogues grown for years without a rule, articles described in three different ways, movements that move away from the usual without anyone having time to notice.

Before looking at use cases, though, it is worth knowing what the tax standard asks to keep track when talking about warehouse, because it changes what an automation project needs to predict from the start.

What the warehouse records must track, by law

Companies above a certain size threshold must keep auxiliary filings of stock, in a systematic form and according to criteria of orderly accounting, to follow the variations between the stocks detected in the annual inventories, as established by the Article 14 of Presidential Decree 600/1973. The quantities of goods intended for sale, semi-finished products (if distinctly classified), finished products, raw materials and packaging must be shown. The same rule allows to exclude from the detailed tracking the categories of goods whose total cost in the previous year does not exceed a minority share of the total, chosen from those of more marginal importance.

Those subject to this obligation, because of turnover and structure, therefore cannot treat inventory as purely operational data: it is a matter of accounting records in every respect, with a direct link to the inventory book that the Article 2214 of the Civil Code imposes on those who engage in commercial activity, discussed more closely in AI for Accounting. If you are not sure if the threshold concerns you, it is one of the quickest questions to clarify with your accountant before setting up any project: it changes if the system you build only has to help those looking for an article or it also has to produce a data that ends in declaration.

It is worth adding that the annual inventory to which the warehouse records link is not a purely administrative exercise: it is the moment when the written stock meets the real stock on the shelf, and the differences that emerge in that comparison are often the same that an automatic reporting system might have indicated months earlier, if someone had listened to it on daily movements instead of waiting for the year-end count.

The variety of the catalog counts more than square meters

It is the criterion that decides whether a project makes sense, and is misunderstood more often than it seems. A huge warehouse with a few dozen standardized items does not have a problem of interpretation: the codes are few, everyone knows them, the management software manages them without help. A physically small warehouse with thousands of heterogeneous references, spare parts, small parts, technical material, instead has a research and registry problem that is felt every day.

• How many different references do you really have in the catalogue, not by heart?
• How long does it take a new person to find an article on their own?
• How many suspicious duplicates coexist in the registry under different names?
• How many times have you ordered something that was already in the house under another name?

The last two questions usually get uncomfortable answers, and that's where the benefit is measured: the more awkward the answers, the more material the project has to work on from day one.

The most immediate case: look in a misspelled catalog

Those who have worked in the warehouse for years know the codes from memory. Those who have recently arrived do not, and waste precious time in the moments of greatest traffic. A system that understands a description such as "that brass fitting with the recessed attachment" and proposes compatible candidates, letting those who know the piece confirm, eliminates a barrier that those who have worked there for a long time even stop noticing as a problem.

Connecting new price lists to catalog codes

Similar descriptions may hide different variants or packages. The flow for update supplier price lists with AI preserves the correspondence between external and internal codes, reports dubious associations and verifies unity and validity before loading. It is a delimited passage of the registry, useful even when the catalog feeds more business activities.

When the registry is the real project

The same article ends up being called in three different ways depending on who inserted it and from which supplier arrived that day. The result is duplicates, wrong orders, and stocks that never fully return. Fixing the registry isn't as flashy as an assistant answering questions, but it's the work that makes everything else reliable.

1. Measure the disorder. How many codes you have, how many duplicate suspects, how many descriptions too short to be useful.
2. Have the system propose groupings. Locate descriptions that likely point to the same article.
3. Get validated by those who know the pieces. Only those who handle them know if two similar items are really interchangeable or only similar.
4. Define a nomenclature for the future. Without a shared rule disorder recreates itself in a few months.
5. Correct duplicates in management software with attention to the history of movements already recorded on each code.

The third step cannot be skipped: two articles with almost identical description can be the same piece or two incompatible components, and the difference is known only by those who hold them. A decided amalgamation without that verification produces wrong stocks, which is a worse problem than the disorder from which one started.

The anomalies that no one has time to look for

Articles that have been stationary for too long, movements out of the usual pattern, recurring differences on the same codes: they are controls that in theory are done and in practice almost never, because no one has time to look at the entire catalog every week. A system that compares expected and real movements and only signals true deviations, not every variation, directs where to look without replacing the physical count that remains necessary anyway.

Here, the difference between a useful system and an ignored one lies entirely in the alert threshold. A system that warns about every small fluctuation is muted within a week by its recipients, just as a notification that sounds too often ends up being disabled. A system that only flags deviations beyond an established pattern — perhaps the same item code deviating for the third time in a month — gets attention instead, because its recipients learn to trust it. Calibrating this threshold takes a few weeks of observation together with someone who knows the warehouse; it is not a parameter you can guess correctly on the first attempt.

The spare parts retailer and the workshop with the technical warehouse

In one example: a spare parts retailer with a very large catalog receives word-described telephone requests, not by code, and the most natural project is just natural language research, with visible benefit from the first week of use.

A manufacturing company with an internal technical warehouse experiences the opposite problem: the items are less numerous but the registry has become dirty in years of insertions made by different people, with different nomenclatures. Here the right project is normalization, a less immediate job but that applies regardless of AI, because a clean registry also serves those in the company who will never touch an artificial intelligence system.

Between the two, there is also a middle case worth recognising: a company with both a large catalogue and poorly maintained master data. In that case, the order in which you tackle the two projects matters as much as the projects themselves. Starting with search before fixing the master data means building a system that returns plausible but not always correct answers, because it works with duplicate or inconsistent descriptions; the risk is that the first wrong answers destroy users’ trust before the project has had a chance to show what it can really do. It is better to accept a few extra weeks at the start to fix the underlying data, even if the first visible result arrives later.

Who instead has a small warehouse with a few dozen items that everyone knows by heart should conclude, honestly, that none of these projects are needed: it is a legitimate conclusion, more frequent than the technology providers admit, and it must be accepted instead of building something that no one will really use. The same honesty in recognizing when a project has no object is discussed, for another business function, in AI for staff shift scheduling: the underlying criterion, look at the real problem before the technology, does not change from one function to another.

The warehouse does not work isolated from the rest of the company. A clean registry is the condition for the matching of invoices and orders described in AI and Electronic Billing, and the same applies to the comparison of supplier quotes discussed in AI for procurement and supplier management: if the same article exists under three different codes, neither of the two downstream projects will work as promised. For this reason, when the disorder is so much, it is better to fix the registry first of all the rest, even if the direct return seems less immediate than an assistant who immediately answers the questions.

Before leaving, calculate what the project would really cost with the method described in how much it costs to automate a process, taking into account both the initial development and maintenance that a live catalogue requires in subsequent years. If you work in production and want to figure out where to start between research, registry and anomalies, Giallo Studio helps to automate the function that today generates the most lost time, starting from where disorder weighs most on daily work.