How Many NetSuite AI Units Do You Get, and How Long Do They Last?
One team can use up the AI budget that another team expected to have. That is the operational risk hidden inside NetSuite’s AI Units model: the allowance is shared at the account level, not reserved as a personal quota for each employee or workflow.
The model is convenient for administration. It is also dangerous in production when a popular workflow starts consuming more Units than expected. Oracle provides an allowance, publishes example consumption ranges, and exposes account-level monitoring. It does not provide a native mechanism for assigning each department a hard spending limit before the shared pool runs out.
That is the central fact to understand before enabling NetSuite AI broadly.
Your license creates a prepaid AI Unit pool
Oracle’s AI Units FAQ says that each eligible NetSuite General Access Cloud Service User receives 1,000 AI Units per month of the license term [1].
The allowance is tied to the term, not simply to a calendar month. Oracle provisions the Units upfront into a shared customer pool. The relevant license item is #6023, and the allowance is calculated from the number of eligible users and the length of the contract.
For example, a customer with 10 eligible users on a 36-month term receives:
10 users × 1,000 Units × 36 months = 360,000 AI Units
That is the total pool for the term. It is not 1,000 Units that reset independently for every user at the start of each month. The distinction matters because one department’s activity can consume Units that another department assumed were available.
Oracle also describes separate environment pools:
- A connected sandbox receives a pool equal to the licensed Units in the production account.
- A development environment receives a separate pool of 10,000 AI Units per month of term [1].
Unused Units do not carry over after the NetSuite licensing term ends [1]. That makes the planning problem two-sided. A customer can waste part of the allowance by not using it, or consume it too quickly and need additional capacity before the term is over.
The same question can cost 10 or 200 Units
NetSuite does not expose AI usage as ordinary model tokens. Oracle calculates AI Units according to the amount of AI processing required for a task. The public documentation does not provide a conversion such as “one AI Unit equals X input tokens,” and there is no universal price for one Ask Oracle question.
Oracle’s published examples show why a single average cost would be misleading. Ask Oracle consumption depends on the type and complexity of the request:
- A simple how-to question, such as how to create a vendor credit, may consume about 10 AI Units.
- An analysis question, such as checking the remaining balance of an invoice, may consume 10 to 50 Units.
- A research question, such as finding the top five customers by overdue accounts receivable, may consume 50 to 200 Units [2].
The difference is not cosmetic. A team that mostly asks procedural questions can get substantially more activity from the same pool than a team that uses Ask Oracle to analyze records, compare results, and produce ranked answers.
Oracle gives the following example ranges for other generative AI features:
- Case Summary: 5 to 75 AI Units.
- Narrative Insights: 5 to 200 AI Units.
- Prompt Studio testing: 5 to 10 AI Units.
- SuiteScript 2.1 N/llm requests: 5 to 25 AI Units.
- Text Enhance: 5 to 10 AI Units.
- Transaction Matching Assistant: 5 to 10 AI Units [2].
These are planning ranges, not fixed prices. A longer prompt, a larger record, or a multi-step request can change actual consumption. The only reliable way to understand a customer’s usage profile is to measure the workflows running in that account.
A shared pool is convenient and operationally dangerous
The shared-pool design removes one administrative burden. An administrator does not need to distribute a separate monthly allowance to every individual user. The account can use the Units where they are needed, and a department with low demand does not strand capacity that another department could use.
The trade-off is the lack of isolation. A high-volume workflow can consume the shared pool without respecting the informal expectations of other teams. A newly enabled assistant, an automated SuiteScript integration, or a heavily used reporting workflow can change the account’s burn rate quickly.
This is where the model becomes an operational control problem rather than a simple licensing detail. The administrator needs to know which roles and workflows consume Units, how quickly consumption is changing, and how much of the term remains. A monthly total alone is not enough. By the time the account-level number looks alarming, the organization may have little capacity left to identify the cause.
Oracle says administrators can monitor account-level consumption from Setup > Company > View Billing Information, with usage alerts available as part of the monitoring experience [1]. That is useful visibility, but visibility is not the same as a per-workflow limit. The organization still needs its own policy for rollout, ownership, and escalation.
A practical rollout should define three thresholds before enabling AI for a large user group:
- A review threshold, when a workflow’s consumption is materially higher than expected.
- A reservation threshold, below which new use cases require approval.
- A stop threshold, when the remaining pool is protected for critical workflows only.
Those thresholds may be implemented through internal governance rather than a native NetSuite quota feature. The important point is to set them before the pool is nearly empty.
Additional Units have SKUs, but not a public dollar price
Oracle documents additional pooled packages, including:
- 10,000 Pooled AI Units, item #7127.
- 25,000 Pooled AI Units, item #7143 [1].
The public FAQ identifies the packages and item numbers, but it does not publish a universal dollar price. A buyer cannot calculate the price of an additional 10,000 or 25,000 Units from the public documentation alone. The customer’s quote, order form, or Oracle account team must provide that figure.
When the pool is exhausted, Oracle’s documented options are to purchase more Units or pause further use of AI features. That means the commercial decision arrives after the operational decision has already been made. The organization first enables and consumes AI, then discovers whether its usage pattern requires more capacity and what the additional capacity will cost.
The right procurement questions are therefore specific:
- Which eligible users contribute to the initial pool?
- Is the customer’s allowance provisioned for the full term upfront?
- What price applies to item #7127 and item #7143 on this quote?
- Are additional Units available immediately when the account reaches its limit?
- Which environments receive separate pools?
- What monitoring and alerting is included in the customer’s account?
A definitive public “price per AI Unit” would make budgeting easier. Oracle has not provided one in the cited documentation, so any exact dollar figure should come from the customer’s commercial paperwork rather than a secondary article.
Native NetSuite AI and external connectors use different meters
NetSuite’s AI Units FAQ makes an important architectural distinction: the NetSuite AI Connector, which supports Model Context Protocol integrations with external AI clients, does not consume NetSuite AI Units [1].
That does not make the external route free. The external client, model provider, hosting layer, and security controls can all have their own costs. The difference is that native NetSuite features such as Ask Oracle are measured against the NetSuite AI Unit pool, while an external client connected through the AI Connector follows its own provider and billing model.
For example, a team could use an external NetSuite-aware assistant such as MokuBot for selected reporting or investigation workflows while reserving native AI Units for workflows that need to run inside the NetSuite interface. That is not automatically the better architecture. It does, however, give the team a separate cost boundary and a separate place to measure usage.
The comparison should include more than a token invoice. Evaluate data permissions, auditability, latency, model quality, operational ownership, and how corrections are handled. Two tools may reach the same ERP records while creating very different governance obligations.
Plan from workflow demand, not from the user count alone
The user count determines the initial allowance. It does not determine whether the allowance will last. Duration depends on the mix of requests, the number of records involved, automation frequency, and how many teams adopt the same features.
Before a broad rollout, build a simple usage model for each planned workflow:
- Expected requests per day or week.
- Likely consumption range per request.
- Number of participating users or automated jobs.
- Business owner responsible for the workflow.
- Minimum remaining pool required for critical operations.
Use the high end of Oracle’s published ranges for risk planning, not the midpoint. A workflow that looks inexpensive at 10 Units per request may become material if it runs across hundreds of users or executes automatically. A research-style request at 50 to 200 Units deserves a separate review from a simple how-to question.
The important planning question is not “How many AI Units does my license include?” It is “Which workflows will consume the pool, and what will we do when their demand changes?”