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