Accounting For Developers, Part I
Interesting, I&#x27;d heard of &quot;double entry&quot; before but I&#x27;ve never used it. I&#x27;ve written and maintain code that uses only 1 record per transaction and I&#x27;d love resources to look into that go into the &quot;why&quot; of double entry.<p>For example my current &quot;transactions&quot; table has fromUserId and toUserId columns (1 user = 1 account) and so purchases&#x2F;transfers&#x2F;reloading your account all take just 1 row. For reloading the &quot;fromUserId&quot; is a system user that is allowed to go &quot;into the negative&quot; since it&#x27;s responsible in a way for &quot;minting&quot; money into the system.<p>I&#x27;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. &quot;Spent $X at vendor&quot; makes sense as a description from the user&#x27;s perspective but not from the vendor&#x27;s. Double entry would solve this as I could generate a description specific to each user&#x27;s perspective &quot;Spent $X at vendor&quot; &quot;Sold $X to user&quot; or something like that.<p>But I&#x27;m sure there are other advantages to a double-entry system that I&#x27;m missing so any resources would be appreciated.<p>I&#x27;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.