← Back to Blog
Inventory accuracy across channels: one source of truth
Ecommerce & Order-to-Cash

Inventory accuracy across channels: one source of truth

byBruno Galo · Published on 22 Feb 2026

Last updated 12 Aug 2026

Available inCatalàEnglishEspañolPortuguês

A company selling through a storefront, two marketplaces and a sales team has four systems that each believe they know how many units are available. None of them is wrong at the moment it is asked. All of them are wrong a few seconds later.

The instinct is to fix this with faster synchronisation — push stock levels to every channel more often, reduce the interval, approach real time. This helps at low volume and fails at exactly the moment it matters, because the problem is not latency. Two channels can sell the last unit within the same second, and no synchronisation frequency prevents that. What prevents it is deciding, in one place, who is allowed to promise a unit.

Most mid-market overselling incidents we investigate trace to an architecture where availability is published to channels but never reserved by them. The channels are being told what exists rather than being allocated what they may sell.

Why this matters

Overselling has an asymmetric cost. A stockout that prevents a sale costs the margin on that sale. An oversell that takes a customer's money and then cannot fulfil costs the margin, the refund handling, the customer's trust and — on marketplaces — a performance metric that affects your ranking and, if it deteriorates far enough, your ability to sell there at all. The two errors are not comparable, which is why availability logic should be deliberately conservative rather than optimised for maximum exposure.

Understating availability has its own compounding cost, and it is the one companies tolerate silently. A buffer held on every channel to prevent overselling is stock that cannot be sold anywhere. Applied across a large catalogue it represents a material amount of working capital producing nothing, and because it never appears as a failure, nobody reviews it.

Then there is the accounting dimension. Inventory that the systems disagree about is inventory whose valuation is uncertain, which surfaces at year end when the auditor asks why the perpetual records and the physical count differ. Channel inventory accuracy is a financial control, not only an operational convenience.

At a glance: the four states stock can be in

State Meaning Who may change it Common failure
On hand Physically present and counted Warehouse only Treated as available and published to channels
Reserved Committed to a specific order or channel allocation The reservation engine, on request Not modelled at all — the root cause of most overselling
Available to promise On hand minus reserved, minus buffer Derived only, never edited Calculated differently by each channel
Incoming On a purchase order with an expected date Procurement Published as available before it exists

The second row is the one most mid-market estates omit. Without a reservation state, "available" is a number computed from history rather than a promise anyone is holding, and every channel is free to sell the same unit.

What works, and what to be honest about

What works:

One system owns availability, and it is the ERP. Not the storefront, not the marketplace connector, not a spreadsheet the merchandiser maintains. Availability is derived in one place from on hand, reserved and buffer, and every channel consumes that derivation rather than computing its own.

Reservation at the point of commitment, not at the point of fulfilment. When a channel takes an order, it requests a reservation and receives a yes or no. This is the mechanism that makes concurrent selling safe, and it is the difference between publishing information and allocating stock.

A near-real-time push with a reservation backstop. Update channels frequently enough that displayed availability is broadly right, and rely on reservation to prevent the edge case. This is more robust than pursuing true real-time and considerably cheaper to operate.

Buffers that are deliberate, differentiated and reviewed. A buffer on a fast-moving item with weekly replenishment is a different decision from one on a slow-moving item with a twelve-week lead time. Applying a single percentage across the catalogue is the most common way companies quietly immobilise working capital.

Cycle counting rather than annual counts. Continuous counting weighted by value and movement keeps the on-hand figure trustworthy without shutting the warehouse. An agent flagging variances that exceed thresholds — and detecting patterns suggesting a systematic issue rather than a one-off miscount — makes this sustainable at mid-market headcount.

What to be honest about:

Marketplaces will not always respect your model. Some hold their own availability, apply their own logic, or impose latency you do not control. You are managing exposure rather than eliminating it, and the practical mitigation is a larger buffer on those channels specifically — accepting a working capital cost in exchange for protecting a performance metric.

Physical accuracy is the floor, and no architecture raises it. If on hand is wrong because of picking errors, unrecorded damage or receipts posted late, every derived number is wrong. Companies frequently attempt to solve an availability problem that is actually a warehouse discipline problem.

Multi-location makes this materially harder. Once stock sits in several locations, availability depends on which location can serve which channel within the promised delivery window. That is an allocation policy, not a data structure, and it needs deciding explicitly.

