Two decades of implementing other people’s ERP software gives you a specific kind of education. You learn what the systems can do and what they claim they can do. You learn where the architecture bends and where it breaks. And eventually, you have a very clear picture of the mistake that virtually every system makes in the same way — a mistake you’ve been working around on behalf of clients for your entire career.
I started my career implementing SAP. Not the mid-market editions — the full enterprise platform, for companies large enough that the implementation team was itself larger than many of the companies I’d later help move to cloud ERP. The work was rigorous, technically demanding, and deeply instructive about how financial systems need to behave at scale.
After SAP came NetSuite implementations, then SAP Analytics Cloud, then the full arc of what mid-market finance looks like in practice: companies between $20M and $200M, trying to build financial infrastructure that could support growth without requiring enterprise-scale resources to maintain.
What eighteen years teaches you
The pattern I kept seeing, across platforms and industries and company sizes, was a specific kind of structural problem. The general ledger was always downstream of everything else. Invoices were created in the billing system and posted to the GL. Purchase orders were created in procurement and posted to the GL. Subscriptions were created in the subscription platform and posted to the GL. The GL received what it was sent, recorded it, and was treated as authoritative — without having any independent verification that what it received was complete or correct.
I spent years helping clients reconcile the consequences of this architecture. Subledger-to-GL differences at month-end. Billing system revenue that didn’t match the recognized revenue in the ERP. AR aging in the CRM that was different from the AR aging in the GL. These weren’t individual bugs in individual systems. They were predictable outputs of an architecture that puts the financial record downstream of the business events it’s supposed to record.
Every workaround we built — every reconciliation process, every close procedure, every integration monitoring setup — was compensating for the same underlying design choice: that the ledger comes last.
The architecture question
The question I kept coming back to, and eventually couldn’t stop asking, was: what happens if you reverse it? What if the ledger comes first? What if every financial event has to pass through the ledger before it can exist anywhere else? Not as a destination, but as a gate — a constitutional requirement that every economic event satisfy the financial rules before it’s real?
The consequence of that question, followed seriously, is that reconciliation becomes impossible because there’s nothing to reconcile. The billing system doesn’t maintain an AR balance that gets posted to the GL — it posts journal entries to the ledger, and the AR view is derived from those entries. The subscription platform doesn’t sync to the finance system — it writes to the ledger, and the subscription status is a view of those entries filtered by contract type.
Every module in the system is reading from and writing to the same financial foundation. The subledgers are not separate systems — they’re lenses on the ledger, scoped to the transactions relevant to their domain.
Why it took this long to build
This architecture is harder to build than the alternative. The easy path is what everyone builds: separate modules, connected by integrations, with the GL as the final destination. It maps onto organizational structure, it maps onto how most teams think about software (“the sales tool and the finance tool are different tools”), and it’s what all the reference architectures show.
Building against that grain requires holding the ledger-first principle as a hard constraint through every architectural decision — which means saying no to things that would make individual modules faster to build but would compromise the constitutional model. It requires database-layer enforcement of rules that most systems implement at the application layer. It means the foundation has to be right before the surface can exist.
Eighteen years of watching the destination-ledger model produce the same problems in the same ways made the constraint feel not just acceptable but necessary. Nue is built the way it is because I spent eighteen years learning exactly what happens when you build it the other way.