This is something that bugs me. When this ticket was initially created Bitcoin was something for very early adopters... a small community overall.

We are now in 2022 and there is still no proper support for it. I don't mind so much the classification as Stock... kinda works for me, but I want to be able to properly record a transaction from one crypto account to another, including fees. This makes it more a hybrid between currency and stock (which it is)

The refusal to support it reminds me a bit to vim and his benevolent developer refusing to move on with the time and resulting in NeoVim.

As of now this seems more like a refusal out of principle to not let users add their own currencies.

Just in case it helps anyone... If you're prepared to build the application from source code, there's a simple way to add currencies. The official workarounds don’t meet my needs. I mine, exchange and transfer crypto currencies frequently. Being able to properly and easily account for that is important to me. With the method below you can even create expense accounts denominated in a cryptocurrency which comes in handy for transaction fees.

## Disclaimer ##
I'm not a GnuCash developer and I don't recommend using this hack if you are using GnuCash for anything other than your own personal information. If you wish to use this method for tax purposes or creating reports for clients, do so at your own risk.

All you need to do is add to this file before compiling:

libgnucash/engine/iso-4217-currencies.xml

e.g.

<currency
isocode="ETH"
fullname="Ethereum"
unitname=""
partname=""
namespace="ISO4217"
exchange-code="nil"
parts-per-unit=""
smallest-fraction="1000000"
local-symbol="ETH"
/>

A few things to note:

1. Although it is not correct, namespace must be ISO4217 for it to appear in the currencies list.
2. If you want to go beyond 6 decimal places, please test thoroughly. I chose not to risk it.
3. Don’t expect to be able to use the live prices feature.

I thought that I’d be locked into using my customised build once I did this, but it seems that may not be true. The file/database containing accounts defined in the non-standard currencies seems to work just fine in the standard version of GnuCash. This would suggest that the predefined currencies are only used as a template when creating a new account. It also suggests that building from source code may not even be necessary and the same result could be achieved by manually editing the database instead.

Is gnucash team still considering this request? The treatment as a security does not work at all for my needs where I use cryptocurrency as currency on a daily basis personally and for my business. I tried ledger-cli but would really prefer the nice interface and features provided by gnucash.

I have a similar problem with XLM (Stellar Lumen) cryptocurrency.

I was forced to use XLM as a security not as a currency. But there are problems:

- 1 XML today is 0,04308 €
- when i received 356,2904939 XLM, its value is rounded to 2 decimals of € (not so critical at this point)
- some operations in the stellar network imply a fee of 0,00001 XLM. Since, I can't have expense accounts with the XLM security, I must convert 0,00001 XLM to 4,308e-07 € which Gnucash rounds to 0 €. This convertion must be done with the purchase price to avoid having capital gain/losses.

These problems would be solved if we could set additional currencies. I don't know another way.

Hello, all.

Until we get the extra decimal places I'm thinking about recording my bitcoin balances in what I call BTCC, as in bitcoinCENTs. So, 1 BTC = 100 BTCC. That gives the extra 2 places of precision. My wallet has 5.23472183BTC and is recorded at 534.472183BTCC.

I have it listed as a stock type. When paying expenses with bitcoin I plan to sell coin to a wash/suspense account and recording the expense in there.

Seems like the best practice, no?

> Yes, we'll be able to support smaller fractions than 10E-6 in 2.8. That's what I'm working on now.
Great to hear :)

> I do expect that more of them will do so in the next two years, and I predict that most OECD countries will follow the US lead.

Remains to be seen, but I can understand taking the conservative approach in the interim.

> The relevant code is scattered about the UI as well as the engine, and the major focus of this development cycle to fix that and get a properly layered database-driven application that will make it feasible to change the basic rules in the future.

That eases my concerns on this matter substantially. Perhaps once said rework is complete then I, and many others, can consider migrating back from Ledger.

Thanks for all your work on this project :)

Yes, we'll be able to support smaller fractions than 10E-6 in 2.8. That's what I'm working on now.

Duh, of course there are countries besides the US. But AFAIK none of them have issued rules about how to account for "virtual currency" transactions. Accounting is about rules, not arithmetic: The arithmetic is easy.

If you live in the USA, you *must* account for your bitcoin (or any other "virtual currency" that you use) in the way already supported by GnuCash. If you live anywhere else, you probably *should* account for them the same way, simply because that's what's least likely to get you in trouble, until your country's tax and accounting authorities get around to publishing their own rules. I do expect that more of them will do so in the next two years, and I predict that most OECD countries will follow the US lead.

I don't at present know all of the things that will have to change in GnuCash to support treating currencies and commodities the same. The relevant code is scattered about the UI as well as the engine, and the major focus of this development cycle to fix that and get a properly layered database-driven application that will make it feasible to change the basic rules in the future.

@John Ralls

