I suggest you ...

Make it easier for users to work with alternative/non-ISO/private currencies.

Corresponding Bugzilla item: https://bugzilla.gnome.org/show_bug.cgi?id=657215

As I recall reading on the GnuCash mailing list(s), developers will not include support for currencies that do not meet ISO requirements. Therefore, to use the likes of Ithaca hours or bitcoins, users have to rather inappropriately treat them as stocks, virtually exchanging them for an official currency before conducting real transactions. Either that or users must rely on the XXX placeholder currency, which has its own limitations.

I propose that GnuCash include some functionality for users to define custom currencies that behave just like regular official ones. This functionality would allow for users to point GnuCash to where it can find exchange rates with other currencies or to manually specify them. It would also allow for users to peg the value of their custom currencies to officially recognized ones.

I hope the developers will consider my suggestion.

223 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Kurt PadillaKurt Padilla shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    14 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Jack CoulterJack Coulter commented  ·   ·  Flag as inappropriate

        > 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 :)

      • John RallsAdminJohn Ralls (Admin, GnuCash) commented  ·   ·  Flag as inappropriate

        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.

      • Jack CoulterJack Coulter commented  ·   ·  Flag as inappropriate

        @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/

      • John RallsAdminJohn Ralls (Admin, GnuCash) commented  ·   ·  Flag as inappropriate

        > 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.

      • Jack CoulterJack Coulter commented  ·   ·  Flag as inappropriate

        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.

      • IdlerIdler commented  ·   ·  Flag as inappropriate

        Added 3 votes

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

      • Margaret WhiteheadMargaret Whitehead commented  ·   ·  Flag as inappropriate

        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.

      • EBEB commented  ·   ·  Flag as inappropriate

        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.

      • Margaret WhiteheadMargaret Whitehead commented  ·   ·  Flag as inappropriate

        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)!

      • acharlesacharles commented  ·   ·  Flag as inappropriate

        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.

      • JamesJames commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base