3 ms·

Isn't accrual accounting the use of an account to log transactions at the time of sale rather than at the time of payment? If so the same technicalities apply,

Isn't accrual accounting the use of an account to log transactions at the time of sale rather than at the time of payment? If so the same technicalities apply, you can log your credits and debits in different accounts, no need for ACID transactions here, unless my experience in this area is flawed. > Well good luck with selling your "eventually consistent" accounting system. There's a reason why "eventually consistent" works in accounting, and that's the cut-off time. You don't require from your data to be consistent at every instant, but rather require that your accounting be guaranteed consistent at cut-off time, because that's the data that you base your reporting on. One way to guarantee that is to use only ACID transactions, but it's only one of many ways, and it has flaws (that might or might not be blocking depending on how distributed your architecture is).

jacques_chester 14y ago
> you can log your credits and debits in different accounts, no need for ACID transactions here, Um, yes. There is. There totally is. There's a reason ACID is illustrated with examples based on debiting one account and crediting another at what is a logically simultaneous instance (Atomicity). Because if you do one and not the other, your accounts are now Wrong-with-a-capital-W-for-legal-consequences (Consistency). We need these to happen in some sort of order, so we pretend only one such entry happens at a time (Isolation). It would also be jolly nice if we didn't lose the records (Durability) every time the RAM lost its juice. > You don't require from your data to be consistent at every instant Again: yes. You do. That's literally the entire purpose of double-entry bookkeeping: to guarantee that the books are always consistent.