'equity' cannot accept virtual and non-virtual postings to the same account

[Jostein Berntsen]

Is there a reason for this?

Example data:

2014/03/05 * Opening Balance
Assets:Project:Budget 1000000,00 NOK

Equity:Opening Balance

= /TeamDev/
(Assets:Project:Budget) (1000,00 NOK * amount)

Example command and output:

ledger reg -s budget
While handling posting from
"/home/jostein/Documents/Finans/ledger/project.dat", line 16:
> (Assets:Project:Budget) (1000,00 NOK * amount)
Error: 'equity' cannot accept virtual and non-virtual postings to the same
account




Jostein

[John Wiegley]

>>>>> Jostein Berntsen <jbe...@broadpark.no> writes:

> Is there a reason for this?

This sounds rather odd, and may be a bug.

John

[Martin Blais]

Really? This surprises me. I read this as a reasonable assumption and looked up the Ledger doc for it but could not find it.

It makes sense to me that one may want to restrict balancing transactions to accounts with no virtual transactions at all and vice-versa, segregating accounts by whether their transactions are all virtual or none at all. Otherwise the accounting equation is not guaranteed to sum to zero! How do these virtual postings get handled when you transfer net-income to equity for drawing out a balance sheet?

In Beancount 2.0 I removed virtual postings for that reason, and also because their availability always pointed me to a misuse of how I booked many of my transactions, in most instances I was using virtual accounts as a crutch. By not having them, it forced me to get creative and figure out how to book my Ledger right, and now they're mostly superfluous (at least my use case, I claim you don't need them). I'm thinking about reintroducing something like them eventually: a Virtual:* account hierarchy separate from Assets/Liabilities/Equity/Income/Expenses that would not go into the accounting equation nor get balance checks (no special syntax except for the Virtual: prefix). In other words, instead of virtual POSTINGS, you would have virtual ACCOUNTS, and it would be understood that those accumulators don't participate in the accounting equation, they're there to count other things. In fact, they could be a great way for plugins to automatically calculate and present various values without disrupting the user's DE transactions.

Any thoughts?

--

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

[Lifepillar]

In article
<CAK21+hP9ZP05erD8fHKKQTX-...@mail.gmail.com>,

@Jostein: I have concluded some time ago that keeping virtual and
non-virtual accounts distinct is a best practice (good tip for
LedgerTips?). This can be easily achieved without much inconvenience by
using two accounts sharing a common prefix instead of one account.

I think that Ledger's behavior is not only a reasonable assumption, but
a requirement: I can't recall the details off the top of my head (maybe
someone else will help), but I'm pretty sure that creating equity
reports is a use case that *requires* separate virtual and non-virtual
accounts to avoid ambiguities.

@Martin: I use virtual accounts sparingly, but there are situations
where they are logically necessary. Keeping in mind that I am not an
accountant, consider the following example: an employee in the public
sector gets a salary that is taxed in advance. He may get a monthly
statement with the following information:

Gross income: $5200
Family allowance (tax-exempt): $100
Taxes: $1700
Net income: $3500

The net income is the money that he eventually gets in the bank. He may
keep track of this information as follows:

2013/05/17 * Myself
Assets:Checking:Myself $3500.00
Income:Salary:Family Allowance $-100.00
Income:Salary:Taxable:Net
[Expenses:Taxes:Salary] $1700.00
[Income:Salary:Taxable:Taxes] $-1700.00

Since the employee never really gets the taxed amount, I think that
those are conceptually virtual postings and must be treated as such.
What do you think?

Now, a balance report including virtual postings will show all the
details:

ledger bal myself income taxes

$3500.00 Assets:Checking:Myself
$1700.00 Expenses:Taxes:Salary
$-5200.00 Income:Salary
$-100.00 Family Allowance
$-5100.00 Taxable
$-3400.00 Net
$-1700.00 Taxes
--------------------
0

A balance report without virtual transactions will only show the net
income:

ledger bal myself income taxes --real

$3500.00 Assets:Checking:Myself
$-3500.00 Income:Salary
$-100.00 Family Allowance
$-3400.00 Taxable:Net
--------------------
0


Enjoy,
Life

[Harshad RJ]

On Sat, May 17, 2014 at 10:40 PM, Lifepillar <lifep...@lifepillar.com> wrote:

2013/05/17 * Myself
    Assets:Checking:Myself          $3500.00
    Income:Salary:Family Allowance  $-100.00
    Income:Salary:Taxable:Net
    [Expenses:Taxes:Salary]         $1700.00
    [Income:Salary:Taxable:Taxes]  $-1700.00

​Balanced virtual transactions can be implemented by using tags. Just add a tag say, virtual:salary.

I find tags a better solution for that case because they are more general.​ You can slice and dice them along many dimensions instead of just real v/s virtual.

--

Harshad RJ

[John Wiegley]

>>>>> Harshad RJ <harsh...@gmail.com> writes:

> ​Balanced virtual transactions can be implemented by using tags. Just add a
> tag say, virtual:salary.
>
> I find tags a better solution for that case because they are more general.​
> You can slice and dice them along many dimensions instead of just real v/s
> virtual.

There's no reason I couldn't infer a metadata tag from postings with a virtual
account. It could infer "Virtual: <account name>", for example, allowing you
to slice and dice using the tagging mechanism.

John

[Martin Blais]

One critical aspect of the DE method is that A + L + E + I + X = 0. If you allow transactions to break the rule (by allowing virtual postings to make arbitrary credits/debits to accounts with non-virtual postings) you lose that guarantee. Transferring NI to the equity accounts to draw a balance sheet at some point in time requires the equation to hold, that's one example. Same goes to summarizing past history (summarizing it with transactions to opening-balances). More fundamentally, the beauty of the DE method is that guarantee that if each of the transactions balances, groupings of them will do too.

I still don't see a way to integrate virtual postings within that framework, other than strictly segregating those virtual postings on their own and separate from the rest of the postings, or to filter out virtual postings before doing processing.

So I agree with you about keeping virtual and non-virtual distinct, but I'm not convinced yet that the system allowing you to break that rule is a wise decision.

 

@Martin: I use virtual accounts sparingly, but there are situations
where they are logically necessary.

You are providing an almost perfect example of how virtual transactions allow you to shoot yourself in the foot (detailed comments below).

Keeping in mind that I am not an
accountant, consider the following example: an employee in the public
sector gets a salary that is taxed in advance. 

He may get a monthly
statement with the following information:

Gross income: $5200
Family allowance (tax-exempt): $100
Taxes: $1700
Net income: $3500

The net income is the money that he eventually gets in the bank. He may
keep track of this information as follows:

2013/05/17 * Myself
    Assets:Checking:Myself          $3500.00
    Income:Salary:Family Allowance  $-100.00
    Income:Salary:Taxable:Net
    [Expenses:Taxes:Salary]         $1700.00
    [Income:Salary:Taxable:Taxes]  $-1700.00

Since the employee never really gets the taxed amount, I think that
those are conceptually virtual postings and must be treated as such.
What do you think?

I think in this case you're simply doing this wrong and you don't need virtual postings at all.

Here's how I would do this:

- Income counts the gross income amount ($5,200).

- Tax withholding (not just for govt accounts, BTW) is usually recorded as a regular (non-virtual) expense, that is, you received an expense of that corresponding amount that the government recorded in your name.

- Your non-taxable allowance can be tracked in a separate contra income account (that is, one with a positive amount). That's what I do for some of my deductions.

2013/05/16 * Myself

  Income:Employer:Salary   -5200.00 USD

  Income:Employer:Deductions:FamilyAllowance  100.00 USD

  Assets:Bank:Checking    3500.00 USD

  Expenses:Taxes:Salary          1700.00 USD

Your "net" income is simply the balance of the Income:Employer:Salary account - Expenses:Taxes:* accounts. You can write a query to calculate it.

Here's how I actually do this (from my Ledger, removed numbers, kept the signs):

2014-05-07 * "GOOGLE INC       PAYROLL" ^google-XXXXXXX
  Assets:US:MyBank:Checking                            XXXX.XX USD
  Income:US:Google:GroupTermLife                      -XXXX.XX USD
  Income:US:Google:Salary                             -XXXX.XX USD
  Income:US:Google:Deductions:Dental                   XXXX.XX USD
  Income:US:Google:Deductions:GroupTermLife            XXXX.XX USD
  Income:US:Google:Deductions:InternetReimbursement   -XXXX.XX USD
  Income:US:Google:Deductions:Medical                  XXXX.XX USD
  Income:US:Google:Deductions:TransitPreTax            XXXX.XX USD
  Income:US:Google:Deductions:Vision                   XXXX.XX USD
  Expenses:Taxes:US:Google:Tax:Medicare                XXXX.XX USD
  Expenses:Taxes:US:Google:Tax:Federal                 XXXX.XX USD
  Expenses:Taxes:US:Google:Tax:City                    XXXX.XX USD
  Expenses:Taxes:US:Google:Tax:SDI                     XXXX.XX USD
  Expenses:Taxes:US:Google:Tax:State                   XXXX.XX USD
  Expenses:Taxes:US:Google:Tax:SocSec                  XXXX.XX USD
  Assets:US:Google:Vacation                               X.XX VACHR
  Income:US:Google:Vacation                              -X.XX VACHR

I order the postings in the same order that they show up in the paystub so that it's easy to update new entries (I do this every couple of months, download the stubs and update my ledger).

No virtual postings.

Auxiliary note: One might argue that the tax withheld sitting at the government in an account with your name on it is an "Asset" account (one like that for each tax year), and that the expense only gets incurred at the time you make your tax filing for that year (e.g. the following April) that includes all your deductions and special situation (e.g. married status or not and everything that changes according to that), and that would work out as well, but the problem with using that approach is that your balance sheet, throughout the year, would reflect the taxes you are to pay later on (making your assets look inflated) and unless you would accompany it with a corresponding account payable liability account, that would be confusing. I prefer to account for taxes as an Expense, so that throughout the year my income statement includes a good approximation of what my tax expenses will turn out to be for that year (which is exactly what source withholding is supposed to be), and at the time of filing I make an adjustment on that same expenses account when I compute the exact amount.  

I'm starting to think that I should start creating a distinct expense account for each tax year, because that's how both the Canadian and US governments handle it: amounts that you post get booked to a particular year (I've had cases where I'd make a payment online and had to call them afterwards so they would move the amount to the right year bucket). This way I could track the sums owed _for each year_ and file the corresponding paper statements together by year and if there are adjustments to be made in future years (e.g. an audit, shit happens) then it would get booked correctly and I could still calculate my taxes/gross ratio correctly.

Thoughts?

 

Now, a balance report including virtual postings will show all the
details:

    ledger bal myself income taxes

            $3500.00  Assets:Checking:Myself
            $1700.00  Expenses:Taxes:Salary
           $-5200.00  Income:Salary
            $-100.00    Family Allowance
           $-5100.00    Taxable
           $-3400.00      Net
           $-1700.00      Taxes
--------------------
                   0

A balance report without virtual transactions will only show the net
income:

    ledger bal myself income taxes --real

            $3500.00  Assets:Checking:Myself
           $-3500.00  Income:Salary
            $-100.00    Family Allowance
           $-3400.00    Taxable:Net
--------------------
                   0


Enjoy,
Life

[Martin Blais]

That's also what I use when I need to slice and dice. For example, the Beancount web interface has a link for each tag, that allows you to view balance sheet, income statement, etc. for the subset of transactions with that tag (e.g. expenses during a trip or for a project).

Just to be clear, what you mean is having two transactions, one tagged and one untagged:

 2013/05/17 * Myself

    Assets:Checking:Myself          $3500.00
    Income:Salary:Family Allowance  $-100.00
    Income:Salary:Taxable:Net

2013/05/17 * Booking taxes  #taxes

    Expenses:Taxes:Salary         $1700.00
    Income:Salary:Taxable:Taxes  $-1700.00

so you could view summaries of the transactions including or excluding those with a #taxes tag. This has the advantage of not breaking the balancing rules.

[Jostein Berntsen]

For some reason these commands gives the right output:

ledger bal budget
ledger reg budget

But these give the error above:

ledger reg -s budget
ledger reg -M budget

My intention is to add hours like in the entry below to the Budget account
and calculated into a total cost in NOK. How is the best way to do this?

2014/04/17 Resource 1 - Week 16, 2014 Book
; Week16: 2014
; Resource1: John James
; TeamDev: Workshop and plannning
Allocation:Resources:TeamDev -15 H
Assets:Project:Budget


Jostein

[Martin Michlmayr]

* Lifepillar <lifep...@lifepillar.com> [2014-05-17 19:10]:

> consider the following example: an employee in the public sector
> gets a salary that is taxed in advance. He may get a monthly
> statement with the following information:

> Gross income: $5200
> Family allowance (tax-exempt): $100
> Taxes: $1700
> Net income: $3500

BTW, there's a calculation error here. Either net income should be
$3600 or taxes $1800. But that's a just a minor detail. I found your
example very interesting and illuminating.

> The net income is the money that he eventually gets in the bank. He may
> keep track of this information as follows:
>
> 2013/05/17 * Myself
> Assets:Checking:Myself $3500.00
> Income:Salary:Family Allowance $-100.00
> Income:Salary:Taxable:Net
> [Expenses:Taxes:Salary] $1700.00
> [Income:Salary:Taxable:Taxes] $-1700.00
>
> Since the employee never really gets the taxed amount, I think that
> those are conceptually virtual postings and must be treated as such.
> What do you think?

I don't see why they would be conceptually virtual postings. Sure,
tax is deducted at source but this is pretty normal and it's still tax
that *you* are paying (sure, your employer is deducting tax at source,
but it's your tax liability, not your employer's), so it should go
into your ledger. If you pay too much tax, you might get a refund, so
it's definitely something I want to show up in ledger.

So, personally, I'd track the above example as:

2013/05/17 * Myself
Assets:Checking:Myself $3500.00

Expenses:Taxes:Salary $1800.00

Income:Salary:Family Allowance $-100.00

