Balance assertion for a top level account

[Chris Bennett]

Hi there,

I use assertions for account statements, opening & closing balances
etc.

I have quarterly reporting requirements for my business and would like
to add some additional assertions for some of the top level accounts
(Expenses, Income). I don't seem to be able to make this work.

In a test file:

2015/10/01 Light Refreshments
MyCompany:Expenses:LightRefreshments $4.55
MyCompany:Liabilities:AP:LightRefreshments


$ ledger -f test.ledger bal
0 MyCompany
$4.55 Expenses:LightRefreshments
$-4.55 Liabilities:AP:LightRefreshments
--------------------
0

$ ledger -f test.ledger bal ^MyCompany:Expenses --depth 2
$4.55 MyCompany:Expenses


But when I assert a balance for the Expense account, it errors:

2015/12/31 MyCompany:Expenses closing balance
MyCompany:Expenses $0.00 = $4.55
Equity:Dummy


$ ledger -f test.ledger bal
While parsing posting:
MyCompany:Expenses $0.00 = $4.55
^^^^^
Error: Balance assertion off by $4.55

I remember this coming up in the ML in the past, but can't find a
reference. I want to refactor some of my accounts & transactions, but
want to avoid breaking the resultant value for top level accounts
(since the data has already been reported to the government and I
don't want that to change by my refactoring :)).

Any suggestions on how to do what I want?

Thanks,

Chris

[Ben Finney]

Chris Bennett <ch...@ceegeebee.com> writes:

> But when I assert a balance for the Expense account, it errors:
>
> 2015/12/31 MyCompany:Expenses closing balance
> MyCompany:Expenses $0.00 = $4.55
> Equity:Dummy
>
>
> $ ledger -f test.ledger bal
> While parsing posting:
> MyCompany:Expenses $0.00 = $4.55
> ^^^^^
> Error: Balance assertion off by $4.55

Yes. You're asserting “After this transaction that moves $0.00, the
balance should be $4.55”.

I think instead you want::

2015/10/01 Light Refreshments
MyCompany:Expenses:LightRefreshments $4.55
MyCompany:Liabilities:AP:LightRefreshments

2015/12/31 MyCompany:Expenses closing balance

MyCompany:Expenses $4.55 = $0.00
Equity:Dummy

The second asserts “After this transaction which moves $4.55, the
balance should be $0.00”.

$ ledger -f ~/Documents/finance/foo.ledger balance
$-4.55 Equity:Dummy
$4.55 MyCompany
$9.10 Expenses
$4.55 LightRefreshments

$-4.55 Liabilities:AP:LightRefreshments
--------------------
0

But maybe instead you have a mistake in which transactions you specify
for the transactions?

--
\ “Don't worry about people stealing your ideas. If your ideas |
`\ are any good, you'll have to ram them down people's throats.” |
_o__) —Howard Aiken |
Ben Finney

[Ben Finney]

Ben Finney <ben+l...@benfinney.id.au> writes:

> Chris Bennett <ch...@ceegeebee.com> writes:
>
> > 2015/12/31 MyCompany:Expenses closing balance
> > MyCompany:Expenses $0.00 = $4.55
> > Equity:Dummy
>

> You're asserting “After this transaction that moves $0.00, the balance
> should be $4.55”.

My understanding of this is informed by the Ledger 3 documentation
<URL:http://ledger-cli.org/3.0/doc/ledger3.html#Balance-verification>,
maybe you could explain in those terms what you expect to happen?

--
\ “There's a certain part of the contented majority who love |
`\ anybody who is worth a billion dollars.” —John Kenneth |
_o__) Galbraith, 1992-05-23 |
Ben Finney

[Chris Bennett]

Hi Ben,

Thanks for your reply.

> Yes. You're asserting ???After this transaction that moves $0.00, the
> balance should be $4.55???.

Yep, that's how I've been using that expression for beginning and end
of statement balance assertions, to pre & post declare what the
balance must be at beginning and end of the specified transactions.

ledger3.pdf that I have on hand says:
6.10.1 Balance assertions
[..]
Assets:Cash $-20.00 = $500.00

This simply asserts that after subtracting $20.00 from Assets:Cash,
that the resulting total matches $500.00. If not, it is an error.

