Software Guide

SKU Management Software: SKU Tracking, Data, and Inventory Control

What a SKU record has to hold, the capabilities worth paying for, how to keep a large catalog clean, and the questions that separate the options.

SkuNexus Team · April 25, 2024 · 11 min read
SkuNexus is the best SKu Software

SKU management software tracks every stock keeping unit you sell across warehouses, storefronts, and marketplaces. It keeps on-hand, committed, and available quantities correct as receipts, picks, transfers, and returns post against each SKU, and it keeps the movement history you need when a count does not reconcile.

What SKU software does

A SKU, or stock keeping unit, is the identifier your business assigns to a sellable item. It belongs to you, not to the manufacturer. A UPC or GTIN identifies a product globally; a SKU identifies the item the way your operation actually handles it, which is why two merchants can stock the same case of coffee under two completely different codes.

SKU software is the system of record for those identifiers. For each one it holds four kinds of data:

  • Descriptive: title, attributes, unit of measure, dimensions and weight, supplier, cost
  • Identifier: barcodes, vendor part numbers, marketplace listing IDs
  • Quantity: on hand, committed to open orders, available to promise, on order, broken out by location
  • Movement history: every receipt, pick, adjustment, transfer, cycle count, and return posted against the SKU

The last two separate a stock system from a product catalog. A catalog tells you what you sell. SKU software tells you how much of it you have, where it sits, and what happened to it.

What a complete SKU record holds

Field group Examples What breaks without it
Identity SKU code, barcodes, vendor part numbers, channel listing IDs Scans fail at receiving; channel orders arrive unmatched
Physical Unit of measure, dimensions, weight, storage requirements Cartonization and rate shopping guess; slotting is manual
Sourcing Supplier, cost, lead time, minimum order quantity, case pack Reorder suggestions arrive too late or in unusable quantities
Position On hand, committed, available, on order, per location and bin Overselling, and picks sent to the wrong building
History Every receipt, pick, transfer, adjustment, count, return Variances become unexplainable; audits become manual

A platform that stores the first three groups is a catalog with extras. The last two are what make it inventory software.

Traceability: lots, serials, and expiry

Some catalogs need identity below the SKU. Food and beverage, supplements, and cosmetics track lot codes and expiry so a recall can be scoped to the affected production run instead of the entire SKU. Electronics and equipment track serial numbers so a warranty claim resolves to one unit. Auto parts often need both, plus the vehicle fitment data that determines whether the part is the right one at all.

The practical requirement is that the lot or serial travels with the unit through receiving, putaway, picking, and shipping, and that it is queryable afterward in both directions: which customers received units from this lot, and which lot did this customer receive. That question is the reason SKU-level audit logs matter beyond accounting. If a platform records only quantity changes and not the identifiers attached to them, a recall becomes a manual reconstruction from shipping records.

Where SKU data usually breaks

Most merchants do not adopt a dedicated system because they want better reports. They adopt it because something broke. The failures repeat:

  • Duplicate SKUs for one physical item. A supplier change or a new marketplace listing creates a second code, and on-hand quantity splits across both.
  • Storefront variant IDs used as SKUs. Rename a variant and the history disconnects from the item sitting on the shelf.
  • Kits and bundles that are not decomposed. Selling a bundle does not decrement its components, so component stock drifts silently.
  • One blended quantity across locations. The number looks right in total and is wrong at every individual warehouse.
  • No movement trail. When a count is off, nobody can say when it went off or who touched it.

Capabilities worth paying for

Quantity by location, updated as work happens

Availability has to be calculated per location and per channel, not stored as a single number. That means tracking committed quantity separately from on hand, so an order placed but not yet picked stops the same unit from being sold twice. Merchants selling through a storefront, a marketplace, and a retail counter need this before they need anything else. Multi-location order management covers how allocation rules behave when stock lives in several buildings.

Reorder points and low-stock alerts

Set a threshold per SKU per location and let the system raise a purchase suggestion when available quantity crosses it. The version that actually works accounts for quantity already on order and for supplier lead time, so you do not reorder something that ships tomorrow. Purchase order software handles the receiving half of the same loop.

Barcode scanning tied to the SKU record

Scanning is how SKU data stays honest. Receiving, putaway, picking, packing, and cycle counting should all post against a scanned code rather than a typed one. Support for multiple barcodes per SKU matters more than most buyers expect, because vendors relabel and marketplaces issue their own codes. The barcode scanner inventory guide goes deeper on hardware and workflow.

Movement history and audit logs

