AI agent for inventory exceptions and stock discrepancies

Inventory discrepancies are discovered in one of three places, and the cost differs by an order of magnitude between them. Found by a cycle count, a discrepancy is a variance to investigate. Found by a picker with an order in hand, it is a scramble — a substitution, a partial shipment, a delivery date to renegotiate. Found by the customer, it is a refund, a complaint, and on a marketplace, a performance metric that affects your ranking.

Most mid-market companies discover a large share of their discrepancies in the second and third places, because the first requires counting activity nobody has capacity for. Annual counts find everything at once, twelve months late. Cycle counting finds things promptly but only where you happened to count.

An agent changes which of the three places you find things in. Not by counting — it cannot count — but by noticing that the recorded data is internally inconsistent, that movement patterns imply a problem, and that a particular item is behaving in a way that historically precedes a discrepancy. It directs the counting capacity you have at the places most likely to be wrong.

Availability architecture — reservation, buffers, multi-location allocation — is covered separately in Inventory Accuracy Across Channels. This article assumes those decisions are made and addresses detection.

Why this matters

The direct cost of a stock discrepancy is rarely the value of the missing units. It is the disruption: the expedited replacement, the split shipment, the customer service time, the credit note, and on a marketplace, the metric.

The indirect cost is the buffer. A company that does not trust its stock records protects itself by holding availability back on every channel. That buffer is working capital producing nothing, and it is sized by the level of distrust rather than by any calculation. Improving detection so that records can be trusted allows the buffer to shrink, and that is usually the largest single financial benefit — larger than the shrinkage prevented.

There is a valuation dimension too. Discrepancies discovered at year end become a write-off in one period that in reality accumulated over twelve, which distorts every month in between and produces an audit conversation about the reliability of the perpetual records.

At a glance: what an agent can detect without counting anything

The pattern rows are where an agent earns its place. A single variance is noise; the same variance recurring on one item, one location or one shift is information, and detecting that requires comparing across time in a way nobody does manually.

Two rows need care. Operator-level patterns have employment implications and must route confidentially to one named person, never into a general queue. And the unit-of-measure row is worth internalising: a substantial share of what presents as physical shrinkage in mid-market warehouses is a pack quantity or conversion error in the item master, and treating it as a counting problem means investigating the warehouse for a data fault.

What works, and what to be honest about

What works:

Detecting internal inconsistency continuously. Negative availability, movements without documents, receipts without orders — these are unambiguous errors visible in the data alone. Finding them the same day is entirely achievable and prevents the downstream scramble.

Directing cycle counts by risk rather than by rotation. Counting capacity is fixed. Pointing it at items the agent has flagged, weighted by value and movement, finds materially more variance per count than a fixed rotation.

Separating data faults from physical faults before dispatching anyone. An item with repeated small variances usually has a master data problem. Sending someone to count it will confirm the variance without explaining it. Classifying first saves the trip and fixes the cause.

Pre-dispatch validation. Checking that a picked quantity reconciles to the order and the recorded stock before the shipment leaves converts a customer-facing failure into an internal one. This is the highest-value check in the set.

Trend reporting on variance by cause. The point of detection is reduction. Categorised variance trends tell you whether the underlying causes are being fixed or whether you are simply finding them faster.

What to be honest about:

The agent cannot tell you what is physically there. It infers that something is probably wrong. Confirmation requires a person and a count, and companies expecting detection to remove counting will be disappointed. It makes counting effective, not unnecessary.

Physical process discipline sets the ceiling. If receipts are posted in batches at the end of a shift, if damage goes unrecorded, if picks are confirmed after the fact, the data is wrong in ways no analysis recovers. This is warehouse management, and it is the prerequisite.

Alert fatigue arrives quickly. An agent flagging every minor variance produces a queue that gets ignored, at which point the genuine signal is lost with the rest. Thresholds should start conservative and be tuned by whether flags turned out to be real.