Kits, bundles and assemblies break naive logic. A bundle's availability is a function of its components, and components are usually also sold individually. This needs modelling deliberately or the bundle will oversell its scarcest part.

Some overselling is commercially acceptable. On a fast-replenishing item where a one-day delay is tolerable, a small oversell rate may be cheaper than the buffer required to eliminate it. That should be a priced decision, not an accident.

Decision framework: designing availability

Run in order. Stop at the first match.

1. Is your physical on-hand figure trustworthy?
If not, start with the warehouse: receipt and pick confirmation discipline, cycle counting, variance investigation. No availability design survives an unreliable on-hand number.

2. Do you model a reservation state at all?
If not, this is the fix. Reservation at commitment, released on cancellation or expiry, visible in the availability calculation. It is the single change that addresses most overselling.

3. Does one system own the availability calculation?
If channels compute their own, consolidate. One derivation, consumed by all channels, with no channel permitted to edit it.

4. Are your buffers deliberate and differentiated?
If a single blanket percentage is applied, review it by item velocity, lead time and channel risk. This typically releases working capital immediately and is one of the few interventions here with a direct balance sheet effect.

5. Do you sell bundles, kits or assemblies?
Model component-derived availability explicitly before extending anything else, or the rest of the design will be undermined by the products most likely to disappoint a customer.

6. Do you hold stock in more than one location serving the same channel?
Define allocation policy — which location serves which channel under which conditions — before optimising anything else. Ambiguity here produces both oversells and unnecessary buffers simultaneously.

7. All of the above and still overselling?
The residue is almost certainly marketplace latency you do not control. Manage it with channel-specific buffers and monitor the exposure rather than expecting to design it away.

Indicative cost and effort

Workstream Typical elapsed time Effort profile
Warehouse accuracy and cycle counting programme 6–14 weeks Medium — operational discipline
Reservation model design and implementation 5–10 weeks Medium — core change
Consolidating availability calculation to the ERP 4–8 weeks Medium
Buffer policy review and differentiation 2–4 weeks Light, direct working capital return
Bundle and kit availability modelling 3–6 weeks Medium
Multi-location allocation policy and configuration 4–8 weeks Medium
Channel publication and monitoring 3–6 weeks Medium
Variance detection agent 3–6 weeks Medium

Assumes one ERP instance and up to four sales channels. Additional locations, third-party logistics or heavy bundling extend these. Get a quote for a scoped estimate.

Frequently asked questions

Should availability be pushed to channels or pulled by them?
Push for display, so the customer sees something broadly accurate without a latency penalty on every page view. Pull — a live reservation request — at the point of commitment, where correctness matters. Mixing them this way is more robust than either alone.

How large should a buffer be?
Derive it from replenishment lead time, demand variability and the cost of a stockout versus an oversell for that item and channel. A blanket figure across the catalogue is always wrong in both directions simultaneously: too large on fast movers, too small on volatile ones.

Do we need a dedicated order management system?
Usually not at mid-market scale if the ERP can hold reservations and derive availability. A separate order management layer earns its cost with many channels, multiple fulfilment locations and complex allocation rules — but it also becomes another system with its own view of stock, which is the problem you started with.

How do we handle pre-orders and incoming stock?
As a separate promise type with its own date, never folded into available to promise. Selling incoming stock is a legitimate commercial decision; publishing it as though it were on hand is how delivery commitments get broken.

What is a realistic accuracy target?
Measure two things separately — physical accuracy against cycle counts, and oversell rate by channel — and set targets from your own baseline. A single "inventory accuracy" figure conflates a warehouse discipline problem with an availability architecture problem, and they have different owners and different fixes.

Closing — Next steps

Channel inventory problems present as synchronisation failures and are almost always reservation failures. The question worth asking is not how often stock levels are published, but whether anything in the estate holds a promise when a customer commits — and if so, which system, and whether every channel respects it.

A diagnostic that takes an afternoon: for one week, log every oversell and every cancelled-for-stock order, with the channel and the item. Then check what buffer that item carries. The pattern will tell you whether you have a reservation problem, a physical accuracy problem, or a buffer policy that is costing you more than the oversells it prevents.

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.

Comments

No comments yet.

Leave a comment

Your comment will be reviewed before publishing.

An unhandled error has occurred. Reload 🗙