Comment by jacques_chester | Hacker News Reader

Comment by jacques_chester | Hacker News Reader

Parent Full thread

jacques_chester

> Actually they don't need to use transactions at all in accounting. All they need is a debit history and a credit history.

If by "debit history" and "credit history" you're thinking of how your bank transactions are recorded, then you may wish to look into the concept of accrual accounting.

Merely tracking cash in and out doesn't give you a full view of what the business is up to.

> accept that some figures won't reflect exactly the reality of the balance, since some compensations are done immediately (automatically) while others are performed, manually, days or week later.

Well good luck with selling your "eventually consistent" accounting system.

While I would prefer if accounting systems could be improved to record and aggregate uncertainty for those places where values entered are based on what is realistically an estimation rule (eg depreciation, stock valuation rules etc), the fact is that all such rules are stated as part of the reports. Within that framework, you report as correctly as possible to the cent or better.

Otherwise bad things happen. Accountants lose their charters. Executives go to jail. That sort of thing.

Serious business is ... serious business.

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).

> 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.

Otherwise bad things happen. Accountants lose their charters. Executives go to jail. That sort of thing.

Funnily enough, "Enron" was the first name that sprang to mind whilst reading comment.

That was due to bad wording on my part, my bad.

I meant that one should accept that at any random moment the data might be inconsistent with the reality, but after the cut-off time the data for the previous period is guaranteed to be consistent.

Reply on news.ycombinator.com