Blog

Available-to-Promise in Acumatica 2026 R2: Setup, Sales-Order Behavior, and Pitfalls

Estimated reading time: approximately 58 minutes.

Available-to-Promise in Acumatica 2026 R2 helps a distributor answer a practical question during sales-order entry: when can the full open quantity of this stock item be covered and shipped from the selected warehouse? The calculation looks beyond current on-hand inventory. It processes configured supply and demand in date order, applies the order type's ATP horizon and safety-stock policy, and returns an ATP date for an eligible line. It can also calculate the date on which the entire order can ship in full.

That answer is useful only when the inputs reflect the company's fulfillment policy. An ATP date is not a guarantee from a supplier, a warehouse reservation, or a substitute for allocation and shipment processing. It is a calculated commitment signal based on the documents, dates, warehouses, item classes, order types, and quantities that the configuration tells Acumatica to consider. A sound rollout therefore combines setup, data review, worked scenarios, reconciliation, user guidance, and post-launch monitoring.

This guide explains the 2026 R2 feature, the distinction between ATP and familiar inventory quantities, the configuration sequence, sales-order behavior, a detailed example, testing, governance, integrations, and common failure patterns. Product behavior and field names are based on the Acumatica 2026 R2 form reference and release materials available on 21 October 2026. Validate the process in the organization's exact build before using ATP dates in customer commitments.

Table of Contents

1. What Available-to-Promise means in Acumatica 2026 R2
2. Why distributors need a date-based promise
3. ATP compared with on hand available and available for shipping
4. ATP compared with capable to promise and inventory planning
5. The four configuration layers behind an ATP date
6. Enable the Available-to-Promise feature deliberately
7. Create ATP calculation rules that match fulfillment policy
8. Assign ATP rules through item classes
9. Configure order types for cumulative look-ahead
10. Choose an ATP horizon that covers relevant supply
11. Decide whether ATP should protect safety stock
12. Understand the dates used on a sales order
13. How the cumulative look-ahead calculation works
14. How line-level and order-level ATP differ
15. Worked ATP example with supply demand and safety stock
16. How warehouse selection changes the promise
17. Which sales-order lines are eligible for ATP
18. How order status and unconfirmed shipments affect the action
19. How shipping rules and back orders interact with ATP
20. Allocation is different from an ATP calculation
21. Purchase orders transfers and replenishment in the ATP timeline
22. Special cases that need separate testing
23. ATP behavior for imported and integrated sales orders
24. Data quality controls before implementation
25. A practical ATP test plan
26. Reconcile an ATP date to its source documents
27. Design permissions ownership and exception handling
28. Roll out ATP without disrupting order entry
29. Monitor promise quality after go-live
30. Common ATP pitfalls and how to diagnose them
31. Available-to-Promise implementation checklist
32. Frequently Asked Questions
33. Sources

What Available-to-Promise means in Acumatica 2026 R2

Acumatica defines the Available-to-Promise feature as the ability to determine when a sales-order line, or the sales order as a whole, can be shipped to a customer in full. The feature lets an organization create multiple ATP calculation rules, assign them to item classes, select which order types use ATP, and configure the calculation settings for those order types. The 2026 R2 Enable/Disable Features reference describes that scope directly.

The result is a date. For a qualifying sales-order line, Acumatica determines the earliest date on which its full open quantity can be covered. For the order, the system can calculate the date on which all eligible lines can be shipped in full. The Sales Orders form reference documents both calculations and the conditions under which the commands appear.

The phrase can be covered is important. ATP considers a time-phased series of quantities. It starts with the applicable available quantity at the beginning of the horizon, then adds supply and subtracts demand in chronological order according to the ATP rule. When the running balance can cover the quantity being evaluated, the system has a candidate coverage date. If the order type requires shipment, lead time to the customer's location is part of the displayed ATP result.

ATP is therefore more informative than reading one quantity from an inventory inquiry, but it remains dependent on recorded facts. A purchase order with an optimistic promised date can pull the calculation forward even when the vendor is habitually late. A sales order missing from the included demand categories can make supply look freer than it is. A warehouse with stale transfer dates can produce a technically consistent answer that operations cannot deliver.

Acumatica announced general availability of 2026 R2 on 1 October 2026 and identified Available-to-Promise as a new Distribution capability. The official release announcement says the distribution enhancements are intended to support more reliable customer commitments; the practical control is still the tenant's own configuration and data. See the Acumatica 2026 R2 release announcement and 2026 R2 release overview.

Back to TOC

Why distributors need a date-based promise

Sales teams often receive a simple question: can we deliver the requested quantity by the customer's date? Inventory systems commonly show several quantities, but none necessarily answers the date question alone.

On-hand quantity describes what the system records physically. Available quantity applies an availability calculation rule to on-hand inventory and selected additions and deductions. Available for shipping removes quantities that are already shipped, allocated, in unavailable locations, or tied to certain unreleased transactions. These numbers describe a current state. They do not, by themselves, show how future receipts and future demand unfold across a sequence of dates.

A date-based calculation matters when the answer changes over time. Consider an item with 20 units available for shipping today, customer demand for 15 units tomorrow, a purchase receipt for 50 units next Tuesday, and another demand document for 30 units on Wednesday. The business cannot safely tell a customer asking for 40 units that “50 are coming next week” without evaluating what consumes those units and when.

ATP gives order-entry users a documented timeline behind the result. In the line-level calculation dialog, Acumatica lists the supply and demand documents considered, their dates, reference numbers, positive or negative quantities, and the running Available-to-Promise quantity. That transparency makes the answer reviewable. A user can see whether the date depends on a specific purchase order, transfer, return, production supply, or competing demand document.

The business benefit does not come from displaying another date field. It comes from replacing informal promise logic with a shared rule. Customer service, sales, purchasing, inventory planning, and warehouse operations can discuss the same documents instead of relying on different spreadsheets or memory. The rule also exposes disagreements that need policy decisions: whether on-hold orders consume supply, whether safety stock is protected, which inbound documents count, and how far forward the system should look.

The Biz-Tech Acumatica Distribution ERP guide provides broader context for sales orders, availability, allocation, replenishment, purchasing, receiving, and warehouse fulfillment. ATP sits between these processes. It reads their recorded supply and demand to support a promise; it does not execute the downstream work.

Back to TOC

ATP compared with on hand available and available for shipping

The safest ATP rollout begins with a shared vocabulary. Users should not use on hand, available, available for shipping, and available to promise as if they were interchangeable.

On hand is the recorded physical quantity. It is useful for inventory control, but a portion may already be allocated, shipped, stored in a location excluded from availability, expired, or otherwise unsuitable for a new order.

Available is a configurable quantity. The Inventory Allocation Details reference describes it as on hand plus total additions minus total deductions. The selected availability calculation rule determines which plan types are additions and deductions. Two item classes can therefore show different available behavior when their rules differ.

Available for Shipping focuses on what can support shipping from the warehouse. Acumatica calculates it from on hand after deducting shipped quantities, quantities allocated for sales, production, and service orders, quantities in warehouse locations excluded from availability, unreleased issues, certain kit-assembly component demand, and certain kit-disassembly quantities. This value can be lower than on hand for valid operational reasons.

Available to Promise produces an earliest coverage date based on future supply and demand, the quantity to promise, the selected warehouse, the ATP rule assigned to the item's class, the order type's horizon, and the safety-stock choice. It uses Available for Shipping as a visible starting context in the calculation dialog, but it answers a different question.

This distinction should appear in training, order-entry procedures, and test scripts. If a salesperson expects ATP to reserve inventory, the process will fail even if the calculated date is correct. If a planner expects the current available quantity to account for future receipts, the planner may reject a valid ATP result because the measures answer different questions.

The same distinction matters for integrations. A commerce connector may publish On Hand, Available, or Available for Shipment, while ATP is evaluated during sales-order work. Biz-Tech's DSCO inventory synchronization guide shows why the exported quantity basis and selected warehouses must match the fulfillment policy. Publishing a current quantity to a channel and calculating a future promise date are related but separate controls.

Back to TOC

ATP compared with capable to promise and inventory planning

Available-to-Promise should also be separated from Capable-to-Promise and from Distribution Requirements Planning.

Acumatica's manufacturing Capable-to-Promise, or CTP, evaluates when manufactured items can be completed by considering production capacity and manufacturing constraints. The official Capable-to-Promise general information describes finite scheduling, resource availability, raw-material lead times, subassemblies, and planning or production orders. CTP is a manufacturing scheduling workflow. The new Distribution ATP feature is a supply-and-demand coverage calculation for sales-order lines and orders.

The two terms can sound similar because both support customer commitments. Their models are not equivalent. ATP does not automatically prove that a production work center has capacity, that engineering is complete, or that a configurable item can be produced on the candidate date. The Sales Orders reference explicitly excludes configurable lines from the ATP calculation. A manufacturer should continue to use the documented CTP workflow where production capacity is central.

Distribution Requirements Planning, or DRP, has another purpose. DRP creates time-phased planning recommendations and exceptions so the organization can procure or transfer inventory when it is needed. ATP reads configured supply and demand to answer a commitment question. DRP helps decide what supply actions should be taken. One can reveal that a quantity is not coverable within the ATP horizon; the other may guide the planner toward a purchase or transfer response.

This boundary prevents overclaiming. ATP can make existing supply-and-demand information more useful at order entry. It does not repair inaccurate lead times, create vendor capacity, reserve transport, authorize procurement, or schedule production. Those responsibilities remain in the appropriate purchasing, transfer, warehouse, planning, and manufacturing processes.

Back to TOC

The four configuration layers behind an ATP date

An ATP date becomes available only when four layers align.

1. Feature layer. The Available-to-Promise feature must be enabled on Enable/Disable Features (CS100000).
2. Rule layer. An availability calculation rule with the Available-to-Promise rule type must define the supply and demand categories to consider.
3. Item layer. The ATP calculation rule must be assigned to the relevant item class on Item Classes (IN201000), so qualifying stock items inherit the rule.
4. Order layer. The sales-order type must use Cumulative with Look-Ahead in the ATP Calculation field, with an ATP horizon and an explicit safety-stock decision.

The sales-order line then has to meet the documented eligibility conditions. It must contain a stock item, use the Issue operation, remain incomplete, not be configurable, and not have a related unconfirmed shipment. The order must be in a status that permits the ATP command.

This layered design is valuable because it prevents one global rule from being forced onto every item and transaction. A distributor can define different ATP rules for item families that have different supply reliability or demand behavior. It can enable ATP for order types used in customer commitments while leaving other types on the default Do Not Calculate setting.

The flexibility also creates a diagnostic requirement. When Calculate ATP is absent or an ATP Date remains blank, the cause may be at any layer. Troubleshooting should begin with the configuration chain rather than with a code assumption.

Back to TOC

Enable the Available-to-Promise feature deliberately

Enable the feature first in a nonproduction environment. The feature makes ATP controls available on the related forms, but the implementation work begins after the checkbox is enabled.

Before activation, define the business owner and the desired scope. The owner should be able to answer these questions:

• Which sales-order types create customer-facing commitments?
• Which stock-item classes should receive an ATP rule?
• Which supply documents are reliable enough to count?
• Which demand statuses should reduce promise capacity?
• Should safety stock be protected from promises?
• How far into the future are inbound dates considered credible?
• Who can accept or override the resulting date?

Enabling a feature without these decisions can produce inconsistent use. One item class may be configured quickly while another is missed. A test order may show the ATP command, leading users to assume the feature is complete, even though only a subset of items has rules.

Record the configuration baseline before changing it. Export or document the relevant item classes, availability rules, order types, warehouses, locations, safety-stock values, lead times, and representative open documents. This evidence supports testing and rollback. It also helps distinguish a new ATP issue from a pre-existing availability or data-quality problem.

Treat activation as a governed configuration change. Use a sandbox or copy of production data, schedule representative tests, document expected results, and obtain functional approval before deploying. The feature's purpose is operational, so a technically successful enablement is not enough.

Back to TOC

Create ATP calculation rules that match fulfillment policy

Use Availability Calculation Rules (IN201500) to create a rule whose Rule Type is Available-to-Promise. The 2026 R2 Availability Calculation Rules reference distinguishes this rule type from the standard Available type. The ATP rule is used to calculate dates for stock items in sales-order lines and for the order, based on future supply and demand.

The rule's checkboxes decide which recorded events affect the timeline. Demand options include issues, prepared sales, open sales orders, shipped quantities, allocations, back orders, service-order demand, production demand, kit demand, transfer demand, and project-material demand where the related features apply. Supply options can include purchase orders, prepared purchases, purchase receipts, transfers, sales returns, kit assembly supply, production supply, and material supply.

Do not select every checkbox because it exists. Each inclusion needs a business interpretation. A prepared purchase order may represent credible supply in one organization and an unapproved draft in another. An on-hold sales order may represent real customer demand or an unqualified quote-like request. The rule should reflect the meaning of statuses in the organization's process.

Use a decision worksheet with four columns:

Some items need different policies. Fast-moving stocked goods may rely on purchase orders and transfers. Special-order items may be tied to purchase-to-order documents. Repair parts may receive unpredictable returns. Segmenting item classes can be safer than constructing one permissive rule for the entire catalog.

Document the rationale beside the technical setup. When a result is questioned months later, the team needs to know why a plan type was selected, not merely that the checkbox is selected.

Back to TOC

Assign ATP rules through item classes

The ATP rule is assigned in the ATP Calculation Rule field on Item Classes (IN201000). The Item Classes reference states that only an availability calculation rule with the Available-to-Promise type can be selected.

This assignment is a major control point. An eligible sales-order line must contain a stock item whose item class has an ATP rule. If the rule is missing, the line will not qualify even when the feature and order type are configured.

Review item-class design before mass assignment. Item classes often group records for financial, replenishment, tax, or reporting reasons, not solely for promise behavior. One class may contain items with very different lead-time reliability. If a single rule would be misleading, consider whether item-class restructuring is appropriate or whether the ATP rollout should begin with a narrower set.

Do not assume that new items will always inherit the intended rule without review. Add the ATP rule to the new-item governance checklist. When a stock item is created or moved between classes, validate its promise behavior with the same care applied to availability, replenishment, and accounting defaults.

For existing catalogs, produce an exception report that shows active stock items with their item class, assigned ATP rule, default warehouse, and relevant planning attributes. Flag items in customer-facing order flows that have no ATP rule. Also flag discontinued, obsolete, non-stock, configurable, or special-process items so the project does not spend time testing lines that are outside the intended scope.

Back to TOC

Configure order types for cumulative look-ahead

On Order Types (SO201000), the Available-to-Promise Settings section appears when the feature is enabled and the order type uses an eligible automation behavior. The Order Types reference lists Invoice, Sales Order, RMA Order, and Mixed Order automation behaviors for this section.

ATP Calculation has two choices:

• Do Not Calculate, the default, leaves ATP dates inactive for orders of that type.
• Cumulative with Look-Ahead processes supply and demand in chronological order within the horizon and can consider supply expected after the requested date.

Select Cumulative with Look-Ahead only for order types where a promise calculation belongs in the workflow. Review custom order types separately. A copied order type may have different operations, automation behavior, shipping expectations, or integration dependencies even when its code resembles the standard SO type.

An order type is also a contract with integrations. E-commerce, EDI, customer portals, PDF-order automation, and custom connectors frequently choose the destination order type during import. Changing ATP settings on that type can alter what users see on imported orders and what downstream processes might read. The underlying order creation does not automatically calculate or publish an ATP date unless the workflow invokes the appropriate action, but the configuration becomes part of the transaction's behavior.

Capture the old and new settings for every affected type. Confirm the automation behavior, default operation, shipping requirement, shipping rule, back-order behavior, quick-process settings, and integration mappings. ATP should be added to the established process, not treated as an isolated checkbox.

Back to TOC

Choose an ATP horizon that covers relevant supply

ATP Horizon (Days) defines the number of calendar days from the current business date within which Acumatica searches for supply and demand transactions. The system excludes transactions dated beyond the horizon. The Order Types reference states that the default is 90 days when Cumulative with Look-Ahead is selected.

The default is a starting point, not a universal answer. A horizon should be long enough to include supply that the company genuinely uses for promises and short enough to avoid false precision.

A distributor that replenishes domestic stock weekly may not need to consider documents six months out. An importer with ocean freight and seasonal buys may need a longer period. A service-parts business may receive supply sporadically and prefer a conservative horizon because distant purchase dates are less reliable.

Evaluate the horizon with transaction evidence:

1. Measure actual supplier lead-time distribution by item family or vendor.
2. Identify how far ahead customers normally request delivery.
3. Review the date quality of purchase orders, transfers, and returns at different ages.
4. Test whether a longer horizon merely finds uncertain supply instead of improving commitment quality.
5. Define what users should say when ATP is blank because the quantity cannot be covered within the horizon.

A blank ATP Date does not necessarily mean the item can never be supplied. The Sales Orders reference says the field is empty when the quantity cannot be covered within the ATP horizon. The distinction should be explicit in training. The correct next step may be to review purchasing, alternate warehouses, substitutions, transfers, or a manual customer negotiation rather than extending the horizon to make a date appear.

Do not change the horizon casually after go-live. A longer horizon can make more orders appear coverable, while a shorter horizon can remove dates that users previously saw. Treat a horizon change as a policy change and rerun the approved scenarios.

Back to TOC

Decide whether ATP should protect safety stock

Order Types includes Include Safety Stock in ATP Calculation. When selected, Acumatica subtracts the safety-stock quantity from the available quantity before calculating ATP so the calculation does not promise inventory below that level. The setting is cleared by default.

The choice is operational. Safety stock may exist to protect service levels during demand variability, supplier delay, or other uncertainty. If ATP ignores it, the promise calculation can consume the buffer in its mathematical coverage. If ATP protects it, an order may receive a later date even though physical units appear to be present.

Neither choice is inherently correct for every order type. Some companies treat safety stock as a firm floor. Others permit selected customer orders to use it with approval. A single checkbox cannot model an informal exception policy by itself.

Use these questions to decide:

• Is safety stock maintained accurately by item and warehouse?
• Does the current process already protect it during allocation and shipment?
• Can sales override the buffer, and if so, who approves the exception?
• Are strategic customers handled through a separate order type or workflow?
• Will users understand why ATP is later than the current physical quantity suggests?
• How often is the buffer recalculated, and what evidence supports the quantity?

Test both states with the same documents. For example, begin with 25 units available for shipping, safety stock of 10, and a request for 20. With safety stock excluded from the promise calculation, current supply may cover the request. With safety stock protected, only 15 units are promiseable at that point, so ATP should move to a later supply event or remain blank within the horizon.

The test demonstrates why the policy belongs in training and customer-service scripts. The system is not “wrong” when it gives different dates under the two settings. It is applying two different promise policies.

Back to TOC

Understand the dates used on a sales order

ATP depends on dates, but sales orders contain several date concepts. Users should know which one they are viewing and who owns its accuracy.

Requested On is when the customer wants to receive the item. The line can have its own requested date, particularly when the order-level shipping rule allows back orders. This is a customer requirement, not proof that supply exists.

Ship On is when the item should be shipped. Acumatica normally derives it from Requested On minus the lead days. If that result is earlier than the current business date, the current date is used. The line's Ship On date can be editable when Back Order Allowed applies.

ATP Date on the line is the earliest date on which the full open quantity can be covered under the configured calculation. The calculation dialog also shows Lead Time (Days). When the order type requires shipment, Acumatica adds lead time to the date on which the quantity can be covered to determine the ATP date.

ATP Date on the Shipping tab is the date on which the sales order can be shipped in full after order-level calculation. It is not necessarily the same as the earliest line date because the order cannot ship in full until its limiting line is ready.

Supply and demand dates come from the documents included by the ATP rule. A purchase order line's expected date, a transfer's date, a sales order's demand date, or a return's date can move the running balance. These dates must be maintained by their process owners.

Use a date dictionary in the rollout documentation. List the source field, business meaning, owner, update trigger, and whether it influences ATP. This small artifact prevents a recurring misunderstanding: users may read an ATP result as a requested delivery date, or may update Requested On without realizing that the calculation relies on different supply dates.

Back to TOC

How the cumulative look-ahead calculation works

The line-level Available-to-Promise Calculation dialog gives the clearest explanation of the method. Acumatica shows the item's warehouse context, quantity to promise, on-hand quantity, available-for-shipping quantity, safety stock, lead time, requested date, and calculated ATP date. Beneath the summary, it lists the supply and demand documents used in the calculation.

Each timeline row has:

• the date on which the document is expected to increase or decrease availability;
• the document type;
• a reference number linked to the source document;
• a positive quantity for supply or a negative quantity for demand; and
• the running Available-to-Promise quantity as of that row.

The running balance begins with the available quantity at the start of the ATP horizon. Acumatica then adds each document quantity in chronological order. The quantity to promise is evaluated against this progression. The candidate date is the earliest point at which the applicable balance can cover the full quantity, subject to safety stock and other settings.

This method is called cumulative because earlier supply and demand affect later availability. It uses look-ahead because supply after the requested date can still produce a future ATP result. That does not mean the customer request is met. It means the system has found the earliest later point, within the horizon, at which the full quantity can be covered under the rule.

The calculation is deterministic with respect to its inputs, but the inputs change. A newly entered order, rescheduled purchase, canceled transfer, partial receipt, return, allocation, or warehouse change can alter the result. Users should recalculate before communicating a date when material documents have changed.

Do not create an external simplified formula and assume it will reproduce every tenant result. The selected plan types, statuses, features, warehouse rules, safety stock, and line eligibility all matter. Use the calculation dialog as the primary reconciliation surface because it shows the actual documents Acumatica used.

Back to TOC

How line-level and order-level ATP differ

The Details tab provides a Calculate ATP action for one selected line. The result can be reviewed in the calculation dialog before it is saved to the line. Users can also change the warehouse or quantity to promise in the dialog; when saved, those changes update the line along with the ATP date.

The More menu provides Calculate ATP Date for the entire order. Acumatica evaluates all eligible lines, inserts their line dates, and calculates the date on which the order can ship in full. The order-level ATP Date appears on the Shipping tab.

The distinction matters when an order has several items:

• Line A may be coverable today.
• Line B may depend on a purchase receipt next Friday.
• Line C may be coverable in another warehouse on Wednesday.
• The complete order date must reflect the set of eligible lines and the chosen fulfillment behavior.

If a customer accepts split shipments, line dates may guide a staged commitment. If the customer requires Ship Complete, the latest constraining line controls the meaningful complete-order promise. The order-level calculation provides a shared reference, but the shipping rule and customer agreement still determine how operations should act.

Line-level review is also useful for diagnostics. A user can change the warehouse or test a smaller quantity without editing several order fields blindly. The dialog should not become an undocumented override mechanism. If warehouse or quantity changes affect the commercial agreement, require the same approval and audit controls used for ordinary order changes.

Back to TOC

Worked ATP example with supply demand and safety stock

The following example illustrates the logic without claiming to reproduce every tenant's plan configuration. It assumes one stock item, one warehouse, a 30-day horizon, an ATP rule that includes the listed documents, and zero delivery lead time unless stated otherwise.

Scenario setup

The customer wants 40 units of item A100. The selected warehouse is MAIN.

• Available for Shipping at the start of the horizon: 20 units
• Safety stock: 5 units
• 23 October: existing open sales-order demand of 8 units
• 24 October: purchase-order supply of 25 units
• 25 October: transfer-out demand of 10 units
• 28 October: purchase-order supply of 30 units
• 30 October: existing back-order demand of 12 units

The new line itself is the quantity being tested, so the example does not subtract it as a separate competing demand row.

Timeline without safety-stock protection

The running quantity first reaches 40 on 28 October. It remains above 40 after the 30 October demand, so 28 October is the candidate coverage date in this simplified timeline.

Timeline with safety-stock protection

If the order type protects 5 units of safety stock, begin from an effective promiseable quantity of 15 rather than 20.

The balance reaches 40 on 28 October, but later included demand reduces it to exactly 40. Depending on how the product evaluates coverage against later dated commitments within the configured method, the calculation dialog is the authoritative result. The example's purpose is to show that safety stock changes the running balance and can change the date or eliminate coverage near the horizon boundary.

Add customer delivery lead time

Assume the stock is covered on 28 October and the customer location has two lead days. When the order type requires shipment, the documented calculation adds the lead time to determine the ATP date shown to the user. The operational interpretation should distinguish the warehouse coverage date from the customer-facing date.

Change the warehouse

Suppose warehouse EAST has 45 available-for-shipping units and no earlier included demand. The line-level dialog lets the user change the warehouse and recalculate. EAST may produce an earlier date, but that result is not a command to move the order automatically. The user must consider fulfillment cost, warehouse policy, branch access, shipping zone, customer expectation, and whether the organization uses order orchestration.

What to validate in the real system

Build the scenario with actual documents and record:

1. Every document that appears in the calculation dialog.
2. Every expected document that does not appear.
3. The sign and date of each quantity.
4. The starting available-for-shipping value.
5. The safety-stock behavior.
6. The coverage date before lead time.
7. The saved line ATP date and order ATP date.
8. The result after changing one input at a time.

This approach tests both configuration and user interpretation. A screenshot of a final date without the document timeline is not enough evidence.

Back to TOC

How warehouse selection changes the promise

ATP is evaluated for the warehouse selected on the line. In the calculation dialog, changing the warehouse recalculates the date. This is useful when the company can fulfill from multiple sites, but it makes warehouse data part of the promise.

Warehouses may differ in:

• current available-for-shipping quantity;
• inbound purchase schedules;
• transfer supply and demand;
• safety-stock values;
• excluded locations;
• customer delivery lead time;
• shipping zones and carrier services;
• item-specific warehouse settings; and
• operational cutoffs or capacity not represented in ATP.

The earliest mathematical date is not always the best fulfillment choice. Shipping from a distant site may increase freight cost, split an order, complicate tax or branch handling, or consume supply reserved operationally for another region. Define when users may change the warehouse and whether approval is required.

If Order Orchestration is enabled, do not assume ATP and orchestration make the same decision. Order orchestration chooses fulfillment according to configured strategies and plans; ATP calculates coverage for the selected warehouse and quantity. Test the combined workflow using the actual order type, orchestration strategy, shipping zone, and warehouse priorities.

Unavailable warehouse locations also matter to the starting quantity. Inventory Allocation Details states that Available for Shipping excludes quantities in locations where Include in Qty. Available is cleared. Validate receiving, quarantine, inspection, damaged-goods, and staging locations so physical stock that cannot ship is not mistaken for promiseable stock.

Back to TOC

Which sales-order lines are eligible for ATP

According to the Sales Orders reference, a line qualifies for ATP calculation only when all of these conditions are met:

• It contains a stock item.
• The item's item class has an ATP calculation rule.
• The line is not completed.
• The operation is Issue.
• The line is not configurable.
• The line does not have a related unconfirmed shipment.

The conditions explain several common cases before troubleshooting begins.

A non-stock service or charge line does not represent warehouse stock and therefore does not receive this ATP calculation. A receipt operation adds inventory rather than issuing it to the customer. A completed line no longer needs a new coverage date. A configurable item may require configuration and manufacturing logic outside the distribution ATP model. A line already tied to an unconfirmed shipment has entered a different fulfillment state.

Create a negative test for each exclusion. The goal is not to force every line to display a date. The goal is to confirm that eligible lines calculate and ineligible lines remain outside the process for the documented reason.

Mixed orders, returns, replacements, kits, drop shipments, and custom line types deserve extra attention because one document can contain different operations and fulfillment paths. Review the line, not only the order header.

Back to TOC

How order status and unconfirmed shipments affect the action

The ATP commands are available only for sales orders in documented working statuses. The 2026 R2 Sales Orders reference lists On Hold, Awaiting Payment, Credit Hold, Open, and Back Order for the calculation actions.

These statuses cover orders that may still need a commitment decision. A canceled or completed order is outside that decision. A line with a related unconfirmed shipment is excluded because fulfillment processing has already created a shipment document whose quantities and status need to be resolved.

Users should calculate at defined checkpoints:

1. During order review, after item, quantity, warehouse, requested date, and shipping information are correct.
2. After credit or payment status changes when the order remained open long enough for supply and demand to move.
3. After a material purchasing, transfer, or back-order update.
4. Before sending a promise externally when the prior calculation is no longer recent.
5. After changing the warehouse or open quantity.

Avoid a rule that says “calculate once at order creation.” ATP is a snapshot of a changing document timeline. The saved date can become stale after other transactions change. The process should define when recalculation is mandatory and how users recognize an old result.

An unconfirmed shipment requires operational review rather than an ATP workaround. Confirm, correct, or delete the shipment according to normal controls. Do not detach or alter shipment records merely to make the ATP button available.

Back to TOC

How shipping rules and back orders interact with ATP

Shipping rules determine how an order may be fulfilled. Acumatica documents three familiar outcomes on sales orders: Ship Complete, Back Order Allowed, and Cancel Remainder. ATP does not replace these rules.

With Ship Complete, the practical commitment centers on the date when the order can ship in full. The order-level ATP date is especially relevant because the latest constraining eligible line controls the complete shipment.

With Back Order Allowed, lines can have different requested and ship dates. Line-level ATP can support staged commitments, but the business must explain each shipment and keep the remaining demand visible. Back-order demand should be included or excluded from the ATP rule according to a deliberate policy.

With Cancel Remainder, the first shipment can end the remaining obligation according to the order process. An ATP date for the full original open quantity may be less relevant if the customer accepts partial fulfillment and cancellation of the balance. The sales policy should decide whether ATP is used before that decision and how the communicated commitment is recorded.

Test partial availability explicitly. Enter an order larger than current stock, calculate ATP, create a partial shipment where allowed, confirm or leave the shipment unconfirmed, and recalculate the remaining order after the correct operational step. Observe line eligibility, open quantity, back-order status, and the updated timeline.

Back orders can consume future supply when the ATP rule deducts them. This is usually essential for fairness: a new order should not be promised against a receipt already needed for older demand. If back orders are excluded, document the reason and test the priority process that prevents overpromising.

Back to TOC

Allocation is different from an ATP calculation

Allocation reserves or associates inventory quantities with demand according to the order and inventory process. ATP estimates the earliest date on which the full open quantity can be covered under a rule. A calculated ATP date does not, by itself, hard-allocate the stock or prevent another transaction from consuming it.

This distinction is critical in high-volume order entry. Two users can calculate similar dates close together while supply and demand continue to change. If the business requires reservation, the allocation workflow must occur and be monitored separately.

Inventory Allocation Details is the main diagnostic surface for current availability and item plans. It shows on-hand, available, available-for-shipping, additions, deductions, and the source documents behind them. The ATP dialog provides the time-phased subset used for the promise calculation. Use both when a user reports that the promise date conflicts with the apparent inventory position.

Training should use precise verbs:

• “Calculate ATP” means determine an earliest coverage date.
• “Save ATP” means write the reviewed result to the line, and possibly save changed warehouse or quantity values from the dialog.
• “Allocate” means reserve or designate inventory through the applicable sales-order process.
• “Create shipment” moves the order into warehouse fulfillment.
• “Confirm shipment” records the completed shipment step according to the configured workflow.

Biz-Tech's guide to PDF order automation and inventory allocation explains a similar boundary: automation can create clean sales-order demand, while Acumatica still controls allocation, back orders, transfers, and shipment behavior. ATP adds a date calculation to that controlled process; it does not erase the boundary.

Back to TOC

Purchase orders transfers and replenishment in the ATP timeline

Future supply can make ATP valuable, but only when the underlying documents are credible.

Purchase orders. If the ATP rule includes open purchase orders, their quantities and expected dates can increase the running balance. Review approval status, vendor confirmation, partial receipts, overdue lines, and date-maintenance discipline. An open purchase order is not the same as a confirmed delivery.

Purchase receipts. Unreleased receipts may represent goods that have arrived but are not yet available under the ordinary inventory process. Test whether the selected plan category belongs in the ATP rule and whether inspection or quality holds create additional constraints.

Transfers. Transfer supply and demand should be paired by warehouse and date. A transfer into MAIN is potential supply for MAIN and demand against the source warehouse. Late transfer processing can make one warehouse appear short while another appears to have supply in motion.

Replenishment. A recommendation or planning exception is not necessarily an executable supply document. ATP uses the plan types included in the rule. Confirm which planning outputs become purchase orders, transfers, or other documents before counting them.

Purchase-to-order and drop shipment. Sales lines linked to purchasing follow specific fulfillment relationships. Test linked quantities, partial documents, vendor dates, and receipt or direct-ship behavior. Do not assume the general warehouse ATP date is the appropriate customer commitment for a drop shipment without validating the documented flow.

Build an exception report for inbound supply used by ATP. Useful conditions include promised dates in the past, lines with no promised date, partially received orders, transfers not released, purchase orders on hold, and vendors whose actual receipts frequently miss recorded dates. ATP quality depends on the owners correcting those records.

Back to TOC

Special cases that need separate testing

Some inventory and order patterns cannot be covered safely by one ordinary stocked-item scenario.

Kits

