FIFO cost basis for skin traders, with a worked example

You bought the same AK-47 four times last year, at four different prices. Then you sold two of them. Which purchase did you just sell?

The item cannot answer that. One Redline is indistinguishable from another, and nothing in your inventory records which specific unit left it. But the answer changes your tax bill, sometimes by a lot — so tax systems require you to pick a matching method and apply it consistently. The most widely accepted is first in, first out.

How FIFO works

FIFO assumes the unit you disposed of is the oldest one you still hold. Your purchases form a queue in the order you made them; each sale takes from the front.

Take these six trades in one item over a year:

You spent $161.00 across four purchases and received $105.50 across two sales. You still hold two units. FIFO matches them like this:

• The September sale at $45.50 takes the oldest purchase, the January one at $30.00. Gain: $15.50.
• The November sale at $60.00 takes the next oldest, the March one at $42.00. Gain: $18.00.

Your realised gain for the year is $33.50. The June and September purchases were never matched, so their combined $89.00 stays as the cost basis of the two units you still hold, and carries into next year.

The arithmetic closes: $161.00 spent less $89.00 still held means $72.00 of basis was consumed, and $105.50 received less $72.00 is $33.50.

Why the method changes the answer

Run the same six trades through the other common methods and you get three different numbers:

Same trades, same year, a spread of $17.00 on six transactions in one item. Scale that across four thousand disposals and the method is not a detail — which is precisely why you cannot pick per sale. You choose one, you apply it to everything, and you say on the report which one you used.

Which method are you allowed to use?

This depends on where you file, and it is worth checking rather than assuming:

• United States. FIFO is the default. Specific identification is permitted for some asset classes if you can genuinely document which unit you sold — which for fungible skins you usually cannot.
• United Kingdom. HMRC uses Section 104 pooling for fungible assets, an averaging approach, with same-day and 30-day rules layered on top. Whether skins are fungible enough to pool is arguable, since float and pattern make many of them genuinely distinct.
• Elsewhere. Several countries mandate average cost; others accept FIFO. A few permit LIFO. Do not assume the method your software defaults to is the one your authority expects.

Or you can avoid the question

Every method above exists for one reason: nobody knows which specific unit was sold, so a rule is needed to stand in for the fact. But CS2 items are not actually anonymous. Each one has a Steam asset ID, and many carry stickers, a name tag, a charm or a distinctive pattern.

That is the approach Itemtax takes. Its matching engine follows each item from the moment it entered your inventory to the moment it left, so a sale is tied to the item that was really sold rather than to the oldest one with the same name, and it falls back on a rule only where an item genuinely cannot be pinned down. When that happens the line says so, rather than presenting the fallback as if it were a fact. Specific identification, where it is available, is more accurate than any rule can be — and what makes it hard to do by hand is the subject of Why tracking CS2 skins for tax is so hard.

Fees change both sides

Cost basis is not the sticker price and proceeds are not the sale price. Marketplace fees move both, in opposite directions:

• On a sale, the fee reduces your proceeds. Sell at $100 on a venue taking 15% and your proceeds are $85, not $100.
• On a purchase, any buyer-side fee increases your basis. Pay $50 plus a 2% fee and your basis is $51.

Both adjustments reduce the gain, and both are routinely dropped from hand-built spreadsheets — so the spreadsheet overstates the profit and the trader overpays. On a year of high-volume trading with fees around the typical 5–15%, this is not a rounding error.

Convert on the day, not at year end

If you buy in one currency and file in another, each trade converts at the rate on its own date. Using one year-end rate for everything is the second classic spreadsheet error, and unlike the fee problem it can push the result in either direction depending on which way the currency moved.

This matters more here than in most markets, because the venues really do price differently — Buff163 in yuan while your report is in dollars or pounds, with purchases and sales months apart.

Why this breaks down by hand

The queue above is manageable because it is one item and six trades. The real version is thousands of disposals across hundreds of distinct items, on five venues, where a skin bought on one was sold on another — and the matching has to run per item, across all of them at once, in date order, with fees applied on each line and the right exchange rate for the day of each trade.

A spreadsheet can do this. It takes a weekend, and the errors it produces are quiet ones — an unmatched buy here, a fee omitted there — which surface only if someone checks. That is the job Itemtax automates: connect your accounts, and every disposal is matched to the item behind it and to what that item actually cost, with each figure traceable back to the trade it came from.

For the wider picture on when a disposal is taxable at all, see Do you pay taxes on CS2 skins? — and for who actually reports your sales, and who does not, Does Steam report your skin sales to the IRS?.