Inventory as source of truth: why AI must never guess stock

Some numbers in a business can be approximately right and still useful. Website traffic, estimated reach, a rough forecast of next month's sales — nobody is harmed if they are a little off.

Inventory is not one of those numbers. If a store believes it has twelve units and actually has zero, it will sell items it cannot ship. If it believes it has zero and actually has forty, it will hide products customers want and perhaps reorder stock it does not need. Every error turns into a concrete cost: a cancelled order, an apology email, a refund, a wasted purchase, a customer who does not come back.

That is why we treat inventory as a source of truth — one authoritative record, kept accurate by disciplined syncing and regular reconciliation — and why MerchNivo, our AI e-commerce employee for Shopify stores, is built so that its AI never guesses stock. This article explains both halves: how to keep inventory true, and how AI should behave around it.

Why inventory is special

Most e-commerce data describes the past. Orders happened. Refunds happened. Sessions happened. Inventory is different: it is a claim about the present, used to make promises about the future. When a product page says "in stock", the store is promising it can ship.

Inventory is also unusually easy to get wrong, because many things change it:

• sales on every channel the store uses;
• returns and restocks;
• damaged, lost or quarantined units;
• transfers between locations;
• incoming purchase orders arriving early, late, short or over;
• manual corrections after a count;
• bundles and kits that consume several components;
• integrations with warehouses, marketplaces and point-of-sale systems, each with its own timing.

Each of these is a chance for the count to drift. And unlike most data problems, stock drift is invisible until it causes a failure.

One system of record

The first principle is simple to state and surprisingly often ignored: for each item at each location, exactly one system holds the authoritative count.

For many small and mid-sized stores, that system is the store platform itself — Shopify's inventory at each location. For others, it is a warehouse management system or an inventory tool, with the store platform receiving counts from it. Either arrangement can work. What does not work is two systems that each believe they are in charge.

Once the system of record is chosen, every other system has a defined relationship with it:

Writing this table down, per store, is one of the most useful half-hours an operator can spend. It belongs in the store's source-of-truth document, next to the other rules that should not drift.

On hand, committed, available, incoming

Stock is not one number. At minimum, a useful model separates:

• On hand — units physically at a location.
• Committed — units allocated to orders not yet fulfilled.
• Available — units that can still be sold (on hand minus committed, minus anything reserved or unsellable).
• Incoming — units on a recorded purchase order or transfer, with an expected date.

Confusing these is a common source of error. A report that shows on-hand units as sellable will overstate stock during busy periods, when many units are already committed to orders waiting to ship. MerchNivo works with the platform's distinctions rather than inventing its own, and labels which figure it is using.

Sync keeps systems close

When more than one system touches inventory, they need to stay in step. Sync is the ongoing process of sending changes from one to another.

Good sync has a few properties:

• Direction is defined. Each field flows one way, from the system of record outward, or from a defined source inward. Two-way sync of the same field between two systems is where overwrites and loops come from.
• Changes are events, not snapshots. Sending "sold 2 units" is safer than sending "stock is now 10", because the second can overwrite a change that happened in between.
• Failures are visible. A sync that silently fails is worse than no sync, because everyone believes the numbers are current.
• Timing is known. If a channel updates every fifteen minutes, everyone should know that a fast-selling item can oversell within that window, and set buffers accordingly.
• Updates are idempotent. The same change delivered twice should not decrement stock twice.

Even with all of that, sync is not enough on its own. Messages get lost, integrations get misconfigured, someone edits a count directly in the wrong system, a bundle mapping breaks. Sync keeps systems close. It does not prove they agree.

Reconciliation proves they agree

Reconciliation is the deliberate, regular comparison of inventory records to find differences that sync missed. It happens at two levels.

System-to-system reconciliation compares counts between the system of record and each connected system. If the store platform says 18 and the marketplace listing says 25, something has drifted. Ideally this runs automatically and reports differences above a small tolerance.

Record-to-physical reconciliation compares the system of record with what is actually on the shelf. That means counting: full stocktakes periodically, and cycle counts — a rotating subset of items — more often. Fast-moving and high-value items deserve more frequent counts.