Some variance is not worth investigating. Below a value threshold, the investigation costs more than the discrepancy. Set the threshold deliberately and review the aggregate below it periodically to catch a pattern rather than each instance.

Operator-level findings need handling before they exist. Decide the route and the policy before the agent is capable of producing such a finding, not after the first one appears.

Decision framework: where to start

Run in order. Stop at the first match.

1. Is your physical posting discipline reliable — receipts, picks and damage recorded as they happen?
If not, fix this first. Detection built on data recorded hours or days after the event will produce flags that cannot be interpreted.

2. Are you detecting unambiguous data errors today — negative availability, undocumented movements?
If not, start here. These require no thresholds, no tuning and no judgement, and they are usually present in volume on first run.

3. Do you validate picked quantities against the order and record before dispatch?
If not, implement this next. It is the single check that most reliably prevents a discrepancy reaching a customer.

4. Is cycle counting scheduled by rotation rather than by risk?
Redirect it using agent flags weighted by value and movement. Same capacity, considerably more variance found.

5. Are you distinguishing data faults from physical faults before dispatching a count?
If not, add the classification. Repeated small variances on one item are usually a master data error, and treating them physically never resolves them.

6. Do you have a value threshold below which variances are accepted, and a route for operator-level patterns?
Define both explicitly before go-live.

7. All of the above in place and discrepancies still reaching customers?
The remaining cause is likely the availability architecture rather than detection — reservation, buffers or multi-location allocation. That is a design problem, not a detection one.

Indicative cost and effort

Assumes one ERP instance and one or two warehouse locations. Third-party logistics, where you do not control posting discipline, changes this materially. Get a quote for a scoped estimate.

Frequently asked questions

Can this replace cycle counting?
No. It makes cycle counting more productive by directing it, and it catches data errors counting would never find. Companies that reduce counting capacity on the strength of a detection agent lose the confirmation step the whole approach depends on.

How do we avoid alert fatigue?
Conservative thresholds, a value floor, and tracking flag precision — the proportion of flags that turned out to be real. If precision falls, tighten rather than adding reviewers. A queue people trust is worth more than a queue that is comprehensive.

What if we use a third-party logistics provider?
Detection is still useful and the remedies are contractual rather than operational. You will be detecting discrepancies in someone else's operation, which makes agreed variance reporting and reconciliation part of the contract rather than something you fix yourself.

How much of what looks like shrinkage is actually a data problem?
In our experience a meaningful proportion — unit of measure errors, pack quantity mismatches, bundle definitions. This is why classification before investigation matters: the two causes look identical in a variance report and have entirely different fixes.

What is the realistic benefit?
Fewer customer-facing failures, more variance found per count, and — usually the largest item — a reduction in the availability buffer once records are trustworthy enough to justify it. The last of those is a working capital effect and is worth modelling explicitly in the business case.

How quickly can the inventory data feeds be connected in real time?
Quicker than the exception logic above, typically — a certified partner like Stacksync can have real-time inventory sync across systems running within weeks. Deciding which discrepancies are worth an alert, and which are noise, is the part that takes iteration.

Closing — Next steps

Inventory exception detection is not about finding shrinkage faster. It is about moving the point of discovery upstream of the customer, and about telling the difference between a warehouse that has lost something and an item master that was never right.

A first step requiring no build: run a query for negative available quantities and for movements without supporting documents. Both are unambiguous errors, both are usually present, and the count you get back is a reasonable proxy for how much your records can currently be trusted.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• Oracle NetSuite, inventory management, count and adjustment documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• ASCM / APICS, inventory record accuracy and cycle counting guidance — https://www.ascm.org
• IFRS Foundation, IAS 2 Inventories — measurement and write-down — https://www.ifrs.org
• APQC, Open Standards Benchmarking — supply chain measures — https://www.apqc.org
• Atypical Tech engagement experience, mid-market inventory and warehouse implementations across Iberia
• Stacksync, real-time integration and sync platform blog — https://www.stacksync.com/blog