Retail POS and Inventory: How to Pick a System That Knows What's on Your Shelves

Why is inventory the real buying decision?

Every POS on the market can scan a barcode, take a card, and print a receipt. If that were the whole job, you could pick a system by coin flip. The difference between platforms — the difference you'll live with for the next five years — is what happens to your stock data before and after that scan.

In retail, the POS is the cash register bolted onto an inventory system, and the inventory system is what you're actually buying.

Here's why that framing matters in dollars. For a typical independent retailer, inventory is the single largest asset on the balance sheet — often 50–70% of everything the business owns. Industry-typical shrink runs 1.5–2% of sales, dead stock quietly ties up 10–20% of inventory value in many stores, and every stockout of a proven seller is margin you never get back. A POS that tracks stock accurately attacks all three. A POS that treats inventory as an afterthought leaves you managing your largest asset on gut feel and an annual panic count.

So flip the evaluation order: audition the inventory module first — receiving, counting, reordering, reporting — and only then check that the register screen is pleasant. We've watched Dallas retailers pick a system for its slick checkout and spend the next two years exporting CSVs to spreadsheets to answer "what should I reorder?" Don't be that store.

What is matrix inventory, and who needs it?

Matrix inventory tracks one product across attribute combinations — size, color, width, style — as a grid of variants under a single parent item. A men's oxford in five sizes and four colors isn't twenty unrelated products; it's one product with twenty variants, each carrying its own barcode, cost, on-hand count, and sales history, all rolling up to the parent for reporting.

If you sell apparel, footwear, or anything with size runs, matrix support is mandatory, not nice-to-have. Without it you get one of two failure modes: either you create twenty flat SKUs per style and reporting turns to mush ("how is this shirt selling?" becomes a twenty-row export), or you track one SKU per style and lose size-level visibility — which is exactly where apparel money dies, because being out of medium while sitting on ten XXLs looks like "in stock" to a non-matrix system.

Test it in the demo: create a style with two attributes, receive a purchase order against specific variants, then run a report showing size-level sell-through. If any of those three steps requires a workaround, the platform doesn't really do matrix — it does tags.

What do high-SKU stores need that others don't?

Liquor stores, convenience stores, tobacco shops, and grocers play a different game: 5,000–30,000+ SKUs, thin margins, high velocity, and regulatory exposure at the register. Three capabilities separate purpose-built systems from general retail POS wearing a costume:

• Case breaks and unit conversion. You buy a case of 12, sell singles, six-packs, and full cases — sometimes all three from the same delivery. The system must receive by case and deplete by any sell unit, keeping cost-per-unit straight so your margin reporting isn't fiction. Bonus points for automatic case-to-single price relationships.
• Age verification prompts. Restricted items should force an ID check at the register — a hard stop with a date-of-birth scan or entry, logged per transaction, not a skippable suggestion. In Texas, a TABC violation is an existential event for a liquor store; your POS is your first line of documentation that your staff checked.
• Speed at scale. Item lookup across 20,000 SKUs must be instant, price updates must batch (when a distributor changes 400 prices, you import a file, not edit 400 items), and shelf-label printing should come straight out of the system.

This category is where KORONA POS earns its reputation — it was built for exactly this profile, which is why it's our default recommendation for liquor and convenience operators (more in the platform section below).

How should barcode workflows actually run?

Barcodes aren't just for checkout. A retail POS earns its inventory keep in three scanning workflows:

Receiving

The dock is where inventory accuracy is won or lost. The right workflow: receive against a purchase order, scanning each item so the system confirms what actually arrived versus what was ordered — catching shorted cases and substitutions at the door, while the driver is still there to sign for the discrepancy. Received quantities update on-hand automatically and update item cost if the vendor's price changed. If your candidate POS receives inventory by typing quantities into a grid from memory, your on-hand numbers will drift within a month.

Cycle counts

The annual full-store count is an autopsy; cycle counts are checkups. Good systems let you count one section per week with a scanner or a phone camera, compare against expected on-hand, and post adjustments with a reason code. A store that cycle-counts a few categories weekly maintains 95%+ inventory accuracy year-round; a store that counts once a year is accurate one day a year.

Shrink tracking

Every adjustment should demand a reason — damage, theft, expiry, sampling, count correction — so shrink becomes a report instead of a mystery. When shrink concentrates in one category or one shift pattern, that's information. Industry-typical shrink is 1.5–2% of sales; if a category runs 5%, the report just paid for the POS.

How do reorder points and vendor POs save your margins?

A reorder point is the on-hand level at which an item flags for replenishment; a good POS calculates it from sales velocity and vendor lead time, then drafts the purchase order for you.

The workflow to demand: each item carries a minimum (reorder point) and a target (par). When stock hits the minimum, the item lands on a reorder report grouped by vendor; one click drafts a PO for the difference between on-hand and par; the PO emails to the vendor and waits at the dock for scan-receiving. The loop closes without a clipboard.