When a difference is found, the resolution should be recorded: what the difference was, what caused it if known, and what adjustment was made. Over time, those records show patterns. A particular location that always runs short, a bundle that always drifts, an integration that loses updates at weekends. Patterns point to fixes.

Why AI must never guess stock

This is where AI enters, and where our position is firm.

A language model is designed to produce plausible text. Ask it how many units of a product are left and, if it does not have the number, it may produce one anyway — in the same confident tone it uses for everything else. It might extrapolate from yesterday's figure, average across variants, or simply fill the gap. The result reads like a fact.

In most domains, that is an inconvenience. In inventory, it is an operational failure. A briefing that says "you have plenty of stock of the black cable" when the store has none will lead the owner to keep advertising a product that cannot ship.

So the rule across Oryvelon — AI explains, verified data decides — applies with extra force here:

1. Stock figures are retrieved by code from the system of record, through the platform's official access, at a known time.
2. Calculations are done by code: available units, stock cover, days until stock-out, variance from the last check.
3. The model receives those facts and explains them. It does not receive a request to "estimate" anything.
4. Output is validated: every stock figure in the briefing must match a figure in the input. See structured outputs and schema validation.
5. Missing data is stated, not filled. If a figure is unavailable, the briefing says so.

What MerchNivo says when data is unclear

The most important behaviour is what happens when inventory data looks wrong. MerchNivo checks for signs that stock data cannot be trusted and reports them as their own signal, rather than silently working with a bad number:

• Negative available stock, which usually means orders were accepted beyond the count.
• Counts that have not changed in an unusually long time on items that are selling.
• Disagreement between locations and the total, or between channels.
• Sales recorded against variants with no inventory tracking.
• Recent large manual adjustments without an obvious reason.

A briefing in that situation reads something like:

Inventory data needs checking: Wireless Charger Pad, white. The store shows –3 available units, which suggests orders were accepted beyond recorded stock. Stock cover cannot be calculated reliably until the count is corrected. Suggested: confirm the physical count and update inventory.

That is less satisfying than a neat stock-cover number. It is also correct, and it points the owner at the real problem.

Worked example: overselling during a promotion

Imagine a store running a weekend promotion on a popular variant. The store platform is the system of record. A marketplace channel receives stock updates on a fixed interval.

On Saturday, the variant sells quickly on both channels. Between updates, the marketplace keeps selling units the store has already sold through its own checkout. By Saturday evening, available stock on the platform shows –4.

What should happen:

1. Monday's briefing (or an alert sooner, if configured) flags negative available stock on that variant as a data problem, lists the orders affected and suggests confirming the physical count.
2. The owner checks the shelf, finds that a few units were in a returns bin and not counted, adjusts stock and decides how to handle the remaining oversold orders.
3. The weekly review notes the cause: sync interval too long for a promoted fast mover.
4. The fix is operational, not AI: a stock buffer on the marketplace for promoted items, or a shorter sync interval during campaigns.

At no point did the AI estimate how many units were "probably" on the shelf. It pointed at the discrepancy, with evidence, and a person resolved it.

Forecasts are not stock

There is one place where estimation is legitimate: looking ahead. How many days will current stock last? When should a reorder be placed? These are forecasts, and forecasts are useful. The rule is that a forecast must be built on true stock and must be labelled as a forecast.

MerchNivo keeps the two clearly separate. The figure "14 units available" comes from the system of record and is presented as a fact, with the time it was read. The figure "about three days of cover at the last seven days' pace" is a calculation, done in code, with its method stated in the same sentence. The owner can see which part is observed and which part is projected, and can disagree with the projection — a promotion starting tomorrow will change the pace — without doubting the count.

What the AI model contributes is the explanation around those numbers: why a variant's pace has changed, which items share a supplier with a long lead time, which reorder decisions are most urgent. It does not adjust the forecast by intuition, and it never turns a projection back into a stock figure.

Multi-location stores

Stores that hold stock in more than one place — a home office, a warehouse, a fulfilment partner, a retail counter — multiply every problem above. The total can look healthy while the location that serves most orders is empty.