Every quantity change should carry a timestamp, a user, a reason code, and a reference document. That is what turns a variance from an argument into a short investigation, and it is what finance asks for at year end. If a platform can show you a running ledger per SKU, cycle counting becomes a correction process instead of a guessing game.

SKU performance reporting and rationalization

Sell-through, turns, days of supply, margin, and return rate per SKU tell you which codes earn their shelf space. Rationalization is the follow-through: retire the slow tail, consolidate near-duplicates, and stop reordering what has not moved in two seasons. This is where inventory control practice and the software meet.

Managing a large SKU catalog

Catalogs become unmanageable through accretion, not through one bad decision. A few habits keep a five-figure catalog usable.

  1. Pick a naming convention and freeze it. Short, readable, and parseable by a human beats clever. Encode only attributes that will never change, and never encode price, season, or vendor.
  2. Put variable attributes in fields, not in the code. Color, size, and material belong in structured attributes you can filter and report on.
  3. Never reuse a retired SKU. Reuse destroys the history that made the record worth keeping.
  4. Define kits explicitly. A bundle needs a component list so a sale decrements the right units in the right places.
  5. Run a rationalization pass on a schedule. Quarterly is enough for most merchants. Merge duplicates, retire dead codes, and write down the decision.

Merchants at this scale usually also need per-SKU rules rather than global settings: different reorder logic for a fast-moving consumable than for a special-order item. If your software supports only one policy for the whole catalog, the exceptions end up back in a spreadsheet.

The SKU numbers worth acting on

SKU reporting produces more metrics than anyone can use. Five of them drive decisions.

  • Inventory turns. Cost of goods sold divided by average inventory value, per SKU or per category. Low turns mean cash sitting on a shelf. Compare a SKU against its own category, not against the catalog average, because a seasonal item and a staple should not be held to the same number.
  • Days of supply. Current available quantity divided by average daily units sold. Read alongside supplier lead time: a SKU with 12 days of supply and a 30 day lead time is already late, no matter how healthy the on-hand number looks.
  • Sell-through rate. Units sold divided by units received over the same window. Useful right after a buy, when turns have not accumulated enough history to mean anything.
  • Stockout rate. The share of days a SKU was unavailable while it had demand. Total stockout counts flatter you; measuring the days that mattered does not.
  • Dead stock value. Cost of units with no movement in a defined window. This is the number that funds the case for rationalization, because it is denominated in cash rather than in SKU counts.

Each of these depends on movement history being complete. A platform that overwrites quantities rather than posting transactions can show you a current number but cannot show you the trend that makes the number actionable.

ABC analysis and how to retire a SKU

ABC analysis ranks SKUs by contribution, usually by annual revenue or by cost of goods sold, and splits them into three bands. The A band is a small share of codes producing most of the value; the C band is a long tail that consumes shelf space, count labor, and purchasing attention out of proportion to what it returns. The point is not the labels. The point is that the three bands deserve different treatment: tighter reorder points and more frequent counts on A items, looser settings and less attention on C items.

Retiring a C-band SKU is a decision, not a deletion. A workable test before you pull one:

  1. Has it moved in the last two full seasons for its category?
  2. Is it a component of a kit, or a required accessory for an A-band item?
  3. Does a near-duplicate SKU exist that customers accept as a substitute?
  4. Is remaining stock worth more sold at a discount than held at carrying cost?

If the answers say retire, mark the SKU inactive rather than removing it. The record has to stay queryable for returns, warranty, and historical reporting long after the last unit ships.

Cycle counting instead of annual counts

An annual physical count tells you how wrong you were, once a year, after the errors have compounded. Cycle counting samples a slice of the catalog continuously so variances surface while their cause is still findable. Count frequency usually follows the ABC bands: A items on a short cycle, C items rarely.

What makes cycle counting work is not the schedule, it is the follow-up. Every variance needs a recorded reason, and repeated variances on the same SKU or in the same zone point at a process problem, not a counting problem. Common culprits are receiving in the wrong unit of measure, kits picked without decrementing components, and returns put back on the shelf without being posted.

When a spreadsheet stops being enough

Merchants tend to hold on to spreadsheets and storefront-native stock fields longer than they should. The signals that the tooling has been outgrown are specific:

  • You sell the same SKU on more than one channel and reconcile quantities by hand.
  • Stock sits in more than one location and allocation decisions are made from memory.
  • Someone maintains a separate file to work out what to reorder.
  • Overselling has moved from an occasional embarrassment to a weekly one.
  • You cannot answer, from a system, where a specific unit went.

Two or three of these together generally mean the manual overhead already costs more than the software would.

How SKU data connects to the rest of your stack

