[berkes]

You may want to look into 'event sourcing' too. Which is an architectural pattern, very well suited to deal with most accounting problems you describe.

I've built a billing system for a hosting platform. Back when all I knew was MVC (and the then common index.php ballofmud). I wish I had known about eventsourcing then, because so many problems that I spent weeks on, would have never occurred, or been solved in hours.

Eventsourcing comes with its own downsides, requires your mindset to change (esp hard in a team that has been doing relational databases or MVC for years), and is convoluted. But it is a very good fit for a large swath of problems. Financial ones the most.

[sorbits]

> 'event sourcing' […] is an architectural pattern, very well suited to deal with most accounting problems

I believe double entry accounting can be described as following this architectural pattern (despite predating it with hundreds of years).

Double entry accounting has both a ledger and a journal. The ledger describes the actual transactions, the journal groups multiple transactions and assigns a “why”, it can also link the journal entry to an invoice, receipt, credit note, or user who caused the journal entry to be created.

So the journal is your event log (not the ledger).

> Eventsourcing comes with its own downsides, requires your mindset to change

Similar to double entry accounting: The learning curve I would say is the “chart of accounts”, how to express everything as ledger transactions, be it tax, fees, discounts, credits, prepayments, etc.

But it can all be done, and once you understand the system, it becomes trivial and extremely flexible.

A rule of thumb is that any number in the interface should come from the ledger, e.g. if you issue an invoice and give your customer a discount, there must be a ledger entry corresponding to that discount.