Can't I use a fractional Buy/Sell price on GnuCash that's more than 2 decimal places?

Question

Context

I want to track the transactions I made on Binance last year into GnuCash. I found out GnuCash doesn't support Bitcoin or cryptocurrencies in general, so I added them as a security, as suggested in this Reddit answer.

As Binance uses 8 decimal places for all currencies traded on it, I created a security with symbol 'BTC' and fraction 1/100000000. Then, I created two accounts: one called "Bitcoin" for that security (BTC) and another called "Binance" for my deposits in BRL. Since BRL uses 2 decimal places by default, I changed the field 'smallest fraction' of the BRL account to match Binance's decimal places, that is, 1/100000000. So far so good.

Problem

When I create a transaction from "Binance" to "Bitcoin" to track a purchase of BTC, I'm allowed to input a value that's up to 8 decimals in the fields "Shares", but the fields "Buy" and "Sell" always rounds the value to 2 decimals places.

To demonstrate it with actual data, my first purchase was on 11 May 2021. I bought 0.000117 BTC when BTC/BRL was at 297,782, which resulted in an expense of precisely 34.840494 BRL. That's the amount I want to place in the field "Buy" of the ledger of the account "Bitcoin", but as soon as I finish editing the field, GnuCash rounds it to 34.84 BRL and automatically adjusts the field "Price" to 297,777.7778, which is incorrect. I spent 34.840494 BRL, not 34.84 BRL.

I thought this might be due to the fact that the account "Binance" uses a 2-digit fiat currency (BRL); that GnuCash might be disregarding my setting for 'smallest fraction', so I had the idea of creating a security for BRL that has 8 decimal places. That didn't work either. I'm afraid GnuCash has hardcoded a 2-digit rounding strategy for values in the fields "Buy" and "Sell". Is there any workaround for this or am I missing something?

Answer 1

Since your broker is allowing you (forcing you?) to trade in small fractions of a BRL, one workaround is to create a security in GnuCash that is worth... a small fraction of a BRL.

I created a security (working title: "miniBRL") which can be exchanged at the rate of 10,000 miniBRL = 1.00 BRL. (I also trialled the microBRL, worth one millionth of a BRL, but GnuCash would not accept the astronomical exchange rate for purchasing BTC with microBRL. miniBRL worked though, on your example trade.)

So now, when you actually bought 0.000117 BTC with 34.840494 BRL, your GnuCash process could be:

1. Convert (buy) 350,000.00 miniBRL using 35.00 BRL from your Binance trading account.
2. Use 348,404.94 miniBRL to purchase 0.000117 BTC at an exchange rate of 2,977,820,000

After this process, the GnuCash accounts for BRL and miniBRL in your trading account should align with Binance's records of BRL in your trading account.

Answer 2

I think I ran into a similar problem running GnuCash 4.8 from Ubuntu 22.04 LTS. I believe the problem lies in the logic controlling the register GUI because when I import the values from a CSV file they come in with more precision. In short, you cannot reliably edit the "Price", "Shares", and "Totals" values freely. In 4.8 especially, values just randomly change. Further, there are unavoidable rounding issues that may become problems depending on your data source(s) and commodity setting that need to be avoided completely.

For an explicit example, with TRADING enabled a register entry (with splits) will look like this:

Date	Action	Memo	Account	Shares	Price	Buy	Sell	Total
	Buy		Asset:IBM	0.1234	1.00	0.1234 IBM
			Trading:USD	$ 99.99	8/854	0.12 IBM
	Dividend		Income:Dividend	$ -99.99	8/854		0.12 IBM
			Trading:IBM	-0.1200	1.00		0.12 IBM
			Imbalance-IBM	-0.0034	1.00		0.0034 IBM

The problem is that if I manually tried to change the "0.12" to "0.1234" it would immediately go back to "0.12" when I hit <tab>, even though IBM (all the accounts, actually) are set to 1/100000 and I also set the currency to 4 decimal places in the Edit -> Preferences -> Numbers ... settings. GnuCash would also randomly reset the "Shares" value to 1 or some other seemingly-random value. Sometimes it would tell me that the values were in conflict and ask which of the "Price", "Shares", or "?Total" I wanted to change. No matter which I chose GnuCash did something random and unhelpful.

To fix this problem, you have to go into the "Shares" and "Price" columns and enter the correct fixed values. For "Shares" as a currency, this is the actual dollar amount. For price, enter its inverse (eg, if the stock is $101.50/sh, enter 1/101.5). [Edit to add: When editing imported transactions I found it easiest to enter just the "Shares" column and let it calculate the price.] Then, don't hit <tab> but hit <down-arrow> and change the price entry there to be the same. Never edit the buy/sell quantities directly, because this is where the second problem comes in.

The second problem is that my report (the CSV file I imported) says "0.1234", but GnuCash says "0.12" and my calculator says "0.1233876". I think the "Imbalance" account will go away if I set the commodity resolution to 1/1000, and I may do that once I'm more comfortable with the other data I imported. But the key here is that the amount spent and the cost per share need to be the defining values, and the "Total" is rounded to whatever makes sense for display purposes. These numbers are rounded in the imported data and will be rounded in the GnuCash display as well.

Answer 3

As stated in my answer to this other question, the number of decimals allowed in the Buy and Sell columns is tied to the base currency of your GnuCash file. I found this out via trial and error. For example, if you select XPT (Platina) as your base currency, which has a precision of 1/1000000, then you are allowed to enter more decimals.

Of course, using XPT is not a solution, but this is how GnuCash works currently (V 4.12). On bugs.gnucash.org you can find several tickets related to bitcoin support but they are still in progress (some of them for several years).

A solution would be to change the name and precision of a currency in the factory list to Bitcoin, but currently it is not allowed. I read somewhere that the list is fixed and comes from some ISO standard. It can include only accepted currencies of countries and some extras like Gold and Platina.