Stock kits and non-stock kits can depend on component availability, kit assembly, disassembly, or customized processing. The ATP line may represent the kit item while operational feasibility depends on components. Test the actual kit configuration and the plan types included in the ATP rule. The Biz-Tech kit component inventory guide explains why On Hand, Available, Available for Shipping, component demand, purchase supply, and assembly documents must be distinguished.

Lot and serial tracking

A total quantity can appear sufficient while the usable lots do not meet expiration, assignment, customer, project, or quality requirements. Inventory Allocation Details can exclude expired quantities and locations not included in availability, but the business should test its lot and serial workflow through allocation and shipment.

Configurable items

The documented sales-order ATP calculation excludes configurable lines. Use the applicable configuration and manufacturing process. Do not present a missing ATP date as a defect when the line is outside the feature's eligibility.

Project-specific inventory

Project inventory can restrict which quantity belongs to a customer or project. Test project and task dimensions, warehouse locations, allocations, and item plans. A company-wide quantity may not be available to the specific order.

Returns

An expected return is uncertain until the goods arrive and their condition is known. If the ATP rule includes sales returns, define when a return can be counted and whether inspection or disposition delays the item becoming ship-ready.

Expired or quarantined stock

The warehouse can physically contain units that should not be promised. Confirm location availability settings, lot expiration behavior, quality controls, and the starting Available for Shipping quantity.

Units of measure

ATP evaluates quantities in a system that may use different sales, purchase, and base units. Test conversion factors, rounding, divisible-unit settings, pack sizes, and vendor quantities. A conversion error can move the date even when document counts look reasonable.

Customizations and integrations

Custom code may set warehouse, requested date, order type, operation, status, plan type, or quantity. Review customizations that extend SO301000, IN201500, IN201000, purchase processing, transfer processing, or integrations. Retest after every upgrade or customization change.

Back to TOC

ATP behavior for imported and integrated sales orders

Imported orders use the same Acumatica order configuration after they are created. The source system does not bypass the need for a correct Acumatica item, warehouse, order type, quantity, unit of measure, requested date, operation, and status.

This point matters because integrations often apply defaults:

• A connector may choose one order type for all incoming orders.
• A store configuration may assign a default warehouse.
• A cross-reference may translate an external SKU or warehouse into Acumatica values.
• An import scenario may place orders on hold.
• EDI or commerce data may omit a requested delivery date or use a different date definition.
• A customization may create allocations, purchase links, or shipments soon after import.

Each default can affect ATP eligibility or the resulting timeline. A wrong warehouse can produce a valid date for the wrong supply pool. A wrong item can inherit a different ATP rule. A direct-to-invoice flow may not follow the sales-order process expected by customer service. An automatically created unconfirmed shipment can make the line ineligible for calculation.

Review the integration mapping as part of the ATP design. The Biz-Tech WooCommerce data-flow guide shows how a connector can set the destination document type, order type, and warehouse. The Salesforce inventory-allocation guide reinforces that imported demand affects inventory through the Acumatica sales order that is created, while allocation rules remain in Acumatica.

Create end-to-end tests for each order source:

1. Import a known item and quantity.
2. Confirm the resulting order type, warehouse, UOM, requested date, status, and line operation.
3. Calculate ATP and capture the document timeline.
4. Compare the result with a manually entered order using identical values.
5. Change one mapping, such as warehouse, and confirm the expected change.
6. Continue through allocation, shipment, confirmation, and invoice processing.
7. Verify what date, if any, is returned to the external channel.

Do not automatically publish the ATP date to a marketplace, portal, CRM, or EDI acknowledgment without a separate interface design. Define the outbound field, timezone, date semantics, recalculation trigger, error handling, and what happens when the date is blank or later changes.

Back to TOC

Data quality controls before implementation

ATP can expose weak data because it asks the system to connect many ordinary transactions on a timeline. Improve the data before judging the feature.

Item master data

Confirm that each in-scope stock item has the correct item class, base and sales UOMs, default warehouse, item-warehouse settings, safety stock, lead times, lot or serial settings, and active status. Identify duplicate or obsolete items that should not receive customer demand.

Warehouse and location data

Review warehouse access, defaulting, customer shipping zones, item availability by warehouse, and location flags. Quarantine, damaged, inspection, returns, staging, and consignment locations should reflect whether their stock is eligible for availability and shipping.

Supply dates

Measure overdue and missing promised dates on purchase orders and transfers. Ask buyers and warehouse planners how dates are updated after vendor acknowledgments, partial receipts, or delays. A daily ATP process needs a daily date-maintenance habit.

Demand status discipline

Review how long sales orders remain on hold, credit hold, open, or back order. Remove canceled or abandoned demand through the proper workflow. Decide which statuses the ATP rule treats as real demand.

Document quantities

Look for unusual UOM conversions, negative quantities, partially completed lines, incorrect open quantities, and duplicate integration records. Reconcile linked purchase-to-order and transfer documents.

Customer lead-time inputs

Confirm that the delivery lead time used in the result corresponds to the customer location and shipping process. Carrier transit time, warehouse cutoff, weekends, holidays, and route schedules may need operational controls beyond the base ATP calculation.

Ownership

Assign each data category to a role. Sales owns customer request details; purchasing owns expected vendor dates; inventory control owns location and quantity accuracy; warehouse operations owns shipment state; the ERP team owns configuration; process leadership owns exception policy.

Use measurable entry criteria for the pilot. Examples include no missing ATP rule on pilot item classes, no overdue inbound document without a reviewed date, no unexplained negative Available for Shipping quantity, and signed expected results for representative scenarios.

Back to TOC

A practical ATP test plan

A reliable test plan combines configuration coverage, business scenarios, negative cases, and reconciliation. Use a recent copy of production data where permitted, because synthetic master data often misses real item-class, warehouse, and document variation.

Establish the baseline

Before enabling ATP, record the current promise process. Identify which fields users read, which spreadsheets or inquiries they consult, who approves an exception, and how late promises are tracked. This baseline will show whether ATP reduces ambiguity or simply adds another date.

Build a scenario matrix

Test at least the following:

Change one variable at a time

Begin with a known document set. Calculate and capture the result. Then change one input: a PO date, quantity, warehouse, safety-stock setting, horizon, demand status, or rule checkbox. Recalculate and explain the difference. Multiple simultaneous changes make a failed expectation difficult to diagnose.

Verify both line and order calculations

Test Calculate ATP on a selected line and Calculate ATP Date for the order. Confirm saved values in the line and Shipping tab. Use orders with one line and several lines.

Test user roles

Run scenarios under the actual sales, customer-service, purchasing, warehouse, and administrator roles. Confirm that users can see the necessary source documents without receiving unnecessary access. A calculation result that links to documents the user cannot inspect needs an escalation path.

Test concurrency and change

Have one user calculate while another updates an included supply document in a controlled test. Recalculate and confirm the changed result. The purpose is to teach that ATP is time-sensitive, not to prove that a saved date is permanently reserved.

Record evidence

For each scenario retain the configuration version, build number, user role, starting values, source documents, screenshots of the timeline, expected result, actual result, and reviewer decision. This evidence supports training and future regression tests.

Back to TOC

Reconcile an ATP date to its source documents

Reconciliation should be a standard response to a questioned ATP date. Avoid debating the final date before reviewing the timeline.

1. Open the sales order and confirm its status, type, warehouse, item, quantity, operation, requested date, open quantity, and shipment state.
2. Confirm that the Available-to-Promise feature is enabled.
3. Open the order type and record ATP Calculation, ATP Horizon, and the safety-stock setting.
4. Open the item's item class and record the assigned ATP Calculation Rule.
5. Open the rule and record every selected supply and demand category.
6. Open Inventory Allocation Details for the item and warehouse. Reconcile On Hand, Available, Available for Shipping, locations, and item plans.
7. Open the line-level ATP dialog and export or transcribe the dated document rows.
8. Follow each reference number to its source document. Confirm date, status, warehouse, open quantity, and link relationships.
9. Rebuild the running balance in a simple worksheet.
10. Confirm safety-stock and lead-time effects.
11. Recalculate after correcting any source document through its normal workflow.

Do not edit a transaction merely to force the expected answer. If the calculation uses an unwanted document, determine whether the document is wrong, its status is wrong, its date is stale, or the rule includes a plan category the business does not trust.

The dialog's source links are an important control. They turn ATP from an opaque date into an auditable chain. Save that evidence when resolving a customer-impacting exception.

If a customization or build-specific issue is suspected, create the smallest reproducible scenario. Include exact build, enabled features, order type, rule settings, item class, document data, user role, and steps. Compare the result in a clean environment when practical before escalating.

Back to TOC

Design permissions ownership and exception handling

ATP crosses functional boundaries, so ownership must be explicit.

ERP administrator. Enables the feature, controls configuration changes, documents versions, and coordinates regression testing.

Distribution functional owner. Approves the ATP rule, horizon, safety-stock policy, order-type scope, and operational interpretation.

Sales and customer service. Enters accurate order data, calculates at defined checkpoints, communicates approved dates, and escalates exceptions.

Purchasing. Maintains credible inbound dates and resolves supplier changes that affect promises.

Inventory and warehouse teams. Maintain quantity accuracy, location availability, transfers, allocations, shipment status, and exception stock.

Integration owner. Validates order defaults and controls any outbound use of the ATP date.

Finance or commercial leadership. Defines which customers, order values, or margin conditions require approval before a later date, split shipment, expedited freight, or safety-stock exception is accepted.

Separate permissions for calculation, transaction editing, and configuration. A sales user may need to calculate and inspect the timeline without being allowed to edit ATP rules or purchase dates. A buyer may maintain purchase dates without changing the order's commercial terms.

Define exception categories:

• blank date within the horizon;
• date later than the customer request;
• source document with uncertain or overdue supply;
• safety-stock override request;
• alternate-warehouse request;
• split-shipment request;
• expedited purchase or freight request;
• strategic-customer prioritization;
• result that conflicts with a physical or supplier reality.

For each category, name the decision owner, required evidence, response time, allowed changes, and where the decision is recorded. ATP should make exceptions visible, not move them into private messages.

Back to TOC

Roll out ATP without disrupting order entry

Use a controlled sequence instead of enabling every order type and item class at once.

Phase 1: policy and design

Map the current promise process. Approve rule categories, horizon, safety stock, order types, item scope, roles, and exception handling. Identify integrations and customizations.

Phase 2: configuration prototype

Enable ATP in a sandbox. Create one ATP rule for a coherent item family, assign it to a pilot item class, and configure one order type. Use a small set of representative warehouses and customers.

Phase 3: data cleanup

Correct stale dates, class assignments, warehouse defaults, location flags, UOMs, safety stock, back orders, and incomplete supply documents for the pilot scope.

Phase 4: scenario testing

Execute the approved matrix and reconcile every result. Include integrations, permissions, negative cases, and multi-line orders.

Phase 5: user pilot

Select a small sales and customer-service group. Ask them to use ATP alongside the existing promise process without changing external commitments automatically. Collect discrepancies and classify their causes.

Phase 6: operational integration

Update procedures, customer communication templates, approvals, reports, dashboards, and any intended outbound interfaces. Train purchasing and warehouse users on how their dates and statuses influence promises.

Phase 7: production release

Deploy the signed configuration through the organization's change process. Verify it in production with non-disruptive test orders or carefully selected real orders. Confirm the exact build and enabled feature state.

Phase 8: expansion

Add item classes, order types, warehouses, and integrations only after the pilot metrics are stable. Reuse regression tests and document rule differences.

The rollout should include an explicit stop condition. Pause expansion if users cannot reconcile dates, overdue inbound records remain common, the integration publishes unreviewed dates, or late commitments increase.

The broader Acumatica 2026 R2 Upgrade Guide provides a framework for sandbox testing, customizations, integrations, training, and cutover. ATP should follow the same controlled upgrade discipline.

Back to TOC

Monitor promise quality after go-live

The goal is not to maximize the number of orders with an ATP date. The goal is to improve the reliability and explainability of customer commitments.

Track measures that connect the calculation to outcomes:

Promise adherence

Compare the communicated promise date with the actual shipment or delivery result. Segment by item class, warehouse, vendor-dependent supply, order type, and customer.

ATP date stability

Measure how often the saved date changes before shipment and the size of the change. Frequent movement may indicate stale supply dates, volatile demand, weak allocation, or a horizon that reaches too far.

Requested-date gap

Measure the difference between Requested On and ATP Date. This identifies item families and warehouses where demand regularly exceeds the planned supply position.

Blank ATP rate

Track eligible lines that remain uncovered within the horizon. Do not treat zero as the target. A blank result can be an honest signal. Investigate clusters by item, vendor, warehouse, or rule.

Manual override rate

Record warehouse, quantity, date, or safety-stock exceptions. High volume may mean the policy does not match real operations or users are bypassing it.

Source-document quality

Monitor overdue purchase lines, missing promised dates, late transfers, unconfirmed shipments, old back orders, and abandoned on-hold sales orders.

Customer-service handling time

Measure the time needed to answer a date inquiry and the number of handoffs. A transparent calculation may reduce manual investigation even before on-time performance changes.

Review results weekly during the pilot and monthly after stabilization. Separate configuration errors, data errors, process exceptions, and supplier or warehouse execution problems. ATP cannot solve every cause, but it can make the causal chain easier to inspect.

Back to TOC

Common ATP pitfalls and how to diagnose them

Calculate ATP is missing

Check the feature, order type's ATP Calculation setting, order status, item class rule, line operation, completed state, configurable status, and related unconfirmed shipment. Follow the four-layer configuration chain.

ATP Date is blank

Confirm that the quantity cannot be covered within the horizon. Review the timeline for missing or excluded supply, competing demand, safety stock, wrong warehouse, and dates beyond the horizon. A blank field can be the correct answer.

The date is much later than expected

Look for included demand before the anticipated supply, protected safety stock, lead time, back orders, transfer demand, overdue supply moved to a later date, or an item in the wrong class.

The date is earlier than operations believe

Investigate optimistic purchase dates, on-hold supply counted as credible, missing demand categories, stale canceled or duplicated data, returns counted before inspection, wrong UOM conversion, and stock in an operational state not represented by the rule.

On Hand is high but ATP is late

Reconcile Available for Shipping. The stock may already be allocated, shipped, located in an excluded location, expired, reserved for another purpose, or protected as safety stock.

Available for Shipping is low but future supply exists

Current ship-ready quantity and future promise are different. Confirm that the future document type is included, dated within the horizon, assigned to the same warehouse, and in an eligible status.

A purchase order does not appear

Check the rule's purchase categories, PO status, warehouse, item, UOM, open quantity, date, link type, and whether the transaction is beyond the horizon.

An old sales order consumes supply

Confirm whether its status and plan category are included. Resolve the order through the proper cancel, complete, close, or back-order process. Do not exclude valid demand merely to improve dates.

Alternate warehouse gives an attractive date that cannot be used

Review warehouse access, branch and shipping policy, customer lead time, freight, carrier service, tax implications, order orchestration, item restrictions, and operational capacity.

Imported orders calculate differently from manual orders

Compare order type, warehouse, status, UOM, requested date, operation, item mapping, quantity, and any automatic shipment or purchase link. Build a paired control test.

Users treat ATP as a reservation

Correct the procedure and training. Add an allocation checkpoint and a warning in the work instruction. Track cases where calculated dates change because inventory was not allocated.

Users extend the horizon until a date appears

Return to the data and policy. A farther date is not more reliable merely because the system can see it. Require approval for horizon changes and evaluate inbound-date accuracy.

Safety stock is bypassed informally

Choose a governed exception path. Consider a separate order type only if it matches the business process and is tested. Do not encourage users to change item master data temporarily.

The order date and line dates disagree

Review all eligible lines and the shipping rule. The order-level date reflects when the full order can ship, while individual lines can be ready earlier.

The result changed after a patch or upgrade

Run the saved regression scenarios. Compare build numbers, enabled features, rules, item classes, order types, customizations, plan types, and source documents. Reopen the current Acumatica documentation before escalating.

Back to TOC

Available-to-Promise implementation checklist

Scope and policy

• [ ] Name the ATP business owner and technical owner.
• [ ] Define which customers, item families, warehouses, and order types are in scope.
• [ ] Decide whether safety stock is protected.
• [ ] Approve the ATP horizon using lead-time and date-quality evidence.
• [ ] Define how blank, late, or changing dates are handled.
• [ ] Define when a calculated date may be communicated externally.

Configuration

• [ ] Enable Available-to-Promise in a sandbox.
• [ ] Create ATP-type calculation rules.
• [ ] Document every included supply and demand category.
• [ ] Assign ATP rules to the correct item classes.
• [ ] Set order types to Cumulative with Look-Ahead where appropriate.
• [ ] Record horizon and safety-stock settings for each order type.
• [ ] Review custom order types and automation behaviors.

Master data and transactions

• [ ] Validate item class, stock status, UOMs, and warehouse defaults.
• [ ] Validate item-warehouse safety stock and lead-time inputs.
• [ ] Review warehouse-location availability flags.
• [ ] Correct overdue or missing purchase and transfer dates.
• [ ] Resolve abandoned on-hold orders and invalid back orders.
• [ ] Reconcile linked purchase-to-order, drop-ship, kit, and transfer documents.

Testing

• [ ] Test current stock, future supply, competing demand, and no-supply cases.
• [ ] Test the horizon boundary and both safety-stock settings.
• [ ] Test line-level and order-level calculations.
• [ ] Test alternate warehouses and multi-line orders.
• [ ] Test shipping rules and partial fulfillment.
• [ ] Test every documented line exclusion.
• [ ] Test all user roles.
• [ ] Test each integration source against a manual control order.
• [ ] Reconcile results to the calculation dialog and source documents.
• [ ] Save evidence for future regression testing.

Rollout and operations

• [ ] Train sales, customer service, purchasing, and warehouse teams.
• [ ] Separate ATP calculation from allocation and shipment steps.
• [ ] Define recalculation checkpoints.
• [ ] Define exception ownership and approval evidence.
• [ ] Verify reports, dashboards, and integrations that use the date.
• [ ] Monitor promise adherence, date changes, blanks, and overrides.
• [ ] Review supplier and warehouse data quality regularly.
• [ ] Revalidate after patches, upgrades, or configuration changes.

Back to TOC

Frequently Asked Questions

What is Available-to-Promise in Acumatica 2026 R2?

Available-to-Promise, or ATP, is a Distribution feature that calculates the earliest date on which the full open quantity of an eligible sales-order line can be covered in a selected warehouse. It can also calculate the date on which the complete order can ship in full. The result is based on a configured timeline of supply and demand within an ATP horizon.

Does ATP reserve inventory for the customer?

No. ATP calculates a date; it does not replace inventory allocation or shipment processing. If the business needs stock reserved, users must follow the applicable allocation workflow. A saved ATP date can change when other supply and demand documents change.

Why is Calculate ATP not visible on a sales order?

Confirm that the Available-to-Promise feature is enabled, the order type uses Cumulative with Look-Ahead, the order has an eligible status, and the line contains an eligible stock item whose item class has an ATP rule. The line must use the Issue operation, remain incomplete, not be configurable, and have no related unconfirmed shipment.

Why is the ATP Date blank?

The requested quantity may not be coverable within the configured ATP horizon. Review the line-level calculation, warehouse, quantity, safety stock, included supply and demand categories, document dates, and competing demand. A blank date can be a correct warning rather than a configuration error.

What is the difference between Available for Shipping and Available to Promise?

Available for Shipping is a current quantity after defined operational deductions, including shipped and allocated quantities and inventory in excluded locations. Available to Promise is a future date calculation. It processes configured supply and demand chronologically to find when the full quantity can be covered.

How does safety stock affect ATP?

When Include Safety Stock in ATP Calculation is selected for the order type, Acumatica subtracts safety stock from the available quantity before calculating the date. This protects the buffer from being promised through the ATP calculation and may move the result later or leave it blank inside the horizon.

What does the ATP horizon control?

The horizon is the number of calendar days from the current business date in which Acumatica searches for supply and demand transactions. Documents beyond the horizon are excluded. The Order Types form defaults the value to 90 days, but the organization should choose a horizon that matches credible lead times and date quality.

Can users calculate ATP for another warehouse?

Yes. The line-level calculation dialog lets a user change the warehouse and recalculate. Saving the dialog also updates the line's warehouse if it was changed. The organization should govern this choice because freight, branch, customer, tax, orchestration, and operational rules may make the earliest warehouse date unsuitable.

Does ATP work for configurable or non-stock items?

The documented sales-order ATP calculation applies to qualifying stock-item lines and excludes configurable lines. Non-stock items do not receive the inventory coverage calculation. Manufacturing organizations should evaluate the applicable Capable-to-Promise workflow for produced items where resource capacity matters.

Which documents are included in ATP?

The ATP calculation rule controls the plan categories. Depending on enabled features and selected checkboxes, the rule can include or deduct sales orders, back orders, allocations, issues, purchase orders, receipts, transfers, returns, kit documents, service demand, production supply and demand, and project-material plans. Review the actual rule and calculation dialog rather than assuming a fixed universal list.

How often should ATP be recalculated?

Recalculate after material changes to quantity, warehouse, order status, requested date, purchase or transfer timing, allocation, or other included supply and demand. At minimum, calculate during order review and again before communicating a customer commitment when the earlier result may be stale.

Can ATP dates be sent to an e-commerce or EDI system?

They can be integrated only through an intentional interface design. Define the outbound field, date meaning, timezone, recalculation trigger, blank-date handling, change notifications, error behavior, and approval policy. Do not assume that enabling ATP automatically publishes its result to an external channel.

Back to TOC

Sources

1. Acumatica 2026 R2 release announcement
2. Acumatica release news and 2026 R2 overview
3. Introducing Acumatica Cloud ERP 2026 R2
4. Sales Orders SO301000 form reference for 2026 R2
5. Order Types SO201000 form reference for 2026 R2
6. Item Classes IN201000 form reference for 2026 R2
7. Enable or Disable Features CS100000 form reference for 2026 R2
8. Availability Calculation Rules IN201500 form reference for 2026 R2
9. Inventory Allocation Details IN402000 form reference for 2026 R2
10. Capable-to-Promise general information
11. Biz-Tech Acumatica Distribution ERP guide
12. Biz-Tech guide to PDF order automation and inventory allocation

Available-to-Promise can improve order-date decisions when the calculation rule, item classes, order types, warehouses, safety stock, and document dates reflect real operating policy. The next practical step is to choose one item family and one order type, reproduce a small set of supply-and-demand scenarios in a sandbox, and reconcile every date before expanding the rollout. Biz-Tech Services can help with Acumatica 2026 R2 configuration, integration review, test design, and distribution-process optimization through the Biz-Tech support and consultation page.

Back to TOC

---

by Gary

Faster Generic Inquiries in Acumatica 2026 R2: Grouped Tables, Query Design, and Dashboard Performance

Slow Generic Inquiries in Acumatica are usually improved by reducing the work performed by the base inquiry before changing how the results look. Start with the business question, select only the required data sources and fields, join tables on the correct keys, filter early, limit unnecessary totals and rows, and test with representative data. Acumatica 2026 R2 grouped table views can make results easier to explore, but they use an existing Generic Inquiry as their data source and do not automatically correct an inefficient query.

This guide explains how to diagnose Acumatica Generic Inquiry performance without sacrificing the meaning of the report. It covers Generic Inquiry design, 2026 R2 grouped table views, dashboard refresh behavior, benchmarking, reconciliation, deployment controls, and the point at which a workload belongs in a different reporting architecture. The intended audience includes Acumatica administrators, functional consultants, report designers, developers, SQL specialists, finance leaders, operations managers, and quality assurance teams.

Table of Contents

Why Generic Inquiry performance is a business issue

How an Acumatica Generic Inquiry processes data

What changed with grouped table views in 2026 R2

Why grouped tables do not replace query optimization

Define the business question before editing the inquiry

Build a performance baseline that can be repeated

Recognize the main Generic Inquiry performance patterns

Choose the smallest correct set of data sources

Design table relations without multiplying records

Use conditions and parameters to reduce the working set

Control displayed rows and page size deliberately

Sort only when the result requires an order

Group and aggregate without changing the metric

Manage formulas and calculated fields carefully

Configure grouped table views for useful analysis

Improve dashboard performance at the consumption layer

Treat nested Generic Inquiries as dependencies

Prevent duplicate and missing results

Use a disciplined before and after test method

Worked test case for open sales orders

Worked test case for grouped accounts payable analysis

Worked test case for an executive dashboard

Reconcile performance changes with business totals

Deploy Generic Inquiry changes safely

Monitor performance after release

Know when a Generic Inquiry is the wrong tool

Generic Inquiry performance review checklist

Frequently Asked Questions

Sources

Why Generic Inquiry performance is a business issue

A slow inquiry is not merely an inconvenient screen. The same Generic Inquiry can feed a list, export, pivot table, dashboard widget, integration, OData request, AI feature, or user workflow. A design that performs adequately for one analyst can become expensive when it is placed on a dashboard opened by many users or refreshed throughout the day.

The business impact also depends on when the inquiry runs. A ten-second inquiry opened once during a monthly review may be tolerable. The same inquiry used by an order desk after every customer call can delay work. If several dashboard widgets rely on broad inquiries and refresh at short intervals, the cumulative load may affect users who are entering orders, releasing documents, or reviewing inventory.

Performance therefore needs an explicit service expectation. The team should identify who uses the inquiry, how often it runs, how current the data must be, how many rows users actually need, and what decision depends on the result. Without that context, optimization often removes useful detail or shifts work to another part of the system.

A sound performance review protects two outcomes at the same time:

1. The inquiry returns quickly enough for its operational purpose.
2. The result still represents the correct business population, grain, and calculation.

The second condition is essential. A fast inquiry that omits valid documents, duplicates amounts, or changes the definition of an open order is not optimized. It is wrong.

Back to TOC

How an Acumatica Generic Inquiry processes data

An Acumatica Generic Inquiry is a configurable data request built on data access classes, commonly called DACs. The designer selects data sources, defines relations, applies conditions and parameters, specifies grouping and sorting, and chooses fields for the result grid. Acumatica then generates the request needed to retrieve and present the data. The official Creation of a Generic Inquiry documentation describes this sequence and emphasizes that the design depends on the organization's business needs.

It is useful to separate the work into four layers.

Business definition

This layer defines the question, population, grain, measures, and security. An inquiry may answer "Which sales orders are open" or "What is the total open order value by customer and week." Those are different questions. They require different rows, fields, grouping, and validation.

Query definition

This layer includes DAC selection, relations, conditions, parameters, formulas, grouping, sorting, and limits. Most material performance problems begin here because these settings determine how much data must be joined, filtered, calculated, sorted, and returned.

Presentation definition

This layer controls how users see the result. In 2026 R2 it can be a table, pivot table, or grouped table view. Presentation can reduce visual clutter and help users reach the right level of detail, but it cannot make an overbroad or incorrectly joined base inquiry logically correct.

Consumption pattern

This layer covers dashboards, exports, OData consumers, automations, and repeated interactive use. The same query design creates different total load depending on refresh intervals, user count, filters, and concurrency.

The distinction prevents a common mistake: changing a widget or grouped view while leaving the expensive base request untouched. Diagnose each layer, then change the lowest layer that actually causes the problem.

Back to TOC

What changed with grouped table views in 2026 R2

Acumatica 2026 R2 adds grouped table views as a formal data representation for Generic Inquiry results. A grouped table organizes records into an expandable hierarchy and can show summarized information together with underlying detail. According to Acumatica's Data Views General Information, the available representations are Table, Pivot Table, and Grouped Table.

The feature must be enabled through Grouped Table Views in Generic Inquiries on the Enable or Disable Features form, CS100000. Once enabled, users can create personal grouped views for inquiries they can access. Administrators can create shared views and can make an appropriate shared view the default for all users.

A grouped table can contain multiple group levels. Each level can have its own fields, sort order, aggregate values, and display settings. The details section can retain the underlying records, so a manager can start with a summary and expand a group when a total needs explanation. The official Grouped Table configuration guidance explains how to create and configure these views.

For example, an accounts payable inquiry can be grouped first by vendor and then by financial period. A group level can display total and average document amounts, while the details section retains individual bills and adjustments. Acumatica's grouped table activity uses this pattern to demonstrate a shared default view.

Grouped views can improve usability in several ways:

• Users can begin with summaries instead of scanning a flat result set.
• Multiple analytical views can reuse one governed inquiry.
• The underlying details remain available for investigation.
• Administrators can standardize a shared view for a role or process.
• Personal views let individual users organize the same governed data without cloning the inquiry.

These are meaningful improvements, especially where teams previously created several near-duplicate inquiries to present the same facts at different levels.

Back to TOC

Why grouped tables do not replace query optimization

A grouped table is a view of one Generic Inquiry's results. Acumatica states that each data view uses an existing Generic Inquiry as its data source and that the inquiry's parameters and filters apply to every representation. That means the grouped table and the base inquiry must be evaluated together.

If the underlying inquiry joins unnecessary DACs, returns years of history, calculates expensive formulas for every row, or multiplies records through an incorrect relation, a grouped presentation does not remove that work by definition. It may make the output easier to read, but the query still needs to produce the source data required by the view.

The practical rule is simple:

Use grouped table views to improve how people explore a correct, appropriately scoped inquiry. Optimize the base Generic Inquiry to reduce unnecessary data work.

This distinction also protects the business meaning of the result. Moving a metric into a grouped view may change where aggregation occurs. A detail inquiry grouped for display is not always equivalent to an inquiry designed to return one row per business entity. If a dashboard needs only one total, it may be better to build a narrowly scoped source inquiry than to return a large detail population and aggregate it later.

Before adopting a grouped table as a performance change, answer four questions:

1. Does the base inquiry return fewer rows or perform fewer calculations after the change?
2. Does the grouped view merely collapse rows visually, or does it change the data request?
3. Are the same filters and parameters applied in both the baseline and revised tests?
4. Do totals and distinct business keys reconcile at every group level?

If the first answer is no, describe the grouped table as a usability improvement rather than a query optimization.

Back to TOC

Define the business question before editing the inquiry

The fastest useful Generic Inquiry is the smallest correct request for a defined decision. Performance work should therefore begin with a one-sentence business question, not with the Generic Inquiry screen.

Consider the difference between these requests:

• List all open sales order lines.
• Show open sales order value by customer.
• Show orders ready to ship today by warehouse.
• Count overdue shipments for an executive dashboard.

The first request needs line-level detail. The second needs a customer-level measure and may not need every line field. The third needs operational filters and warehouse data. The fourth may need only a narrow population and a count. Reusing one broad inquiry for all four tasks is convenient during prototyping but can be expensive and difficult to validate.

Document the following before changing the design:

• Population: Which records qualify and which must be excluded.
• Grain: What one result row represents.
• Measures: Which amounts, quantities, counts, dates, or statuses matter.
• Dimensions: Which fields users need for grouping, filtering, or explanation.
• Freshness: How current the result must be.
• Audience: Who can see the data and who owns its definition.
• Consumption: Screen, dashboard, export, OData, automation, or another use.
• Acceptance criteria: Required totals, sample records, and response-time target.

This brief is also the basis for reconciliation. If the grain is "one row per sales order," the test must compare distinct orders, not only the number of result rows. If the measure is "open amount," the team must define how holds, cancellations, partial shipments, tax, currency, and released documents affect the total.

Back to TOC

Build a performance baseline that can be repeated

An optimization claim is credible only when the baseline and revised inquiry are tested under comparable conditions. Capture the baseline before editing the inquiry, even when the problem appears obvious.

Use a test tenant or controlled nonproduction environment with representative data. Record the Acumatica version and build, enabled features, database or hosting context, inquiry identifier, filters, user role, and relevant customization packages. Performance observed on a small demonstration dataset cannot predict a production tenant with several years of transactions and concurrent users.

For each test scenario, record:

• Time from request to usable result.
• Number of rows returned.
• Distinct count of the primary business key.
• Key totals or aggregates.
• Selected parameter values and filters.
• Whether record counts and totals were enabled.
• Records per page and Select Top settings.
• Dashboard refresh or cache setting when applicable.
• First-run and repeated-run behavior.
• Any server, database, or application evidence available to the responsible technical team.

Run each scenario more than once. A single result may be influenced by caching, competing activity, or network conditions. For operational comparison, use the same sequence of tests and report the median together with a slower percentile such as the 95th percentile when the sample size is sufficient. These are measurement practices, not Acumatica performance guarantees.

The baseline should include at least one typical case and one legitimate heavy case. A date range covering the current week may represent daily work, while a full financial year may represent period-end analysis. Do not benchmark an artificially narrow filter and then claim that the inquiry is fast for all users.

Back to TOC

Recognize the main Generic Inquiry performance patterns

Most slow Generic Inquiries fall into one or more recurring patterns. Recognizing the pattern helps the team avoid random changes.

Broad population

The inquiry loads far more records than the user needs. Common signs include no required date parameter, an all-branches default, historical closed documents mixed with current exceptions, or a dashboard widget that queries the full table to show one number.

Row multiplication

The result contains duplicate business entities or unexpectedly high totals because a one-to-many relation is joined at the wrong grain. Adding another detail table can multiply existing detail rows. A cross join is especially dangerous because the result size is the number of rows in one source multiplied by the number in the other, as the Generic Inquiry form reference explains.

