Same question here -- I take it this makes more sense for investment 
accounts and atypical currencies, but I don't see how it makes sense for 
(e.g.) USD when asserting conformance to a bank account statement. Further 
nonintuitive behavior is that if you enter a balance assertion at a whole 
number and don't add any decimal places, it is automatically set to zero 
tolerance, that is:

2021-01-01 * "Initial transaction"
    Assets:Cash              0.49 USD
    Income:Other

2021-01-02 balance Assets:Cash  0.50 USD ; passes

2021-01-02 * "second transaction"
    Assets:Cash              0.50 USD
    Income:Other

2021-01-03 balance Assets:Cash  1 USD ; fails

I think I will probably be inputting/importing my future bank statement 
balance assertions with explicit zero tolerance (0.50~0 USD).

On Tuesday, August 3, 2021 at 11:37:47 AM UTC-4 Taylor Corum wrote:

>
> Hello,
>
> According to what I have read in the docs (
> https://beancount.github.io/docs/precision_tolerances.html#balance-assertions-padding),
>  
> on balance assertions "The tolerance is inferred automatically to be 1 unit 
> of the least significant digit of the number on the balance assertion." The 
> tolerance on regular transactions appears to be half of that.
>
> What is the rational for inferring the tolerance to 1 unit of the least 
> significant digit rather than half that much? This seems a little 
> unintuitive to me and I would like to make sure I understand. For example 
> the following balance assertion would pass even though it is off by one 
> cent.
>
> 2021-01-01 * "Initial transaction"
>     Assets:Cash              0.49 USD
>     Equity:Opening-Balances
>
> 2021-01-02 balance Assets:Cash  0.50 USD
>
> Is it best practice to use balance assertions with a higher degree of 
> precision than the base currency or to explicitly give a tolerance on each 
> assertion?
>
> Thank you for your help.
>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/beancount/c2506461-29b2-405f-80d4-4a69cfbfac74n%40googlegroups.com.

Reply via email to