Building a Scalable Accounting Ledger

This claims 1 and -1 is confusing, then proceeds to use the confusion. Why not use the language of the problem domain?<p>The rules are unambiguous. An increase in assets are a DR, increase in liabilities a CR, in income a CR, in expenses a DR, in owners equity a CR.<p>Decreases the opposite.<p>Using 1 and -1 is nonsensical because their meaning in mathematics is fixed, while as shown by the rules above, in accounting DR&#x2F;CR meanings change.<p>So a couple of example journal entries…<p><pre><code> Product sale for cash Sales CR 100 Bank DR 100 Payment of rent Rent DR 50 Bank CR 50 Sale for cash where tax collected and owed Income CR 70 Tax Payable CR 30 Bank DR 100 Monthly petty cash tin entry Postage DR 5 Accounts receivable DR 20 (loan to John) Transport DR 15 (taxi Paul) Bank CR 40 </code></pre> Note that your bank statement is from the banks perspective. When you put money into the bank it is a CR because it is increase in the banks liability.<p>Is this too hard to model? I suggest not?

Did not expect this to hit the front page! A few notes:<p>- 1 always represents debit and -1 always represents credit. Regardless of whether it is an asset or liability account.<p>- Each account has what is called a &quot;normal balance&quot;. This tells us whether you increase the value of the account using debits or credits. This is also modeled as 1 or -1.<p>- Amounts are always positive<p>- To find the actual dollar value for a transaction, you can multiply: amount * direction * normal. If the direction and normal are the same sign, then that means we increase the value. Otherwise we decrease. Your code doesn&#x27;t need to know which accounts are assets vs liability vs equity in this scheme.<p>- Of course, you still need to know whether to insert transactions as debit or credit, and you need to know the normal balance of your accounts. But once you figure that out (by googling, or talking to your finance team) then the data model takes care of the rest.

Tangentially related, I know little about double-entry accounting and was wondering what CR and DR meant. If CR was credit, then what was DR? It&#x27;s somewhat obviously debit, but why DR and not DB or some other abbreviation that uses letters in &quot;debit&quot;? I found a beautiful answer here [0] in the Accounting Historians Journal.<p>[0]: <a href="https:&#x2F;&#x2F;egrove.olemiss.edu&#x2F;aah_journal&#x2F;vol13&#x2F;iss2&#x2F;12&#x2F;" rel="nofollow">https:&#x2F;&#x2F;egrove.olemiss.edu&#x2F;aah_journal&#x2F;vol13&#x2F;iss2&#x2F;12&#x2F;</a><p>Edit: I should add that CR and DR at one point in time were related to creditor and debitor. I referenced that article, because it&#x27;s the journey of the author to find an answer that I enjoyed about it.

I think the transactions table is misnamed. This is a table of posting legs. Which all must balance for a single transaction. I don&#x27;t think you should get hung up on +ve-ve versus cr and Dr. When double entry was formalised negative numbers were not common and then thought errant. It is only in the eighteenth century it became normal. I enjoyed the entry. Note that you might you use different minimum fractions eg we use 0.00001p as a discrete value.

Feels more as a way to introduce a product (scratch data), rather than a technical article. If you have only one entity to manage accounts for - why would you need to build an accounting engine? In other case, when you manage accounts for multiple entities, such as different &quot;clients&quot; or &quot;branches&quot; - you have millions of transactions, and a query such as &quot;get accounts for this client&quot; will take a long time - and you still need to introduce some kind of materialized views.

This confirms what I’ve heard repeated before: it’s easier to teach programming to an accountant than accounting to a programmer.

How is this any difference with using the sign of the amount column to signify debit or credit? Using that approach at least you save a column. Otherwise have explicit debit and credit columns if you want to be &quot;consistent with how accounting is done&quot;.

I don&#x27;t really see how what is described is &quot;scalable&quot;.<p>With hundred thousandth of transactions, performing the sums will be expensive.<p>And nothing ensure the safeness of the order of entries...

I didn&#x27;t get the date as text and the amount as real in table transactions.

Why would you want to build your own accounting ledger from scratch? Accounting is a completely new domain for most engineers, and TigerBeetle (<a href="https:&#x2F;&#x2F;tigerbeetle.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tigerbeetle.com&#x2F;</a>) already solves this problem.