31–40 of 66 posts
Nice article, I'd be curious to know if/how their engine abstracts the complexity behind multi-currency transactions, or whether they rely on the accounting model to handle multi-currency. We built our own double-entry accounting engine at my previous company, and while the engine was not as fancy as what Square describes, the real challenge was building out the accounting models that manipulated the engine's primiti…
Earlier quoted context omitted.
Rows in the database are never updated or deleted. Only new rows are added.
A blockchain could be used to enforce that immutability. Which might be an actual, useful application for blockchains.
Unless you're talking about a distributed public no-trust ledger, yes that can be solved with block chain as it's what Bitcoin is. But that's not a problem they're having.
This 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 debi…
> Surely some of their customers have competent accountants maintaining the business's books. This unasked-for effort will make their job harder.
Uh, why? It's trivial to present information tracked as positive debits and negative credits in two positive columns; keeping the internal architecture of the database this way should be irrelevant to the end user, it's just avoiding using a hack designed to optimize the experience of people doing a manual process with medieval European technology and attitudes towards negative numbers in an automated backend where none of the problems it mitigates exist in the first place.
I 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.
This 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…
> So your model used a many-to-one relationship when you really wanted a many-to-many?
In many schema discussions you’d be right, but in the case of payments systems it’s not the case. Payments and payouts are separate transactions and only loosely related. The allocation of credit from one leads to an increment in the settlement of the other, but there’s no structural relationship in the journal itself.
> Preventing inconsistencies by enforcing constraints is a key point of an RDBMS. This is literally why people use SQL DBs
The inconsistencies in question relate to the domain model of accounting, not referential integrity or other (normally) easily enforced database invariants.
> You mean, like a NOT NULL constraint? Or, if you mean zeroed out, an appropriate constraint and/or before update trigger protecting the amount?
When you want to archive off aged records, or constrain across db shards, this is a serious issue. Taking the piss doesn’t make it go away. But in that particular paragraph I believe they’re referring to the payout itself become void e.g. due to a reversal, and having designed around similar issues I understand their concern. It’s exactly where single-column ledgers become a huge pain in the audit.
It provides models with Postgres constraints to ensure the double entry accounting rules are not broken.
It isn’t the same scale as Books, but I imagine that won’t matter for a lot of use cases.
This 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 debi…
You just end up with an apparently negative balance in the income account that represents your own cut due to fees etc. From the GL point of view it looks like a subledger with a contra account but that’s nothing to faze a competent accountant. Back in the 13th century it was probably tricky to represent on an abacus, not so much now.
This 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…
>Preventing inconsistencies by enforcing constraints is a key point of an RDBMS. This is literally why people use SQL DBs.
This comment is not specific or related to the work at hand, but note that this is only true for a single-machine database or a sharded setup in which you never have to perform transactions across shards. That is, the ACID guarantees are only enforceable in most RDBMS if all your data is on the same machine.