18 ms·

Accounting For Developers, Part I

648 points by qin 4y ago

deleted 4y ago
[deleted]
freddie12S 4y ago
cupachabra 4y ago
Ok 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?
- wholien 4y ago
  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.
  - cupachabra 4y ago
    Super helpful in that case :)
zdw 4y ago
Whenever 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 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 https://github.com/zdw/ledgercalc
- fabianhjr 4y ago
  I have tried several (like https://hledger.org/ https://hledger.org/ ) but would prefer some REA/ValueFlows accounting software.
- dugmartin 4y ago
  More info here on other like-minded systems like hledger and Beancount: https://plaintextaccounting.org/ https://plaintextaccounting.org/
- rthomas6 4y ago
  I use this, except I use Beancount. It's written in Python and is easier to write your own little extensions. There's also a GUI called Fava that goes along with it and is really good.
- NoboruWataya 4y ago
  Also GnuCash, which I feel requires no elaboration on HN as it is so frequently its own topic of discussion.
joshstrange 4y ago
Interesting, 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.
- rr888 4y ago
  Much of the Why is because bookkeeping predates computers, so its all about ledgers in books.
- mathgeek 4y ago
  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 https://en.wikipedia.org/wiki/Double-entry_bookkeeping (obviously the most technical as it's Wikipedia) https://anderscpa.com/accounting-102-startups-double-entry/ https://anderscpa.com/accounting-102-startups-double-entry/ (specifically startup-focused) https://www.nerdwallet.com/article/small-business/double-entry-accounting https://www.nerdwallet.com/article/small-business/double-ent... https://www.fool.com/the-ascent/small-business/accounting/articles/double-entry-accounting/ https://www.fool.com/the-ascent/small-business/accounting/ar...
ubermonkey 4y ago
This is a huge blindspot for our tribe, and as such is a GREAT resource. Bookmarking!
Naga 4y ago
This is a pretty good article about the basics! I'm a CPA who is now working in the tech space. I've helped work on some accounting software and other finance-type processes. I'm happy to answer any questions if anyone has them! Either here, or my email is in my profile.
- tbonesteaks 4y ago
  Any resources you would recommend to learn the basics and/or fundamentals of accounting and finance?
  - Naga 4y ago
    Accounting is also a strange field because its a bunch of almost unrelated fields stuck together. Accounting covers financial accounting (dealing with recording transactions, representing reality, etc), tax, management and cost accounting (things like tracking performance, figuring out what the widget you produced actually costs you, once you've included the direct costs and an estimate of overhead) and a whole slew of other things like internal controls, governance questions (how do you align incentives in an organization?), etc. Picking up a textbook on financial accounting is probably a good starting place to get the basics of debits/credits, but from there it depends what your interests are. For books on finance, I recommend Niall Ferguson's Ascent of Money as a pretty good introduction into the history of finance and how it all sortof fits together.
jwsteigerwalt 4y ago
Great post. This is so overlooked. I had a career in accounting and finance before technology and consider myself so lucky that the accounting concepts important to business and financial database design are no problem for me.
matdehaast 4y ago
For those interested, Tigerbeetle[0] is a high-peformance purpose built accounting database. It supports - double entry transfer - two-phase transfers (ie reserve an amount and post it later) - linked transfers (move money across multiple accounts atomically) Worth looking at. [0] - https://www.tigerbeetle.com/ https://www.tigerbeetle.com/ & https://github.com/coilhq/tigerbeetle https://github.com/coilhq/tigerbeetle
- eatonphil 4y ago
  Also one of the bigger Zig codebases out there for you PL nerds.
  - _vvhw 4y ago
    After the Zig compiler that is, which dwarfs TB's code base. The Zig core team are all machines. ;)
- kinleyd 4y ago
  Interesting. And Zig too? Hmm.
  - _vvhw 4y ago
    Thanks! I don't think we could have done TigerBeetle the way we did, without Zig. It's been two years now, and looking back the choice has worked out well for our design decisions. For example: - single-threaded control plane (thread-per-core architecture), - static memory allocation at startup (we never call malloc() or free() thereafter—no UAFs) for extreme memory efficiency (TB can address 100 TiB storage using only 1 GiB statically allocated memory), - explicit memory alignment expressed in the type system (for Direct I/O), and of course, - Zig's comptime which is insane. We use it to do all kinds of things like optimize the creation of Eyztinger layouts, or to eliminate length prefixes in our on disk LSM table formats.
- _vvhw 4y ago
  Thanks! What we realized for TigerBeetle, is that double-entry is often lifted and brought directly into the networked world of distributed systems as double-entry, as a ledger database. However, most distributed financial systems of record also spend alot of their time talking to other distributed financial systems of record. So there are all these different entities (e.g. banks) all running different infrastructure and all wanting not only to track money within their own system but also to move money safely between systems. Historically, double-entry is great at tracking transactions within a system or entity, but it's not great at this intersection between double-entry and distributed systems, because of the way that networks fail. We were seeing that these systems all end up with the equivalent of a two-phase commit coordinator, which is alot of work to implement correctly on top of double-entry. And everyone is building these ad hoc ledgers that are not only ledgers but also two-phase commit coordinators. So what we've done for TigerBeetle [1], is to take double-entry and marry it with distributed systems, to make it really easy to track transactions as money enters and leaves a system, by providing two-phase double-entry transfers out of the box. For example, not only a debits/credits balance, but also the concept of pending/posted debits/credits balance. And then to package this all up as a mission-critical safe and performant (1m TPS) open source database that the whole ecosystem can partner with and build on. [1] I did a deep dive into TigerBeetle in a recent talk at the Recurse Center called “Let's Remix Distributed Database Design!“ going into the storage fault research that we've implemented for TigerBeetle. For example, the safety reasons for why we didn't pick RAFT as our consensus, or the latency reasons for why we don't use LevelDB or RocksDB, and how our testing is inspired by FoundationDB's Deterministic Simulation Testing — https://www.youtube.com/watch?v=rNmZZLant9o https://www.youtube.com/watch?v=rNmZZLant9o
EvanAnderson 4y ago
Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money. The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money. My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a credit is an entry in the right column." Without the context of the specific accounts being debited or credited the terms themselves mean nothing. Aside: A 100-level knowledge of accounting can confer near "super powers" when it comes to dealing with finance and accounting people. Double-entry bookkeeping is one of the oldest and longest-practiced "IT" disciplines. Your work probably touches revenue / expenses for your employer and someday you'll need to interface with accounting or finance people. Being able to speak the language, even poorly, has helped me gain trust and credibility that I don't believe speaking only in IT terms would have.
- kinleyd 4y ago
  Sadly, I gave up accounting in high school after failing to reason through the meaning of 'credit' and 'debit' (Yes, I went in too deep!). My epiphany came in B-school when I tackled it again, when I finally figured out what your instructor summarized.
- CSMastermind 4y ago
  I was lucky enough to work on a billing system early in my career and pick up some rudimentary knowledge of accounting. I can confirm that even being able to 'speak the language' a little bit provides immense value to you as a developer.
  - Mezzie 4y ago
    Also can confirm as an accountant's kid. It's kind of like being given a cheat code.
- rahimnathwani 4y ago
  > "debit" and "credit" and > think they have to do with > "owing" or "being owed" money. I think of it as 'owing' (liability) or 'owning' (asset). When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account. Examples: - bank credits a customer account => bank owes more to its customers - company credits income account => company owes more to its shareholders - company credits accounts receivable => company owns less in unpaid invoices > Without the context of the > specific accounts being debited > or credited the terms > themselves mean nothing. This seems incorrect to me. > A debit is the entry in the left > column, and a credit is an > entry in the right column. Debits/credits concepts can exist (and we can operate on them) without the existence of left/right columns.
potamic 4y ago
Any time the idea of double entry bookkeeping comes up there is nothing but unanimous advocacy for it. This thread echoes the same sentiment where there's several comments about the importance of double entry. And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. The reasons are always around error tracking, tracing source of funds, standing the test of time etc. and yet in my head I'm not able to envision the specific problem double entry can solve that single entry cannot. Somewhere in my head I feel a double entry system makes sense if you have two different parties making respective entry. But if it's all with a single party, single entry system should be equivalent to a double entry system. My accounting concepts are weak so I'm unable to justify. Hoping someone with more expertise can shed some light here.
- alain94040 4y ago
  Think of each transaction as a movement: it has a source and a destination. Therefore, you need to account for it in two places: where it came from, and where it went. Does that make more sense?
  - rr888 4y ago
    I think you can expand this explanation with database terminology. In modern RDBMS, you could have naive implementation with two account's balance, and increment one decrement the other. But without transactions it just isn't safe, its better to have one row in a table with a debit and credit. Now if you're doing accounts by hand you really need that single line transaction record.
    - meekaaku 4y ago
      > its better to have one row in a table with a debit and credit. No. Some transactions have 3 lines, eg: two debits and one credit. Some examples: - Split payment at a shop, $100 item bought with $70 cheque and $30 cash would be credit sales $100 debit cash $30 debit bank $70 Now if you introduce sales tax or VAT/GST, its more complicated. Say the $100 item is actually $90 + $10 VAT, then entries goes: credit sales $90 credit vat-payable $10 debit cash $30 debit bank $70
svat 4y ago
There's another very nice description, with useful pictures, by Martin Blais (as part of the documentation of Beancount) at https://beancount.github.io/docs/the_double_entry_counting_method.html https://beancount.github.io/docs/the_double_entry_counting_m... (example picture that I would say is the heart of the idea: https://beancount.github.io/docs/the_double_entry_counting_method/media/19e2cc49a057dfeea1cf5254610eab4c9a124488.png https://beancount.github.io/docs/the_double_entry_counting_m... ) Another one, with completely different graphs, is by Martin Kleppman at https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu... — despite the name ("Accounting for Computer Scientists"), on reflection / trying it out, I find it less useful than the Beancount one. (Both of these are actually linked in the second paragraph of the posted article, but they're independently worth mentioning / good.)
retetr 4y ago
Can someone explain. From their definition it looks like the credits and debits column in their example transaction table is flipped e.g. the first "debit" to the cash (debit normal) account increases the value, while the "credit" to the equity (credit normal) account also increases the value. (edited for spelling)
- projektfu 4y ago
  See my other comment here: https://news.ycombinator.com/item?id=32499123 https://news.ycombinator.com/item?id=32499123
akersten 4y ago
> A credit entry will always increase the balance of a credit normal account and decrease the balance of a debit normal account. Put differently: Not sure if the author is reading comments here, but the diagram after this sentence shows the opposite!
- stocknoob 4y ago
  Yes, that was quite confusing. Thanks for mentioning.
- lucasrocha259 4y ago
  Author here. We just pushed out a fix. Thank you for flagging!
- selljamhere 4y ago
  I noticed this, too. The summary bullets at the end of the post also oppose the diagram. Probably a simple mixup of credit/debit in the left column. The rest of the article usually lists do it first.
jedberg 4y ago
For those of you who like the blockchain, think of that as triple entry accounting -- you put one charge as credit in one column, debit in another, and a public record on the blockchain.
swyx 4y ago
former CFA turned developer here. I've been doing an informal workshop on "Finance for Developers", figured I should share my material here for people looking for more. Not selling anything.. yet but this stuff is easy for me to pump out given my previous career haha Reading: https://docs.google.com/document/d/1imIgNckZ_kM564fpGgTBtsqiGwRAIOcmA_hzuwRH4bo/edit https://docs.google.com/document/d/1imIgNckZ_kM564fpGgTBtsqi... 1hr Youtube workshop: https://www.youtube.com/watch?v=Lelq40jILA4 https://www.youtube.com/watch?v=Lelq40jILA4 2hr Audio podcast discussion: https://share.transistor.fm/s/0b9270a5 https://share.transistor.fm/s/0b9270a5 to make a point directly related to this post - i believe accounting is the starting point for finance - but you can learn "just enough" accounting to make it work.
quelltext 4y ago
I think the figure / chart in "Effect on balance by account type" is wrong / flipped. It says that debits decrease debit normal account balance which doesn't match the text description or subsequent examples.
- lucasrocha259 4y ago
  Author here. This is helpful feedback, we could have perhaps taken more time before jumping in on the Modern Bagelry example. A common misconception is that one account needs to increase while the other needs to decrease. But what we are actually showing that they can both increase or decrease in tandem, depending on the debit and credit entries in the transaction and the direction of the accounts. In the first transaction cash increases because it's a debit entry in a debit normal account (cash); and equity also increases because it's a credit entry in a credit normal account (equity).
  - aktuel 4y ago
    So you basically have these two types of account, because you want all accounts to have a positive balance in general? If we would not care about certain types of accounts having negative balances, then we could say that for each transaction the sum of all account changes would always have to add up to zero. We could then still -depending on the account type- flip the sign after calculating the account balance. Am I understanding this right?
    - lucasrocha259 4y ago
      Part of the idea here is that debits = credits is a cleaner way to depict balances 'netting out to zero' than using positive or negative balances.
  - quelltext 4y ago
    The main issue was that at the time the "Effect on balance by account type" figure was reversed / incorrect, and so the example was just not making sense. Reading on further and again I realized it was not the example but that figure that was wrong. I see that you fixed that now. Thanks.
sudhirj 4y ago
Can someone help with a few ideas on this topic? I've been volunteered to be the treasurer at my building home owner's association, and trying to keep accounts for the whole building on a single excel sheet is a shitshow. So obviously I'm building a SaaS that will handle all the accounts for every HOA in the whole world and become a trillion dollar product. But I need to figure out which accounts are debit normal and credit normal and how transactions should flow first. So far I have the following accounts: * Per-apartment accounts, like the account for Apt#A1, Apt#A2, Apt#B1 etc. * A Maintenance Receivable account - the account for maintenance payments that should have come in. * A actual current operating account - account that reflects the building's bank account, showing money that came in from apartments for maintenance payments and also expenses. * An Expenses account. For expenses. So far the typical transactions I can think of are: * Beginning of every month the maintenance is due (say 100), so each apartment gets a -100 with a corresponding +100 on Maintenance Receivable. * When an apartment pays, they get a +100, but this is money that actually lands in the current operating bank account, so that's a +100 too? I'm guessing this is where the genius of not using plus or minus but using debit and credit comes in. That avoids the confusion, one is a debit and one is a credit, but which is which and which is a debit normal and credit normal account? * When there's an expense, I remove money from the bank account account and put it in the expenses account. Seems sort of ok, but the Maintenance receivable account is always increasing. How do I set this up so I can correctly represent what an apartment owes while also capturing what it paid as inputs to the buildin's bank account?
- epa 4y ago
  Assets are +, Liabilities are -. So a receivable is an asset and +100 is correct. when the money comes in, you need to +100 cash and -100 receivable.
  - sudhirj 4y ago
    So when an apartment pays, is 4 entries in the single transaction? Credit their apartment account, debit the bank account, credit cash and debit receivables? Never thought of making 4 entries for a single transaction.
dllthomas 4y ago
There is no accounting for developers.
umrashrf 4y ago
If you are in Canada, you might find this helpful https://www.youtube.com/watch?v=WV-vNltqasA https://www.youtube.com/watch?v=WV-vNltqasA
mguerville 4y ago
Great article by a company that's honestly been great to work with, I think it's interesting that they write such an entry level piece when their solution is enterprise grade but it shows their dedication to educating not just the users and stakeholders of the end product but also the implementers, which very few software companies do.
andix 4y ago
Some practical cases where you really need such a system: A customer pays one product with two different sources of payment (gift card + visa, or one half with cash and the other with card) You want to verify if the balance in the cash register, or on the credit card account are correct. You already received money from a customer, but it will take some time until you can create the invoice (for example you want to print the serial number on it, and don’t know it yet), but for legal reasons you are not allowed to change an invoice later. So you have to record a payment without having an invoice yet.
HatchedLake721 4y ago
I had a pleasure to dive deep into this topic and we built a double-entry bookkeeping system from scratch in a heavily regulated industry that tracked debt consolidation for thousands of customers with payouts to thousands of creditors. I think this is one of the most proudest things I was ever was involved in architecting, designing and building. I left before it got to prod, but from people still there, I've been told it's been working flawlessly!
biznickman 4y ago
I cannot upvote this enough. I worked at a fintech company that was vehemently opposed to using double entry accounting and it created an incredible amount of inefficiencies and massive errors and expenses at the company. If you are dealing with money in any system and tracking it in a database, double-entry accounting is not an option.
jdasdf 4y ago
I have 2 main issues with understanding double entry accounting, that i haven't really been able to grasp properly: 1 - How do i use it to keep track of multiple "currencies"? It's simple enough to remove 1$ from the cash account into the inventory account, but that 1$ i now have in the inventory isn't actually cash... How can i use this to keep track of the number of widgets i actually have in storage? Rather than the cost it took me to get them there. 2 - How do i account for profits? Back to the example, i move the 1$ from my cash onto the inventory. Great now i have 1$ in inventory. I sell half my inventory for 2$. How exactly do i account for this? I still have presumably 0.5$ in inventory, and now i got 2$ in cash, but where did that come from and go? Presumably i'd take 2$ from the inventory and put it in a client account, but does that mean i now have negative 1$ inventory? Sure the client account would also have another transaction putting the 2$ into my cash account. And wouldn't this make one transaction into actually 2 transactions? One from inventory to client, and one from client to cash? If you can help me grasp this i would really appreciate it!
- sbuttgereit 4y ago
  This is going to be quick, dirty, and simplistic. I've explained deeper in a different comment. But this should help. Things to keep in mind... The accounting equation: Assets = Shareholder Equity + Liabilities. This expresses what we own (assets) and who has a claim over what we own (shareholders, creditors). Shareholder's equity can be expanded as: Retained Earnings + (Revenue - Expenses); retained earnings is revenue - expenses in prior years. Transactions assuming you start with $1 in cash. When you buy the inventory you credit the Cash Account (asset) by $1 and debit the Inventory Account (asset) by $1. In essence you've converted the cash asset into an inventory asset. When you sell the inventory you have a multi-part transaction. Inventory movement: Credit the Inventory Account (asset) by $1 and Debit the Costs of Goods Sold Account (Expense) by $1. You no longer have the inventory. The Sale part: Debit the Cash Account (asset) by $2 and Credit the Sales Account (Revenue) by $2. You have received a new $2. In the end you remove the inventory as an expense to Costs of Goods Sold and you have new cash from sales revenue. From the accounting equation perspective it looks like: Before inventory purchase: $1 (Asset/Cash) = $1 (Equity, assuming it wasn't borrowed) + $0 (Liabilities) After Inventory Purchase: $1 (Asset/Inventory) = $1 (Equity) + $0 (Liabilities) After Sale: $2 (Asset/Cash) = $1 (Equity) + ($2 (Revenue/Sales) - $1 (Expense/COGS)) + $0 (Liabilities)