Income:Salary:Taxable $-5200.00

Which is pretty much how I track my employment income.

On the other hand, I find the distinction you generate with bal and
bal --real very interesting and useful -- it reminds me of a feature I
proposed: http://bugs.ledger-cli.org/show_bug.cgi?id=714

However, one concern I have about virtual accounts is that they make
it easy to violate the accounting equation.

Let's assume I typed the following posting:

2013/05/17 * Myself
Assets:Checking:Myself $3500.00
Income:Salary:Family Allowance $-100.00
Income:Salary:Taxable:Net

[Expenses:Taxes:Salary] $1800.00

[Income:Salary:Taxable:Taxes] $-1700.00

Now ledger bal still seems to work, but ledger bal --real shows that
things don't balance. Is there any good reason why this should be
allowed? Are there good use cases for this?

I guess I would feel more comfortable about virtual accounts if they
would have to balance. Otherwise it seems to me that they just invite
errors.

[Of course, I should mention that I don't use virtual accounts at all,
so maybe I'm just missing something.]
--
Martin Michlmayr
http://www.cyrius.com/

[Martin Michlmayr]

* Martin Michlmayr <t...@cyrius.com> [2014-05-17 18:41]:

> > Gross income: $5200
> > Family allowance (tax-exempt): $100
> > Taxes: $1700
> > Net income: $3500
>
> BTW, there's a calculation error here. Either net income should be
> $3600 or taxes $1800. But that's a just a minor detail. I found your
> example very interesting and illuminating.

Oh, you probably meant gross income of $5200 consisting of $5100
taxable income and a $100 tax-exempt allowance. In my example, I
assumed $5200 taxable inome plus the $100 tax-free allowance. Sorry
for misunderstanding.

[Martin Michlmayr]

* Martin Blais <bl...@furius.ca> [2014-05-17 13:52]:

> I think in this case you're simply doing this wrong and you don't need
> virtual postings at all.
> Here's how I would do this:
>
> - Income counts the gross income amount ($5,200).
> - Tax withholding (not just for govt accounts, BTW) is usually recorded as
> a regular (non-virtual) expense, that is, you received an expense of that
> corresponding amount that the government recorded in your name.

+1

As many cases in recent times, I find myself in agreement with Martin.

> - Your non-taxable allowance can be tracked in a separate contra income
> account (that is, one with a positive amount). That's what I do for some of
> my deductions.

I don't think the allowance is a deduction. If I understood
correctly, the $5200 income consists of $5100 (taxable) salary and
$100 (exempt) allowance.

So:

> 2013/05/16 * Myself
> Income:Employer:Salary -5200.00 USD
> Income:Employer:Deductions:FamilyAllowance 100.00 USD

should be:

Income:Employer:Salary -5100.00 USD
Income:Employer:Allowance:Family -100.00 USD

> Assets:Bank:Checking 3500.00 USD
> Expenses:Taxes:Salary 1700.00 USD
>
> Your "net" income is simply the balance of the Income:Employer:Salary
> account - Expenses:Taxes:* accounts. You can write a query to calculate it.

Correct. But I think Lifepillar showed that using virtual accounts is
much more elegant. You can simply use --real and get the net figure.

Without using virtual accounts, you have to run a long "bal" command,
especially if there are many different expenses accounts (tax might be
split into income tax, social security, etc).

> Here's how I actually do this (from my Ledger, removed numbers, kept the
> signs):

FWIW, I use something very similar.

> 2014-05-07 * "GOOGLE INC PAYROLL" ^google-XXXXXXX
> Assets:US:MyBank:Checking XXXX.XX USD
> Income:US:Google:GroupTermLife -XXXX.XX USD
> Income:US:Google:Salary -XXXX.XX USD
> Income:US:Google:Deductions:Dental XXXX.XX USD
> Income:US:Google:Deductions:GroupTermLife XXXX.XX USD
> Income:US:Google:Deductions:InternetReimbursement -XXXX.XX USD

I don't know you call this a deduction. Wouldn't
Income:US:Google:Allowance:InternetReimbursement
be a better name?

> Income:US:Google:Deductions:Medical XXXX.XX USD
> Income:US:Google:Deductions:TransitPreTax XXXX.XX USD
> Income:US:Google:Deductions:Vision XXXX.XX USD

Are you should these shouldn't be Expense accounts? e.g.
Expenses:Health:Insurance

> Assets:US:Google:Vacation X.XX VACHR
> Income:US:Google:Vacation -X.XX VACHR

Is this to track vacation days?

> Auxiliary note: One might argue that the tax withheld sitting at the
> government in an account with your name on it is an "Asset" account (one
> like that for each tax year), and that the expense only gets incurred at
> the time you make your tax filing for that year (e.g. the following April)

I find it hard to make that argument. (You know, death and taxes... ;)

> I prefer to account for taxes as an Expense, so that throughout the
> year my income statement includes a good approximation of what my
> tax expenses will turn out to be for that year (which is exactly
> what source withholding is supposed to be), and at the time of
> filing I make an adjustment on that same expenses account when I
> compute the exact amount.

This is exactly what I do. If you have to pay additional tax, you
just book another expense If you're lucky enough to get a refund, you
reduce the expense. The only downside with this is that a large
refund (or payment) will mess up the overall expenses for that month
(e.g. you might have negative expenses in a month because your refund
was so high). If you did accrual accounting properly, you'd probably
have to split it up or at least assign it to the correct year (refund
in April is really for the previous year); I don't do this 100%
correctly in my personal finance (so far).

> I'm starting to think that I should start creating a distinct expense
> account for each tax year, because that's how both the Canadian and US
> governments handle it: amounts that you post get booked to a particular
> year

I'd use tags.

[Martin Blais]

On Sat, May 17, 2014 at 7:06 PM, Martin Michlmayr <t...@cyrius.com> wrote:

* Martin Blais <bl...@furius.ca> [2014-05-17 13:52]:

> - Your non-taxable allowance can be tracked in a separate contra income

> account (that is, one with a positive amount). That's what I do for some of
> my deductions.

I don't think the allowance is a deduction.  If I understood
correctly, the $5200 income consists of $5100 (taxable) salary and
$100 (exempt) allowance.

Ohhhh sorry I realize I did screw up one number in my example.

 

So:

> 2013/05/16 * Myself
>   Income:Employer:Salary   -5200.00 USD
>   Income:Employer:Deductions:FamilyAllowance  100.00 USD

should be:

   Income:Employer:Salary   -5100.00 USD
   Income:Employer:Allowance:Family   -100.00 USD

Yes, indeed, either like that or if it's some deduction, like this:

 

   Income:Employer:Salary   -5300.00 USD

   Income:Employer:Allowance:Family   100.00 USD

Either way, depending on what this "family allowance" actually means.

I use the second style for deductions.

At the EOY, my numbers match very precisely those that I see on my W2 and that gives me a warm fuzzy feeling of happiness : -)  IMO the closest you can track all the categories from your pay stub as they payroll processor does the better.

>   Assets:Bank:Checking    3500.00 USD
>   Expenses:Taxes:Salary          1700.00 USD
>
> Your "net" income is simply the balance of the Income:Employer:Salary
> account - Expenses:Taxes:* accounts. You can write a query to calculate it.

Correct.  But I think Lifepillar showed that using virtual accounts is
much more elegant.  You can simply use --real and get the net figure.

Without using virtual accounts, you have to run a long "bal" command,
especially if there are many different expenses accounts (tax might be
split into income tax, social security, etc).

Well I don't know about how Ledger reports it, but to me, if the numbers are accounted for in your ledger and available from the transactional data in some way, it's more of a matter of figuring out how to report it. If the reporting capabilities are insufficient, one should improve that instead instead of using what I think of as a hack in the data entry (because these virtual postings are not required to balance; I'm not 100% it's still true in current Ledger but when we talked about this way back when the feature was introduced they weren't IIRC; certainly Beancount's virtual postings weren't participating in the balance checks at the time). Using tags would be a non-hacky way to do this, like Harshad points out, but I think better would be find some way to program the reporting.

Moreover, these virtual accounts work here in this specific case, but what if they're needed somewhere else in the ledger to solve some other problem?  Can you have multiple sets of them or is there a single meaning for "--real"? How is a tax expense not "real"? What does this mean?  The reason I tend to kick back about this feature is that it has happened to me at least ten times over the time I was learning how to do this that I would trip up because I did not know how to book my transactions right and ended up using virtual postings as a crutch whereas I should have been forced to get more creative and figure it out. Eventually I managed to get rid of all of them without loss of information. I plan to document all these as examples at some point, I think a lot of examples would be useful to someone learning the DE method. That's why I feel quite strongly that in most cases the problem needs not break out of the DE model; I'm sure there are *some* cases where they are needed, but I just don't have those use cases myself and I don't see good use cases I couldn't convert. It would be useful to build a list of real-world use cases of virtual postings and see if they can all be solved without or not - make a compelling argument about the need for virtual postings.

Everything is a compromise; IMO the danger and possibilities for errors that virtual postings introduce is not worth the benefit, not by a long shot. This is why I removed them in the 2.0 rewrite. If I reintroduce them, it will be in a limited fashion that as much as possible preserves the balancing model, such as just supporting a separate Virtual:* hierarchy, so: virtual accounts, not postings (FYI: Beancount only allows accounts to live in one of the five A,L,E,I,X categories; this is on purpose, the reporting functions produce standard accounting reports that use these facts about accounts. This would merely introduce a 6th one that gets treated separately).

> Here's how I actually do this (from my Ledger, removed numbers, kept the
> signs):

FWIW, I use something very similar.

> 2014-05-07 * "GOOGLE INC       PAYROLL" ^google-XXXXXXX
>   Assets:US:MyBank:Checking                            XXXX.XX USD
>   Income:US:Google:GroupTermLife                      -XXXX.XX USD
>   Income:US:Google:Salary                             -XXXX.XX USD
>   Income:US:Google:Deductions:Dental                   XXXX.XX USD
>   Income:US:Google:Deductions:GroupTermLife            XXXX.XX USD
>   Income:US:Google:Deductions:InternetReimbursement   -XXXX.XX USD

I don't know you call this a deduction.  Wouldn't
Income:US:Google:Allowance:InternetReimbursement
be a better name?

That's just what they call is on my pay stubs. It lives in the "deductions" section IIRC.

 

>   Income:US:Google:Deductions:Medical                  XXXX.XX USD
>   Income:US:Google:Deductions:TransitPreTax            XXXX.XX USD
>   Income:US:Google:Deductions:Vision                   XXXX.XX USD

Are you should these shouldn't be Expense accounts? e.g.
Expenses:Health:Insurance

... and Dental. 

Hmmm that's a good point, I'll review this indeed...

It does bother me that those have generally positives amounts, and points to your comment likely being right.

I'll see why they call these deductions.

 

>   Assets:US:Google:Vacation                               X.XX VACHR
>   Income:US:Google:Vacation                              -X.XX VACHR

Is this to track vacation days?

Yes.

The payroll processing company even shows you the balance (in vacation hours) of your vacation accrued at the bottom left of the pay stub, so I put a 

YYYY-MM-DD balance Assets:US:Google:Vacation  X.XX VACHR

line after I update my ledger for pay stubs.

When I take vacation, I then deduct from this asset account and offer myself an Expenses:Google:Vacation. This way I can tell how much vacation I actually took that year, and it provides a double-check that Google booked it right when I notified them - via the internal automated web site - that I was taking time off :-)

> Auxiliary note: One might argue that the tax withheld sitting at the
> government in an account with your name on it is an "Asset" account (one
> like that for each tax year), and that the expense only gets incurred at
> the time you make your tax filing for that year (e.g. the following April)

I find it hard to make that argument. (You know, death and taxes... ;)

Yeah. I was mostly mentioning it because when explaining to someone else why an Income account is of a negative value, it's useful to think on a tax expense as something you received - like an asset - in exchange for the work you "gave away."

 

> I prefer to account for taxes as an Expense, so that throughout the
> year my income statement includes a good approximation of what my
> tax expenses will turn out to be for that year (which is exactly
> what source withholding is supposed to be), and at the time of
> filing I make an adjustment on that same expenses account when I
> compute the exact amount.

This is exactly what I do.  If you have to pay additional tax, you
just book another expense  If you're lucky enough to get a refund, you
reduce the expense.  The only downside with this is that a large
refund (or payment) will mess up the overall expenses for that month
(e.g. you might have negative expenses in a month because your refund
was so high).  If you did accrual accounting properly, you'd probably
have to split it up or at least assign it to the correct year (refund
in April is really for the previous year); I don't do this 100%
correctly in my personal finance (so far).

> I'm starting to think that I should start creating a distinct expense
> account for each tax year, because that's how both the Canadian and US
> governments handle it: amounts that you post get booked to a particular
> year

I'd use tags.

That would work too, but perhaps would be more annoying.

In solving many of these problems I have found that tags will often be used as a subaccount would, so for at least some uses they're equivalent.  A similar remark can be made about payees: a payee could often be replaced by a subaccount if the transactions for that payee always book to the same account, e.g. Expenses:Internet with payee "Time Warner" or Expenses:Internet:TimeWarner. I have been pondering adding an option to automatically convert one into the other at runtime if this occurs; I could automatically detect when a consistent payee always occurs to the same account.

Thanks for your thoughtful comments,

[Martin Blais]

On Sat, May 17, 2014 at 9:04 PM, Martin Blais <bl...@furius.ca> wrote:

Moreover, these virtual accounts work here in this specific case, but what if they're needed somewhere else in the ledger to solve some other problem?  Can you have multiple sets of them or is there a single meaning for "--real"? How is a tax expense not "real"? What does this mean?  The reason I tend to kick back about this feature is that it has happened to me at least ten times over the time I was learning how to do this that I would trip up because I did not know how to book my transactions right and ended up using virtual postings as a crutch whereas I should have been forced to get more creative and figure it out. Eventually I managed to get rid of all of them without loss of information. I plan to document all these as examples at some point, I think a lot of examples would be useful to someone learning the DE method. That's why I feel quite strongly that in most cases the problem needs not break out of the DE model; I'm sure there are *some* cases where they are needed, but I just don't have those use cases myself and I don't see good use cases I couldn't convert. It would be useful to build a list of real-world use cases of virtual postings and see if they can all be solved without or not - make a compelling argument about the need for virtual postings.

