Balancing in all possible units

[Mark Lodato]

Hi Martin,

I am starting to use beancount and am finding the balancing to be a bit troublesome. Any thoughts on implementing my suggestion below?

The documentation mentions "peculiarities in Vanguard investment accounts whereby rounding appears to follow odd rules and balances don’t match." But in reality Vanguard follows a simple algorithm. The only difference is that Vanguard performs the computation in units of the commodity being converted to (i.e. the posting with a positive amount) whereas Beancount always uses the commodity of the cost (USD).

Let's take a real-world example:

2009-09-14 * "Buy"
  Assets:Checking        -3,331.23  USD              
  Assets:Vanguard:VTSMX     128.174 VTSMX {25.99 USD}

This fails with error:

Transaction does not balance: (0.01226 USD)

But it does balance.  Vanguard computed 3,331.23 USD / 25.99 USD/VTSMX = 128.173528... and rounded to 128.174.

A (seemingly) simple solution is to perform the computation in all commodities involved and accept if any sum is within the precision tolerance. So in my example:

- Fail in USD

  - Posting 1: -3,331.23 USD

  - Posting 2: 3,331.24226 USD (= 128.174 * 25.99)

  - Sum: 0.01226 USD > 0.005 USD (fail)

- Pass in VTSMX

  - Posting 1: -128.173528 VTSMX (= -3,331.23 / 25.99)

  - Posting 2: 128.174 VTSMX

  - Sum: 0.0004717 VTSMX < 0.0005 VTSMX (pass)

What do you think? Would it make sense for beancount to use this modified algorithm?

Thanks!

Mark

[Martin Blais]

Thanks Mark for the well-written question.

I'm not sure if this relaxation always makes sense (e.g. for currencies), but it certainly seems like it would be sensible for investment commodities like this.

I'd want the default to be full precision and only when you override the tolerance for VTSMX would it take effect (and relax the check).

The real problem is that in general there's no balance check on the units, only on the "weight" of each posting.

While in your simple example it seems trivial to compute the sum of the VTSMX equivalents, in general (> 2 postings, some in other currencies, etc.) it's not something that's already being calculated, and that's probably not an easy addition.

Maybe we can come up with some other heuristic to relax the tolerance in terms of USD, so that the maximum of a list of tolerance values (in USD) gets used in the current check. I'd be inclined to consider even a per-transaction override.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAHREChgep_7vkV2tEJqphM9oK3zsArA6yD4%3D5pBT-UdGNAL1mg%40mail.gmail.com.

[Justus Pendleton]

On Wednesday, February 12, 2020 at 11:50:02 AM UTC+7, Martin Blais wrote:

Maybe we can come up with some other heuristic to relax the tolerance in terms of USD, so that the maximum of a list of tolerance values (in USD) gets used in the current check. I'd be inclined to consider even a per-transaction override.

Some kind of per-transaction flag seems closer to the new (not yet implemented) spirit of "less magic precision/rounding heuristics in beancount". Maybe some kind of per-account flag would work? Hmm, that seems problematic. What if two accounts have differing flags (imagine a world with four or five different balancing strategies for different weird scenarios, tax regimes, currencies, whatver), which one gets used? Seems like you'd need to *also* support a per-transaction flag to disambiguate situations like that.

[Martin Blais]

I still wish for a general rule...

 

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/49e60bea-fa13-419c-bcf0-45df7510a17e%40googlegroups.com.

[lod...@gmail.com]

On Tuesday, February 11, 2020 at 11:50:02 PM UTC-5, Martin Blais wrote:

Thanks Mark for the well-written question.

I'm not sure if this relaxation always makes sense (e.g. for currencies), but it certainly seems like it would be sensible for investment commodities like this.

I'd want the default to be full precision and only when you override the tolerance for VTSMX would it take effect (and relax the check).

The real problem is that in general there's no balance check on the units, only on the "weight" of each posting.

While in your simple example it seems trivial to compute the sum of the VTSMX equivalents, in general (> 2 postings, some in other currencies, etc.) it's not something that's already being calculated, and that's probably not an easy addition.

Maybe we can come up with some other heuristic to relax the tolerance in terms of USD, so that the maximum of a list of tolerance values (in USD) gets used in the current check. I'd be inclined to consider even a per-transaction override.

Actually it ends up that this feature already exists! The "infer_tolerance_from_cost" option has exactly the same effect as what I proposed, except it does it using the currency of the cost/price. I found this when trying to implement it myself. :)

...but...

That said, I now believe that my original transaction was wrong. The cost basis was not "25.99 USD per share" but simply "3,331.23 USD for 128.174 units". From the IRS's perspective, if I later sell the entire lot, the cost basis should be precisely 3,331.23 USD, not 3,331.24226 USD. If I were to sell 100 units, the cost of those 100 units would be round((3,331.23 USD / 128.174) * 100, 2) = 2,598.99 USD, and the remaining cost would be 3,331.23 - 2,598.99 = "732.24 USD for 28.174 units". There is a bogleheads thread about this.

In other words, the rounding is an immediate unrealized capital gain or loss.

That said, it sounds like Vanguard may not keep track of the cost basis as a 2-tuple (units, cost) but rather as a cost-per-share rounded (or truncated?) to 4 (or 5?) decimal places. So, if I want to match Vanguard's 1099-B, it sounds like I should use the following:

2009-09-14 * "Buy"
  Assets:Checking        -3,331.23  USD              

  Assets:Vanguard:VTSMX     128.174 VTSMX {25.9899 USD}

This indeed balances. No need for the "infer_tolerance_from_cost" option. So that is what I'll do. I'll let you know how it works out; it'll take me some time.

I'd also be interested to hear if anyone else has figured this out or if I am incorrect.

[Mark Lodato]

Upon further reading, it seems that rounding error should be considered one type of "commission," and beancount does not properly handle commissions as noted in the docs. There was a proposal to fix this from 2014, Inventory Booking Improvements. Has any progress been made on that front? In the meantime, how do beancount users keep track of the actual, taxable capital gains?

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/B2hxF6N7y6s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/ce48b65a-7e09-44ed-b7c7-aafc16937b90%40googlegroups.com.

[Justus Pendleton]

On Monday, February 17, 2020 at 3:19:36 AM UTC+7, Mark Lodato wrote:

Upon further reading, it seems that rounding error should be considered one type of "commission," and beancount does not properly handle commissions as noted in the docs. There was a proposal to fix this from 2014, Inventory Booking Improvements. Has any progress been made on that front? In the meantime, how do beancount users keep track of the actual, taxable capital gains?

I don't think Martin has had time for a while for any sweeping changes like that.

In practice? People do....

a) Use brokers that don't charge commissions.

b) Live with beancount being wrong and rely on your 1099 instead

c) Do manual stuff outside of beancount, i.e. export things to a spreadsheet.