When to use tags and when to create separate account?

[mpl...@gmail.com]

Guys hi,

As the title says i wonder when to use tags and when to create separate account?

I have several separate ecommerce sites, all have same checking account and i would like to track profit, expenses, etc separately to see performance of each site.

What i do now is something like this:

Income:Business:ECOM1   
Expenses:Business:ECOM1:Ads
Expenses:Business:ECOM1:Hosting

Income:Business:ECOM2  
Expenses:Business:ECOM2:Ads
Expenses:Business:ECOM2:Hosting

Is this right way to do it?

Or should i use same accounts

Income:Business:  
Expenses:Business:Ads
Expenses:Business:Hosting

and just use tags #ECOM1 and #ECOM2 ?

[Justus Pendleton]

On Saturday, April 21, 2018 at 7:37:28 PM UTC+7, mpl...@gmail.com wrote:

As the title says i wonder when to use tags and when to create separate account?

I don't know if there's really any set best practice. I use tags for (relatively) short lived things. For instance, if I'm on a vacation, it all goes to Expenses:Vacation but I'll tag each vacation separately #iceland #hongkong etc. Or if I'm trying to get any kind of "cross-account" view on something. Say I'm doing a home remodel. I would tag everything as #remodel even if various expenses might come from multiple accounts (Expense:Tax, Expense:Legal, Expense:etc....).

In your case since it is more of an on-going thing I would create sub accounts as you've done. But that's just me.

One good thing about plaintext accounting is that it is (somewhat) easy to massively restructure everything if you ever change your mind.

[Martin Michlmayr]

* mpl...@gmail.com <mpl...@gmail.com> [2018-04-21 05:37]:

> As the title says i wonder when to use tags and when to create
> separate account?

There is no right or wrong. Some people like to put a lot of
information into their account names while others prefer simple account
names. My general impression is that professional accounts prefer a
simple chart of accouts, though.

> Or should i use same accounts
>
> Income:Business:
> Expenses:Business:Ads
> Expenses:Business:Hosting
>
> and just use tags #ECOM1 and #ECOM2 ?

Personally, I like simple account names so I'd go with that plus tags.

Ledger has an interesting concept called pivot which allows you to do
both. It allows you to make metadata information to become part of
the account name.

e.g.:

2018-04-22 * Income from ABC
Assets:Bank 100.00 EUR
Income:Business:Hosting -100.00 EUR
; Customer: ABC

2018-04-22 * Income from CDE
Assets:Bank 150.00 EUR
Income:Business:Hosting -150.00 EUR
; Customer: CDE

Normal balance:

ledger -f a bal income
-250.00 EUR Income:Business:Hosting

Balance with --pivot:

ledger -f a bal income --pivot Customer
-250.00 EUR Customer
-100.00 EUR ABC:Income:Business:Hosting
-150.00 EUR CDE:Income:Business:Hosting
--------------------
-250.00 EUR

The same would be easy to do with a beancount plugin. I don't know if
anyone has done it already. If not, I intend to create one in the
near future.

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

[Martin Blais]

On Sun, Apr 22, 2018 at 8:30 AM, Martin Michlmayr <t...@cyrius.com> wrote:

* mpl...@gmail.com <mpl...@gmail.com> [2018-04-21 05:37]:
> As the title says i wonder when to use tags and when to create
> separate account?

There is no right or wrong.  Some people like to put a lot of
information into their account names while others prefer simple account
names.  My general impression is that professional accounts prefer a
simple chart of accouts, though.

> Or should i use same accounts
>
> Income:Business:   
> Expenses:Business:Ads
> Expenses:Business:Hosting
>
> and just use tags #ECOM1 and #ECOM2 ?

It's an arbitrary choice.

The true question is about how you want to query it.

Consider this: Beancount essentially produces a single table of postings whose fields are always joined with the fields of the transaction which contains them.

e.g. 

  <transaction-fields> <posting-fields>

It all boils down to how you want to aggregate them.

You can aggregate them by account name.

You can aggregate them by tag.

You can aggregate them by combinations of those (and other fields as well).

The default reports (balance sheet, income statement) use the account names to produce aggregations, so that's one consideration, but it doesn't matter much, as in a future version of Beancount, the reports will be produced by queries as well (more easily customizable in that way).

You can achieve the same thing already with a group-by on the (account, meta) pair:

plugin "beancount.plugins.auto"

2018-04-22 * "Income from ABC"

    customer: "ABC"

    Assets:Bank                100.00 EUR

    Income:Business:Hosting   -100.00 EUR

2018-04-22 * "Income from CDE"

    customer: "CDE"

    Assets:Bank                150.00 EUR

    Income:Business:Hosting   -150.00 EUR

;; bean-query /home/blais/r/q/beancount-data/user/michlmayr/groupby.beancount

;; "select account, entry_meta('customer'), sum(position) where account ~ 'Income' group by 1, 2"

;;         account         ent sum_positio

;; ----------------------- --- -----------

;; Income:Business:Hosting ABC -100.00 EUR

;; Income:Business:Hosting CDE -150.00 EUR

[Martin Michlmayr]

* Martin Blais <bl...@furius.ca> [2018-04-22 17:31]:

> You can achieve the same thing already with a group-by on the (account,
> meta) pair:

Doh, I should have thought of that. That's a good example of why BQL
is a great idea.

[mpl...@gmail.com]

Thank you for all your replies guys! I will stick to separate accounts for now, but will sure play with group-by feature.

[Martin Blais]

On Sun, Apr 22, 2018 at 5:43 PM, Martin Michlmayr <t...@cyrius.com> wrote:

* Martin Blais <bl...@furius.ca> [2018-04-22 17:31]:
> You can achieve the same thing already with a group-by on the (account,
> meta) pair:

Doh, I should have thought of that.  That's a good example of why BQL
is a great idea.

The most relevant insight in this whole thing is IMHO the fact that you can reduce all these accounting tasks to a single query on a single table (a join of transaction fields and postings fields). I started with the SQL thing not really knowing how far it would take us, but it turns out it pretty much can do it all, and you can factor out the reporting rendering code into two functions: one to render journals (generic, just a table), and one to render trees of accounts (implies a hierarchy from one particular column). Actual pivot tables (e.g., expenses by month) can be a post-processing of a group-by query with two columns (e.g., account, month-of-date, rendering sum(postings) in the cells).

[Martin Michlmayr]

* Martin Blais <bl...@furius.ca> [2018-04-22 17:31]:

> You can achieve the same thing already with a group-by on the (account,
> meta) pair:
>
> plugin "beancount.plugins.auto"
>
> 2018-04-22 * "Income from ABC"
> customer: "ABC"
> Assets:Bank 100.00 EUR
> Income:Business:Hosting -100.00 EUR
>
> 2018-04-22 * "Income from CDE"
> customer: "CDE"
> Assets:Bank 150.00 EUR
> Income:Business:Hosting -150.00 EUR
>
>
> ;; bean-query
> /home/blais/r/q/beancount-data/user/michlmayr/groupby.beancount
> ;; "select account, entry_meta('customer'), sum(position) where account ~
> 'Income' group by 1, 2"
> ;; account ent sum_positio
> ;; ----------------------- --- -----------
> ;; Income:Business:Hosting ABC -100.00 EUR
> ;; Income:Business:Hosting CDE -150.00 EUR

Given this example, is where a way to limit the query where sum(position)
is < 125?

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