[GNC] Balance sheet (multicolumn) shows Assets != Liabilities due to rounding of foreign currency amounts

[Tamar Hamlyn]

Hi GnuCash users,

I searched the bug tracker but couldn't find this specific issue
documented below.

Kind regards,
Tamar.

Issue: Balance sheet (multicolumn) shows Assets != Liabilities due to
rounding of foreign currency amounts

Version
-------
GnuCash 5.15, macOS

Issue
-----
Generating a balance sheet (multicolumn) can produce asset total !=
liability total, due to rounding of foreign currency amounts. Standard
balance sheet is unaffected.

Steps to reproduce
------------------
A test gnucash file with transactions below is attached.

New book:
Choose reporting currency: AUD

New accounts under Current Assets:
Bank 1(JPY)
Bank 2(JPY)

Existing Equity account:
Opening balances(AUD)

Transactions (entering the AUD quantity in the "to amount" field in
the exchange rate window):
Bank 1: JPY 500k / Opening balances: AUD 3,333.33
Bank 2: JPY 200k / Opening balances: AUD 1,333.33

Prices:
Tools, Price Database, expand Currencies to JPY, add a new
end-of-period exchange rate of:
2026-06-30: 0.00666665

Note the slight exchange rate difference with the transaction-derived
rate of 0.00666666. This difference is what triggers divergent
rounding between the two reports.

Run report:
Balance sheet (multicolumn). Report Options, Commodities tab: set
reporting currency to AUD, set price source to last up through report
date.
For comparison, also run standard balance sheet. Apply same report
options in Commodities tab: set reporting currency to AUD, set price
source to last up through report date.

Actual behaviour
----------------
Balance sheet (multicolumn) does not balance: assets != liabilities.
Assets total from balance sheet report is: AUD 4,666.65
Liabilities total from balance sheet report is: AUD 4,666.66

Note the 1 cent difference. Balance sheet (standard) displays correct
behaviour, assets and liabilities both total AUD 4,666.66.

Desired behaviour
-----------------
Balance sheet should ALWAYS balance.

If balance sheet totals do not match, this suggests an accounting
error and invites questions about errors or inaccuracies. It makes the
balance sheet report invalid by definition.

Possible cause
--------------
The possible cause might relate to the multicolumn report using a
round-then-sum approach, while the standard report uses
sum-then-round.

The current behaviour in balance sheet (multicolumn) is consistent
with the following:
- First convert child foreign currency amount to a corresponding
(rounded) amount in reporting currency. This involves multiple
conversions and applies rounding to every conversion.
- Then sum the resulting rounded reporting currency amounts to produce
intermediate and top-level reporting currency totals.
This approach accumulates rounding errors at each level in the account
hierarchy, which in turn results in the top-level discrepancy in
totals. It is a round-then-sum approach.

Possible fix
------------
If strict equality between assets and liability is desirable, then
balance sheet (multicolumn) report should instead do the following:
- First, determine all intermediate and top-level foreign currency
quantities, by aggregating all child foreign currency quantities at
each point in the account hierarchy.
- Convert each foreign currency total at each level in the account
hierarchy to the reporting currency amount as a single conversion.
Present these totals in the report.
This sum-then-round approach only performs a single rounding operation
as the last step at each level of the account hierarchy. This ensures
that maximum accuracy is retained for account totals, as they are
constructed directly from their local-currency components. Notably
this approach does not re-use rounded subtotals to construct parent
account amounts.

Discussion
----------
While the sum-then-round approach can ensure the balance sheet does
balance, it also means that report subtotals and totals may not
reflect the sum of their displayed sub-accounts and subtotals. Is it
desirable to prioritise line-item consistency over balance-sheet
equality?

I'd be grateful for feedback from users or devs who have encountered
this issue, or who are familiar with the development history, who have
views either way on which approach might be preferred.

Real-world impact
-----------------
The above rounding errors mean that a real-world balance sheet does
not balance in approximately 5 out of the past 10 years. The accounts
contain assets across around 6 foreign currencies, with relatively
infrequent changes in holdings throughout the history.

There are no specific triggers for the mismatched balance sheet
totals, other than the randomness of rounding foreign currency
subtotals and their conversion at the relevant exchange rates in
effect at each balance sheet date.

AI usage
--------
The explanation above was written by myself after testing the above
steps manually in GnuCash. I then ran my draft through Claude which
made minor changes to grammar and clarity of explanation.

Attachments
-----------
1 General Journal.png
2 Balance Sheet Multicolumn.png
3 Balance Sheet Standard.png
4 test-balancesheet-multicolumn.gnucash (XML)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1 General Journal.png
Type: image/png
Size: 54177 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20260528/06c8a1c0/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3 Balance Sheet Standard.png
Type: image/png
Size: 40554 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20260528/06c8a1c0/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2 Balance Sheet Multicolumn.png
Type: image/png
Size: 44711 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20260528/06c8a1c0/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-balsheet-multicolumn.gnucash
Type: application/octet-stream
Size: 43176 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20260528/06c8a1c0/attachment-0001.obj>