Expensive presentation work

The inquiry returns many columns, sorts a large population, calculates formulas, loads record counts and totals, or requests an excessive page size. Each operation may be reasonable alone but costly in combination.

Repeated consumption

An inquiry that is acceptable interactively becomes expensive when several widgets, users, or integrations run it repeatedly. Very short dashboard refresh intervals can turn a modest query into a continuous workload.

Incorrect aggregation

The inquiry groups at one level but includes fields or formulas that imply another. The system may need to calculate more than expected, and the output may be misleading even if it loads quickly.

Nested complexity

One Generic Inquiry uses another as a data source, which may itself depend on additional inquiries. Reuse can improve governance, but deep or broad dependency chains make the total work harder to see and test.

Environmental contention

The inquiry design may be sound, but performance changes during imports, releases, integrations, backups, or other heavy activity. Query optimization alone cannot resolve capacity or scheduling problems. The baseline must capture when the slowdown occurs.

Back to TOC

Choose the smallest correct set of data sources

Every data source should have a stated purpose. If the inquiry only needs fields from a sales order header, adding line, shipment, invoice, customer location, and inventory DACs creates work and changes the possible grain. Remove a data source only after confirming that it is not required for a condition, parameter, formula, security rule, navigation link, or result field.

Acumatica's documentation recommends identifying the DACs and fields behind the relevant forms before creating an inquiry. The DAC Discovery guidance explains that users access database data through DACs and that the selected fields become result columns or inputs to the report design.

Use this review sequence:

1. Mark the parent business entity that defines one intended row.
2. List every output field and identify its source.
3. List every condition, parameter, formula, grouping field, and navigation field.
4. Remove fields that no consumer uses.
5. Identify data sources that remain only because of removed fields.
6. Retest the inquiry after each logically related change.

Selecting fewer result columns can improve network transfer and rendering, but the larger gain often comes from eliminating an unnecessary one-to-many source. If a field is needed only for drill-down, consider whether navigation to the source record can replace copying many descriptive columns into the result.

Do not select a base DAC solely because its name looks familiar. Inspect the form field, DAC schema, keys, and relationships. Acumatica documents that DAC key fields can be discovered through the schema browser and recommends key and foreign key fields for relations because they allow faster retrieval. See Discovery of Key Fields.

Back to TOC

Design table relations without multiplying records

Relations determine both performance and correctness. The designer must know the cardinality of each pair: one-to-one, one-to-many, or many-to-many. The order and type of joins also affect which records survive and how many rows the result contains.

Acumatica's multiple data sources documentation explains that sources are paired as parent and child, and the sequence of pairs determines how the system builds the combined data. The Related Tables dialog can propose relationships, but the designer remains responsible for confirming that the relation matches the business question.

Verify complete keys

Many Acumatica documents use composite keys. Joining only on a reference number while ignoring document type, company, branch, or another key component can connect unrelated records. Use the full logical relationship required by the DACs and business process.

Choose the join type intentionally

An inner join keeps only records with a match in both sources. A left join keeps every parent record and adds matching child data when available. Changing an inner join to a left join can recover missing parents, but it can also introduce null child fields. Changing a left join to an inner join may reduce rows while silently excluding valid business records.

Count at the intended grain

Suppose 100 sales orders average five lines and each line has two related allocation records. A header-to-line-to-allocation result can contain approximately 1,000 rows before other relationships are added. Counting rows would not count orders. Summing a header amount across those rows could multiply the value. The correct design depends on whether the intended grain is order, line, or allocation.

Avoid cross joins unless the business case requires them

A cross join combines every row from one source with every row from another. Even small sources can create a large result. Cross joins should be treated as a deliberate analytical operation with a bounded dataset, not a shortcut for an unresolved relationship.

Validate optional relationships

When child data is optional, test parents with no child, one child, and multiple children. This reveals both missing rows and multiplication. Keep a small set of known business records for regression testing after every relation change.

Back to TOC

Use conditions and parameters to reduce the working set

Conditions and parameters are among the most effective ways to reduce unnecessary work, but they serve different purposes. A condition defines what the inquiry includes by default. A parameter lets the user supply a value in the selection area and can narrow the result for a particular task.

Acumatica's condition configuration documentation shows how conditions combine fields, operators, values, parentheses, and And or Or logic. Treat the Boolean expression as code. A misplaced bracket or broad Or clause can change both performance and meaning.

Useful default conditions often include:

• Current or open status when the inquiry supports operational work.
• A bounded transaction date or financial period.
• A branch, company, warehouse, project, or customer scope appropriate to the audience.
• Exclusion of deleted, archived, voided, or completed records when those records do not serve the decision.
• A clear exception condition for dashboards designed for management by exception.

Parameters should reflect natural user decisions. A warehouse manager may choose warehouse and promised date. A controller may choose branch and financial period. Requiring a parameter can prevent accidental all-history requests, but it can also make an inquiry unusable for scheduled or integrated consumers. Confirm how every consumer supplies the parameter.

Avoid formulas around fields used for filtering when a direct comparison can express the same rule. A transformation applied to every candidate row may make the condition harder to evaluate efficiently. When date logic is needed, prefer bounded start and end values that preserve the intended time zone and business definition.

Test empty, default, typical, and extreme parameter values. A default that means "all" may defeat the performance objective. A default date based on the current day may be correct for one role and wrong for another. Record the default behavior in the inquiry's documentation and test plan.

Back to TOC

Control displayed rows and page size deliberately

The Interface Options settings on the Generic Inquiry form include Select Top and Records per Page. They affect how many records the user receives and sees, but they should not be used to hide an undefined population.

Acumatica's Number of Records Shown documentation states that Select Top limits the displayed result after the specified sort order is applied. It also warns that excessively large Select Top or Records per Page values can increase processing time and degrade server performance.

Use Select Top when the business question is genuinely about a ranked subset, such as the 50 oldest overdue shipments or the 25 largest open balances. Define an explicit sort that makes the subset deterministic. "Top 50" without a business order can return an unstable or meaningless selection.

Use Records per Page to support readable interaction. A larger page can reduce paging clicks but increases the amount rendered at once. Test the page size with the actual number and width of columns. A narrow inquiry with ten fields behaves differently from a result with dozens of wide calculated columns.

Acumatica 2026 R2 also exposes an option to disable record counts and totals. The form reference states that hiding the number of records or pages can make the associated inquiry load faster. This is appropriate when users do not need the count or footer totals for the decision. It is not appropriate when the count itself is the control being monitored.

Do not confuse display limits with data correctness. If a user exports data or a widget applies a separate aggregation, verify how the limit affects that consumer. Document any intentional truncation prominently enough that users do not treat a partial result as a complete population.

Back to TOC

Sort only when the result requires an order

Sorting is valuable when order conveys meaning, such as oldest first, largest variance first, or customer then document date. Sorting a large result by several fields also requires work, so each sort field should support a user task or a deterministic limit.

Acumatica's Sorting and Grouping documentation explains that the Sort Order tab defines the default order and that user-defined sorting can override it. When no explicit sort is defined, Acumatica uses a default order and shows a warning in the tab.

Review sorting with these questions:

• Does the user need the order, or is it decorative?
• Does Select Top depend on this order?
• Can the same business order be expressed with fewer fields?
• Is a text formula being sorted where a native date or numeric field would be clearer?
• Does a dashboard widget apply its own order or display only an aggregate?

Remove redundant sorts, but keep the fields required to make a limited result stable. For example, sorting by requested date alone may leave many ties. Adding a document key as a final sort can make the result repeatable without changing the primary business order.

Back to TOC

Group and aggregate without changing the metric

Grouping can reduce a detail population to one row per business dimension, but only when the selected aggregate functions match the field types and the intended measure. Acumatica supports AVG, COUNT, MAX, MIN, SUM, and STRINGAGG in the Generic Inquiry grouping configuration. The official grouping guidance notes that numeric fields default to SUM and other fields default to MAX when no aggregate is selected, while calculated fields require deliberate aggregate choices.

Start by writing the metric in plain language. "Open order value by customer" requires a definition of open order value and one output group per customer. If header amounts repeat across joined lines, summing the header amount after the join is wrong. The correct source may be a line amount, an already aggregated source inquiry, or a design that preserves one header row.

Pay close attention to these cases:

• COUNT versus distinct business entities: A row count after a detail join may count lines or allocations rather than documents.
• SUM of repeated header fields: The same order total can repeat for each child row.
• AVG after uneven duplication: Customers with more detail rows may receive unintended weight.
• MAX used as a placeholder: MAX can select one value from a group without proving that all rows share that value.
• STRINGAGG growth: Concatenating many values can create large strings that are hard to use and expensive to render.
• Null behavior: Aggregate functions may ignore null values, which can affect counts and averages.

Create reconciliation totals at both the overall and group level. If the inquiry groups by branch and customer class, validate a few known branches, then compare the grand total to an independent source. Do not accept a grand total alone because errors in different groups can offset one another.

Back to TOC

Manage formulas and calculated fields carefully

Formulas make Generic Inquiries flexible, but they can add per-row work and create subtle differences between detail and grouped results. Every formula should have an owner, a business definition, a data type, and a test set.

Use native fields when they already represent the required value. Recalculating status labels, dates, or amounts through nested expressions can make the inquiry harder to maintain and may prevent straightforward filtering or grouping. When a formula is necessary, keep it as simple as the rule allows and avoid repeating the same expression across several result fields.

Test formula behavior for:

• Null values and empty strings.
• Zero denominators.
• Currency and unit conversions.
• Time zones and date boundaries.
• Negative values and credit documents.
• Rounding before and after aggregation.
• Text values stored differently from their displayed labels.
• Grouped results where the formula references a nonaggregated field.

Acumatica's grouping documentation warns that the aggregate function must match the field type and that calculated columns need a manually selected aggregate because no single default works for every formula. A runtime error is visible; a logically wrong aggregate is more dangerous because it can look plausible.

If a formula is used only for display styling, determine whether the style is worth the cost on a large result. If it drives a condition or business decision, include it in the reconciliation evidence. Formula changes should be treated as calculation changes, not cosmetic edits.

Back to TOC

Configure grouped table views for useful analysis

A grouped table should reflect how users investigate a question. More hierarchy is not automatically better. Deep groups create extra navigation and can hide the level at which a total is defined.

Use this configuration sequence:

1. Select a base inquiry with a documented grain and validated totals.
2. Choose the first group that matches the user's primary decision, such as vendor, customer, warehouse, project, or branch.
3. Add a second group only when it supports a common drill path, such as financial period within vendor.
4. Select aggregate fields that reconcile to the base inquiry.
5. Choose a meaningful sort within each group.
6. Decide which groups open expanded or collapsed based on typical result size.
7. Show only fields needed at each level.
8. Test personal, shared, and default behavior with appropriate roles.

The grouped view should not become a substitute for a clearly scoped base inquiry. If users always filter to the current month, put that requirement in a parameter or shared filter. If executives need only a total and an exception count, a dedicated summary inquiry may be more appropriate than a detailed grouped view.

When making a shared view the default for all users, consider whether every role interprets the groups the same way. A controller may start with branch and period, while an operations manager may start with warehouse and promised date. Separate views can reuse the same inquiry when the underlying data and security are genuinely shared.

Validate the view on the expected screen width and with long labels, empty groups, negative totals, and large groups. A technically correct hierarchy can still be slow to use if users must expand many nodes or scroll across unnecessary columns.

Back to TOC

Improve dashboard performance at the consumption layer

Dashboard performance depends on the source inquiry, the number of widgets, filters, parameters, refresh intervals, and user behavior. Acumatica's Table Widgets documentation confirms that data table widgets display data collected by a Generic Inquiry. KPI widgets also select a source inquiry and aggregate a chosen field.

Start by inventorying every widget on the dashboard. Record its source inquiry, filter, parameters, displayed fields, record limit, aggregate function, and refresh setting. Two widgets that appear simple may each run a broad inquiry independently.

Match refresh intervals to business freshness

Acumatica allows widget caching and refresh intervals. The Widget Settings documentation explains that cached data is reused when it is newer than the configured interval. Selecting On Page Reload disables that reuse and updates data whenever the dashboard opens or refreshes.

Use the longest interval that still supports the decision. A weekly trend does not need a five-minute refresh. An order exception widget may need fresher data, but it should also use narrow conditions. Document the expected delay so users know whether the dashboard is current to five minutes, an hour, or a day.

Give each widget a bounded question

A scorecard should not rely on a detail inquiry that returns many unused columns. A table widget should have a reasonable record limit and should show only actionable rows. Shared filters and dashboard parameters can narrow data, but the source inquiry still needs a safe default.

Reduce simultaneous work

Remove duplicate widgets, consolidate overlapping metrics when the design remains understandable, and avoid placing every available chart on a home page. A dashboard used by hundreds of users creates a different workload from a specialist dashboard opened occasionally.

Test the dashboard as a dashboard

An inquiry tested alone may perform differently when several widgets load together. Measure the complete page, observe which widget finishes last, and test with the relevant user role. Include cache-expired and cache-valid scenarios.

For a broader view of how reporting, dashboards, and AI features fit into the current platform, see Biz-Tech's Acumatica Agentic ERP 2026 guide. Treat each feature as a consumer of governed data, not as a reason to expose a broad inquiry without controls.

Back to TOC

Treat nested Generic Inquiries as dependencies

Acumatica 2026 R2 allows a Generic Inquiry to use another Generic Inquiry as a data source. The official Generic Inquiry as Data Source documentation states that multiple simple inquiries can be combined into a more complex request and that the system prevents circular parent relationships.

This reuse can improve governance. A validated base inquiry can define a shared fact set, and several parent inquiries can apply different presentation or business rules. It can also hide complexity if the dependency chain is not documented.

For every nested source, record:

• Source inquiry title and identifier.
• Intended grain and population.
• Parameters and defaults.
• Fields exposed to the parent.
• Parent inquiries and widgets that depend on it.
• Owner and last validation date.
• Expected performance range for representative inputs.

Avoid nesting merely to avoid understanding the underlying DACs. Each level should provide a stable, reusable contract. If a child inquiry returns more fields or rows than the parent needs, consider a narrower source. If several parents independently apply the same corrective filters, the shared source definition may be incomplete.

When changing a source inquiry, test every known parent. Acumatica can warn about deleted source fields, but it cannot determine whether a retained field now has a different business meaning. Dependency testing must cover totals, sample records, filters, navigation, exports, and performance.

Back to TOC

Prevent duplicate and missing results

Performance tuning often changes relations and filters, the same settings that determine which records appear. Build correctness tests before making those changes.

Use a controlled sample that includes:

• A parent with no child record.
• A parent with one child.
• A parent with several children.
• Two document types that share a reference number pattern.
• Records across branches or companies where relevant.
• A null optional value.
• A closed or voided record near the filter boundary.
• A record exactly on the start and end date.
• A negative or credit amount.
• A record the test user cannot access.

Then validate several dimensions of the output.

Population completeness

Confirm that qualifying business entities appear and excluded entities do not. Compare known document keys, not only row counts.

Grain integrity

Confirm what one row represents after each join. If the intended grain is order line, use a composite key that identifies the line. Check for duplicate keys.

Measure reconciliation

Compare counts, quantities, and amounts with a trusted form, report, or independently validated query. State whether the source uses document currency, base currency, signed amounts, or another convention.

Security behavior

Run the inquiry as representative roles. An administrator's correct result does not prove that a restricted user sees the right population or that the inquiry avoids exposing sensitive fields.

Boundary behavior

Test dates, periods, statuses, and amounts exactly at the condition boundary. A greater-than condition and a greater-than-or-equal condition can produce different operational lists.

Do not accept a faster result until these tests pass. Performance and correctness are one release decision.

Back to TOC

Use a disciplined before and after test method

The purpose of before-and-after testing is to isolate the effect of a specific design change while preserving the business result. Use one change set at a time whenever practical.

Prepare the test

Copy the inquiry rather than overwriting the only working version. Freeze the test data or record the data snapshot time. Use the same user, role, parameters, browser path, and environment. Identify any integrations or batch processes that could distort the run.

Run the baseline

Execute the original inquiry several times for each scenario. Record usable response time, row count, distinct key count, totals, and errors. For dashboard cases, record complete dashboard load time and individual widget behavior where visible.

Apply one coherent change

Examples include correcting one relation, adding a required date parameter, removing an unused detail DAC, changing an excessive page size, disabling unused counts, or adjusting one widget refresh interval. Avoid combining many unrelated changes in the first comparison because the team will not know which change mattered.

Run the revised test

Repeat the same sequence. Compare the distribution of times, not only the fastest run. Confirm that the result has the same intended population and measures. If the change intentionally alters the population, document the new definition and validate it as a functional change.

Decide with evidence

Promote the change only when it improves the relevant user experience or resource use and passes reconciliation. A small speed difference may not justify added complexity. A major improvement that changes totals requires correction before release.

Maintain a compact evidence record containing the inquiry versions, settings changed, test cases, results, reconciliation, reviewer names, and approval. This makes later regression diagnosis much faster.

Back to TOC

Worked test case for open sales orders

This test case illustrates the method without claiming a universal performance result. Actual timing must come from the customer's build, dataset, hosting model, customizations, security role, and workload.

Business question

Which open sales orders require attention for a selected warehouse and promised-date range, with one row per sales order line?

Common slow design

The inquiry defaults to all warehouses and all dates. It joins order header, order line, allocation, shipment, customer, address, and inventory sources even though the operational list needs only order, line, customer name, warehouse, promised date, quantity, and status. Several wide description fields are returned. The result is sorted by customer name, order date, inventory description, and reference number. Records per Page is set to a very large value.

Review plan

First, confirm the required grain is one order line. Then identify which joins create multiple rows per line. Make warehouse and date-range parameters part of the normal workflow. Remove sources and columns that do not support the list, filters, navigation, or security. Keep a deterministic sort based on promised date and document keys. Select a usable page size.

Correctness controls

Use known orders with no allocation, one allocation, and multiple allocations. Confirm that the line quantity is not multiplied. Reconcile distinct order and line keys. Check orders exactly on the date boundaries and orders with partial shipment activity. Compare the population to the source sales order form using the same definition of open.

Performance evidence

Run the original and revised inquiries with the same warehouse and date range. Record repeated response times, returned rows, distinct line keys, and totals. Then test the legitimate heavy case, such as a broader date range used during backlog review. The revised inquiry is accepted only if both cases remain correct and the operational case improves meaningfully.

Expected design lesson

The likely improvement comes from scoping the population and removing unnecessary relational work, not from hiding rows after retrieval. The exact benefit cannot be promised before testing.

Back to TOC

Worked test case for grouped accounts payable analysis

This scenario uses the 2026 R2 grouped table capability for its intended analytical purpose.

Business question

Show accounts payable documents by vendor and financial period, with total and average document amount at the period level and access to individual documents for explanation.

Base inquiry requirements

The base inquiry must return the correct AP document population with a documented grain. It should include the vendor, financial period, document key, document date, status, and amount fields required by the grouped view. Conditions should define whether released, open, voided, and adjustment documents are included.

Grouped view design

Create a grouped table view with vendor as the first level and financial period as the second. Add total amount and average amount at the period level. Keep document details available beneath the group. Choose whether groups open collapsed based on the typical vendor and period count. An administrator may create a shared default view if this hierarchy suits the audience.

Performance interpretation

The grouped view may help users reach summaries without scanning a flat list. Do not state that it makes the base query faster unless the measured request changes. Compare the base table and grouped view with the same parameters, and separately measure user task completion if usability is the objective.

Correctness controls

Reconcile each vendor-period total to the base inquiry and to an accepted AP source. Check vendors with credit adjustments, multiple currencies, null optional fields, and no activity in a period. Confirm that the average uses the intended document population and that null values are handled as expected.

Expected design lesson

Grouped table views can replace cloned presentation inquiries when one validated source supports several useful hierarchies. Their strongest benefit is governed exploration, while query efficiency still depends on the base inquiry.

Back to TOC

Worked test case for an executive dashboard

Executive dashboards often reveal consumption problems because several broad queries run together.

Business question

Show the count and value of overdue shipments, the value of open orders, and a short list of the oldest exceptions, with data fresh enough for daily management.

Common slow design

Three widgets use broad detail inquiries. Each loads on every page refresh. The scorecards aggregate columns from inquiries that return many unused fields. The exception table shows hundreds of rows even though leaders act on the oldest twenty. The dashboard is set as a home page for a large user group.

Review plan

Define a narrow source for each distinct metric or a carefully governed shared source when the population is identical. Apply default exception conditions. Use only the fields required for the widget. Give the table an intentional record limit and sort. Set refresh intervals according to business freshness rather than defaulting every widget to On Page Reload.

Correctness controls

Reconcile the scorecard counts and values to the underlying exception population. Verify that the table's top records correspond to the defined order. Test with the roles that receive the dashboard. Confirm the timestamp and refresh expectation are understandable to users.

Performance evidence

Measure the dashboard after cached data has expired and again while the cache remains valid. Record full page readiness and identify any widget that lags. Test concurrent access appropriate to the user population when the environment and responsible technical team support it.

Expected design lesson

Dashboard performance is a system of query scope, widget count, caching, refresh intervals, and audience size. Improving only the visual layout does not address repeated database work.

Back to TOC

Reconcile performance changes with business totals

Reconciliation turns a technical optimization into an auditable business change. It should be designed before the test, not added after a discrepancy appears.

Use three levels of reconciliation.

Record reconciliation

Compare known business keys between original, revised, and trusted sources. Explain every missing or added key. For large populations, use counts and automated comparisons, then inspect a risk-based sample.

Aggregate reconciliation

Compare counts, quantities, and amounts overall and by meaningful groups. Useful groups include branch, warehouse, status, period, document type, customer class, and currency. Group-level comparison identifies offsetting errors that a grand total can hide.

Rule reconciliation

Verify that each condition implements the written business rule. A status label may combine several stored values. A date may represent order date, requested date, shipment date, or financial period. A balance may be in document or base currency. Document the rule beside the test evidence.

Set acceptance tolerances deliberately. Record counts and discrete document totals usually require exact agreement. Calculated currency amounts may require a defined rounding tolerance. Response times require a target range and sample size rather than one perfect run.

When totals differ, stop and classify the difference:

• The original inquiry was wrong and the revised result corrects it.
• The revised inquiry introduced a defect.
• The business definition changed.
• The test data changed between runs.
• Security or parameters differed.
• Rounding, null handling, or aggregation changed.

Do not average these causes into a vague explanation. Resolve and approve the specific difference.

Back to TOC

Deploy Generic Inquiry changes safely

Generic Inquiries can become infrastructure. They may support dashboards, exports, integration endpoints, automation, AI features, and user navigation. A change that looks local can affect several consumers.

Use a controlled deployment process:

1. Copy or export the current inquiry and dependent views before modification.
2. Record the inquiry identifier, site map location, access rights, and consumers.
3. Make and test the change in a nonproduction environment with representative data.
4. Run functional, reconciliation, performance, and security tests.
5. Review dependent dashboards, pivot tables, grouped views, OData consumers, and nested inquiries.
6. Schedule the release when rollback and observation are practical.
7. Recheck parameters, filters, roles, shared views, and default views after deployment.
8. Monitor response time, errors, totals, and user-reported differences.

Acumatica's 2026 R2 release introduces wider platform changes beyond grouped tables. If the inquiry work is part of an upgrade, coordinate it with the broader readiness plan in Biz-Tech's Acumatica 2026 R2 Upgrade Guide. Version, feature enablement, Modern UI behavior, customizations, and connected products can all affect the test scope.

Avoid editing a predefined inquiry directly when a copy is the safer governance choice. Use clear naming and descriptions so users can distinguish the supported version. Retire obsolete copies after confirming no consumer depends on them; otherwise, near-duplicate inquiries create confusion and inconsistent totals.

Back to TOC

Monitor performance after release

Performance changes as transaction volume, retention, user count, dashboards, and integrations grow. A passing implementation test is not permanent evidence.

Create a small monitoring record for important inquiries:

• Inquiry owner and business owner.
• Purpose and intended grain.
• Major consumers.
• Representative parameter scenarios.
• Expected row-count range.
• Expected response-time range.
• Key reconciliation totals.
• Last test date and Acumatica build.
• Known seasonal or period-end load.

Review the inquiry after upgrades, large data migrations, new customizations, dashboard changes, or material growth in transaction volume. Also review it when users compensate for slowness by exporting data, widening default filters, duplicating inquiries, or building spreadsheets. Those workarounds often signal that the existing design no longer supports the decision.

Track performance at the user task level. A query may become slightly faster while the user needs more manual filters or additional screens. Measure time to a usable answer, not only server response. For dashboards, include cache behavior and the number of widgets. For exports, include row volume and downstream processing.

Keep freshness honest. Update the article, inquiry documentation, and test evidence when behavior changes; do not change dates merely to imply current validation.

Back to TOC

Know when a Generic Inquiry is the wrong tool

Generic Inquiries are well suited to operational lists, governed exploration, dashboard sources, exports, navigation, and many integration or automation scenarios. They are not the best architecture for every analytical workload.

Consider another approach when the requirement involves:

• Very large historical datasets scanned repeatedly.
• Complex transformations across many fact tables.
• Heavy concurrency that competes with transactional processing.
• Long-running trend analysis with stable periodic snapshots.
• A semantic model shared across many external BI reports.
• Calculations that require extensive preprocessing.
• Regulatory reporting that needs a fixed, formally controlled output.
• A dashboard that needs data at a different refresh and storage pattern from live transactions.

Possible alternatives include a dedicated summary inquiry, a pivot table, an Acumatica report, Analytical Report Manager for the appropriate financial use, an external BI model, or a governed data warehouse. The correct choice depends on the required grain, latency, volume, auditability, and user interaction.

Do not move a workload merely because it is slow. First determine whether the inquiry is poorly scoped. Conversely, do not keep adding conditions and indexes to force an operational query tool to serve a warehouse-scale analytical problem.

Biz-Tech's overview of Acumatica Cloud ERP reporting and dashboards provides broader context for selecting reporting surfaces. Where teams need help turning business questions into governed inquiries, Biz-Tech's AI Analyst describes a review-first approach to creating and refining Generic Inquiries and related reporting assets. Product suitability, availability, licensing, and implementation scope should be confirmed for the customer's environment.

Back to TOC

Generic Inquiry performance review checklist

Use this checklist before approving a new or revised inquiry.

Business definition

• The question, audience, decision, and freshness requirement are written.
• The intended population and one-row grain are explicit.
• Counts, amounts, quantities, and dates have documented meanings.
• The business owner approves the definition.

Data design

• Every DAC and result field has a purpose.
• Relations use the complete logical keys.
• Join types preserve the intended population.
• One-to-many relationships do not duplicate measures.
• Cross joins are absent unless explicitly required and bounded.
• Nested inquiry dependencies are documented.

Filtering and limits

• Default conditions match the operational population.
• Parameters prevent accidental broad requests where appropriate.
• Empty and extreme parameter values are tested.
• Select Top has a deterministic sort and a business reason.
• Records per Page is usable and not excessive.
• Record counts and totals are enabled only when needed.

Calculation and presentation

• Aggregate functions match field types and metric definitions.
• Formulas handle nulls, zero, dates, currency, units, and rounding.
• Grouped views reflect the user's drill path.
• The grouped view is not described as a query improvement without evidence.
• Dashboard widgets use appropriate fields, filters, limits, and refresh intervals.

Testing

• The baseline and revised tests use the same environment and inputs.
• Typical and legitimate heavy scenarios are included.
• Repeated timings are recorded.
• Row counts, distinct keys, group totals, and grand totals reconcile.
• Representative user roles are tested.
• Dependent dashboards, exports, nested inquiries, and integrations are checked.

Release and monitoring

• The original design can be restored.
• Owners and dependent consumers are recorded.
• The deployment window allows observation and rollback.
• Post-release response time and totals are reviewed.
• The next review trigger is defined.

Back to TOC

Frequently Asked Questions

What is an Acumatica Generic Inquiry

An Acumatica Generic Inquiry is a configurable way to retrieve and display ERP data through data access classes without writing a conventional report for every question. Designers choose data sources, relations, conditions, parameters, grouping, sorting, and result fields on the Generic Inquiry form, SM208000. The inquiry can also serve dashboards, exports, navigation, integrations, and other governed consumers.

Why is my Acumatica Generic Inquiry slow

The most common causes are an overbroad population, unnecessary data sources, incomplete or multiplying joins, excessive formulas or sorting, very large page settings, record counts that are not needed, nested inquiry complexity, or repeated dashboard refreshes. Measure the inquiry with representative parameters and data before changing it because environmental contention can produce similar symptoms.

Do grouped table views make Generic Inquiries faster in 2026 R2

Not automatically. A grouped table organizes the results of an existing Generic Inquiry into a hierarchy with summaries and details. It can improve analysis and reduce the need for cloned presentation inquiries, but the underlying query still needs correct sources, joins, filters, calculations, and limits. Claim a speed improvement only after comparable testing.

How should I optimize joins in an Acumatica Generic Inquiry

Begin with the intended row grain, then use the complete key and foreign key fields that represent each relationship. Confirm whether each join is one-to-one or one-to-many and choose inner or outer behavior intentionally. Test parents with zero, one, and multiple children, then reconcile distinct business keys and totals to detect multiplication or missing records.

Should I use Select Top to improve Generic Inquiry performance

Use Select Top when the business question genuinely requires a ranked subset and define an explicit sort that makes the result deterministic. Do not use it to conceal an undefined or incorrect population. Verify how the limit affects exports, dashboard aggregations, and other consumers, and make any intentional truncation clear to users.

Can Records per Page be set very high

It can, but Acumatica warns that excessively large Select Top or Records per Page values can increase processing time and degrade server performance. Choose a page size that supports the user's task and test it with the actual number and width of columns. A large page is not a substitute for useful filters or parameters.

How do dashboard refresh settings affect Generic Inquiry load

Dashboard widgets can cache results for a configured interval. If On Page Reload is selected, the widget updates whenever the dashboard opens or refreshes. Frequent refreshes across many users and widgets can repeatedly execute source inquiries. Match each interval to the business freshness requirement and test the complete dashboard after cached data expires.

How do I test a Generic Inquiry optimization

Copy the inquiry, record the environment and parameters, run the original several times, and capture response time, rows, distinct keys, and totals. Apply one coherent change, repeat the same tests, and reconcile the output. Include both typical and legitimate heavy cases. Do not publish a fixed improvement percentage from another tenant's dataset.

How can I prevent duplicate totals in grouped results

Define the metric and row grain before grouping. Check whether header values repeat across joined detail rows, use the appropriate source field and aggregate, and compare distinct document keys. Reconcile totals by several business dimensions, not only at the grand-total level, because errors in separate groups can offset each other.

When should I replace a Generic Inquiry with another reporting tool

Consider another architecture when the workload repeatedly scans very large history, requires complex transformations, supports heavy analytical concurrency, or needs a governed semantic model and periodic snapshots. First correct any avoidable query-design problems. Then compare a summary inquiry, pivot, formal report, external BI model, or data warehouse against the required volume, latency, auditability, and user experience.

Back to TOC

Sources

1. Acumatica 2026 R2 Reporting Tools Guide
2. Creation of a Generic Inquiry General Information
3. Generic Inquiry Form Reference SM208000
4. Data Views General Information
5. Data Views Creating and Configuring Grouped Tables
6. Modification of Inquiry Results The Number of Records Shown
7. Data from Multiple Data Sources General Information
8. Data from Multiple Data Sources Discovery of Key Fields
9. Sorting and Grouping General Information
10. Widget Settings General Information
11. Specific Widgets Table Widgets
12. Specific Widgets KPI Widgets

Biz-Tech Services can help Acumatica teams review slow Generic Inquiries, validate joins and totals, tune dashboard consumption, and choose the appropriate reporting architecture. A reporting performance review should begin with representative data, documented business definitions, and measurable acceptance criteria rather than a promised universal speed increase.

Back to TOC

 

---

by Gary

Acumatica Modern UI Performance Troubleshooting After an Upgrade

Prepared for Biz-Tech Services | Last verified 19 October 2026

A five-layer diagnostic sequence for measurable Acumatica Modern UI troubleshooting.

When Acumatica Modern UI feels slow after an upgrade, do not begin by tuning SQL, disabling customizations, or blaming the browser. First reproduce one business task, determine whether the slowdown affects one user, one screen, or the whole site, and compare browser timing with Acumatica Request Profiler data. That sequence separates client and network delay from application-server, Generic Inquiry, customization, and database causes.

The key is to diagnose a transaction rather than a feeling. “The system is slow” cannot be tested. “Opening Sales Orders as the warehouse supervisor takes 11 seconds on the first load and 8 seconds on a warm repeat, while other users complete it in 3 seconds” gives the team a screen, role, browser, data state, timing, and comparison point.

This guide provides a repeatable diagnostic sequence for Acumatica 2026 R1 and 2026 R2 environments. Test every conclusion against the exact build, database, customizations, roles, and data volumes used by your organization. Community reports can help identify questions to investigate, but they do not establish the cause in your tenant.

