A measured approach to tracking AI Assistant consumption, forecasting demand, and planning ahead of the monthly allocation.
November 5, 2026
Acumatica AI Units are a monthly consumption measure for AI Assistant, and teams can monitor usage in the AI Unit Consumption screen and the License Monitoring Console. A reliable budget starts with the allocation shown for the customer’s own environment, a short pilot that measures real usage, and a forecast based on the workflows the business plans to run. It should also define who checks the meter, what internal review points prompt action, and what people will do if the allocation is close to being exhausted.
The key planning rule is simple: use measured consumption to estimate demand, but do not convert an AI Unit balance into a dollar forecast unless the customer’s current order terms provide that conversion. Acumatica’s AI Assistant FAQ describes AI Units as reflecting a blend of model input, output, and cache tokens; the public documentation reviewed here does not provide a universal per-prompt rate or a single public price per unit. Review the current entitlement and any additional-unit terms with the Acumatica partner or customer success contact before committing to a budget.
This guide focuses on that operating model: how to establish a baseline, build a workload forecast, review the monthly trend, and respond before a service interruption. It complements Biz-Tech’s broader Acumatica AI Assistant governance guide, which covers inquiry design, security, roles, and human review.
The short answer: budget from observed use, not a guessed price
What Acumatica AI Units measure—and what they do not tell you
Where to monitor usage in a 2026 R2 environment
Understand the built-in threshold warning
Separate the consumption plan from the financial budget
Confirm entitlement, environment, and ownership before measuring
Inventory the workflows that will draw on the pilot
Establish a baseline with a controlled pilot
Forecast the month using measured demand
Worked example: distinguish a training spike from normal demand
Set internal review points before the product warning
Run a review cadence that matches the pace of adoption
Reduce avoidable demand without reducing useful access
Keep AI Assistant usage distinct from other AI and integration costs
What to do when the forecast approaches the allocation
A 30-day rollout for a measured AI Units budget
Copy-and-use AI Units planning worksheet
Common budgeting mistakes to avoid
Conclusion: make the allocation visible and the response predictable
The short answer: budget from observed use, not a guessed price
A workable AI Units plan has four pieces. First, identify the monthly allocation and the environment to which it applies. Second, run a limited pilot with a few named business questions and a defined group of users. Third, compare the reported consumption before and after that pilot and maintain a simple use-case log. Fourth, forecast planned use for the rest of the month and check the meter on a regular schedule.
The allocation is the operating limit. The forecast is a management estimate. The commercial budget is a separate calculation that depends on the customer’s agreement. Keeping these three ideas separate avoids two common errors: treating a dashboard percentage as a price, and assuming that every natural-language question consumes the same amount.
As of the Acumatica 2026 R2 documentation reviewed for this article, administrators can review usage on AI Unit Consumption (ML900000) and in the License Monitoring Console (SM604000). The Console’s Constraint History includes “AI Units by Month (% of Limit),” and Acumatica documents a warning in AI Assistant when consumption passes the site threshold specified in the license. The documented default threshold is 90 percent. A threshold warning is a signal to review the trend; it is not a forecast, a purchase order, or a substitute for an owner who checks usage.
The practical sequence is therefore: verify the entitlement, baseline a bounded workflow, forecast with actual data, set earlier internal review points, and agree on a response path with the partner. Teams that are still deciding which inquiries and users should be in scope should first review their access and governance design. Once the scope is clear, this article helps them manage consumption without relying on an invented “units per question” assumption.
What Acumatica AI Units measure—and what they do not tell you
Acumatica describes AI Units as its measure of AI Assistant consumption. The company’s AI Assistant FAQ says the measurement reflects a blend of input, output, and cache tokens across models. That description is useful for planning because it explains why a simple count of chat turns may not predict usage precisely: a short question can lead to a different interaction from a longer request with a detailed result, and the measurement is not presented as a fixed one-unit-per-question counter.
The public materials reviewed for this article do not specify a single fixed conversion from words, tokens, questions, or user sessions to AI Units. They also do not publish one universal price for a unit. Administrators should therefore avoid copying a rate from another organization, building a financial forecast from a hypothetical average, or promising that a given number of users will fit within an allocation. Another tenant’s experience can be a starting question for a pilot, not evidence of this customer’s consumption.
The monthly limit is a planning boundary, not a service-level guarantee. Acumatica’s FAQ says that if the monthly AI Unit allocation is exhausted, AI Assistant will no longer be available until the allocation resets at the start of the next month; it also says additional AI Units can be purchased. The availability, activation steps, timing, and commercial terms for any additional units should be checked with the customer’s Acumatica VAR or customer success manager. Do that before a pilot approaches its allocation, not after users encounter an interruption.
The documented meter is specifically tied to AI Assistant consumption. Acumatica’s product portfolio also includes other AI-related capabilities, and some organizations use external models, integrations, or separately licensed tools. Do not assume every AI-related feature shares the same meter or that every external model call appears in AI Unit Consumption. Confirm the relevant licensing and telemetry separately for each capability.
A final distinction matters: AI Unit usage is not a quality score. A low meter does not prove that responses are correct, appropriately scoped, or useful. A high meter does not prove that a pilot is valuable or wasteful. Consumption should be read alongside approved use cases, user feedback, source reconciliation, and the business outcome the team expects. Acumatica’s AI Terms also place responsibility on customers to review and validate AI outputs before relying on them for production or business-critical work.
Where to monitor usage in a 2026 R2 environment
Acumatica identifies two places to review AI Unit consumption. The AI Unit Consumption screen is ML900000. The License Monitoring Console is SM604000; its Constraint History tab includes a column for AI Units by Month as both a total and a percentage of the monthly limit. The Acumatica FAQ names both screens, and the 2026 R2 Console form reference defines the displayed monthly measure. Exact access and visible values can depend on the installed version, role, license, and tenant configuration, so confirm the screen in the environment being managed.
Use one screen as the team’s normal check-in point and document the other as the cross-check. When a monthly review is due, record the current period, displayed limit, consumed amount, percentage of limit, capture date and time, and the person who reviewed it. If the two views appear inconsistent, refresh or re-open them as appropriate, capture the discrepancy, and ask the partner or support team how the values are calculated for the installed build. Do not silently average two different readings.
The License Monitoring Console is also useful because its broader purpose is to show license constraints and resource statistics. Keep the AI Unit measure distinct from nearby system metrics such as transaction limits or resource consumption. A rise in API traffic, CPU use, commercial transactions, or storage is not itself proof that AI Unit use has risen. Use each metric for the question it actually answers.
The references cited here document aggregate monthly consumption and the percentage of the limit, but do not describe a standard report that allocates every AI Unit to an individual user, prompt, or business process. Treat per-workflow allocation as something to establish with a controlled pilot and a local operating log, not as a guaranteed field in the product screen. Avoid recording chat contents in a budget spreadsheet unless there is a separate, approved reason and data-handling process. A use-case label, date, aggregate before-and-after reading, and event count may be enough to estimate a workflow.
Keep a screenshot or export only if your internal recordkeeping policy allows it. If the meter is accessible only through the application, a dated manual log may be simpler and clearer than creating a new integration just to copy a monthly number. The goal is a trustworthy decision record, not more telemetry for its own sake.
Understand the built-in threshold warning
Acumatica’s 2026 R2 help says AI Assistant displays a warning when AI Unit consumption exceeds a site threshold specified in the license. The documented default threshold is 90 percent. The warning appears in the AI Assistant window, outside the chat conversation, and is displayed once per user when that user opens AI Assistant and connects to the cloud service. If a chat is already open, the warning can appear under the most recent answer.
That timing makes the warning useful but insufficient as a budget control. A user who does not open the assistant may not see it at the same time as an administrator checking the month’s usage. One person seeing it does not automatically mean every user has seen it. It is therefore good practice to check the consumption screen or Console directly on a calendar, assign an owner, and tell the pilot group how to report the warning.
The documented 90 percent default is not a recommendation to let usage reach 90 percent before acting. A company can define earlier internal review points, such as a weekly review once use passes a chosen percentage or a same-day escalation when the forecast exceeds the planned allocation. Those are internal operating decisions. Do not represent them as configurable Acumatica product alerts unless the installed version and license confirm that control.
Before launch, ask the partner to confirm the threshold applicable to the customer’s license and whether it differs from the documented default. Record the answer and the date. If the organization sees a warning earlier or later than expected, capture the displayed message and current usage, then confirm whether the tenant’s threshold, license, or version explains the difference. Avoid building a notification process around behavior you have not tested.
A warning should lead to a short review: validate the current reading, compare it with the planned curve, identify any scheduled activity that explains the increase, and choose a response owner. A warning without an action path creates anxiety. An action path without a clear reading risks unnecessary restrictions. Together, the meter, the trend, and a named owner make the warning actionable.
Separate the consumption plan from the financial budget
A percentage of monthly AI Units is not a dollar amount. The meter tells administrators how much of an allocation has been used, but the public documentation cited in this guide does not establish a universal price per AI Unit. Commercial terms may depend on a customer’s order, package, renewal, region, or other agreed terms. Ask the Acumatica partner or customer success contact to confirm the actual entitlement and price for the customer before building a financial plan.
Build the operating plan and the cost plan as related but separate records. The operating plan contains the monthly unit allocation, measured usage, expected workflow volume, internal review points, and continuity actions. The financial plan contains only the applicable contractual price, committed amount, billing period, purchase terms, and the person authorized to approve additional units. This separation makes it clear which values come from the meter and which values come from a commercial document.
When no unit price is confirmed, write “commercial rate pending confirmation” rather than inserting a placeholder dollar amount that could be mistaken for a quote. If the finance team needs a planning range, request one from the authorized commercial contact and record the assumptions and validity date. Do not infer that unused units roll over, that purchasing more units changes the monthly reset, or that one payment method applies to all accounts unless the current terms say so.
The same caution applies to return-on-investment calculations. A pilot can measure time saved, report requests avoided, or the time required to identify an exception. Those operating measures can help the business assess value. They do not, by themselves, determine the cost per AI Unit. Keep the benefit estimate, usage forecast, and contract quote visible as separate inputs so a decision-maker can examine each one.
A simple decision note should show: current allowance; month-to-date consumption; expected month-end consumption; the assumptions behind the forecast; current commercial terms; remaining uncertainty; and the person who approves a change. This is enough for a useful discussion without inventing a price formula.
Confirm entitlement, environment, and ownership before measuring
Before a pilot, verify that AI Assistant is available in the version and subscription the organization actually uses. Acumatica’s FAQ says AI Assistant requires 2026 R1 or later and directs customers to their VAR or CSM to discuss adding it to the subscription. It also notes the 2026 R2 transition to general availability for customers on 2026 R1 and later. Treat that as product availability guidance; the customer’s own order and tenant configuration still need confirmation.
Write down the environment being measured: production, test, or another instance; the tenant or company context; the release version; the monthly allocation shown in the license; and the date the values were reviewed. If the organization has more than one environment or agreement, do not combine readings until the partner confirms how those allocations relate. A number without its environment and period is difficult to interpret a month later.
Name three practical owners. The consumption owner checks the meter and maintains the forecast. The business owner validates that the planned questions are useful and that a non-AI alternative exists for essential work. The commercial owner checks entitlement and additional-unit terms with the authorized partner contact. In a small company, one person may hold more than one role, but write down who is responsible for each decision.
Also identify the operational contact for a service issue. If AI Assistant becomes unavailable, users should know where to find the approved report, dashboard, or existing workflow that covers the most important question. The fallback does not need to reproduce every conversational feature. It should protect the specific business process the pilot supports.
These checks keep usage data attached to the right account and decision. They also prevent a common budgeting trap: treating a screenshot from a sandbox, a previous month, or another customer’s tenant as if it were the production allocation currently available to the business.
Inventory the workflows that will draw on the pilot
A useful forecast begins with business work, not a desired monthly number. List each proposed AI Assistant workflow in plain language. Examples could include checking open receivables by aging band, reviewing exceptions in a defined purchasing queue, or summarizing a project-cost question that can be reconciled to an existing report. Each entry should have one business owner, an intended user group, a reference inquiry or report, an expected cadence, and a clear validation step.
Separate routine questions from exploration and training. A recurring weekly question is easier to model after it has been measured several times. Open-ended exploration is more variable. Training and onboarding can produce temporary usage that will not match normal operations. Month-end or quarter-end periods may also differ from an ordinary week. Recording these categories prevents a workshop spike from being treated as the future run rate for every month.
For each workflow, estimate volume in business terms: number of eligible users, expected sessions per week, operating weeks per month, and any scheduled peak. Use ranges when adoption is uncertain. A pilot with eight users who each ask one prepared question twice a week is a different scenario from an entire department experimenting freely. These counts are assumptions for planning and should be labeled as such until measured.
Add a priority and a fallback. Priority answers what the business would protect if the forecast tightens. The fallback identifies a saved inquiry, dashboard, report, or manual process that can cover the essential need temporarily. A lower-priority exploratory scenario can be delayed without affecting a close or customer commitment; a recurring operational question may deserve closer attention.
Finally, document what is outside the pilot. Examples might include unsupervised use by all departments, new inquiries that have not been reviewed, or unrelated automation features. An explicit boundary helps interpret the trend. If consumption rises while the scope is unchanged, investigate the known workflows first; if the scope changed, update the forecast before concluding that behavior has become less efficient.
Establish a baseline with a controlled pilot
Record a starting meter reading immediately before the pilot begins. Capture the date, time, displayed period, limit, consumed amount, percentage, environment, and any scheduled AI Assistant activity already in progress. If several groups are already using AI Assistant, note that the starting figure reflects their activity too. A clean before-and-after comparison is only possible when other consumption is stable or separately accounted for.
Run the pilot in a defined window. For a first measurement, use a small group, a few representative questions, and a short schedule. Ask users to record the workflow label, date, whether the question was part of normal work or training, and whether they needed a retry or follow-up. Avoid logging customer records, personal data, or full prompts in a general-purpose budget sheet. If prompt records are needed for quality analysis, store them under the organization’s normal access, retention, and review controls.
At the end of the window, capture the same meter fields. Calculate the difference between the ending and starting readings. Divide that difference by the number of observed sessions only when the window was controlled enough to attribute the usage reasonably. If other teams were using the assistant at the same time, describe the result as an aggregate trend rather than a per-session rate.
Repeat the measurement across more than one pattern: a straightforward recurring question, a follow-up exchange, and a more exploratory task. Do not intentionally provoke unnecessary consumption. The purpose is to understand the range of ordinary work the business intends to support, not to benchmark arbitrary prompts. Use real business questions that have an approved data scope and an existing way to validate the answer.
A baseline is not a guarantee. It is a starting estimate with a confidence level. Label each rate as high, medium, or low confidence based on the number of observations, whether other users were active, whether the workflow was representative, and whether training distorted usage. Update the estimate when the use case, inquiry, user group, product version, or model behavior changes.
Forecast the month using measured demand
A simple forecast can be built in a spreadsheet or a small operating log. It does not need a complicated statistical model. For each planned workflow, multiply the number of expected events in the month by the observed average consumption per event, then add one-time or seasonal activity separately. Sum the results and compare them with the monthly allocation displayed for the applicable environment.
A basic formula is:
Forecasted month-end units = actual month-to-date units + expected units for the remaining recurring activity + planned one-time activity + an uncertainty reserve.
The reserve is an internal planning choice, not an Acumatica setting. A team may select a fixed buffer, a percentage of forecast demand, or a range based on pilot uncertainty. If usage is highly variable, a scenario range is more honest than a single precise number. Document why the reserve was chosen and revisit it after several months of actual data.
Use the expected calendar, not only a straight-line projection. If a month contains an implementation workshop, training week, quarter-end close, or planned expansion, add that activity in the period when it will occur. Conversely, if the initial days were unusually heavy because of training, do not multiply those days across the entire month without examining the mix. The formula is a structure for reasoning; it does not make a poor assumption reliable.
The monthly usage percentage can be calculated as:
Usage percentage = displayed units consumed ÷ displayed monthly limit × 100.
That is a simple relationship between the values shown in the meter. For planning, compare the expected month-end units with the limit, then show a low, expected, and high scenario. For example, the low case might assume only approved recurring workflows; the expected case adds scheduled training; and the high case includes planned expansion plus the chosen uncertainty reserve.
As a check, compare the forecast with actual usage on a repeated cadence. If the forecast changes sharply, keep the previous forecast and record what changed: more active users, a new workflow, retries, training, a billing-period boundary, or a changed scope. The reason for a forecast revision is often more useful than the difference between two numbers.
Worked example: distinguish a training spike from normal demand
The following numbers are fictional and are included only to demonstrate the method. Assume an organization sees a monthly allocation of 100,000 AI Units. After the first ten calendar days, the meter shows 36,000 units consumed. A straight-line calculation would project 108,000 units for a 30-day month: 36,000 divided by 10, multiplied by 30. That indicates that the team should investigate, but it does not tell the whole story.
The use log shows that 16,000 units occurred during a one-time, two-day training workshop and that ordinary approved workflows accounted for about 20,000 units during the remaining eight observed days. If the normal pattern is expected to continue for 20 more days at the observed pace, that part of the forecast is 50,000 additional units: 20,000 divided by eight days, multiplied by 20. The team then adds the recurring use expected during the rest of the month, such as a planned weekly session or month-end activity, and labels each assumption.
Suppose the approved schedule adds 25,000 units after the current reading, including 18,000 for normal recurring work and 7,000 for a planned training session. The forecast becomes 61,000 units: 36,000 already used plus 25,000 planned. If the team also applies a 10,000-unit uncertainty reserve, its expected planning figure is 71,000. The reserve is a fictional internal choice, not a recommended Acumatica setting. The point is to show the calculation transparently.
The review should now ask whether the training activity was planned, whether any other teams were active during the baseline, and whether the recurring sample covers a complete business cycle. If the remaining month includes quarter-end or a larger rollout, include that separately. If it does not, avoid assuming that the training spike will repeat every month.
This example also shows why a percentage alone can mislead. Thirty-six percent of the allocation used by day ten may look like a 108 percent projected finish under a simple linear model. Once the event mix is understood, a measured operating forecast can be materially different. The team should not dismiss a spike automatically, but it should classify the spike before imposing a restriction or requesting additional units.
If the forecast exceeds the allocation, prepare a decision rather than a false assurance. Options could include postponing a nonessential expansion, using an existing dashboard for a routine recurring check, reducing the pilot group temporarily, or asking the partner about additional units and the terms. Record the chosen option, approval, expected effect, and the next review date.
Set internal review points before the product warning
The built-in warning is documented at a default of 90 percent, but a budget owner should usually review the trend earlier. The internal review points depend on the organization’s usage variability, business calendar, ability to buy additional units, and tolerance for interruption. A company with a close-critical use case and slow procurement may need earlier escalation than a small optional pilot with a reliable manual fallback.
One practical policy is to set three internal bands. The first band is a routine checkpoint: verify that actual use is reasonably close to the plan. The second band is a forecast review: if actuals plus scheduled demand may consume the remaining allocation, ask the business owner to confirm priorities and ask the commercial owner to confirm the available options. The third band is a continuity escalation: if there is a credible risk of reaching the allocation before reset, inform users of the fallback and obtain a decision from the authorized approver.
The exact percentages are company choices. For illustration, an organization might review at 50 percent of allocation, escalate a forecast at 75 percent, and activate a continuity plan if expected month-end use reaches 90 percent. Another organization may select different values. These examples are not vendor defaults and do not change Acumatica’s threshold behavior. Write the actual internal values in the operating policy and mark them as internal.
Pair percentage triggers with calendar checks. A trigger without a scheduled check depends on someone noticing the meter. A scheduled check without a trigger can result in repeated readings but no action. For instance, an owner may review weekly, then move to daily when the forecast shows less than the internal reserve remaining. The cadence and threshold should reflect the expected rate of change.
Every trigger should map to one action and one person. “Usage is high” is not an action. “The consumption owner captures the reading, the business owner identifies any activity that can pause, and the commercial owner contacts the VAR if the forecast reaches the approved escalation band” is actionable. Share the path with the pilot team so a warning does not become a surprise or a rumor.
Run a review cadence that matches the pace of adoption
During a small pilot, a weekly check is often easier to operate than a complex daily dashboard. Review the meter at the same point each week and record the date, period, limit, units consumed, percentage, forecast, and notable events. If the team is expanding rapidly, approaching an internal trigger, or supporting a time-critical process, increase the cadence based on the observed rate of change.
At each check-in, ask four questions. Is the meter reading current and tied to the correct environment? Is actual use within the forecast range? What event or workflow explains the largest change since the last review? Does the expected demand for the rest of the period still match the business calendar? A short meeting that answers these questions is more useful than a spreadsheet full of unexplained percentages.
The consumption owner maintains the record. The business owner confirms whether the workflow remains valuable and whether the planned user group has changed. The administrator confirms that the intended users and inquiries remain appropriate. The commercial owner checks any licensing, purchasing, or renewal decision. One person can coordinate the meeting, but the decisions should not be left to a usage chart alone.
At month-end, save the final reading and compare it with the forecast made at the beginning and midpoint of the month. Record the forecast error and its cause. Did a pilot expand? Was training heavier than expected? Did a use case move to a saved dashboard? Did the meter behave differently after a release or configuration change? Use these observations to improve the next month’s forecast rather than treating the first month as a failure.
After several periods, the team can move from a cautious pilot forecast to a more stable operating plan. Keep the original assumptions and revisions so decision-makers can see whether the forecast is improving. Do not overfit to a few unusual days or claim precision unsupported by the meter’s reporting granularity.
Reduce avoidable demand without reducing useful access
Consumption management should focus on business fit, not on making users afraid to ask questions. If users need a brief answer to a repeatable question, a published report, dashboard, or saved inquiry may be the better routine tool. AI Assistant can remain useful for follow-up analysis or questions that benefit from natural-language exploration. Choosing a fit-for-purpose path can improve usability even when the monthly allocation is not under pressure.
Train users to ask a clear business question and include the relevant period or scope when that matters. This is good practice for answer quality; do not promise that shorter wording always reduces AI Unit use by a known amount. The measurement blends multiple token categories across models, and the public documents cited here do not provide a deterministic formula for predicting consumption from prompt length. Measure the organization’s own patterns before claiming that a particular phrasing saves units.
If users repeat questions because answers are confusing, investigate the underlying inquiry, terminology, and training. Avoid framing every follow-up as waste. A follow-up can be exactly how a finance analyst reaches a valid result. The more useful question is whether the workflow is producing an answer that the user can reconcile and act on, and whether the use pattern is within the agreed forecast.
Review the approved inquiry set and the user group as a governance process. Changes to inquiries, user access, or the business question can change both the operating profile and the controls the organization relies on. A usage review should therefore link back to the change record, not just the consumption number. Biz-Tech’s AI Assistant governance guide covers exposed inquiries, access, and human review in more depth.
Acumatica’s 2026 R2 AI Assistant help notes that Help-related questions do not consume AI Units. If users are using the Help Agent for product navigation or version-specific how-to questions, do not classify that as AI Assistant data-analysis consumption without checking the current documentation and tenant behavior. Keep the distinction visible in training materials so managers do not misinterpret a help-seeking habit as an unexpected data-query workload.
Keep AI Assistant usage distinct from other AI and integration costs
An ERP program can involve more than one AI or automation path: conversational AI Assistant use, AI automation, external AI tools, MCP clients, integrations, and third-party marketplace products. The current Acumatica documentation cited in this guide describes the AI Unit measure as AI Assistant consumption. Do not assume that the same monthly counter includes every related capability, and do not assume that a capability consumes no units simply because a different meter is not visible.
Make a small inventory of capabilities that can incur a commercial or operational cost. For each, record the product or service name, provider, environment, owner, licensing source, usage signal, billing period, and the contact who can verify terms. If an external AI client or integration has its own subscription, track that separately from the Acumatica meter. If product behavior is unclear, ask the provider before including it in a forecast.
This is also why “AI Units” should not be used as a generic label for all AI spend in a management report. Use a distinct line for Acumatica AI Assistant monthly allocation, another for third-party services where applicable, and separate entries for project or implementation cost. That makes a business review auditable and avoids double-counting.
The Acumatica AI overview and 2026 R2 release news describe the range of AI-related capabilities in 2026 R2. Their breadth is a reason to confirm scope, not a reason to merge all usage measures. As the organization adds a workflow, update the inventory and ask whether the new feature shares the existing meter, uses a separate allocation, or has its own commercial agreement.
What to do when the forecast approaches the allocation
When the forecast approaches the monthly allocation, verify the current reading first. Capture the environment, period, displayed limit, units consumed, and the date and time. Check whether the forecast includes scheduled training, a one-time rollout, close-period activity, or a recent expansion. Correct obvious omissions before making a purchasing decision, but do not delay escalation while waiting for perfect attribution.
Next, classify planned activity into three groups: essential for a defined business process, valuable but deferrable, and exploratory. The business owner should confirm the priority. Where a routine question can be answered through an existing report or dashboard, use the fallback the business already understands. Do not replace a necessary control or reconciliation with an unvalidated report simply to conserve usage.
Contact the authorized Acumatica commercial contact early enough to understand options, price, timing, and any approval steps. The public FAQ says additional AI Units can be purchased, but the customer should confirm how that applies to its agreement and environment. Record the response with the date and any limitations. Do not promise that a purchase can be completed instantly or that it will be effective for a particular tenant until the partner confirms it.
If the allocation is exhausted, Acumatica’s FAQ says AI Assistant is unavailable until the allocation resets at the beginning of the next month, and additional AI Units may be purchased. Communicate the fallback clearly: which approved report or dashboard to use, where to raise a support request, and when the next status update will occur. If the AI Assistant is optional for a pilot, users should already know this fallback from the pilot kickoff.
After the period resets or the commercial change takes effect, verify availability and the displayed meter before reopening the workflow. Reconcile the actual outcome against the forecast and update the next month’s plan. A near-limit event is an opportunity to improve scope, forecasting, or communication—not a reason to increase the allocation automatically without understanding demand.
A 30-day rollout for a measured AI Units budget
Days 1–3: confirm the commercial and technical boundary. Verify the release, entitlement, environment, monthly limit, threshold behavior, and authorized commercial contact. Name the consumption owner, business owner, administrator, and escalation approver. Write down what AI Assistant workflows are in scope and which related AI or external tools are tracked elsewhere.
Days 4–7: select the first workflows. Choose a small number of recurring business questions that have an owner, an existing inquiry or source, a validation method, and a reason to use natural-language analysis. Estimate activity in business terms and separate routine use, training, exploration, and peak-period events. Identify a report or dashboard fallback for the most important process.
Days 8–14: collect a baseline. Record the starting meter reading, run the limited pilot, and capture the ending reading. If the measurement window includes activity from other teams, mark it as aggregate. Log event counts and categories without collecting more sensitive prompt content than necessary. Assign confidence to each estimate.
Days 15–21: build the forecast and review points. Estimate remaining recurring activity, add scheduled events and an uncertainty reserve, and compare the result with the displayed allocation. Choose internal review bands that are earlier than the point at which continuity is threatened. Assign an action and owner to each band. Confirm the customer’s commercial terms with the partner if additional units may be needed.
Days 22–30: observe, communicate, and revise. Check the meter on the agreed cadence, record changes to the forecast, and investigate material differences. Tell users what to do if they see a built-in warning or cannot access AI Assistant. At month-end, save the final reading, evaluate the value and quality of each workflow, and decide whether to continue, adjust, pause, or expand.
The 30-day schedule is a practical starting framework, not a product requirement. If the organization’s close cycle, procurement process, or AI Assistant availability requires a different timetable, adapt the dates and retain the same checkpoints. The important outcome is a current entitlement record, a measured baseline, a named owner, a forecast that identifies its assumptions, and a continuity action that users can follow.
Copy-and-use AI Units planning worksheet
The following worksheet can be maintained in a spreadsheet, ticket, or operational document. Keep the same fields each month so the readings can be compared. If a field is not available from the product screen, mark it as a locally recorded value or a planning assumption.
|
Field |
What to record |
|
Period and environment |
Month, tenant or instance context, release version, and whether the reading is from production or another environment |
|
Monthly allocation |
The limit displayed for the applicable agreement, plus the date it was verified |
|
Starting reading |
Units consumed, percentage of limit, capture time, and consumption owner |
|
Workflow name |
A short business label, such as weekly receivables review or training session |
|
Expected activity |
Users or sessions, cadence, and any scheduled peak; label these as assumptions until measured |
|
Pilot measurement |
Beginning and ending readings, time window, event count, and whether other use could affect the result |
|
Estimated range |
Low, expected, and high demand, with a note about the assumptions behind each case |
|
Forecast at review |
Actual month-to-date units plus planned remaining use and reserve |
|
Internal trigger |
The company’s review band and the action owner; mark it as an internal policy |
|
Fallback |
The report, inquiry, dashboard, or process users can use if AI Assistant is unavailable |
|
Commercial status |
Confirmed terms, pending question, authorized approver, and date checked with the partner |
|
Decision and next review |
Continue, adjust, pause, expand, or contact the partner; include the owner and date |
Use the worksheet as a decision aid, not as a substitute for Acumatica’s meter or the customer’s agreement. The “monthly allocation” and “units consumed” fields should come from the environment being managed. The event counts, workflow estimates, reserve, and internal triggers are local planning data. Labeling the source of each value makes it easier for finance, operations, and IT to understand what is known and what is assumed.
At month-end, preserve the forecast that was made before the actual result was known. Then add the final reading and a short variance note. If the forecast was too high because a training event did not repeat, lower the recurring baseline but keep training as a separate scenario. If it was too low because a new group began using the assistant, update the expected user population and revisit the internal escalation plan.
Common budgeting mistakes to avoid
Using another customer’s units-per-question rate. AI Unit consumption depends on a blend of input, output, and cache tokens across models. A rate observed in another tenant or a different set of questions is not a promise for this organization. Use an outside example only to formulate a pilot test, then replace it with local evidence.
Treating the default warning as the budget target. The documented 90 percent threshold is a warning behavior, not a recommendation to operate near the limit. Create earlier internal review bands based on the organization’s lead time and fallback options.
Assuming a dashboard percentage is a price. A percentage of the monthly limit does not establish the cost of that usage. Check the customer’s current commercial terms before converting usage into currency or requesting a purchase.
Forecasting the whole month from a training day. Training, onboarding, or a launch event can be atypical. Keep one-time events separate from recurring demand and document what is expected to repeat.
Assuming the product reports consumption per user or per prompt. The sources cited here document aggregate monitoring locations and a monthly percentage-of-limit measure. Do not promise a per-user breakdown unless the installed product and current documentation confirm it. Use a controlled pilot log when workflow-level estimates are needed.
Mixing different AI products in one total. AI Assistant, an external model, a marketplace tool, and an automation capability may have different usage measures and commercial terms. Track them separately until their relationship is verified.
Letting nobody own the meter. Shared responsibility can become no responsibility. Assign one person to collect the reading and coordinate action, even when approvals belong to other owners.
Making a cost decision without a fallback. If the assistant becomes unavailable at the monthly limit, users should know how to complete the essential work. Prepare that option during the pilot, not during a close deadline.
Overcorrecting when a forecast changes. A spike might be planned training, a real increase in useful adoption, an accidental scope change, or a measurement artifact. Confirm the event and the reading before restricting access.
Ignoring the business value. Conservation is not the objective by itself. Review usage alongside the quality of answers, whether results reconcile to trusted data, and the time or effort the workflow is meant to save. If a use case is not useful, remove it; if it is useful and exceeds the allocation, prepare a documented commercial decision.
Frequently asked questions
What are Acumatica AI Units?
Acumatica describes AI Units as a measure of AI Assistant consumption. Its FAQ says they reflect a blend of input, output, and cache tokens across models. They are not documented here as a fixed number of units per question.
Where can I monitor AI Unit consumption?
Acumatica identifies AI Unit Consumption (ML900000) and the License Monitoring Console (SM604000). In the Console’s Constraint History, the “AI Units by Month (% of Limit)” column shows total units used by AI Assistant and the percentage of the monthly limit.
What triggers the AI Assistant usage warning?
The 2026 R2 help says AI Assistant displays a warning when consumption exceeds a site threshold specified in the license. The documented default is 90 percent. The warning is shown once per user when that user opens AI Assistant and it connects to the cloud service.
Does every AI Assistant question use the same number of units?
The public sources reviewed for this guide do not describe a fixed per-question rate. Acumatica says the measure reflects a blend of input, output, and cache tokens across models, so estimate from a controlled pilot rather than a universal rate. The 2026 R2 help also says Help-related questions do not consume AI Units.
Can I convert an AI Unit balance into a dollar cost?
Not from the meter percentage alone. The public documentation cited here does not provide a universal price per unit. Use the customer’s current order terms and confirm any additional-unit price, timing, and conditions with the authorized Acumatica partner or customer success contact.
What happens if the monthly allocation is exhausted?
Acumatica’s AI Assistant FAQ says the assistant will be unavailable until the allocation resets at the start of the next month; it also says additional AI Units can be purchased. Confirm the applicable options and timing for the customer’s agreement.
Can I see consumption by user or prompt in the standard screens?
The materials cited in this guide document the monthly allocation and aggregate usage views, but do not describe a standard per-user or per-prompt breakdown. Verify the installed environment before relying on such a report. A controlled pilot log can help estimate usage by workflow.
Should I wait for the default 90 percent warning before escalating?
No. The 90 percent figure is the documented default product warning threshold, not a universal internal budget trigger. Set company review points earlier if the organization needs lead time to adjust scope, purchase additional units, or prepare an operational fallback.
Do AI Units include external AI or integration activity?
The Acumatica FAQ and License Monitoring Console references describe AI Units as AI Assistant consumption. Do not assume other Acumatica AI capabilities, external AI providers, marketplace products, or integrations share that same meter. Confirm each product’s usage and licensing terms separately.
How often should an administrator check the meter?
Choose a cadence based on pilot size, rate of change, procurement lead time, and business criticality. A weekly review may suit a small stable pilot; a fast rollout or near-limit forecast may call for more frequent checks. Assign an owner and record every forecast change.
Conclusion: make the allocation visible and the response predictable
Acumatica AI Units are easiest to manage when the organization treats usage as an operating signal, builds its forecast from measured workflows, and keeps that forecast separate from contract pricing. The monitoring screens show how much of the monthly allocation is being used; a controlled pilot and local planning record help explain the demand; and internal triggers connect a rising meter to a clear decision.
Start by verifying the customer’s current entitlement, environment, threshold, and commercial terms. Then select a few valuable, reconcilable questions, capture a baseline, and review the forecast on a calendar. If the expected demand approaches the allocation, classify the work, protect essential processes with a known fallback, and contact the authorized partner before the limit becomes an interruption.
For help designing the pilot, reviewing inquiry scope, and aligning AI Assistant usage with the organization’s access and reporting model, contact Biz-Tech Services. For broader security and rollout guidance, see the companion Acumatica AI Assistant governance guide.
Sources
- Acumatica AI Assistant FAQ
- Working with AI Assistant: General Information, 2026 R2
- License Monitoring Console, 2026 R2 Form Reference Guide
- Acumatica Artificial Intelligence overview
- Introducing Acumatica Cloud ERP: 2026 R2
- Acumatica Artificial Intelligence Terms, June 2026
- Acumatica AI Assistant in 2026 R2: Use Cases, AI Units, GI Security, and Governance
