A different design problem
When Intuit shipped QuickBooks in 1992, it was not building a cut-down version of enterprise accounting software. It was solving a fundamentally different problem: the bookkeeper, the owner and the person answering the phone are often the same person, and that person has perhaps twenty minutes before the next interruption. The product had to close itself to error before the error could be made, not audit the trail afterward.
Sage reached the same conclusion from the other side of the Atlantic, building through the 1980s toward software that a small British manufacturer could run without a dedicated finance department. Both companies arrived at roughly the same design constraint — the operator's time is the scarce resource — and the product reflects that in ways that make it almost unintelligible to enterprise buyers.
Before the software, the deadline. The close is older than every system that serves it.
Thraex picture desk
Chart-of-accounts flexibility, the thing an ERP implementation team spends months on, is deliberately limited in QuickBooks. Drill-down audit trails, a legal requirement in systems serving large organisations, are present but shallow. Per-seat licensing is priced for a business with two or three users, not a procurement committee with a budget code. The software assumes that the person who enters the invoice will also run the payroll and reconcile the bank statement.
This is not a deficiency. It is an accurate read of the market: millions of businesses never grow past the point where these tradeoffs become painful, and a product optimised for their actual workflow is genuinely more useful than one which preserves every option. The relational model underneath QuickBooks is the same mathematics Edgar F. Codd published in 1970; what changed is that Intuit wrapped it in a workflow that assumes the operator is not a trained accountant.
The failure mode, when it comes, is data migration: a business that outgrows QuickBooks discovers that its chart of accounts, its customer history and its payroll records are structured around assumptions that larger systems do not share. Getting out is harder than getting in — which is, in the documented history of enterprise software, the familiar pattern.