What counts as an Acumatica Modern UI performance problem?

An Acumatica Modern UI performance problem is a repeatable delay in a defined user task, request, inquiry, or process compared with an accepted baseline. The delay may come from the browser, network, application server, database, Generic Inquiry design, customization code, automation, or the number of interactions required to finish the task.

That last distinction matters. A page can return quickly while users still need more clicks or pointer movement than before. Conversely, a workflow can feel familiar while a server request, SQL statement, or integration call is taking too long. Measure both technical response time and task completion time when the complaint concerns productivity.

Acumatica's official troubleshooting guide begins with the same scope distinction: either the whole site is slow or a particular process is slow. It then moves through basic causes, application-versus-database time, server configuration, database checks, additional evidence collection, and support escalation. [1]

Start with four classification questions

Before collecting a large trace, answer four questions:

1. What exact action is slow? Name the screen, action, record, filters, and expected result.

2. How wide is the impact? One user, one role, one location, one browser, one screen, or the whole site?

3. When does it happen? First load only, every repetition, certain data volumes, a scheduled period, or under concurrency?

4. What changed? Acumatica build, browser, customization package, Generic Inquiry, database, infrastructure, integration, role, or data volume?

Run the same transaction at least three times. Record the first result separately because cold browser assets, application caches, database caches, or freshly started services can make the first run different from warm repeats. Use the same record and filters where possible, and do not compare an administrator's broad access with a production role unless role differences are part of the test.

The five-layer diagnostic sequence

1. Reproduce the user task and capture browser evidence

Open the browser's developer tools before reproducing the issue. On the Network panel, preserve the log, capture the slow action, and note the request with the longest elapsed time. Record whether the wait is primarily before the request starts, during connection and transfer, or while waiting for the server response. Acumatica's Modern UI uses web technologies and request-based communication that browser development tools can inspect. [2]

Repeat in another supported browser or a clean browser profile. If the problem occurs only in one profile, examine extensions, cached assets, local storage, security software, and browser policy. If it occurs only from one location, compare latency, VPN path, proxy, DNS, packet loss, and bandwidth. Acumatica's official first-step guidance explicitly recommends comparing browsers and physical locations before moving deeper into the stack. [1]

Do not stop when clearing cache appears to help once. Retest the same task after the browser and server are warm. A cache reset can remove stale assets, but it can also create a slower first load and hide an intermittent problem.

2. Compare browser time with Acumatica Request Profiler

Use Request Profiler (SM205070) to determine whether Acumatica spent the time on the server. For a particular process, open Settings > Profiler, start logging, reproduce only the target transaction, stop logging, and export the profile. The exported ZIP can include URL requests, SQL activity, exceptions, warnings, errors, and stack details needed for analysis or support. [3]

Compare three values:

Measurement	What it tells you	Likely next owner
Browser elapsed time is high, profiler server time is low	Delay is outside most Acumatica server processing	Browser, endpoint security, proxy, VPN, or network owner
Profiler server time is high, SQL time is low	Application logic, customization, external call, serialization, or server capacity may dominate	Acumatica administrator or developer
SQL time is a large share of server time	Query design, blocking, indexing, statistics, plan choice, or database capacity needs review	SQL specialist with Acumatica context
Both timings are reasonable but the task is slow	Interaction design, navigation, or repeated manual steps may be the issue	Process owner and Modern UI specialist

Request Profiler has default thresholds for automatic monitoring, including 20 seconds for certain screen, Generic Inquiry, and report requests and 60 seconds for other requests. Those values are logging defaults, not promises of acceptable performance. Your baseline must reflect the business task and environment. [3]

3. Isolate Generic Inquiry and customization cost

If the slow screen, selector, dashboard, AI data source, or export depends on a Generic Inquiry, reproduce it with the exact role, filters, parameters, sorting, and row volume. A GI that is quick for a narrow test may become expensive when a condition is removed, a calculated field is added, a join multiplies rows, or a user exports the complete result.

Capture the inquiry name, parameters, returned row count, total browser time, Request Profiler server time, and SQL time. Then test one controlled change at a time. Narrow the date range, remove a nonessential calculated field, simplify sorting, or replace a broad join only in a sandbox. Keep the result set logically equivalent before calling the change an optimization.

For a suspected customization, compare the same action before and after unpublishing the specific project in a safe environment. Acumatica's troubleshooting guidance recommends profiling the action without the suspected project, publishing it again, repeating the same action, and comparing results. [1] A clean-system test does not prove that every customization is faulty; it identifies whether the measured cost changes when a defined package is present.

Check more than custom business logic. Modern UI customization problems can involve client-side code, generated files, build errors, stale assets, screen definitions, or API calls. Review browser console errors and the customization build output alongside server traces. If a customization calls an external service, time that dependency separately so a slow remote response is not mislabeled as database latency.

4. Investigate database and environment causes

When SQL consumes a material part of the slow request, capture the exact query context before changing indexes. Review blocking, long-running statements, execution plans, resource pressure, storage latency, database growth, statistics, and maintenance history. Acumatica's official sequence includes SQL Server configuration and reports or the corresponding MySQL checks after application-server analysis. [1]

Also inspect the environment around the transaction:

• running processes and automation schedules;
• System Monitor activity and unusually long jobs;
• application-pool memory and recent recycling;
• CPU, memory, disk latency, and database-server pressure;
• antivirus or endpoint scanning on application paths;
• license or concurrency conditions where relevant;
• integrations or imports running during the same period.

Correlate timestamps. A request that slows at 10:00 every morning may coincide with automation, backups, reporting, virus scanning, or an integration batch. Evidence from different clocks is hard to compare, so record the time zone and ensure application, database, monitoring, and workstation clocks are aligned.

5. Decide whether to optimize, patch, or escalate

Optimize when the evidence identifies a repeatable design cost that your team owns: an overbroad GI, an inefficient customization, unnecessary external calls, a poorly scheduled process, or an environment bottleneck. Make one change, rerun the same test, and record both the performance difference and functional result.

Patch when the behavior matches a documented defect for the exact Acumatica build and the release guidance identifies a corrected build. Validate the patch in a production-like sandbox with the same workflow, role, data, and customizations. “A newer build exists” is not enough evidence by itself.

Escalate when the problem is reproducible but the available evidence does not isolate an owned component, or when the trace points to platform behavior that requires Acumatica Support. Submit a focused case with the build, deployment model, timestamps, screen ID, steps, role, browser, profile export, logs, data scope, business impact, recent changes, comparisons, and tests already completed. This follows Acumatica's documented sequence: collect Request Profiler and log evidence before opening the support case. [1] [3]

The first five measurements to capture

If time is limited, collect these five measurements before changing anything:

1. Business-task duration: start-to-finish time for one named task, including the record and filters used.

2. Browser request duration: the slowest relevant request from the Network panel, plus a HAR file when permitted by security policy.

3. Request Profiler server and SQL time: captured during the same reproduction window.

4. Scope comparison: same task from another supported browser, user or role, and location.

5. Environment context: build number, customization packages, dataset size or row count, concurrent jobs, and timestamp.

Together, these measurements prevent three common mistakes: treating a local browser issue as a database problem, tuning SQL for time spent in application or external code, and escalating without a reproducible transaction.

Acumatica performance evidence worksheet

Use one row per controlled test. Attach the exported files separately rather than pasting sensitive data into the worksheet.

Field	What to record
Business task	Screen ID, action, record, filters, expected result
Impact	Users, roles, locations, and frequency affected
Environment	Acumatica version and build, deployment, app and database topology
Client	Browser/version, device, extensions, VPN/proxy, location
Change history	Upgrade, patch, customization, GI, browser, infrastructure, or data change
Test controls	Same data, same role, cold or warm run, repetition count
User timing	Total task-completion time for each run
Browser timing	Slow request URL or operation, status, waiting and transfer time
Profiler timing	Total server time, SQL time, memory, exceptions, relevant trace rows
Database evidence	Blocking, long query, plan, resource or storage observation
Comparison	Baseline environment, alternate browser/location, customization on/off
Result	Confirmed layer, rejected hypotheses, next owner and next test
Attachments	HAR, profiler ZIP, logs, screenshots, query plan, monitoring export

Sanitize customer names, personal data, credentials, tokens, and business-sensitive values before sharing evidence outside the authorized team. First-chance exception logging and other verbose diagnostics should be enabled only for the short period needed because the output can grow quickly. [1]

Build a reliable performance baseline before troubleshooting

A performance baseline is a documented range for a repeatable business task under known conditions. It is more useful than a single target such as “every screen must load in two seconds” because different Acumatica actions perform different amounts of work. Opening a maintained customer record, calculating a large inquiry, releasing a batch, and exporting thousands of rows should not be evaluated as if they were the same transaction.

Begin with ten to twenty tasks that represent the work people depend on most. Include the actions that affect cash, fulfillment, production, customer service, purchasing, project billing, and financial close. For each task, record the screen ID, role, data volume, record state, filter set, browser, location, build, and number of concurrent users or processes. A useful baseline is specific enough that another analyst can reproduce it without asking what the original tester meant.

Measure the full task from the user's perspective and the important requests inside it. Total task time shows whether the employee can complete the work efficiently. Browser and Request Profiler timings show which technical layer contributed to the wait. Retain both because an improvement in one request may not reduce the number of steps, and a shorter task may hide an expensive background call.

Use a small series rather than one run. A practical starting point is one cold run followed by at least three warm runs. Record every value instead of keeping only the fastest result. The median warm time describes the typical experience better than a best-case number, while the slowest valid run helps reveal intermittent blocking, network variation, or competing jobs. Do not combine failed tests, different records, or changed filters into the same comparison.

Define the acceptable range with the process owner. The threshold should reflect the business consequence of the delay, the normal data volume, the frequency of the action, and the technical work involved. A two-second increase on an action performed hundreds of times per day can matter more than a longer delay on a monthly report. The baseline therefore connects technology measurements to operational cost.

Baseline element	Minimum definition	Why it matters
Task identity	Screen ID, action, record state, filters, expected result	Prevents unlike transactions from being compared
User context	Role, branch, company, locale, and relevant preferences	Security and configuration can change the work performed
Data context	Row count, date range, document size, and related history	Performance often changes with scale
Client context	Browser/version, device, location, VPN or proxy path	Separates client and network effects
Server context	Build, topology, packages, integrations, and scheduled activity	Makes the test environment reproducible
Timing method	Cold or warm run, start and stop points, repetition count	Keeps measurements consistent
Acceptance rule	Expected range, warning level, owner, and review date	Converts evidence into a decision

Acumatica performance baseline: A useful baseline is a versioned record of how long a defined business task and its principal requests take under repeatable conditions. It must identify the build, role, data, client, environment, timing method, and acceptable range. Without those controls, a before-and-after comparison can describe different work rather than a real performance change.

Diagnose by scope before diagnosing by technology

Scope is the fastest way to reduce the number of plausible causes. Ask how many users, screens, processes, locations, and time periods are affected. The answers do not prove a cause, but they determine the next comparison that will produce the most information.

One user is affected

When one user is affected and peers with the same role can repeat the task normally, compare the endpoint first. Check the browser version and profile, extensions, cached assets, local storage, endpoint protection, device resource pressure, display or accessibility tools, VPN state, and network route. Then compare the user's role, preferences, branch, company, and saved filters with a working peer.

Do not assume that “one user” means “one computer.” Have the user sign in on a known-good device when policy permits, and have a comparison user test the affected device. This two-way test separates user configuration from endpoint configuration more cleanly than reinstalling software or changing several settings at once.

One screen or action is affected

When the rest of the site performs normally, focus on the dependencies of that transaction. Identify its Generic Inquiries, selectors, dashboards, reports, customization code, external calls, attachments, automation steps, and database queries. Capture Request Profiler data for only that action so unrelated requests do not obscure the trace.

Use a neighboring transaction as a control. If Sales Orders is slow, compare another screen that uses the same customer and inventory data but not the same customization. If an inquiry is slow, compare a narrower filter and a known-simple inquiry under the same role. The control helps identify whether the issue follows the data, the screen design, or the environment.

One location is affected

When users in one office, warehouse, or remote network are affected, compare connection setup and request timing. Record round-trip latency, VPN or proxy use, packet loss, DNS behavior, and whether large static assets or API responses are delayed. A browser HAR file can show whether time accumulates before the server responds or during transfer.

Avoid treating a successful ping as proof that the application path is healthy. Acumatica traffic may pass through gateways, inspection services, load balancers, or identity components that a simple network test does not exercise. Compare the actual browser transaction from affected and unaffected locations.

The whole site is affected

When many users and unrelated screens slow at the same time, widen the evidence window. Review application-server resources, application-pool behavior, database pressure, blocking, storage latency, running processes, scheduled automation, integrations, backups, scanning, and license or concurrency conditions where applicable. Acumatica's official troubleshooting sequence specifically separates overall-site performance from a slow individual process because the likely evidence and corrective actions differ. [1]

The problem appears only at certain times

Time-bound issues often correlate with other workloads. Map the slowdown against automation schedules, imports, exports, backups, maintenance, reporting, integration bursts, end-of-period activity, and user concurrency. Use a shared time zone and synchronized clocks. The strongest evidence is a repeated correlation between the slow transaction and a measured competing workload, followed by a controlled schedule or resource change that removes the effect.

Observed scope	Highest-value first comparison	Common evidence to collect
One user	Same user on another device; another user on the affected device	Browser profile, role, preferences, endpoint and route
One screen	Same screen with controlled data; neighboring screen as a control	Network request, profiler trace, GI, customization, SQL
One location	Same task from another location	HAR, latency, proxy/VPN path, transfer timing
Whole site	Unrelated screens and users during the same period	Server resources, jobs, blocking, storage, concurrency
Certain times	Same task inside and outside the affected window	Schedules, monitoring timeline, process history, correlations

Read browser evidence without misdiagnosing the server

The browser Network panel is most valuable when it is used to answer a precise question: where did the elapsed time accumulate for the request associated with the slow action? Preserve the log, reproduce one transaction, and identify the request or sequence that aligns with the user's wait. Record the request name or URL pattern, method, status, start time, duration, response size, and timing phases.

A long wait before a request is sent can indicate browser queuing, client-side work, connection limits, or another blocking resource. A long connection phase can point toward DNS, proxy, TLS, VPN, routing, or network instability. A long wait for the first response byte is consistent with time spent beyond the browser, but it does not by itself distinguish application code, SQL, an external dependency, or server capacity. A long content download can reflect response size or transfer conditions.

Use the browser Console as supporting evidence. Repeated exceptions, failed resource loads, blocked requests, or customization errors may explain a stalled interface even when the backend request is reasonable. Capture the exact message, timestamp, source, and action that produced it. A console warning unrelated to the tested transaction is not automatically the cause.

HAR files can contain URLs, parameters, record identifiers, headers, cookies, or other sensitive information. Follow the organization's data-handling policy before exporting or sharing them. Remove credentials and sensitive values, retain an unmodified copy only in an approved location when required, and tell the recipient what was sanitized.

Compare like with like. Use the same browser cache condition, record, role, and request sequence for the affected and control tests. If one test is the first visit after clearing cache and the other is a warm repeat, the comparison does not isolate the variable you intended to test.

Browser time versus Acumatica server time: Browser elapsed time includes work outside the Acumatica server, while Request Profiler server time measures processing recorded by Acumatica. When browser time is much higher than profiler time, investigate the client and delivery path. When profiler time explains most of the browser wait, inspect application, customization, external dependency, and SQL evidence inside the server trace.

Use Request Profiler as a controlled experiment

Request Profiler is not merely a place to collect a large log. It is a tool for connecting a user action to server time, SQL time, memory, exceptions, and trace details. The clearest profile contains the smallest practical set of activity that reproduces the issue.

Before starting logging, prepare the target screen and the exact record or filter. Note the local time and the tester. Start the profiler, perform the action once, stop logging promptly, and export the result. Avoid navigating through unrelated screens during the capture. If the slow behavior requires a sequence, document every step so the recipient can match the profile entries to the user's actions.

Interpret totals in context. Server time that is high with little SQL time directs attention to application logic, customization code, serialization, external calls, or resource pressure. SQL time that closely tracks server time directs attention to the generated query, blocking, plan, data distribution, and database resources. Exceptions and warnings may reveal a repeated fallback or retry, but they still need to be matched to the transaction.

Memory figures can help compare two versions of the same action. A large difference does not establish a leak on its own; it identifies a transaction that deserves a longer observation or code review. Likewise, one expensive request does not explain a whole-site complaint unless its timing and concurrency align with the broader impact.

Acumatica documents automatic monitoring thresholds in Request Profiler, including defaults for certain screen, Generic Inquiry, report, and other requests. Use those thresholds to understand what the profiler records automatically, not as universal service-level targets. [3] A frequently repeated four-second action may be operationally significant even if it does not cross an automatic logging threshold.

Run A/B comparisons with only one intentional difference:

1. Capture the task on the current build and package set.

2. Change one variable in a sandbox, such as the suspected customization, GI revision, browser path, or schedule.

3. Repeat the same record, role, filters, cache condition, and repetition method.

4. Compare user time, browser time, server time, SQL time, memory, result correctness, and any exceptions.

5. Restore or retain the change according to the test plan, then document the conclusion and next owner.

If several variables change together, the test may show improvement without explaining it. That makes the result difficult to reproduce and risky to promote into production.

Troubleshoot Generic Inquiry performance methodically

Generic Inquiries are frequently reused across screens, dashboards, exports, integrations, AI tools, and operational reporting. A design that appears in one place can therefore influence several user experiences. Troubleshooting should protect the business meaning of the inquiry while reducing unnecessary work.

Start by documenting what the GI is supposed to return. Identify the business grain: one row per sales order, line, shipment, customer, inventory item, or another defined entity. If joins create more rows than the business grain allows, the inquiry may process and return duplicate combinations even when users see a familiar result after grouping.

Review joins and conditions together. A correct relationship with an incomplete join condition can multiply rows. A filter applied after a broad join can make the database assemble a much larger intermediate result than the final grid suggests. Calculated fields, subqueries, aggregation, grouping, and sorting can add work, especially when the result covers a long period or many branches.

Test the GI with the production role rather than only an administrator. Security scope and accessible companies, branches, customers, or records can change both the result and the generated work. Record parameters and saved filters because two users can appear to open the same inquiry while requesting different datasets.

Pay attention to selectors and dashboards. A selector may execute while a user enters data, so a moderate delay repeated many times becomes disruptive. A dashboard can issue several inquiries at once, making its total load a concurrency problem rather than a single-query problem. Isolate each component before optimizing the combined page.

For exports, distinguish grid display from full dataset retrieval. The visible page may load a limited result while an export requests far more rows, columns, formatting, or calculated values. Record both the displayed row count and the exported row count.

Use the following sequence in a sandbox:

1. Confirm the required business grain and columns.

2. Reproduce with the exact role, parameters, filters, sorting, and data range.

3. Record browser, server, and SQL time plus returned row count.

4. Check joins for unintended multiplication and filters for unnecessary breadth.

5. Remove one nonessential column, calculation, sort, group, or join at a time.

6. Compare timing and validate totals, distinct keys, and sample records.

7. Test every consumer that depends on the inquiry before publishing the revision.

Slow Generic Inquiry diagnosis: A slow GI should be evaluated by business grain, joins, conditions, calculations, sorting, security scope, parameters, and returned volume. The safe optimization is the smallest design change that reduces measured work while preserving record counts, totals, keys, navigation, security, and downstream consumers.

Isolate Modern UI customization and integration effects

Customization troubleshooting should identify a package, component, or call path rather than classify all custom code as the problem. Begin with the dependency map for the slow task: screen extension, graph extension, event handler, client-side code, API call, external service, custom inquiry, automation, and any overridden behavior.

Check publication and build evidence after the upgrade. A customization can publish successfully while still performing unnecessary work at runtime. Conversely, a client-side build error, stale generated asset, or browser exception can impair the interface before the server transaction begins. Review both the customization build output and the browser evidence.

When safe, compare the same task with the suspected project unpublished and republished in a sandbox. Keep every other relevant condition constant. Acumatica's performance troubleshooting guidance describes this comparison as a way to identify customization involvement. [1] The result should be framed precisely: “server time decreased when package X was absent” is evidence; “all customization is slow” is not.

If several projects depend on one another, test a supported package set. Do not create an artificial environment that cannot execute the transaction correctly. Record dependencies, publication order, build output, and functional differences. A faster test that skips required business logic is not an acceptable optimization.

Time external dependencies independently. A customization may call a tax provider, carrier, commerce platform, document service, or internal API. Capture the start, finish, outcome, timeout, and retry behavior of that call. If Acumatica waits for a remote response, database tuning will not remove the delay. Consider whether the interaction must be synchronous, but treat architecture changes as a separate design decision with business and recovery implications.

Review repeated work. Code that queries or recalculates once per line, field event, or grid refresh can scale poorly as document size grows. Compare a small and large document while holding other variables constant. A sharply increasing curve is more informative than a single slow example.

Validate behavior after every performance change. Confirm field defaults, totals, taxes, discounts, inventory allocation, approvals, releases, notes, attachments, integrations, and audit expectations that the customization affects. Performance is one acceptance dimension; the transaction must remain correct and supportable.

Investigate SQL without jumping directly to indexes

SQL evidence should begin with the query and its operating context. Identify the Acumatica action, profiler entry, parameters, duration, reads where available, wait or blocking condition, execution plan, data scale, and competing activity. This prevents a database change from being based on an isolated statement copied without the application conditions that produced it.

Blocking and resource pressure can make a normally efficient query appear slow. Check whether the statement was waiting on another transaction, storage, memory, CPU, or a concurrent maintenance operation. Correlate the database timeline with the Acumatica and browser timestamps. A plan captured after the event may not reflect the plan or parameter values used during the slow execution.

Review data distribution and statistics. An upgrade can coincide with data growth, changed filters, new workflows, or maintenance differences even when the underlying query text is familiar. A plan that works for a narrow parameter may perform poorly for a broad one. Record the actual business parameters before testing an alternative.

Do not add an index solely because a tool suggests it. Evaluate write cost, storage, overlap with existing indexes, maintenance, upgrade support, and whether the query comes from a customization or a standard process. A targeted GI or code change may reduce more work with less long-term cost. Database changes should follow the organization's Acumatica support and change-control practices.

For overall-site issues, examine server configuration and health in the order described by the official guide. Acumatica's troubleshooting sequence includes the distinction between application-server and database-server time, followed by server and database checks and then additional evidence collection. [1] This order reduces the risk of tuning the database when most of the elapsed time occurs elsewhere.

Retest with the same workload after any change. Compare not only duration but also reads, CPU, blocking, result counts, and the effect on concurrent transactions. An improvement for one query that degrades order entry, imports, or release processing is not a successful system-level fix.

Account for post-upgrade conditions that distort results

The period immediately after an upgrade can produce measurements that do not represent steady-state operation. Application services may have restarted, caches may be cold, browser assets may have changed, database plans may be refreshed, and scheduled jobs may be catching up. Users may also be learning new navigation, which affects task time independently of server performance.

Separate stabilization observations into technical response and human execution. Measure the request sequence, and also watch a trained user complete the entire task. If requests are fast but the task takes longer, investigate layout, focus order, keyboard use, saved views, filters, and the number of interactions. If the same steps remain but requests are slower, continue with browser, profiler, customization, and database evidence.

Verify the exact build and package set. A statement about “2026 R1” or “2026 R2” is too broad for support or regression work because maintenance builds and customization revisions can differ. Record the complete Acumatica build, browser version, package versions, deployment topology, database version, and date of the test.

Warm the environment in a controlled way before accepting a baseline. Run the selected tasks once, then measure the defined warm series. Keep cold-start results as a separate operational measure if restarts or scale-out events matter to the business. Do not discard cold behavior; label it correctly.

Confirm background recovery. Integrations, automation schedules, search indexes, reporting extracts, or other processes may resume after an upgrade and compete for resources. Record queue depth and completion state. A slowdown caused by temporary backlog requires a different response from a repeatable screen defect.

Compare with the pre-upgrade environment only when the data and test method are comparable. A refreshed sandbox with a larger database, different integrations, fewer server resources, or different user concurrency cannot provide a clean version comparison. Document unavoidable differences and avoid claiming that the release caused the full measured gap.

The Acumatica 2026 R2 Upgrade Guide provides the broader readiness and stabilization framework. The Modern UI Migration Readiness guide helps teams identify complete role-based tasks so the performance test covers more than opening a screen.

Prepare an escalation package that support can use immediately

A strong escalation package allows another technical team to reproduce the issue, understand its business impact, and inspect the same evidence without beginning with basic discovery. Keep it focused enough to review and complete enough to act on.

Start with a one-paragraph summary. Name the environment, full build, affected task, scope, expected behavior, observed behavior, and business consequence. Include the first observed date and whether the issue began after a known change. Avoid conclusions that the evidence has not established.

Provide exact reproduction steps. State the screen ID, role, record or sanitized equivalent, filter values, buttons or actions, expected result, observed time, repetition count, and frequency. Explain whether the first run differs from warm repeats. If production data cannot be shared, describe the minimum data characteristics needed to reproduce the workload.

Attach a timeline using one time zone. Include the browser capture time, profiler session, application log interval, database observation, and any concurrent job. This lets support align events that were recorded by different systems.

Summarize comparisons already completed:

• affected and unaffected user;
• affected and unaffected location;
• supported browsers or clean profile;
• cold and warm run;
• customization present and absent in a sandbox;
• narrow and broad data range;
• normal and affected time window;
• current and comparison build when valid.

List the result of each comparison, including tests that rejected a hypothesis. This prevents repeated work and shows which variables are still open. Attach the Request Profiler export, sanitized HAR when allowed, relevant logs, screenshots, build and package inventory, monitoring graphs, and database evidence. Do not attach an entire unrestricted log archive when a focused interval will answer the question.

Close with the assistance requested. Ask whether support should confirm a known defect, interpret a trace, recommend a corrected build, review platform behavior, or advise on the next diagnostic step. A precise request is easier to route than “please fix performance.”

Minimum Acumatica support evidence: Provide the full build, deployment model, business impact, screen ID, exact steps, role, record and filters, timestamps, browser timing, Request Profiler export, relevant logs, package inventory, comparisons performed, and a clear request. Sanitize sensitive data while preserving the technical relationships needed for reproduction.

How to prevent performance regressions after the fix

Turn the confirmed transaction into a regression test. Store the screen, role, filters, representative record, row count, cold or warm condition, expected result, and acceptable range. Run it after Acumatica builds, browser changes, GI revisions, customization releases, and infrastructure work.

Include high-volume and exception paths, not only a blank screen or a small demo record. For the broader upgrade process, the Acumatica 2026 R2 Upgrade Guide explains how to build performance checks into sandbox validation and stabilization. If your organization is still moving custom screens and workflows, use the Modern UI Migration Readiness guide to inventory the role-based tasks that need coverage.

The goal is a small, trusted baseline rather than a single universal threshold. A sales-order screen, a 200,000-row inquiry export, and a batch release have different purposes. Each needs a business owner, representative data, and an agreed measurement.

Frequently asked questions

Why is Acumatica Modern UI slow only on the first load?

The first load may include browser assets, application initialization, and cold caches that later runs reuse. Record the cold result separately, then repeat the same action on a warm session. If only the first load is slow, inspect static-asset delivery, cache behavior, browser policy, and application startup rather than averaging the first and later runs together.

How do I tell whether Acumatica or the network is slow?

Compare the browser's elapsed request time with Request Profiler server time for the same action. A long browser request with low server time points toward the client, network, proxy, or endpoint path. High server time means the delay is within application processing, SQL, customization code, an external dependency, or server capacity.

Can a Generic Inquiry make Modern UI feel slow?

Yes. Joins, calculated fields, filters, sorting, security scope, returned row volume, and exports can increase the work behind a Generic Inquiry. Test the exact role and parameters, capture row count and profiler timings, then change one element in a sandbox while verifying that the business result remains correct.

Should I clear the browser cache after an Acumatica upgrade?

Clearing stale browser assets can be a valid controlled test, especially after UI or customization changes, but it is not a complete diagnosis. Record the result, distinguish the next cold load from warm repeats, and confirm whether the improvement persists. If the issue returns, capture browser and server evidence instead of repeating cache clearing as the only remedy.

When should I open an Acumatica Support case?

Open a case when you can reproduce the issue but cannot isolate an owned component, when evidence points to platform behavior, or when a documented defect may apply. Include the exact build, steps, timestamps, screen ID, role, browser, profiler export, relevant logs, comparisons, and business impact so support can begin with evidence rather than request basic reproduction details.

Get a focused Acumatica performance diagnostic

Biz-Tech Services can help reproduce a slow Acumatica transaction, separate browser, network, application, customization, Generic Inquiry, and database causes, and prepare an evidence package for remediation or support. Explore Biz-Tech Services Acumatica consulting and support or contact the team to request a performance diagnostic for your exact build and workflow.

Sources

1. Acumatica 2026 R2 System Administration Guide: Troubleshooting Performance

2. Acumatica: A Modern User Interface for a New Technology Era, Part I

3. Acumatica 2026 R2 System Administration Guide: Request Profiler

4. Acumatica 2025 R1 Modern UI overview

5. Acumatica Community: How is 26R1 Modern UI performing for you? (directional user reports; verify in your own environment)

---

by Gary

Acumatica AI Agents and Agent Actions: A Governed Automation Playbook

Acumatica AI agents can become controlled steps inside an ERP process: a user, business event, import scenario, schedule, or workflow invokes an agent action; the agent reads the current record and approved supporting data; it writes a bounded result; and the surrounding process decides what happens next. The practical opportunity in Acumatica 2026 R2 is therefore not unrestricted autonomous ERP. It is governed automation in which the target record, available tools, editable fields, trigger, review point, exception path, and audit evidence are designed before activation.

That distinction matters because an agent can change business records. A useful implementation does more than write a persuasive instruction. It limits the data the model can retrieve, exposes only the tools required for the task, constrains outputs to values that downstream rules can evaluate, tests both normal and adverse cases, and assigns a human owner. Acumatica provides relevant controls through the Agents form, endpoint-backed tools, published Generic Inquiries, field masking, result previews, processing logs, token statistics, AI Automation History, business events, workflows, and import scenarios. Those controls still require process design and operational discipline.

This playbook explains how finance, operations, IT, and process owners can select a suitable use case, design the agent boundary, protect sensitive data, build approval and exception paths, test changes, monitor cost and behavior, and scale only after evidence supports the decision. It focuses specifically on Acumatica AI Automation agents and agent actions. For the broader 2026 R2 program, see the Biz-Tech Acumatica 2026 R2 Upgrade Guide.

Executive Summary for Business and Technology Leaders

An Acumatica AI agent is most valuable when it applies judgment to a narrow record-level task that ordinary rules cannot express cleanly. Examples include classifying an incoming record, drafting a bounded description, comparing a current transaction with approved reference data, or assigning one of several defined review outcomes. Acumatica documentation describes agents that can retrieve the current record, update editable fields and detail lines, and retrieve supporting information through published Generic Inquiries. Once activated, an agent action can be invoked manually or by a configured business event, import scenario, or workflow.

The control model should begin outside the model. The process must specify which record exists before the agent runs, what data the agent may receive, what fields it may update, which output values are valid, what event or transition may follow, and who reviews exceptions. Acumatica notes that an agent works with the current record on its target form and cannot create a new record on that form. It also cannot invoke another target-form action from inside the agent. Record creation, releases, notifications, status transitions, and other actions should remain separate, visible process steps.

The safest first production use case usually has five characteristics:

• A clear owner can explain the business decision in plain language.
• The required data is available on one target form or through a small number of governed Generic Inquiries.
• The permitted output can be limited to a small set of fields or values.
• A person can verify correctness without recreating the entire analysis.
• An incorrect result can be contained, corrected, and traced without financial posting or irreversible downstream effects.

The rollout decision should be evidence based. A pilot should show that the agent selects the right scope, uses the intended tools, produces acceptable changes, routes uncertainty correctly, stays within a tolerable token and processing budget, and fails safely when data is missing or instructions conflict. If those conditions are not demonstrated, the next action is not broader deployment. It is a narrower boundary, better source data, clearer instructions, or a conventional deterministic rule.

Back to Table of Contents

What an Acumatica AI Agent and Agent Action Actually Do

In Acumatica 2026 R2, the Agents form ML202000 is used to configure and test AI Automation agents. Selecting a target data-entry form gives the agent a current-record context. Acumatica adds standard tools that retrieve the current record and apply updates to editable fields or detail lines. A configured endpoint defines which entity and fields those tools expose. Supporting data can be added through Generic Inquiry tools, with one published inquiry per tool.

After testing, activating most agents adds a generated command to the target form. A user can invoke that command from the More menu or add it as a favorite. The action can also participate in a process started by a record change, schedule, user action, import, business event, or automation workflow. Acumatica registers an internal action name that begins with LLMAction_ followed by the agent ID; workflow and import-scenario configurations use that name.