There do in fact, exist countries besides the US. It's not knowable how every country will legislate Bitcoin, many have yet to make a statement one way or the other, some may decide to treat cryptocurrencies as securities, some may consider them currencies. Personally, I can't see the harm in simply allowing your users to make their own decision, appropriate to the laws of their jurisdiction. Ideally, through implementing a currency editor much like the existing security editor.

Failing that, an alternative could be to improve the existing securities functionality. Presently, this functionality is unsuitable for cryptocurrency use for two main reasons:

* Insufficient precision. Bitcoin is divisible down to fractions of 1E-8. Currently, Gnucash cannot represent fractions smaller than 1E-6. Thankfully, it seems that this concern may be addressed one way or another, if the "Rethinking Numeric"[1] thread is anything to go by.

* Inability to denominate income/expense accounts in securities. Around many cryptocurrencies, but particularly in the case of Bitcoin, exists a growing ecosystem of products and services denominated directly in cryptocurrencies. Right now, expense/income accounts can only be denominated in units from the "CURRENCY" namespace. I see no logical reason why it should not be possible for such accounts to be denominated directly in cryptocurrencies, especially considering a number of extremely large retailers (Dell, Newegg, Overstock) now directly accept Bitcoin for purchases. Likewise, a growing number of people/organisations offer services directly in exchange for Bitcoin, such as server hosting and contract jobs (programming and web development tasks are particularly common here).

I find it difficult to understand the hostility this topic has been received with each and every time it's been raised. There's quite clearly demand for better cryptocurrency support in FOSS accounting software. I'd posit that the only reason Gnucash hasn't yet been forked is that the technical-minded users who have the knowledge and expertise to do such a thing, simply take the path of least resistance, and switch (like I have) to Ledger[2], as it handles this use-case seamlessly. As it stands though, Ledger's not really an appropriate solution for the average, non-technical masses.

Regardless of your personal views, it's hard to deny that cryptocurrencies are a growing, global phenomena. Sooner or later, it should become apparent that listening to your users is a prerequisite to remaining relevant. As applies to any complex, organised system, regardless of whether the nature of that system is economic, social, biological or technological, there exists a simple choice: adapt, or fade into obscurity.

[1] http://lists.gnucash.org/pipermail/gnucash-devel/2014-May/037723.html
[2] http://ledger-cli.org/

> Currencies should not only be defined by ISO. US Gov said Bitcoin is a currencies already.

Utterly incorrect and likely to get you in trouble. See question 1 in
http://www.irs.gov/pub/irs-drop/n-14-21.pdf?utm_source=3.31.2014+Tax+Alert&utm_campaign=3.31.14+Tax+Alert&utm_medium=email

Bitcoin and all similar "convertible virtual currencies" are properties, like stocks or bonds. For US federal tax purposes at least GnuCash's current treatment of Bitcoin is correct.

I'd love this too. While you can, as a workaround, define cryptocurrencies as securities, this is less than ideal. Cryptocurrency-only markets are becoming increasingly common, and as far as I can tell, Gnucash doesn't allow you to define the price of one security in terms of another (e.g, some smaller/newer cryptocurrencies, like Monero (XMR), are mainly traded for bitcoins/litecoins (BTC/LTC) - they don't have well defined prices in any national/traditional currencies. Beyond that, you can't use cryptocurrencies defined as stocks for Income/Expense accounts.

Simply allowing custom currencies to be defined with a similar UI to that used for defining securities would go a long way to making Gnucash more usable to those increasingly involved in cryptofinance.

Added 3 votes

Currencies should not only be defined by ISO. US Gov said Bitcoin is a currencies already.

Please, consider the suggestion. I need to work with bitcoin and litecoin.

Please at least update the official ISO currencies to include ZMW! This is now the currency in Zambia where I am and I need it.

I need LTC and BTC and i really do not care about that ISO code. It's not the ISO code that makes the currency important or useful.
It is just like any other currency and automated price quote is unimportant.

I agree - in my case I need to add ZMW which is the new ISO code for the rebased Zambian currency as from 1st January 2013.
I need to be able to identify the 2013 Kwacha as different from the 2012 Kwacha, which has been reduced by a factor of 1000.
Until this is sorted out I am having to use Malawi Kwacha (MWK)!

See also the specific Bitcoin ticket - http://gnucash.uservoice.com/forums/101223-feature-request/suggestions/2277730-bitcoin

Apart from bitcoin, there are a variety of local currencies and new ones arising. Ithica hours was mentioned, there are also clams, philly ours, etc.

Same here, avid GnuCash user and new to bitcoin I was disappointed by that lack of support

Something like this would introduce GnuCash to the growing bitcoin crowd. I know I gave the idea of using GnuCash and bitcoins an unsuccessful try. Might get some support out of it--just my 2 cents.