Actually, I wonder: does Quickbooks or Simply Accounting or other company-level DE bookkeeping system support fudging accounts without a balance? I don't know, but if not, that would be a convincing argument for them being superfluous. If the SMBs can do all the complicated transactions they need to without breaking the balancing rules, it's rather unlikely that what we do is so special that we need to be able to.

[Martin Blais]

On Sat, May 17, 2014 at 9:04 PM, Martin Blais <bl...@furius.ca> wrote:

On Sat, May 17, 2014 at 7:06 PM, Martin Michlmayr <t...@cyrius.com> wrote:

>   Income:US:Google:Deductions:Medical                  XXXX.XX USD
>   Income:US:Google:Deductions:TransitPreTax            XXXX.XX USD
>   Income:US:Google:Deductions:Vision                   XXXX.XX USD

Are you should these shouldn't be Expense accounts? e.g.
Expenses:Health:Insurance

... and Dental. 

Hmmm that's a good point, I'll review this indeed...

It does bother me that those have generally positives amounts, and points to your comment likely being right.

I'll see why they call these deductions.

Why yes, of course, you are right, these are the deductions from my paycheck, expenses paid through my salary.

I'm flabbergasted I was still booking this wrong.

They are, indeed, to be dealt with as expenses.

I've revised how I do this, both for these expenses, and for per-year booking of taxes, and it now looks like this:

2014-05-09 * "GOOGLE INC       PAYROLL / GOOGLE INC       PAYROLL" ^google-XXXXXXX
  Assets:US:TD:Checking                                     XXXX.XX USD
  Income:US:Google:GroupTermLife                           -XXXX.XX USD
  Income:US:Google:Salary                                  -XXXX.XX USD
  Expenses:Health:Dental:Insurance:Google                   XXXX.XX USD
  Expenses:Health:Life:GroupTermLife:Google                 XXXX.XX USD
  Expenses:Communications:Internet:Reimbursement:Google    -XXXX.XX USD
  Expenses:Health:Medical:Insurance:Google                  XXXX.XX USD
  Expenses:Transportation:PublicTrans:TransitPreTax         XXXX.XX USD
  Expenses:Health:Vision:Insurance:Google                   XXXX.XX USD
  Expenses:Taxes:US:TY2014:Medicare:Google                  XXXX.XX USD
  Expenses:Taxes:US:TY2014:Federal:Google                   XXXX.XX USD
  Expenses:Taxes:US:TY2014:City:Google                      XXXX.XX USD
  Expenses:Taxes:US:TY2014:SDI:Google                       XXXX.XX USD
  Expenses:Taxes:US:TY2014:State:Google                     XXXX.XX USD
  Expenses:Taxes:US:TY2014:SocSec:Google                    XXXX.XX USD
  Assets:US:Google:Vacation                                    X.XX VACHR
  Income:US:Google:Vacation                                   -X.XX VACHR

It does not look as "regular" but it is more correct. All my health expenses are now grouped together under Expenses:Health:*, which integrates both my health insurance costs and the amounts I pay out-of-pocket (e.g., copays, deductibles, drugs/pharmacy). I don't know why I hadn't done this before, this is so much better. Note that the internet reimbursement is booked by the payroll company as a negative deduction so I'm choosing to book it as reducing my ISP internet expense as well... I could have chosen to view it as an income account but I prefer not to, because it always just reduces the expense.

Also, booking the tax accounts this way matches more clearly how one organizes accounts to obtain a "taxes paid / total income" ratio for that year. I can just sum up Expenses:Taxes:US:TY2014;* to find out how much in taxes was paid *for that year*. (For those who might be unclear about why this is needed, 2014 taxation year expenses may be incurred in 2015, first at the date of filing taxes, and later on if/when I receive an adjustment/correction from the government for that year, so it's impossible to use the transaction dates for this purpose. Corrections may appear years after filing too. Note that all tax communications tend to have a taxation year attached to them, so it's easy to book the amount in the right year.)

This is an example where the "close" directive comes in handy: after filing taxes and receiving confirmation from the government, I can just choose to mark the accounts for that taxation year as closed, and they will not show up in the reports for years beyond the close date.

Now the truly, wonderfully great thing is how much *power* we have using our little text files. It's exhilarating. I can write a little script that renames my accounts automatically - I use xx-rename - look at it in visual diff, run bean-web on it, look at the reports, decide if I like it or not, revert and retry if I screwed up until I get it right. If I don't like it, "hg revert" and I'm back where I was. If I like it, "hg commit" and move on. Global renames, even of transactions far in the past, are not a problem. Text file power! The knowledge you acquire while learning how to do your bookkeeping right impacts your entire past transaction history, you can fix everything. Knowing that I will never lose any of this data to a software update or a company going EOL'ing their product and that I am able to completely reshape my history in the best way possible is something I could never give up now. Try doing that in any of the bookkeeping software that provide GUI interfaces.

[Martin Blais]

On Sat, May 17, 2014 at 9:04 PM, 

> I'm starting to think that I should start creating a distinct expense
> account for each tax year, because that's how both the Canadian and US
> governments handle it: amounts that you post get booked to a particular
> year

I'd use tags.

That would work too, but perhaps would be more annoying.

In solving many of these problems I have found that tags will often be used as a subaccount would, so for at least some uses they're equivalent.  A similar remark can be made about payees: a payee could often be replaced by a subaccount if the transactions for that payee always book to the same account, e.g. Expenses:Internet with payee "Time Warner" or Expenses:Internet:TimeWarner. I have been pondering adding an option to automatically convert one into the other at runtime if this occurs; I could automatically detect when a consistent payee always occurs to the same account.

Thanks for your thoughtful comments,

So I did convert all my tax accounts to be "by taxation year" and I quite like it! :-)

For instance, I have a notice from the govt about some amount owed for TY2011 and now I can just pull up that account to see a history of payments made for that taxation year, beyond 2011.

I thought I'd share, others may find this useful.

Here's the set of declarations that works for me (example from 2013, I have a section like this for each taxation year):

;; General accounts
2013-01-01 open Expenses:Taxes:US:TY2013:Federal                 USD
2013-01-01 open Expenses:Taxes:US:TY2013:StateNY                 USD
2013-01-01 open Expenses:Taxes:US:TY2013:Federal:PreTax401k      IRAUSD

;; Employer-specific accounts for at-the-source withholdings.
2013-01-28 open Expenses:Taxes:US:TY2013:Medicare:Google    USD ; "Employee Medicare"
2013-01-28 open Expenses:Taxes:US:TY2013:Federal:Google     USD ; "Federal Income Tax"
2013-01-28 open Expenses:Taxes:US:TY2013:CityNYC:Google     USD ; "New York City Tax"
2013-01-28 open Expenses:Taxes:US:TY2013:SDI:Google         USD ; "NY Disability Employee"
2013-01-28 open Expenses:Taxes:US:TY2013:StateNY:Google     USD ; "NY State Income Tax"
2013-01-28 open Expenses:Taxes:US:TY2013:SocSec:Google      USD ; "Social Security Employee Tax"

2013-01-01 * "Annual maximum 401k contribution allowed for 2013"
  Income:US:Federal:PreTax401k                  -17500 IRAUSD
  Assets:US:Federal:PreTax401k                   17500 IRAUSD

2014-03-29 * "Filed US taxes"
  Expenses:Taxes:US:TY2013:Federal                  XXXX.XX USD
  Expenses:Taxes:US:TY2013:StateNY                  XXXX.XX USD
  Liabilities:AccountsPayable

... more tax-related entries, maybe ...

;; Closing at-the-source withholding accounts right away.
2013-12-31 close Expenses:Taxes:US:TY2013:Federal:PreTax401k
2013-12-31 close Expenses:Taxes:US:TY2013:Medicare:Google
2013-12-31 close Expenses:Taxes:US:TY2013:Federal:Google
2013-12-31 close Expenses:Taxes:US:TY2013:CityNYC:Google
2013-12-31 close Expenses:Taxes:US:TY2013:SDI:Google
2013-12-31 close Expenses:Taxes:US:TY2013:StateNY:Google
2013-12-31 close Expenses:Taxes:US:TY2013:SocSec:Google

;; Closing the general accounts 1.5 years after the filing date in case of updates.
2015-12-31 close Expenses:Taxes:US:TY2013:Federal
2015-12-31 close Expenses:Taxes:US:TY2013:StateNY

The general accounts for each receiver are there to book amounts for the tax filing and further adjustments.

They get closed much later when I'm more confident that the filing has been accepted.

