In thinking through our NetSuite AI Units explainer, a question comes to mind that every CFO is probably already asking: now that AI usage in NetSuite is metered, what does an AI automation actually cost?
Nobody has published that math. So let’s do it, with a real example.
Where the meter is, and where it isn’t
Three facts from the public documentation set up everything that follows.
Embedded AI is metered. Generative AI features inside NetSuite consume AI Units, and Oracle publishes per-feature estimates. The one that matters for automation is the SuiteScript N/llm module, the tool developers use to build AI into scripts and workflows: 5 to 25 units per prompt.
External AI is not. AI running through the NetSuite AI Connector Service, like Claude, consumes zero units. Those requests execute on the LLM provider’s side, so that bill lives with your AI provider.
Plain scripting was never metered at all. Ordinary SuiteScript, including the record transformation that turns a sales order into an invoice, costs zero AI Units. The meter is on AI inference inside the platform. It is not on code, and it is not on external AI.
Hold onto that third one. It is the key to the whole analysis.
The example: a billing agent
Say your sales operations team bills 250 orders a day. At 21.7 working days a month, that is 5,425 orders.
You want an AI agent that works like a member of the team: it reviews every transaction, bills the 80% that are clean without touching a human, and surfaces the 20% that need judgment, with its reasoning attached.
Every full NetSuite user license includes 1,000 AI Units a month, pooled at the account level. So the useful way to measure an automation’s appetite is in user-equivalents: how many users’ worth of included allocation does it eat?
There are three ways to build this agent. The architecture decision, not the AI, is what sets the bill.
Architecture A: one AI call per order
The straightforward version. Every order gets a single N/llm prompt: here is the order, the customer, the terms. Bill it or flag it.
5,425 orders x 1 prompt x 5 to 25 units = 27,000 to 136,000 units a month.
A billing decision with real context is not a 5-unit request, so plan toward the middle: call it 80,000 units a month. That is the included allocation of an 80-user account, consumed by one automation.
Architecture B: a full agentic loop on everything
The version that matches the demo-day vision. For every order, the agent gathers context, evaluates, decides, and writes up its reasoning. That is 3 to 5 chained prompts per order.
5,425 orders x 3 to 5 prompts x 5 to 25 units = 81,000 to 678,000 units a month.
The realistic middle is around 325,000 units a month, the included allocation of a 325-user account. For most mid-market companies, that is not “watch the meter” territory. That is buying add-on unit packs every month, forever, for one process.
Architecture C: rules first, AI for exceptions
Here is the version that takes more thought up front. Your 80% clean orders mostly do not need AI at all. Complete data, credit clear, no holds, terms match: that is deterministic SuiteScript. Zero units, and it bills the same order the same way every single time.
The AI works the 20% that is actually ambiguous: 1,085 orders a month, each getting a real multi-prompt interrogation.
1,085 orders x 3 to 5 prompts x 5 to 25 units = 16,000 to 136,000 units a month. Realistic middle: about 65,000 units.
Same business outcome as Architecture B. Eighty percent untouched, twenty percent surfaced with reasoning. At roughly a fifth of the burn.
Why the cheap architecture is also the right one
Here is the part worth pushing on, because it is the opposite of what most AI marketing implies: Architecture C is not the budget compromise. It would be the right design at zero cost.
Ask what an AI model contributes on a clean order. Credit clear, terms match, data complete. The best possible outcome of that “interrogation” is agreement with a rule you could have written. You paid for reasoning and received confirmation. Worse, you added variance to a financial control. A rule is deterministic and your auditor can read it. A model can drift, and in billing that is not a quirk. It is a SOX finding waiting to happen.
Now ask what the model contributes on the ambiguous 20%. Everything. The mismatched PO, the partial shipment nobody anticipated, the customer email that changed the terms. That is judgment, and judgment is the thing you could never afford to staff at this scale. Putting real analytical attention on every exception is the actual revolution. Re-deriving arithmetic on clean orders is not.
Notice that Architecture C is also how your best sales ops person already works. They do not deeply interrogate clean orders. They pattern-match those in seconds and spend their attention on the weird ones. Architecture B is not an AI teammate. It is paying senior-analyst attention to every trivial order, which no team you would ever hire does.
Two additions complete the design. First, a thin anomaly screen across the whole population, because pure rules cannot notice that a technically clean order is strange in a way no rule anticipated. That is a cheap scoring pass, not a full agentic loop. Second, a graduation loop: when the AI resolves an exception and the resolution turns out to be a repeatable pattern, that pattern becomes a new rule. The mature system continuously converts judgment into determinism, and the AI keeps working the frontier the rules cannot reach yet.
The external option, and how it executes without the meter
There is a fourth architecture: run the judgment outside NetSuite entirely.
The mechanics matter here, because the common objection is “but how does external AI actually bill anything?” The answer: the same way everything else does. Through code. An external agent connected via the AI Connector does its thinking on the provider’s side, then calls a tool, and a tool is plain deterministic SuiteScript running inside NetSuite under the connected user’s permissions. The transform from order to invoice is the identical code you would write in a scheduled script today. Zero units for the thinking, because it happened outside. Zero units for the execution, because scripting was never metered.
What does the thinking cost instead? Public API pricing makes this concrete. At current Claude rates, a multi-step exception review runs somewhere between 3 and 10 cents per order depending on the model and how much context you feed it. For our 1,085 monthly exceptions, that is roughly $35 to $100 a month on the provider’s meter, against 65,000 units a month on NetSuite’s.
Before anyone declares a winner, three honest caveats. Your included AI Units are use-them-or-lose-them, so until the pool runs dry the in-platform path is effectively free at the margin. The external path works on schedules and batches, not as a script firing on the transaction in real time, though for billing runs, batch is usually fine. And routing ERP data through an external model is a governance conversation your auditor gets a vote in. That conversation is exactly what the AI Connector was designed to pass, but it still has to happen.
One more practical note: depending on what NetSuite’s standard connector tools support, the billing action may require building a custom tool. That is documented, supported, and not a big lift, but it is the difference between working day one and a couple of weeks of development. Confirm before you promise it to your CFO.
Stop estimating. Measure.
Everything above is planning math built on Oracle’s published estimates, and Oracle is explicit that actual consumption varies with request complexity. The good news is you do not have to trust anyone’s spreadsheet, including this one.
Sandbox accounts get their own dedicated AI Unit pool, sized to match production, at no additional cost. So the real answer costs about a week: build the exception handler in sandbox, run 100 orders through it, and read the actual burn at Setup > Company > View Billing Information. Run the same 100 orders through the external path and watch the token count. Now you have measured dollars per decision on both meters, for your orders, your data, your complexity.
That number, not a vendor projection and not a blog post, is what belongs in the budget conversation.
The bottom line
The meter does not punish AI adoption. It punishes lazy architecture. The design that burns 325,000 units a month and the design that burns 65,000 produce the same business outcome. The difference is whether someone decided, deliberately, what belongs to rules and what belongs to judgment.
That decision is the actual work. It is also the same design discipline that made automation succeed long before anyone metered it.
If you are thinking through where AI fits in your NetSuite instance, and what it should cost, our strategy calls are free and unbiased. Bring your ugliest process. That is where the interesting math lives.