What cost basis accounting methods are applicable to virtual currencies?
"The only ""authoritative document"" issued by the IRS to date relating to Cryptocurrencies is Notice 2014-21. It has this to say as the first Q&A: Q-1: How is virtual currency treated for federal tax purposes?   A-1: For federal tax purposes, virtual currency is treated as property. General tax principles applicable to property transactions apply to transactions using virtual currency. That is to say, it should be treated as property like any other asset. Basis reporting the same as any other property would apply, as described in IRS documentation like Publication 550, Investment Income and Expenses and Publication 551, Basis of Assets. You should be able to use the same basis tracking method as you would use for any other capital asset like stocks or bonds. Per Publication 550 ""How To Figure Gain or Loss"", You figure gain or loss on a sale or trade of property by comparing the amount you realize with the adjusted basis of the property. Gain. If the amount you realize from a sale or trade is more than the adjusted basis of the property you transfer, the difference is a gain. Loss. If the adjusted basis of the property you transfer is more than the amount you realize, the difference is a loss.  That is, the assumption with property is that you would be using specific identification. There are specific rules for mutual funds to allow for using average cost or defaulting to FIFO, but for general ""property"", including individual stocks and bonds, there is just Specific Identification or FIFO (and FIFO is just making an assumption about what you're choosing to sell first in the absence of any further information). You don't need to track exactly ""which Bitcoin"" was sold in terms of exactly how the transactions are on the Bitcoin ledger, it's just that you bought x bitcoins on date d, and when you sell a lot of up to x bitcoins you specify in your own records that the sale was of those specific bitcoins that you bought on date d and report it on your tax forms accordingly and keep track of how much of that lot is remaining. It works just like with stocks, where once you buy a share of XYZ Corp on one date and two shares on another date, you don't need to track the movement of stock certificates and ensure that you sell that exact certificate, you just identify which purchase lot is being sold at the time of sale."
The first method is the correct one. You bought an asset worth of $1000 and you put it on your depreciation schedule. What it means is that you get to write off the $1000 over a certain period of time (and not at once, as you do with expenses). But the value you're writing off is the $1000 regardless of how much you've written off already. Assume you depreciate in straight line over 5 years (that's how you depreciate computers for Federal tax purposes, most states follow). For the simplicity of the calculation, assume you depreciate each year as a whole year (no mid-year/mid-quarter conventions). The calculation is like this: If you sell the computer - the proceeds above the adjusted basis amount are taxed as depreciation recapture up to the accumulated depreciation amount, and as capital gains above that. So in your case - book value is the adjusted basis at the end of the year (EOY), depreciation this year is the amount you depreciate in the year in question out of the total of the original cost, and the accumulated depreciation is the total depreciation including the current year. In Maryland they do not allow depreciating to $0, but rather down to 25% of the original cost, so if you bought a $1000 computer - you depreciate until your adjusted basis is $250. Depreciation rates are described here (page 5). For computers (except for large mainframes) you get 30% depreciation, with the last year probably a bit less due to the $250 adjusted basis limitation. Here's what the GnuCash documentation, 10.5 Tracking Currency Investments (How-To) has to say about bookkeeping for currency exchanges. Essentially, treat all currency conversions in a similar way to investment transactions.  In addition to asset accounts to represent holdings in Currency A and Currency B, have an foreign exchange expenses account and a capital gains/losses account (for each currency, I would imagine).  Represent each foreign exchange purchase as a three-way split: source currency debit, foreign exchange fee debit, and  destination currency credit. Represent each foreign exchange sale as a five-way split: in addition to the receiving currency asset and the exchange fee expense, list the transaction profit in a capital gains account and have two splits against the asset account of the transaction being sold. My problems with this are: I don't know how the profit on a currency sale is calculated (since the amount need not be related to any counterpart currency purchase), and it seems asymmetrical.  I'd welcome an answer that clarifies what the GnuCash documentation is trying to say in section 10.5. If you want to convert more than a few thousand dollars, one somewhat complex method is to have two investment accounts at a discount broker that operations both in Canada and the USA, then buy securities for USD on a US exchange, have your broker move them to the Canadian account, then sell them on a Canadian exchange for CAD.  This will, of course, incur trading fees, but they should be lower than most currency conversion fees if you convert more than a few thousand dollars, because trading fees typically have a very small percentage component. Using a currency ETF as the security to buy/sell can eliminate the market risk. In any case, it may take up to a week for the trades and transfer to settle. Calculating and adjusting cost basis accurately is a daunting task, but there is a (paid) online tool, NetBasis, which will automatically calculate and adjust your cost basis.  It is used by brokerage firms and Fortune 500 companies and is available to the public.  Go to netbasis.com. All you need are the purchase and sale dates and shares of the stock or mutual fund and the system has the rest of the information, such as corporate actions (splits, spin-offs, etc), pricing, and dividends and it also will apply the appropriate IRS rules for inherited and gifted shares. The regulation also gives investors the option to choose calculation methods.  Not only does NetBasis automatically calculate the method you choose, it will also give the results for all options and allow you to choose the best result. NetBasis also provides you with detailed supporting documentation which shows all of the calculations and the adjustments in chronological order. NetBasis has data going back as far as 1925, so it will accurately calculate cost basis for your old American Telegraph and Telephone shares. NetBasis also handles complex investment scenarios such as wash sales, short sales, return of capital, etc. Moderator's note: Disclosure: The answerer's profile indicates they are affiliated with NetBasis. This is bullshit. The US government requires taxes to be paid in USD. There's your intrinsic value. If you want to be compliant with the federal law, your business and you as an individual are required to convert assets or labor into USD to pay them. "First of all, it's quite common-place in GnuCash (and in accounting in general, I believe) to have ""accounts"" that represent concepts or ideas rather than actual accounts at some institution.  For example, my personal GnuCash book has a plethora of expense accounts, just made up by me to categorize my spending, but all of the transactions are really just entries in my checking account. As to your actual question, I'd probably do this by tracking such savings as ""negative expenses,"" using an expense account and entering negative numbers.  You could track grocery savings in your grocery expense account, or if you want to easily analyze the savings data, for example seeing savings over a certain time period, you would probably want a separate Grocery Savings expense account. EDIT: Regarding putting that money aside, here's an idea:  Let's say you bought a $20 item that was on sale for $15.  You could have a single transaction in GnuCash that includes four splits, one for each of the following actions: decrease your checking account by $20, increase your expense account by $20, decrease your ""discount savings"" expense account by $5, and increase your savings account (where you're putting that money aside) by $5." "In 2014 the IRS announced that it published guidance in Notice 2014-21. In that notice, the answer to the first question describes the general tax treatment of virtual currency: For federal tax purposes, virtual currency is treated as property. General tax principles applicable to property transactions apply to transactions using virtual currency. As it's property like any other, capital gains if and when you sell are taxed. But there's nothing illegal or nefarious about it, and while you might get some odd questions if a large deposit ends up in your bank account, as long as you answer them there really isn't a problem. If you don't have documentation of how much you paid for it, if it's a trivial amount compared to what it's worth now you can just declare $0 as your basis. I would suggest you try to have documentation that you've held it at least one year so that it's a long-term capital gain, but you can just mark the purchase date as ""Various"" on your tax form. I've done this (for a much smaller amount of bitcoins, alas) and haven't run into any trouble. While there are some good reasons to sell slowly, as others are saying, I want to play devil's advocate for a minute and give you a reason to sell quickly: A decision to hold is equivalent to a decision to buy. That is, if a million dollars randomly ended up in your bank account for no reason, you probably wouldn't choose to go put it all into bitcoin, and then slowly sell it. Yet that's more-or-less an equivalent financial situation to holding on to the bitcoin and slowly selling it. While there are certainly tax advantages to selling over the course of many years, bitcoin is one of the most volatile commodities out there, and one has no idea what will happen over the next few weeks, let alone the next few years. It may go to tens of thousands of dollars a coin, or it may go to basically zero. If I had a million dollars in my pocket, bitcoin isn't how I'd choose to store it all. Just something to think about; obviously you need to make the best choice for you for yourself." "For the purposes of report generation, I would recommend that you present the data in the currency of the user's home country. You could present another indicator, if needed, to indicate that a specific transaction was denominated in a foreign currency, where the amount represents the value of the foreign-denominated transaction in the user's home country Currency. For example: Airfare from USA to London: $1,000.00 Taxi from airport to hotel: $100.00 (in £) In terms of your database design, I would recommend not storing the data in any one denomination or reference currency. This would require you to do many more conversions between currencies that is likely to be necessary, and will create additional complexity where in some cases, you will need to do multiple conversions per transaction in and out of your reference currency. I think it will be easier for you to store multiple currencies as themselves, and not in a separate reference currency. I would recommend storing several pieces of information separately for each transaction: This way, you can create a calculated Amount for each transaction that is not in the user's ""home"" currency, whereas you would need to calculate this for all transactions if you used a universal reference currency. You could also get data from an external source if the user has forgotten the conversion rate. Remember that there are always fees and variations in the exchange rate that a user will get for their home country's currency, even if they change money at the same place at two different times on the same day. As a result, I would recommend building in a simple form that allows a user to enter how much they exchanged and how much they got back to calculate the exchange rate. So for example, let's say I have $ 200.00 USD and I exchanged $ 100.00 USD for £ 60.00, and there was a £ 3.00 fee for the exchange. The exchange rate would be 0.6, and when the user enters a currency conversion, your site could create three separate transactions such as: USD Converted to £: $100.00 £ Received from Exchange: £ 60.00 Exchange Fee: £ 3.00 So if the user exchanged currency and then ran a balance report by Currency, you could either show them that they now have $ 100.00 USD and £ 57.00, or you could alternatively choose to show the £ 57.00 that they have as $95.00 USD instead. If you were showing them a transaction report, you could also show the fee denominated in dollars as well. I would recommend storing your balances and transactions in their own currencies, as you will run into some very interesting problems otherwise. For example, let's say you used a reference currency tied to the dollar. So one day I exchange $ 100.00 USD for £ 60.00. In this system I would still have 100 of my reference currency. However, if the next day, the exchange rate falls and $ 1.00 USD is only worth £ 0.55, and I change my £ 60.00 back into USD, I will get approxiamately $ 109.09 USD back for my £ 60.00. If I then go and buy something for $ 100.00 USD, the balance of the reference currency would be at 0, but I will still have $ 9.09 USD in my pocket as a result of the fluctuating currency values! That is why I'd recommend storing currencies as themselves, and only showing them in another currency for convenience using calculations done ""on the fly"" at report runtime. Best of luck with your site!"