(Of course if that weren't the case - e.g. a late audit - I could just comment out the lines and then add later entries - Beancount barks if you have entries with a date after an account has been closed.)

The employer-specific accounts allow me to count the numbers that the corresponding W2 should provide.

If you had multiple employers during that year you would have a separate set of these accounts for each.

I close these right at the end of that year because there will be no further corresponding source withholding after it.

The PreTax401k accounts track allowed contributions to a 401k account. 

If you don't max it out with contributions, you have to write off the remainder of the Assets:US:Federal:PreTax401k at the EOY.

The balance of the Assets account at the EOY tells you how much to write off.

About using tags instead: I still prefer accounts in the end, here's two reasons why, which I noticed after I tried this out:

1. When I'm looking at the income statement for a particular calendar year, having separate accounts naturally provides a breakdown of how many payments I made for this current year, and how many I did for the last year (the one I filed). It's nice to see both balances separately. If I used tags, I would not have those, I'd have to filter by tag and see one or the other.

2. Some of my transactions actually involve payments for multiple tax years; I wouldn't be able to handle those with tags, I would have to split them into multiple transactions. Here are two examples:

2013-08-21 * "Payment / WWW PAYMENT - CRA-AMT OWING" | "Tax payment to CRA to cover for amounts due after refiling of 2010, 2011, 2012 taxes"
  Assets:CA:MyBank:Checking            -XXXX.XX CAD
  Expenses:Taxes:CA:TY2009:Federal	   X.XX CAD
  Expenses:Taxes:CA:TY2010:Federal	  XX.XX CAD
  Expenses:Taxes:CA:TY2011:Federal      XXXX.XX CAD

In this one, updated filings on multiple years triggered them to send me a single amount due, collating information from those three years. I made a single payment, to cover for amounts in three different years. This is one transaction. Attaching tags to the transaction would also not reflect each posting's specific amount; the accounts naturally handle this well.  (Can you attach a tag to a posting in Ledger? Not in Beancount.)



2013-10-07 * "Payment / WWW PAYMENT - CRA-AMT OWING - Not admissible to QST jul 2010 - apr 2011"
  Assets:CA:MyBank:Checking             -XXX.XX CAD
  Expenses:Taxes:CA:TY2010:Federal	 XXX.XX CAD
  Expenses:Taxes:CA:TY2011:Federal	 XXX.XX CAD

In this second example, amounts reimbursed for a local sales tax (4x/year) were rescinded following an update of residency status. The dept that handles this sales tax must be distinct from the other ones I suspect, because they sent me a request for a payment with amounts that straddles two taxation years. By having the accounts, I can book those to the correct year.

I wonder if a more general rule-of-thumb can be inferred here: "if you can make do with subaccounts, you should always favor that over tags or other mechanisms." Not sure if always true? But surely something to think about.

[Lifepillar]

In article <20140517224...@jirafa.cyrius.com>,

Martin Michlmayr <t...@cyrius.com> wrote:

> Oh, you probably meant gross income of $5200 consisting of $5100
> taxable income and a $100 tax-exempt allowance.

Sure, sorry for not being more explicit.

Thank you all, I've learned a lot! As I said, I'm not an
accountant, so my example was from the perspective of a "home"
user. Quoting from the feature request by Martin M.:

> A lot of us are tracking our personal finance. We sometimes get
> the question as to how to track salary best: should we track all
> gross income and then track deductions, such as tax. Or should we
> simply enter our net pay since this is the figure we typically care
> about.

The solution I have proposed with virtual transactions achieves the goal
of tracking everything, yet easily filter out (with --real) what you are
typically interested in. If one includes --real in reports by default,
tax-related postings, less relevant for day-to-day bookkeeping, are
never shown unless explicitly requested.

But you all made convincing arguments against virtual postings,
and have proposed viable alternatives, using tags or subaccounts.
I think that the drawback of tags is that generating reports becomes
more involved (e.g., to know how much I have saved this month, I can't
just `ledger --real bal income expenses` any longer, because I need
to filter net income and exclude taxes). As for subaccounts,
since virtual account [X] can be replaced by real account V:X,
probably one can use subaccounts as easily as virtual transactions.

Anyway, this discussion has given me several ideas, which
I plan to try on my data.

Enjoy,
Life

[Lifepillar]

In article
<CAK21+hObT7wAsaUVtaWJ00EZbCNCZp3oSd3RUg=pQ5Ca...@mail.gmail.com>,

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

> Now the truly, wonderfully great thing is how much *power* we have
> using our little text files.

Totally agree. The only thing that could compete (and possibly be
superior) would be a relational temporal database!

Life

[John Wiegley]

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

> It would be useful to build a list of real-world use cases of virtual
> postings and see if they can all be solved without or not - make a
> compelling argument about the need for virtual postings.

I'd be interested to know your solution to the following problems, which were
the reason virtual postings were created in the first place.

Problem The First

I was a treasurer for my local religious community. We had 3 physical bank
accounts, and 5 virtual "community accounts". The physical accounts kept the
actual money, and represented our relationship with the outside world; the
virtual accounts indicated how that money had been allotted, and represented
our relationship with the community. The banks only cared about the real
accounts, and the community only cared about the virtual accounts.

To prevent ridiculous amounts of double-booking, I invented virtual postings
so that money deposited by a transaction could immediately go to "two places
at once": both to the physical bank(s), and to the community fund(s). By
reporting with --real I saw only the world's view, and by reporting without
--real I saw the whole picture.

Problem The Second

Another religious duty I compute is effectively tithing (we call it
Huqúqu'lláh, and it's computed differently, but that's another story). In
order to compute the tithe owed, I accrue 19% of every deposit to a virtual
account, and then subtract from that account 19% of every needful expenditure.
The total remaining at the end of the year is what I owe in tithe.

This tithing account is not a real account, as it exists in no financial
institution; but it is real enough as a personal duty. By using virtual
account, I can track this "side-band" Liability, and then pay it off from an
assets account when the time comes. If I report with --real I will simply see
how much I've paid to this Liability; and if I report without --real I see how
much Huqúqu'lláh is presently owed.


Those are the only things I've actually used virtual accounts for, and was the
reason I added them. I've tried other schemes, like double-booking, but they
became unwieldy enough that I had to give up on them. I have a feeling
tagging might lead to a similar measure of complexity. The point is, is has
to be simple enough that I can keep up with it regularly, and yet rich enough
is expressivity that I'm able to solve the whole problem. Virtual accounts
ended up fitting this bill for me perfectly in these two cases.

John

[Eric Abrahamsen]

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


[...]

> It would be useful to build a list of real-world use cases of virtual
> postings and see if they can all be solved without or not - make a
> compelling argument about the need for virtual postings.

I have a fairly simple use-case, the system for which I'm putting
together right now. I have a consulting contract with a company here in
China, and like many local companies they are creative about tax
evasion. My fee is paid in part as "salary", which is taxed, and in part
as spurious "reimbursements" for expenditures, which aren't taxed. I
have to collect official receipts for various things I spend money on,
and then present them to the company each month, and they reimburse me.

I spent a while thinking about how to represent this. I knew I wanted
the reimbursed portion to be a "real" account, under Assets:Receivable,
because that's real value. I also needed to keep track of how much I'd
accumulated in receipts, but decided to use a virtual account for that,
because it isn't "real" value moving from one account to another, it's
simply a catalyst for movement between two other accounts. So now I've
got:

~ Monthly
; Payee: Tax Dodgers, Inc
Assets:Merchants:5231 7000 RMB ; regular salary part
Assets:Receivable 3000 RMB ; receipts
Income:Salary

Then I go to dinner and get a receipt:

04/13 * 华堂
Expenses:Food:Restaurant 143.10 RMB
(Assets:Receipts) 143.10 RMB
Assets:Cash

After a few weeks I have 1920.90 RMB in my virtual receipt account, and
I hand them in (but they haven't paid me the reimbursement yet):

05/04 ! Tax Dodgers, Inc
* (Assets:Receipts) = 0 RMB
Assets:Merchants:5231 1920.90 RMB
Assets:Receivable

When the reimbursement comes through I clear the whole transaction, and
add an aux date.

There are several handy ways to report on this, but in practice all I
need is:

ledger reg --limit 'payee=~/dodgers/' assets:receivable

This is nice because the last line comes out bold on the terminal if the
reimbursement is still pending. At a glance I can see how much I gave
them in receipts, how much they still owe me, and how much in receipts I
still need to gather to get my full salary.

The ugly bits are the duplicate numbers when I collect a receipt for an
expenditure (though I'm working on solving that with automated
transactions), and the fact that I end up manually balancing a virtual
account against a real account. That feels weird, but does no real harm.

Anyway, that's my story!

Eric

[Martin Blais]

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

>
> > It would be useful to build a list of real-world use cases of virtual
> > postings and see if they can all be solved without or not - make a
> > compelling argument about the need for virtual postings.
>
> I'd be interested to know your solution to the following problems, which were
> the reason virtual postings were created in the first place.
>
> Problem The First
>
> I was a treasurer for my local religious community.  We had 3 physical bank
> accounts, and 5 virtual "community accounts".  The physical accounts kept the
> actual money, and represented our relationship with the outside world; the
> virtual accounts indicated how that money had been allotted, and represented
> our relationship with the community.  The banks only cared about the real
> accounts, and the community only cared about the virtual accounts.
>
> To prevent ridiculous amounts of double-booking, I invented virtual postings
> so that money deposited by a transaction could immediately go to "two places
> at once": both to the physical bank(s), and to the community fund(s).  By
> reporting with --real I saw only the world's view, and by reporting without
> --real I saw the whole picture.

There is a crucial question to ask here, which divides this problem into two
cases: "Are the virtual accounts straddling real accounts?" In other words,
are each of the 5 virtual account's postings fully contained within the real
accounts?

If not, this is easily solved using subaccounts.

Like this, for example:

  Assets:Real:Account1
  Assets:Real:Account1:Community1
  Assets:Real:Account1:Community2
  Assets:Real:Account2
  Assets:Real:Account3
  Assets:Real:Account3:Community3
  Assets:Real:Account3:Community4

This gives you three real accounts:

  Assets:Real:Account1
  Assets:Real:Account2
  Assets:Real:Account3

And five community accounts:

  Assets:Real:Account1:Community1
  Assets:Real:Account1:Community2
  Assets:Real:Account2
  Assets:Real:Account3:Community3
  Assets:Real:Account3:Community4

By looking at reports for 'Assets:Real:Account1', you are looking at the
register of all real transactions. In practice, transfers between the
community accounts there in will be few and easy to ignore when looking at the
register.

This _does_ hinge on the capability to display a register of transactions for
a parent account that includes all of the postings of child accounts. (This is
how Beancount renders a journal of transactions for a parent account by
default.)

If the community accounts straddle the real accounts, you just filter by the
CommunityX bit. Imagine for a moment the worse case, that all real accounts
have all community subaccounts (in practice this rarely occurs, BTW,
real-world structure is always more constrained than this deliberately chosen
"full-product of dimensions" example):

  Assets:Real:Account1:Community1
  Assets:Real:Account1:Community2
  Assets:Real:Account1:Community3
  Assets:Real:Account1:Community4
  Assets:Real:Account1:Community5
  Assets:Real:Account2:Community1
  Assets:Real:Account2:Community2
  Assets:Real:Account2:Community3
  Assets:Real:Account2:Community4
  Assets:Real:Account2:Community5
  Assets:Real:Account3:Community1
  Assets:Real:Account3:Community2
  Assets:Real:Account3:Community3
  Assets:Real:Account3:Community4
  Assets:Real:Account3:Community5

You can filter by just looking at the Community1 accounts:

  Assets:Real:Account1:Community1
  Assets:Real:Account2:Community1
  Assets:Real:Account3:Community1

Looking at the balance sheet / income statement / journals for this subset of
postings will give you all the reports you need for project Community1.

This is a common case: Imagine you and your wife/life partner are both working
professionals and share a joint account for convenience of making common
expenses (e.g. you're going to a restaurant together and one of you pays but
you want to generally split the expense, you also use those joint funds to pay
for individual expenses, etc.). You want to account for each other's
contributions separately. You would get a real bank account and create two
subaccounts in it:

  Assets:US:Bank:Joint:Husband
  Assets:US:Bank:Joint:Wife

'Assets:US:Bank:Joint' is the real underlying bank account. An expense paid
from that debit card would be booked like this:

2014-05-19 * "Dinner together at favourite sushi place"
  Expenses:Restaurant              101.20 USD
  Assets:US:Bank:Joint:Husband     -65.00 USD ; A bit extra for sake box
  Assets:US:Bank:Joint:Wife

I've been using this for real and has worked for me so far. No virtual
accounts.





(digression not about virtual postings but answers auxiliary questions about them)

Now this points to a more general idea that I've been pondering for a while:
these "accounts" can often be seen as a set of flat dimensions, the fact that
they have a hierarchy can get in the way. I tend to have accounts that look
like this:

  TYPE:COUNTRY:INSTITUTION:ACCOUNT:SUBACCOUNT

like this, for example:

  Assets:US:HSBC:Checking
  Assets:CA:RBC:Savings

For these four dimensions, I actually like having most accounts (Assets,
Liabilities and Income) specify them in this order. This does not always make
sense though, especially for expense accounts; for those you wouldn't really
want to have a COUNTRY dimension at the root. You want the general category
only, so I'll have, for example:

  Expenses:Food:Restaurant
  Expenses:Food:Grocery

but sometimes the dimensions get inverted too, like in my recent change about
how to track taxation:

  Expenses:Taxes:US:TY2014:Google:Federal
  Expenses:Taxes:US:TY2014:Google:StateNY
  Expenses:Taxes:US:TY2014:Google:CityNYC
  ...

Here the "institution" is Google, and shows deeper in the hierarchy.

Finally, you often do want to have multiple types for the same or similar
accounts, for instance, to track gains and dividends income from a particular
investment account, you want a mirror of most of the dimensions except for the
assets bit:

  Assets:US:ETrade:IRA -> Income:US:ETrade:IRA

For instance:

  Assets:US:ETrade:IRA:Cash
  Income:US:ETrade:IRA:Dividends

You see what I'm getting at... these components really operate more like a
database table with values possibly NULL, e.g.,

  type     country  institution  account   category
  -------- -------- ------------ --------- -----------
  Assets   US       HSBC         Checking  NULL
  Assets   CA       RBC          Savings   NULL
  Assets   US       ETrade       IRA       Cash
  Income   US       ETrade       IRA       Dividends
  Expenses NULL     NULL         Food      Restaurant
  Expenses NULL     NULL         Food      Grocery

Having to order your account components in a hierarchy forces you to

decide how you want to report on them, a strict order of grouping from

top to bottom.

So I've been thinking about an experiment to rename all accounts according to
dimensions, where the ordering of the components would not matter. These two
would point to the same bucket, for example (changing the syntax slightly),

  Expenses|Taxes|US|TY2014|Google|Federal
  Expenses|US|Google|Taxes|TY2014|StateNY

You could then display reports (again, the usual reports, balance sheet,
income statement, journals) for "the subset of all transactions which has one
posting in an account in <set>" where <set> is defined by values on a list of
dimensions, a bit like a WHERE clause would do.

Now, now, now... this would be a bit radical, now wouldn't it? Many of these
accounts do point to real accounts whose postings have to be booked exactly,
and I'm a bit worried about the looseness that this could introduce. One and
only one account name for a particular account is a nice property to have.

So what can we do to select across many dimensions while still keeping
hierarchical account names?

The first thing I did in Beancount is to create views for all unique account
component names. For example, if the following account exists:

  Assets:US:ETrade:IRA

You will see four "view" links at the root of the Beancount web page:

  Assets
  US
  ETrade
  IRA

Clicking on the link selects all the transactions with a posting with an
account where that component appears. (Views provide access to all the reports
filtered by a subset of transactions.) You can click your way to any journal
or report for that subset of transactions. This exists in HEAD today. You can
draw all the reports where a particular component appears, e.g., "Google", as
in "Income:US:Google:Salary" and "Expenses:Taxes:US:TY2014:Google:Federal".

But this does not define "dimensions." It would be nice to group values for
these components by what kind of thing they are, e.g., a bank, an instution, a
country, a tax year, etc, without regard for their location in the account
name. A further experiment will consist in the following:  again assuming
unique "account component names" (which is not much of a constraint to
require, BTW, at least not in my account names), allow the user to define
dimensions by declaring a list of component names that form this dimension.
Here's how this would look, with the previous examples (new syntax):

  dimension employer  Google,Autodesk,Apple
  dimension bank      HSBC,RBC,ETrade
  dimension country   US,CA,AU
  dimension taxyear   TY2014,TY2013,TY2012,TY2011,TY2010
  dimension type      Assets,Liabilities,Equity,Income,Expenses (implicit?)

You could then say something like "show me trial balance for all transactions
with posting accounts where bank is not NULL group by bank" and you would
obtain mini-hierarchies for each group of accounts (by bank, across all other
dimensions).

(With the state of my current system, I could probably code this as a
prototype in a single day.)

Addtionally, accounts have currency constraints and a history of postings
which define a set o currencies used in them. More selection can be done with
this (e.g., show me all transactions with postings that credit/debit CAD
units).

IMHO, all you're trying to do with these virtual accounts is aggregate with
one less dimension, you want to remove the real account and group by community
project. My claim is that there are ways to do that without giving up o the
elegant balancing rules of the DE system.

--------------------------------------------------------------------------------

> Problem The Second
>
> Another religious duty I compute is effectively tithing (we call it
> Huqúqu'lláh, and it's computed differently, but that's another story).  In
> order to compute the tithe owed, I accrue 19% of every deposit to a virtual
> account, and then subtract from that account 19% of every needful expenditure.
> The total remaining at the end of the year is what I owe in tithe.
>
> This tithing account is not a real account, as it exists in no financial
> institution; but it is real enough as a personal duty.  By using virtual
> account, I can track this "side-band" Liability, and then pay it off from an
> assets account when the time comes.  If I report with --real I will simply see
> how much I've paid to this Liability; and if I report without --real I see how
> much Huqúqu'lláh is presently owed.

If you have a single employer/source of income to pay the tithe on, or a
single place where the income gets deposited, it's not much of a problem: just
a create a subaccount for it. Let's look at it from the POV of the deposit
account:

  Assets:US:BofA:Checking
  Assets:US:BofA:Checking:Tithe

2014-05-19 * "Booking tithe"
  Assets:US:BofA:Checking         -300 USD
  Assets:US:BofA:Checking:Tithe    300 USD

This again depends on the ability to render a journal that includes all
subaccount postings. You can easily visually ignore these transactions in your
Ledger, presumably you'll be doing it monthly or at the most weekly. When you
transfer the money out for the donation, do it from the Title subaccount, e.g.

2014-05-19 * "Fulfilling my obligation"
  Assets:US:BofA:Checking:Tithe     -1200 USD
  Expenses:Title

The problem is that if you have multiple accounts to compute the tithe for,
you can repeat this pattern, e.g.

  Assets:US:BofA:Checking              ; Employer deposits
  Assets:US:BofA:Checking:Tithe
  Assets:US:Lulu:Cash                  ; Book royalties
  Assets:US:Lulu:Cash:Tithe
  Assets:US:WellsFargo:Checking        ; Contract revenue deposits
  Assets:US:WellsFargo:Checking:Tithe

This is the same problem and solution as before: you want to select all
transactions with subaccount "Tithe" in them and produce various reports on
this subset. Just select those transactions, you don't need virtual accounts.


> Those are the only things I've actually used virtual accounts for, and was the
> reason I added them.  I've tried other schemes, like double-booking, but they
> became unwieldy enough that I had to give up on them.  I have a feeling
> tagging might lead to a similar measure of complexity.  The point is, is has
> to be simple enough that I can keep up with it regularly, and yet rich enough
> is expressivity that I'm able to solve the whole problem.  Virtual accounts
> ended up fitting this bill for me perfectly in these two cases.

To me, tagging is just another mechanism to select a subset of transactions.
Tagging is most useful when the list of transactions do not share something
else in common, like an account, or expenses related to a project. A good
example is a trip whose expenses are varied and from which the assets used are
numerous, e.g. various credit cards, cash, debit accounts, maybe from various
people. Tags are perfect to marking all those transactions as belonging to the
same set.


The executive summary: I think you can do everything by finding a way to
select a relevant subset of transactions from non-virtual accounts.

[Martin Michlmayr]

* Eric Abrahamsen <er...@ericabrahamsen.net> [2014-05-19 09:59]:

> ~ Monthly
> ; Payee: Tax Dodgers, Inc
> Assets:Merchants:5231 7000 RMB ; regular salary part
> Assets:Receivable 3000 RMB ; receipts
> Income:Salary

Is this just an example or something you actually use? I'm asking
becaue I don't understand this transactions. Why would
Assets:Receivable go up every month? Also, what it
Assets:Merchants:5231? Surely, if you're paid monthly, your bank
account would go up, and not some Assets:Merchants account.

> After a few weeks I have 1920.90 RMB in my virtual receipt account, and
> I hand them in (but they haven't paid me the reimbursement yet):
>
> 05/04 ! Tax Dodgers, Inc
> * (Assets:Receipts) = 0 RMB
> Assets:Merchants:5231 1920.90 RMB
> Assets:Receivable
>
> When the reimbursement comes through I clear the whole transaction, and
> add an aux date.

This whole approach looks a bit complicated and fragile to me. I'll
explain the workflow I use. I'm not sure it's better, but it works
for me:

1) When I spend something while on a business trip, I do not book it
as an expense. I don't think that would be correct since I'm
effectively just lending money to my employer until I'm reimbursed.
So it's an asset. I called it Assets:Reimbursable:XXX (XXX for my
employer).

2014-05-10 * Taxi
Assets:Reimbursable:XXX $20
Assets:Cash

2) Then I enter expenses into my employer's expensive reports and
generate an expense report. I use the data from the expense report to
generate ledger transactions. They look like this:

2014-05-15=2014-05-10 * Reimbursement: Taxi
Assets:Receivable:XXX $20
Assets:Reimbursable:XXX -$20

; This is an allowance (e.g. a per diem)
2014-05-14=2014-05-10 * Subsistence
Assets:Receivable:XXX $5
Income:Allowances:Incidentals

I use the date of the expense report as the date and the date of the
expense as the effective date. This is a bit of a hack, but allows me
to use
ledger --effective --sort d reg reimbur
to match expenses and reimbursements (if doesn't go to 0 at the end of
each day, I either forgot to expense something or to tag an expense).

I essentially convert Assets:Reimbursable to Assets:Receivable. When
I submit my expense report, I'm just awaiting payment from my
employer.

This allows me to differentiate between things I still need to put
into the expense system and payments I'm awaiting.

3) I get paid by my employer:

2014-05-19 * Reimbursement for XXXX
Assets:Checking:Bank $25
Assets:Receivable:XXX -$25

I use tags to track expenses that relate to one particular trip /
expense report. Initially, I just tag it with the directory name I
use to store receipt (e.g. 2014-03-21-boston-libreplanet) but later I
add a tag for the number of the expense report.

I think this workflow follows a logical approach: when you spend
money, you have an asset that can be reimbursed (Assets:Reimbursable).
When you do an expensive report, it becomes a receivable
(Assets:Receivable). And finally, this receivable goes away when you
get paid.

Now I understand that it might be slightly different if I were a
contractor rather than an employee. In that case, I can see an
argument for booking these expenses a actual Expenses: rather than
Assets:Reimbursable. (After all, they are expenses for your business
regardless of whether you get reimbused or not.)

You could tag with them with your client, and then use
ledger reg Expenses: tag client
to get a list in order to bill them. This would just be income and
not a reimbursement as with a true employee.

I believe this approach should work for most people. Now in your
case, we need to be slightly more creative. It sounds as if got paid
$40 if you had a receipt for $40, even though you only spent $20 (no
need to confirm). I have one idea how to handle this. It's not
currently supported by ledger, but it's a feature that I realized a
few days ago would be useful.

It would be nice if ledger would allow you to run 'reg' or 'bal' on
tags. In order words, you could have:

05/15 * Taxi
; Receipt:: 40 RMB
Expenses:Transportation 23 RMB
Assets:Cash

05/15 * BHG
; Receipt:: 154 RMB
Expenses:Food:Supermarket 154 RMB
Assets:Bank

and then do:

ledger reg --account=tag('Receipt')

or to generate an invoice for your employer:

ledger bal -p "this month" --account=tag('Receipt')

This doesn't work at the moment, but I'll file a feature request:
http://bugs.ledger-cli.org/show_bug.cgi?id=1042
[Now that I filed this bug, it seems like what I'm asking for is a
virtual account. ;-) But I want the tag to remain _outside_ the
accounting system whereas a virtual account is part of your accounts.]