ghoward 4y ago
Funny that this would show up when a month ago, GnuCash was submitted on this site. [1] I decided then that I would take the opportunity to learn how to use it and learn accounting properly for my family budget, mostly because I want to start a small business eventually, and double-entry accounting will be necessary for that. So I did. It went extremely well. The GnuCash Tutorial and Concepts Guide [2] was exactly what I needed. For all you developers wanting to learn double-entry accounting, I have one piece of advice: actually learn to use the terms that accountants use. Sure, it may be annoying that you have to say that something is a "debit" or a "credit" versus just saying that it's a positive or a negative amount. But in my experience, that annoyance passes quickly once it clicks. Do take the time to learn it right. And if you use GnuCash, set it to use the standard terms. [1]: https://news.ycombinator.com/item?id=32136384 https://news.ycombinator.com/item?id=32136384 [2]: https://www.gnucash.org/docs/v4/C/gnucash-guide/index.html https://www.gnucash.org/docs/v4/C/gnucash-guide/index.html
contingencies 4y ago
I've implemented tens of accounting systems, always multi-currency and usually multi-lingual. Originally in RDBMS, but in the last decade generally with triggers in SQLite. The most complicated one I've done was Kraken (~2011) which needed arbitrary precision support for unknown future crypto asset types. Opine: (1) Accounting as a profession is being automated away as governments create APIs to facilitate report submission and SCM/ERP/payroll become automated. Not too soon. (2) Yes, IMHO absolutely the debit/credit account terminology needs to die. It's backward and a source of confusion for the non-indoctrinated. Use negative numbers and present formatting for antiquarians where required. (3) As a student of ancient history, falsely ascribing off-handed western-inventors to things is so 19th century colonialist. Double entry is just an overly-lauded stage in the development of accounting anyway, not the endgame. Ancient societies got by just fine tying knots in cords (ancient China, Maya, Polynesia, etc.) and many ledgers run fine without double entry now. It's primitive compared to what's available in computer science today. (4) Distributed transaction systems are an algorithmic problem, not an excuse for manual documentation. Let's give away autonomous implementations for free, make GAAP about reporting, standardize account and transaction identification and innovate on process. New systems recommendation: (1) For account identification, use IIBAN which provides IBAN-compatible account identification and checksums and is an open system @ https://github.com/globalcitizen/iiban https://github.com/globalcitizen/iiban (2) For all accounting, use UTC. (3) For transaction identification, use UTC second of origination (UTCSO) + account of interest (AOI; eg. IIBAN) + intra-second transaction identifier (ISTI). Free thoughts on forward-looking accounting systems @ https://raw.githubusercontent.com/globalcitizen/ifex-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco...
phil-martin 4y ago
One of my favorite resources on accounting is https://www.ledger-cli.org/3.0/doc/ledger3.html https://www.ledger-cli.org/3.0/doc/ledger3.html It's application specific, but has enough examples in there to remind me of accounting principles from years past. Combined with the other plain text accounting resources, it was the first resource that made everything "click" for me, well, for varying definitions of "click". I often refer back to it when I need to remind myself of things. One thing on my todo list to expierment with is modelling double entry accounting as a graph, with nodes of the graph an account, and edges of the graph a transaction with the two amounts on the edge. That's nice and all but the part I'm really interested in experimenting is modelling reconciliation as equivalencies of graphs. I have a separate graph that models the real world bank accounts and flow of cash, and organisational flow of money, and then I have my accounting graph that models all the transactions. For reconciliation I would go "these whole bunch of edges in this graph A are the same as all these other edges in graph B" I just want to see what falls out the other end...
pwpw 4y ago
As a CPA looking for an entry-level job as a software developer, it has been disheartening to see hiring managers brush aside my accounting knowledge and experience as next to worthless. I think the theory behind double-entry accounting is super interesting and a base-level knowledge would be helpful for many developers. Particularly those working at a small startup that have to wear the accounting/financial hat. The sooner you use double-entry accounting, the better your life will be in the future. Double-entry is an incredibly old system that's battle-tested, so it's remarkable to see some people still opposed to it today. It's reassuring to see so many comments here expressing positive sentiment around the topic!
- jakemcgraw 4y ago
  We’re (Harness Wealth) are always looking for developers with knowledge of US tax code hmu jake@harnesswealth.com
