Resetting income/expense accounts to zero yearly..

[Marius Kjeldahl]

As party of yearly reporting (for a business), the yearly result is typically transferred to the proper balance accounts before a new year starts, so all the non-balance accounts typically start at zero each year.

I see at least two options;

1. Create the proper postings to zero out each individual account individually

2. Have a separate ledger file per year, where only the balance accounts (after transferring the yearly result to the proper balance accounts) gets transfer as part of the ingoing balance

How do the rest of you do this, and/or what's the recommended way with ledger?

Thanks,

Marius K.

[Martin Blais]

In Beancount I take a differnent stance on this: You should never have to enter transactions to transfer net income to equity. This is something the software should be able to do for you, and to be prepared to do so at any point in time, so that you can correct errors made in past data entry and the correct transfer should automatically follow. 

FWIW, I call this operation "clear" (I need a better name I admit) and provide capability in the query interface to do this. In the web interface, the per-year views automatically do this at the end date to generate balance sheets.

[Rick F]

I do both, but I agree I wish it were simpler.

For each year, in addition to the operating ledger file I have an opening and a closing ledger file.  The opening file establishes the opening balances for balance accounts and is included by the operating file.  The closing file includes the operating file and the transactions needed to close out the operating accounts for the year.

Keeping the files separate allows me to sanity check the whole system.  A trial balance on the opening file for one year should be identical to the closing file for the prior year.  If someone has gone in and monkeyed with any of the prior year's ledger files, the two will not agree.  By keeping the closing transactions in a separate file from the operating ledger, I can do queries on income and expenses for a prior year.  If I run the same report on the closing file, all those queries would come up zero.

Yes, this is a bit of a kludge, but it does what you need it to do.  You could also do this all with a single file and some carefully crafted tags and queries but this system seems much easier.  Perhaps ledger could be extended with some concept of opening and closing books to simplify building queries, but until then this seems the simplest way to do it.

Ledger is not without nice features to support this, however.  Using your list of accounts you can write many of your closing transactions as:

2014/12/31  Closing 2014 Expenses
  Expenses:Interest  =$0.00
  Expenses:Rent  =$0.00
 ...
  Equity:Retained Earnings:Expenses

Unfortunately this breaks down if you have accounts with transactions in multiple currencies.  From memory, I seem to recall there being problems as well if I try to zero out an already zero account.

Some enhancements would greatly simplify this:

1. A unitless "=0" should generate register entries that zero out all currencies held in that account
   
1. Subfeature: Zeroing out only one currency should only zero out that currency in the account
2. Zeroing a parent account should generate transactions to zero out all sub-accounts.
1. Subfeature: I suppose you could extend this so that any assignment would be applied the same to each subaccount, but I don't see the usefulness in that for values other than zero.  For example, if I assigned Expenses =$1, expenses would end up with not $1, but $1 for each subaccount.
3. No transaction should be generated for an account that is already zeroed.
4. Allow already zeroed accounts to be zeroed without generating a register entry.
1. Subfeature: If there are no other entries in a given transaction except the balancing entry, also don't generate a register entry.

Closing out the year would then be as simple as:

2014/12/31  Closing 2014 Expenses
  Expenses  =0
  Equity:Retained Earnings:Expenses


2014/12/31  Closing 2014 Income
  Income  =0
  Equity:Retained Earnings:Income

Maybe this could be done using the python interface...

[Simon Michael]

On 5/31/15 4:37 AM, Marius Kjeldahl wrote:
> How do the rest of you do this, and/or what's the recommended way with
> ledger?