The agent is not the whole process. It is one step that retrieves information, applies the instructions, and returns a bounded result. A subsequent business event or workflow condition can evaluate the value written by the agent and decide whether to notify a reviewer, assign a task, run another step, or move the record. This separation is useful because it leaves deterministic routing and approvals in Acumatica configuration rather than asking the model to control every consequence.

The boundary also prevents common overstatements. An agent does not receive unrestricted database access merely because it operates inside the ERP. It receives what its tools, endpoints, Generic Inquiries, filters, and current-record context expose. It cannot update fields that are read-only through the configured endpoint, and it cannot update a detail line if the line cannot be edited manually on the target form. If a task requires a dialog, another form, or a target-form action, that task belongs in a separate workflow step or customization.

Back to Table of Contents

How AI Automation Differs from AI Assistant and Biz Tech AI Analyst

Acumatica AI Automation, Acumatica AI Assistant, and Biz-Tech AI Analyst solve different problems. Treating them as interchangeable leads to poor architecture and confusing expectations.

Acumatica AI Automation agents operate in a configured record context. They can retrieve current-record data, call approved supporting tools, and update fields that the configured endpoint permits. Their natural role is bounded execution within a business process. The governance question is which actions, data, fields, triggers, and outcomes are permitted.

Acumatica AI Assistant is oriented toward conversational analysis. The Assistant works with administrator-exposed Generic Inquiries so users can ask questions, examine source records, and create analytical outputs such as tables, charts, pivots, or dashboard widgets. It is suited to finding and explaining information, while AI Automation agents are designed to participate in defined process steps. Organizations planning both should maintain separate ownership, access reviews, use-case inventories, and acceptance tests. The Biz-Tech guide to Acumatica AI Assistant governance covers that analytical use case in more detail.

Biz-Tech AI Analyst is a separate Biz-Tech product for creating and refining Acumatica reports, Generic Inquiries, and Import Scenarios through a proposal-and-approval process. It can help turn business requirements into governed designs, including import mappings, but it does not replace Acumatica AI Automation or remove the need to govern an agent action. AI Analyst presents the proposed data sources, fields, filters, grouping, mapping, and limitations before building or changing a design. For imports, the user's team retains control of Prepare and Import.

These products can complement one another. A team might use Biz-Tech AI Analyst to prepare a narrowly scoped Generic Inquiry or Import Scenario, use Acumatica AI Automation to apply judgment to each current record, and use Acumatica AI Assistant to analyze approved results. The architecture is sound only when each capability retains its own access boundary, review process, and operational owner.

Back to Table of Contents

Choose a Process That Benefits from Model Judgment

The first design decision is whether the task needs an LLM. Many ERP actions are better implemented with formulas, workflows, business events, approval maps, import mappings, validation rules, or code. Those mechanisms are deterministic, easier to test exhaustively, and usually cheaper to run. An agent earns its place when the input contains ambiguity, unstructured text, contextual comparison, or classification that would otherwise require brittle rules or repetitive human interpretation.

Good candidates often transform information rather than authorize a final transaction. Examples include drafting a standardized summary from an existing record, categorizing an activity into one of several review queues, comparing a record with reference data, identifying the reason a record requires attention, or proposing a value for a reviewer to accept. The sales-order pricing demonstration in Acumatica documentation follows this pattern: the agent compares actual line prices with expected values retrieved through a Generic Inquiry and prepares a description of the differences.

Weak candidates combine too many business decisions. An instruction such as “review the order, decide whether the customer is trustworthy, change prices if needed, release the order, and notify everyone” mixes data retrieval, subjective judgment, financial authority, a target-form action, and communication. It is difficult to test, difficult to explain, and inconsistent with the documented boundary that an agent cannot invoke another action on the target form. Split such a process into record preparation, agent evaluation, human or rule-based approval, and deterministic execution.

Use a short selection test before configuration:

1. State the input record and the business question in one sentence.
2. Identify the smallest output that makes the next step possible.
3. List the exact fields and reference data required.
4. Define an abstain or review outcome for insufficient evidence.
5. Name the person who can judge whether the output is correct.
6. Describe how the original state can be restored or corrected.

If the team cannot answer those questions, it is not ready to write agent instructions.

Back to Table of Contents

Define the Automation Boundary Before Writing Instructions

Agent governance begins with a process contract. The contract should identify the target form, current entity, trigger, inputs, tools, fields the agent may update, permitted result values, prohibited changes, review path, and evidence retained. This contract should be approved by the process owner and technical owner before anyone spends time refining prompts.

The target form anchors the agent to a current record. Confirm that the form is a data-entry form, that the required entity is available through an endpoint, and that the intended fields can be retrieved and updated. If the Default endpoint omits a required field, decide whether extending an endpoint is justified. Acumatica warns that after an endpoint changes, tool settings in every affected agent must be updated and saved so the tools are rebuilt against the current endpoint definition. Endpoint changes therefore belong in change control, not an informal prompt-editing exercise.

Limit write scope. If the agent only needs to assign a review category and add an explanation, do not expose unrelated writable fields. If it does not need line-level updates, do not design the instructions around them. If a downstream workflow needs a status-like value, use a dedicated field with a small controlled vocabulary rather than asking the model for free-form prose that another rule must interpret.

Define what the agent must not do. Examples include changing quantities, prices, tax data, payment information, customer credit settings, posting periods, ownership, or release status. Some prohibited actions may already be impossible through the selected tools, but documenting them helps reviewers confirm that the technical configuration matches the business policy.

Finally, describe the next step independently of the agent. A workflow or business event should evaluate the saved output and determine whether a person reviews it, a notification is sent, or the record advances. This makes the process observable and allows the organization to disable the agent action without redesigning every downstream rule.

Back to Table of Contents

Build a Minimum Data Contract

An agent should receive the least data required to answer its assigned question. More context can improve a demonstration while weakening production control. Extra columns increase the chance that sensitive information is transmitted, that irrelevant details distract the model, that token consumption grows, and that a future data change alters behavior unexpectedly.

For current-record tools, document each exposed field and why it is required. Separate fields needed for reasoning from fields needed only for identification or traceability. For Generic Inquiry tools, define the inquiry owner, published screen ID, filters, returned columns, row limit, business meaning, refresh assumptions, and access restrictions. A query that was designed for human exploration may be too broad for an agent tool.

Acumatica supports adding one or more Generic Inquiry tools, each retrieving data from a single published inquiry. The tool name and description help the model decide when to call it. Use names that describe the business data and descriptions that state both purpose and limits. Avoid a generic description such as “use this for more information.” A better description explains which records the inquiry returns, what filter should be applied, and which decision the data supports.

The data contract also needs volume limits. An inquiry that returns hundreds of rows may exceed the useful context for the task, increase response time, and raise provider costs. Add shared filters and query conditions that produce only the relevant comparison set. Test with records near the expected maximum, not only with a convenient example that returns two rows.

Review the contract whenever a source changes. New columns, renamed fields, modified joins, different filters, or expanded access can change what the agent sees without any edit to its business instructions. Treat a material Generic Inquiry or endpoint change as a reason to retest affected agents.

Back to Table of Contents

Protect Sensitive Data and Understand the Masking Boundary

Acumatica AI Automation can mask selected fields returned by the get_current tool before data is sent to the LLM. The system replaces values with placeholders, keeps the actual data in Acumatica, and restores recognized placeholders when the model returns them. This is useful when an agent needs to carry a value through a result without analyzing the value itself.

Masking has operational limitations. A model cannot calculate with or classify a value it cannot see. If a numeric amount is masked, the model cannot use the actual amount to compute a percentage or compare it with a threshold. Acumatica also documents that after patch_current is invoked, an agent with masked fields cannot call get_current again. Instructions and tool sequence must account for that boundary.

Most importantly, masking on get_current does not mask columns returned by Generic Inquiry tools. Acumatica documentation explicitly warns that GI results are sent to the LLM without that masking. A governed design must therefore remove sensitive columns from the inquiry itself, apply appropriate filters, and limit returned records. Do not assume that selecting masked fields on the current-record tool protects a broad supporting inquiry.

Perform a field-level data review before production:

• Identify personal, payroll, banking, payment, tax, credential, contract, pricing, health, and regulated information.
• Decide whether the model needs to see, carry, aggregate, or ignore each value.
• Remove unnecessary fields at the source rather than relying only on instructions.
• Confirm the LLM provider, deployment, retention, regional, and commercial terms with the organization's security and legal owners.
• Review processing logs carefully because they can contain tool inputs, messages, returned data, errors, and model output.

The processing log is a governance asset and a sensitive record. Limit access to people who need it, define retention expectations, and avoid copying production logs into unsecured tickets or chat threads.

Back to Table of Contents

Write Instructions as an Executable Business Policy

Business instructions should describe purpose, required data, allowed tools, decision rules, output fields, valid values, exceptions, and stopping conditions. They should not depend on motivational language or broad requests to “use best judgment.” A reviewer should be able to compare the instructions with the process contract and identify any missing or conflicting rule.

Start with the goal and scope. Name the current record and the single decision the agent supports. Then define the tools and when to use them. Insert exact field and tool names from Acumatica rather than typing approximations. Acumatica provides an Insert Data Field command because the model must use names that match the configured tool schema.

State decision rules in observable terms. If the output is a review category, enumerate the allowed values and the evidence required for each one. Include an explicit value such as NEEDS_REVIEW when the data is incomplete, contradictory, outside policy, or unavailable. Downstream workflows should recognize that value and route it to a person instead of treating uncertainty as approval.

Separate analysis from writing. An agent that evaluates a record and generates explanatory text should first determine the controlled result, then produce a short explanation grounded in the retrieved fields. Limit length and prohibit unsupported claims. If the process needs a note for a customer or vendor, require human approval before external communication.

Add constraints that reflect actual business policy: fields that must remain unchanged, date or amount boundaries, valid currencies, permitted record statuses, maximum number of lines, and conditions that require no update. Avoid repeating constraints in contradictory ways. Acumatica notes that conflicts among system instructions, business instructions, and tool descriptions can cause processing errors.

Version the instructions. Record the approver, effective date, related agent ID, target form, endpoint version, GI versions, and test evidence. A prompt edit can change production behavior as materially as a workflow or code change.

Back to Table of Contents

Keep Human Approval at the Right Decision Point

Human review should protect the consequence, not merely observe the model. Placing a reviewer after an irreversible action provides little control. Place approval before release, payment, posting, external communication, compliance classification, account changes, or any transition that materially affects another party.

For a low-risk internal field, post-action review may be sufficient if changes are visible, reversible, and sampled regularly. For higher-risk records, the agent should write a proposal or review status rather than the final authoritative value. A workflow can assign the record to an authorized user, display the explanation, and require acceptance or correction.

Design the review screen around evidence. The reviewer needs the original value, proposed value, reason, relevant source data, and any missing or conflicting information. A bare “AI approved” flag is not enough. Acumatica's test Result tab demonstrates the value of before-and-after differences; production review should follow the same principle when possible.

Define reviewer authority and service expectations. Specify who may approve, who handles exceptions, how quickly records must be reviewed, and what happens when no reviewer acts. Avoid silently allowing an agent-generated value to become authoritative because a queue aged past a deadline.

Measure human disagreement. Corrections reveal where instructions, source data, or use-case boundaries need improvement. Preserve a reason for overrides rather than recording only that the value changed. A rising override rate should trigger investigation and perhaps automatic suspension of the action for the affected scenario.

Back to Table of Contents

Use Agent Actions in Import Scenarios Carefully

Acumatica 2026 R2 allows an import scenario to invoke an AI Automation agent action for each record it creates or updates when the AI Automation feature is enabled. This can apply judgment during a controlled import, but it also multiplies execution volume and introduces ordering requirements.

The documented action sequence is Save, agent action, and Save again. The first save creates or updates the current record so the agent has something to process. The agent reads that record and writes its result. The second save persists the agent's values. Each row uses Commit and executes for each record. The internal action name is entered manually in angle brackets because the dynamic agent action does not appear in the normal lookup.

Mapping conflicts deserve special attention. If the source file maps a value into a field that the agent also writes, the import can overwrite the model's result. Acumatica advises leaving the corresponding source values empty when the agent is responsible for those fields. Document field ownership explicitly so a future spreadsheet template or mapping change does not reintroduce the conflict.

Every imported record causes a separate LLM request sequence, and the import waits for each result. Begin with a small record count, measure processing time and token use, and verify the AI Automation History before increasing volume. Do not launch a large production import based on a successful one-record test.

Create restart and reconciliation rules. Determine how to identify records that completed the first save but not the agent action, or the agent action but not the final save. Use an import batch identifier, status field, or other traceable marker. Define whether a failed record can be retried safely and whether the agent will produce the same result when the current record already contains a partial output.

Back to Table of Contents

Orchestrate with Business Events and Workflows

An agent action becomes more useful when Acumatica configuration controls when it runs and how its result is handled. A business event can respond to a record change, schedule, or user action. A workflow can expose the agent action only in appropriate states, run it automatically, or use it in a transition. These mechanisms should remain responsible for sequence and authorization.

Use stable output values for downstream logic. Acumatica recommends instructing an agent to write one of a fixed set of values when a business event or workflow condition depends on the result. Free-form text is suitable for explanation, but it is a poor control signal. A dedicated field with values such as NO_ISSUE, REVIEW, and BLOCKED is easier to route, report, and test.

Remember that a business event fires only when its monitored value changes. If the agent writes the value already stored in the field, the event does not trigger. Design state transitions accordingly. Clearing the field before every run may create other risks, so test repeat execution and idempotency instead of assuming every successful agent call causes a new event.

Keep target-form actions separate. Acumatica states that the agent cannot invoke another action of the target form. If the process requires release, assignment, notification, creation of another document, or another command, configure that as a subsequent event or workflow step. This produces clearer logs and lets each action enforce its own rights and validation.

Add an automation stop. Administrators should know how to deactivate the agent, disable an invoking event or workflow transition, and hold affected records. Document the order of operations so an incident response does not create more partially processed work.

Back to Table of Contents

Test the Agent Before Activation

Testing must prove both correctness and containment. On the Agents form, the Test Agent function uses an example record and shows intended changes without saving those changes to the database for most agents. The Result tab identifies the affected entity and displays before-and-after values. The Processing Log records instructions, tool schemas, tool calls, responses, timing, errors, messages, and token consumption.

Build a representative test set rather than selecting only clean examples. Include ordinary records, records at policy boundaries, missing fields, unexpected detail-line counts, inactive or closed statuses, values outside normal ranges, conflicting GI results, no GI results, duplicate references, and attempts to introduce irrelevant instructions through text fields. Use de-identified or suitable nonproduction data according to organizational policy.

For every case, record the expected result before running the agent. A test is weak when reviewers decide after seeing the output that it “looks reasonable.” Compare the actual result with an approved expectation and capture differences. For classification, measure agreement by category. For generated text, define required facts, prohibited claims, maximum length, and acceptable tone.

Inspect tool behavior, not only the final wording. Confirm that the model called the expected inquiry, applied the intended filter, retrieved the correct records, and updated only the permitted fields. A plausible answer produced from the wrong data path is still a failure.

Repeat tests across model or connection changes. Agent LLM Connections can point to supported providers including Azure, Amazon Bedrock, OpenAI, and Anthropic, and providers may retire or change models. Acumatica recommends reviewing provider availability and retesting connections. A connection or model change should trigger functional regression tests, masking-placeholder tests, volume tests, and renewed approval before production use.

Back to Table of Contents

Validate Failure and Exception Paths

Production reliability depends on how the process behaves when the model, connection, data, or surrounding workflow fails. The desired failure mode is usually a visible exception with no unauthorized update, not an improvised answer.

Test invalid credentials, unavailable endpoints, provider timeouts, rate limits, missing GI permissions, empty results, malformed data, excessive record volume, noneditable fields, and an agent output that does not match the controlled vocabulary. Confirm what appears in the Result and Processing Log tabs and how operators identify the affected record.

Define retry rules. Some failures are transient, but an automatic retry can duplicate work or apply a change after the record has moved to another state. Before retrying, verify that the current record is still eligible, that earlier changes were not saved, and that the action is idempotent. Limit retry count and route repeated failures to a named queue.

Distinguish technical errors from business uncertainty. A provider timeout is a technical failure. Missing evidence or contradictory source data is a business exception. They may require different owners, communications, and service targets. Do not let a generic error status hide the cause.

Create a reconciliation view or Generic Inquiry that shows records awaiting agent processing, records completed, exceptions, last-run time, outcome, reviewer status, and related batch or workflow identifiers. This operational view is often more valuable than a polished demonstration because it enables supervisors to manage real work.

Back to Table of Contents

Monitor Activity Tokens Cost and Behavior

Each agent execution can make multiple requests to an LLM, especially when tools are called. Acumatica records token statistics calculated by the ERP and values reported by the provider. The two can differ because providers tokenize and report categories differently. Acumatica documentation states that the provider remains the source of truth for actual usage and billing.

During testing, use the Processing Log to see which requests and tool steps consume tokens. Over time, use AI Automation History ML400000 to review connection tests, agent tests, and production actions invoked by users, business events, import scenarios, or workflows. The history includes Acumatica-calculated values and provider-reported input, output, and total tokens when the provider supplies them.

A blank provider value does not necessarily mean zero usage. It may mean the provider did not report the value. Establish a reconciliation process with the provider dashboard and commercial terms. Monitor both unit economics and business throughput: cost per processed record, cost per accepted result, elapsed time, failure rate, and reviewer effort.

Behavior monitoring is equally important. Track outcome distribution, human override rate, exceptions by cause, tool-call patterns, fields changed, and volume by trigger. A sudden change may indicate new source data, a modified Generic Inquiry, a prompt edit, an endpoint change, a model update, or a shift in incoming records.

Set thresholds for investigation and suspension. Examples include a material rise in NEEDS_REVIEW, repeated writes outside expected fields, processing time that disrupts imports, provider cost above budget, or reviewer disagreement above the pilot baseline. Thresholds should initiate a defined response rather than remain dashboard decoration.

Back to Table of Contents

Establish Change Control and Audit Evidence

An AI agent is a production configuration with dependencies. Its effective behavior comes from the business instructions, system instructions, tool descriptions, endpoint entity and version, writable fields, Generic Inquiry definitions, filters, provider connection, model, invoking configuration, and downstream workflow. Change control must cover that full dependency set.

Maintain an inventory with agent ID, name, purpose, owner, target form, endpoint, tools, supporting inquiries, invoking events or workflows, output fields, approval path, connection, reviewer, activation date, and last validation date. Link the inventory entry to the approved process contract and test evidence.

Require review for material changes. A wording correction that cannot affect behavior may need lightweight review, but a new tool, field, decision rule, model, GI column, filter, or automatic trigger requires regression testing. Changes to shared endpoints or inquiries should identify every dependent agent before publication.

Preserve evidence from testing and production review without copying sensitive content unnecessarily. Useful evidence includes test case IDs, expected and actual controlled outcomes, before-and-after field differences, error classifications, timing, token totals, reviewer decision, and approval. Store logs according to security and retention policy.

Auditability also means explaining current behavior. An administrator should be able to answer why the agent could see a field, why it was allowed to update another field, which version of instructions applied, which process invoked it, and who approved activation. If those answers require reconstructing decisions from emails, the control is incomplete.

Back to Table of Contents

Use a Phased Implementation Plan

A four-phase rollout keeps the first deployment small while producing evidence for each expansion decision.

Phase one defines the process. Select one record-level use case, write the process contract, identify sensitive data, specify permitted outputs, and choose the reviewer. Confirm feature availability, licensing, target build, provider requirements, and environment policy with the appropriate Acumatica partner and internal owners.

Phase two builds in a sandbox. Configure the connection, target form, endpoint-backed tools, supporting Generic Inquiries, instructions, output fields, and manual action. Do not add an automatic trigger yet. Test representative records and correct scope, data, and instruction problems.

Phase three runs a controlled pilot. Activate the command for a limited user group or narrow queue. Require review of every result. Measure accepted results, corrections, exceptions, processing time, token consumption, and operational effort. Keep a conventional fallback process available.

Phase four automates only the proven boundary. Add a business event, workflow, schedule, or import scenario when manual pilot evidence shows consistent behavior and safe failure. Continue sampling accepted outcomes and reviewing exceptions. Expand volume, record types, or write scope one variable at a time.

Each phase needs an exit decision. The team should explicitly approve advancement, repeat the phase with changes, or stop. “No serious complaints” is not sufficient evidence. Use documented acceptance criteria and a named owner.

Back to Table of Contents

Measure Business Value Without Overclaiming

The business case should compare the governed process with its actual baseline. Relevant measures may include review time per record, queue age, percentage of records requiring manual investigation, classification agreement, correction rate, exception resolution time, processing cost, and downstream error rate. Choose measures tied to the selected use case.

Avoid treating model output volume as value. Processing more records is beneficial only when the outputs are correct enough, reviewed at the appropriate level, and used by the next process step. Likewise, a reduction in manual touches is not positive if unresolved exceptions or downstream corrections increase.

Measure accepted automation separately from assisted work. A reviewer may save time even when every result still requires approval. That can be a valid outcome and a safer long-term design for sensitive decisions. Do not force full automation merely to improve an adoption metric.

Include control costs: configuration, source-data maintenance, review, provider consumption, investigation, retraining, and change management. Agent economics can change when record volume, prompt length, tool calls, or provider pricing changes. Review the cost model with actual production history.

Report limitations with results. State the period, record population, model and connection, process version, review method, and exclusions. A pilot on one business unit and one record type does not prove enterprise-wide performance.

Back to Table of Contents

Governance Checklist Before Production Activation

Use the following checklist as a release gate:

• The process owner approved a one-sentence purpose and a bounded business outcome.
• The target form, current entity, endpoint, tools, fields, and supporting inquiries are documented.
• The agent receives only the data required for the task.
• Sensitive fields are removed, masked where supported, or otherwise governed.
• The team understands that Generic Inquiry results are not protected by current-record field masking.
• Permitted updates and prohibited changes are explicit.
• Downstream logic uses controlled values rather than interpreting free-form prose.
• Human approval is placed before consequential or irreversible actions.
• Normal, boundary, missing-data, adverse-input, error, retry, and repeat-run cases passed.
• Reviewers verified tool calls and field differences, not only final wording.
• Token use, provider billing, elapsed time, and expected volume are within budget.
• AI Automation History and operational reconciliation views are assigned to owners.
• Rollback steps can deactivate the agent and its invoking configuration safely.
• Instruction, endpoint, inquiry, workflow, and connection changes require appropriate retesting.
• A named owner approved activation and the next review date.

The checklist should be retained with implementation evidence. If an item does not apply, record the reason rather than deleting it. That creates a reviewable decision and helps future owners understand the original boundary.

Back to Table of Contents

Common Implementation Mistakes

The first mistake is starting with instructions instead of a process contract. Prompt refinement cannot repair an undefined owner, excessive write scope, or missing approval step.

The second is exposing a broad Generic Inquiry because it is convenient. Supporting inquiries should be purpose-built or carefully constrained. Remember that current-record masking does not mask GI results.

The third is combining judgment and consequence. Let the agent propose or classify, then let a person or deterministic workflow authorize the material action.

The fourth is testing one clean record. A production decision needs boundary, missing-data, conflicting-data, volume, repeat-run, and technical-failure cases.

The fifth is relying on free-form text as a workflow condition. Use fixed output values for routing and keep prose for explanation.

The sixth is ignoring dependency changes. Endpoint, GI, model, provider, instructions, and workflow changes can all alter behavior.

The seventh is assuming provider token values are always complete. Blank values can mean unreported usage, and the provider dashboard remains the billing authority.

The eighth is automating a large import too early. Each record can generate a separate execution and multiple LLM requests, so begin with a small batch and reconcile every outcome.

The ninth is presenting Acumatica AI Automation as equivalent to AI Assistant or Biz-Tech AI Analyst. Their purposes and control boundaries differ.

The tenth is treating activation as the end of implementation. Production monitoring, human feedback, exception handling, and scheduled revalidation are part of the operating model.

Back to Table of Contents

Frequently Asked Questions

What is an Acumatica AI agent

An Acumatica AI Automation agent is a configured model-driven capability associated with a target data-entry form. It can retrieve the current record, update fields and editable detail lines through endpoint-backed tools, and retrieve supporting data from published Generic Inquiries. After testing and activation, the related agent action can be invoked manually or through configured business events, workflows, schedules, or import scenarios.

Can an Acumatica AI agent create a new record

The documented agent action works with the current record on its target form and cannot create a new record on that form. A surrounding process must create or identify the record before invoking the agent. The agent may update permitted fields on that current record; other creation or action steps should be configured separately.

Can an agent run another form action?

Acumatica documentation states that an agent cannot invoke another action of the target form. Configure release, notification, assignment, transition, or other commands as separate business-event or workflow steps with their own permissions and validation.

How can agent actions be started

An active agent normally adds a command to the target form for user invocation. An action can also be invoked through a business event, import scenario, or workflow. The appropriate trigger depends on the process risk, record state, desired review point, and expected volume.

Does masking protect data returned by Generic Inquiries

No. Acumatica's documented field masking applies to selected values returned by the get_current tool. It does not mask data returned by Generic Inquiry tools. Remove sensitive GI columns, use narrow filters, limit records, and review the inquiry as a separate data boundary.

How should an agent communicate a result to a workflow

Use a dedicated field with a fixed set of permitted values, such as NO_ISSUE, REVIEW, or BLOCKED. The agent may also write an explanation, but downstream logic should not have to interpret unrestricted prose. Test repeat execution because a business event is triggered only when the monitored value changes.

Can an import scenario call an agent action

Yes, when AI Automation is enabled. Acumatica documents a Save, agent action, Save sequence for each record, with Commit selected and execution configured for each record. Start with a small batch because each record creates a separate LLM execution and the import waits for the response.

How do I estimate AI Automation cost

Review token consumption in the Processing Log during tests and in AI Automation History over time. Compare Acumatica-calculated values with provider-reported usage, and reconcile with the provider dashboard because the provider remains the source of truth for billing. Include processing volume, tool calls, retries, review effort, and support overhead.

When should a team keep human approval

Keep approval before financial posting, release, payment, external communication, compliance classification, account changes, or another material consequence. Lower-risk internal suggestions may use sampling after a controlled pilot, but the organization should retain an exception path, override evidence, and a way to suspend the automation.

What is the safest first Acumatica AI agent use case

Choose a narrow current-record task with limited data, a small controlled output, an easy human check, and a reversible result. Classification, summarization, or proposal generation is usually safer than autonomous transaction processing. Test manually before adding automatic triggers.

Back to Table of Contents

A Practical Next Step

Start with one real queue, one current record, one decision, and one owner. Write the process contract before configuring an agent. Then build the smallest tool and data boundary that can support the decision, test adverse cases, and run a reviewed pilot. Scale only the part that evidence shows to be reliable.

Biz-Tech Services can help organizations assess Acumatica AI Automation use cases, design controlled workflows and import scenarios, review Generic Inquiry and endpoint exposure, define test evidence, and establish monitoring and rollback procedures. The objective is a production process that remains understandable and governable after the demonstration ends. Explore practical implementation resources in the Biz-Tech Acumatica Lessons library or discuss a scoped automation review with Biz-Tech Services.

Back to Table of Contents

Sources

1. Acumatica 2026 R2 Integration Guide Use of Agent Actions
2. Acumatica 2026 R2 Integration Guide Agent Actions in Import Scenarios
3. Acumatica 2026 R2 Form Reference Agents ML202000
4. Acumatica 2026 R2 Integration Guide Creation of Agents
5. Acumatica 2026 R2 Integration Guide Hiding of Sensitive Data
6. Acumatica 2026 R2 Integration Guide Testing and Troubleshooting Agents
7. Acumatica 2026 R2 Integration Guide Collection of Statistics
8. Acumatica 2026 R2 Form Reference Agent LLM Connections ML201000
9. Acumatica Cloud Platform and 2026 R2 AI Overview
10. Biz-Tech Services Acumatica 2026 R2 Upgrade Guide
11. Biz-Tech Services Acumatica AI Assistant Governance Guide
12. Biz-Tech AI Analyst

Back to Table of Contents

---

by Gary

Acumatica Classic UI and Chromium XSLT: Patch and Test Before November 17, 2026

Acumatica Classic UI and Chromium XSLT: Patch and Test Before November 17, 2026

Verified October 15, 2026

Browser change has become an operational Acumatica risk. Chromium is removing XSLT support on November 17, 2026, and Acumatica has warned that Classic UI screens can stop loading in Chromium-based browsers without the applicable update. This guide gives administrators and operations leaders a focused patch, test, and communication plan - while keeping the larger Modern UI transition moving.

The deadline is a browser change with an ERP impact

On November 17, 2026, Chrome 158 is scheduled to stop supporting XSLT on Stable releases for most users. Acumatica's Classic UI relies on browser behavior affected by that change, so a Classic screen can fail to load in Chrome, Edge, or another Chromium-based browser even when the ERP server itself is healthy.

This is not simply a browser-standard discussion. A missed patch can interrupt order entry, approvals, reporting, and administration wherever a team still opens Classic UI screens. The immediate objective is continuity; the strategic objective is to reduce the remaining Classic UI footprint before the next upgrade decision.

Back to TOC

Know which environments and users are exposed

Start with a short inventory, not an assumption. Record each production, sandbox, and tenant environment; its Acumatica version and build; the hosting model; the installed patch level; the browsers employees use; and the departments that still rely on Classic UI. Include administrators, power users, remote users, and third-party support teams.

Then identify the workflows rather than only the screens. A modern home page does not prove that a month-end dashboard, a legacy pivot table, a customized inquiry, a wizard, or an ISV add-on is safe. Ask each owner to name the transaction they cannot postpone for a business day.

Back to TOC

Separate the browser patch from the Modern UI transition

The Chromium XSLT issue and the Classic UI retirement are related but different decisions. The current Acumatica notice says the updated fix is available through patches for 2026 R1, 2025 R2, and 2025 R1, while customers on 2024 R2 or earlier need a supported-version upgrade or a temporary non-Chromium workaround. Confirm the exact supported build and patch with Acumatica before making a production change.

A patch preserves near-term access to Classic UI in Chromium-based browsers; it does not eliminate the migration work. Acumatica's 2026 R2 documentation makes Modern UI the default, and Classic-only forms are warned for later retirement. Treat the patch as continuity protection while the organization completes its Modern UI plan.

Back to TOC

Build a patch decision record

For every environment, capture the current version, build, patch candidate, maintenance window, backup point, owner, validation evidence, and rollback decision. SaaS and private-cloud customers can have different delivery responsibilities, so do not infer the outcome from another customer's model. Review the current Acumatica patch notice immediately before scheduling work.

This record gives finance and operations a reliable answer to a practical question: which workflows have been proven after the change, and which still need an alternate path? It also prevents a browser update from being treated as an undocumented production experiment.

Back to TOC

Run regression tests that reflect real work

Test the browser and application together in a sandbox first. Use a supported Chromium browser at the current corporate version, then exercise the workflows identified in the inventory. Confirm login, navigation, data entry, save, release, approvals, attachments, printing or exports, dashboards, inquiries, and any custom actions that the team uses during a normal operating cycle.

For each test, preserve the expected result, actual result, timestamp, browser version, Acumatica build, and tester. Retest integrations and scheduled processes where a Classic UI setup page or manual exception path is involved. A successful landing page is not a regression test.

Back to TOC

Give users a clear contingency plan

Publish one short notice before the production window: what is changing, when it occurs, which teams should test, where to report a problem, and what to do if a screen does not load. The Acumatica notice identifies Firefox as a temporary workaround in affected situations; use it only as a controlled contingency while the applicable patch or upgrade is completed, not as a silent long-term operating model.

Assign a named business owner and technical owner for each critical workflow. During the first business cycle after the change, monitor support tickets and confirm that exception queues, approvals, and time-sensitive operations continue normally.

Back to TOC

Use the deadline to retire hidden Classic dependencies

The inventory will often uncover work that has not been modernized because it still works: custom forms, Classic dashboards, pivot tables, and legacy add-on screens. In 2026 R2, Classic UI is disabled by default, and the Beacon guidance specifically calls out forms and functionality that remain Classic-only as candidates for preparation.

Rank those items by operational risk, user volume, and replacement effort. Some may be converted, some redesigned, and some retired. Give each item an owner, target release, acceptance criteria, and a user-training date. That is a more durable response than waiting for the next upgrade window to expose the dependency.

Back to TOC

A practical 10-business-day readiness sequence

Days 1-2: finish the environment and workflow inventory, confirm the current Acumatica advisory, and choose a patch candidate. Days 3-4: apply the patch in sandbox and execute the regression pack with business users. Days 5-6: resolve failures, validate customizations and ISV components, and document the production plan. Days 7-8: communicate the change and prepare the support rota. Days 9-10: apply the approved patch in production, run smoke tests, and track results through the next critical business cycle.

If the timeline is already compressed, reduce scope only after protecting the highest-risk workflows. Do not skip version confirmation, backup planning, or a post-change verification simply to meet the date.

Back to TOC

Why XSLT removal matters to Acumatica Classic UI

