Natural Language Analytics for NetSuite: How NSGPT Answers a Ledger Question

The short version: Natural language analytics lets a finance team ask NetSuite a question in plain English. The English is the easy part. The hard part is everything between the question and an answer you can sign off on: the right SuiteQL against your real schema, the right slice of data, a calculation you can check, and a record of who asked what. This post walks one ledger question through those steps, the way NSGPT answers it.

The data access bottleneck

Every finance leader knows the frustration: the data exists in NetSuite, but getting at it requires either technical expertise or waiting in line for someone who has it. Traditional BI requires analysts to know saved search syntax, understand NetSuite's data model, or write SuiteQL. Even with dashboards in place, answering an ad-hoc question often means submitting a ticket and waiting days for a response.

The result is predictable. CFOs make decisions with incomplete information. Controllers spend weekends compiling reports. FP&A analysts become bottlenecks for their own teams. And questions that could matter go unasked, because the effort to answer them exceeds their perceived value.

Natural language analytics—sometimes called natural language query (NLQ), conversational analytics, or "text-to-SQL"—removes that queue. Instead of building a saved search or writing SuiteQL, you ask: "Which customers make up our AR over 60 days past due?"

Why text-to-SQL alone isn't the answer

Translating a sentence into a query is the part every demo shows. It is also the part that breaks first on a real ERP. Generic text-to-SQL accuracy that looks like 85–90% on a clean demo schema falls off sharply on a production NetSuite account, for reasons that are structural rather than cosmetic:

• Schema complexity: NetSuite's data model spans hundreds of tables with complex relationships, and multi-subsidiary, multi-currency, multi-book configurations multiply it.
• Ambiguous terminology: "Revenue" might mean gross, net, recognized, or billed revenue depending on context. Without domain knowledge, a query engine guesses—and guesses fluently.
• Custom fields: Most NetSuite accounts carry years of custbody_ and custrecord_ fields. A generic engine doesn't know what yours mean.
• Security boundaries: Not everyone should see everything. The query has to respect role-based access while still being useful.

So the useful question isn't "can it write SQL?" It's "what happens around the SQL?" Here is that, one step at a time.

One ledger question, step by step

Take the question above: which customers make up our AR over 60 days past due? It sounds like a one-liner. Answering it properly takes six steps.

1. Ground the question in your account

"AR over 60 days past due" has to become specific records and fields in your NetSuite: open customer invoices, the amount still remaining, the due date as the aging basis, and the subsidiaries and currencies your account actually uses. This is the map a hand-rolled setup lacks—the Claude + MCP walkthrough calls it schema grounding, and it is the difference between a confident answer and a correct one.

2. Query live NetSuite, read-only

The agent writes SuiteQL and runs it directly against your live NetSuite instance. Access is scoped to read-only at the NetSuite API permission level, and there is no NSGPT copy of your ledger—no extract, no warehouse, no nightly sync. The query for this question is short:

SELECT
  BUILTIN.DF(t.entity) AS customer,
  SUM(t.amountremaining) AS amount_over_60,
  COUNT(*) AS invoice_count
FROM
  transaction t
WHERE
  t.type = 'CustInvc'
  AND t.amountremaining > 0
  AND t.duedate < SYSDATE - 60
GROUP BY
  BUILTIN.DF(t.entity)
ORDER BY
  amount_over_60 DESC

3. Aggregate in the query, not in the model

Your general ledger is millions of lines, and no context window should be paged through all of them for one question. The aggregation happens in SuiteQL, so the model reasons over the right few hundred rows—one per customer—rather than every open invoice. Getting that slice right is a retrieval problem, and it is where a naive setup hands the model the wrong data and gets a confident answer to a question nobody asked.

4. Calculate in code, not in prose

Concentration, payment-history comparisons, period-over-period change: those are arithmetic, and arithmetic belongs in code. NSGPT runs Python analysis inside a RestrictedPython sandbox, isolated from the host and network, so the numbers in the answer come from a calculation you can inspect—not from a model estimating them in a sentence.

5. Answer with the work shown

The answer comes back with the query that produced it, the chart, and the method in plain English. A finance lead won't sign off on a number they can't trace, so the method has to be readable alongside the code that computes it. Follow-up questions keep their context—"now show me the same customers' average days late over the last 12 months"—rather than starting over.

6. Log it

Every query, agent action, and data access is logged with timestamp, user, and context, and role-based permissions map to your organization and project hierarchy. When an auditor asks who ran what against the ledger last quarter, there is an answer.

When the question keeps coming back

Some questions are one-offs. Others come back every week—and a question asked weekly should stop being a question. That's where the answer graduates into an interactive workbook (markdown, Python, SuiteQL, and chart cells together) or a dashboard that refreshes on live data; see Analytics & Intelligence for both. And if the question is a deterministic pull—"every open invoice over $50,000 past due"—a saved search was already the right tool; when a saved search beats an agent draws that line.

NetSuite's SuiteAnalytics Assistant

Oracle has recognized the shift. NetSuite's SuiteAnalytics Assistant brings natural language query to the platform: users ask questions such as "Show me an accounts payable aging report" and receive visualized answers drawn from their SuiteAnalytics Workbooks. For teams already invested in the ecosystem, it's a meaningful step and a good baseline to test against.

Its limits are the same three to test any tool against:

• Scope: It works within the boundaries of existing Workbooks. Questions that span data domains or need complex joins may not be supported.
• Context: A generic engine doesn't know your chart of accounts structure, subsidiary relationships, or industry-specific metrics.
• Depth: Finance work usually needs multi-step analysis, follow-ups, and drill-down—more than single-query Q&A.

Evaluate with production data. Don't judge any NLQ tool on simple queries against clean demo data. Test it on your actual NetSuite instance, your customizations, and your edge cases. If your most common ad-hoc questions are answered reliably, you may have enough coverage. If they involve cross-functional analysis, custom calculations, or multi-subsidiary complexity, you need something built for financial analytics.

Getting it right in your team

1. Establish data governance first. Self-service analytics only works when the definitions underneath it are solid—otherwise you're democratizing chaos. Agree what "revenue," "AR," and "margin" mean before anyone asks.
2. Start with high-value, low-complexity questions. Frequent questions with clear answers: standard reports, period comparisons, simple filtering and aggregation.
3. Teach effective questions. Results improve when people use specific terminology, state the time period explicitly, and ask one question at a time on complex topics.
4. Keep human review where it counts. Board communications, regulatory filings, and audit support still get a person's sign-off. The point is to remove the drudgery of data access, not the judgment.

The bottom line

Natural language is becoming the default way finance teams ask questions of their data. The teams that get value from it are the ones that treat the sentence as the start of the job, not the whole of it: grounded in the real schema, read-only against live data, calculated in code, shown with its working, and logged.

If you want to see that on your own NetSuite data—ask the question your team keeps filing tickets for—request a walkthrough. Data access is read-only, and nothing leaves your NetSuite instance; Security has the detail.