I have one journal file per year. I started this for performance reasons
but it has some other advantages: increased isolation (it's harder to
accidentally mess up old data) and information hiding (less data in my
face when I'm editing).

As the last entry of the year, I post the required amount to each asset
and liability account to bring them all to 0 ("closing balances"). At
the start of the next year's file, I put the same entry with the signs
flipped ("opening balances"). I use hledger's equity command (similar to
ledger's) to generate these.

The closing and opening entries at each year transition cancel each
other out, so I see the correct asset/liability balances regardless of
whether I am reporting on multiple files or just one. I use all.journal
which includes all years, when I want to see a lot of history.

I don't bother zeroing income/expense/equity accounts, or folding them
back into assets/liabilities the way (I believe) accountants do. I am
probably missing an opportunity for error-checking here, that I don't
understand yet. An upside of not zeroing them is I can easily see their
total across multiple years.

This isn't perfect, it's just how I've been doing it for a few years.

[Martin Blais]

On Fri, Jun 12, 2015 at 5:25 PM, Simon Michael <si...@joyful.com> wrote:

On 5/31/15 4:37 AM, Marius Kjeldahl wrote:
> How do the rest of you do this, and/or what's the recommended way with
> ledger?

I have one journal file per year. I started this for performance reasons

How many transactions do you have?

How long would it take to process the whole thing every time?

I can't imagine it's much more than one second.

 

but it has some other advantages: increased isolation (it's harder to
accidentally mess up old data) and information hiding (less data in my
face when I'm editing).

Messing up old data should be fine if you have sufficient balance assertions.

The balance assertions are your guardrails.

And what accidents are you concerned about? I use revision control to maintain my text file. It should be obvious to review past changes and reverse them if needed. To me this is part of the beauty of using text files.

As the last entry of the year, I post the required amount to each asset
and liability account to bring them all to 0 ("closing balances"). At
the start of the next year's file, I put the same entry with the signs
flipped ("opening balances"). I use hledger's equity command (similar to
ledger's) to generate these.

Splitting up the input into multiple files should not require having to close the year. These are two separate concerns. 

You could replace those with balance checks (you could probably generate these from your program and copy them back into the file after eyeballing and verifying them), if you want some confidence changing the past doesn't break the future.

The closing and opening entries at each year transition cancel each
other out, so I see the correct asset/liability balances regardless of
whether I am reporting on multiple files or just one. I use all.journal
which includes all years, when I want to see a lot of history.

What if you wanted to do that quarterly? What about on an odd date?

All that's needed to support arbitrary closing dates is to have some routine that for each income statement account posts a transaction that moves the balance to equity (and thus to zero). Generating those transactions is trivial; I've done this, I can attest to it, you will be surprised to discover how easy it is to add. Add this to HLedger.

There's no reason we should be closing periods manually. We have computers.

I don't bother zeroing income/expense/equity accounts, or folding them
back into assets/liabilities the way (I believe) accountants do.

This is only done to draw a balance sheet with an equity section that balances assets & liabilities.

The fact that it's not dynamic is only a consequence of not having the technology to do so.

We have the technology now.

Why even bother sticking with this antiquated way of doing things?

 

I am
probably missing an opportunity for error-checking here, that I don't
understand yet. An upside of not zeroing them is I can easily see their
total across multiple years.

You should want to be able to see their balance for arbitrary periods of time, on demand, across years or any other time boundary.

In fact, I think NOT having these year closing transactions makes things simpler. If you generate journals across these boundaries these offsetting transactions might show up in your journal (lest you do something special to remove them). 

You don't need to impose a specific time boundary or order; the time boundaries are just a function of the reports you need to generate. The transfers are only useful to generate reports.

This isn't perfect, it's just how I've been doing it for a few years.

--

---
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.

[Nathan Grigg]

Related to the current thread, but slightly tangential:

Sometimes I've felt the need for balance assertions for Income/Expense accounts, but I've been discouraged by the fact that the balance of these accounts is not meaningful without specifying a period.

In short, it would be convenient to have year-to-date balance assertions on Income and Expense accounts. For example, reports from my employer's payroll and from my health insurance include year-to-date totals that I could use to ensure I'm not missing transactions.

Nathan

[Martin Blais]

The feature I thought for this is the ability to add an assertion over an arbitrary period of time.

This is related to budgeting, to some extent.

For example, you should be able to say "assert that between this date and that date the balance changes by at least/at most/exactly this much", e.g.

  2014-04-30 balance since 2014-04-01   Expenses:Restaurant   <600.00 USD

I think Ledger can already do this if I recall, via an expression?

[Chris Bennett]

> The feature I thought for this is the ability to add an assertion over an
> arbitrary period of time.
> This is related to budgeting, to some extent.
> For example, you should be able to say "assert that between this date and
> that date the balance changes by at least/at most/exactly this much", e.g.
>
> 2014-04-30 balance since 2014-04-01 Expenses:Restaurant <600.00 USD
>
> I think Ledger can already do this if I recall, via an expression?

Did anything come of us this for beancount, or a way of expressing
this in ledger?

This is exactly what I'm attempting to do to improve the integrity of
my quarterly & annual ledger files for personal & business activity,
whilst refactoring the parts of my account structure I'm not happy
about :)

Regards,

Chris

[Michael Norrish]

Have separate Income:2016, Income:2015 etc accounts?

Michael

[Martin Blais]

On Fri, Feb 12, 2016 at 8:53 PM, Chris Bennett <ch...@ceegeebee.com> wrote:

> The feature I thought for this is the ability to add an assertion over an
> arbitrary period of time.
> This is related to budgeting, to some extent.
> For example, you should be able to say "assert that between this date and
> that date the balance changes by at least/at most/exactly this much", e.g.
>
>   2014-04-30 balance since 2014-04-01   Expenses:Restaurant   <600.00 USD
>
> I think Ledger can already do this if I recall, via an expression?

Did anything come of us this for beancount, or a way of expressing
this in ledger?

In Beancount, not done yet.

If you feel taking a shot at it:

The grammar would need some extension to handle some new syntax goodness, here:

https://bitbucket.org/blais/beancount/src/b71424fdefe87d2019180b67329109161e7a77e8/src/python/beancount/parser/grammar.y?at=default&fileviewer=file-view-default

And in its handlers called back on the Python side:

https://bitbucket.org/blais/beancount/src/b71424fdefe87d2019180b67329109161e7a77e8/src/python/beancount/parser/grammar.py?at=default&fileviewer=file-view-default

The data object it produces is here:

https://bitbucket.org/blais/beancount/src/b71424fdefe87d2019180b67329109161e7a77e8/src/python/beancount/core/data.py?at=default&fileviewer=file-view-default#data.py-105

Here's where the check is for the simple equality version, which would need to handle inequalities:

https://bitbucket.org/blais/beancount/src/b71424fdefe87d2019180b67329109161e7a77e8/src/python/beancount/ops/balance.py?at=default&fileviewer=file-view-default#balance.py-58

In Ledger, no idea, but I think it's already there through some of the generalized expressions.

This is exactly what I'm attempting to do to improve the integrity of
my quarterly & annual ledger files for personal & business activity,
whilst refactoring the parts of my account structure I'm not happy
about :)

I love it

 

Regards,

Chris

--
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/20160213015333.GA19207%40cgb-linux.rcmb.lan.