XSLT, or Extensible Stylesheet Language Transformations, is a browser technology that can transform XML data into a format a user can view and work with. Chromium has deprecated the browser-side XSLTProcessor API and the XML stylesheet processing instruction, with removal planned for Chrome 158 on November 17, 2026. That browser decision is broader than Acumatica, but it matters to Acumatica because portions of the Classic UI depend on the browser behavior being removed.

The operational symptom can be deceptively simple: a Classic UI screen that worked yesterday may stop loading after a browser update. Users may initially report a blank page, incomplete rendering, or a screen that appears to hang. Because the server can remain available and Modern UI screens can continue working, the incident may look inconsistent across departments. That inconsistency is exactly why organizations need an inventory tied to real workflows rather than a generic statement that the site is available.

The change also demonstrates an important dependency-management lesson. ERP continuity depends not only on application code and infrastructure but also on browsers, identity services, document engines, operating systems, and third-party components. A mature readiness plan records those dependencies, assigns ownership, and tests them together before a vendor deadline becomes a production outage.

Back to TOC

Understand the October 2026 change before the November deadline

Acumatica's original guidance focused on Chromium's planned November removal. The October 1, 2026 update added urgency: an unexpected Chromium behavior change caused Classic UI problems to surface earlier than anticipated and required updated fixes. Acumatica listed expedited patch dates for 2026 R1, 2025 R2, and 2025 R1. Organizations should therefore avoid treating November 17 as the first possible impact date.

This changes the planning sequence. Administrators should first verify whether their current browser and Acumatica build already show the issue, then confirm whether the environment contains the updated fix rather than only an earlier patch intended for the original removal schedule. A patch name or installation date is not enough evidence. The change record should identify the exact Acumatica build, the patch source, the browser version used for testing, and the date the current vendor notice was checked.

If a team already experienced intermittent Classic UI failures, the incident evidence should feed the regression pack. Capture affected screen IDs, browser versions, console or network symptoms when available, user roles, customizations, and whether the same transaction succeeds in Modern UI or Firefox. This turns an urgent support event into a repeatable validation scenario instead of relying on memory after the patch is installed.

Back to TOC

Map the Acumatica version and hosting model

The correct response depends on both the Acumatica release and who is responsible for applying updates. Acumatica's current notice distinguishes environments on 2025 R1 or later from those on 2024 R2 or earlier. It also distinguishes SaaS delivery from private-cloud subscription environments. Those distinctions determine whether a fix may be delivered automatically, whether a customer must schedule a patch, or whether a supported-version upgrade is required.

Create one row per environment and include production, test, training, disaster-recovery, and integration tenants. Record the full version and build, hosting model, responsible administrator, maintenance process, browser-management policy, installed customizations, and business owner. Do not assume a sandbox matches production merely because the two environments share a major release. Patch history, customization packages, data volume, and authentication configuration can differ.

The inventory should also name the partner or internal team that can confirm patch eligibility. If an environment is outside the versions covered by the current fix, the decision becomes an upgrade and continuity decision rather than a normal patch. That requires additional time for customization validation, integration testing, data refresh, user acceptance, and change approval. Escalate that gap immediately instead of leaving it inside a technical checklist.

Back to TOC

Create a dependable Classic UI dependency inventory

A useful dependency inventory starts with people and transactions. Ask department leads which processes still require a Classic UI screen and when those processes become time-critical. Examples include order release, shipment processing, cash management, month-end reconciliations, time entry, project billing, manufacturing exceptions, construction commitments, and administrative setup. The goal is to connect each screen to a business outcome and recovery priority.

Next, inspect technical sources. Review site maps, customization projects, access-right assignments, Classic dashboards, pivot tables, wizards, custom forms, and ISV documentation. Search support tickets for terms such as Classic UI, legacy screen, switch interface, blank page, browser, dashboard, or pivot. Ask power users to demonstrate shortcuts and exception paths because those are often absent from formal process documentation.

For every dependency, record the screen ID, workflow, user group, frequency, peak period, customization owner, Modern UI status, test owner, and fallback. Add a confidence field so unverified assumptions are visible. A screen marked as available in Modern UI is not complete until a business user confirms that the required fields, actions, imports, attachments, reports, and navigation behavior support the real transaction.

Back to TOC

Prioritize workflows by operational risk

Not every Classic UI dependency deserves the same response. Prioritize the inventory using business impact, time sensitivity, transaction volume, number of affected users, availability of a workaround, customization complexity, and recovery effort. A rarely used inquiry with a documented Modern UI replacement is different from a release screen that controls daily shipping.

A practical classification uses three tiers. Tier 1 covers workflows that can stop revenue, payment, regulatory, payroll, shipment, or customer-service operations within hours. Tier 2 covers important work that can tolerate a short delay but creates a growing backlog. Tier 3 covers low-frequency administrative or analytical tasks with a workable alternative. The exact labels matter less than having owners agree on the order of testing and recovery.

Risk ranking also helps when time is limited. If the organization cannot execute every test before the maintenance window, it can protect Tier 1 workflows first, document the residual risk, and schedule the remaining validation. The ranking should be approved by process owners, not assigned by IT alone, because technical teams may not know which seemingly small action closes a financial period or releases a customer commitment.

Back to TOC

Design the sandbox before applying the patch

A sandbox is valuable only when it represents the production conditions relevant to the change. Confirm that it uses the intended Acumatica build, customization packages, ISV components, authentication method, browser policies, and representative roles. Refresh data when necessary to reproduce critical transactions, while following the organization's privacy and data-handling rules.

Freeze the test baseline before patching. Record the current browser version and execute a small set of control tests so the team knows which issues already exist. Then apply the candidate patch using the same documented sequence planned for production. Capture start and finish times, installer output, service status, application startup behavior, and any manual configuration changes.

After patching, confirm basic health before business testing begins. Verify login, navigation, background processing, scheduled jobs, integrations, printing, email, and access to both Modern and remaining Classic UI screens. If the sandbox contains unrelated experimental changes, identify them clearly or create a cleaner environment. Otherwise a failed test can lead to hours of investigation against the wrong cause.

Back to TOC

Build browser coverage around the real desktop estate

Chrome and Microsoft Edge are the most visible Chromium-based browsers in many organizations, but the testing scope should come from the managed desktop estate. Record supported browsers, release channels, update policies, virtual desktop images, kiosk devices, remote-access platforms, and any embedded browser components used by companion applications. Confirm whether updates are centrally controlled or can arrive independently on user devices.

Use the current corporate browser version for the main regression cycle and include the next available managed version when practical. This is especially important when the organization delays browser updates, because a sandbox tested on an administrator's current browser may not represent a warehouse workstation or remote desktop pool. Capture the full browser version in every result, not simply Chrome or Edge.

Do not use compatibility modes or alternate browsers as invisible permanent fixes. A temporary workaround can protect continuity, but it should have an owner, an expiration date, a deployment method, and security approval. The supported application patch and the Modern UI transition remain the durable paths. Browser exceptions that outlive the incident can create a second unmanaged dependency.

Back to TOC

Test authentication session and navigation behavior

Begin the functional test pack with the path users take before they reach a transaction. Validate single sign-on or native login, multifactor redirects, tenant selection, company and branch selection, session timeout, logout, and reauthentication. Confirm that bookmarked Classic UI URLs, navigation favorites, and links from notifications still land on the intended page.

Mixed-interface environments deserve special attention. Test navigation from a Modern UI page to a Classic-only page and back again. Verify that the user's role, branch, locale, and session context remain correct. If the organization uses multiple tabs, confirm that common tab patterns do not produce stale sessions or unexpected redirects after the patch.

Record any difference between a direct URL, a site-map link, and a workflow action that opens another screen. A page may render successfully when opened directly while a contextual action passes parameters differently. Tests should therefore begin from the same starting point users follow in normal work rather than launching every screen from an administrator's saved link.

Back to TOC

Validate data entry and transaction completion

For each critical workflow, test the transaction from creation through its business endpoint. Confirm field defaults, selectors, date and quantity entry, validation messages, saves, releases, approvals, reversals, attachments, notes, and follow-up navigation. Use realistic roles and data conditions so field security and automation behave as they do in production.

Include positive and negative cases. A successful order entry proves only the normal path. Test missing required fields, credit holds, inventory shortages, approval rejection, failed integrations, duplicate references, and other exceptions the team resolves in Classic UI. These paths often open additional dialogs or screens and are more likely to expose a hidden dependency.

Reconcile the result in the database-facing application screens and downstream business records. For example, confirm that a released document has the expected status, related batch, inventory effect, and audit trail. Browser compatibility testing is not complete if the page looks correct but the transaction produces incomplete or duplicated business data.

Back to TOC

Test reports dashboards pivots and exports

Reporting components deserve their own workstream because they combine browser rendering, parameters, data retrieval, printing, and export behavior. Inventory Classic dashboards, pivot tables, report forms, inquiry exports, and links distributed by email or documentation. Identify which ones support executive, compliance, customer, and month-end decisions.

For each report, test parameter entry, date ranges, branch restrictions, drill-down links, pagination, printing, PDF output, Excel export, and scheduled delivery where applicable. Compare totals and row counts with a known baseline. Visual success is not sufficient if the exported file changes columns, formats dates differently, omits rows, or loses filters.

Acumatica's 2026 R2 transition guidance specifically calls out Classic dashboards and pivot tables among the items organizations should prepare for Modern UI. Use the browser-readiness exercise to decide which assets should be rebuilt, replaced with Generic Inquiries, moved to a supported dashboard experience, or retired because no one uses them. Confirm ownership before deleting or redesigning anything.

Back to TOC

Validate customizations and ISV solutions

Customizations can preserve business value while also increasing uncertainty during a platform change. Build a list of customization projects, custom screens, modified actions, JavaScript, themes, external widgets, and ISV packages that touch the Classic UI. Record the publisher, source repository or package location, current version, and support contact.

Ask each owner whether a Modern UI version is available and whether the current package has been certified for the target Acumatica patch. Do not treat the absence of a vendor warning as confirmation. Request written compatibility guidance for components that affect Tier 1 workflows, and retain that response with the change evidence.

Regression tests should cover both the visible customization and its side effects. Confirm custom fields, selectors, calculations, actions, pop-up dialogs, file handling, automation schedules, and data sent to integrations. If a workaround requires temporarily disabling a customization, document the business consequence and the precise steps for restoring it. Avoid making emergency production edits that cannot be reproduced in source control.

Back to TOC

Protect integrations and automated processes

Many integrations run without a browser, but their configuration, monitoring, and exception handling may still rely on Classic UI pages. Inventory API connections, import and export scenarios, scheduled processes, email processing, commerce connectors, bank feeds, tax services, document capture, and robotic automation. Identify the screen an administrator uses when a job fails.

Test routine execution and at least one controlled exception. Confirm credentials, endpoint behavior, queues, retry logic, logs, and reconciliation. If users normally open a Classic screen to correct a rejected record, validate that recovery path explicitly or provide a Modern UI alternative before the browser change reaches production.

Desktop automation deserves special scrutiny because it may depend on page structure rather than supported APIs. A patch or interface change can break selectors even when a human user sees a functional screen. Record every bot or script that interacts with the browser, rerun it in the patched sandbox, and prefer a supported integration approach when redesign is practical.

Back to TOC

Define evidence and acceptance criteria

A readiness decision should be based on evidence that another reviewer can understand. For each test, store the environment, Acumatica build, browser version, user role, test data, steps, expected result, actual result, screenshots when helpful, defect reference, tester, and date. Link the evidence to the change ticket rather than leaving it in personal notes or chat.

Acceptance criteria should describe business completion. Replace vague results such as screen opens with outcomes such as warehouse user creates and confirms a shipment, prints the required document, and verifies the released status using the assigned role. This wording makes it harder to close a test before the transaction reaches its real endpoint.

Classify defects by operational impact and assign a disposition: fix before production, accept temporarily with a documented workaround, remove the dependency, or defer with business approval. Re-run failed tests after any patch or configuration change. A final readiness summary should show passed Tier 1 workflows, unresolved risks, owners, and the explicit go or no-go decision.

Back to TOC

Plan backup rollback and recovery

The production plan should state what is being backed up, who verifies the backup, how long restoration would take, and what data could be created between the change and a rollback decision. Coordinate application, database, file storage, customization, and configuration backups according to the hosting model and established support procedures.

Define rollback triggers before the maintenance window. Examples include failed login for a critical population, inability to complete a Tier 1 transaction, widespread Classic UI rendering failure, corrupted output, or integration backlog beyond an approved threshold. Name the person authorized to call the rollback and the latest time that decision can be made safely.

A browser workaround can be part of recovery, but it is not identical to restoring the application. If Firefox is approved as a temporary path, prepare installation, security policy, bookmarks, user instructions, and support ownership in advance. Test the workaround with the same critical roles. Remove the temporary configuration once the supported patch path is stable.

Back to TOC

Communicate with users before and after the change

User communication should be specific enough to change behavior without overwhelming people with browser-engine detail. Tell affected users which workflows are in scope, the maintenance window, what normal behavior should look like, how to report a blank or incomplete screen, and whether a temporary browser is approved. Include screenshots or screen IDs when teams use similar names for different functions.

Ask department leads to nominate testers and confirm availability during the validation window. For shift-based operations, include warehouse, field, or production users who may not read the same channels as office teams. Provide a short script for the service desk so reports are tagged consistently with browser version, screen ID, time, user role, and business impact.

After deployment, send a clear completion notice only when the smoke tests pass. If risk remains, state the affected workflow, workaround, owner, and next update time. During the first full business cycle, monitor tickets and transaction queues. Close the change after process owners confirm that operations are stable, not immediately after the technical installation finishes.

Back to TOC

Coordinate finance operations IT and leadership

The deadline crosses organizational boundaries. IT owns browser deployment, infrastructure coordination, backups, and technical change control. Acumatica administrators own version verification, patch planning, security roles, and application evidence. Process owners define critical transactions and acceptance. Leadership resolves schedule conflicts and accepts residual business risk.

Finance should identify period-close, payment, billing, and reconciliation windows that restrict change timing. Operations should identify shipping, receiving, manufacturing, field, and customer-service peaks. Security should review temporary browser exceptions and access implications. The service desk should know how to distinguish a browser-rendering issue from authentication, network, or application availability problems.

Use one readiness meeting with a concise decision pack rather than several disconnected technical updates. The pack should show environment status, critical workflow results, open defects, rollback readiness, user communication, and the Modern UI follow-up plan. That structure keeps the immediate patch decision focused while making long-term dependencies visible to leaders who control resources and priorities.

Back to TOC

Move from emergency patching to Modern UI readiness

The patch reduces the immediate Chromium risk, but organizations should use the resulting inventory to plan Modern UI work. Acumatica's direction is clear: Modern UI is the default in 2026 R2, users cannot normally switch interfaces when a Modern version exists, and Classic-only functionality is moving toward retirement. A successful patch should therefore buy controlled migration time, not justify indefinite delay.

Group remaining items into standard screens, configuration differences, custom screen conversions, dashboards and pivots, training gaps, ISV dependencies, and process redesign. Estimate each group separately because the skills and validation effort differ. A custom screen may require TypeScript and layout work, while a familiar standard screen may need only role-based testing and training.

Set milestones around business workflows rather than raw screen counts. Completing ten low-value screens does not reduce risk if the only shipping exception process remains Classic-only. Prioritize items by the same operational tiers used for browser testing, and require a business owner to accept the Modern UI result. Update process documentation and support materials as each dependency is retired.

Back to TOC

Measure readiness with useful operational metrics

Metrics should reveal whether risk is shrinking. Track the number of Classic UI dependencies by tier, percentage with a confirmed Modern UI path, percentage of Tier 1 tests passed, environments on the approved patch, open defects by severity, users trained, and workflows still dependent on a temporary workaround. Report trends and owners, not only a single green status.

After production deployment, measure failed-page incidents, service-desk volume, transaction backlog, workaround usage, and time to resolve browser-related reports. Compare these results with the baseline. A low ticket count can indicate success, but it can also mean users created manual workarounds without reporting them, so check with process owners during the first critical cycle.

For the Modern UI program, add adoption and quality measures: active users by interface, custom screens converted, acceptance tests completed, unresolved behavior gaps, and time spent supporting legacy paths. Review the metrics monthly until Tier 1 Classic dependencies reach zero. Retire emergency browser policies and temporary documentation as soon as the supported operating model is stable.

Back to TOC

Common mistakes that increase deadline risk

The first mistake is assuming that an automatic SaaS update removes the need for testing. Delivery responsibility and business acceptance are different. The second is checking only the home page. A mixed-interface tenant can appear healthy while a specific Classic workflow fails. The third is recording a major version without the full build and current patch evidence.

Other common failures include testing only with an administrator, excluding exception paths, overlooking Classic dashboards and pivots, forgetting third-party add-ons, and using a temporary browser without security approval. Teams also lose time when results are stored in chat messages instead of a shared test record, or when no one has authority to decide whether a defect blocks deployment.

The most expensive mistake is treating the compatibility fix as the end of the project. That leaves the organization exposed to the next browser or platform change and compresses the Modern UI migration into a later upgrade window. Use the November deadline as a forcing function to create accurate ownership, reusable tests, and a funded retirement plan for the remaining legacy dependencies.

Back to TOC

Executive decision checklist

Before approving production work, leaders should be able to answer the following questions. Do we know every production and sandbox version? Have we confirmed the current Acumatica patch guidance? Are all Tier 1 Classic workflows identified and tested in the managed browser estate? Are customizations, ISV products, reports, integrations, and exception paths included? Is the backup and rollback decision documented? Are users and the service desk prepared?

They should also ask what remains after the patch. Which Classic dependencies lack a Modern UI path? Which items block a future 2026 R2 or later upgrade? Who owns each conversion, validation, or vendor escalation? What is the target date for removing temporary browser workarounds? How will progress be measured and reported?

A responsible go decision does not require zero defects, but it does require transparent residual risk, named owners, workable contingencies, and business acceptance. If those conditions are absent, the correct action is to adjust the window or reduce risk before proceeding. The November date is important, but an undocumented emergency change can create more disruption than the browser change it is intended to prevent.

Back to TOC

Production cutover runbook

The cutover runbook should convert the approved plan into a timed sequence that anyone on the change team can follow. Begin with a readiness checkpoint confirming the maintenance window, backup completion, patch package, administrator access, tester availability, communication status, and rollback authority. Record the starting Acumatica build and browser versions before anyone changes the environment.

During implementation, log each action and its result. Typical steps include pausing scheduled work when required, applying the approved patch, restarting relevant services, confirming application availability, validating login, and releasing the environment to smoke testers. Avoid adding unrelated configuration or customization changes to the same window. A narrow scope makes troubleshooting and rollback decisions faster.

The smoke-test order should follow business risk. Test authentication and one high-value transaction first, then complete the remaining Tier 1 scenarios, integrations, reports, and exception paths. Establish a time limit for investigation so a difficult defect does not consume the rollback window. Record whether the team proceeds, pauses, uses a temporary contingency, or restores the previous state.

Close the maintenance window with a formal handoff. Confirm the final build, browser results, open issues, workaround status, monitoring owners, and next communication time. Preserve the runbook and evidence because the same tests can support a later patch, browser release, or Modern UI conversion. A reusable runbook turns one deadline response into a stronger operational control.

Back to TOC

First business day monitoring plan

The highest-value monitoring occurs when users resume normal work. Staff the service desk and application team around the first order cycle, shipment wave, approval run, scheduled integration, and financial processing period. Ask process owners to report both failures and unexpected manual steps. A workflow can technically complete while taking much longer or forcing users into an undocumented workaround.

Create a focused incident category for Classic UI and Chromium reports. Collect the user, time, browser version, Acumatica build, screen ID, navigation path, screenshot, and business impact. Compare similar reports before changing the system; several departments may be seeing one shared issue. Separate browser rendering problems from access rights, network latency, stale cache, customization defects, and unrelated application errors.

Monitor server and application indicators alongside user feedback. Review error logs, background job status, integration queues, email processing, scheduled reports, and transaction backlogs. If the organization deployed a temporary alternate browser, track who uses it and for which workflows. That usage is a measurable residual dependency and should decline after the supported fix is confirmed.

At the end of the first business day, issue a concise status summary: transactions tested, incidents received, resolutions, outstanding risks, and the next review point. Continue monitoring through the next critical weekly or month-end cycle if those processes were not exercised during the initial window. Do not close the change solely because the maintenance period ended without an alert.

Back to TOC

Long term governance for browser dependent ERP features

Browser dependencies should become part of the ERP governance model. Add supported browsers and managed versions to the platform standard, identify who reviews browser deprecation notices, and connect that review to Acumatica release and patch management. Include browser changes in the same calendar used for operating-system, identity, database, and integration dependencies.

Maintain a reusable compatibility test pack with role-based transactions, reports, customizations, and exception paths. Run a focused subset before major browser deployment and the full pack for high-risk application or platform changes. Automate evidence collection where it is reliable, but retain human acceptance for workflows whose success depends on business judgment, usability, or printed output.

Governance should also prevent new Classic dependencies. Require new customizations and ISV purchases to state their Modern UI support, browser requirements, upgrade policy, and test responsibility. Review existing custom work during each Acumatica upgrade cycle and remove assets that no longer have an owner or business purpose. This reduces the volume of emergency analysis during future deadlines.

Finally, keep leadership informed through a small set of operational measures: unsupported environments, Tier 1 legacy dependencies, patch compliance, open vendor gaps, and Modern UI conversion progress. The purpose is not to create more reporting. It is to make hidden platform risk visible early enough that the organization can schedule work before an external vendor date controls the timetable.

Back to TOC

Patch validation checklist

Confirm the target Acumatica version and exact patch against the latest vendor notice. Verify backup and rollback ownership. Test a Chromium browser in sandbox. Exercise each critical Classic UI workflow from login to completion. Validate custom screens, reports, dashboards, pivot tables, attachments, exports, and approval steps. Record results. Communicate the production window and contingency browser. Complete production smoke tests and keep the evidence with the change record.

Back to TOC

Frequently Asked Questions

Will the November 17, 2026 date affect every Acumatica customer? The exposure depends on version, patch level, browser, and whether users still rely on Classic UI. Verify the current Acumatica notice for your environment.

Does applying the patch remove the need to move to Modern UI? No. It addresses browser continuity; it does not replace the migration and customization work required for the Modern UI direction.

Can Firefox be the permanent answer? Treat it as a temporary contingency only. It may preserve access in some scenarios while you complete the supported patch or upgrade path.

Which items need the most careful testing? Custom screens, Classic-only forms, dashboards, pivots, workflow exceptions, ISV components, and actions used during time-sensitive business cycles should be explicit test cases.

What should a PCS customer do? Confirm the applicable patch and installation process with Acumatica or your partner, then patch and validate before the deadline.

What should a SaaS customer do? Confirm the delivered patch status and validate business-critical workflows in your tenant; automatic delivery does not replace acceptance testing.

Can an organization still use Classic UI in 2026 R2? The current documentation says Classic UI is disabled by default in 2026 R2, with limited legacy access mechanisms and remaining Classic-only functionality warned for later retirement. Confirm the exact release guidance before planning.

When should the work start? Immediately. The October 2026 browser behavior change described in Acumatica's updated notice means waiting until November can leave too little time for a controlled regression cycle.

Back to TOC

Sources

• Chrome for Developers: Removing XSLT for a more secure browser
• Acumatica Community: Chromium XSLT Deprecation Affecting Classic UI
• Acumatica Community: Classic UI Deprecation in 2026 R2 and FAQ
• Acumatica Beacon: Customization Update to 2026 R2 - Retirement of the Classic UI

Biz-Tech Services can help teams inventory Classic dependencies, validate patches, and plan a controlled Modern UI transition without losing sight of business-critical workflows.

---

by Gary

Acumatica AI Assistant in 2026 R2: Use Cases, AI Units, GI Security, and Governance

Acumatica AI Assistant in 2026 R2: Use Cases, AI Units, GI Security, and Governance

A practical guide to governed reporting, AI Units, Generic Inquiry security, and rollout controls.

Why AI Assistant governance is an operating issue

AI Assistant makes ERP reporting more conversational: a user can ask a business question in ordinary language and receive a text answer, table, chart, or pivot table. That convenience can remove a real bottleneck for finance, operations, and project teams that otherwise wait for a report or build a one-off inquiry. It also changes the operating model. The quality, relevance, and visibility of answers are shaped by the Generic Inquiries that administrators choose to expose, the descriptions that make those inquiries understandable, and the roles assigned to users. Governance is therefore not an after-the-fact security review. It is the design work that determines what the assistant can reliably answer and who can use it.

For a 2026 R2 organization, the practical question is not whether natural-language access to ERP data is valuable. It is whether the business can introduce it with a defined data boundary, an accountable owner, a measured usage model, and a review path for decisions that matter. This guide explains how to set that foundation. It focuses on reporting and analysis, where an assistant can accelerate discovery while people remain responsible for interpretation, approval, and action.

Back to TOC

What Acumatica AI Assistant is and is not

Acumatica AI Assistant is a natural-language interface embedded in Acumatica. In the documented 2026 R2 experience, it can answer questions using Generic Inquiries configured by an administrator, preserve context within a conversation, and display information as text, lists, tables, charts, or pivot tables. A useful governance principle follows directly from that design: the assistant is not a general, unrestricted search engine over the ERP database. Its useful data scope is the intentionally exposed inquiry set.

It is also important not to overstate what it does. The official FAQ describes AI Assistant as limited to querying data through configured and exposed Generic Inquiries; it does not update records or perform actions. That boundary makes the first rollout easier to contain, but it does not eliminate the need for oversight. A response may still be misunderstood, based on an inappropriately broad inquiry, or used as the basis for a decision without the correct business context. Treat AI Assistant as a governed analysis interface, not as an autonomous decision maker.

Back to TOC

What changed for AI Assistant in 2026 R2

Acumatica states that AI Assistant became generally available with the 2026 R2 release for customers on 2026 R1 and later, subject to obtaining it through the customer subscription process. The 2026 R2 materials also describe context-aware assistance, a self-aware capability that can state its limits, a Help Agent informed by Beacon content, and the ability to turn a question into a dashboard widget. These changes make the assistant more visible to business users, which is exactly why role design and operational ownership should be settled before broad enablement.

General availability should not be read as a signal to enable everything at once. Availability, licensing, entitlement, and actual behavior should be checked in the target tenant before publication or rollout. A controlled pilot lets the organization validate the version, enabled features, user experience, inquiry results, and AI Unit consumption on its own data. That evidence is more useful than assumptions drawn from another customer, another edition, or an earlier release.

Back to TOC

Start with business questions rather than with a feature list

The best first questions are narrow, repeatable, and already familiar to the business. A controller might want to review open receivables by aging band and customer class. A purchasing manager might want to identify overdue purchase orders with a material impact on customer commitments. A project leader might want to compare actual cost with budget for active projects. Each question has a clear owner, a recognizable source of truth, and a result that a person can validate against an existing report or inquiry.

Avoid beginning with questions that combine confidential data, undefined metrics, or many competing exceptions. “Which customers are risky?” sounds useful, but it depends on a governed definition of risk, appropriate data access, and human judgment about how the result will be used. Start by documenting the question, expected output, intended audience, data owner, and a simple acceptance test. If a result cannot be reconciled to a trusted baseline, the inquiry or its descriptions need work before more users depend on it.

Back to TOC

Make Generic Inquiry exposure a deliberate data boundary

Generic Inquiries are the central governance control for AI Assistant. Acumatica documentation explains that an administrator can select Expose to AI Assistant on a published inquiry, add descriptions for the inquiry, fields, and parameters, and process the descriptions through AI Assistant Data Processing. The assistant then works from that approved set. An exposed inquiry is not merely a reporting artifact; it becomes a curated interface between users’ natural-language questions and business data.

Use a small, reviewable inventory. For every candidate inquiry, record the business purpose, owner, audience, sensitive fields, key filters, expected refresh behavior, and review date. Remove experimental inquiries from the initial set. Prefer purpose-built inquiries over broad “everything” inquiries, and test them with representative users. When an inquiry changes materially, re-evaluate its exposure and reprocess its AI description. This limits accidental scope expansion and gives the organization a clear answer when someone asks what the assistant is allowed to use.

Back to TOC

Design roles and access before enabling users

The official FAQ says AI Assistant inherits access rights defined on each Generic Inquiry, so users see only data they are authorized to view. It also notes that administrators initially have access and additional users need the AI Assistant User role. Inherited security is valuable, but it is not a substitute for reviewing whether the underlying inquiry itself expresses the intended business boundary. A user who legitimately has broad inquiry access may still not be the right audience for a broadly exposed conversational analysis experience.

Map access in three layers: application roles, inquiry access, and the AI Assistant User assignment. Ask who should ask questions, which inquiries they should be able to use, and who can change the inquiry definitions. Separate ordinary business users from people who administer exposed inquiries. Test with non-administrator pilot accounts, including edge cases such as regional managers, temporary staff, and users with mixed finance and operations responsibilities. Document removals as carefully as grants, because a role change may be the fastest way to reduce exposure when an issue is found.

Back to TOC

Write descriptions that improve answers without revealing more data

AI descriptions help the assistant associate business language with the right inquiry, field, and parameter. They should explain what a measure means, the period it covers, the intended use, and any important caveat. For example, an “open invoice balance” field description can clarify whether it excludes disputed documents, whether the amount is in base currency, and which date drives aging. Clear descriptions reduce ambiguous questions and make it easier for users to recognize whether an answer fits the decision at hand.

Descriptions should not become a secondary data store. Do not put credentials, private customer notes, hidden operating procedures, or sensitive assumptions into a description simply because it is convenient. Use a review checklist that includes accuracy, business terminology, security sensitivity, and ownership. If a query depends on a parameter, write a clear instruction for that parameter so users understand the boundary rather than receiving a plausible-looking result built on an accidental default.

Back to TOC

Establish an AI Units budget and monitoring routine

AI Units are Acumatica’s measure of AI Assistant consumption. Acumatica describes them as reflecting a blend of model input, output, and cache tokens, and identifies the AI Unit Consumption screen and License Monitoring Console as places to monitor usage. If the monthly allocation is exhausted, the assistant is unavailable until the allocation resets or additional units are obtained. That makes consumption monitoring both a financial and a continuity control.

Set a monthly owner and an escalation threshold before launch. During a pilot, measure consumption by use case rather than only in aggregate: recurring executive questions, exploratory analysis, training activity, and repeated retries can have very different patterns. Review sudden changes in use as an operational signal. A spike may reflect strong adoption, confusing descriptions, an overly broad prompt pattern, or a process that should be served by a saved dashboard instead. Publish a simple user guideline: ask concise, specific questions; review the proposed result; and use established dashboards for routine monitoring where that is a better fit.

Back to TOC

Create a human review policy for decisions and exceptions

A conversational answer can be a useful starting point, but it should not silently replace a controlled business decision. Define categories that always require source verification or a second reviewer: payment holds, credit decisions, payroll-related analysis, pricing exceptions, vendor selection, project write-offs, and anything involving regulated or confidential data. The policy can be brief, but it should tell users when an AI Assistant response is informational, when it must be reconciled, and where the authoritative record remains.

For every pilot use case, decide what evidence a user should retain. In some cases a link to the inquiry result and a saved report is sufficient. In others, a supervisor approval or an exported reconciliation may be appropriate. The goal is not to create bureaucracy around simple questions. It is to ensure that a polished chart or summary does not conceal an unverified interpretation, a stale filter, or a missing exception.

Back to TOC

Treat data sensitivity as a design input

Data classification should influence which inquiries are exposed, how they are filtered, and which roles receive access. Financial figures, customer information, employee data, health information, project margins, and personally identifiable data do not all have the same handling requirements. Start with the classifications already used by the organization, then evaluate the fields included in each proposed inquiry. If an inquiry mixes useful operational data with highly sensitive fields, consider a separate, least-privilege inquiry for the AI use case.

Acumatica states that AI Assistant temporarily stores a user prompt and a record that a tool call succeeded, rather than the underlying data itself, to support follow-up questions; it also states that customer data is not used to train foundational models. Those statements are helpful, but a rollout team should still review the current contractual terms, regional requirements, retention expectations, and internal policies with the appropriate security and legal stakeholders. Do not turn a product statement into a blanket compliance conclusion.

Back to TOC

Use a pilot that can prove or disprove the rollout assumptions

A pilot should be small enough to observe and broad enough to surface real differences in language, roles, and workflows. Select a cross-functional group such as a finance analyst, operations manager, project manager, IT administrator, and the business owner of each inquiry. Give them a short set of tested questions, then allow additional questions that they record for review. Capture whether the assistant selected the appropriate inquiry, whether the result reconciled to an existing source, whether the wording was clear, and whether the user knew what to do next.

Define entry and exit criteria. Entry criteria might include published and reviewed inquiries, completed role tests, named owners, a consumption threshold, and user training. Exit criteria might include an agreed accuracy rate for the approved question set, no unresolved access issues, a documented support path, and a decision about the next inquiry group. A pilot is successful when it produces trustworthy evidence, not merely when participants say the experience is impressive.

Back to TOC

Measure quality, safety, adoption, and business value together

