Accounting For Developers, Part I
moderntreasury.com
Accounting For Developers, Part I
1–10 of 193 posts
Re: Accounting For Developers, Part I
#2Ok this is an interesting post but I as understand it, its more like "what can go wrong when developing accounting software" and not that developers need a special type of accountant?
Re: Accounting For Developers, Part I
#3Ok this is an interesting post but I as understand it, its more like "what can go wrong when developing accounting software" and not that developers need a special type of accountant?
Yes this post is about developing accounting or other kinds of software that tracks money (from the subtitle: "... we walk through basic accounting principles for anyone building products that move and track money").
One can treat it as a primer on double-entry accounting as well.
Re: Accounting For Developers, Part I
#4Whenever accounting comes up in geek circles, it's worth mentioning ledger and similar systems it inspired which use plain text files to implement double entry accounting:
I used this system for years as a consultant - it's also pretty easy to extend - I did this using the Python API to implement an arbitrary RPN calculator on top of it:
Re: Accounting For Developers, Part I
#5Interesting, I'd heard of "double entry" before but I've never used it. I've written and maintain code that uses only 1 record per transaction and I'd love resources to look into that go into the "why" of double entry.
For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row. For reloading the "fromUserId" is a system user that is allowed to go "into the negative" since it's responsible in a way for "minting" money into the system.
I'll be the first to agree that a double-entry system would make some of my code simpler. Currently listing out transactions is somewhat annoying since you need to know the context (the user requesting the list) so you display the data correctly. "Spent $X at vendor" makes sense as a description from the user's perspective but not from the vendor's. Double entry would solve this as I could generate a description specific to each user's perspective "Spent $X at vendor" "Sold $X to user" or something like that.
But I'm sure there are other advantages to a double-entry system that I'm missing so any resources would be appreciated.
I've got some time to rewrite that system and I think double-entry sounds like the right path forward. It probably was the right path from the start but I was busy building, not researching accounting methods like I probably should have been. That said, this project of mine has been very successful (from my perspective) and who knows if it would have been had I gotten mired down in accounting from the start.
Re: Accounting For Developers, Part I
#6Interesting, I'd heard of "double entry" before but I've never used it. I've written and maintain code that uses only 1 record per transaction and I'd love resources to look into that go into the "why" of double entry. For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row. For reloading the "fromUserId…
A pretty quick Google found what I feel are some decent/good resources that show the tradeoffs:
https://en.wikipedia.org/wiki/Double-entry_bookkeeping (obviously the most technical as it's Wikipedia)
https://anderscpa.com/accounting-102-startups-double-entry/ (specifically startup-focused)
https://www.nerdwallet.com/article/small-business/double-ent...
https://www.fool.com/the-ascent/small-business/accounting/ar...
Re: Accounting For Developers, Part I
#7Whenever accounting comes up in geek circles, it's worth mentioning ledger and similar systems it inspired which use plain text files to implement double entry accounting: https://www.ledger-cli.org I used this system for years as a consultant - it's also pretty easy to extend - I did this using the Python API to implement an arbitrary RPN calculator on top of it: https://github.com/zdw/ledgercalc
I have tried several (like https://hledger.org/ ) but would prefer some REA/ValueFlows accounting software.
Re: Accounting For Developers, Part I
#8Interesting, I'd heard of "double entry" before but I've never used it. I've written and maintain code that uses only 1 record per transaction and I'd love resources to look into that go into the "why" of double entry. For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row. For reloading the "fromUserId…
From my, very limited understanding, the big benefit is the representation of obligations and receivables.
For example, if you take a bank loan of $1 you’d make an entry for your cash balance to be $1 and your obligations to your bank being $1. Your books are balanced.
Now you use that $1 to buy a machine. $1 down from your cash, $1 up in your non-cash assets.
For what if instead you pay someone for a service for $1? $1 added to your expenses, $1 down from your cash.
And so on, and so on. At the end of the day you have a fairly good idea where your money is coming from and where it’s going as well as any outstanding obligations and receivables.
One of the main aspect is that there’s an element of validation in here. If your books aren’t balanced, something is off.
Re: Accounting For Developers, Part I
#9Interesting, I'd heard of "double entry" before but I've never used it. I've written and maintain code that uses only 1 record per transaction and I'd love resources to look into that go into the "why" of double entry. For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row. For reloading the "fromUserId…
Double entry bookkeeping doesn't mean that you have two records for each transaction. In fact, it's the exact opposite! Transactions fundamentally have two parts -- where the money is coming from and where the money is going -- and double entry bookkeeping says that both of those entries are part of the same record.
Re: Accounting For Developers, Part I
#10This is a huge blindspot for our tribe, and as such is a GREAT resource. Bookmarking!