POS Inventory Features: Stock, Cost and the Receipt Line

The catalogue is what prints on the receipt

Visa's Table 5-33 lists "Description of goods or services" among the elements a transaction receipt must contain, and defines it simply as a description of the purchase. That requirement is met or missed by your item list. A POS whose staff ring most sales through a generic open-amount key produces receipts that do not describe what was sold. The same weakness shows up later: when a cardholder disputes a charge, a line reading "Misc $42.00" is a poor piece of evidence, and the item-level detail you would want is the detail you did not capture. Building the catalogue properly is not an inventory luxury — it is the cheapest compliance and dispute-defence work available at the counter.

Whether you need inventory accounting at all is partly a tax question

Owners often ask whether inventory features are worth it, as if the answer were purely operational. IRS Publication 538 describes a small business taxpayer as one with "average annual gross receipts of $26 million or less (indexed for inflation) for the 3 prior tax years", and says such a taxpayer can account for inventory by treating it as non-incidental materials and supplies, or by conforming to its treatment of inventory in an applicable financial statement — or, with no applicable financial statement, by using the method in its books and records prepared according to its accounting procedures. That threshold is indexed, so check the figure for your current tax year rather than relying on the number in the publication. The practical point stands either way: if your accounting method leans on the books-and-records option, your POS is the books and records, and the quality of what it holds is the quality of the method. This is general information and not tax advice — confirm your method with your accountant.

Real-time deduction, variants and reorder points

Stock deducted at the moment of sale is what makes every other feature trustworthy. Variant handling matters wherever one product exists in sizes, colours or flavours, because a system that treats each variant as an unrelated product loses the ability to report on the product. Reorder points turn the stock record into an instruction rather than a report: below a set level, the item appears on a reorder list. The value there is working capital, not labour. Illustrative example with made-up round numbers: a shop carrying 400 lines that reorders on intuition might hold three months of cover on slow sellers and run out of the fast ones; the same shop reordering on sell-through holds a different mix at the same total stock value. We are not putting a saving on that, because the honest answer depends entirely on the shop.

Cost tracking is what turns sales data into margin data

A system that records only the sale price tells you revenue. A system that also records the landed cost of each unit tells you margin by product and by category, which is the number that decides what to promote, what to delist and what to reprice. Purchase order handling matters for the same reason: if goods receipts update both quantity and cost, cost tracking maintains itself; if they do not, it decays into a spreadsheet nobody updates. When comparing systems, the question is not whether cost fields exist but whether the receiving workflow populates them.

One stock record across channels

If you sell both in store and online, a shared inventory prevents selling the same unit twice. Split systems produce cancellations and refunds. Whether that justifies a more expensive platform depends on how much of your volume is online and how tight your stock cover is — a shop with deep stock on every line feels it far less than one selling one-of-a-kind goods. Ask specifically whether the sync is real-time or scheduled, and what happens to an order placed in the gap.

Inventory data, card data and scope

One boundary worth keeping clear: inventory data and cardholder data are different things and should stay that way. Your item catalogue, costs and stock counts carry no card data, and nothing about inventory reporting should require it. The card side of the counter lives with the PIN pad and card reader, which fall under the PCI PTS Point of Interaction standard covering devices "used to protect cardholder PINs, account data, and other sensitive payment card data at the point of interaction". If a vendor proposes an integration that moves card data into the inventory or reporting layer to enable a feature, that is a question for your acquirer before it is a question of features.

What to confirm before you sign

Does stock deduct at the moment of sale, or on a schedule? Do variants roll up to a parent product for reporting? Do goods receipts update cost as well as quantity? Can you set reorder points per item and per location? Does sell-through reporting run by product and by category, and can you export it? Does the receipt template carry a real item description? Does it sync to your accounting software — confirm before buying rather than after. And if you run more than one site, does reporting consolidate. Those answers separate systems more reliably than a feature list does.