When I started building Sonar AI, I was pretty sure I knew what the challenging part of the project would be. I figured that if I could find a way to present an AI model with enough data, everything else would follow.
What I found was actually the opposite. When I stopped moving data around - stopped trying to fill the context window with as much data as it could handle - things snapped into place. And this was only possible because of the way Sonar works - how it's embedded within NetSuite, with access to everything it needs (real NetSuite reports, data, etc), combined with the capabilities of a modern Web browser, and powered by the most advanced frontier AI models.
In this article I'll explain how Sonar AI works with large volumes of data. I'll clear up some of the misconceptions about how Sonar works, and show how Sonar isn't just another AI chatbot.
An Example
Before I dig into the technical aspects of how Sonar AI works, let me give an example of a project that involved working with a lot of data.
This morning I ran a gross-margin analysis inside a live NetSuite account. I wanted a comparison of the first half of 2026 versus the first half of 2025. And I wanted more than just numbers. I wanted to know if the margin was moving because of unit cost, pricing, volume, or some mix of those factors, and I wanted the analysis down to the individual item.
Sonar read every posted invoice and cash-sale line item in scope, plus every item-linked cost of goods sold (COGS) posting from the fulfillments. No sampling was needed, and no row cap was hit.
Equally important and notable is that nothing was exported to a spreadsheet first, and nothing was shipped out to third party data warehouses. The aggregation ran as SuiteQL queries directly inside of NetSuite. One pass pivoted both periods per item. About 130 summary rows were returned, and that was the entire amount of data that was ever passed to the model.
Then a dynamically generated script computed the margin bridge (the price effect, cost effect, volume and mix, new items, discontinued items) as ordinary arithmetic. Not estimated by a language model, which is a thing models are genuinely bad at. The five components summed to +$83,741.33, which is the real change in gross margin for the period, to the cent, with every input traceable back to a query I could read and re-run.
What Sonar found, in a couple of minutes, was that the margin growth was coming from volume, not price. Pricing was nearly flat. Unit costs barely moved - one item out of 118 shifted more than two percent. And a family of backpacks that had sold 209 units the year before sold 9 this year, at slightly higher prices, with margins unchanged. That's not price pressure. When the price holds and the volume falls off a cliff, then you're usually looking at a stock-out or a delisting, and that's the kind of thing you only catch at the line level.
I want to emphasize that the model never saw a single transaction line. It saw 130 summary rows, and the analysis still covered every line that mattered. That gap - between what gets computed and what the model reads - is really the whole idea, and it's worth slowing down on because it sounds like a contradiction until you see the mechanics.
The Database Does the Math
Sonar isn't really doing anything magical here. This is just how databases work, and Sonar is making good and proper use of the Oracle database that powers NetSuite. I think that over time we've collectively stopped thinking about this because the AI conversation has trained us to think about context windows instead of queries.
When you run an aggregation like the one I described above, the query engine reads every line in scope, filters it, multiplies it out, and sums it.
Every applicable row gets read. What comes back is one row per item, with revenue, units, and cost for each period sitting side by side. In this account, that was a few thousand lines in but only 130 rows out. In an account with millions of lines across 16,000 items, the same query returns 16,000 rows. So the reading scales with the data, and the result scales with the question being asked. Those are two different numbers, and once you separate them, working with large volumes of data becomes a non-issue.
A margin bridge across two periods needs six facts per item - revenue, units, and cost, twice. Everything downstream is arithmetic on those six numbers. So the sequence that Sonar ran was:
- The model wrote the query. This is the part that takes real reasoning - what's in scope, how the periods are defined, how COGS lines tie back to items, etc.
- The database ran the query over every line and returned the per-item summaries - and the query is deterministic. You get the same answer every time you run the query.
- A script did the bridge math on those summaries, and it's also deterministic, because the model isn't adding up numbers and doesn't need to.
- The model reads the small result and does the thing it's really good at - noticing that a backpack family lost 200 units at higher prices, and reasoning about what that pattern probably means.
Notice what never happened anywhere in that process. A million rows never traveled anywhere. Not into a context window, not into an attachment, not into some data warehouse in someone else's cloud.
The detailed data stays in the database, and that's what allowed me to dig deeper into what the model initially found. If my next question was about which locations drove the backpack decline, then that just resulted in another query over the same lines, and another small summary comes back. The depth comes from being able to keep asking, not from having dragged all of the data out of the database on the first trip.
Most of What You Analyze Isn't Big
Before I continue, I want to reframe the whole large data volume issue.
Your business likely produces transaction lines by the million. But the things you really want to analyze - the objects your questions are about - are likely far fewer. A few thousand items. A dozen locations. Twelve periods a year. A few hundred accounts. Transaction volume is what the business generates; analytical volume is what the prompt needs, and they differ by three or four orders of magnitude. Nearly every question a finance or ops team asks lives on the small side of that gap.
Think about the actual workload. A flux analysis is account balances across periods - hundreds of rows. An accounts receivable aging is open invoices bucketed by days outstanding - hundreds again. A board package is a dozen summarized statements. Even a deep dive like this morning's margin work produced a 16,000-row answer at most, for a company with 16,000 items, not a million-row one. The million lines mattered. Every one of them fed the sums. But they were never something a person, or a model, was going to sit and read.
"It's Just a Summary"
I hear a version of this objection a lot, and I have some sympathy for it. If it's a summary, the thinking goes, then it isn't really analysis.
There's a case where I completely agree, and it's when a static report is handed to you as the final word, with no way to question it. That isn't analysis. It's a conclusion you're being asked to take on faith.
The problem with that type of report isn't that it's summarized. Analysis has never meant reading every row. It means breaking a change down into its causes, testing whether your explanation holds, and drilling in where the numbers argue back. Every one of those steps produces and consumes summaries. This morning's margin bridge was nothing but summaries, compared and reconciled against each other, and it surfaced a root cause I'd never have seen by scrolling transaction lines for an entire afternoon.
Every AI tool out there ends at a summary anyway, regardless of what it did along the way. The end result of an analysis consists of aggregates and variances and a narrative, because nobody reads a million rows. So the real question was never whether a tool summarizes. It's what you can do with the summary once you have it.
With Sonar, a report shows up with the SuiteQL queries that were used to produce it. They're sitting right there in the conversation, ready to be re-run and checked.
And the report is where the work starts, not where it ends. Ask why sales of that backpack family fell off, and the follow-up query runs against the same live lines. Ask which customers are no longer active, or whether an item went out of stock, or which location felt it first, and each answer comes back in seconds, computed fresh from the source.
Let the Database Do Its Thing
There's an assumption being made in a lot of the current AI tool marketing campaigns, that an analysis is only as deep as the number of rows the model can see. It sounds obvious. In practice I've found that it's backwards, and it's the reverse principle that Sonar is built on.
A database is a verifiable calculator. A language model is a reasoning engine. If you ask a model to read a million rows token by token, then you've built the least reliable adding machine ever devised. That's exactly where models drift and skip and hallucinate. Ask a database to sum those same rows and you get a deterministic answer in milliseconds, one that lands identically no matter who runs it. So I gave each engine the job it's suited for. The database does the counting. The model figures out what the count means.
What everyone says they want is full transaction coverage. What they need is verifiable computation, and I think that a lot of teams are being encouraged to treat those as the same thing. But they aren't.
With Sonar, my whole approach comes down to doing the arithmetic next to the data, in a query language the team already reads, and making the results reconcile against the change they claim to explain.
On AI-Generated Queries
There's one issue that I can't and won't dismiss, because I've seen it happen. An AI writes a SuiteQL query that looks right but isn't. If your team can't read and validate the SQL, then everything downstream of it is - or should be - suspect.
But look hard at the usual alternatives. The pre-built extracts, saved searches, and ETL mappings that everyone assumes are safe. Somebody - or something - wrote those, too. Each one bakes in assumptions a person made once, and everyone downstream inherits them, usually without ever reading them. A pre-validated pipeline is still a pile of queries you didn't write. The only difference is that they were written earlier, by someone who isn't in the room when your analysis is being made.
With Sonar, I didn't try to make the queries trustworthy. But I did make them testable, no matter who wrote them. The SQL queries that are generated and used are visible in the chat every single time.
Also, the results have to reconcile. Look at the work I did this morning. Five independently computed components summed to the real margin change, and when a query is wrong that kind of check fails loudly. And that's the whole point, because "silent wrongness" is something that can really burn you.
And finally, the numbers tie back to the books. Because Sonar runs inside NetSuite, it can run the standard Income Statement and its own SQL in the same session, and compare them. If a figure can't survive that comparison, then it has no business being included in a report.
Nobody should have to trust a query. But everybody should be able to test one.
The Danger in Replicating Data
A lot of tools handle large volumes by replicating your NetSuite data into an external store and then analyzing the copy. For cross-system analytics, or for history that's been archived outside of your production account, this warehouse-based approach is sometimes the right call, and I've recommended exactly that in those situations.
But replicating data has costs that never show up in a demo, and if you're weighing that type of solution, here are some things to consider:
- How fresh is the data? A late journal entry, a credit memo, this morning's reclass - did they make the last sync? Inside the source system, that question doesn't exist.
- Who validates the extract itself? Every saved search feeding the pipeline, every field mapping, every sync window is a place the copy can quietly drift from the books. You've added a reconciliation job, not removed one.
- What happened to your permissions? NetSuite enforces roles, subsidiary restrictions, field-level security. A warehouse inherits none of that on its own, and your auditors will eventually ask about it. Better if you ask first.
- When the copy disagrees with the Income Statement your controller signs, which number wins? A copy can only reconcile against itself.
None of this makes the warehouse approach wrong, but it is a trade-off that you should consider. Sonar's approach is to keep the analysis where the books already are, so none of those questions ever have to be answered in the first place.
The Importance of Trust
When you're using AI to do financial analysis, trust doesn't come from how much data you can throw at a model. It comes from whether a human can check the work. And it's that one belief that shaped nearly every decision I made when developing Sonar.
Sonar runs inside NetSuite, under the signed-in user's role, so whatever you can't see, it can't see either. I didn't have to build a governance layer, because the platform already has a good one, and inheriting it is far more trustworthy than reimplementing it and hoping I got the edge cases right. The database does the math - SuiteQL for aggregation, NetSuite's own reports when those are what the team already trusts, server-side scripting when the logic outgrows SQL. The model picks what to compute and interprets what comes back, and that's the boundary I hold to. And nothing gets left behind: no replica, no warehouse, no standing copy of your general ledger sitting in someone else's cloud. When the session ends, the data is right where it started.
An agent like Sonar lives and dies by NetSuite's own query performance and by whatever SuiteQL happens to expose. Truly cross-system work (such as NetSuite plus Salesforce plus a data lake) is a very different problem, and an agent that lives inside one system obviously isn't a good solution in that case. No architecture I could build, Sonar included, removes the need for a person who understands the business to look at the output and ask whether it actually makes sense. That job doesn't go away, and I wouldn't trust a tool that claimed it did.
Wrapping Up
Skepticism about AI in finance is healthy, and I don't want to talk anyone out of it. A summary of a partial export isn't analysis. Unverifiable AI has no place anywhere near a close. On that much, I think everyone building in this space agrees, or at least they should.
Where I push back is on the fix.
The common answer is essentially "more." Bigger context windows, bigger replication, more rows in front of the model.
I believe the fix is architectural. Do the computation next to the data, make the results reconcile, and keep the queries where anyone can rerun them.
Whatever NetSuite AI tool you're looking at, including Sonar, I think the test is the same, and it's easy enough to run in an afternoon. Pick a period. Pick a margin question. Ask to see the query and the reconciliation. Then decide for yourself.