Do not reduce governance to a security checklist. Track four categories: quality, safety, adoption, and value. Quality can include reconciliation success for approved questions and the percentage of answers that required inquiry changes. Safety can include access-test results, sensitive-data incidents, and completed reviews of exposed inquiries. Adoption can include active users, repeat use by role, and the types of questions users ask. Value can include time saved in recurring reporting, fewer manual report requests, or faster exception identification where the business can credibly measure it.

Use the measures to decide what to improve. Low adoption might mean training is weak, but it can also mean the first inquiries are not valuable. High use with low trust is a warning sign, not a victory. A modest set of reliable, owned questions usually creates more lasting value than a large set of ambiguous inquiries that users cannot explain or reconcile.

Back to TOC

Plan for changes to data, roles, models, and releases

Governance is ongoing because the system changes. New customizations can add fields and tables. An inquiry can be revised. A person’s role can change. Acumatica can release an update that affects availability or behavior. Establish a lightweight change process: identify the changed asset, assess whether it is exposed to AI Assistant, re-test the relevant question set, reprocess descriptions where required, and update the inventory. Schedule periodic access reviews and a quarterly review of active inquiries, usage, and unresolved user feedback.

Release planning deserves special attention. Before an upgrade, validate the AI Assistant feature state, role assignments, exposed inquiries, data-processing status, key outputs, integrations around reporting, and the current contractual or entitlement details. Keep the test evidence with the upgrade record. This turns AI Assistant from an untracked convenience into a managed part of the ERP reporting estate.

Back to TOC

How Biz Tech AI Analyst fits into the conversation

Biz-Tech AI Analyst is separate from Acumatica AI Assistant. According to Biz-Tech product documentation, it is an Acumatica customization package that lets business users describe a reporting need in plain language. It can propose a new report or Generic Inquiry, explain its intended columns, tables, filters, and grouping, and build it only after the user approves the proposal. It can also propose changes to existing reports and inquiries, while preserving versions for reports and offering an undo path. It is designed to help business users create or refine reporting artifacts without writing SQL or BQL.

The distinction matters for governance. Acumatica AI Assistant is a governed question-and-answer experience over administrator-exposed Generic Inquiries. Biz-Tech AI Analyst is intended to help users create or change report and inquiry definitions within their assigned Acumatica rights and approval flow. Its documentation states that it does not insert, change, or delete business data; it creates or changes report and inquiry definitions. Organizations considering both should define separate owners, access policies, approval expectations, and token or licensing controls rather than treating them as interchangeable tools.

Back to TOC

A practical 30 day governance roadmap

Days 1 through 5: name an executive sponsor, operational owner, technical administrator, inquiry owners, and security reviewer. Confirm the target version and entitlement. Inventory candidate inquiries and classify their data. Days 6 through 10: choose five to ten high-value questions, review inquiry exposure and descriptions, and build a role matrix. Days 11 through 15: process descriptions, assign pilot roles, test non-administrator access, and define consumption thresholds and support routing.

Days 16 through 22: run the controlled pilot, reconcile answers, capture feedback, and correct inquiry design rather than asking users to work around bad results. Days 23 through 30: review usage, evidence, access results, and unresolved risks. Decide whether to expand to another audience, add a small set of inquiries, improve training, or pause until a control is strengthened. Repeat the cycle whenever material data, roles, or release conditions change.

Back to TOC

Common rollout mistakes to avoid

The first mistake is exposing broad inquiries because they are already available to an administrator. The second is assuming inherited access means no review of inquiry scope is necessary. The third is measuring only demonstrations and not reconciliation quality. Other frequent problems include failing to explain parameters, neglecting AI Unit thresholds, allowing a pilot to become a silent production rollout, and using AI output as a substitute for a controlled approval or financial review.

A more reliable approach is intentionally modest: a limited question set, a small user group, named owners, tested roles, and evidence that results match trusted sources. That discipline makes expansion easier because every new inquiry and audience has a clear route through the same governance process.

Back to TOC

Conclusion and next step

Acumatica AI Assistant can make governed ERP information easier to reach, but it does not create governance by itself. The organization creates it by curating Generic Inquiries, assigning roles deliberately, monitoring AI Units, testing answers, and keeping people accountable for decisions. The strongest rollout is one where users can explain what the assistant can use, why they can see the answer, and how they would verify it.

Begin with a short AI reporting and security workshop: select the initial business questions, review the underlying inquiries and access model, define pilot success measures, and document the owner for each control. Biz-Tech Services can help organizations assess reporting design, Generic Inquiry exposure, security roles, custom development, and the practical path from pilot evidence to an operational rollout.

Back to TOC

Frequently Asked Questions

Is Acumatica AI Assistant generally available in 2026 R2?

Acumatica states that, as of the 2026 R2 release, the managed-availability program concluded and AI Assistant is generally available to customers on 2026 R1 and later. Confirm entitlement and configuration for the target tenant before rollout.

What data can AI Assistant use?

It works through Generic Inquiries that an administrator has configured and exposed to AI Assistant. The organization should maintain an inventory of those inquiries and review their purpose, scope, and ownership.

Does AI Assistant respect Acumatica security?

Acumatica says it inherits access rights defined on each Generic Inquiry. Organizations should still test actual role combinations with non-administrator pilot accounts and review the inquiry scope itself.

Can AI Assistant change ERP records?

The official FAQ describes it as limited to querying configured Generic Inquiries; it cannot perform actions or update records.

What are AI Units?

AI Units measure AI Assistant consumption. Monitor them in the AI Unit Consumption screen and License Monitoring Console, set thresholds, and plan for the possibility that the monthly allocation may be exhausted.

Why do Generic Inquiry descriptions matter?

Descriptions help the assistant interpret business language and parameters. They should define measures and constraints clearly without storing sensitive information that does not belong in a description.

How is Biz Tech AI Analyst different?

Biz-Tech AI Analyst is a separate customization that proposes and, after user approval, creates or changes reports and Generic Inquiries within a user’s rights. It does not change business data.

What is the safest first rollout?

Start with a small pilot of high-value, reconcilable questions; validate roles, exposed inquiries, usage, and user understanding before expanding.

Back to TOC

Sources

• Acumatica AI Assistant FAQ
• Exposing Generic Inquiries to AI Assistant
• Working with AI Assistant general information
• Acumatica artificial intelligence overview
• Acumatica on AI ERP evaluation and governed access
• Biz Tech AI Analyst product documentation — Internal Biz-Tech product documentation, September 2026

Back to TOC

---

by Gary

Modern UI Migration Readiness

Modern UI Migration Readiness

Prepared for Biz-Tech Services | Last verified 13 October 2026

Acumatica Modern UI migration readiness is the discipline of proving that your people, processes, customizations, and dependencies can operate safely in the modern interface before a production upgrade makes it the default. This guide explains what to inventory, test, train, remediate, and measure so the migration supports the work that matters most.

Table of Contents

• Why Modern UI readiness is now a business priority
• What changes with Acumatica 2026 R2
• Build a Modern UI inventory before changing settings
• Assess customizations and custom screens
• Audit integrations, ISV products, and embedded experiences
• Decide the future of dashboards, pivot tables, and inquiries
• Map end-to-end workflows by role
• Set up a safe, representative test environment
• Create a role-based testing strategy
• Plan user adoption around recurring work
• Protect security, personalization, and controls
• Measure performance and accessibility in real conditions
• Sequence remediation and make tradeoffs explicit
• Run a rehearsal and production cutover
• Define readiness metrics and the next practical step
• A practical four phase migration plan
• How finance operations should validate the new experience
• How operations teams should validate warehouses and production
• Common readiness mistakes and how to avoid them
• Modern UI migration readiness checklist
• Frequently Asked Questions
• Sources Used

Why Modern UI readiness is now a business priority

Modern UI migration readiness is no longer a cosmetic ERP initiative. It determines whether people can complete the work that creates invoices, receives goods, closes jobs, posts time, releases payments, and answers customers. Acumatica 2026 R2 makes Modern UI the default experience and removes the normal ability to switch an otherwise available form back to Classic UI. Acumatica also states that Classic-only forms are planned to become unavailable in 2027 R1. The practical implication is simple: an organization that still depends on Classic-only assets must treat them as a visible operating risk, not as a future enhancement backlog.

The leadership question is not whether users prefer a familiar layout. It is whether every business-critical path has a supported, tested Modern UI route. The migration affects finance, operations, IT, reporting, internal controls, external integrations, and adoption. A good program gives each of those groups a role: business owners define the essential outcomes, IT validates technical compatibility, developers remediate UI-specific work, and executive sponsors decide which risks are acceptable.

This guide is a readiness framework, not a claim that every Acumatica tenant has the same gaps. Feature coverage, custom packages, ISV products, deployment model, version, and business process all matter. Use it to create an evidence-based inventory and a go/no-go decision before a release window is fixed.

Back to Table of Contents

What changes with Acumatica 2026 R2

In 2026 R2, Modern UI is the standard user experience. When a form has a Modern UI version, Acumatica opens it in Modern UI. The ordinary UI-selection options are no longer presented in the installer, system menu, Site Map, or Site Preferences. Administrators can temporarily enable legacy behavior through a web.config setting, but that is a troubleshooting measure, not a migration strategy.

The release still allows access to some Classic-only functionality, but it warns that the capability is being retired. Acumatica specifically identifies unmigrated dashboards and pivot tables, wizard forms, the Customization Editor Layout Editor, custom forms that have not been converted, and other Classic-only forms. Teams should record each of these items, identify its business owner, and decide whether to migrate, replace, retire, or defer it with documented risk acceptance.

Do not confuse an interface transition with a data conversion. Acumatica describes the switch as an interface change: records, transaction history, and configurations remain in the same application. However, an unsupported UI customization can make data difficult to view, enter, or act on. Readiness therefore focuses on business behavior and usability, not on moving master data between systems.

Back to Table of Contents

Build a Modern UI inventory before changing settings

Start with discovery, not conversion. Build one inventory covering standard forms, custom and customized forms, dashboards, pivot tables, generic inquiries, reports, mobile projects, embedded links, personalization, browser scripts, code-behind files, third-party extensions, and documented workarounds. Include the screen ID, purpose, business process, frequency, criticality, owner, current UI behavior, dependencies, and proposed disposition.

Use a tiering model that reflects operational consequence. Tier one includes steps that affect cash, shipment, production, safety, statutory reporting, customer commitments, or an active project billing cycle. Tier two covers important management, analysis, and supervisory work. Tier three includes occasional or replaceable conveniences. Tiering prevents a long list of minor layout issues from obscuring a single payment, warehouse, or compliance blocker.

Inventory evidence must be observable. A screenshot, a saved test case, a package name, an ISV confirmation, a user interview, or a record of usage provides better evidence than a spreadsheet cell that says ready. Ask super users where they leave Acumatica, reopen old bookmarks, use a browser favorite, or ask another user to complete a task. Those informal detours often reveal the Classic UI dependencies that configuration lists miss.

Back to Table of Contents

Assess customizations and custom screens

Most backend business logic does not automatically become a Modern UI problem. The higher-risk items are the portions of a customization that assume Classic UI page markup, control IDs, JavaScript behavior, fixed dimensions, code-behind files, or browser-side manipulation. Acumatica notes that forms with inline JavaScript or ASPX.CS code may require additional migration work; Modern UI recalculates controls according to its design guidelines and screen size rather than preserving Classic UI size calculations.

Run compatibility validation on a copy of each package in a sandbox that matches the intended target version. Treat a successful validation as the beginning of testing, not sign-off. For every package, record the validator result, conversion work performed, published version, affected screens, source repository reference, regression cases, test owner, and remaining limitations. Do not rely on an old package file or a verbal statement that it worked on another tenant.

The Customization Project Editor includes a Convert to Modern UI command for selected screens. It can generate source files for custom screens or extension files for customized screens. Use tooling to accelerate analysis, then review the generated result against the actual workflow. Conversion cannot decide whether a legacy dialog, layout, or client-side behavior remains the right interaction for a modern responsive application.

Back to Table of Contents

Audit integrations, ISV products, and embedded experiences

A Modern UI project can fail through a dependency that is not visually obvious. ISV solutions can open a custom form, inject a toolbar action, rely on legacy behavior, or publish a customization package at upgrade time. External systems may target a screen, launch an embedded page, parse an exported view, or depend on an operator following an old navigation route. Give every vendor and internal product owner a concrete compatibility questionnaire and a due date.

Request the exact supported version, prerequisite patches, installation order, Modern UI limitations, known issues, test guidance, support contact, and cutover coverage. Ask whether the vendor has tested your target Acumatica build rather than asking whether the product supports Modern UI in general. Record the answer and test the most consequential transaction in the sandbox. A statement of compatibility without a repeatable test is incomplete evidence.

Review bookmarks, deep links, browser extensions, iframe content, scanning and printing workflows, and automated browser steps. Replace brittle screen-driven automation with supported integration patterns where possible. When a dependency cannot be modernized before the release, document the business impact, temporary procedure, monitoring, owner, and date for removal. This makes technical debt a managed decision rather than an invisible production dependency.

Back to Table of Contents

Decide the future of dashboards, pivot tables, and inquiries

Dashboards and pivot tables often contain operational knowledge that is not captured in a formal customization project. In 2026 R2, existing Classic dashboards and pivot tables can still be accessed while teams migrate what they need, but new Classic dashboards and pivot tables cannot be created when Classic UI is disabled. The useful question is not whether every artifact should be copied; it is which decision or daily action each one supports.

Classify each asset as keep and migrate, redesign, replace with a generic inquiry or report, consolidate, or retire. Then test it with the audience who uses it. Check security, filters, saved views, export, drill-down behavior, shared versus personal settings, and performance at realistic volume. A modernized dashboard that loads but provides the wrong role with the wrong slice of information has not met its purpose.

Use this work to reduce duplication. When five teams maintain similar inquiries with slightly different calculations, establish a governed owner and a clear definition. Modern UI migration is an opportunity to improve information architecture, but it should not become an unbounded analytics redesign. Keep required operational assets in the critical path and schedule broader reporting rationalization as a separate, owned initiative.

Back to Table of Contents

Map end-to-end workflows by role

Screen-level testing is necessary but insufficient. A user experiences an order, purchase, work order, project, or close as a chain of steps across screens, approvals, attachments, reports, devices, and integrations. For each tier-one workflow, map the trigger, inputs, roles, decision points, exception paths, outputs, control evidence, and downstream system effects. This establishes what “ready” means in business terms.

Finance should trace payables, receivables, cash, tax, period close, approvals, and financial reporting. Distribution should trace promise dates, allocation, warehouse execution, shipment, invoice, return, and inventory adjustment. Manufacturers should trace planning, release, material, labor, completion, quality, and cost. Project and construction teams should trace commitments, changes, time, billing, retainage, and compliance. Use your actual configuration rather than a vendor demonstration path.

Include exceptions deliberately: an approval rejection, a partial shipment, an expired lot, a failed payment, a missing attachment, a late timecard, a reopened project, or a duplicate integration message. Exception handling exposes navigation, permissions, messages, and recovery work that happy-path demos leave untouched. It also gives the business a way to decide whether a changed interaction is acceptable before it happens under pressure.

Back to Table of Contents

Set up a safe, representative test environment

A productive migration sandbox resembles production in version, configuration, packages, security, tenant structure, report definitions, data volume, and devices without creating real-world transactions. Refresh responsibly, protect sensitive data, and isolate email, payment, carrier, tax, commerce, and file-transfer endpoints. Test credentials and certificates with nonproduction endpoints wherever the provider offers them.

Establish a baseline before changing anything. Capture key financial totals, inventory quantities and valuation, open orders and commitments, scheduled jobs, integration queues, user counts, response times, and critical report output. Record filters and time stamps. The same evidence becomes the comparison pack after an upgrade or customization publication. A total without the date, branch, company, ledger, or report parameters is difficult to audit.

Promote packages in a controlled sequence and preserve source control references. Use a clean test run after each major remediation wave. If an error is discovered, log the exact build, package version, role, browser, inputs, expected result, actual result, evidence, and owner. Reproducing a defect is far less expensive than rediscovering it at cutover.

Back to Table of Contents

Create a role-based testing strategy

Write test cases in the language of work. “Open the screen” is a smoke test; “receive a serialized item, resolve a quantity exception, print the label, release the receipt, and confirm inventory and AP consequences” is a meaningful business test. Each test should name the role, preconditions, data, steps, expected result, evidence, and pass/fail owner.

Separate technical checks from business acceptance. Technical checks cover publication, login, permissions, performance, errors, supported browsers, and dependent services. Business acceptance confirms that a role can complete its recurring work and that results are accurate. Both are needed. A developer should not be the only person to certify a controller’s close workflow, and an end user should not be asked to diagnose a package publication error.

Set entry and exit criteria. A tier-one test must pass in the target version; severity-one defects must be resolved or formally rejected; reconciliations must meet agreed tolerances; vendors must confirm essential components; and training must be complete for affected roles. Use defect severity based on business impact, not on how quickly an issue seems fixable. This prevents false readiness caused by optimistic labels.

Back to Table of Contents

Plan user adoption around recurring work

People do not need a catalogue of every design change. They need to know how to complete their own work, recognize a changed behavior, and get help without inventing an uncontrolled workaround. Build short role-based learning paths around daily tasks: navigation, search, inquiries, entering and releasing documents, working with attachments, approvals, personal settings, and exception recovery.

Use current screenshots from the approved target environment. A job aid copied from Classic UI is itself a migration defect. Give super users hands-on practice before their teams and assign them a clear escalation route. Their feedback should distinguish a genuine defect from a preference, a training gap, a configuration decision, and a process problem. Each category needs a different response.

Stage communication by business rhythm. Finance may need dedicated practice ahead of close, warehouse users ahead of a peak shipping window, and project teams ahead of billing. Publish the planned switch, what users will see, the support channel, any temporary limitations, and the decision owner. Adoption becomes manageable when people see a direct connection between the training and the work waiting on their desk.

Back to Table of Contents

Protect security, personalization, and controls

Modern UI readiness must preserve least privilege. Re-test role access, branch restrictions, approval maps, workflow states, sensitive fields, attachments, report access, inquiry visibility, and exported information. Do not assume a screen that renders correctly respects the same operational boundary. Use separate roles to prove both allowed and denied behavior.

Personalization deserves deliberate governance. Users may tailor screens, fields, tabs, and layouts, but critical controls must remain discoverable and consistent. Define what is centrally managed, what is role-specific, what can be personalized, and how a user requests a correction. Preserve the evidence needed for audit and make sure job aids point to the approved workflow rather than a particular individual’s personalized view.

Review browser policies, multifactor authentication, session timeouts, shared-device behavior, and attachment handling. Work with compliance and security leads when data is exposed through embedded services, analytics, automation, or customer-facing experiences. A migration that simplifies navigation while weakening a segregation-of-duties control is not ready for production.

Back to Table of Contents

Measure performance and accessibility in real conditions

Modern UI is responsive by design, so test the real mix of workstations, display sizes, browsers, warehouse devices, and network conditions. Observe load time, search behavior, scrolling, filters, grids, popups, file upload, printing, and keyboard use during normal volume. Fixed-size Classic UI assumptions frequently surface when a screen is used on a smaller display or with a different zoom level.

Measure a small set of representative tasks instead of relying only on an overall page-load impression. For example, time how long it takes to find an order, enter a receipt, open an inquiry, approve a bill, attach a document, and release a transaction. Compare the user experience with baseline expectations, and investigate whether a gap is caused by data, configuration, customization, network, browser policy, or a third party.

Accessibility and usability are operational quality concerns. Check readable labels, focus order, error messages, keyboard navigation, contrast, responsive reflow, and the clarity of actions. Invite users who work at different experience levels to perform realistic tasks. The best migration is one in which a new user can understand the next correct action without depending on a legacy layout.

Back to Table of Contents

Sequence remediation and make tradeoffs explicit

Use the inventory and test evidence to create a risk-ranked backlog. Fix tier-one blockers first, then high-frequency pain points, then strategic enhancements. For every item, state the decision: migrate, redesign, replace, retire, defer, or accept risk. Include an owner, target date, test case, dependency, estimate, and a measurable completion condition.

Avoid a big-bang scope that combines interface conversion, an ERP version upgrade, new AI functionality, report redesign, data cleanup, process reengineering, and a new commerce connector unless there is a compelling business reason. A stable base release makes later improvement safer. Where a combined release is unavoidable, give each component its own disable path, owner, and acceptance evidence.

Escalate uncertainty early. Missing vendor confirmation, a legacy script without source, a failing high-volume inquiry, or an untested device integration is not a minor observation. It is a decision point. Executive sponsors should resolve scope, funding, timing, or risk acceptance while alternatives remain available rather than after a production window has begun.

Back to Table of Contents

Run a rehearsal and production cutover

A timed rehearsal turns a plan into evidence. Use the intended upgrade route, target packages, configuration steps, integration holds, communications, smoke tests, reconciliations, and support model. Record actual duration, deviations, dependencies, and decisions. Improve the runbook until each task has an owner, start condition, expected duration, evidence, and fallback.

The production runbook should include user communication, backup and restore verification, interface pause or queue management, the upgrade, package publication, authentication checks, smoke tests, business-process validation, reconciliation, release of integrations, and monitoring. Define exactly who can declare a hold, who can authorize rollback, and what triggers that decision. A successful installer message is not a go-live decision.

During stabilization, monitor business outcomes as well as technical telemetry. Review errors, job failures, queue backlog, failed sign-ins, support tickets, print and email activity, payment and banking flows, performance, and critical document counts. Hold short cross-functional triage sessions. Make every emergency fix traceable, tested where possible, and visible to the people responsible for the affected workflow.

Back to Table of Contents

Define readiness metrics and the next practical step

A useful dashboard reports evidence, not optimism. Track the percentage of tier-one workflows passed, number of unresolved blockers, customization and ISV confirmation status, training completion, reconciliation differences, rehearsal duration, support coverage, and known exceptions. Pair each metric with an owner and a threshold. “Green” should mean that a documented condition has been met, not that a meeting felt positive.

After release, measure adoption and value separately from readiness. Look at task completion, support demand by role, workaround use, close duration, inquiry response time, transaction exceptions, and the business measures the migration was intended to protect. Review at 30, 60, and 90 days. This prevents the organization from declaring success at cutover while recurring users struggle with a slow or inconsistent process.

The next practical step is a facilitated readiness assessment that produces a screen and workflow inventory, risk-ranked backlog, test plan, training plan, and cutover decision criteria. Biz-Tech Services can help teams assess Modern UI coverage, customizations, integrations, ISV dependencies, business processes, and adoption risks—then turn the findings into an executable migration plan.

Back to Table of Contents

A practical four phase migration plan

Phase one is discovery and alignment. Confirm the target Acumatica version and the reason for the migration; nominate process owners; inventory screens, packages, dashboard assets, ISVs, integrations, and user groups; and tier the workflows. The output is a shared fact base, not a promise that all issues are easy. Leadership should approve the critical workflow list and the decision rules before conversion work begins.

Phase two is remediation and sandbox validation. Convert or redesign screen-specific work, obtain partner and vendor confirmations, replace unsupported behavior, and run technical regression tests. Keep a daily list of new defects and decisions. Where a remediation affects a workflow, give the business owner an early opportunity to see it; waiting until the final user-acceptance session makes even a small design decision feel like a surprise.

Phase three is role-based acceptance and rehearsal. Train super users, execute the tier-one test pack, reconcile data and documents, run the cutover script end to end, and verify the support model. Phase four is production and stabilization: communicate clearly, execute the approved runbook, monitor the agreed indicators, triage issues visibly, and turn deferred improvements into an owned release plan. The phases may overlap, but each needs explicit exit evidence.

Back to Table of Contents

How finance operations should validate the new experience

Finance should establish a baseline that makes discrepancies observable. Capture trial balances by company, branch, ledger, and period; AP and AR aging; cash positions; tax reports; inventory valuation where relevant; unreleased batches; and selected financial statements. Preserve the report parameters and as-of time. This provides a stable comparison after sandbox migrations and again after production cutover.

Test complete control chains. For procure-to-pay, enter and approve a bill, process payment, handle a void or adjustment, and reconcile the result. For order-to-cash, include credit review, shipment, invoice, payment, adjustment, refund, and aging. Exercise approval paths, multiple branches, currencies, tax settings, and restricted roles that reflect production. Confirm not only that a document saves, but also that it posts and appears correctly in the reports that people rely on.

The controller or a named delegate should sign a concise acceptance pack. It should show control totals, exceptions, selected transaction evidence, payment and bank-interface outcomes, and a list of any accepted differences with an owner and due date. This is a better go-live control than a generic confirmation that finance users could sign in.

Back to Table of Contents

How operations teams should validate warehouses and production

Distribution and warehouse teams should follow inventory from demand to fulfillment and return. Test availability, allocations, purchasing, receiving, replenishment, picks, packing, shipment, invoicing, returns, transfers, cycle counts, and valuation with real item classes, warehouses, units, kits, serial or lot controls, and partial shipments. Validate labels, printers, scanners, carrier connections, and actual workstations rather than only a developer laptop.

Manufacturing teams should connect planning, scheduling, execution, material movement, labor, completion, quality, and costing. Use representative calendars, work centers, alternate resources, bills of material, routings, scrap rules, subcontract steps, and backflush behavior. A work order that looks correct on one screen may fail in the shift-level sequence that operators use, so involve the people who record labor, issue material, and resolve exceptions.

For both teams, write a manual fallback for the few processes where an external device or service could fail during cutover. Define who records the temporary transaction, how it is reconciled, and when the fallback ends. A contingency that cannot be reconciled is simply deferred risk.

Back to Table of Contents

Common readiness mistakes and how to avoid them

One common mistake is treating a compatibility check as full acceptance. Validators and converters are valuable, but they cannot prove that a role can complete an exception-heavy process or that a custom report still supports a decision. Avoid the mistake by linking each technical artifact to one or more business tests and naming a business owner who can accept the result.

Another mistake is trying to preserve every legacy interaction exactly as it was. Some behavior was designed around fixed Classic UI layouts and no longer makes sense in a responsive interface. Instead, identify the underlying business need, then choose a design that meets it in Modern UI. This reduces rework and produces a process that is easier to maintain than a screen full of special cases.

A third mistake is scheduling training after the production change. Users discover real process gaps when they practice their own work, and those discoveries need time for remediation. Begin targeted super-user practice early, use final target-version screens in materials, and reserve time between user acceptance and production for corrections.

Back to Table of Contents

Modern UI migration readiness checklist

Before approving a production move, confirm that the target version and build are recorded; Classic-only assets are identified; tier-one workflows have named owners; customizations and ISV packages have target-build evidence; integrations have been tested for normal and exception behavior; dashboards, pivots, inquiries, reports, and mobile experiences have a documented disposition; and security roles have been revalidated.

Confirm that representative sandbox data and safe endpoints are available; pre- and post-change reconciliations are defined; role-based test cases have passed; defects are categorized and either resolved or accepted; user aids and training are current; production support coverage is scheduled; a cutover rehearsal has been timed; rollback criteria and authority are known; and communications say what changes and where users get help.

Finally, make the decision explicit. The executive sponsor, IT lead, and affected business owners should review the evidence and record go, no-go, or conditional go. A conditional decision must name the condition, owner, verification method, and deadline. This last step keeps readiness from becoming an ambiguous feeling and makes the migration accountable.

Back to Table of Contents

Frequently Asked Questions

Is Modern UI mandatory in Acumatica 2026 R2?

Modern UI is the default experience in 2026 R2 and ordinary switching options are removed. Classic-only assets can still be accessed temporarily with warnings, but Acumatica says they will no longer be available beginning with 2027 R1.

Will switching to Modern UI change our Acumatica data?

The UI transition does not convert or remove business records. The risk is operational: a customization, screen, report, or workflow may need work before users can interact with data correctly in the new experience.

Do all customizations need to be rewritten?

No. Backend logic can often remain intact. Review and test UI-specific customizations, especially JavaScript, ASPX.CS code-behind, fixed layout behavior, custom screens, and client-side manipulation.

How should we test Modern UI?

Test complete role-based workflows in a representative sandbox. Include normal and exception paths, permissions, integrations, reports, devices, reconciliations, and business-owner acceptance.

What should we do with Classic dashboards and pivot tables?

Inventory them, identify the decision they support, and choose to migrate, redesign, replace, consolidate, or retire each one. Existing Classic assets remain temporarily available in 2026 R2, but new Classic dashboards and pivot tables cannot be created when Classic UI is disabled.

Can we rely on EnableLegacyUI as our long-term solution?

No. Treat it as a short-term diagnostic or transition option. A sustainable plan removes reliance on Classic-only functionality before it becomes unavailable.

Who should own the migration?

IT owns environment and technical compatibility; business owners own workflow acceptance; developers own remediation; change leads own adoption; and an executive sponsor owns priorities, risk acceptance, and the final go/no-go decision.

What should block a production cutover?

A failed tier-one workflow, unsupported dependency, unresolved security issue, material reconciliation difference, unproven recovery procedure, missing vendor support, or incomplete business acceptance should block release.

How long does Modern UI migration take?

The answer depends on the number and complexity of customizations, third-party products, workflows, users, environments, and unresolved legacy dependencies. A discovery inventory and timed rehearsal provide a more reliable estimate than a generic timeline.

What is the most important first step?

Build a risk-ranked inventory of business-critical screens, customizations, dashboards, integrations, ISV products, and workflows. Then verify every tier-one item in a target-version sandbox.

Back to Table of Contents

Sources Used

1. Acumatica 2026 R2 Classic UI retirement guidance
2. Acumatica announcement: Classic UI deprecation in 2026 R2
3. Acumatica 2026 R2 release announcement
4. Migrating custom frontend code to the Modern UI
5. Acumatica Customization Project Editor: Screens
6. Acumatica 2025 R2 release announcement
7. Modern UI features overview 2025 R2 announcement
8. Acumatica support and documentation portal

---

by Gary

Acumatica 2026 R2 Upgrade Guide

An Acumatica 2026 R2 upgrade should move through six decisions: choose a supported release path, identify dependencies, prove the upgrade in an isolated copy, validate business results, rehearse recovery, and authorize production. Modern UI readiness deserves early attention, followed by custom code, connected applications, and financial controls. Approve the move when evidence shows that people can complete essential work and that the team can recover within the agreed outage window.

The difficult part is often the space between systems. A sales order can look correct while its shipment is missing from a carrier platform. An invoice can post while a customized report classifies it incorrectly. This guide explains how to expose those problems before they affect customers, employees, or cash flow.

Acumatica announced the general availability of 2026 R2 on October 1, 2026. The practical guidance below is written for business sponsors, finance and operations managers, system administrators, and implementation teams planning that release. Product facts are linked to official documentation; the readiness framework and examples are planning recommendations, not reported customer results. Sources checked: November 2, 2026. Official release announcement

What should an Acumatica 2026 R2 upgrade achieve?

The first outcome is dependable operation on an approved platform. The second is the ability to introduce improvements without carrying forward avoidable technical debt. Treat these as separate acceptance decisions so that an attractive feature does not conceal an unresolved operational dependency.

Begin with a short statement of business intent. A wholesale distributor might need to preserve its daily shipping capacity while preparing for better delivery commitments. A manufacturer might need to keep production reporting accurate while planning a later scheduling initiative. A project business might prioritize uninterrupted billing and predictable access for field staff. These are example objectives, not assumed benefits of installing the release.

Define what must be true on the first working day. Specify the processes that must run, the roles that must perform them, the reconciliations that must pass, and the available support. Make the statement concrete enough that an operations manager could determine whether the project met it without reading a deployment log.

Then identify improvements that can wait. A redesigned dashboard, an additional automation, or a new external collaboration process may deserve investment, but each introduces its own decisions and tests. A controlled upgrade can establish the platform for those changes while keeping their acceptance separate.

For the steering team, the useful question is: what evidence would persuade us to postpone? Agree on that answer before booking the production window. A missing essential integration, unexplained accounting difference, or unproven recovery method should remain a blocker even when most of the project is complete. This makes the decision consistent when schedule pressure rises.

Back to TOC

Which release facts must be confirmed before planning?

Record the source build, proposed target build, installation model, and approved upgrade sequence before estimating effort. A release name such as 2026 R2 is not sufficiently precise for a deployment decision. Packages, fixes, dependencies, and known issues need to refer to the actual combination the team will test.

Ask the implementation owner to produce a short release record containing the current application and database versions, the selected installation package, the applicable release notes, and any intermediate upgrade required for that starting point. This guide does not assert a universal direct upgrade path. Confirm the path against the current release documentation and your support provider.

Separate availability from entitlement. Acumatica's release overview describes AI, analytics, industry workflows, portals, payments, and Modern UI developments. It is useful for selecting evaluation topics, but it does not establish that every capability is licensed, configured, or ready in a particular environment. Acumatica release overview

Give each proposed addition a named owner and a verified prerequisite list. Include the edition or subscription where relevant, required configuration, compatible third-party versions, permissions, training, and operating costs. A feature with unresolved prerequisites belongs in a conditional scope list rather than the first-day commitment.

