Inventory Management System
You hold 120. You can promise 96. Most systems only show you one number.
A stock record that separates what you hold, what is already committed and what is genuinely free — and keeps the movement that explains each one.
- On hand
- 120 What the business physically holdsunchanged
- Reserved
- 24 Already committed to something+24
- Available
- 96 Free to promise−24
Step through the movements. Each one updates the same record.
StoresWhat did we start with?
The balance the record opened on. Everything after this is a movement somebody can point at, which is the difference between a stock record and a number in a sheet.
Opening balanceCarried forward
StoresWhat arrived?
Forty received against a purchase. On hand rises and so does available, because nothing has claimed the new stock yet. The receipt keeps its reference, so the number can be traced back to what caused it.
Goods receiptGRN-3312
OperationsWhat is now committed?
A production order claims twenty-four. Nothing physically moved — on hand is unchanged — but available drops, because those units are no longer free to promise to anybody else.
Reserved for productionMO-2048
StoresWhat actually left?
Sixteen of the reserved units are issued. On hand falls and the reservation falls with it — and available does not move at all, because those units were already spoken for. This is the row that shows the model is real.
Issued to productionMO-2048
StoresWhy does the count differ?
A count found two fewer than the record said. The correction is an event with a reason and an owner rather than a silent overwrite, so next month somebody can still see what happened and why.
Stock count varianceCNT-0914
Illustrative interface · sample dataavailable = on hand − reserved
Reservation. On hand 120, reserved 24, available 96.The record itself
The argument every stock system exists to settle.
Three numbers, one item. A business that tracks only the first one will keep promising stock it has already committed.
What is an inventory management system?
An inventory management system is the record of what stock a business holds and how that stock changes: what came in, what is committed, what is genuinely available, what was issued or consumed, what moved between locations and what was corrected after a count. Its job is to make stock answerable from one place rather than reconstructed from a sheet, a store register and somebody's memory — and to keep the movement behind every number so the number can be explained.
What is the difference between on-hand and available stock?
On hand is what the business physically holds. Available is what is left after subtracting stock already committed to orders, production or transfers — the industry calls it available-to-promise. The gap between them is where most stock problems live: a business quoting on-hand is quoting a number it cannot actually deliver against. Some setups also hold back safety stock or exclude blocked stock, which widens the gap further.
What is reserved stock?
Reserved stock is inventory that is still physically present but already claimed — by a customer order, a production order, a pending transfer or a job. Reserving does not move anything; it changes what the rest of the business is allowed to promise. When the reserved stock is finally issued, on hand and the reservation both fall together and available stays where it was, because those units stopped being available at the moment they were reserved.
- On handWhat is physically in the business right now, across the places it holds stock. It answers "do we have it", and on its own it answers nothing else.
- ReservedWhat is already claimed — by a production order, a customer order, a transfer or a job. It is still on the shelf and it is not yours to sell twice.
- AvailableOn hand minus reserved. The only number worth quoting to somebody who wants it, and the number most spreadsheets never contain.
When a business argues about stock, it is almost always because two people are quoting different numbers from this list and neither has said which one.
The model this page shows
On hand is what the business holds. Reserved is what is already committed to something. Available is what is left to promise. Real setups often also hold back safety stock, exclude blocked stock and count confirmed incoming supply — which is a scoping conversation, not a different idea.
available = on hand − reserved
Why the number is the number
A stock figure without its movements is a rumour.
Five movements on one item, each shown as what it changed. Read down the trace and the closing figure stops being a number somebody asserted.
- OpeningCarried forwardOpening balanceavailable80
- ReceiptGRN-3312+40on handavailable80120
- ReservationMO-2048+24reservedavailable12096
- IssueMO-2048−16on hand−16reservedavailable96Available did not changeOn hand falls and the reservation falls with it. Those units stopped being available at the moment they were reserved, not at the moment they left — so nothing new becomes free, and nothing that was promised quietly disappears.
- AdjustmentCNT-0914−2on handavailable9694
This is the difference between a system and a spreadsheet cell. The number is not asserted — it is the consequence of a list anybody can read, and a disagreement about stock becomes a question with an answer.
What does inventory management software track?
At minimum: the item and its identifiers, what is on hand, what is reserved, what is available, and every movement that changed those — receipts, issues, reservations and releases, transfers between locations, and adjustments after a count. Each movement carries a reference to what caused it and who recorded it, which is what makes the current figure explainable. Beyond that, batch, serial, expiry, unit-of-measure and valuation are real capabilities that belong in scope only when the stock genuinely needs that level of identity.
The question the system answers
Can we promise a hundred?
The one moment where the difference between on hand and available stops being a definition and starts costing money.
Request
A customer wants 100 by Friday, and the shelf looks like it can cover it.
- On hand
- 102 What is physically here — and the number that says yes
- Reserved
- 8 Already held by production order MO-2048
- Available
- 94 What this request can actually draw on
Review requiredThe shelf holds enough. The business does not have enough free, because eight are already committed to something else, so the request is short against available. A system showing only on hand would have said yes on Monday and found out on Friday. The honest answer is a review — reduce the quantity, release a stale reservation, or move the date — rather than a silent over-commit.
And the order holding the reserved units stays where it belongs
The production order that claimed them lives in Manufacturing ERP, which owns what is being made and where it stands. Inventory owns the stock that order draws on. The two meet at exactly this question and nowhere else — which is why neither has to absorb the other.
Manufacturing ERPEvery over-promise in a stock business is this decision made with the wrong number.
Across the business
One SKU, several places, one total that still makes sense.
Business locations, not shelves. A stock system should tell you where the stock sits in the business — a warehouse system tells the warehouse where it sits inside the building.
Can inventory software work across multiple locations?
Yes, and it is one of the commonest reasons a business outgrows a spreadsheet. A stock record can hold the same item at several business locations — a central store, branches, outlets, a service vehicle — with its own on-hand and reserved figures at each, a total that reconciles, and transfers recorded as movements so both ends stay truthful. What that is not is bin-level location inside a warehouse, which is a separate system with a different job.
- Central store62on hand8 reserved
- Store A24on handNone reserved
- Store B12on handNone reserved
- Service van4on handNone reserved
- Across the business102on hand8 reserved · 94 available
And a transfer is a movement, not a delivery
Central store12Store B
Twelve leave one location and arrive at another. Stock stays inside the business, the total does not change, and both locations tell the truth afterwards. Where the units physically travelled, and who carried them, is a different system's question.
The useful test: can somebody answer "where is our stock" without opening four files? That is a business-location question, and it is the last one Inventory owns before Warehouse begins.
When the shelf disagrees
A count that does not match is information, not an error to hide.
Stock records drift. What matters is whether the correction leaves a trace somebody can read next month.
- Record the countWhat was physically found, by whom, and when. Before anything is changed.
- Show the varianceThe difference against the record, so the size of the problem is visible rather than absorbed.
- Give it a reasonDamage, miscount, an unrecorded issue, a receipt entered twice. The reason is worth more than the correction.
- Adjust deliberatelyAn adjustment event, with an owner — not a quiet overwrite of the number.
This is an operational workflow, not an accounting or audit function. It records what your operation decides; it does not certify it, value it or approve it on anyone's behalf.
A business that adjusts stock silently loses the only evidence it had about why stock keeps going missing.
What needs somebody
The useful screen is not the one with the biggest numbers.
A stock list of two thousand items is not information. Four lines that need a decision today are.
- SKU-2093 · Pin retainerBelow thresholdAvailable 8, below a threshold of 10Decide whether to raise a purchase
- SKU-2110 · Bracket, smallCount differsCounted 88 against a record of 92Give the variance a reason and adjust
- SKU-2204 · Seal kitAwaiting confirmationTransfer of 20 sent, not confirmed receivedConfirm arrival at Store A
- SKU-2251 · Motor mountStale reservationReserved 40 against an order closed last weekRelease the reservation
- SKU-2260 · Washer packNothing to doAvailable 320, nothing outstandingNone
A threshold is a number your operation sets, and crossing it tells a person to look. It does not calculate an optimal order quantity, forecast demand or raise a purchase — those are decisions, and one of them belongs to a different system entirely.
Four of these five need somebody this week. Surfacing them is most of what a stock system is actually for.
Where this stops
Stock touches everything, which is exactly why it must not become everything.
Five neighbouring systems. Knowing which one you actually need is most of the decision.
Inventory management or a warehouse management system?
Inventory answers what stock exists and what state it is in; a warehouse management system answers where it physically sits and how it moves through a building. If your question is "how many do we have and how many are free", that is inventory. If it is "which bin, which picker, which packing lane, in what sequence", that is a WMS. Many businesses need only the first, run several locations perfectly well without bin-level control, and would be paying for complexity they never use.
Inventory management or a POS system?
A POS owns the retail transaction — the counter, the outlet, the customer, the bill. Inventory owns the stock behind it. They connect at one point: the sale asks what is available and then reduces it. Retailers usually need both eventually, but they are different purchases, and a stock system that grows a till tends to be a weak till attached to a stock system that no longer knows what it is.
Inventory management or manufacturing ERP?
Inventory owns what material exists and what is free to use. Manufacturing ERP owns what is being produced and where each production order stands. They meet when an order reserves and then consumes material — one asks, the other answers. A factory usually needs both, and building them as one system is how you get a production tool nobody trusts for stock and a stock tool nobody trusts for production.
Inventory management or procurement software?
Procurement owns everything up to the receipt — the supplier, the requirement, the quote, the approval and the purchase order. Inventory owns everything from the receipt onward. The handover is a single event: goods arrive against a purchase, and stock rises with a reference back to it. Keeping them apart means the buying process can change without disturbing the stock record, and the reverse.
- InventoryWhat stock exists and how its state changes — receipts, on hand, reserved, available, issues, adjustments and movement between business locations.
- WarehouseWhere stock physically sits inside a facility and how it moves through it — receiving, put-away, bins, picking, packing and dispatch.
- Point of saleThe retail transaction: the counter, the outlet, the customer and the sale itself. It asks inventory what is available; it owns what was sold.
- ProcurementEverything before the receipt — supplier, requirement, quote, approval and purchase order. Its receipt becomes an inventory event.
- Manufacturing ERPWhat is being produced and where the production order stands. It consumes stock; it does not hold it.Manufacturing ERP
- EcommerceThe online catalogue, cart and checkout. It asks whether a SKU is available and it owns the purchase journey.Ecommerce storefront
- DashboardsReporting that pulls across several systems when the question is bigger than stock.Dashboards
Warehouse, point of sale and procurement are systems Branditify builds, each with its own operating record. They are described here rather than linked because each is a separate build with its own scope — and a stock system quietly growing a picking workflow or a till is how both jobs end up done badly.
And the service that builds any of them
ERP & Operations is the Branditify engagement for designing and developing custom operational software. This page is one of the systems that engagement produces; if what you need is a different shape, it starts in the same place.
ERP & OperationsWhat connects, what moves
Two questions that decide the size of the project.
Both are answered by looking at what you already have, not by a compatibility list.
Can existing spreadsheet inventory be migrated?
The parts worth having, yes. Item masters, current stock and location lists map well because they are structured enough to carry across. Historical movements depend entirely on how consistently they were kept, and the useful step is to read a real sample and say what will survive rather than promising everything will. Some history is genuinely better kept as an archive than imported as data nobody can trust.
Can inventory connect to existing ecommerce, accounting or ERP systems?
Often, and the honest answer starts with an inspection rather than a compatibility badge. What matters is what your current systems can expose — an API, a scheduled export, a database view, or nothing usable — and that differs between two businesses running the same software. Where a connection is possible, stock reads what it needs and sends back what the other system needs. Where it is not, the same information is captured where it is confirmed. We check first, and never assume an integration exists because a vendor lists it.
Can barcode or QR workflows be included?
The system side, yes: a stock record can carry a barcode or QR value and a screen can be built to accept a scan wherever it saves time — receiving, counting, issuing. The hardware side is a separate question. Whether a particular scanner, label printer or handheld works the way you need is checked against that device and provider before it is scoped, because promising hardware compatibility in advance is how implementations stall.
Can batch, serial or expiry tracking be included?
Yes, when the stock genuinely needs that level of identity — and it is worth deciding early, because it changes the record rather than adding a field. Batches suit stock bought and consumed in lots; serial numbers suit items tracked individually; expiry suits anything with a shelf life. Where none of that is true, adding it makes daily work slower for no benefit. What this is not is a regulatory compliance system for any particular sector.
What it can connect to
Connections are scoped per project, and the first step never changes: find out what your current software, provider or device can actually expose. That answer differs between two businesses running the same tools.
- Where orders come fromAn online store, a marketplace, a sales team or a spreadsheet — whichever genuinely creates demand today. What matters is whether it can tell inventory that something was committed.
- Where purchases come fromA receipt has to raise stock and keep its reference. Whether that arrives from a purchasing system, an email or a person at the store depends on how you actually buy.
- The booksAccounting normally stays exactly where it is. What stock needs to send it is small and specific, and that is a far smaller piece of work than replacing it.
- Identifiers and devicesA record can hold a barcode or QR value where it is useful. Whether a particular scanner, printer or handheld works with it is a question about that hardware, checked before it is promised.
What can move across
Most businesses arrive with a spreadsheet that is more accurate than they admit and more inconsistent than they expect.
- SourceItem lists, opening stock, location lists, old exports — whatever the current tool will give up.
- SampleA real slice of it, read properly, before anything is promised about the rest.
- MapWhich column is the item, the quantity, the location, the unit — and which three columns are the same thing spelled differently.
- CleanDuplicate SKUs, quantities in mixed units, items nobody has stocked since 2023. This is the part that takes the time.
- ImportItem master and opening stock first, because that is what the system needs on day one.
- VerifyCounted against the shelf by somebody who knows the stock, not accepted because the import reported success.
- LiveA working record, with the history that was worth carrying.
Opening stock is worth getting right; five years of movement history usually is not. We say which is which after reading your data, not before.
What changes the size
What makes one inventory system larger than another.
Mostly how much identity the stock needs, and how many other systems have an opinion about it.
What determines the scope of an inventory management project?
Mainly how much identity your stock needs and how many systems have to agree about it. A plain SKU across one location with one team recording movements is a contained build. Batches or serials, several locations with transfers, reservation rules between competing claims, and connections to ordering, purchasing and accounts each add defined work. What rarely determines it is the length of a feature list — most businesses need a narrower system built properly around how they actually move stock.
Custom inventory software or off-the-shelf?
Off-the-shelf is the right answer more often than a software company usually admits. If your stock behaves the way standard products expect — plain items, simple reservations, ordinary locations — buying one is faster and cheaper, and that is the honest recommendation. Custom earns its cost when the stock model is genuinely unusual, when existing systems must be kept and connected, when reservation or approval rules are specific to how you trade, or when a standard tool would force you to change a process that works. The test is whether you would have to change how you operate to use the product, and whether that change would be an improvement.
Does every business need inventory software?
No. A business with a small number of items, one person who knows the stock and infrequent movement is often served perfectly well by a careful spreadsheet, and replacing it buys very little. A system starts earning its place when several people update stock, when items are committed before they are issued, when more than one location holds the same item, or when other systems need to ask what is available. The signal is not the size of the business — it is how often somebody has to check with somebody else before answering a stock question.
Who owns the system and data after a custom build?
You do — the system, the source code and the data in it. There is no licence to keep paying for the software itself, and nothing is held back that would prevent another team working on it later. Hosting, support and further development are separate arrangements you choose, not conditions of keeping what was built.
- How the stock is identifiedA plain SKU is straightforward. Batches, serials, expiry dates or multiple units of measure change the record itself, not just the form on top of it.
- How much connectsA self-contained system is a contained build. Reading orders, sending to accounts and taking receipts from a purchasing system are each a defined piece of work.
- Reservation rulesReserving on demand is simple. Priority between competing claims, partial allocation and automatic release need deciding before they are built.
- Number of locationsOne store is straightforward. Several, each with its own stock position and transfers between them, is a materially different system.
- Who updates stockOne person recording carefully is a different build from a floor team updating on a shared device between other jobs.
- Roles and permissionsWho can adjust stock is the question worth settling first, because an adjustment is the one action that can quietly hide a problem.
- Counting processAn occasional full count is simple. Rolling counts by location or category, with variance approval, is its own workflow.
- ValuationRecording quantity is one system. Costing stock and reporting its value is a different discipline, and often belongs with the books.
- What history movesOpening stock is quick. Carrying years of movement is its own project, and worth it only where the records are good.
What we need to start
What you stock and roughly how many items, where you hold it, how stock is recorded today and by whom, whether anything is reserved or committed before it is issued, what happens when a count disagrees with the record, which systems already exist that this must live alongside, and one recent example of stock going wrong. The last one is usually the most useful part of the conversation.
Background
Relevant capability work.
Branditify has not delivered this exact system. These are delivered projects shown for the capability they document — the records, states and interfaces behind them — each listed as what it actually was.
Questions
Asked before commissioning one.
- We manage stock in a spreadsheet. Is that actually a problem?
- Not automatically, and it is worth saying plainly. A spreadsheet works while one person owns it, movement is slow and nothing is committed before it is issued. It starts failing when several people edit it, when stock is promised in one place and consumed in another, or when a second location appears. The question is not whether spreadsheets are bad — it is how often somebody has to ask somebody else before they can answer.
- What should we digitise first?
- The item master and current stock, then movements. Getting an accurate opening position with clean item records is unglamorous and it is the foundation everything else stands on. Reservations, locations and connections are all easier once the base record is trustworthy, and starting there also gets the system used, which decides whether the rest survives.
- Can the system stop us selling stock we do not have?
- It can make the correct number visible at the moment somebody commits, which is what actually prevents it. Whether a commitment is blocked outright or flagged for review is a rule your operation chooses, and it is worth deciding deliberately — a hard block protects the stock and a soft warning protects the sale, and different businesses genuinely want different answers.
- Can the team update stock away from a desk?
- Usually, and it is worth deciding early rather than retrofitting. A screen meant for a phone or tablet in a store is designed differently from one meant for a desk — larger targets, fewer fields, one job at a time — so which actions genuinely need to work on the floor is a scoping question rather than a setting. Whether a particular handheld behaves the way you expect is checked against it beforehand.
- We buy in boxes and issue in pieces. Is that a problem?
- No, but it is worth settling at the start, because it reaches into the record rather than sitting on top of it. A purchase unit and an issue unit with a fixed relationship between them is ordinary. What needs a decision is which unit the stock figure itself is held in, because reservations, counts and transfers all have to agree with that choice. Where the relationship is not fixed — weights that vary from lot to lot — that is a larger piece of work, and you would hear so before it was scoped.
- Does it do stock valuation or accounting?
- Quantity is inventory's job; value is usually the accounting system's. Costing and valuation can be scoped where they genuinely belong in the operational system, but they are a separate discipline and normally stay with the books rather than being rebuilt beside them.
- Can it reorder automatically?
- It can hold a threshold your operation sets and tell a person when stock crosses it. Deciding what to buy and raising the purchase are decisions — and the purchase side belongs to a procurement process rather than to the stock record. We do not build demand forecasting or automatic purchasing into a first version.
- Who can change stock?
- Decided per role and built in from the start. Recording a receipt, making a reservation and adjusting after a count are three different levels of trust, and the adjustment is the one worth restricting — it is the only action that can quietly make a problem disappear.
- Can we start with one location and expand?
- Usually the better way. One location gives the record a real test with a small blast radius, and what you learn there tends to change the second phase more than planning would have.
- How long before the team is actually using it?
- That follows from how much identity the stock needs and how much connects, so it is scoped after seeing your data rather than quoted before. The part worth protecting in any plan is a first version narrow enough to be used properly — a stock system people work around is worse than the spreadsheet it replaced.
- What happens to our old stock history?
- We read a real sample before deciding. Opening stock and item records normally carry across well; older movement history depends on how consistently it was kept, and some of it is more useful as an archive than as data in a live system. You are told which is which before the work starts.
- What happens after it goes live?
- The first counts change the system — that is expected rather than a failure of the build, because the shelf always has opinions the spreadsheet did not. Support and further development are arranged separately and are your choice, and you own the system and the code either way.
Start here
Tell us what you stock, and the last time the number was wrong.
The second half of that is usually where the real system requirement is hiding.
- What you stock, and roughly how many items
- Where you hold it, and how many places that is
- How stock is recorded today, and by whom
- Whether anything is committed before it is issued
- What happens when a count disagrees with the record
- Which systems already exist that this has to live with
- One recent time stock went wrong, and why