SKU software is only as useful as its connections, because the SKU is the join key for the whole operation.

  • Storefronts and marketplaces. Quantity pushes out, orders pull in, and every channel has its own identifier scheme, so the mapping has to live in the platform. See Shopify inventory management and inventory software for eCommerce.
  • Point of sale. Retail sales have to decrement the same records as online sales, or available-to-promise is fiction.
  • Warehouse execution. Pick, pack, and ship steps write back to the SKU ledger. The WMS guide covers what that looks like on the floor.
  • Purchasing and suppliers. Vendor part numbers map to your SKUs so receiving can scan the label the vendor applied.
  • Accounting. Cost per SKU and inventory valuation flow through to the ledger.

What SKU-level control looks like in production

Three SkuNexus customers, three different reasons for needing it.

Graeter's Ice Cream managed inventory across multiple warehouses on systems that did not share data, with packing decisions made by hand. Automating 100% of their orders on custom SkuNexus functionality removed the manual steps and the errors that came with them, and their annual e-commerce volume grew from 270,000 to over 550,000 pints.

New Look Vision Group, Canada's largest eyewear retailer, needed order fulfillment to keep pace with expansion into the U.S. SkuNexus automated order management across their growing network and integrated with their Magento 2 platform, which reduced processing times and operational cost.

Carewell, an online marketplace for caregiving products, was adding vendors faster than its systems could absorb them. A SkuNexus order management build integrated with their BigCommerce storefront and automated purchase order generation and customer communication, holding order accuracy steady while the vendor count grew.

Choosing SKU software

Questions that separate the options

  1. Can it hold multiple barcodes and vendor part numbers on one SKU?
  2. Does it calculate availability per location, or only in total?
  3. Can reorder rules differ by SKU, by location, and by season?
  4. Is every quantity change logged with user, reason, and reference document?
  5. Do kits and bundles decrement their components correctly?
  6. Does it write back to your storefront fast enough to prevent overselling at your order volume?
  7. What happens when your process does not match the software's assumption: configure, customize, or change your process?

That last question decides more implementations than feature lists do.

What the investment actually includes

Budget for more than the license. Implementation cost tracks with the number of integrations, the volume of historical data to migrate and clean, and how far your workflows sit from the software's defaults. Data cleanup is the line item buyers underestimate most often: duplicate and orphaned SKUs have to be resolved before go-live, not after.

FAQs

What is SKU in software?

SKU stands for stock keeping unit, a unique identifier your business assigns to each item it stocks. In software, the SKU is the key that links descriptive data, barcodes, quantities by location, cost, and movement history to a single record.

How does SKU software handle inventory across multiple warehouse locations?

It tracks quantity per location rather than as one blended number, and calculates availability per location. That lets you allocate an order to the warehouse that can actually ship it, transfer stock between sites with a documented trail, and set different reorder points at each site.

Can SKU software be customized to fit the unique needs of my business?

That depends entirely on the platform. Most tools let you configure fields and rules within limits the vendor set. SkuNexus is built to be modified: workflows, rules, and integrations are open, so the system adapts to how your team already works rather than the reverse.

What is the implementation process for SKU software, and how long does it take?

The usual sequence is needs assessment, data cleanup and migration, configuration and customization, integration with your storefront and other systems, testing against real orders, and training. Duration depends on how many integrations are in scope and how much SKU data needs correcting first.

What are the costs involved in implementing an inventory SKU system?

Licensing, implementation, integration work, and data migration, plus ongoing support and any customization you request later. The variables that move the total most are integration count, catalog size and condition, and how much of your process the software has to be adapted to fit.

Where SkuNexus fits

SkuNexus is an inventory, order, and warehouse platform for mid-market merchants who have outgrown off-the-shelf tools but cannot justify an enterprise suite. The difference is customization: the platform is built to be changed. If your allocation logic, your kitting rules, or your receiving process is unusual, that is something to build around, not something to abandon.

For SKU management specifically, that means real-time quantity across channels and locations, barcode-driven warehouse work, customizable reorder and allocation rules, and integrations with the storefronts and marketplaces you already sell on. For the wider view, start with the inventory management system guide or custom inventory management software.

Schedule a demo and bring your hardest SKU scenario. That conversation is more useful than a feature tour.

Related reading

About the Author

Yitzchak Lieblich, known as Yitz, is the founder and CEO of SkuNexus. He has worked in eCommerce since 2007, founded , and has helped merchants from small startups to Fortune 100 companies run inventory, order, and warehouse operations across auto parts, food and beverage, apparel, B2B wholesale, and retail/D2C.