this is event sourcing
In that event sourcing is largely inspired by accounting record keeping and how various accounting statements are traditionally implemented as computed functions of the ledger entries.
Books: an immutable double-entry accounting database service
21–30 of 66 posts
Re: Books: an immutable double-entry accounting database service
#22For personal use, Beancount[1] looks like a good double-entry bookkeeping tool. [1] https://docs.google.com/document/d/1RaondTJCS_IUPBHFNdT8oqFK...
Beancount is a Python port of ledger-cli https://www.ledger-cli.org/ https://github.com/ledger/ledger/wiki/Ports
There are similarities, but they are different products with different philosophies. See "A Comparison of Beancount and Ledger & HLedger" in the linked docs.
Re: Books: an immutable double-entry accounting database service
#23Isn't this just Accounting 101?
I'm a little surprised they didn't use double entry accounting from the beginning.
Re: Books: an immutable double-entry accounting database service
#24This looks good but some of the background has the air of the kind of artificial problems presented in late night infomercials: > It’s impossible to split a single payment into multiple payouts, since there is a many-to-one relationship of payments to payouts. So your model used a many-to-one relationship when you really wanted a many-to-many? > Since this is just a SQL database, there’s nothing preventing the payout…
Yeah this is really confusing to me. Especially given that tenants are unlikely to mix books, just out of the box multitenant Citus + Postgres would probably get them where they needed with super good perf characteristics.
Hindsight and all that, and every team has inhouse stuff that could probably be gotten rid of, but this seems like a major operational danger compared to relying on more battle-tested stuff. They should probably get the Jepsen guy on this and see if he can get race conditions
Re: Books: an immutable double-entry accounting database service
#25This looks good but some of the background has the air of the kind of artificial problems presented in late night infomercials: > It’s impossible to split a single payment into multiple payouts, since there is a many-to-one relationship of payments to payouts. So your model used a many-to-one relationship when you really wanted a many-to-many? > Since this is just a SQL database, there’s nothing preventing the payout…
Infomercials work.
And not just for overpriced knives.
Re: Books: an immutable double-entry accounting database service
#26Excellent work and a great write-up! I’ve been implementing double blind accounting systems the past decade or so and what they teach in accounting classes is spot on there just isn’t much need for more complexity. There is the added benefit of staying PCI compliant and reconciling things the right way. Doing splits like this is hard work but I gather there are lots of powerful tools out there to help nowadays. Having worked with NACHA and Wells Fargo getting those ACHs done in one fell swoop is extremely innovative actually the system doesn’t lend itself to this very well.
Re: Books: an immutable double-entry accounting database service
#27I actually submitted a YC application for the upcoming batch to work, more-or-less, on exactly this idea - a double entry accounting service for developers.
This sounds like something internal...I don't think developers or typical small businesses need (or would want to!) to store their double-entry accounting database in shards across Google Cloud Spanner & Kubernetes clusters... Good luck with your application -- I, for one, think there's a need for it. I've wished for years that someone would put something like a secure, web-based Gnucash out into the world.
Doesn't necessarily need to be hosted, although given that people are fine with running Quickbooks or any other SaaS it's hard to see why they wouldn't be fine with ledger SaaS.
Can still make a case for licensing, though, depending on the features.
We built this for our internal accounting, it's a ledger service that enforced immutable double entry rules and can run as a container with a Postgres DB configured. https://github.com/realimage/qledger
Re: Books: an immutable double-entry accounting database service
#28So other accounting software provides mutable ? Square are you serious?
Just adding a authentication layer over it and calling immutable
Re: Books: an immutable double-entry accounting database service
#29This looks good but some of the background has the air of the kind of artificial problems presented in late night infomercials: > It’s impossible to split a single payment into multiple payouts, since there is a many-to-one relationship of payments to payouts. So your model used a many-to-one relationship when you really wanted a many-to-many? > Since this is just a SQL database, there’s nothing preventing the payout…
It wouldn't be too remarkable if they stopped there. It's not unusual for enterprise-targeted application databases to return nothing when one queries sys.foreign_keys.
However, they've done the extra credit work to redefine double entry bookkeeping for some indiscernable reason.
> In fact, for the ease of modeling we relaxed how we reason about it and we don’t stick to standard Double Entry Accounting which has debit-normal and credit normal books which determine the sign as we prefer to consistently treating debits as positive and credits and negative.
Surely some of their customers have competent accountants maintaining the business's books. This unasked-for effort will make their job harder.