> $9.10 Expenses

The reversal of values for the balance assertion in your example has
doubled the value of Expenses :(

My example works if I specify the leaf account name for the assertion,
but not anything higher.

Thanks,

Chris

[Chris Bennett]

> I remember this coming up in the ML in the past, but can't find a
> reference. I want to refactor some of my accounts & transactions, but
> want to avoid breaking the resultant value for top level accounts
> (since the data has already been reported to the government and I
> don't want that to change by my refactoring :)).

Just wondering if anyone had ideas on how I can maintain consistency
at the top level accounts for amount, whilst refactoring transactions
amongst the lower level accounts in the hierarchy?

Thanks,

Chris

[Martin Blais]

In Beancount balance assertions apply to parent accounts for the total balance of the parent & all its children accounts.

(Like for leaf accounts, the balance is checked for each commodity, i.e., it's not a total balance check.)

My main use for this is in a 401k account where the OFX download provides the total number of shares broken down by fund type for the entire account, but I have to maintain separate subaccounts by source (e.g. pre-tax, match, after-tax, rollover).

I'm not sure what how Ledger handles balances for parent accounts, would love to hear how it works.

 

[John Wiegley]

>>>>> Martin Blais <bl...@furius.ca> writes:

> I'm not sure what how Ledger handles balances for parent accounts, would
> love to hear how it works.

You could use a general assert with a value expression:

assert account("Expenses").total == $0.00

"total", as opposed to "amount", specifies the total sum of all child
accounts, include anything in the given account itself.

--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2

[Chris Bennett]

Hi John,

> You could use a general assert with a value expression:
>
> assert account("Expenses").total == $0.00
>
> "total", as opposed to "amount", specifies the total sum of all child
> accounts, include anything in the given account itself.

Thanks, that works.

However I found a problem with my particular dataset. I use automated
transactions to reduce the posted amount by a GST percent.

Assertions (both balance and assert) appear to apply prior to calculation
of automated transactions. e.g.

https://gist.github.com/cgb/eceeff1743e76d3e6de6

Is there any way to change this behaviour? I may have to revert my
use of automated transactions (which I'd been thinking of doing anyway
to make my files clearer) but it would be good to toggle this
behaviour.

Thanks,

Chris

[John Wiegley]

>>>>> Chris Bennett <ch...@ceegeebee.com> writes:

> Assertions (both balance and assert) appear to apply prior to calculation of
> automated transactions. e.g.

The related automated transactions should be applied before the assertion,
since they are computed "as we parse". That it's not happening sounds like a
bug to me, since it certainly could affect balances through the use of
unbalancing virtual postings.

[Chris Bennett]

> The related automated transactions should be applied before the assertion,
> since they are computed "as we parse". That it's not happening sounds like a
> bug to me, since it certainly could affect balances through the use of
> unbalancing virtual postings.

I've ended up using asserts as metadata in comments, and then wrote a
wrapper to parse the assert (account, value), run ledger and parse
what it thinks the balance is, and warn me when they are not equal.
This has worked well as I have a ledger file per quarter for each of
income & expenses, so running ledger against each individual file
ensures I don't have issues with increasing balances per quarter.

Ugly but it's met my need for beginning refactoring :) Thanks again
for your responses.

Regards,

Chris

[Pascal Fleury]

On Sun, Feb 14, 2016 at 3:52 AM, John Wiegley <jo...@newartisans.com> wrote:

>>>>> Chris Bennett <ch...@ceegeebee.com> writes:

> Assertions (both balance and assert) appear to apply prior to calculation of
> automated transactions. e.g.

The related automated transactions should be applied before the assertion,
since they are computed "as we parse".  That it's not happening sounds like a
bug to me, since it certainly could affect balances through the use of
unbalancing virtual postings.

I also noticed that balance assertions that are out-of-order (i.e. not in chronological order) will also fail. If the file is then sorted (I use ledger-mode) and the transactions are in the right place when looking at the dates, then the assertion become valid.

It sounds like it is coming from the same issue of computing the assertions as it is parsing ?

--paf

 

--
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

--

---
You received this message because you are subscribed to the Google Groups "Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.