I have a use case for this: I track points I receive when I stay in a
hotel. In addition to points, the number of nights stayed count
towards lifetime status. This isn't something I track in ledger
(since it's not really an asset), so I just put it in a comment.
However, it would be nice to do:
ledger reg --account=tag('Nights')
to get the total number of nights I've achieved.

[Martin Michlmayr]

* Martin Blais <bl...@furius.ca> [2014-05-19 15:42]:

> If not, this is easily solved using subaccounts.

I must say I'm with John on this: virtual accounts are a much more
elegant solution in this case than what you propose.

I'm not sure if there's a way to achieve what John wants with tags. I
chatted with Bradley Kuhn earlier today about Conservancy's use of
ledger and it seems he (mostly) manages without virtual accounts, but
I'm not 100% yet how things work there.

> This is a common case: Imagine you and your wife/life partner are both working
> professionals and share a joint account for convenience of making common
> expenses (e.g. you're going to a restaurant together and one of you pays but
> you want to generally split the expense, you also use those joint funds to pay
> for individual expenses, etc.). You want to account for each other's
> contributions separately. You would get a real bank account and create two
> subaccounts in it:
>
> Assets:US:Bank:Joint:Husband
> Assets:US:Bank:Joint:Wife

Just as an aside, if you're married and it's a joint account, there is
no "this is mine", "this is his/hers". I know you're fond of
subaccounts, but I don't think this is a particularly good example.

> I tend to have accounts that look like this:
>
> TYPE:COUNTRY:INSTITUTION:ACCOUNT:SUBACCOUNT

One thing I noticed in your examples is that you really like
subaccounts. I'm not very fond of them...

> Expenses:Taxes:US:TY2014:Google:Federal
> Expenses:Taxes:US:TY2014:Google:StateNY
> Expenses:Taxes:US:TY2014:Google:CityNYC

... I don't see the advantage of putting your employer's name there.
If you really want that info, I'd just use a tag. Same for the tax
year.

I guess it's just a matter of taste, but your account names seem
unwieldy to me.

> So what can we do to select across many dimensions while still keeping
> hierarchical account names?

Use tags? Note that in ledger, tags can have values, e.g.

; foo: bar

> 2014-05-19 * "Booking tithe"
> Assets:US:BofA:Checking -300 USD
> Assets:US:BofA:Checking:Tithe 300 USD

Now you're creating an account that doesn't exist, which I don't find
ideal.

[Nathan Grigg]

On May 19, 2014, at 5:04 PM, Martin Michlmayr <t...@cyrius.com> wrote:

2014-05-19 * "Booking tithe"
 Assets:US:BofA:Checking         -300 USD
 Assets:US:BofA:Checking:Tithe    300 USD

Now you're creating an account that doesn't exist, which I don't find
ideal.

The real problem is that you’ve created an artificial dependency between Tithe and your Checking account. The good thing about an accounting system is that you can treat your finances as one big pot of money, and Expenses:Groceries doesn’t care which account you use to pay for it.

Another way to think about this case is that you have a liability, because you owe tithe. But you also have the money still, which is an asset.

2014-05-19 * "Booking tithe"
 Assets:Tithe          300 USD
 Liabilities:Tithe     -300 USD

2014-05-20 * “Paying tithe”

  Expenses:Tithe     300 USD

  Assets:Tithe         -300 USD

  Liabilities:Tithe      300 USD

  Assets:Checking  -300 USD

Michlmayr would complain that Assets:Tithe isn’t actually an account, but neither are your Expenses, so I’m okay with that. Blais would probably use Virtual:Tithe instead, as would I, as a way to distinguish between “real” assets and “pretend” assets. Although I would argue you do have a very real $300 set aside, it just doesn’t happen to live in an account. You could also just use an unbalanced virtual account for Liabilities:Tithe, but then you have to stop and think about what the difference between --real and --virtual is, whereas in this case, it is clear what you mean by “what is my balance excluding Assets:Tithe?"

Of course a real accountant would just do this: (accrual based accounting)

2014-05-19 * "Booking tithe”
 Expenses:Tithe     300 USD
 Liabilities:Tithe     -300 USD

2014-05-20 * “Paying tithe”

  Liabilities:Tithe      300 USD

  Assets:Checking  -300 USD

But this records the expense on a different day than when you actually paid it. That would be a problem if, for example, you live in the US and wanted to claim a tax deduction for the tithe, in which case you must claim the deduction for the year the tithe was actually paid (cash based accounting).

Nathan

[Martin Blais]

On Mon, May 19, 2014 at 9:57 PM, Nathan Grigg <nat...@nathangrigg.net> wrote:

On May 19, 2014, at 5:04 PM, Martin Michlmayr <t...@cyrius.com> wrote:

2014-05-19 * "Booking tithe"
 Assets:US:BofA:Checking         -300 USD
 Assets:US:BofA:Checking:Tithe    300 USD

Now you're creating an account that doesn't exist, which I don't find
ideal.

The real problem is that you’ve created an artificial dependency between Tithe and your Checking account. The good thing about an accounting system is that you can treat your finances as one big pot of money, and Expenses:Groceries doesn’t care which account you use to pay for it.

Another way to think about this case is that you have a liability, because you owe tithe. But you also have the money still, which is an asset.

2014-05-19 * "Booking tithe"
 Assets:Tithe          300 USD
 Liabilities:Tithe     -300 USD

2014-05-20 * “Paying tithe”

  Expenses:Tithe     300 USD

  Assets:Tithe         -300 USD

  Liabilities:Tithe      300 USD

  Assets:Checking  -300 USD

Michlmayr would complain that Assets:Tithe isn’t actually an account, but neither are your Expenses, so I’m okay with that.

I'm okay with that too. I don't really feel a need that all accounts correspond to real account; on the other hand, all real accounts do have to have a single system account to track their balance.

 

Blais would probably use Virtual:Tithe instead, as would I, as a way to distinguish between “real” assets and “pretend” assets.

I would prefer it to be a subaccount, because remember, I rely on the fact that you can render a parent account's journal including all its subaccounts. The parent-child relationship is being used.

 

Although I would argue you do have a very real $300 set aside, it just doesn’t happen to live in an account. You could also just use an unbalanced virtual account for Liabilities:Tithe, but then you have to stop and think about what the difference between --real and --virtual is, whereas in this case, it is clear what you mean by “what is my balance excluding Assets:Tithe?"

I think that if you constrained virtual postings somewhat you might make them palatable to me; here's how:

- Move the "virtuality" from posting to something else. Postings cannot be virtual. It's probably best to make transactions virtual rather than accounts.

- All virtual things that you do must involve balancing transactions. There's no breaking the beautiful DE system. Non-balancing is the main beef I have with these virtual things.

- This means that to convert between --real and --virtual is basically a choice to include or not include the virtual transactions in the summarization act. 

Note that this can be carried out with a simple tag, as long as there are sufficient mechanisms to include them or filter them out.

So let's try this: we want John's first example, with no subaccounts (they don't bother me much, but let's have it your way): see the example file here:

https://hg.furius.ca/public/beancount/file/tip/examples/virtual/virtuals.beancount

I created a little plugin to Beancount to exclude transactions with a #virtual tag, because the Beancount interface did not support tag exclusion by default (but that would be trivial to add):

https://hg.furius.ca/public/beancount/file/tip/src/python/beancount/plugins/exclude_tag.py

I baked the web interface with and without virtuals with the following commands (see zip files in attachment).]

bean-bake --plugin beancount.plugins.exclude_tag   virtuals.beancount  without-virtuals 

bean-bake    virtuals.beancount  with-virtuals

You can open a web browser with two tabs and switch between the two for the same report.

Of course a real accountant would just do this: (accrual based accounting)

2014-05-19 * "Booking tithe”
 Expenses:Tithe     300 USD
 Liabilities:Tithe     -300 USD

2014-05-20 * “Paying tithe”

  Liabilities:Tithe      300 USD

  Assets:Checking  -300 USD

But this records the expense on a different day than when you actually paid it. That would be a problem if, for example, you live in the US and wanted to claim a tax deduction for the tithe, in which case you must claim the deduction for the year the tithe was actually paid (cash based accounting).

This is indeed the very best solution to this! 

Accumulate a liability as you go, and resolve it with real transactions later on.

