Inventory Management: What to Control and How to Prioritize It

A customer orders a product that the system shows as available, but it cannot be found when you look for it. Or, conversely, you purchase more units of an item that was already in the warehouse. When these situations happen repeatedly, the issue is usually not just counting stock: what is missing is inventory management that connects actual stock with purchases, sales, returns, and adjustments.

The initial decision is to choose which information needs to be reliable so that you can operate without relying on constant manual checks. By the end, you will be able to define the elements your system should control, rank them by priority, and avoid overloading a first version with features that do not yet solve the main problem.

Direct answer: what inventory management should solve

Inventory management should allow you to know, for every relevant product or material:

• how many units you actually have;
• where they are;
• which movement explains every quantity change;
• which units are committed to an order, reserved, or unavailable;
• who can correct a record and for what reason.

You do not need to start by recording everything at the same level of detail. A business that sells finished products, one that works with materials, and one that provides services using consumables have different needs. The practical criterion is straightforward: first control what, without visibility, causes you to buy incorrectly, sell something you cannot deliver, or stop an operation.

The elements to define, in decision order

The following list is not a feature catalogue. Each point addresses an operational decision that should be made before selecting or developing a tool.

1. Products, materials, or items you will control

   Decide what is included in inventory. It may be a sales product, a part, a material, a spare part, or a consumable. Each item needs an item reference that prevents confusion between similar names.

   If two items differ in size, finish, colour, or format, confirm whether they should be separate items. Treating them as a single item can conceal specific stock shortages.

2. Unit of measure

   Define how each item is counted: units, boxes, metres, kilograms, or another measure that matches your operations. You should also clarify conversions if you purchase in one format and use or sell in another.

   This may seem minor, but it affects subsequent movements. Recording the receipt of one box is not the same as recording the units it contains if both figures are used interchangeably.

3. Stock location

   Specify where each quantity is located: warehouse, shop, vehicle, picking area, storage location, or a third-party location. If there is only one physical location and you do not need to distinguish areas, you can start with a single location.

   Add detail when it changes a decision. For example, separating the warehouse and the shop makes sense if you need to know which one can fulfil a delivery.

4. Movements that change stock levels

   Every stock change should have a recognisable reason. The most common are purchase receipt, sale or consumption issue, return, transfer, and adjustment after a stock count.

   Recording the movement, rather than simply overwriting a final quantity, makes it possible to understand why a figure has changed. It also makes it easier to review a discrepancy without turning the system into an overly complex record.

5. Available, reserved, and pending receipt stock

   Physical stock does not always equal sellable quantity. Some may be reserved for an already confirmed order, under review, or pending return. Similarly, a supplier order is not available stock until it has been received.

   Separating these statuses helps ensure that a sale, a purchase, or order preparation does not rely on the same quantity with different meanings.

6. Stock counts and adjustments

   Define when physical stock is checked and how discrepancies are recorded. At a minimum, an adjustment should record the corrected quantity and the reason. Without a rule, the system may end up showing figures that nobody considers reliable.

   The goal is not to turn every stock count into a bureaucratic task, but to establish a common way to correct discrepancies.

7. People, permissions, and data ownership

   Clarify who receives goods, who confirms issues, who can create item references, and who can modify adjustments. If several people are involved, permissions prevent a necessary correction from becoming a change without context.

   It is also useful to appoint the person who will review exceptions: duplicate items, incomplete movements, or recurring discrepancies.

8. Connections with orders, purchasing, or invoicing

   An integration should only be added when it solves a specific step. For example, when a confirmed order reserves units or when a receipt updates received quantities.

   Before connecting tools, describe what data leaves one and reaches another, who validates it, and what should happen if the connection fails. Otherwise, you may duplicate movements or create discrepancies between systems.

How to prioritize the elements in your first version

Not all the above elements need to be ready from day one. To rank them, assess each one using four questions:

1. What operational problem does it prevent? Identify the specific consequence: a sale without availability, a duplicate purchase, incomplete order preparation, or a search that delays a delivery.
2. Who will use it? Data that nobody checks or updates should not have the same priority as data needed to prepare orders.
3. What happens if it is postponed? If you can continue working with a temporary manual rule without losing control, it is probably not a priority.
4. What does it depend on? Purchase automation, for example, depends first on items, units, and movements being properly defined.

Based on those answers, classify the scope into three groups:

• Essential: item references, units, available quantity, basic movements, and a criterion for adjustments. Without these, there is no reliable foundation to consult.
• Desirable: detailed locations, reservations, internal alerts, or connections with existing tools. These provide control when operations already require that level of precision.
• Future: forecasts, complex replenishment rules, highly specific reports, or automations that depend on consistent historical data.

This classification does not dictate a technical solution. It helps prevent an attractive feature from displacing a basic need, such as correctly recording a goods receipt.

Applied example: a shop with a warehouse and made-to-order sales

Imagine, as a hypothetical case, a small business that sells items from a shop and also prepares made-to-order purchases. It keeps stock in a spreadsheet and updates quantities at the end of the day. The team finds discrepancies when a product is sold in the shop and reserved almost at the same time for an order.

Its goal would not be to create a complete business management system. It would be to know which products it can deliver and prevent units that are no longer available from being reserved.

A first version could include:

• one record per product with item reference, name, and unit;
• two locations: shop and warehouse;
• receipts, issues, transfers, and adjustments with a reason;
• a view of available quantity by location;
• a reservation linked to every confirmed order;
• permissions so that only one person can modify adjustments.

In contrast, it could leave purchase forecasting, advanced reports, and automatic replenishment rules for a later phase. These features would make more sense after confirming that basic movements are recorded consistently.

The example illustrates an important idea: the scope should follow the actual flow of goods. If a delivery is prepared from the warehouse, the system should reflect that transfer or issue; if a return becomes sellable again, there should be an explicit decision to add it back into stock.

What to leave out to avoid complicating the start

It is advisable to postpone any element that does not yet have a clear usage rule. In particular:

• Replenishment alerts without an agreed criterion. An alert is only useful if you know who receives it, which quantity they should review, and what decision they can make.
• Codes, labels, or scanners without a defined physical process. Scanning technology alone does not correct poorly created item references or movements that nobody confirms.
• Generic integrations. Connecting a sales, purchasing, or invoicing system requires deciding which event updates inventory and how errors are handled.
• Extensive reports without an operational question. Start with the information needed to work: what is available, what is reserved, and which movements explain a discrepancy.
• Automatic replenishment rules based on unreliable data. Before automating a purchase, validate which stock is considered available and how receipts and issues are recorded.

Leaving these out does not mean discarding them. It means keeping them as future developments, without presenting them as a condition for basic control to work.

Next step: turn operations into a clear scope

If you already know which movements, locations, and people are involved, the next step is to turn that information into a system that fits your way of working. At AVSISTEC, you can explain your case and assess the development of an application to manage operations, especially if you need to bring inventory, orders, permissions, or your own rules together in one tool.

Before requesting it, prepare a short list of the items you control, the movements you carry out, the tools you use, and the questions you have not yet resolved. You do not need to have the solution decided: defining the problem and the minimum scope is the most useful starting point.