Finally, control changes to the target. If a different build becomes the preferred candidate during testing, record why it changed and which evidence must be repeated. Do not silently apply a newer package because its version number is higher. The production release record should identify exactly what passed acceptance and who approved any difference from the rehearsal.

Back to TOC

How should you decide when to upgrade?

Choose the production date by combining support requirements, technical readiness, and the operating calendar. A date is workable only when the necessary people, vendors, and recovery resources will be available throughout the interruption and the first critical business cycle afterward.

Map the events surrounding a candidate window. Finance may be closing a period or preparing a payment run. Distribution may face a carrier cutoff or seasonal sales event. Manufacturing may be changing shifts or launching a long planning run. Project teams may be preparing contractual billing. A quiet weekend on the office calendar may still be a demanding period for connected systems.

Confirm the provider's responsibilities early. For a hosted environment, distinguish the work performed by the hosting provider from application testing, customization remediation, and user preparation. For customer-managed infrastructure, assign responsibility for the operating system, database, application, network dependencies, and backups. Do not assume that one vendor owns every layer.

Discuss scheduling constraints with the partner or provider using the customer's actual subscription and support arrangement. Public release announcements cannot establish a particular customer's contractual upgrade deadline. Record the confirmed schedule, notice requirements, and options if acceptance is incomplete.

Build contingency into the plan. A late vendor assembly, inaccessible test endpoint, or incomplete inventory can consume the time intended for business testing. Protect that testing time by moving the date or reducing optional scope. Compressing acceptance to preserve an early estimate converts a planning issue into an operating risk.

Back to TOC

Build an inventory around business processes

An effective inventory follows work from its starting event to its final business result. Listing servers and customization packages is necessary, but it does not show which missing component will prevent an employee from completing a task.

Start with a small number of complete processes: order to cash, purchase to payment, inventory movement, production execution, project billing, and financial close. Add service, payroll, or other processes where they apply. For each one, trace the records, approvals, reports, external systems, devices, and scheduled jobs involved.

Record the business owner and technical owner separately. The business owner defines the acceptable outcome and fallback. The technical owner explains the dependency and fixes it. Where no one can identify an owner, schedule discovery before assuming that the component is safe to retire or ignore.

Include infrequent work. A daily test cycle will not naturally reveal a monthly bank export, quarterly report, annual adjustment, or overnight batch that only runs under particular conditions. Use schedules and interviews with process owners to locate these activities. Give them explicit rehearsal dates rather than hoping they appear during general testing.

Classify each dependency by consequence. An item that stops shipping or breaks a financial control should receive attention before a cosmetic convenience. Record whether a manual alternative exists, how much volume it can handle, who approves it, and how long it can remain in use. A workaround without capacity or reconciliation is only an idea.

The resulting inventory should answer a practical question: if this component fails during the upgrade, which process is affected, who decides what happens next, and where is the evidence needed to restore service?

Back to TOC

What does Modern UI change for the upgrade?

Modern UI readiness is a workstream that needs its own inventory, conversion decisions, and user acceptance. Test the tasks that employees perform through the interface, including exception handling and secondary actions, rather than treating a screen that opens as proof of readiness.

The 2026 R2 technical guidance identifies Modern UI as the default and describes a transition for forms available only in Classic UI. Those forms can remain accessible with warnings in 2026 R2, while their availability ends in 2027 R1. The Community announcement states that customers cannot turn off Modern UI; the technical page also documents a temporary legacy configuration. Because those statements have different scope, do not assume that a legacy setting provides an approved production fallback. Resolve any exception for the exact build and support arrangement. Classic UI retirement documentation Community deprecation FAQ

Create a task list for each important role. Include navigation, record search, data entry, selectors, attachments, approvals, mass processing, exports, printing, and corrections. Review custom screens, dashboards, pivot tables, browser scripts, and procedures that depend on the earlier interface.

For each dependency, decide whether to convert it, replace it with standard behavior, or retire it after confirming that it is unused. If a temporary dependency is accepted, attach an owner, a migration deadline, and a tested operating path. Avoid leaving the issue as an unassigned note for the next release.

Involve users while there is time to change the design. Ask a customer-service representative to correct a partially fulfilled order, or a controller to investigate a disputed balance. Such tasks reveal missing context and navigation problems that a simple create-and-save test may overlook.

Back to TOC

Confirm infrastructure without confusing support and capacity

For customer-managed installations, validate platform compatibility before scheduling the application change. Then assess capacity using representative workloads. Meeting a minimum requirement does not demonstrate that the environment can handle the customer's busiest reporting, integration, or transaction periods.

The current 2026 R2 installation page lists Windows Server 2019 or 2022, .NET Framework 4.8, IIS 10, and SQL Server 2022 or 2025 for that Microsoft stack. It requires an Integrated application pool with the Enable 32-bit Applications setting set to False; Classic application-pool mode is unsupported. Read the complete version-specific requirements for the selected database and deployment design. These installation details do not transfer server-management responsibility to SaaS customers. Official installation requirements

Document who controls certificates, DNS, identity, storage, database administration, and backups. Include the service accounts and approved access needed during recovery, without placing credentials in a general project tracker. Confirm that the responsible people can reach the required systems during the actual maintenance window.

If infrastructure also needs an upgrade, rehearse the combined sequence or separate the changes into supported stages. Record the support state at each stage and the point to which recovery will return. An application rollback may not undo a database-platform or operating-system change.

Use measurements that resemble normal work: a large inquiry, a scheduled import, a period report, and concurrent transaction entry. Record volume, filters, timing, and environment conditions. A small development database can help identify code defects, but it provides weak evidence for production processing time. Keep compatibility approval and performance acceptance as distinct items in the readiness record.

Back to TOC

Create a sandbox that is representative and isolated

A useful sandbox reproduces the important characteristics of production while preventing test activity from reaching real customers, employees, or transaction services. Both qualities matter. An isolated but unrealistic environment misses defects; a realistic but connected copy can create unintended business activity.

Use an approved recent copy and document what differs from production. Differences may include data masking, service endpoints, license settings, hardware, user accounts, and scheduled jobs. Explain which tests are affected by each difference so that the team does not overstate the evidence.

Before normal testing starts, inspect outbound email, payment processors, commerce connections, shipping providers, bank files, webhooks, and automated exports. Redirect them to approved test destinations or suspend them as appropriate. Confirm the result with the interface owner. A label saying sandbox is useful for people, but it is not an isolation control.

Keep the environment identifiable in navigation and communications. Give testers a reliable entry point and a clear way to report the environment and build. This prevents a screenshot from an older sandbox being accepted as evidence for the current candidate.

Plan at least one clean rehearsal from the defined starting state after remediation. A development sandbox accumulates exploratory changes, manually corrected records, and partially applied fixes. Those changes can make the final upgrade appear easier than it really is. A repeatable rehearsal shows whether the documented package set and sequence are sufficient.

Preserve the starting data needed for comparisons. Capture baselines with their timestamps and report parameters before upgrading the copy. Without that reference, the team may be unable to distinguish a release defect from an old data problem that the project only recently exposed.

Back to TOC

How should customizations and ISV products be validated?

Validate customizations against the chosen target and then test the business behavior they implement. Technical compatibility and business correctness answer different questions. A package can compile and publish while still calculating the wrong value or presenting an action to the wrong role.

Acumatica's compatibility guidance recommends importing the required projects into a development instance of the target release and starting publication to run compatibility checks. Investigate failures using the developer release notes and validation guidance. Keep compatibility validation enabled as a control instead of treating its suppression as a completed fix. Customization compatibility validation

Build a register of projects, assemblies, custom screens, workflows, reports, inquiries, import scenarios, and mobile definitions. For each item, capture its purpose, source location, package version, dependencies, owner, and acceptance test. Include changes that were once installed directly or copied between environments; undocumented deployment steps often become recovery problems.

For an independent software vendor, or ISV, request compatibility evidence for the product version you actually use. Ask about required changes, known limitations, configuration migration, and cutover support. Then test the installed combination. Two individually supported extensions may still interact through the same business event or processing flow.

Use the upgrade to review retirement candidates carefully. A customization whose purpose is now covered by standard behavior may be removable, but that decision needs a business comparison and migration plan. Do not remove it solely because it has not generated a recent support ticket.

At the end of validation, keep one approved package set with its deployment order and evidence. The same set should be available for the rehearsal and production. If a package changes, identify the affected tests and repeat them before approval.

Back to TOC

Review mobile definitions and actual device workflows

Mobile acceptance should follow the user's physical task and the resulting ERP record. A successful desktop test does not establish that a mobile form, scanner, attachment, or shared-device workflow is ready for production.

For 2026 R2, the MSDL guidance changes customized mobile mappings toward Modern UI view names and data access class field names. The adaptation tool produces a draft that requires review, and relevant features must be enabled for accurate detection. The documentation also states that projects with unadapted MSDL scripts cannot be published. MSDL adaptation guidance

Inventory the mobile tasks the company actually uses. Depending on the environment, these may include service activity, expenses, receiving, counts, labor reporting, or approvals. Record the device type, role, network conditions, attachment requirements, and downstream transaction that proves completion.

Test a normal task and at least one interruption. For example, start an approved test transaction, interrupt connectivity at a controlled point, and observe how the configured process reports or recovers its state. Do not assume offline support exists for every action. Define the expected behavior from the specific product and workflow documentation.

For shared devices, check the transition between users and the permissions each person receives. Confirm that the transaction identifies the correct employee or operator where that attribution matters. Include a supervisor correction path and a clear procedure for reporting a failed submission.

Finish with the physical output. If the process prints a label, captures a photo, or changes inventory, inspect that output and reconcile it to the ERP record. An attractive screen is a small part of operational readiness.

Back to TOC

Test integrations as complete business exchanges

Integration testing should establish that the source event, ERP record, and downstream result agree. A successful HTTP response is useful technical evidence, but it does not prove that the correct order, amount, quantity, or status reached the intended destination.

For each connection, record the producer, consumer, schedule, authentication method, business identifier, retry policy, and reconciliation owner. Identify dependencies on endpoint definitions, custom fields, exports, webhooks, or client libraries. Include low-frequency exchanges and applications outside the ERP team's direct control.

Design tests for create, change, cancellation, rejection, timeout, and replay where those operations apply. Check whether the consumer can distinguish a repeated message from a new business request. This property is often called idempotency: processing the same intended request again should not create an unintended second business result.

Use identifiers that both teams can follow. An order number, external reference, and processing timestamp usually make investigation more useful than a log line that only says success. Protect sensitive data in logs, but retain enough context to connect the technical event to the affected business document.

Define the restart sequence before the maintenance window. Decide which connections are paused, which upstream systems continue collecting work, and where pending items will wait. Release a controlled sample after the upgrade and reconcile it before opening the full queue.

The interface owner should approve both normal operation and recovery. A connection that works only when every service is available has not been adequately rehearsed. The team needs to recognize incomplete work, avoid unsafe replay, and explain how exceptions reach a person who can resolve them.

Back to TOC

What needs special attention in commerce and payments?

Commerce and payment changes deserve focused review because a small technical mismatch can produce duplicate orders, incorrect refunds, or uncertainty about money already processed. Validate the entire transaction history, including corrections and reversals, rather than only the first successful order.

Acumatica documents removal of obsolete commerce APIs in 2026 R2. This does not remove the underlying commerce functionality, but custom code that references or overrides the retired APIs may require changes. Review affected Amazon, BigCommerce, and Shopify extensions against the documented replacements. Removed commerce APIs

Payment interfaces introduce asynchronous equivalents and migration guidance. Compatibility adapters support incremental migration, but they do not preserve binary compatibility where return types changed; affected assemblies must be rebuilt. Obtain the payment provider's guidance for the installed version and test the resulting package. Payment interface changes

Build a test basket from your real business rules. Include discounts, taxes, split fulfillment, partial cancellations, returns, and refunds where used. Compare the commerce record, ERP document, payment reference, and accounting result. A refund should be traceable to the original transaction and should appear consistently in the systems that own it.

Pay attention to ambiguous outcomes. If a request times out after the receiving service has accepted it, a blind retry may be unsafe. The recovery process should first establish whether the original request succeeded, then choose an approved next action. Write that decision into the operating instructions.

Where your landscape includes these connections, involve the owner of the Shopify integration and the ShipStation integration in the rehearsal. Their purpose in the plan is to represent the actual exchange and its reconciliation, not simply to confirm that the connector can authenticate.

Back to TOC

Define finance acceptance with reproducible comparisons

Finance acceptance should demonstrate that balances, document states, and representative postings remain explainable after the upgrade. A signed checklist is strongest when another reviewer can reproduce its results using the same filters and the same point in time.

Create a comparison pack for the ledgers, branches, companies, currencies, and periods that matter to the organization. Include trial balance, receivables and payables, cash, inventory value, and other relevant subledgers. Capture open and unreleased documents as well as posted balances, because pending work may fail only when somebody later attempts to release it.

Specify the report or inquiry version, parameter values, as-of time, and reviewer. If the pre-upgrade and post-upgrade reports use different filters, an apparent discrepancy may be a comparison error. Conversely, equal grand totals can conceal offsetting differences between branches or accounts. Review at the level where the business needs control.

Select transaction examples that exercise real policy: approval limits, tax handling, currency conversion, credit adjustments, payment application, voids, and period boundaries. These are suggested regression scenarios, not claims of newly introduced 2026 R2 functionality. Inspect the resulting entries and reports instead of stopping when the document is saved.

Treat tolerance as a documented decision. Do not invent a blanket percentage that permits unexplained differences in financial data. Establish which rounding or timing differences can occur, how they will be explained, and who can accept them.

Keep historical defects separate from upgrade defects, but do not use that distinction to dismiss them. If a discovered data problem prevents reconciliation or safe operation, it still needs an owner and a disposition before the production decision.

Back to TOC

Prove inventory and fulfillment through exceptions

Inventory acceptance should show that the business can receive, locate, reserve, move, ship, and return stock with consistent quantities and values. Choose scenarios that expose the rules of the actual warehouse rather than relying on a demonstration with one item and one location.

Include the combinations that change behavior: multiple warehouses, alternate units, lot or serial tracking, partial receipts, backorders, kits, transfers, and returns. Follow each scenario through the operational document, inventory balance, and financial result where relevant. Record the expected result before running the test so that an unexpected outcome is not casually reclassified as acceptable.

Test the handoff between office staff and the warehouse. Can customer service identify a partial shipment? Does the picking team receive the correct quantity and location? Can a supervisor correct an exception without creating an unexplained adjustment? These questions reveal whether the whole process remains workable.

Include physical equipment and external services. A shipping process may depend on a printer, scale, carrier connection, label format, and local workstation. Rehearse those dependencies using approved test arrangements and avoid creating real shipments unintentionally.

Measure the operating deadline. If the warehouse must complete picking before a fixed collection time, test whether the upgraded flow can handle representative volume within that window. Define the acceptable queue and the person who can escalate a delay.

For cutover, establish a stock checkpoint and document work in progress. Goods may be physically moving while system processing is paused. Decide how receipts, picks, and returns will be recorded during the interruption and entered afterward. Reconciliation should explain those movements, not force the inventory total to match by posting an undocumented adjustment.

Back to TOC

Validate manufacturing and project work at their control points

Manufacturing and project environments need tests that connect operational progress to cost and revenue. The most useful scenarios cross several steps, because an error may become visible only when work is completed, billed, or reviewed for profitability.

For manufacturing, select representative production orders and follow demand, material allocation, issue, labor, completion, and costing. Include the exceptions used in the plant: scrap, rework, partial completion, alternate resources, subcontract activity, or backflush where configured. Confirm that operators and supervisors can perform the work using their normal roles.

If planning or scheduling changes are included, compare recommendations using the same starting demand, calendars, and capacity assumptions. Ask the planner to explain important differences. A faster planning run does not by itself prove that the proposed sequence is feasible or aligned with production policy.

For projects, trace budget, commitment, time or expense, change, billing, and reported margin. Include the billing methods and corrections that the company uses. Validate the link between project reports and the financial records, especially where report layouts, calculations, or approval flows were customized.

Test a time boundary. A shift change, period transition, or billing cutoff often exposes assumptions hidden in ordinary daytime processing. Verify which date controls the posting and how authorized users correct a late entry.

These are proposed acceptance areas, not assertions that every process changed in the new release. The reason to include them is the business consequence of an unnoticed difference. The process owner should select the cases that represent the company's operating model and sign the evidence showing that the results remain usable.

Back to TOC

Check reports, permissions, and performance together

A report is ready when it produces the correct result, exposes it to the intended users, and completes in a useful time. These three properties should be tested together because an administrator's fast, unrestricted query can conceal problems experienced by ordinary roles.

Create a small catalog of decision-critical outputs. For each report, dashboard, or Generic Inquiry, record the business question, owner, calculation basis, filters, access rules, and expected refresh behavior. A Generic Inquiry is a configurable Acumatica query used to present selected business data; its definition is part of the application behavior that deserves regression testing.

Test access with representative accounts. Confirm that users see their permitted organizations, branches, or records, and that a restricted user cannot reach data through an alternate report or export. Include a negative test that deliberately attempts an unauthorized action in the sandbox.

For performance, use repeated runs under recorded conditions. Separate the first run from later runs where caching may influence time. Keep data volume, filters, role, and concurrent load comparable. Report a range of observed durations instead of presenting the fastest attempt as typical behavior.

When a result changes, determine whether the cause is calculation, security, filters, timing, or underlying data. This classification helps the right owner investigate and prevents a permission defect from being treated as a training question.

Finally, check scheduled delivery and presentation. A report that displays correctly in the browser may still fail when exported, emailed through an approved test route, or printed. Acceptance should cover the format and destination the business actually consumes, including any process that runs outside office hours.

Back to TOC

Introduce AI capabilities with a separate acceptance decision

Treat AI adoption as a governed business change with a defined purpose, permitted data, accountable owner, and review process. Installing 2026 R2 does not establish that a company's data definitions or user permissions are suitable for every AI use case.

The official AI Assistant FAQ states that the service is generally available for 2026 R1 and later, requires subscription enablement, and consumes AI Units. It describes access through administrator-configured Generic Inquiries and user permissions. The documented Assistant queries those exposed data sources; it does not update records or perform business actions. Keep that scope distinct from other automation products. Acumatica AI Assistant FAQ

Choose a small initial question set grounded in approved data. For example, a manager could investigate overdue items in a governed inquiry. Define what overdue means, which date applies, which records are excluded, and who owns the underlying definition. The answer is only as useful as that business context.

Test questions with known answers and questions whose answers should be withheld or qualified. Include ambiguity, incomplete data, role restrictions, and requests outside the permitted scope. Ask reviewers to verify conclusions against the underlying inquiry, especially before making consequential operational decisions.

Set a usage owner and review consumption alongside usefulness. A high number of interactions is not evidence of better decisions. Track whether the approved use case saves review effort or improves exception handling using a comparable baseline, and label any estimated benefit as an estimate until measured.

For many projects, a sensible sequence is to establish a stable upgraded baseline, then enable the selected AI use case through its own controlled release. If both changes launch together, define how to withdraw the optional capability while keeping core operations available.

Back to TOC

A practical 30-day readiness plan

Use the following 30-day outline as a planning example, not an Acumatica requirement or a promised project duration. It assumes access to a suitable sandbox, available process owners, and a manageable remediation backlog. A complex environment may need a longer schedule while retaining the same decision points.

Days 1–7: establish the starting position

Confirm the release record, responsibilities, business calendar, and dependency inventory. Prepare the isolated sandbox and capture comparison data. Perform the first technical upgrade to discover obstacles, preserving logs and package versions. By the end of this phase, the team should know what must change and which missing answers threaten the schedule.

Days 8–18: fix and test the critical paths

Prioritize the processes whose failure would stop operations or compromise a control. Resolve customization and vendor issues, then run complete business scenarios with representative roles. Keep defects connected to a specific test, build, and business consequence. Review whether late discoveries require more time before expanding testing to lower-risk functions.

Days 19–25: rehearse the production sequence

Rebuild from the agreed starting state where practical and execute the intended deployment sequence. Time each step, run reconciliations, release controlled integration samples, and prove recovery. Have business users complete their tasks without a trainer directing every click. Finalize operating instructions using the configuration that actually passed.

Days 26–30: decide and prepare the handover

Review remaining defects, vendor support, recovery timing, and business approvals. Freeze the approved package set and communicate the outage and restart plan. Authorize production only after the readiness conditions are met. If a critical issue remains, use the final days to prepare the next decision rather than forcing the original date.

Keep phase completion tied to evidence. Seven elapsed days do not make discovery complete, and a scheduled rehearsal does not prove that recovery works. The calendar organizes effort; the acceptance criteria determine whether the project advances.

Back to TOC

Write test cases that can support a go-live decision

A useful test case describes a business outcome clearly enough that a second person can reproduce the result. It should identify the starting state, role, action, expected records, and evidence required for approval.

For example, replace a vague item such as test sales orders with a specific scenario: a permitted user enters an order for a controlled item, changes the quantity, completes a partial shipment, invoices it, and processes an approved return. Define the expected quantity, document status, inventory movement, and accounting result at each relevant step. Use values chosen for the customer's configuration rather than treating the example as a universal script.

Record the environment, build, package set, tester, date, and supporting exports or screenshots. When a test fails, preserve enough detail to reproduce it. A defect description should explain the actual and expected results, business impact, and whether other scenarios might be affected.

Retest the original failure after remediation and run the relevant neighboring cases. A change to a shared field, event, or calculation may affect more than the screen where the defect was first reported. The developer and process owner should agree on that regression scope.

Use evidence categories that resist false precision. Passed, failed, blocked, and not tested communicate more than an overall completion percentage. A project with hundreds of passed minor checks can still be unready because one essential payment or inventory flow is blocked.

Keep accepted exceptions visible. Each exception needs an owner, business impact, approved workaround, expiration condition, and follow-up date. If the workaround cannot handle normal volume or cannot be reconciled, it should not be treated as a safe production alternative.

Back to TOC

Prepare a cutover runbook people can execute

The cutover runbook should let the assigned team execute the approved sequence without reconstructing decisions during an outage. Give every step an owner, prerequisite, expected duration, verification, and response when the result differs from expectation.

For the usual upgrade, Acumatica recommends the common Configuration Wizard procedure, which validates published customization compatibility before updating the instance. The documented website-only and database-only commands do not perform that compatibility validation. A divided upgrade therefore requires deliberate planning and separate controls, rather than being used as an unexplained shortcut. Official upgrade procedure

Build the operational sequence around the chosen deployment method. Include user communication, processing suspension, interface checkpoints, backups, application work, package publication, service checks, reconciliations, controlled restart, and business approval. Coordinate the detailed steps with the responsible provider or administrator.

Record observable completion conditions. Instead of restart integrations, specify the first sample to release, the source and destination records to compare, and the owner who authorizes the backlog. Instead of finance checked, identify the reports and approval that permit normal transaction volume.

Make the runbook accessible during a system outage. The team should be able to reach the instructions, package inventory, contacts, and approved recovery materials without depending on the instance being upgraded. Check this access during rehearsal, including the people covering later shifts.

Use one person to coordinate the sequence and one clear channel for decisions. Several technically correct actions can still produce an unsafe result if teams execute them in the wrong order. Timestamp actual starts, completions, pauses, and approvals so the final record shows what happened rather than only what was planned.

Back to TOC

Calculate the recovery deadline before the window starts

A rollback plan needs a measured recovery duration and a last safe decision time. Waiting until the business reopening deadline to decide whether to restore is too late when restoration and validation themselves require substantial time.

Use this planning calculation: latest rollback decision time equals required service restoration time minus recovery duration minus validation and communication time minus contingency. Use durations from rehearsal and account for the systems that must be reconciled before users return.

For illustration, suppose service must be available at 07:00. A rehearsed restore takes 80 minutes, validation and communications take 25 minutes, and the team reserves 20 minutes of contingency. The rollback decision is due by 04:55: a total recovery allowance of 125 minutes before reopening. These figures are invented planning inputs, not an Acumatica benchmark or a customer result.

Define who can initiate recovery and which conditions trigger it. Examples include a failed essential process, an unexplained financial difference, an unavailable required identity service, or a deployment delay that consumes the recovery allowance. The decision owner needs authority to act when the trigger is met.

Also define the recovery boundary. Restoring an ERP database does not reverse a transaction already accepted by a bank, commerce platform, or carrier. The plan must identify external activity completed since the checkpoint and explain how it will be reconciled against the restored system.

Practice access to backups and configuration as well as database restoration. Missing permissions, unavailable installation media, or an unrecorded connection setting can delay recovery even when the backup is valid. Measure the complete return to usable service, including the business checks that make reopening safe.

Back to TOC

Worked example: a shipment that exists in only one system

Consider a fictional distributor rehearsing its upgrade before a busy shipping day. The ERP upgrade completes, inventory totals match, and users can enter orders. During a controlled shipping test, the carrier sandbox accepts a shipment, but the connector times out before the ERP receives confirmation.

The team now has an ambiguous business state. Creating the shipment again might produce a second label or charge. Marking the ERP shipment complete manually might hide the missing reference needed for tracking and reconciliation. Neither action should be the default response to a timeout.

Establish what happened

The shipping lead and integration owner trace the same test shipment using its ERP number, external reference, and timestamps. They confirm whether the carrier accepted the request, whether a response was recorded, and whether any retry has already occurred. They preserve the evidence before changing the record.

The acceptance rule for this example is one intended shipment, one accepted carrier transaction, and one correctly linked ERP result. A delayed acknowledgement must be recoverable without creating an unintended duplicate. This is an illustrative business control; the exact recovery mechanism depends on the installed connector and provider.

Prove the correction

The developer reproduces the timeout in the sandbox and applies the approved change. The team repeats the original case, a rejected request, and a late response. Shipping verifies the label and tracking information, while finance checks any associated charge evidence available in the test service.

The test record identifies the connector build and configuration used. If another package arrives before production, the team does not automatically transfer the passing result to it. They evaluate the difference and repeat the affected cases.

Make the production decision

If the recovery path remains uncertain, the shipping integration is a blocker unless the business has a proven alternative with adequate capacity and reconciliation. A manual workaround must identify who performs the work, how duplicates are prevented, and how records will later be matched.

The example illustrates why a successful installation is insufficient evidence for reopening all workflows. The decisive test is whether the organization can establish the state of the business event, resolve an interruption, and resume processing without losing traceability.

Back to TOC

Train by role and stabilize through real business cycles

Training should demonstrate that a person can complete the required work in the final configuration. Attendance at a presentation is useful preparation, but independent task completion provides stronger evidence of readiness.

Choose a few representative tasks for each critical role and include a correction or exception. Ask users to explain where they would seek help when a result is unclear. Record navigation problems and update instructions before the production date. Replace outdated screenshots and references to interface options that the final configuration no longer offers.

Arrange support around the business calendar. Warehouse teams may need coverage before a carrier cutoff, finance during payment processing, and production teams at shift changes. State the contact route, severity definitions, decision owner, and update cadence so people do not invent informal workarounds when support is busy.

After go-live, monitor complete cycles rather than declaring success after the first login. Confirm that scheduled integrations, reports, approvals, payments, and operational batches have run when expected. Review queue age and unresolved exceptions, not just error counts. A process that stopped silently may not produce a visible error.

Separate training issues, access problems, configuration defects, code defects, and external-service failures in triage. This helps assign the correct owner and reveals repeated problems. Keep emergency changes documented and retest the affected behavior before treating the incident as resolved.

End intensive support when the agreed stability conditions have been demonstrated. Transfer unresolved lower-risk items with owners and dates, confirm that manual work has been reconciled, and schedule the next important business-cycle review. A quiet first day does not prove that a weekly or month-end process is ready.

Back to TOC

Use an evidence checklist for the final decision

Approve the Acumatica 2026 R2 upgrade when the release record, critical tests, reconciliation, people, and recovery evidence support reopening the business. The following checklist is a decision aid; adapt it to the customer's actual operating and contractual requirements.

1. Release and responsibility: The source, target, path, packages, and provider responsibilities are documented and approved.
2. Environment: The required platform is supported, the test environment is representative, and important differences are understood.
3. Application dependencies: Essential customizations and third-party products have passed the required technical and business checks.
4. User work: Critical roles can perform normal tasks and the selected exception paths in the final interface.
5. Connected systems: Transactions and recovery cases reconcile across the ERP and external systems.
6. Business records: Finance, inventory, and other relevant control comparisons have been reviewed with no unexplained blocking difference.
7. Cutover and recovery: The sequence has been rehearsed, durations measured, and rollback authority and deadline agreed.
8. Operating readiness: Users know the interruption plan, support is available, and post-upgrade monitoring has owners.

For each item, attach evidence and a decision owner. Avoid a sign-off that says only no concerns reported. Silence may mean a team has not completed its checks or does not understand the question.

Document a postponed decision with the same care as approval. State the blocker, required evidence, responsible owner, and next review point. That record turns a delay into a controlled action and makes the revised plan easier to defend.

The next practical step is an inventory and readiness review before committing to a production date. The scope of Biz-Tech Services' Acumatica work provides a starting point for discussing implementation, customization, and integration needs. Bring the dependency register and current release record to that discussion so the plan begins with your environment.

Back to TOC

Frequently asked questions

Is Acumatica 2026 R2 already released?

Yes. Acumatica announced general availability on October 1, 2026. That establishes release availability, not the appropriate build or upgrade date for every customer. Confirm the current package, known issues, supported path, and provider schedule before committing to production. Release announcement

Can we keep using Classic UI after the upgrade?

Plan around Modern UI and review any remaining Classic-only dependency explicitly. The technical guidance describes transitional access in 2026 R2 and removal of Classic-only forms in 2027 R1. Resolve any exceptional legacy configuration with your support provider rather than assuming a universal fallback. Classic UI retirement guidance

Must every customization be rewritten?

No single answer applies to all packages. Determine the work through target-version compatibility validation and functional testing. Some changes may be small; others may involve interface conversion, replacement APIs, or rebuilt assemblies. The business process that depends on the customization must pass even when publication succeeds. Validation procedure

Can a hosted customer skip testing?

The recommended approach is to test business behavior even when a provider performs the platform work. Hosting responsibility does not establish whether the customer's reports, permissions, integrations, or operating procedures produce the intended results. Agree with the provider on the test environment, schedule, and division of responsibility.

Is a 30-day plan enough?

It may be a useful planning outline for a prepared environment, but it is not a reliable duration for every project. Infrastructure changes, customizations, vendor availability, data volume, and business testing determine the schedule. Use the initial sandbox results and timed rehearsal to refine the estimate.

How should we estimate production downtime?

Time the full rehearsal, including backups, deployment, package work, validation, and controlled restart. Include the recovery allowance and decision time. Database size alone cannot establish the window, and the time taken by the installer is only one part of the outage.

Do we have to enable AI Assistant during the upgrade?

Treat AI Assistant as a separate scope and entitlement decision. The FAQ requires subscription enablement and defines its access and consumption model. Confirm those requirements, then choose a governed use case and acceptance process. The core upgrade and optional AI adoption can have separate launch decisions. AI Assistant FAQ

What is the clearest reason to postpone go-live?

An essential process lacks reliable acceptance or recovery evidence. Examples include an unexplained reconciliation difference, a required integration with unsafe replay behavior, or a restore that cannot meet the business window. A high overall test completion rate does not remove that blocker.

Will restoring the database reverse every transaction?

Do not assume so. A connected service may already have accepted an order, shipment, or payment after the backup checkpoint. The recovery plan must identify and reconcile that external activity before normal processing resumes. Test the cross-system recovery procedure as well as the database restore.

What should we prepare for an upgrade assessment?

Bring the current build, deployment model, customization and vendor inventory, integration list, business calendar, essential process list, and available recovery evidence. Identify process owners and known issues. These inputs make the assessment specific enough to produce a useful remediation and testing plan.

Back to TOC

Sources and scope of this guide

The following official sources support the release-specific statements. The project sequence, acceptance criteria, checklist, and fictional shipping example are editorial planning guidance. They should be adapted to the customer's configuration and confirmed against the documentation for the exact production build.

• Acumatica 2026 R2 announcement — general availability and release context.
• Acumatica release overview — areas of product development to evaluate.
• Classic UI retirement documentation — interface transition and Classic-only form boundary.
• Community Classic UI FAQ — product guidance and preparation context.
• Installation requirements — supported platform prerequisites.
• Customization compatibility validation — development validation procedure.
• MSDL adaptation guidance — customized mobile mapping changes and review requirements.
• Obsolete commerce API removal — affected extension code and replacements.
• Asynchronous payment interface guidance — migration, adapters, and rebuild considerations.
• Acumatica AI Assistant FAQ — availability, access, usage, and capability boundaries.
• General upgrade procedure — standard upgrade flow and divided-upgrade limitations.

To turn this guide into a plan for your environment, contact Biz-Tech Services with the release record and dependency inventory. The starting deliverable should be a clear list of required work, responsible owners, acceptance evidence, and the conditions for a production decision.

Back to TOC

---

by Gary

Acumatica Agentic ERP 2026: AI Automation Guide

---

by Gary

Acumatica Construction ERP 2026: Complete Guide to Job Costing, Project Accounting, Change Orders & Retainage

---

by Gary