themadturk 4y ago
When I went to school for an AAA in Computer Programming in 1989-90, a quarter of accounting was required for graduation. The instructor didn't like computers (which was the reason about half the class was there), and tried his best to convince everyone they needed to major in accounting, but he was a good teacher and I learned a lot of stuff, none of which I've needed over the last 30+ years but all of which I was glad I learned.

648 points by qin 4y ago

deleted 4y ago

[deleted]

freddie12S 4y ago

cupachabra 4y ago

Ok 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?

wholien 4y ago
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.
- cupachabra 4y ago
  Super helpful in that case :)

zdw 4y ago

Whenever 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 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 https://github.com/zdw/ledgercalc

fabianhjr 4y ago
I have tried several (like https://hledger.org/ https://hledger.org/ ) but would prefer some REA/ValueFlows accounting software.
dugmartin 4y ago
More info here on other like-minded systems like hledger and Beancount: https://plaintextaccounting.org/ https://plaintextaccounting.org/
rthomas6 4y ago
I use this, except I use Beancount. It's written in Python and is easier to write your own little extensions. There's also a GUI called Fava that goes along with it and is really good.
NoboruWataya 4y ago
Also GnuCash, which I feel requires no elaboration on HN as it is so frequently its own topic of discussion.

joshstrange 4y ago

Interesting, 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.

rr888 4y ago
Much of the Why is because bookkeeping predates computers, so its all about ledgers in books.
mathgeek 4y ago
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 https://en.wikipedia.org/wiki/Double-entry_bookkeeping (obviously the most technical as it's Wikipedia) https://anderscpa.com/accounting-102-startups-double-entry/ https://anderscpa.com/accounting-102-startups-double-entry/ (specifically startup-focused) https://www.nerdwallet.com/article/small-business/double-entry-accounting https://www.nerdwallet.com/article/small-business/double-ent... https://www.fool.com/the-ascent/small-business/accounting/articles/double-entry-accounting/ https://www.fool.com/the-ascent/small-business/accounting/ar...

ubermonkey 4y ago

This is a huge blindspot for our tribe, and as such is a GREAT resource. Bookmarking!

Naga 4y ago

This is a pretty good article about the basics! I'm a CPA who is now working in the tech space. I've helped work on some accounting software and other finance-type processes. I'm happy to answer any questions if anyone has them! Either here, or my email is in my profile.

tbonesteaks 4y ago
Any resources you would recommend to learn the basics and/or fundamentals of accounting and finance?
- Naga 4y ago
  Accounting is also a strange field because its a bunch of almost unrelated fields stuck together. Accounting covers financial accounting (dealing with recording transactions, representing reality, etc), tax, management and cost accounting (things like tracking performance, figuring out what the widget you produced actually costs you, once you've included the direct costs and an estimate of overhead) and a whole slew of other things like internal controls, governance questions (how do you align incentives in an organization?), etc. Picking up a textbook on financial accounting is probably a good starting place to get the basics of debits/credits, but from there it depends what your interests are. For books on finance, I recommend Niall Ferguson's Ascent of Money as a pretty good introduction into the history of finance and how it all sortof fits together.

jwsteigerwalt 4y ago

Great post. This is so overlooked. I had a career in accounting and finance before technology and consider myself so lucky that the accounting concepts important to business and financial database design are no problem for me.

matdehaast 4y ago

For those interested, Tigerbeetle[0] is a high-peformance purpose built accounting database. It supports - double entry transfer - two-phase transfers (ie reserve an amount and post it later) - linked transfers (move money across multiple accounts atomically) Worth looking at. [0] - https://www.tigerbeetle.com/ https://www.tigerbeetle.com/ & https://github.com/coilhq/tigerbeetle https://github.com/coilhq/tigerbeetle

eatonphil 4y ago
Also one of the bigger Zig codebases out there for you PL nerds.
- _vvhw 4y ago
  After the Zig compiler that is, which dwarfs TB's code base. The Zig core team are all machines. ;)
kinleyd 4y ago
Interesting. And Zig too? Hmm.
- _vvhw 4y ago
  Thanks! I don't think we could have done TigerBeetle the way we did, without Zig. It's been two years now, and looking back the choice has worked out well for our design decisions. For example: - single-threaded control plane (thread-per-core architecture), - static memory allocation at startup (we never call malloc() or free() thereafter—no UAFs) for extreme memory efficiency (TB can address 100 TiB storage using only 1 GiB statically allocated memory), - explicit memory alignment expressed in the type system (for Direct I/O), and of course, - Zig's comptime which is insane. We use it to do all kinds of things like optimize the creation of Eyztinger layouts, or to eliminate length prefixes in our on disk LSM table formats.
_vvhw 4y ago
Thanks! What we realized for TigerBeetle, is that double-entry is often lifted and brought directly into the networked world of distributed systems as double-entry, as a ledger database. However, most distributed financial systems of record also spend alot of their time talking to other distributed financial systems of record. So there are all these different entities (e.g. banks) all running different infrastructure and all wanting not only to track money within their own system but also to move money safely between systems. Historically, double-entry is great at tracking transactions within a system or entity, but it's not great at this intersection between double-entry and distributed systems, because of the way that networks fail. We were seeing that these systems all end up with the equivalent of a two-phase commit coordinator, which is alot of work to implement correctly on top of double-entry. And everyone is building these ad hoc ledgers that are not only ledgers but also two-phase commit coordinators. So what we've done for TigerBeetle [1], is to take double-entry and marry it with distributed systems, to make it really easy to track transactions as money enters and leaves a system, by providing two-phase double-entry transfers out of the box. For example, not only a debits/credits balance, but also the concept of pending/posted debits/credits balance. And then to package this all up as a mission-critical safe and performant (1m TPS) open source database that the whole ecosystem can partner with and build on. [1] I did a deep dive into TigerBeetle in a recent talk at the Recurse Center called “Let's Remix Distributed Database Design!“ going into the storage fault research that we've implemented for TigerBeetle. For example, the safety reasons for why we didn't pick RAFT as our consensus, or the latency reasons for why we don't use LevelDB or RocksDB, and how our testing is inspired by FoundationDB's Deterministic Simulation Testing — https://www.youtube.com/watch?v=rNmZZLant9o https://www.youtube.com/watch?v=rNmZZLant9o

EvanAnderson 4y ago

Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money. The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money. My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a credit is an entry in the right column." Without the context of the specific accounts being debited or credited the terms themselves mean nothing. Aside: A 100-level knowledge of accounting can confer near "super powers" when it comes to dealing with finance and accounting people. Double-entry bookkeeping is one of the oldest and longest-practiced "IT" disciplines. Your work probably touches revenue / expenses for your employer and someday you'll need to interface with accounting or finance people. Being able to speak the language, even poorly, has helped me gain trust and credibility that I don't believe speaking only in IT terms would have.

kinleyd 4y ago
Sadly, I gave up accounting in high school after failing to reason through the meaning of 'credit' and 'debit' (Yes, I went in too deep!). My epiphany came in B-school when I tackled it again, when I finally figured out what your instructor summarized.
CSMastermind 4y ago
I was lucky enough to work on a billing system early in my career and pick up some rudimentary knowledge of accounting. I can confirm that even being able to 'speak the language' a little bit provides immense value to you as a developer.
- Mezzie 4y ago
  Also can confirm as an accountant's kid. It's kind of like being given a cheat code.
rahimnathwani 4y ago
> "debit" and "credit" and > think they have to do with > "owing" or "being owed" money. I think of it as 'owing' (liability) or 'owning' (asset). When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account. Examples: - bank credits a customer account => bank owes more to its customers - company credits income account => company owes more to its shareholders - company credits accounts receivable => company owns less in unpaid invoices > Without the context of the > specific accounts being debited > or credited the terms > themselves mean nothing. This seems incorrect to me. > A debit is the entry in the left > column, and a credit is an > entry in the right column. Debits/credits concepts can exist (and we can operate on them) without the existence of left/right columns.

potamic 4y ago

Any time the idea of double entry bookkeeping comes up there is nothing but unanimous advocacy for it. This thread echoes the same sentiment where there's several comments about the importance of double entry. And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. The reasons are always around error tracking, tracing source of funds, standing the test of time etc. and yet in my head I'm not able to envision the specific problem double entry can solve that single entry cannot. Somewhere in my head I feel a double entry system makes sense if you have two different parties making respective entry. But if it's all with a single party, single entry system should be equivalent to a double entry system. My accounting concepts are weak so I'm unable to justify. Hoping someone with more expertise can shed some light here.

alain94040 4y ago
Think of each transaction as a movement: it has a source and a destination. Therefore, you need to account for it in two places: where it came from, and where it went. Does that make more sense?
- rr888 4y ago
  I think you can expand this explanation with database terminology. In modern RDBMS, you could have naive implementation with two account's balance, and increment one decrement the other. But without transactions it just isn't safe, its better to have one row in a table with a debit and credit. Now if you're doing accounts by hand you really need that single line transaction record.
  - meekaaku 4y ago
    > its better to have one row in a table with a debit and credit. No. Some transactions have 3 lines, eg: two debits and one credit. Some examples: - Split payment at a shop, $100 item bought with $70 cheque and $30 cash would be credit sales $100 debit cash $30 debit bank $70 Now if you introduce sales tax or VAT/GST, its more complicated. Say the $100 item is actually $90 + $10 VAT, then entries goes: credit sales $90 credit vat-payable $10 debit cash $30 debit bank $70

svat 4y ago

There's another very nice description, with useful pictures, by Martin Blais (as part of the documentation of Beancount) at https://beancount.github.io/docs/the_double_entry_counting_method.html https://beancount.github.io/docs/the_double_entry_counting_m... (example picture that I would say is the heart of the idea: https://beancount.github.io/docs/the_double_entry_counting_method/media/19e2cc49a057dfeea1cf5254610eab4c9a124488.png https://beancount.github.io/docs/the_double_entry_counting_m... ) Another one, with completely different graphs, is by Martin Kleppman at https://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html https://martin.kleppmann.com/2011/03/07/accounting-for-compu... — despite the name ("Accounting for Computer Scientists"), on reflection / trying it out, I find it less useful than the Beancount one. (Both of these are actually linked in the second paragraph of the posted article, but they're independently worth mentioning / good.)

retetr 4y ago

Can someone explain. From their definition it looks like the credits and debits column in their example transaction table is flipped e.g. the first "debit" to the cash (debit normal) account increases the value, while the "credit" to the equity (credit normal) account also increases the value. (edited for spelling)

projektfu 4y ago
See my other comment here: https://news.ycombinator.com/item?id=32499123 https://news.ycombinator.com/item?id=32499123

akersten 4y ago

> A credit entry will always increase the balance of a credit normal account and decrease the balance of a debit normal account. Put differently: Not sure if the author is reading comments here, but the diagram after this sentence shows the opposite!

stocknoob 4y ago
Yes, that was quite confusing. Thanks for mentioning.
lucasrocha259 4y ago
Author here. We just pushed out a fix. Thank you for flagging!
selljamhere 4y ago
I noticed this, too. The summary bullets at the end of the post also oppose the diagram. Probably a simple mixup of credit/debit in the left column. The rest of the article usually lists do it first.

jedberg 4y ago

For those of you who like the blockchain, think of that as triple entry accounting -- you put one charge as credit in one column, debit in another, and a public record on the blockchain.

swyx 4y ago

former CFA turned developer here. I've been doing an informal workshop on "Finance for Developers", figured I should share my material here for people looking for more. Not selling anything.. yet but this stuff is easy for me to pump out given my previous career haha Reading: https://docs.google.com/document/d/1imIgNckZ_kM564fpGgTBtsqiGwRAIOcmA_hzuwRH4bo/edit https://docs.google.com/document/d/1imIgNckZ_kM564fpGgTBtsqi... 1hr Youtube workshop: https://www.youtube.com/watch?v=Lelq40jILA4 https://www.youtube.com/watch?v=Lelq40jILA4 2hr Audio podcast discussion: https://share.transistor.fm/s/0b9270a5 https://share.transistor.fm/s/0b9270a5 to make a point directly related to this post - i believe accounting is the starting point for finance - but you can learn "just enough" accounting to make it work.

quelltext 4y ago

I think the figure / chart in "Effect on balance by account type" is wrong / flipped. It says that debits decrease debit normal account balance which doesn't match the text description or subsequent examples.

lucasrocha259 4y ago
Author here. This is helpful feedback, we could have perhaps taken more time before jumping in on the Modern Bagelry example. A common misconception is that one account needs to increase while the other needs to decrease. But what we are actually showing that they can both increase or decrease in tandem, depending on the debit and credit entries in the transaction and the direction of the accounts. In the first transaction cash increases because it's a debit entry in a debit normal account (cash); and equity also increases because it's a credit entry in a credit normal account (equity).
- aktuel 4y ago
  So you basically have these two types of account, because you want all accounts to have a positive balance in general? If we would not care about certain types of accounts having negative balances, then we could say that for each transaction the sum of all account changes would always have to add up to zero. We could then still -depending on the account type- flip the sign after calculating the account balance. Am I understanding this right?
  - lucasrocha259 4y ago
    Part of the idea here is that debits = credits is a cleaner way to depict balances 'netting out to zero' than using positive or negative balances.
- quelltext 4y ago
  The main issue was that at the time the "Effect on balance by account type" figure was reversed / incorrect, and so the example was just not making sense. Reading on further and again I realized it was not the example but that figure that was wrong. I see that you fixed that now. Thanks.

sudhirj 4y ago

Can someone help with a few ideas on this topic? I've been volunteered to be the treasurer at my building home owner's association, and trying to keep accounts for the whole building on a single excel sheet is a shitshow. So obviously I'm building a SaaS that will handle all the accounts for every HOA in the whole world and become a trillion dollar product. But I need to figure out which accounts are debit normal and credit normal and how transactions should flow first. So far I have the following accounts: * Per-apartment accounts, like the account for Apt#A1, Apt#A2, Apt#B1 etc. * A Maintenance Receivable account - the account for maintenance payments that should have come in. * A actual current operating account - account that reflects the building's bank account, showing money that came in from apartments for maintenance payments and also expenses. * An Expenses account. For expenses. So far the typical transactions I can think of are: * Beginning of every month the maintenance is due (say 100), so each apartment gets a -100 with a corresponding +100 on Maintenance Receivable. * When an apartment pays, they get a +100, but this is money that actually lands in the current operating bank account, so that's a +100 too? I'm guessing this is where the genius of not using plus or minus but using debit and credit comes in. That avoids the confusion, one is a debit and one is a credit, but which is which and which is a debit normal and credit normal account? * When there's an expense, I remove money from the bank account account and put it in the expenses account. Seems sort of ok, but the Maintenance receivable account is always increasing. How do I set this up so I can correctly represent what an apartment owes while also capturing what it paid as inputs to the buildin's bank account?

epa 4y ago
Assets are +, Liabilities are -. So a receivable is an asset and +100 is correct. when the money comes in, you need to +100 cash and -100 receivable.
- sudhirj 4y ago
  So when an apartment pays, is 4 entries in the single transaction? Credit their apartment account, debit the bank account, credit cash and debit receivables? Never thought of making 4 entries for a single transaction.

dllthomas 4y ago

There is no accounting for developers.

umrashrf 4y ago

If you are in Canada, you might find this helpful https://www.youtube.com/watch?v=WV-vNltqasA https://www.youtube.com/watch?v=WV-vNltqasA

mguerville 4y ago

Great article by a company that's honestly been great to work with, I think it's interesting that they write such an entry level piece when their solution is enterprise grade but it shows their dedication to educating not just the users and stakeholders of the end product but also the implementers, which very few software companies do.

andix 4y ago

Some practical cases where you really need such a system: A customer pays one product with two different sources of payment (gift card + visa, or one half with cash and the other with card) You want to verify if the balance in the cash register, or on the credit card account are correct. You already received money from a customer, but it will take some time until you can create the invoice (for example you want to print the serial number on it, and don’t know it yet), but for legal reasons you are not allowed to change an invoice later. So you have to record a payment without having an invoice yet.

HatchedLake721 4y ago

I had a pleasure to dive deep into this topic and we built a double-entry bookkeeping system from scratch in a heavily regulated industry that tracked debt consolidation for thousands of customers with payouts to thousands of creditors. I think this is one of the most proudest things I was ever was involved in architecting, designing and building. I left before it got to prod, but from people still there, I've been told it's been working flawlessly!

biznickman 4y ago

I cannot upvote this enough. I worked at a fintech company that was vehemently opposed to using double entry accounting and it created an incredible amount of inefficiencies and massive errors and expenses at the company. If you are dealing with money in any system and tracking it in a database, double-entry accounting is not an option.

jdasdf 4y ago

I have 2 main issues with understanding double entry accounting, that i haven't really been able to grasp properly: 1 - How do i use it to keep track of multiple "currencies"? It's simple enough to remove 1$ from the cash account into the inventory account, but that 1$ i now have in the inventory isn't actually cash... How can i use this to keep track of the number of widgets i actually have in storage? Rather than the cost it took me to get them there. 2 - How do i account for profits? Back to the example, i move the 1$ from my cash onto the inventory. Great now i have 1$ in inventory. I sell half my inventory for 2$. How exactly do i account for this? I still have presumably 0.5$ in inventory, and now i got 2$ in cash, but where did that come from and go? Presumably i'd take 2$ from the inventory and put it in a client account, but does that mean i now have negative 1$ inventory? Sure the client account would also have another transaction putting the 2$ into my cash account. And wouldn't this make one transaction into actually 2 transactions? One from inventory to client, and one from client to cash? If you can help me grasp this i would really appreciate it!

sbuttgereit 4y ago
This is going to be quick, dirty, and simplistic. I've explained deeper in a different comment. But this should help. Things to keep in mind... The accounting equation: Assets = Shareholder Equity + Liabilities. This expresses what we own (assets) and who has a claim over what we own (shareholders, creditors). Shareholder's equity can be expanded as: Retained Earnings + (Revenue - Expenses); retained earnings is revenue - expenses in prior years. Transactions assuming you start with $1 in cash. When you buy the inventory you credit the Cash Account (asset) by $1 and debit the Inventory Account (asset) by $1. In essence you've converted the cash asset into an inventory asset. When you sell the inventory you have a multi-part transaction. Inventory movement: Credit the Inventory Account (asset) by $1 and Debit the Costs of Goods Sold Account (Expense) by $1. You no longer have the inventory. The Sale part: Debit the Cash Account (asset) by $2 and Credit the Sales Account (Revenue) by $2. You have received a new $2. In the end you remove the inventory as an expense to Costs of Goods Sold and you have new cash from sales revenue. From the accounting equation perspective it looks like: Before inventory purchase: $1 (Asset/Cash) = $1 (Equity, assuming it wasn't borrowed) + $0 (Liabilities) After Inventory Purchase: $1 (Asset/Inventory) = $1 (Equity) + $0 (Liabilities) After Sale: $2 (Asset/Cash) = $1 (Equity) + ($2 (Revenue/Sales) - $1 (Expense/COGS)) + $0 (Liabilities)