A few practices help. Report availability per location as well as in total. Make fulfilment rules explicit, so it is clear which location ships which orders. Treat transfers as stock in transit, visible but not available, until they are received. And reconcile each location on its own schedule, since the causes of drift are usually local. MerchNivo shows per-location figures when a stock signal depends on them, so an owner is not reassured by a total that hides an empty shelf.

Buffers and safety stock

Because sync is never instant and counts are never perfect, many stores hold back a small buffer on some channels — publishing slightly less than the true available stock — so that timing gaps do not cause overselling. Separately, safety stock is the level at which a reorder should happen early enough to cover supplier lead time plus uncertainty.

Both are business decisions, and both belong to the owner. MerchNivo can show the data behind them — how often a variant has oversold, how long reorders take to arrive, how variable daily sales are — and can suggest reviewing a buffer. It does not set them.

Bundles, kits and variants

Bundles deserve their own warning, because they are a frequent source of inventory errors. A bundle that sells as one product might consume three components. If the bundle has its own stock count that is not linked to its components, both can drift: the bundle keeps selling while a component runs out, or the component shows stock that is really committed to bundles.

The principle is the same as everywhere else: one source of truth. Either the components are authoritative and the bundle's availability is calculated from them, or the bundle is stocked as its own physical item. Mixing the two is where problems start. MerchNivo flags bundles whose orders are stalling in fulfilment, which is often the first visible symptom — see our guide to Shopify operations signals.

How we learn from a real store

Inventory problems look different on paper than on a Saturday afternoon. Oryvelon operates Noveniq, a direct-to-consumer technology accessories store, and its operations are a steady source of realistic inventory questions: how often cycle counts are actually done, which discrepancies are most common, how operators react to a data-quality warning compared with a neat number.

That learning shapes MerchNivo's defaults. Noveniq's customer data does not. The boundary is described in running a real store as a testbed, and development uses synthetic stock scenarios rather than copies of real records, as covered in environments and test data.

A checklist for inventory truth

For any store, whether or not it uses AI tools:

1. Name the system of record for stock at each location, and write it down.
2. Map every system that reads or writes inventory, with the direction of each flow.
3. Separate on hand, committed, available and incoming in reports and decisions.
4. Check sync failures, not just sync settings.
5. Reconcile systems automatically and report differences above a tolerance.
6. Cycle count fast movers and high-value items more often than the rest.
7. Record every adjustment with a reason.
8. Set channel buffers for fast-selling items where sync has a delay.
9. Link bundles to components, or stock them as their own items — not both.
10. Make sure any AI tool reads stock from the system of record and says clearly when it cannot.

Common mistakes

• Two systems in charge. Each overwrites the other; nobody knows which is right.
• Snapshot sync. "Stock is now X" overwrites changes made in between.
• Silent sync failures. Numbers look current and are not.
• Treating on hand as available during busy periods.
• Counting stock that has not arrived. An expected delivery is not inventory until it is received.
• Unlinked bundles. A reliable source of overselling.
• AI that estimates. A plausible wrong number is worse than an honest "unknown".
• Fixing symptoms, not causes. Adjusting a count without recording why guarantees it will drift again.

Summary

Inventory is a claim about the present that becomes a promise to customers, so errors cost money immediately. Treating inventory as a source of truth means naming one authoritative system for each item and location, defining how every other system reads from or reports to it, separating on hand, committed, available and incoming stock, and pairing sync with regular reconciliation so drift is found and explained. AI has a clear place in this: it explains counts that code has retrieved and checked, flags data that looks unreliable and suggests actions a person approves. It never estimates stock. When MerchNivo cannot trust an inventory figure, it says so plainly, because an honest warning protects a store far better than a confident guess.

Questions and answers

What does inventory as source of truth mean?

It means one system holds the authoritative stock count for each item and location. Other systems, including sales channels and AI tools, read from it or are reconciled against it rather than keeping their own version.

Why shouldn't AI estimate inventory?

Because a language model can produce a plausible stock figure that is wrong, and stock errors lead directly to overselling, missed reorders and customer disappointment. Stock must be retrieved from the system of record.

What is inventory reconciliation?

Inventory reconciliation is the regular comparison of stock records across systems, or between records and a physical count, to find and resolve differences that everyday syncing has missed.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Commerce & SaaS

NextRunning a DTC brand as a real operating business →