Better systems go further and suggest the reorder point: an item selling 14 units a week from a vendor with a 7-day lead time needs roughly two weeks of cover plus safety stock — and the math should update as velocity changes seasonally. That's how you stop stocking to gut feel, which in practice means over-buying slow movers (cash trapped on shelves) and under-buying proven sellers (your best margin, out of stock on Saturday).

Vendor management matters here too: multiple vendors per item with different costs and case packs, vendor-specific item numbers on the PO, and cost history so you can see which distributor has been quietly raising you 2% a quarter.

How does omnichannel sync really work?

If you sell online and in-store, the only architecture that works long-term is one product catalog and one stock pool serving both channels in real time. A sale at the counter decrements the webstore; a web order reserves stock before someone buys the last one off the shelf; a price change propagates everywhere at once.

The alternative — separate in-store and online systems "synced" nightly by a connector — fails in exactly the way you'd expect: Saturday afternoon, the webstore sells the unit that walked out the door at 11 a.m., and now you're refunding a customer and eating the acquisition cost. Overselling and its evil twin, phantom inventory (the system says 3, the shelf says 0), are the two failure modes to interrogate in every demo.

This is WooPOS's home turf: it's built to run the register and a WooCommerce webstore off a single synchronized catalog, which is why it's our recommendation for merchants where the webstore is a real channel rather than a brochure. Whatever platform you pick, ask three questions: How fast does a counter sale update the webstore (seconds or "next sync")? What happens to web orders when an item hits zero? And do online and in-store sales land in one reporting pool, so "how did this product do?" has one answer?

Which reports matter (and which are noise)?

Retail POS reporting menus are long; the reports that change decisions are short. Four earn a standing weekly appointment:

Everything else — hourly sales heatmaps, register-level tender breakdowns, year-over-year drilldowns — is useful occasionally, but these four are the operating rhythm. If a candidate POS can't produce all four without exporting to Excel, keep shopping.

What about loyalty and gift cards?

Loyalty and gift cards are inventory-adjacent revenue tools, and they belong in the same platform decision. A points program tied to the POS turns your sales history into a marketing list — "you haven't been in for 60 days, here's 10% off" beats a billboard for an independent store. Gift cards, meanwhile, are cheap financing (cash now, goods later, and industry-typical breakage means a slice is never redeemed at all) — but only if balances work at every register and online from a single pool. Check that loyalty accrues correctly on discounted and matrix items, that gift cards can be sold and redeemed in both channels, and that neither feature is a third-party bolt-on with its own monthly fee and its own support number.

Which platform fits which store?

We carry three retail platforms and match by store profile, not commission:

• Clover — the right call for boutiques, gift shops, salons-with-retail, and general stores up to roughly 10,000 SKUs. Excellent hardware, fast staff onboarding, solid core inventory with an app market for extras. Its limits show up in deep matrix needs and very large catalogs — if you're an apparel store with heavy size runs, test the matrix workflow hard before committing.
• KORONA POS — purpose-built for high-SKU, high-velocity retail: liquor, convenience, tobacco, and similar. Case breaks, age verification prompts, fast bulk price updates, and inventory features that hold up at 20,000+ SKUs. This is our default for beverage retail in Texas.
• WooPOS — for merchants running (or launching) a WooCommerce webstore alongside a physical counter. One catalog, one stock pool, real-time two-way sync, and surprisingly deep inventory for the price. If online is a real channel for you, start here.

The honest summary: Clover wins on simplicity, KORONA wins on catalog depth and compliance workflows, WooPOS wins on omnichannel. See the lineup on our retail solutions page — and remember from our restaurant guidance that the processing agreement attached to any POS is most of its lifetime cost, so get the all-in number, not the SaaS number.

How do you migrate and do the first count?

A retail POS migration is really a data migration with a register attached. The sequence that works:

1. Export and scrub the catalog. Pull products, barcodes, costs, prices, and vendors from the old system. Kill dead SKUs (this is the best spring cleaning you'll ever do), standardize categories, and fix the "MISC" items your reports have been choking on for years.
2. Import products first, quantities never. Load the clean catalog into the new system — but do not import on-hand quantities from the old system. Those numbers are the accumulated drift you're escaping.
3. Count your way to truth. Set opening quantities with a full physical count: freeze receiving, count in zones with scanners, have a second person spot-check high-value zones. For big catalogs, count over 2–3 closed evenings by section.
4. Go live immediately after the count, so day-one numbers are real. Run the old processing account 30–45 days for trailing chargebacks — the same wind-down discipline we describe in our guide to switching processors — then close it in writing.
5. Cycle-count from week one. One section a week keeps the opening count true forever. Accuracy is a habit, not an event.

Frequently asked questions