Is chart of accounts usually a flat structure, or can it look more like a tree? I'm thinking of grouping similiar accounts together to see what's the balance on single ones vs the group.
Accounting for Developers, Part II
51–60 of 79 posts
Re: Accounting for Developers, Part II
#52Is chart of accounts usually a flat structure, or can it look more like a tree? I'm thinking of grouping similiar accounts together to see what's the balance on single ones vs the group.
Its a tree. Eg:
Expense
- Salaries
- Rent
-- Warehouses
-- Retail space
- Utilities
Re: Accounting for Developers, Part II
#53Here’s my approach to accounting: If $moneyIn > $moneyOut: Print(“hells yeah”) Else: Print(”oh shit”)
Ha. But a pedantic take at face value:
This doesn't work on a low level, such as: If you're looking at an account you want to balance to 0, e.g. a suspense account, prepayment account, etc.
Also doesn't work with practical application, such as: Catering for a profitability target e.g. ($in / $out) > 1.1
Re: Accounting for Developers, Part II
#54A quote from a related blog post: "Eventually I figured it out: basic accounting is just graph theory. Accounts = Nodes, Transactions = Edges" https://martin.kleppmann.com/2011/03/07/accounting-for-compu... Also probably worth checking out Martin Fowler's writing on accounting. https://martinfowler.com/apsupp/accounting.pdf https://www.amazon.com/Analysis-Patterns-Reusable-Object-pap...
Klepmann is correct but practically you don't control external accounts thus cannot authoritatively determine if they either exist, have ceased to exit, or the contents of their ledgers. Thus, a large number of transactions will always have hanging references. This ultimately dictates the need for a "settlement state", which should be modeled as a state machine with careful transitions. Reversible transactions, fees,…
Thank you. Those are some interesting references. I do like your reference of state machines at the edges of the accounting model. Definitely the case in payments systems. I don't like how Modern Ledger goes straight to credits and debits whereas Klepmann has a graduated approach. I have been thinking about writing a bit more about this.
Re: Accounting for Developers, Part II
#55Here’s my approach to accounting: If $moneyIn > $moneyOut: Print(“hells yeah”) Else: Print(”oh shit”)
I did like Charles Dickens who has Mr Micawber say ‘Annual income 20 pounds, annual expenditure 19 [pounds] 19 [shillings] and six [pence], result happiness. Annual income 20 pounds, annual expenditure 20 pounds ought and six, result misery.’
Re: Accounting for Developers, Part II
#56Earlier quoted context omitted.
I would like to know about this as well. I struggled with this for a while for a prediction market app that I'm building. Eventually I ended up with [1]. I am somewhat pleased with it, but it does feel unwieldy to work with. I have some vague hope that somebody who actually implemented banking software would know of an obvious and elegant schema. The summary of my approach is: * A table with accounts. * A table with…
Thanks! If I understood your explanation and schema correctly, a mutation itself is balanced, and if you have a transaction that involves three accounts, that would be split up into two balanced mutations, right? The advantage I see with this design is that a mutation (and thus a transaction) is always balanced (you store the amount only once, and credit account and a debit account). The disadvantages seem to be that…
Yes, that's a fair summary.
Performance is not something I'm worried about for my app, maybe a few dozen people would use it at the same time, and I run everything at serializable isolation level anyway. But I can imagine that for processing real-world payment volumes, at some point you need to sacrifice the balanced-by-construction property for performance.
One issue I noticed is that there is some freedom in the representation of transfers. You can pick a canonical representation by demanding that the amount is positive, but then you have to make a case distinction everywhere in code. Often the code becomes much simpler if negative amounts are allowed. But it does make the credit/debit more confusing, and it goes against the observation in part 1 of the series, that accounting systems rarely work with negative numbers. I wonder why though.
Re: Accounting for Developers, Part II
#57> "We hope to publish guides about more complex use cases (lending, insurance, etc.) in the future." That would be appreciated. It'd be nice to see the minimal complexity needed for something like a local credit union that managed customer savings and checking accounts, as well as home and car loans. More ambitious would be a central banking app, in particular how does double-entry accounting work when a central bank…
That's a cool idea. Any other deep-dive guides on fintech/payments that would be helpful for readers here? We're always looking for new topics to write about.
The book Central Banking 101, by Joseph Wang, is a good deep-dive on how the accounting works on the central-banking side when money is created, etc.
Re: Accounting for Developers, Part II
#58Earlier quoted context omitted.
This sort of schema requires a process to verify the sum before committing, and verification is annoying to achieve with constraints. Instead, you might consider something like: transaction_line (id, transaction_id[fk], dr_account_id[fk], cr_account_id[fk], amount)
The problem with this will be when you have 3 accounts involved on a transaction. Eg, you take a sales receipt with part bank transfer, part cash. Sales Cr $100 Cash Dr $30 Bank Dr $70 Your approach will have: Sales Cr $70, Bank Dr $70 Sales Cr $30, Cash $30 That looks like two sales, which is not really the case.
Isn't it more accurate to say it was two sales than one? In what way is it misleading?
Re: Accounting for Developers, Part II
#59Here’s my approach to accounting: If $moneyIn > $moneyOut: Print(“hells yeah”) Else: Print(”oh shit”)
I'll take advantage of the simplistic calculation. If you give me all your money, I'll give you back all your money plus N (N guaranteed to be a positive number). Now, I'll give it back in 10 years, but you'll have definitely made money. Or, in your terms "hells yeah"!
Re: Accounting for Developers, Part II
#60A quote from a related blog post: "Eventually I figured it out: basic accounting is just graph theory. Accounts = Nodes, Transactions = Edges" https://martin.kleppmann.com/2011/03/07/accounting-for-compu... Also probably worth checking out Martin Fowler's writing on accounting. https://martinfowler.com/apsupp/accounting.pdf https://www.amazon.com/Analysis-Patterns-Reusable-Object-pap...
Klepmann is correct but practically you don't control external accounts thus cannot authoritatively determine if they either exist, have ceased to exit, or the contents of their ledgers. Thus, a large number of transactions will always have hanging references. This ultimately dictates the need for a "settlement state", which should be modeled as a state machine with careful transitions. Reversible transactions, fees,…
On UTC: why so, as accounting periods are happening in local time