Why would you want to build your own accounting ledger from scratch? Accounting is a completely new domain for most engineers, and TigerBeetle (https://tigerbeetle.com/) already solves this problem.
Building a Scalable Accounting Ledger
11–20 of 40 posts
Re: Building a Scalable Accounting Ledger
#12This 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.
Money exists outside us dollar and should be stored ideally a a composite of currency and decimal or just a decimal.
Then use currency specific rounding rules and always defer to CLDR [0] when displaying.
1. https://cldr.unicode.org/translation/number-currency-formats...
Re: Building a Scalable Accounting Ledger
#13I 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...
I think they were suggesting they chose "a column-oriented database like Clickhouse" to solve the summing problem for them, with some magic under the hood, maybe doing aggregates, as was mentioned separately as a solution if you wanted to roll your own.
Re: Building a Scalable Accounting Ledger
#14Feels 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 "clients" or "branches" - you have millions of transactions, and a query such as "get accounts for this client" will take a long time - and you still need to introduce some kind of materialized views.
Re: Building a Scalable Accounting Ledger
#15Why would you want to build your own accounting ledger from scratch? Accounting is a completely new domain for most engineers, and TigerBeetle ( https://tigerbeetle.com/ ) already solves this problem.
I think our definition of «solved» might be slightly different hehe.
«The production release of TigerBeetle is imminent.»
Not putting money into this system any time soon in other words.
Re: Building a Scalable Accounting Ledger
#16I 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…
How many legs are there in a transaction?
Re: Building a Scalable Accounting Ledger
#17Earlier quoted context omitted.
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.
Money exists outside us dollar and should be stored ideally a a composite of currency and decimal or just a decimal. Then use currency specific rounding rules and always defer to CLDR [0] when displaying. 1. https://cldr.unicode.org/translation/number-currency-formats...
There is always a main currency for any entity, so any foreign currency dealings or having a reporting currency adds some fun in the form of changing exchange rates, realized/unrealized exchange rate differences, rounding errors and other shenanigans.
Re: Building a Scalable Accounting Ledger
#18This 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…
Then you get to corrective transactions, where a normal return is
Sales DR 100
Bank CR 100
Sales CR -100
Bank DR -100
Re: Building a Scalable Accounting Ledger
#19This 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…
> Is this too hard to model? I suggest not?
I'm sure I could put my mind to following those rules, but what's to be gained?
If 'assets' and 'income' are opposites, and 'income' and 'liabilities' are the same, then I'm just not going to bother. What if my income is paid in assets in the form of $1 bills? CR or DR?
And 'equity', Jesus is that a nebulous concept.
Re: Building a Scalable Accounting Ledger
#20Earlier quoted context omitted.
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?
It does not because if you use + and - liabilities are negative and assets positive and if you add all balances the sum is zero. Actually the commercial accounting software I use works like that, it uses negative balances for liability accounts.