Designing Accounting and ERP Platforms for Real Businesses
Accounting software isn't a features list — it's a trust system. Here's what that changes about how it should be built.
A bug in most software produces a confused user. A bug in accounting software produces a wrong number on a tax filing. That difference should shape almost every design decision.
Every number needs a paper trail
In an accounting system, no total should exist without a traceable path back to the transactions that produced it. That's not a reporting feature — it's a structural requirement that has to be designed into the data model from the first migration, not added later when an audit asks for it.
Credit notes and payments are not simple CRUD
Applying a credit note, recording a partial payment, or reversing an entry all touch multiple records that need to stay consistent even under concurrent use. These workflows deserve transactional database functions with proper locking, not client-side logic that assumes nothing else is happening at the same time.
| Workflow | Naive approach | What holds up |
|---|---|---|
| Payment recording | Update balance directly from the client | Server-side transaction with row locking |
| Credit note application | Manual balance adjustment | Atomic function tying credit to specific invoices |
| Multi-company reporting | Separate queries merged in the UI | Company-scoped queries with shared aggregation logic |
The reconciliation trap
If a system makes it possible for the displayed balance and the sum of underlying transactions to ever disagree, it will happen — usually discovered by a customer, not by testing.
The takeaway
Accounting software is judged on whether the numbers can be trusted under pressure — concurrent use, partial failures, audits years later. Building for that bar from the start costs more up front and far less over the life of the product.
Does this topic connect with a product or challenge in your team?
Let’s discuss your product needs, architecture or workflows.
