Before Numeric, I was the first finance hire at a venture-backed startup. My first project was getting the company through a first audit.
I spent months on it. Drafting policies, creating schedules, posting journal entries. And when it came time to produce the final reports, I went back to Excel to build them by hand.
I remember thinking: are you kidding me? The system whose only job is to produce these statements can't even produce the statements I need.
After the audit we hired a team of terrific accountants, and they set up a rigorous month-end process. The same manual audit prep, now completed every month.
But here's what has always really struck me.
Very little of this work is ever used to run the company or actually understand the business. The auditors may get their report, but the general ledger contains none of the rich context that drives decision-making. The useful data ends up collecting dust in a google drive folder.
So finance teams spin up a new shadow system, reconstituting the ledger in a data warehouse and stitching together operational info. Companies have separate systems to report and analyze, to forecast and plan.
What seems perfectly natural to accountants is actually pretty counterintuitive: most of the actual work happens in external spreadsheets or point solutions.
Your business doesn’t even use the accounting database to make decisions. In effect, the ERP is relegated to being a simple repository for journal entries.
We believe that the limitation is the core data model.
AI needs context, journal entries have little context.
Today, we’re in the early innings of the AI age and there's a real opportunity to change the way finance and accounting teams work.
But, as most readers are well aware, AI runs on context. The more it understands about your business, the more informed and accurate the answer. We've all seen this.
And the general ledger, by design, has almost no context. Events are summarized into journal entries and often real, rich context lives in point solutions or subledgers.
So when you point AI at it, you get exactly what you'd expect. Features that summarize at the surface. Dashboards that visualize at the surface. Agents that guess. Because they have to. They're inferring from totals.
Put AI on top of the general ledger and you've built a faster horse.
If we want to truly leverage AI, we need to cut to the core and build a new system that starts from the opposite direction.
We have to start by building the full picture of the business. Every event, every resource, every counterparty, connected. A system that knows exactly what's happening and why. A system where you define your policy once, and every financial record is a result of it. A system where the general ledger is just another report you compute, not something you write to.
Said otherwise: model the business, and derive the accounting from that model.
A different data model is needed.
Now, it might not be obvious why we need a richer data model. So let’s consider an example.
Take a revenue contract. It starts simple: an implementation fee and a ratable subscription. You project the ratable recognition and allocate the transaction price. Then you add seats. Maybe you miss an SLA and issue a ten percent credit. Or you offer a discount for an early renewal. Six months in, you realize you used the wrong SSP. With each change, the journal entries get harder and harder to interpret.
The objects of accounting don’t just happen as one-off events. They get modified, extended, renegotiated. Errors and information get caught late.
To process these events, you need the full picture of the original contract and all the subsequent changes. And you can’t reconstruct that picture from the trail of posted journal entries.
The journal entry loses three core pieces of information.
The first is traceability. It's impossible in GLs today to click from an income statement through to the exact JEs through to the original contract. No underlying record exists against which the output can be checked, so correctness is established by manual review or not at all. Modifications become grueling. Investigating variance is a treasure hunt.
The second is dimension. The business event carried a customer, product, region, sales team, term, and channel. Those attributes are what make the resulting number interpretable, but the entry preserves only a limited set. So, teams often turn to the chart of accounts to try to capture this dimensionality or purchase FP&A software that bridges information in their GL with business context. Accounts multiply. Naming conventions become architecture. Every new reporting request creates another debate about where the debit or credit belongs.
The third is time. Business activity has a lifecycle. Contracts are amended, renewed early, partially refunded, or expanded mid-term. A journal entry is a dated posting, not a model of the underlying object and its history. When reality changes, there is no single object to update. Teams reverse the original entry, repost it at new values, and maintain a parallel record of what actually occurred.
The journal entry made sense as the center of accounting historically - you needed to compress context via pen and paper. As finance teams are asked for far beyond financial statements, they become one piece of the puzzle versus what the system revolves around.
Finance needs a data platform with a controlled, auditable accounting layer on top.
Instead of an horing on the journal entry, we believe the finance system of record should anchor on the raw business event.
General ledgers were designed with one goal: produce a trial balance. That's important, but what finance teams need today is increasingly a data platform built for finance, where the trial balance is just one report the system can produce downstream of the financial graph.
Want revenue by geo by sales rep? Cloud and token spend allocated to each customer? Sales and marketing spend by the customers you acquired this period? Your financials quickly restated under a new department hierarchy?
Traditional accounting systems make this type of work incredibly hard. They reduce each transaction to a journal entry: an amount, an account, and a fixed set of segments chosen up front. Once that entry is posted and locked, it's a static snapshot, cut off from the record that created it and limited to the dimensions someone thought to include at the time. If you want a new view, you're reclassing entries or exporting to spreadsheets.
The financial story of a business isn't captured by independent transactions moving value within a chart of accounts. The real picture is long-lived objects, like invoices, contracts, and leases, the relationships among them, and the business events that happen to them. That picture is the financial graph, and the ERP has no model to represent it.
Numeric’s Financial Data Platform does. We keep those objects and their relationships as the source of truth, and generate the trial balance from them on demand.
Controls still apply, and debits still equal credits.
When an object changes, everything downstream updates automatically, instead of being manually re-booked for each view your business needs. This means that when something changes, you can encode the latest correct interpretation, and the system will automatically reprocess the full accounting treatment.
The FDP ingests and stores full source information, processes the accounting and reporting on top of that data set, and builds the financial graph of your business from end-to-end.
By treating accounting as a derived layer atop source data, it’s almost more like Snowflake with accounting logic than it is like NetSuite.
Accountants become finance engineers.
Before today, the job of the accountant when facing some unhandled event was to turn that event into a journal entry. Now, the job is to modify the system to perform the accounting. Your judgment informs hard-coded accounting policies and exceptions or sensitive issues are raised directly to you.
This is accounting largely as an engineer would do it. Your focus isn’t on manually entered journal entries, you don’t transform data. The system processes the data, and you program the system.
