Available to promise (ATP): the formula, a worked example and how capable to promise differs
Available to promise (ATP) is the stock you can still commit to a new order on a given date.

What available to promise means
Wikipedia describes available-to-promise as the business function that answers a customer’s order inquiry from the resources available, with a quantity and a delivery date. ERP vendors define it the same way. Oracle’s JD Edwards documentation calls ATP the uncommitted portion of inventory or planned acquisitions, used to promise customer orders. Microsoft’s Dynamics 365 documentation calls it the quantity you can promise a customer on a specific date.
The key word is uncommitted. Stock on the shelf that an earlier order already claims is not available to promise, even though a stock count shows it. Supply that is scheduled but not yet in, such as a production order or a purchase order, does count, on the date it is due.
ERPs call the whole step order promising. Business Central has an Order Promising Lines page, Dynamics 365 describes order promising through delivery date control, and Oracle sells Global Order Promising. The term means the same thing in supply chain and logistics. For a manufacturer or distributor, ATP is the number behind the promise date on each sales order line and each quote.
The available to promise formula
ATP in the first period = on hand − safety stock + scheduled receipts − committed orders
ATP in each later period = scheduled receipts − committed orders
Cumulative ATP = the running total of the period figures
ATP with look-ahead in a week = the lowest projected balance from that week to the end of the horizon
The first two lines are the formulas in Oracle’s JD Edwards guide, in shorter words. Its receipts are work orders, purchase orders and planned orders. It subtracts sales orders, component demand from work orders, interplant demand and expired lots. It never includes forecast, because ATP counts actual customer orders. Safety stock comes off in the first period, and inventory optimization covers how to set it.
What counts as a receipt is a setting, not a law. SAP defines which stocks, receipts and requirements count in its scope of check. Two plants on the same ERP with different settings can get different answers for the same item.
A later period goes negative when its orders exceed its receipts. JD Edwards then shows zero for that period and lowers cumulative ATP by the shortfall. The look-ahead version also holds back stock from earlier periods to cover the later shortfall. Dynamics 365 calculates ATP this way and calls it cumulative ATP with look-ahead. Its ATP counts issues until cumulative receipts exceed cumulative issues, and it never shows a negative quantity.
How to calculate available to promise: a worked example
A plant keeps a standard steel electrical enclosure in stock. The numbers are made up to show the method. At the start of week 1 it has 45 in stock. Production orders bring 50 in week 3 and 50 in week 6, and customers have orders in every week.
| Week | Scheduled receipts | Committed orders | Projected on hand | ATP with look-ahead |
|---|---|---|---|---|
| Week 1 | 0 | 15 | 30 | 5 |
| Week 2 | 0 | 20 | 10 | 5 |
| Week 3 | 50 | 10 | 50 | 5 |
| Week 4 | 0 | 25 | 25 | 5 |
| Week 5 | 0 | 20 | 5 | 5 |
| Week 6 | 50 | 10 | 45 | 25 |
| Week 7 | 0 | 15 | 30 | 25 |
| Week 8 | 0 | 5 | 25 | 25 |
Read week 3. The projected balance says 50 enclosures will be on the shelf, but only 5 of them are free. Weeks 3 to 5 hold orders for 55, five more than the week 3 production order brings. Five of the 10 units left from the opening stock must be held for those orders.
Worked receipt by receipt, the arithmetic is short. The opening 45 covers the 35 ordered in weeks 1 and 2, leaving 10. The week 3 receipt of 50 falls 5 short of the 55 ordered in weeks 3 to 5, so it borrows 5 of those 10. The week 6 receipt covers the 30 ordered in weeks 6 to 8 and leaves 20. ATP is 5 until week 6, then 5 plus 20, or 25.
Promising a new order
A customer asks for 20 enclosures in week 4. The projected balance for week 4 is 25, so a desk working from that number says yes. The order takes week 5 below zero: the balance drops to −15, and the customer already promised 20 in week 5 is short by 15.
ATP gives a different answer. Only 5 are free in week 4, and ATP first covers 20 in week 6, when it reaches 25. The promise date is week 6. A split works too: 5 in week 4 and 15 in week 6, with the 15 tracked as a backorder until then.
Get every order line into your ERP, dates included
Tell Derik how purchase orders reach your desk, which ERP they go into and how the ship date on each line is set today. He will tell you what a four-week order desk build would cover.
Start a conversationAvailable to promise vs capable to promise
ATP counts only supply that exists or is already scheduled. Capable to promise asks the next question: if the plant made or bought more, when could it ship? Business Central’s order promising treats CTP as a what-if for the quantity that is neither in inventory nor on scheduled orders. In its example, an order for 10 with 6 available sends the other 4 to CTP.
Microsoft’s Dynamics 365 documentation states the difference plainly: ATP looks at material only and assumes unlimited capacity, while CTP checks both material and capacity. Oracle’s Global Order Promising runs its CTP check through several bill of material levels, down to resource and supplier capacities.
| Available to promise (ATP) | Capable to promise (CTP) | |
|---|---|---|
| Question | How many can I promise from stock and scheduled supply, and when? | When could I deliver the rest if I make or buy more? |
| What it reads | On hand, scheduled receipts and committed orders | The same, plus bills of materials, routings, work centre capacity and supplier lead times |
| Capacity | Assumed unlimited | Checked |
| Result | A confirmed quantity and date | A date, plus new planned supply once someone accepts it |
| Fits | Stocked items and distributors | Items made or bought to order |
Back to the example. The customer insists on week 4, so CTP looks for the 15 enclosures that ATP cannot cover. Each one takes 1.5 assembly hours, so 15 need 22.5 hours. Doors, hinges and locks ordered in week 1 arrive in week 3, when the assembly cell has 24 free hours. CTP adds 15 to the week 3 run, and all 20 ship in week 4.
In Business Central, accepting a CTP date creates a planning line and a reservation, so the extra supply is planned and held for that order. ATP in the example then drops to zero until week 6, and the next customer gets a week 6 date.
How ERPs run the ATP check
SAP and Business Central run the check along the same path. It works back from the date the customer wants and looks for enough ATP on that date. If there is none, it proposes the next good date.
SAP’s availability check follows steps 1 to 3 closely. It schedules backward from the requested delivery date to a material availability date, and confirms the item if cumulative ATP covers it on that date. If not, it schedules forward from the next date with enough ATP and proposes a delivery date.
| ERP | Where the check runs | How it works |
|---|---|---|
| SAP S/4HANA | Availability check on each sales order item | Cumulative ATP on the material availability date. Advanced ATP (aATP) adds alternative-based confirmation, which can move the item to another plant or storage location. |
| Oracle E-Business Suite | Global Order Promising, called from Order Management | ATP from collected supply and demand, or ATP and CTP from an Advanced Supply Chain Planning plan. It can check availability during configuration in Oracle Configurator. |
| Oracle JD Edwards | Requirements planning | ATP by period and cumulative ATP, from receipts and actual orders, with no forecast. |
| Business Central | Order Promising Lines on a sales order | ATP from unreserved inventory and planned supply, and CTP that creates requisition lines. Only items marked Critical are included. |
| Dynamics 365 Supply Chain Management | Delivery date control on each sales line | Sales lead time, ATP, ATP plus issue margin, or CTP. ATP is cumulative with look-ahead. |
Sources for the table: SAP Learning, Oracle’s Global Order Promising guide and JD Edwards guide, and Microsoft’s pages for Business Central and Dynamics 365.

