Tracking cost-of-goods-sold on individual card singles

Most inventory software tracks cost of goods sold (COGS) at the SKU or product level. Every unit of "Card X" a store has ever bought gets averaged into one cost figure, applied to every future sale of Card X. That average holds up for retail categories where a store buys the same product at close to the same price every time. Trading card singles don't work that way.

A store's copies of the same card can enter inventory at very different prices in the same week. A buylist intake might bring in a copy for $2. A bulk lot might value the same card at $0.50 once broken down. A single bought from another seller might cost $4. All three are "the same card" at the SKU level, but a blended average erases the price difference between them. When one specific copy sells, the SKU-level average applied to it can be badly wrong, overstating margin on the cheap copy and understating it on the expensive one.

At small volume this barely matters. At the volume a serious TCGplayer store runs, buylist intake, bulk lot breakdowns, and singles purchases layered together across thousands of cards, the gap between blended-average COGS and real per-unit cost compounds into a margin number that's wrong across the whole catalog.

Why almost nothing addresses this

Cost tracking at the individual-unit level, instead of the SKU level, is close to absent from the trading card software market. ShadowPOS is the one vendor that names it directly, calling its own feature "Accurate COGS Tracking" and stating plainly that "no other platform does this." That's a vendor's claim about its own product, not an independent finding, but it's an accurate description of how little is written about the problem anywhere else. Almost no other vendor treats per-unit cost as a feature worth naming.

ShadowPOS prices that capability inside a $200 per month all-inclusive plan, plus a 2% fee on marketplace sales and a separate 2% fee on website sales. Both percentage fees stack on top of the flat monthly charge and scale with revenue, regardless of the margin any individual sale actually produced.

Why a percentage fee works against the number you're trying to measure

That structure creates a specific problem for a store adopting per-unit COGS tracking to see its real margin. A 2% marketplace fee and a 2% website fee are themselves a cost that scales with sales, stacked on top of the same revenue the COGS calculation is trying to net against. The more precisely a store measures margin on a card, the more of that margin a percentage-of-sales fee claims back first.

Hoard's flat-fee pricing tiers don't carry a percentage-of-sales component. The monthly cost is fixed regardless of how many orders a store fulfills or how much revenue they generate. For a store tracking real per-card margin, that distinction matters: the cost of the tool doesn't move with the number the tool is measuring, so a gain in margin accuracy isn't offset by a bigger fee on the same sale.

Hoard's inventory sync and cost tracking follows the same logic as the rest of the inventory management guide: a card is a specific physical unit with its own history, not an interchangeable slot in a SKU. Cost is one more field where treating every copy as identical produces a number that's wrong on purpose, quietly enough that nobody checks it.

Sources: ShadowPOS · ShadowPOS: Cost of Goods Sold on TCG Singles