This case keeps coming back again and again, of wanting to do accrual accounting but wanting to do cash-based calculations. I think we need to have a long and separate discussion about cash vs accrual accounting and for sure we can come up with a creative solution that solves this problem right once and for all.

[Martin Blais]

On Mon, May 19, 2014 at 8:04 PM, Martin Michlmayr <t...@cyrius.com> wrote:

* Martin Blais <bl...@furius.ca> [2014-05-19 15:42]:

> If not, this is easily solved using subaccounts.

I must say I'm with John on this: virtual accounts are a much more
elegant solution in this case than what you propose.

I'm not sure if there's a way to achieve what John wants with tags.  I
chatted with Bradley Kuhn earlier today about Conservancy's use of
ledger and it seems he (mostly) manages without virtual accounts, but
I'm not 100% yet how things work there.

> This is a common case: Imagine you and your wife/life partner are both working
> professionals and share a joint account for convenience of making common
> expenses (e.g. you're going to a restaurant together and one of you pays but
> you want to generally split the expense, you also use those joint funds to pay
> for individual expenses, etc.). You want to account for each other's
> contributions separately. You would get a real bank account and create two
> subaccounts in it:
>
>   Assets:US:Bank:Joint:Husband
>   Assets:US:Bank:Joint:Wife

Just as an aside, if you're married and it's a joint account, there is
no "this is mine", "this is his/hers".  I know you're fond of
subaccounts, but I don't think this is a particularly good example.

Replace it with "roommates" if that works better for you.

> I tend to have accounts that look like this:
>
>   TYPE:COUNTRY:INSTITUTION:ACCOUNT:SUBACCOUNT

One thing I noticed in your examples is that you really like
subaccounts.  I'm not very fond of them...

I only use them where I need to.

(Emacs provides instant completion, so I don't mind long names in my own stuff.)

>   Expenses:Taxes:US:TY2014:Google:Federal
>   Expenses:Taxes:US:TY2014:Google:StateNY
>   Expenses:Taxes:US:TY2014:Google:CityNYC

... I don't see the advantage of putting your employer's name there.
If you really want that info, I'd just use a tag.  Same for the tax
year.

Tags are less flexible, though I think this may be a difference between how Beancount and Ledger do reporting. In Ledger, I get the impression that a user is always selecting some subset of transactions with expressions (from the questions on this forum) so using tags more liberally makes more sense. With Beancount, common usage is to just select your subset (I call them "views" in the web interface) - 99% of the time that's the current year - and click your way through the particular views on the web interface for that set of transactions. You don't change the matching transactions nearly as much... so having the account name in there provides that breakdown by default, which is nice. So maybe I favor tags less because of this.

For instance, if I used tags, I'd have to switch views to whichever tax year in order to view them. Right now I can just switch to the unfiltered view and click on any tax year's root account to view all transactions that relate to that tax year. The only difference is in the convenience of reporting.

After 2.0 is completely test-covered, I plan to factor out all the filtering code from the "views" that form the web interface, and build a command-line tool that allows you to filter and produce the same reports as the web interface but in ASCII format. Instead of producing HTML code, the rendering code will produce "report" objects which then get rendered in a separate step either in HTML or ASCII for the console. The subset of transactions will be selectable by a simple rules language on the command-line.  It should provide an interface perhaps more similar to Ledger's (though parsing time is somewhat slower than Ledger's I suspect, my huge personal file takes about 1.2 seconds to parse right now, which is still acceptable to me).

I guess it's just a matter of taste, but your account names seem
unwieldy to me.

> So what can we do to select across many dimensions while still keeping
> hierarchical account names?

Use tags?  Note that in ledger, tags can have values, e.g.

    ; foo: bar

> 2014-05-19 * "Booking tithe"
>   Assets:US:BofA:Checking         -300 USD
>   Assets:US:BofA:Checking:Tithe    300 USD

Now you're creating an account that doesn't exist, which I don't find
ideal.

--
Martin Michlmayr
http://www.cyrius.com/

[Martin Blais]

On Tue, May 20, 2014 at 12:15 AM, Martin Blais <bl...@furius.ca> wrote:

>   Expenses:Taxes:US:TY2014:Google:Federal
>   Expenses:Taxes:US:TY2014:Google:StateNY
>   Expenses:Taxes:US:TY2014:Google:CityNYC

... I don't see the advantage of putting your employer's name there.
If you really want that info, I'd just use a tag.  Same for the tax
year.

Tags are less flexible, though I think this may be a difference between how Beancount and Ledger do reporting. 

(more...) 

Another thing I forgot to mention is that tags have proved to be awfully easy to forget to insert. It's happened to me many times I've gone back in a file and just noticed a missing tag for an old transaction.  By having it baked in the account name, it forces me to put it in the right place.

The reason I want my employer name in this account name is to have a counter that produces the same numbers as on my W2 at the end of the year, thought it they were tagged, and I'd have an easy way to restrict transactions to only those tagged by this account, I could produce the number like that. I suppose it's similar... a tag applies to the entire transaction, however; a component in an account name only applies to its posting. In this case it would work out fine with tags IMO.

 

I guess it's just a matter of taste, but your account names seem
unwieldy to me.

> So what can we do to select across many dimensions while still keeping
> hierarchical account names?

Use tags?  Note that in ledger, tags can have values, e.g.

    ; foo: bar

Interesting... so they're like dimensions, really. 

It's more like meta-data on CL objects.

 

> 2014-05-19 * "Booking tithe"
>   Assets:US:BofA:Checking         -300 USD
>   Assets:US:BofA:Checking:Tithe    300 USD

Now you're creating an account that doesn't exist, which I don't find
ideal.

Doesn't bother me the least. I do it reasonably often. To me it's just a bucket that counts things.

[Stefano Zacchiroli]

On Mon, May 19, 2014 at 07:51:51PM -0400, Martin Michlmayr wrote:
> I essentially convert Assets:Reimbursable to Assets:Receivable. When
> I submit my expense report, I'm just awaiting payment from my
> employer.

So, do you have a way to automatically check that, for each expense
report, your employee has actually reimbursed you the exact amount
you've asked for? (It doesn't always happen with my employer, and when
it doesn't I want to subsequently record a Income:Reimbursement gain /
Expense:Reimbursement loss --- but I need a way to spot that first!)

I've a work-flow similar to yours, but the problem I'm facing is that
the Assets:Reimbursable (or Assets:Receivable FWIW) coalesces together
all trips, so it's hard to check if a specific trip balances to zero.
As an additional complexity, you might imagine a trip in which you've
been reimbursed 10$ more, and another in which you've been reimbursed
10$ less; they sum up to zero but I'd like to see both of them as
"errors" instead of concluding that everything is fine up to now.

I've tried various combinations of --group-by / --pivot, but thus far I
haven't found a precise solution to my problem. Any tips?

(Of course using sub-accounts would solve this problem if, for instance,
you start using one sub account per trip. But that seems overkill, not
really elegant, and forces yo explicitly declare tons of accounts if
you're using --strict.)

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 . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[Stefano Zacchiroli]

On Sat, May 17, 2014 at 11:37:01PM -0400, Martin Blais wrote:
> Now the truly, wonderfully great thing is how much *power* we have
> using our little text files. It's exhilarating. I can write a little
> script that renames my accounts automatically - I use xx-rename - look
> at it in visual diff, run bean-web on it, look at the reports, decide
> if I like it or not, revert and retry if I screwed up until I get it
> right.

Very much agreed. Although that comes at the price of either
sacrificing the correct surface syntax (e.g. right indentation,
alignment, etc.), or of writing quite complex text patching scripts.

In particular, I'm personally annoyed that when I batchly update ledger
files to rename accounts, transaction amounts easily become unaligned.
So, before (git) committing I go through them with ledger-mode and C-c
C-q them to fix alignment. I've written Python code to emit properly
aligned transactions when generating transaction templates from my bank
statements, but I haven't gone as far as doing that around plain old
sed.

Do your scripts take care of that too?

Do we need a ledger-sed or something of the sort? Or maybe something
simpler, such as a ledger-indent?

[Martin Blais]

On Tue, May 20, 2014 at 6:06 AM, Stefano Zacchiroli <za...@upsilon.cc> wrote:

On Sat, May 17, 2014 at 11:37:01PM -0400, Martin Blais wrote:
> Now the truly, wonderfully great thing is how much *power* we have
> using our little text files. It's exhilarating. I can write a little
> script that renames my accounts automatically - I use xx-rename - look
> at it in visual diff, run bean-web on it, look at the reports, decide
> if I like it or not, revert and retry if I screwed up until I get it
> right.

Very much agreed.  Although that comes at the price of either
sacrificing the correct surface syntax (e.g. right indentation,
alignment, etc.), or of writing quite complex text patching scripts.

I've just been living with the mess for the most part, but sometimes when I do that kind of rename I'll include the whitespace of the longer account so it remains aligned; it's a bad solution however, doesn't always work.

In particular, I'm personally annoyed that when I batchly update ledger
files to rename accounts, transaction amounts easily become unaligned.
So, before (git) committing I go through them with ledger-mode and C-c
C-q them to fix alignment.  I've written Python code to emit properly
aligned transactions when generating transaction templates from my bank
statements, but I haven't gone as far as doing that around plain old
sed.

Do your scripts take care of that too?

Not yet but it has been annoying me too.

 

Do we need a ledger-sed or something of the sort?  Or maybe something
simpler, such as a ledger-indent?

I need one.  I'll write one. This is an easy thing to do... I'll align on the first currency to the position of the longest account + a few chars.

[Martin Michlmayr]

* Martin Blais <bl...@furius.ca> [2014-05-20 00:45]:

> Another thing I forgot to mention is that tags have proved to be awfully
> easy to forget to insert.

That's true, although:

1) Most of my CVS->ledger process is semi-automated and adds the right
tags for me.

2) You could add account checks that ensure that certain tags are
there e.g. ledger could warn you that an "Employer" tag is needed when
there's an Income:Salary.

> a tag applies to the entire transaction, however; a component in an
> account name only applies to its posting. In this case it would work
> out fine with tags IMO.

I always mix up the transaction/posting terminology, but tags can be
fine grained:

2014-05-01 * Test
; :foo:
A £10.00
B ; :b:

In this example, "foo" applies to the whole thing whereas "b" only applies
to B.

$ ledger -f a reg tag foo
2014-05-01 Test A £10.00 £10.00
B £-10.00 0
$ ledger -f a reg tag b
2014-05-01 Test B £-10.00 £-10.00
$

[Martin Michlmayr]

* Stefano Zacchiroli <za...@upsilon.cc> [2014-05-20 11:59]:

> So, do you have a way to automatically check that, for each expense
> report, your employee has actually reimbursed you the exact amount
> you've asked for? (It doesn't always happen with my employer, and when
> it doesn't I want to subsequently record a Income:Reimbursement gain /
> Expense:Reimbursement loss --- but I need a way to spot that first!)

It's not automatic, but I can run an easy query:

ledger -f 2014 --effective --sort d reg receivable:xxx and tag 2014-03-21-boston-libreplanet

When I receive the reimbursement, the figure should go to zero. If
it stays > 0, you'd just account for this Expense:Reimbursement loss.

When I update the ledger file for my bank account, I see a payment
coming in from my employer. Based on the amount and time, I will know
whether it's a reimbursement or my salary. If it's a reimbursement,
I can look up with the query above if the amount matches (fortunately,
I don't have the same issue above - if my expert report is approved, I
get the correct figure).

And then you do:

2014-05-08 * Reimbursement for HP EEM TER 10216952
; :2014-04-28-hp-expenses:
; :HP:EEM:TER10216952:
Assets:Current:NatWest 67.05 GBP
Assets:Receivable:HP

In your case, if the money was off, it would be:

2014-05-08 * Reimbursement for ...
; :some-tag:
Assets:Bank 70.00 EUR
Expense:Reimbursement loss 10.00 EUR ; employer rejected taxi
Assets:Receivable:Employer -80.00 EUR

As an aside, one of my future projects is to add account, commodity
and tag directives, so I can use --explicit --pedantic. I'll
therefore change

; :HP:EEM:TER10216952:

to:

; :HP:
; EEM: TER10216952

because I don't want to define every TER* tag (There's a new one for
every expensive report). I just want to say that EEM is a valid tag
and the value has to be ^TER\d+$

> I've a work-flow similar to yours, but the problem I'm facing is that
> the Assets:Reimbursable (or Assets:Receivable FWIW) coalesces together
> all trips, so it's hard to check if a specific trip balances to zero.

I just tag all transactions with a tag that indicates where I store
receipts for that trips. This way, you can easily see what refers to
that trip only:

ledger -f 2014 --effective --sort d reg reimbu and tag 2014-03-21-boston-libreplanet

> As an additional complexity, you might imagine a trip in which you've
> been reimbursed 10$ more, and another in which you've been reimbursed
> 10$ less; they sum up to zero but I'd like to see both of them as
> "errors" instead of concluding that everything is fine up to now.

Just use tags.

[Martin Blais]

On Tue, May 20, 2014 at 12:45 AM, Martin Blais <bl...@furius.ca> wrote:

On Tue, May 20, 2014 at 12:15 AM, Martin Blais <bl...@furius.ca> wrote:

>   Expenses:Taxes:US:TY2014:Google:Federal
>   Expenses:Taxes:US:TY2014:Google:StateNY
>   Expenses:Taxes:US:TY2014:Google:CityNYC

I got the ordering of the last two components reversed here

it should have read:

>   Expenses:Taxes:US:TY2014:Federal:Google

>   Expenses:Taxes:US:TY2014:StateNY:Google
>   Expenses:Taxes:US:TY2014:CityNYC:Google

 

 

... I don't see the advantage of putting your employer's name there.
If you really want that info, I'd just use a tag.  Same for the tax
year.

Tags are less flexible, though I think this may be a difference between how Beancount and Ledger do reporting. 

(more...) 

Another thing I forgot to mention is that tags have proved to be awfully easy to forget to insert. It's happened to me many times I've gone back in a file and just noticed a missing tag for an old transaction.  By having it baked in the account name, it forces me to put it in the right place.

