Hacker News Reader

Comment by jes5199 | Hacker News Reader

okay but how do you model a three-party transaction? say you want to collect fees or taxes

you simple create two records linked by one 'transaction', the source in both cases is the same account, while the destination for one of those postings is the fee account and the other destination is a merchant or similar account. And you can link as many of those postings under a single transaction

okay so now you’ve got double-entry bookkeeping except all of your credits/debits have two dollar values instead of one. let’s call it “quadrupal-entry”

yes, it's a form of double-entry bookkeeping - that's the base. If it weren't double-entry then indeed it would be a pretty poor choice. This design enforces double-entry at a fundamental level, it's never possible to create a record that doesn't affect 2 accounts - and that's actually the whole point of it :)

You have a single USD (or other) value - so in the simplest form it just looks like this:

From: Alice To: Bob Amount: 10 Currency: USD

And the balances are simply sum(transactions where account is receiver) - sum(transactions where account is sender)

You never have 3 party transactions - if you do, you would not be able to track money flow.

You can have multiple transactions. One to pay tax, one to pay fees and one to pay the actual thing.

You bundle these things in another abstraction, eg. An invoice.

Reply on news.ycombinator.com