Rounding errors from Betterment ETF transactions

[Jason Chu]

I've decided to track the actual transactions from my Betterment investments taken from my quarterly statements.  It seems their PDFs have all the data I should need and it's copyable text, so that's kind of nice.

They include both the transactions themselves as well as the quarterly balances.  The problem is the precision of the PDF isn't high enough.  The PDF lists three digits after the decimal place (6.703 MUB), but after a few transactions (usually when a particular ETF is tax-loss harversted and it's sold off entirely), I have found cases where I'm missing up to 0.002 units.

How would you recommend I handle this?

[Martin Blais]

Not fun.

Two ways to mitigate this:

1. There is an experimental feature you can turn on with an option that allows you to override the tolerance for balance checks with an amount like 2300.87 ~ 0.003 USD

2. You could book a loss explicitly to an account for the accumulated difference and get rid of it.

Neither solution is great.

--
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 post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/2bfdfda9-b93a-40f3-97e7-0a39a83e421f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stefano Zacchiroli]

On Wed, Jan 06, 2016 at 03:00:56PM +0000, Martin Blais wrote:
> Not fun.

I've the same issue with my home banking service and a few investments.
It's indeed not fun, and the only answer I ever got from the customer
service is, in essence, *shrug*.

> 1. There is an experimental feature you can turn on with an option
> that allows you to override the tolerance for balance checks with an
> amount like 2300.87 ~ 0.003 USD
>
> 2. You could book a loss explicitly to an account for the accumulated
> difference and get rid of it.

I'm doing (2). I'm still on Ledger and I don't know if it supports (1).
But I'd probably prefer (2) anyway because it makes explicit in the
books that there has been a precision error elsewhere (and not in your
books). YMMV.

Cheers.
--
Stefano Zacchiroli . . . . . . . za...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[redst...@gmail.com]

On Wednesday, January 6, 2016 at 7:29:28 AM UTC-8, Stefano Zacchiroli wrote:

> 2. You could book a loss explicitly to an account for the accumulated
> difference and get rid of it.

I'm doing (2). I'm still on Ledger and I don't know if it supports (1).
But I'd probably prefer (2) anyway because it makes explicit in the
books that there has been a precision error elsewhere (and not in your
books). YMMV.

Yep, I have the same problem too in several instances, and use (2) as well for the explicitness. I book it to an Equity:Rounding-Error account, which seems most appropriate (as it's neither income nor an expense), which also has the nice effect of not polluting my income/expense accounts.

Ironically, an institution I have records for supplied 3-digit precision in their .csv files, and 4-digits in their .pdf file (much harder to parse)!

[Stefano Zacchiroli]

On Thu, Jan 07, 2016 at 05:50:23PM -0800, redst...@gmail.com wrote:
> > I'm doing (2). I'm still on Ledger and I don't know if it supports
> > (1). But I'd probably prefer (2) anyway because it makes explicit
> > in the books that there has been a precision error elsewhere (and
> > not in your books). YMMV.
>
> Yep, I have the same problem too in several instances, and use (2) as well
> for the explicitness. I book it to an Equity:Rounding-Error account, which
> seems most appropriate (as it's neither income nor an expense), which also
> has the nice effect of not polluting my income/expense accounts.

Ah, interesting idea. Right now I book adjustments under either Expenses
or Income, depending on whether they are "profits" or "losses", but I
certainly don't like having to decide that each time. Is posting under
Equity the generally accepted best practice here, or are there other
options?

A drawback I can see in posting under Equity is that when you produce an
income statement (which I usually obtain by filtering on Income +
Expenses), it will be a little bit off w.r.t. reality.

> Ironically, an institution I have records for supplied 3-digit
> precision in their .csv files, and 4-digits in their .pdf file (much
> harder to parse)!

Gah, that sucks :-/

[redst...@gmail.com]

On Thursday, January 7, 2016 at 11:28:15 PM UTC-8, Stefano Zacchiroli wrote:

On Thu, Jan 07, 2016 at 05:50:23PM -0800, redst...@gmail.com wrote:
> > I'm doing (2). I'm still on Ledger and I don't know if it supports
> > (1).  But I'd probably prefer (2) anyway because it makes explicit
> > in the books that there has been a precision error elsewhere (and
> > not in your books). YMMV.
>
> Yep, I have the same problem too in several instances, and use (2) as well
> for the explicitness. I book it to an Equity:Rounding-Error account, which
> seems most appropriate (as it's neither income nor an expense), which also
> has the nice effect of not polluting my income/expense accounts.

Ah, interesting idea. Right now I book adjustments under either Expenses
or Income, depending on whether they are "profits" or "losses", but I
certainly don't like having to decide that each time.  Is posting under
Equity the generally accepted best practice here, or are there other
options?

A drawback I can see in posting under Equity is that when you produce an
income statement (which I usually obtain by filtering on Income +
Expenses), it will be a little bit off w.r.t. reality. 

This is true. The reality is, the original input is not correct, so you'll have to take a hit somewhere. My personal tradeoff is to live with the rounding error (literally :)), rather than have it show up under my Income or Expenses. I don't know what the accepted best practice is, but this works out well for me.

I think this depends somewhat on the types of queries you tend to run, what you compare, and on your input as well. For example, if you need your income to be accurate because you compare that against your institution, and Income: is your commodities originate, you might be better of booking the error back to it. For me, the commodities originate primarily in purchases, so things would be off wrt reality if I booked to an Income account.

On a related note, I'm careful to always explicitly book the exact amount (rather than elide) in question to the Equity account, either manually or through my importers. Else, I might end up missing a larger amount in the Equity account and not notice since I rarely tend to examine the Equity account. I've considered writing a plugin that checks each posting in Equity:Rounding-Errors to ensure they don't exceed a very small amounts.

[Daniël Bos]

I do exactly the same, book it as Equity:Rounding-Error. I don't know
if it's standard practice, but since it's neither Income, nor Expense
in my mind, so Equity is the natural place for it to go.
Alternatively, you could "make up" the extra precision in the original
bookings to make the rounding error go away, but that doesn't seem
like an improvement to me :-)

> --
> 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 post to this group, send email to bean...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/beancount/37fd726c-0d54-44cb-bdda-2282fb2f2e3c%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Best regards,
Daniël Bos


Your government is reading your email. Slow them down with encryption.

My public key: http://goo.gl/gms497 (4096 bit RSA, id EF2D5D91)
Fingerprint : D8D0 9FBE F075 F709 7B52 2F73 326C 2123 EF2D 5D91

[Martin Blais]

Both the ideas of

- a plugin that doesn't allow you to elide amounts / use auto-postings

- a plugin that caps the allowable amount of postable to some account, e.g. Equity:Rounding-Error

seems useful to me, and in-line with the agenda of building a pedantic system detecting unexpected inputs.

(Note: The first one would need to be a built-in one, because it has to collaborate with the interpolation code so that it leaves a trace of having interpolated for the plugin to detect it. Interpolation happens before plugins run.)