Building a Scalable Accounting Ledger
scratchdata.com
Building a Scalable Accounting Ledger
1–10 of 40 posts
Re: Building a Scalable Accounting Ledger
#2This claims 1 and -1 is confusing, then proceeds to use the confusion. Why not use the language of the problem domain?
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.
Decreases the opposite.
Using 1 and -1 is nonsensical because their meaning in mathematics is fixed, while as shown by the rules above, in accounting DR/CR meanings change.
So a couple of example journal entries…
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
Is this too hard to model? I suggest not?
Re: Building a Scalable Accounting Ledger
#3[dead]
Re: Building a Scalable Accounting Ledger
#4This claims 1 and -1 is confusing, then proceeds to use the confusion. Why not use the language of the problem domain? 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. Decreases the opposite. Using 1 and -1 is nonsensical because their meaning in mathematics is fixed, while as shown by the rules above, in accounting DR/CR…
Also, money is usually kept as integer of cents. It is clear, inambiguous and allows for other rounding rules that sometimes pop up in legislation.
Re: Building a Scalable Accounting Ledger
#5I think the transactions table is misnamed. This is a table of posting legs. Which all must balance for a single transaction.
I don'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.
Re: Building a Scalable Accounting Ledger
#6This claims 1 and -1 is confusing, then proceeds to use the confusion. Why not use the language of the problem domain? 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. Decreases the opposite. Using 1 and -1 is nonsensical because their meaning in mathematics is fixed, while as shown by the rules above, in accounting DR/CR…
I think you think it's confusing only because you're not used to it. The two models are mathematically equivalent.
The rules are unambiguous. Values which indicate capital are positive. Values which indicate ownership are negative. An increase in capital corresponds to an increase in ownership of said capital, which add up to zero. Perfectly balanced, as bookkeeping should be.
I find CR DR to be more confusing than +/-, because the latter works out naturally with basic arithmetic, whereas the former requires this arbitrary DR CR crud, which are made up terms that literally mean nothing and you have to rote memorize how they apply to different accounts (and to add insult to injury, the terms often have the exact opposite meaning to consumers due to how banks present the terminology, which means the terms literally can mean either thing depending on the context).
Re: Building a Scalable Accounting Ledger
#7This claims 1 and -1 is confusing, then proceeds to use the confusion. Why not use the language of the problem domain? 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. Decreases the opposite. Using 1 and -1 is nonsensical because their meaning in mathematics is fixed, while as shown by the rules above, in accounting DR/CR…
I think you think it's confusing only because you're not used to it. The two models are mathematically equivalent. The rules are unambiguous. Values which indicate capital are positive. Values which indicate ownership are negative. An increase in capital corresponds to an increase in ownership of said capital, which add up to zero. Perfectly balanced, as bookkeeping should be. I find CR DR to be more confusing than +…
I think where this would get confusing is that a positive number would have to decrease some accounts, but increase others, right?
Re: Building a Scalable Accounting Ledger
#8I didn't get the date as text and the amount as real in table transactions.
Re: Building a Scalable Accounting Ledger
#9This confirms what I’ve heard repeated before: it’s easier to teach programming to an accountant than accounting to a programmer.
Re: Building a Scalable Accounting Ledger
#10I don't really see how what is described is "scalable".
With hundred thousandth of transactions, performing the sums will be expensive.
And nothing ensure the safeness of the order of entries...