The reason I want my employer name in this account name is to have a counter that produces the same numbers as on my W2 at the end of the year, thought it they were tagged, and I'd have an easy way to restrict transactions to only those tagged by this account, I could produce the number like that. I suppose it's similar... a tag applies to the entire transaction, however; a component in an account name only applies to its posting. In this case it would work out fine with tags IMO.

So I thought about this more and I've come around and I think I agree with you. This would be better solved with more powerful filtering, that would avoid having to create an explicit subaccount, at least in this case, the subaccounts do work but in this case they do look at bit excessive (the advantage is that from the income statements I have the breakdowns by default). I've had the same quandry about payees, sometimes I've been keeping separate payments - esp. when they're regular - with subaccounts, and it has been annoying me a bit, like Expenses:Internet:TimeWarner. This should just be a query like "account:Expenses:Internet and payee:TimeWarner".

In the next iteration I'll define all my web views by a query expression instead of having fixed sets of dimensions... this will be nice, because the web interface will then support all its current views but for an arbitrary set of filters, and I should be able to provide any combination of the filters instead of creating links to all the combinations from the root page, It'll make it simpler and cleaner... if you want a specific subset of transactions that is not covered by the default links, you could type a query and create a new view on the fly. (OTOH you won't be able to just click your way through everything.) With this, I should be able to remove the subcategories and include out just those with that :Employer: component (by filtering on a component from the income account, e.g. component:Google) and that should provide the amounts to show on the W2 without having to resort to tags (that was my goal with those subaccounts, to get the expected W2 amounts for each source of revenue).

[Simon Michael]

On 5/17/14 10:10 AM, Lifepillar wrote:
> @Jostein: I have concluded some time ago that keeping virtual and
> non-virtual accounts distinct is a best practice (good tip for
> LedgerTips?).

Noted, thanks!

[Simon Michael]

On 5/17/14 11:50 PM, Martin Blais wrote:
> I wonder if a more general rule-of-thumb can be inferred here: "if you
> can make do with subaccounts, you should always favor that over tags or
> other mechanisms." Not sure if always true? But surely something to
> think about.

That has always been my default stance.

I'm only half way through this thread, but it contains a wealth of
information. We need a curator of useful mail list knowledge.

[John Wiegley]

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

> If the community accounts straddle the real accounts, you just filter by the
> CommunityX bit. Imagine for a moment the worse case, that all real accounts
> have all community subaccounts (in practice this rarely occurs, BTW,
> real-world structure is always more constrained than this deliberately
> chosen "full-product of dimensions" example):

> Assets:Real:Account1:Community1
> Assets:Real:Account1:Community2
> Assets:Real:Account1:Community3
> Assets:Real:Account1:Community4
> Assets:Real:Account1:Community5
> Assets:Real:Account2:Community1
> Assets:Real:Account2:Community2
> Assets:Real:Account2:Community3
> Assets:Real:Account2:Community4
> Assets:Real:Account2:Community5
> Assets:Real:Account3:Community1
> Assets:Real:Account3:Community2
> Assets:Real:Account3:Community3
> Assets:Real:Account3:Community4
> Assets:Real:Account3:Community5

They do fully straddle, and this solution above is just too ugly. Ledger
often opts for convenience over theoretic purity, and this is one of those
cases where I find it fully justified.

When I mentioned my motivation for virtual accounts, I said that part of it
was to make an onerous task less onerous so that I would actually keep up with
it. The huge amount of account splitting you've suggested above would make
the system laborious enough that I would give up on it. Hence, virtual
accounts.

John

[Martin Blais]

It's true that this is not a "nice" solution, but neither is using virtual accounts, because you give up the balancing check, which in my view is simply not an acceptable option... It might look nice, but it makes it really easy for you to make a mistake that goes undetected. That's not a solution either IMHO.

I'm curious as to the reasons behind this structure. Why is the structure of these projects managed in that way? Why do you need to have assets for each community project? Is there a better way to structure this? I.e., how does a company splice and dice their assets between their internal cost centers? (A similar problem.)  In my experience there's nothing that can't be sorted out by introducing a level of indirection or two, some intermediate buckets to reallocate the beans... can't the funds from all these real accounts be pooled to some intermediate non-real account and then entries issued to allocate budgets for each of the projects, which could then subtract their entries from their own dedicated budget accounts as they incur them? There has to be a way, I think if we discussed with a corporate accountant it might provide some insight that makes this example solved with regular postings.

In any case, I think we can come up with something better that achieves the goal of managing two sets of distinct categorization while still keeping the balances. Here's an idea: What if we marked some accounts (your real accounts in the example above) as "required" to book all of the entries that affect them into two well-defined but distinct subsets of postings, say A and B?  Then, when parsing, one would select the A set of postings or the B set of postings. Requiring all those transactions to have two sets of balancing postings would ensure that all the amounts in that account are correctly booked one way or the other. You're basically entering two categorizations in the same place for all transactions that related to some set of accounts, and then choosing one set of categorization across all of them, or another. This could be done early on, even during parsing.

I'm convinced we can come up with some other ideas to solve this problem that don't require giving up balancing.

[John Wiegley]

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

> It's true that this is not a "nice" solution, but neither is using virtual
> accounts, because you give up the balancing check, which in my view is
> simply not an acceptable option... It might look nice, but it makes it
> really easy for you to make a mistake that goes undetected. That's not a
> solution either IMHO.

I have the balance check with --real. That's the only balance I truly need to
care about, since any other balance is not "real".

> I'm curious as to the reasons behind this structure. Why is the structure of
> these projects managed in that way? Why do you need to have assets for each
> community project? Is there a better way to structure this? I.e., how does a
> company splice and dice their assets between their internal cost centers? (A
> similar problem.)  In my experience there's nothing that can't be sorted out
> by introducing a level of indirection or two, some intermediate buckets to
> reallocate the beans... can't the funds from all these real accounts be
> pooled to some intermediate non-real account and then entries issued to
> allocate budgets for each of the projects, which could then subtract their
> entries from their own dedicated budget accounts as they incur them? There
> has to be a way, I think if we discussed with a corporate accountant it
> might provide some insight that makes this example solved with regular
> postings.

I don't know. It's been a while since I held that position, so I haven't
faced that particular necessity of late.

> In any case, I think we can come up with something better that achieves the
> goal of managing two sets of distinct categorization while still keeping the
> balances. Here's an idea: What if we marked some accounts (your real
> accounts in the example above) as "required" to book all of the entries that
> affect them into two well-defined but distinct subsets of postings, say A
> and B?  Then, when parsing, one would select the A set of postings or the B
> set of postings. Requiring all those transactions to have two sets of
> balancing postings would ensure that all the amounts in that account are
> correctly booked one way or the other. You're basically entering two
> categorizations in the same place for all transactions that related to some
> set of accounts, and then choosing one set of categorization across all of
> them, or another. This could be done early on, even during parsing.

What would this look like?

> I'm convinced we can come up with some other ideas to solve this problem
> that don't require giving up balancing.

I'd be interested to see your ideas!

John

[Eric Abrahamsen]

Martin Michlmayr <t...@cyrius.com> writes:

> * Eric Abrahamsen <er...@ericabrahamsen.net> [2014-05-19 09:59]:
>> ~ Monthly
>> ; Payee: Tax Dodgers, Inc
>> Assets:Merchants:5231 7000 RMB ; regular salary part
>> Assets:Receivable 3000 RMB ; receipts
>> Income:Salary
>
> Is this just an example or something you actually use? I'm asking
> becaue I don't understand this transactions. Why would
> Assets:Receivable go up every month? Also, what it
> Assets:Merchants:5231? Surely, if you're paid monthly, your bank
> account would go up, and not some Assets:Merchants account.

Yup, that's the real transaction: "Merchants" is the name of my bank :)

