Bitcoin DCA and taxes: tax lots and cost basis

A tax lot is a single purchase of an asset, recorded as three things: how much you bought, what it cost you, and when. That cost is the lot's cost basis, and it is usually the purchase price plus the fees you paid to acquire it.

The confusing part is that Bitcoin is fungible in every practical sense. The satoshis you bought in 2019 are indistinguishable from the ones you bought last Tuesday, and your wallet shows one balance. Accounting does not care. Where tax is tracked lot by lot, each purchase stays a separate parcel with its own history until you dispose of it. Other systems merge the parcels on paper: they pool identical coins into one holding with an averaged cost, so a sale is measured against the pool and not against a purchase you pick. Either way every purchase still has to be recorded. The cost basis calculator page has a short entry on pooling. Which system applies to you is a question about local rules.

In a lot-based system each lot also carries its own holding period: the clock that starts on the day you acquired it. Many tax systems treat gains differently depending on how long the specific parcel was held. The clock belongs to the lot, not to your account. So a stack built by DCA holds lots at every possible stage of that clock at once.

A lump-sum buyer has one purchase to keep track of. A DCA buyer adds one with every buy, forever. The arithmetic is trivial and the result is not:

Weekly buying for three years is the headline case: 52 × 3 = 156 purchases. One hundred and fifty-six acquisition dates and 156 costs to keep on record. In a lot-based system that is also 156 cost bases and 156 independent holding clocks. If you ever sell, gift, spend, or swap even a fraction of that stack, something has to decide which of those 156 parcels the disposal came out of, and that decision changes the number you report. In a pooling system the rules make that decision for you, and the calculation still runs on the same records.

None of this makes DCA a bad idea. It gives DCA an administrative cost, and that cost is worth knowing about on day one. Setting up a folder and a spreadsheet takes ten minutes at the start. Leaving it until year four means reconstructing three exchanges' worth of history from memory.

A disposal is the event that turns an unrealized paper gain into a realized one that the accounting has to deal with. Buying and holding generally does not do that; parting with the asset generally does. The concept most people get wrong is how many everyday actions count as parting with it. Depending on the jurisdiction, the list commonly includes:

• •Selling Bitcoin for fiat currency, meaning ordinary money like dollars or euros.
• •Trading Bitcoin for another crypto asset. That often counts as a disposal of the Bitcoin even though no cash changed hands.
• •Spending Bitcoin on goods or services. Buying a coffee can be a disposal of a fraction of a lot.
• •Gifting or donating, in some frameworks and not others.

Moving coins between wallets you control is usually a transfer rather than a disposal, because you have not given anything up. It is still the single most common place cost-basis records get destroyed. The receiving platform has no idea what those coins cost you, and if you did not keep the record yourself, nobody has it. Whether any of the above applies to you is a question for a professional where you live. The point here is only that "disposal" is broader than "sold for cash".

When you dispose of part of a stack made of many lots, something must decide which lots the disposal is matched against. These four names are just the answers to that question. They are accounting conventions, not tax strategies in themselves, and they belong to lot-based systems: a pooling system does not ask the question. Which of them you are permitted to use, and what you must document to use it, depends entirely on your jurisdiction.

• •FIFO (first in, first out). The oldest lots leave first. Simple and predictable. In a rising market it tends to match your cheapest coins against the sale, which means the largest gain but also the longest holding period. Some systems apply the order inside each wallet or account, not across everything you hold. The United States note below is one example.
• •LIFO (last in, first out). The newest lots leave first, so the coins you just bought are the ones considered sold. Not permitted everywhere.
• •HIFO (highest in, first out). The most expensive lots leave first, which minimizes the gain on that disposal. It is usually not a standalone method but a way of applying specific identification, with the documentation burden that implies.
• •Specific identification. You nominate exactly which lots the disposal came from. It is the most flexible approach and the most demanding. It generally requires contemporaneous records, meaning ones written at the time, identifying the specific units. That is why lot-level record-keeping is worth doing even if you never intend to use it.

Choosing a method takes an afternoon. Being able to evidence it takes years of discipline, and that is the part DCA makes harder. A lump-sum buyer needs one receipt. A weekly buyer needs a complete, unbroken chain of hundreds of them, surviving every exchange they ever used.

The failure modes are boringly predictable:

• •The exchange shut down, or you closed the account, and the export went with it. Export your history on a schedule, not when you need it.
• •You withdrew to self-custody and the basis did not follow. The blockchain records the movement, not what you paid.
• •Fees were left out of the basis. Acquisition fees are commonly part of what a lot cost you; dropping them overstates gains on every one of your lots at once.
• •You bought in one currency and report in another. The value at the time of each acquisition is what matters; converting everything at today's exchange rate is a different, wrong number.
• •Small spends went unrecorded. Paying for something in Bitcoin is easy to forget and, in many frameworks, is a disposal like any other.

The practical version of all this is unglamorous. Keep a running ledger with one row per acquisition: date, amount of BTC, price, fee, total cost, and where it happened. Add one row per disposal, and back the whole thing up somewhere that is not the exchange. Do that from the first buy and the eventual conversation with a professional is short. Start it in year four and it is archaeology.

The calculator on the homepage can export its purchase-by-purchase breakdown as CSV. That is genuinely useful for seeing the lot structure of a schedule before you commit to it. Open the file and every simulated buy is a row, which is exactly the shape a lot ledger takes. If you set a starting stack, it appears as one extra row, labeled as such, that is not a purchase. A plan whose end date is still in the future exports the buys dated up to today and leaves out the ones still to come. The columns are:

What the export is not:

• •It is a simulation of a hypothetical schedule, not a record of trades you actually made. Your real basis comes from your real exchange records.
• •There are no disposals in it. It only ever accumulates, so it cannot tell you a realized gain under any method.
• •There is no separate fee column. The fee reduces the Bitcoin acquired rather than appearing as its own line, so the file does not show the fee component of a lot's cost.
• •Non-USD figures are converted at one exchange rate for the whole file, not the rate on each historical date. That is fine for getting a feel for the numbers and wrong for anything resembling a tax record.
• •It is not a tax report, and this site does not produce one.

If you want to see the average cost of a set of purchases worked out rather than the lot structure, the Bitcoin cost basis calculator does that directly. The caveat there depends on the system you are in. Where tax is tracked lot by lot, an average across purchases is a useful summary number and not the per-lot basis your accounting needs. Under pooling it is close to the figure the calculation itself uses.