ghoward 4y ago

Funny that this would show up when a month ago, GnuCash was submitted on this site. [1] I decided then that I would take the opportunity to learn how to use it and learn accounting properly for my family budget, mostly because I want to start a small business eventually, and double-entry accounting will be necessary for that. So I did. It went extremely well. The GnuCash Tutorial and Concepts Guide [2] was exactly what I needed. For all you developers wanting to learn double-entry accounting, I have one piece of advice: actually learn to use the terms that accountants use. Sure, it may be annoying that you have to say that something is a "debit" or a "credit" versus just saying that it's a positive or a negative amount. But in my experience, that annoyance passes quickly once it clicks. Do take the time to learn it right. And if you use GnuCash, set it to use the standard terms. [1]: https://news.ycombinator.com/item?id=32136384 https://news.ycombinator.com/item?id=32136384 [2]: https://www.gnucash.org/docs/v4/C/gnucash-guide/index.html https://www.gnucash.org/docs/v4/C/gnucash-guide/index.html

contingencies 4y ago

I've implemented tens of accounting systems, always multi-currency and usually multi-lingual. Originally in RDBMS, but in the last decade generally with triggers in SQLite. The most complicated one I've done was Kraken (~2011) which needed arbitrary precision support for unknown future crypto asset types. Opine: (1) Accounting as a profession is being automated away as governments create APIs to facilitate report submission and SCM/ERP/payroll become automated. Not too soon. (2) Yes, IMHO absolutely the debit/credit account terminology needs to die. It's backward and a source of confusion for the non-indoctrinated. Use negative numbers and present formatting for antiquarians where required. (3) As a student of ancient history, falsely ascribing off-handed western-inventors to things is so 19th century colonialist. Double entry is just an overly-lauded stage in the development of accounting anyway, not the endgame. Ancient societies got by just fine tying knots in cords (ancient China, Maya, Polynesia, etc.) and many ledgers run fine without double entry now. It's primitive compared to what's available in computer science today. (4) Distributed transaction systems are an algorithmic problem, not an excuse for manual documentation. Let's give away autonomous implementations for free, make GAAP about reporting, standardize account and transaction identification and innovate on process. New systems recommendation: (1) For account identification, use IIBAN which provides IBAN-compatible account identification and checksums and is an open system @ https://github.com/globalcitizen/iiban https://github.com/globalcitizen/iiban (2) For all accounting, use UTC. (3) For transaction identification, use UTC second of origination (UTCSO) + account of interest (AOI; eg. IIBAN) + intra-second transaction identifier (ISTI). Free thoughts on forward-looking accounting systems @ https://raw.githubusercontent.com/globalcitizen/ifex-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco...

