Omnichannel Without the Chaos: One Inventory for Your Online Store, POS and Courier Deliveries

Selling in more than one place is no longer optional. A typical growing retailer today takes orders on its website, at one or more shop counters, over the phone, through chat apps and social media, and sometimes through a mobile app. Customers expect to buy online and pick up in store, return in store what they bought online, and see accurate stock everywhere.

Behind the counter, the reality is often very different. Each channel was added with its own tool, and each tool keeps its own stock number. The website sells a jacket the outlet sold an hour ago. The courier has the parcel, but the system still says "processing". Cash on delivery comes back as one settlement file that takes an afternoon to match.

This article explains how to run every channel on one inventory: the architecture behind it, the delivery loop that closes the cash gap, a setup checklist and the metrics that tell you it is working.

Why multichannel turns into chaos

The root cause is almost always the same: stock is stored per tool instead of per location. When the website, the POS and the warehouse sheet each own a number, they can only agree through syncs and exports. Syncs run every few minutes at best, fail silently at worst, and never handle the edge cases: a return, a transfer, a partial delivery.

The symptoms are familiar:

• Overselling during busy periods, followed by apologetic cancellations.
• Hidden stock: products available in an outlet but shown as sold out online.
• Manual courier work: copying addresses into a courier portal, then copying tracking numbers back.
• Unreconciled COD: cash collected by couriers that nobody has matched to orders.
• Returns that never come back into sellable stock, or come back to the wrong location.

The architecture: one ledger, many doors

The fix is to separate two ideas that most tools mix up: channels (where you sell) and locations (where stock physically is). Channels do not own stock. They sell from locations. Every location's stock lives in one ledger.

A ledger of movements, not a counter

A reliable inventory does not store "quantity = 48" and overwrite it. It records every movement as a row: received, reserved, sold, transferred out, transferred in, returned, adjusted, written off. The current quantity is the sum of those rows. This has three big advantages:

• It explains itself. Any number can be traced back to the movements that produced it.
• It handles concurrency. Two channels selling the last unit at the same moment are resolved by the database, not by luck.
• It feeds accounting. Each movement carries a cost, so cost of goods sold and stock valuation come straight from the same data.

On hand, reserved, available

Three numbers per SKU per location do most of the work:

Number	Meaning	Who changes it
On hand	Physically present at the location.	Receipts, sales, transfers, returns, counts
Reserved	Promised to an order that has not shipped yet.	Checkout, cancellations, dispatch
Available	On hand minus reserved. What any channel may sell.	Calculated, never typed

The website and the POS both read available. When an online order is placed, the quantity is reserved at the location that will ship it, so the counter cannot sell it. When the parcel leaves, the reservation becomes a sale. If the order is cancelled, the reservation is released.

Low-stock alerts per SKU

One store-wide threshold ("alert me below 5") does not fit a catalogue where some items sell 50 a day and others 2 a month. Set a threshold per SKU where it matters, let the rest inherit the store default, and make sure alerts fire on every movement that reduces stock — online orders, POS sales, adjustments — not just on one channel.

See it working

This short tour shows warehouses, outlets, stock movements and low-stock alerts in one inventory.

The POS counter: same stock, same customer

A point of sale that runs on the same platform as the online store changes daily operations in small but important ways:

• Each register belongs to an outlet, so every counter sale reduces that outlet's stock immediately.
• Customers are shared. A shopper who buys online and in store has one history, one loyalty balance and one set of coupons.
• Prices and tax come from one engine. Promotions configured once apply online and at the counter.
• Sessions close with a cash count. The expected cash, the counted cash and the difference post to the ledger.
• Some items can be counter-only. Spare parts or bulk goods can be stocked and sold in store without appearing in the online catalogue.

The delivery loop: from "order placed" to "cash in the bank"

For many retailers, especially where cash on delivery is common, the biggest leak is not stock — it is the gap between a parcel leaving and the money arriving. Closing that loop means automating each step.

1. Quote at checkout. The delivery fee comes from rules: zone, weight, method and any free-delivery promotion. Risky buyers (for example, many past returns) can be flagged before you ship.
2. Reserve stock at the location that will ship.
3. Confirm and pack. Confirming the order creates the delivery record automatically — no separate step.
4. Book the courier through its API. The parcel is created at the courier, the tracking number is stored on the order, and the label is printed.
5. Follow status callbacks. When the courier reports in transit, delivered, partly delivered or returned, the order follows without anyone checking a portal.
6. Reconcile COD. The cash the courier collected is matched to each order and posted to the ledger: debit bank, credit courier receivable.

Handle the three outcomes properly

• Delivered: the sale is recognised, loyalty points are earned and a review invitation is scheduled.
• Partly delivered: the parcel knows which lines it carried, so only what arrived counts as sold. The rest is returned to stock or re-shipped.
• Returned: stock goes back to its original location, and points and revenue unwind automatically.

The delivery tour below shows couriers, zones, drivers and live parcel status.

Setup checklist: one inventory in eight steps

1. List your locations — warehouse, outlets, a virtual "in transit" location — and decide which ones ship online orders.
2. Clean your SKUs. One SKU per sellable variant, with a barcode. No duplicates across channels.
3. Count and load opening stock with cost for every location on the same day.
4. Connect every channel to the same catalogue: website, POS registers, manual and phone orders, and the API for mobile apps.
5. Set thresholds: a sensible store default plus per-SKU values for fast movers.
6. Configure delivery: zones, methods, rate rules and courier API credentials. Test one parcel per courier.
7. Turn on transfers with a dispatch and receive step, so stock in a van is never counted twice.
8. Agree a daily routine: review low-stock alerts, unmatched COD and returned parcels every morning.

Metrics that tell you it is working

Metric	How to calculate	Healthy target
Stock accuracy	Matching SKUs at a count ÷ SKUs counted	98% or better
Oversell rate	Orders cancelled for no stock ÷ all orders	Under 0.5%
Delivery success rate	Delivered ÷ shipped	Track by courier and zone
Return-to-origin rate	Returned parcels ÷ shipped	Falling month on month
COD days outstanding	Average days from delivery to cash received	Under 7 days
Sell-through	Units sold ÷ units received, per period	Compare by location

Targets vary by category and market, so treat these as starting points. What matters is that every one of them can be calculated from the same ledger without a spreadsheet.

Common mistakes to avoid

• Syncing instead of sharing. Two systems that sync stock will eventually disagree. One ledger cannot.
• Letting staff edit quantities directly. Every change should be a typed movement — adjustment, damage, found — with a reason.
• Ignoring stock in transit. Without a transit step, a transfer briefly exists in two places or none.
• Treating returns as an afterthought. Decide in advance where returned stock goes and how it is inspected.
• Measuring delivery by courier promises. Measure by your own delivered and returned data, per zone.

How StoreConsole approaches it

In StoreConsole, the storefront, POS, manual orders and the headless API all sell from the same inventory module, which keeps a guarded ledger per location with transfers, reservations and per-SKU alerts. The delivery module prices parcels with a rate engine, books couriers through their APIs, follows status callbacks, records partial deliveries and reconciles COD into accounting. You can explore it in the live demo or read the module pages for Inventory, POS and Delivery.

Key takeaways

• Channels sell from locations; stock belongs to locations, in one ledger.
• Record movements, not quantities. Available = on hand − reserved.
• Automate the delivery loop: quote, reserve, book, track, reconcile.
• Handle delivered, partly delivered and returned as first-class outcomes.
• Measure stock accuracy, oversell rate, delivery success, returns and COD days from the same data.

Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.