Live data from Hacker News

Plain Text Accounting, a guide to Ledger and friends

plaintextaccounting.org

71–80 of 126 posts

Re: Plain Text Accounting, a guide to Ledger and friends

#71
post #28
post #10

Earlier quoted context omitted.

> One of the hard problems in personal finance is data capture With hledger and vim, I typically search and copy a previous similar transaction, then search and copy similar items. I have a keybinding to change the date, so like 3\d changes the date of the transaction I copied to 3 days ago. Overall, being proficient in vim, capture takes very few keystrokes. Since the files are plain text, I can easily e.g. list all…

This is already after the data capture part. The hard part is to remember every little transaction I had until I have vim at my hand. The only solution seems to be working more or less is to take out my phone and type it as soon as the transaction happened. And I won't try to use vim on phone ever again..

This is one of the reasons I use YNAB (for shared household budget) and a Google sheet (for personal budget).

I usually just hold onto the receipt for whatever I do until the end of the working day and get it entered that night. But if a receipt or my pay app isn't an option then I can enter the transaction right there on the phone before I forget.

Re: Plain Text Accounting, a guide to Ledger and friends

#72

I've used the ledger-likes extensively, and they have two major problems: (1) One of the hard problems in personal finance is data capture and input validation. Programs like QuickBooks and Xero don't just hide the GL because they're being mean, they're doing it because even experienced bookkeepers make mistakes on the general ledger all the time. "Since it's a text file it's easy to read" solves exactly the wrong pr…

I dunno, I kinda disagree: I am not writing transactions manually, they are written by my brokerage parser, bank statement parser, blockchain parser, etc.

The reporting and analytics functionality of the ledger-likes is AFAICT unrivaled, and is the REAL reason to use them (not the ostensibly easy-to-use “plain text” general ledger aspect, about which I agree with you)

Re: Plain Text Accounting, a guide to Ledger and friends

#73
post #58

Earlier quoted context omitted.

I'm not that familiar with the theory, in my case I just got started and now I'm used to it. Just to take the last example: 2021-03-20 Sprouts expenses:food:groceries $100 assets:cash $40 assets:checking This means you took 140 from your checking account, withdrew 40 that you now have in cash, and spent 100 in groceries. Does that still make no sense?

Honestly no. When I first read it I thought you'd spent 140 on sprouts which I thought was excessive, but each to their own. Even though you've explained it I'm still struggling to make sense of it. The 3 indented lines don't related at all in an intuitive manner at least for me.

Understandable, they are using transaction balancing / elision

What they should be showing beginners is:

    2021-03-20 Sprouts
        expenses:food:groceries  $100
        assets:cash               $40
        assets:checking         $-140
How’s that?

Re: Plain Text Accounting, a guide to Ledger and friends

#75
post #58

Earlier quoted context omitted.

I'm not that familiar with the theory, in my case I just got started and now I'm used to it. Just to take the last example: 2021-03-20 Sprouts expenses:food:groceries $100 assets:cash $40 assets:checking This means you took 140 from your checking account, withdrew 40 that you now have in cash, and spent 100 in groceries. Does that still make no sense?

Honestly no. When I first read it I thought you'd spent 140 on sprouts which I thought was excessive, but each to their own. Even though you've explained it I'm still struggling to make sense of it. The 3 indented lines don't related at all in an intuitive manner at least for me.

I don't think the file format above is especially conductive to learning. In my experience, most people learn double-entry bookkeeping with T accounts; debit is on the left, credit is on the right, and total credit has to equal total debit.

If you're interested, this seems like a fairly decent guide: https://www.open.edu/openlearn/money-business/introduction-b...

Re: Plain Text Accounting, a guide to Ledger and friends

#76
post #58

Earlier quoted context omitted.

I'm not that familiar with the theory, in my case I just got started and now I'm used to it. Just to take the last example: 2021-03-20 Sprouts expenses:food:groceries $100 assets:cash $40 assets:checking This means you took 140 from your checking account, withdrew 40 that you now have in cash, and spent 100 in groceries. Does that still make no sense?

Honestly no. When I first read it I thought you'd spent 140 on sprouts which I thought was excessive, but each to their own. Even though you've explained it I'm still struggling to make sense of it. The 3 indented lines don't related at all in an intuitive manner at least for me.

A possible source of confusion is that in this context, "Sprouts" is likely the name of a supermarket (not a type of food).

Re: Plain Text Accounting, a guide to Ledger and friends

#77

I've used the ledger-likes extensively, and they have two major problems: (1) One of the hard problems in personal finance is data capture and input validation. Programs like QuickBooks and Xero don't just hide the GL because they're being mean, they're doing it because even experienced bookkeepers make mistakes on the general ledger all the time. "Since it's a text file it's easy to read" solves exactly the wrong pr…

For data capture, what can help is just not aiming to record every cheque.

Record significant spendings, and account the rest as "other" - it should be the amount allowing to balance the ledger, given the current assets, income, and the significant spendings.

My problem with ledger was the absence of correct support for multi currency accounting.

Re: Plain Text Accounting, a guide to Ledger and friends

#78

>Most (not all) plain text accounting implementations use signed amounts instead of debits and credits. This makes them "double entry light" perhaps, but it has been a rather successful simplification, intuitive to most newcomers. They shouldn't do themselves down. I am an accountant and I have used several large systems that do exactly this in the database. It is also by far the preferred way to export a trial balan…

When you say "it is the norm in the industry" do you mean that accountants are moving away from debits and credits, or is it just that accounting software translates to signed numbers when dealing with non-accounting software such as databases and spreadsheets?

Re: Plain Text Accounting, a guide to Ledger and friends

#79

I've used the ledger-likes extensively, and they have two major problems: (1) One of the hard problems in personal finance is data capture and input validation. Programs like QuickBooks and Xero don't just hide the GL because they're being mean, they're doing it because even experienced bookkeepers make mistakes on the general ledger all the time. "Since it's a text file it's easy to read" solves exactly the wrong pr…

> hard problems in personal finance is data capture and input validation It's also true for business accounting. Getting data into your accounting/ERP software is always a clusterfuck, and I've yet to see a process that didn't require many hours/days of reconciliation and posting manual journal entries to close a reporting period.

This is the data representation problem.

It's in the customers' best interest to have a universal format.

It's in no one else's (read: especially vendors) interest for there to be a universal format.

Which is why you generally only see it when it's mandated by a coordinating party in the middle (e.g. Medicare).

Re: Plain Text Accounting, a guide to Ledger and friends

#80
post #71
post #28

Earlier quoted context omitted.

This is already after the data capture part. The hard part is to remember every little transaction I had until I have vim at my hand. The only solution seems to be working more or less is to take out my phone and type it as soon as the transaction happened. And I won't try to use vim on phone ever again..

This is one of the reasons I use YNAB (for shared household budget) and a Google sheet (for personal budget). I usually just hold onto the receipt for whatever I do until the end of the working day and get it entered that night. But if a receipt or my pay app isn't an option then I can enter the transaction right there on the phone before I forget.

Do you use the original or SaaS version of YNAB?
Post reply on HN