phil-martin 4y ago

One of my favorite resources on accounting is https://www.ledger-cli.org/3.0/doc/ledger3.html https://www.ledger-cli.org/3.0/doc/ledger3.html It's application specific, but has enough examples in there to remind me of accounting principles from years past. Combined with the other plain text accounting resources, it was the first resource that made everything "click" for me, well, for varying definitions of "click". I often refer back to it when I need to remind myself of things. One thing on my todo list to expierment with is modelling double entry accounting as a graph, with nodes of the graph an account, and edges of the graph a transaction with the two amounts on the edge. That's nice and all but the part I'm really interested in experimenting is modelling reconciliation as equivalencies of graphs. I have a separate graph that models the real world bank accounts and flow of cash, and organisational flow of money, and then I have my accounting graph that models all the transactions. For reconciliation I would go "these whole bunch of edges in this graph A are the same as all these other edges in graph B" I just want to see what falls out the other end...

pwpw 4y ago

As a CPA looking for an entry-level job as a software developer, it has been disheartening to see hiring managers brush aside my accounting knowledge and experience as next to worthless. I think the theory behind double-entry accounting is super interesting and a base-level knowledge would be helpful for many developers. Particularly those working at a small startup that have to wear the accounting/financial hat. The sooner you use double-entry accounting, the better your life will be in the future. Double-entry is an incredibly old system that's battle-tested, so it's remarkable to see some people still opposed to it today. It's reassuring to see so many comments here expressing positive sentiment around the topic!

jakemcgraw 4y ago
We’re (Harness Wealth) are always looking for developers with knowledge of US tax code hmu jake@harnesswealth.com

themadturk 4y ago

When I went to school for an AAA in Computer Programming in 1989-90, a quarter of accounting was required for graduation. The instructor didn't like computers (which was the reason about half the class was there), and tried his best to convince everyone they needed to major in accounting, but he was a good teacher and I learned a lot of stuff, none of which I've needed over the last 30+ years but all of which I was glad I learned.