>> After a few weeks I have 1920.90 RMB in my virtual receipt account, and
>> I hand them in (but they haven't paid me the reimbursement yet):
>>
>> 05/04 ! Tax Dodgers, Inc
>> * (Assets:Receipts) = 0 RMB
>> Assets:Merchants:5231 1920.90 RMB
>> Assets:Receivable
>>
>> When the reimbursement comes through I clear the whole transaction, and
>> add an aux date.
>
> This whole approach looks a bit complicated and fragile to me. I'll
> explain the workflow I use. I'm not sure it's better, but it works
> for me:

[...]

> I think this workflow follows a logical approach: when you spend
> money, you have an asset that can be reimbursed (Assets:Reimbursable).
> When you do an expensive report, it becomes a receivable
> (Assets:Receivable). And finally, this receivable goes away when you
> get paid.

The main difference is, in my case it _isn't_ a reimbursement -- it is
money spent entirely on my own behalf. The receipts are simply an excuse
for the company to give out funds without paying payroll taxes. To me
these receipts are the perfect definition of "virtual": no money is
moving between accounts, but at the same time I'd like to know how much
I've got, and how much I still need. The manual balancing is a bit
questionable, but it seems like a fine trade-off.

> Now I understand that it might be slightly different if I were a
> contractor rather than an employee. In that case, I can see an
> argument for booking these expenses a actual Expenses: rather than
> Assets:Reimbursable. (After all, they are expenses for your business
> regardless of whether you get reimbused or not.)
>
> You could tag with them with your client, and then use
> ledger reg Expenses: tag client
> to get a list in order to bill them. This would just be income and
> not a reimbursement as with a true employee.
>
> I believe this approach should work for most people. Now in your
> case, we need to be slightly more creative. It sounds as if got paid
> $40 if you had a receipt for $40, even though you only spent $20 (no
> need to confirm). I have one idea how to handle this. It's not
> currently supported by ledger, but it's a feature that I realized a
> few days ago would be useful.
>
> It would be nice if ledger would allow you to run 'reg' or 'bal' on
> tags. In order words, you could have:

[...]

I tried ("Project" is another tag in my files):

$ ledger reg --limit 'tag("Project")'

And it worked correctly. I don't know if that would do what you're
trying to achieve below, with keeping track of nights, but maybe give it
a shot?

[Martin Blais]

It does, and it feels weird for a reason. A big reason to use the DE method is to avoid errors due to manual balances.

I think you're just not being creative enough with it. Here's an alternative system that solves your accounting problem without resorting to virtual accounts: just count the receipts themselves.

option "operating_currency" "RMB"

2014-01-01 open Assets:Merchants:C5231
2014-01-01 open Income:Salary
2014-01-01 open Expenses:Food:Restaurant
2014-01-01 open Assets:Cash

;; Amount of receipts I was promised I could gather for payment.
2014-01-01 open Assets:Receipts:Allowable		RECEIPTS

;; Amount of receipts I accumulated in envelope, pending to be
;; submitted to Tax Dodgers Inc.
2014-01-01 open Assets:Receipts:Pending 		RECEIPTS

;; Amount of cash receipts already submitted to Tax Dodgers, waiting
;; to be received in cash.
2014-01-01 open Assets:Receipts:Receivable		RMB


2014-04-12 * "Payment of salary"
    Assets:Merchants:C5231          7000 RMB ; regular salary part
    Assets:Receipts:Allowable       3000 RECEIPTS
    Income:Salary


;; Then I go to dinner and get a receipt. I store this in an envelope.

2014-04-13 * "Ito-Yokado"
    Expenses:Food:Restaurant        143.10 RMB
    Assets:Cash
    Assets:Receipts:Allowable       -143.10 RECEIPTS
    Assets:Receipts:Pending         143.10 RECEIPTS


;; Some more expensive dinner. More receipts.

2014-04-14 * "Tiandi Yijia"
    Expenses:Food:Restaurant        1777.80 RMB
    Assets:Cash
    Assets:Receipts:Allowable       -1777.80 RECEIPTS
    Assets:Receipts:Pending         1777.80 RECEIPTS


;; After a few weeks I have 1920.90 RMB in my virtual receipt account, and
;; I hand them in (but they haven't paid me the reimbursement yet):

2014-05-04 * "Submit my receipts to Tax Dodgers, Inc"
    Assets:Receipts:Pending	-1920.90 RECEIPTS @ 1 RMB
    Assets:Receipts:Receivable


;; Later on they pay you some of that receivable:

2014-05-10 * "Incomplete payment for submitted receipts"
    Assets:Receipts:Receivable    -1500 RMB
    Assets:Merchants:C5231

This file will run without errors through Beancount. 

I've baked and attached the reports in attachment.

You have an account to track how much you've been promised, how much you've accumulated, how much you've submitted and is receivable in cash. Your income account will have RMB and RECEIPT units so you can easily see how much of each composed your compensation. Does this work?

Here's the ugly:  my method above requires you to insert two postings to the allowable expenses, instead of one, like in your method. I don't think it's that big a deal, but if you want we can fix this and even improve on the original method: you can write a tiny loader plugin that detects a particular tag and automatically inserts the necessary postings to those entries marked with the tag, say #REIMBURSE (the amount should be the sum of the positive RMB amounts on the existing ones). So now you can just do this:

2014-04-14 * "Tiandi Yijia"  #REIMBURSE
    Expenses:Food:Restaurant        1777.80 RMB
    Assets:Cash

Which will automatically generate this:

2014-04-14 * "Tiandi Yijia"  #REIMBURSE
    Expenses:Food:Restaurant        1777.80 RMB
    Assets:Cash
    Assets:Receipts:Allowable       -1777.80 RECEIPTS
    Assets:Receipts:Pending         1777.80 RECEIPTS

Beancount allows you to load a custom Python module that will filter the entries after parsing and modify them to your heart's content (this is probably 20 LOC to write in total). A callback function gets invoked that receives a list of entries, and it spits out a modified list of entries. A few examples here:

https://hg.furius.ca/public/beancount/file/tip/src/python/beancount/plugins

Ledger probably has a similar feature (and if not you could hack the codebase or write a script to convert the source).

Virtual accounts are a crutch. I say: don't use them. If you hadn't had them in the first place, you would have come up with a similar method yourself.

(Finally, a disclaimer: this email is not to suggest or help you carry out tax evasion activities; you should probably consult a tax lawyer about how best to treat those "gifts". This message merely aims to help solve your counting problem in the context of text-based bookkeeping software.)

[Eric Abrahamsen]

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


[...]

> I think you're just not being creative enough with it. Here's an
> alternative system that solves your accounting problem without
> resorting to virtual accounts: just count the receipts themselves.
>
>
>
> option "operating_currency" "RMB"
>
> 2014-01-01 open Assets:Merchants:C5231
> 2014-01-01 open Income:Salary
> 2014-01-01 open Expenses:Food:Restaurant
> 2014-01-01 open Assets:Cash
>
> ;; Amount of receipts I was promised I could gather for payment.
> 2014-01-01 open Assets:Receipts:Allowable RECEIPTS
>
> ;; Amount of receipts I accumulated in envelope, pending to be
> ;; submitted to Tax Dodgers Inc.
> 2014-01-01 open Assets:Receipts:Pending RECEIPTS
>
> ;; Amount of cash receipts already submitted to Tax Dodgers, waiting
> ;; to be received in cash.
> 2014-01-01 open Assets:Receipts:Receivable RMB

[...]

> You have an account to track how much you've been promised, how much
> you've accumulated, how much you've submitted and is receivable in
> cash. Your income account will have RMB and RECEIPT units so you can
> easily see how much of each composed your compensation. Does this
> work?

This does work! When I was thinking this through in the beginning, I was
put off by proliferating accounts: I felt like I should just have one
account for receipts (it's just one value, after all), one account for
income, one "cheater" account for receivables, and views on everything
else (the fancy footwork with the receipts) should be a function of how
I write my reports.

You make a persuasive argument with the above, though, and I'll give
this some serious thought. Multiple sub-accounts of Assets:Receipts does
sound like a good idea.

> Here's the ugly:  my method above requires you to insert two postings
> to the allowable expenses, instead of one, like in your method.

[...]

This is what I was messing with in another branch of this thread,
talking to John about automating transactions using tags/metadata. That
doesn't look like it will work in the short term, but maybe it will in
the future, and when it does it will simplify things much as your
pre-processing scheme would: add a simple tag to "receipt-able"
transactions, and the automation does the rest. I'm not likely to dive
into beancount any time soon (I'm still re-wrapping my head around
plain ledger, after an absence), but I do appreciate the thought and
effort that went into your reply.

> (Finally, a disclaimer: this email is not to suggest or help you
> carry out tax evasion activities; you should probably consult a tax
> lawyer about how best to treat those "gifts". This message merely
> aims to help solve your counting problem in the context of text-based
> bookkeeping software.)

Lord knows I wish this wasn't necessary. I console myself, as one often
does in China, with the thought that everyone else is doing the same
thing.

Thanks again,
Eric

[John Wiegley]

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

> Virtual accounts are a crutch. I say: don't use them. If you hadn't had them
> in the first place, you would have come up with a similar method yourself.

If people don't want to use them, that's fine. But Ledger is not an
accounting tool; it's a tool that may be used to do accounting. As such, I
believe virtual accounts serve a role that others with non-accounting problems
may wish to fill.

That said, there is a reason for --strict, and perhaps one of its meaning
should be to uphold DE principles. Or maybe a --double-entry switch to
disallow anything which might bend those rules in any way.

John

[Jostein Berntsen]

On Saturday, May 17, 2014 9:10:04 PM UTC+2, Jostein Berntsen wrote:

On 16.05.14,22:06, John Wiegley wrote:
> >>>>> Jostein Berntsen <jbe...@broadpark.no> writes:
>
> > Is there a reason for this?
>
> This sounds rather odd, and may be a bug.
>
> John
>
> > Example data:
>
> > 2014/03/05 * Opening Balance
> >         Assets:Project:Budget   1000000,00 NOK
>
> > Equity:Opening Balance
>
> > =  /TeamDev/
> >              (Assets:Project:Budget)   (1000,00 NOK * amount)
>
> > Example command and output:
>
> > ledger reg -s budget
> > While handling posting from
> > "/home/jostein/Documents/Finans/ledger/project.dat", line 16:
> >> (Assets:Project:Budget)   (1000,00 NOK * amount)
> > Error: 'equity' cannot accept virtual and non-virtual postings to the same
> > account
>

For some reason these commands gives the right output:

ledger bal budget
ledger reg budget

But these give the error above:

ledger reg -s budget
ledger reg -M budget

My intention is to add hours like in the entry below to the Budget account
and calculated into a total cost in NOK. How is the best way to do this?

2014/04/17 Resource 1 - Week 16, 2014 Book
    ; Week16: 2014
    ; Resource1: John James
    ; TeamDev: Workshop and plannning
    Allocation:Resources:TeamDev     -15 H  
         Assets:Project:Budget


Jostein

I solved this by entering this code for the automated transactions instead:

=   /TeamDev/
        Assets:Allocation:Hours   (1000,00 NOK * amount)
        Assets:Project:Budget   (-1000,00 NOK * amount)

=   /TeamTest/
        Assets:Allocation:Hours   (800,00 NOK * amount)
        Assets:Project:Budget   (-800,00 NOK * amount)

and:

2014/04/18 Resource 1 - Week 16, 2014
    ; Week16: 2014
    ; Resource1: John James
    Expenses:Resources:TeamDev     15 H; Hours
         Assets:Allocation:Hours


2014/04/18 Resource 2 - Week 16, 2014
    ; Week16: 2014
    ; Resource2: Jim Ding
    Expenses:Resources:TeamDev     30 H; Hours
         Assets:Allocation:Hours


Jostein

[Martin Blais]

On Tue, May 20, 2014 at 9:00 AM, Martin Blais <bl...@furius.ca> wrote:

On Tue, May 20, 2014 at 6:06 AM, Stefano Zacchiroli <za...@upsilon.cc> wrote:

On Sat, May 17, 2014 at 11:37:01PM -0400, Martin Blais wrote:In particular, I'm personally annoyed that when I batchly update ledger

files to rename accounts, transaction amounts easily become unaligned.
So, before (git) committing I go through them with ledger-mode and C-c
C-q them to fix alignment.  I've written Python code to emit properly
aligned transactions when generating transaction templates from my bank
statements, but I haven't gone as far as doing that around plain old
sed.

Do your scripts take care of that too?

Not yet but it has been annoying me too.

 

Do we need a ledger-sed or something of the sort?  Or maybe something
simpler, such as a ledger-indent?

I need one.  I'll write one. This is an easy thing to do... I'll align on the first currency to the position of the longest account + a few chars.

Here's a quick and dirty one that works for my syntax:

https://hg.furius.ca/public/beancount/file/743ca856e985/experiments/bean-format

(or as  beancount/experiments/bean-format  in beancount source code)

I'd be happy to extend it to support Ledger syntax to (or accept a patch).

 

[Stefano Zacchiroli]

[ sorry for catching up with such an old thread only now ]

I'm always struggling between tags and (sub-)accounts, and I'd love to
be able to apply such a general rule.

The main problem with (sub-)accounts, though, is that if you want to use
--strict (which is a good general sanity rule), you have to declare all
of them. And that quickly becomes painful.

I was wondering if some of the pain points could be relieved by allowing
wild-card account declarations, e.g.:

account Foo:Bar:Baz:*

meaning that under that hierarchy account names are free for all. That
would partially defeat the usefulness of --strict, of course. But it
will do so only within a limited scope, IMHO striking a good compromise.

Has something like that been ever considered/discussed? If so, I'd
welcome pointers to the relevant discussions, to catch up with community
knowledge on this issue.

[Martin Blais]

On Fri, Jul 4, 2014 at 5:55 AM, Stefano Zacchiroli <za...@upsilon.cc> wrote:

[ sorry for catching up with such an old thread only now ]

On Wed, May 21, 2014 at 08:08:37AM -0700, Simon Michael wrote:
> On 5/17/14 11:50 PM, Martin Blais wrote:
> >I wonder if a more general rule-of-thumb can be inferred here: "if you
> >can make do with subaccounts, you should always favor that over tags or
> >other mechanisms." Not sure if always true? But surely something to
> >think about.
>
> That has always been my default stance.
>
> I'm only half way through this thread, but it contains a wealth of
> information. We need a curator of useful mail list knowledge.

I'm always struggling between tags and (sub-)accounts, and I'd love to
be able to apply such a general rule.

The main problem with (sub-)accounts, though, is that if you want to use
--strict (which is a good general sanity rule), you have to declare all
of them. And that quickly becomes painful.

I don't feel that pain at all. One creates new accounts only rarely, adding new declarations is a very minor annoyance, and it provides the system with useful information to help it tell you when you make mistakes.  Closing accounts also provides useful information for reporting purposes, i.e., an account closed before the reporting period should not have to appear in a report.

FWIW, Beancount is always strict (there is no strict vs. non-strict option and I like it like that).

[Stefano Zacchiroli]

On Fri, Jul 04, 2014 at 11:52:49AM -0400, Martin Blais wrote:
> I don't feel that pain at all. One creates new accounts only rarely,
> adding new declarations is a very minor annoyance, and it provides the
> system with useful information to help it tell you when you make
> mistakes. Closing accounts also provides useful information for
> reporting purposes, i.e., an account closed before the reporting
> period should not have to appear in a report.

Does Beancount and/or Ledger have any explicit way of closing an
account? In Ledger-cli-land, I'm aware of the 'account' directive, that
pre-declares an account, but I can't find anything in the manual about
explicitly closing an account.

> FWIW, Beancount is always strict (there is no strict vs. non-strict
> option and I like it like that).

I like that!

[Martin Blais]

On Sat, Jul 5, 2014 at 3:52 AM, Stefano Zacchiroli <za...@upsilon.cc> wrote:

On Fri, Jul 04, 2014 at 11:52:49AM -0400, Martin Blais wrote:
> I don't feel that pain at all. One creates new accounts only rarely,
> adding new declarations is a very minor annoyance, and it provides the
> system with useful information to help it tell you when you make
> mistakes.  Closing accounts also provides useful information for
> reporting purposes, i.e., an account closed before the reporting
> period should not have to appear in a report.

Does Beancount and/or Ledger have any explicit way of closing an
account? In Ledger-cli-land, I'm aware of the 'account' directive, that
pre-declares an account, but I can't find anything in the manual about
explicitly closing an account.

In Beancount, you use the "close" directive:

  2006-05-01 open Assets:US:HSBC:Checking

  ...

  2012-06-10 close Assets:US:HSBC:Checking

This directive is used in a couple of ways:

- It barfs an error message if you have transactions after it for that account (it's a sanity check).

- It helps filter which accounts are still active. This is especially useful as your ledger grows in time, as there are accounts that don't exist anymore that you just don't want to see in reports for years that follow their closure.

At the moment, once an account is closed, you cannot reopen it.

http://furius.ca/beancount/doc/cheatsheet

 

> FWIW, Beancount is always strict (there is no strict vs. non-strict
> option and I like it like that).

I like that!

I do it as an attempt to minimize the number of available options.

[Dave Wells]

On Saturday, May 17, 2014 6:04:26 PM UTC-7, Martin Blais wrote:

It would be useful to build a list of real-world use cases of virtual postings and see if they can all be solved without or not - make a compelling argument about the need for virtual postings.

I am just getting started with Ledger and hit the issue that originally started this thread. Basically, I'm trying to use virtual transactions for budget reasons, to spread the cost of something over time. For example:

2014/06/17 Awesome Trip

    Expenses:Travel                           $1000.00

    [Expenses:Travel]                        $-1000.00

    [Assets:Reimbursements:Vacation]     $1000.00

    Assets:Cash:Checking                    $-1000.00

; Pay down balance of Assets:Reimbursements:Vacation over time

2014/07/01 Awesome Trip

    [Expenses:Travel]                           $100.00

    [Assets:Reimbursements:Vacation]     $-100.00

 2014/08/01 Awesome Trip

    [Expenses:Travel]                           $100.00

    [Assets:Reimbursements:Vacation]     $-100.00

; etc.

 

For this use case, real and virtual make a lot of sense to me: --real shows when I actually spent the money, but omitting --real lets me virtually spread the cost and work within my budgets. But since Expenses:Travel has both real and virtual postings, the budget report (ledger --budget --monthly register ^expenses) only works with --real, which defeats the whole purpose.

I believe that in this case I could use effective dates, but that would quickly get tiresome if there are many smaller transactions rather than a single big one as above; I prefer to be able to toss the expenses into a bucket and then pay it down as I can. Since I'm strictly using balanced virtual transactions I think tags would work here, but would love some feedback.

Any tips would be much appreciated!

Dave

[Chris Bennett]

Hi there,

I've been using ledger for a few years now and share a similar
enthusiasm to Martin Blais (I've been reading archives to update my
current best practices and can sense his passion in the emails he
writes :)). I've stumbled on this thread from a few months ago and
thought I'd contribute what I do which may help with this
substitution/alignment issue.

> I've just been living with the mess for the most part, but sometimes when I
> do that kind of rename I'll include the whitespace of the longer account so
> it remains aligned; it's a bad solution however, doesn't always work.

I'm using ledger-cli, and for transaction lines, I use a
space-indented prefix, followed by account name, then a tab, then the
tx amount. Using vim, and setting tabstop to a wide value (say 60 for
me), this results in perfectly aligned tx account and amount values
throughout a whole ledger file.

e.g
2014/08/18 Payslip
<sp><sp>Assets:Bank:Savings<tab>$200.00
<sp><sp>Income:Job:Employer<tab>$200.00

If you are mass replacing, a sed expression like:

sed -i -e 's/^ Income:Job:Employer\t/ Income:Job:RenamedEmployer\t/' savings.ledger

doesn't alter the alignment at all :) And you could easily write some
sugar-shell to reduce the inputs to just "oldname newname" and have
the script deal with the spec.

Don't know if that helps anyone that is having trouble with aligning,
but it's been non-issue with what I do above.

Regards,

Chris