ATP for configured and engineered products
A plant that builds to order rarely has the finished product on the shelf, so ATP on the end item says little. The date depends on the components and the hours. Oracle’s Global Order Promising lets you mark optional items for an ATP check at any level of an assemble-to-order configuration. Business Central can promise dates for bill-of-material items too.
For an engineer-to-order product, part of the lead time is design. A new size or a special option adds drawing hours before any material is ordered. Those hours compete with other orders for the same engineers. A CTP check that counts only shop hours leaves the drawing office out of the date.
For configured products, the quote is often where the date is first promised. A configurator that knows the bill of materials and routing of each option can run the same check while the quote is built. The guide to product configurator software covers how those rules come out of an Excel builder.
Why quoted lead times drift
A date can be wrong on the day it is promised, or become wrong later. Each cause below has a different fix.
- The date is a fixed number. A quote template that says six weeks ignores stock and load. Dynamics 365 calls this method sales lead time, a default number of days that ignores stock, demand and planned supply.
- The check reads stock, not ATP. In the example, the projected balance showed 25 in week 4 when 5 were free. Promising from it left an existing order 15 short.
- A receipt moves. SAP’s training notes that when receipts move later or shrink, orders already confirmed against them can end up short. A late supplier breaks promises that were right when they were made.
- Capacity is assumed unlimited. ATP alone does not look at hours. Two orders can each find material for week 6 and still need the same cell in the same week.
- The quote holds nothing. Unless the system reserves stock or capacity for a quote, the date can be gone by the time the purchase order arrives.
- Lead times get padded after misses. Planners often lengthen planned lead times when due dates are missed. Research on this lead time syndrome found that the change can lower due date reliability instead of raising it.
Start with the records you have. Pull last quarter’s order lines with both the promised and the shipped date, and sort the late ones by item and by cause.
Where AI does the work
AI fits ATP where a person reads records today and types a date. A named person approves each date before it reaches a customer.
- Reading the order line. A language model reads each emailed purchase order and pulls the item, quantity and requested date, quoting the line it came from.
- Running the check. It looks up ATP in the ERP, through its API or a report, and drafts the date with the receipt that covers it. AI for ERP covers how to read an ERP that has no API.
- Proposing a CTP date. For a short line, it reads open production orders, routings and the load on each work centre. It then proposes the earliest date, with the hours shown. Production scheduling with AI covers that capacity data.
- Watching receipts that move. A supplier’s EDI 855 acknowledgement or email can change a ship date. AI lists the customer orders confirmed against that receipt and drafts a new date for each.
- Drafting the acknowledgement. It drafts the order acknowledgement with the confirmed date on each line, for a person to send.
The approver sees the date, the receipt or hours behind it, and any order it pushes back. Human in the loop covers how to design that review.
How ThriveAI gets each order line into your ERP
ThriveAI’s order desk automation starts with the customer’s purchase order, where the date request begins. Derik sets up one inbox for orders. Each PDF, spreadsheet, scan or email is read into fields, including every line’s requested date. Each line is matched to your items, including the customer’s own part numbers, and checked against that customer’s price. Differences are flagged, and the order is drafted in your ERP’s layout beside the original. A person approves, changes or rejects every draft before anything is entered, so any ATP check in your ERP runs on a line keyed correctly. The first stage runs four weeks on your own workspace. Drafted order acknowledgements can follow in a later stage. The order desk automation offer describes the four weeks.