Comment by andreareina | Hacker News Reader

Comment by andreareina | Hacker News Reader

I admittedly haven't been looking for better, but the "double-entry lite" systems I've seen kinda miss the mark a bit.

- Source/destination (as used here) is awkward when transactions have more than one split: at best there's a single source/destination which is entered multiple times and you need to make sure the splits add up right (and that single $50 charge to your credit card doesn't show up that way in the register); at worst you have an m:n split.

- Simple plus/minus without debits and credits (à la hledger, which I am otherwise quite happy about) runs into situations like: I increase my liabilities (e.g. by paying by credit card) by subtracting from the account?!?

I think if you're going to use a GUI then going full debit/credit isn't hard, I got up and running with Quickbooks pretty quickly and GNUCash seems about the same.

EDIT: I don't mean to downplay the accomplishments of the authors of any of the software mentioned, like I said I'm a happy user of hledger and Firefly III looks pretty polished from what I saw of the demo. This is really meant to be more of a meta-comment around the idea that bookkeeping is hard and double-entry debit/credit is doubly so.

> I increase my liabilities (e.g. by paying by credit card) by subtracting from the account?!?

Maybe I'm just inured to the convention, but this makes perfect sense to me. You subtract money from any other account you pay from. At a sufficiently abstract level, paying by credit card is the same thing as overdrawing your checking account. You need to add money to get the balance back to zero.

Makes perfect sense to me too. Credit cards aren't money you have, they're money you can borrow. Paying by credit card is borrowing money. Paying a credit card back means it should show in your system at $0. If your bank shows it at some positive $, that's just convenient financial fiction.

(And possibly dangerous fiction. I think a big part of the way people get in trouble with credit cards is by thinking their credit line is "the money they have", instead of "money they can borrow really fast".)

It's definitely a dangerous fiction.

'0xcde4c3db makes a good point about it making the flow of value clear in the transaction, but the transaction view is already the easy thing to interpret. The value (heh) of bookkeeping is when those flows are aggregated, and the meaning of those aggregations is (admittedly only somewhat) obscured when optimizing for clarifying flows in single transactions.

Charging a credit card to make it more negative does match our intuition of how it affects our overall financial position, but that's due to serendipity. What does it mean that expenses are normally positive, is that a good thing then? Or that my paycheck account is negative?

In the end it's a nit, a small thing I mostly ignore. I just think that part of the complexity it tries to eliminate is essential, with results like negative revenues. It's a leaky abstraction.

It does work for modelling flows, but the meaning of balances gets a bit wonky. Income is revenues - expenses in the debit/credit model, but in the plus/minus model it's -revenue - expenses (hledger's income statement report flips the sign on revenue accounts, so you get the net via the normal equation).

A different way to do double-entry-lite might be to retain plus/minus, but have that operate on the account's normal balance -- pay for expenses by decreasing an asset or increasing a liability. Transactions still balance even if they don't sum to zero -- it makes sense that an IOU balances out the coffee you just got. You do need to understand the four basic account types (explicit equity accounts are arguably not relevant to most individuals), but that's something that's needed anyway. You still don't need to explicitly learn about debits and credits, but if you do it's much closer from here than from the flow-based approach.

Flow is easy, but I feel that in the end modeling the effect on balances is simpler.

For what its worth, I'm an accountant in my day job and our software doesn't differentiate between debits and credits. Debits are positive and credits are negative. You get used to it seeing it all the time.

I am used to it. Mostly. It still throws me for a loop sometimes, like just now when I had to figure out how p/l would be calculated based on the flows.

- Firefly III enforces splits to make sense. Source must be the same for deposits, destinations for withdrawals. It's technically possible to mess up but I never met people who were careless enough to do so. - Yep. That's always tricky to get right.

I'm halfway between going full accountant (never go full accountant) and basically human. I'm pretty happy with the results so far.

Reply on news.ycombinator.com