In short: ASCM, formerly APICS, defines available to promise as the uncommitted portion of inventory and planned production held in the master schedule to support order promising, which makes it a netting calculation rather than an on-hand lookup. When the netted answer is no, the next questions are when supply arrives and how the shortfall gets allocated. Proportional allocation feels fair and is usually the worst commercial outcome on a large shortfall, because every customer ends up short and none satisfied. Supply changes invalidate promises made against the old timeline, so re-promising belongs in the process rather than being handled as an exception.
A customer asks when they can have 4,000 units. Somebody looks at on-hand inventory, sees 6,200, and says next week.
What that answer missed is that 5,800 of those units are already committed to orders that have not shipped yet, and the incoming receipt that was supposed to cover the gap slipped by nine days. The promise was made against a number that describes the warehouse rather than against a number that describes availability.
Available to promise is the calculation that fixes this, and it is one of the few areas in supply planning with a genuinely settled standard answer.
The netting calculation
The definition here is standardised rather than a matter of vendor preference. ASCM, formerly APICS, defines available to promise as the uncommitted portion of inventory and planned production, held in the master schedule to support order promising. The phrase carrying the weight is master schedule, because a master production schedule quantity is one somebody has committed to build, and it behaves very differently from a planned order an MRP run invented overnight.
Available to promise starts from a supply timeline: current on-hand, plus every scheduled receipt by period. Against that sits demand: every committed customer order by period.
The discrete calculation works period by period. In the first period, available to promise equals on-hand plus receipts in that period, minus all committed orders due before the next receipt arrives. In each later period with a receipt, it equals that receipt minus the orders due before the following receipt.
That gives a quantity genuinely uncommitted in each bucket. Then you take a running cumulative total, and the cumulative figure is what you promise against, because a customer asking for delivery in week 6 can be served by anything available in weeks 1 through 6.
Two details separate a correct implementation from a plausible one.
Backward netting. When demand in a period exceeds the available quantity, the shortfall has to be netted against earlier periods rather than left as a negative. A negative available to promise in the middle of a timeline means an earlier commitment was made that cannot be met, and the calculation should propagate that backwards rather than hide it.
Consumption. When you promise against a quantity, that quantity has to be removed so the next enquiry sees the reduced position. Systems that recompute from a static timeline without consuming will happily promise the same units to four customers in one afternoon.
Run all of it on the opening scene and the answer changes.
On hand is 6,200. Scheduled receipts are 4,000 in week 2, 5,000 in week 5 and 4,000 in week 8. Committed orders are 3,000 in week 1, 1,800 in week 2, 1,000 in week 3, 2,400 in week 4, 3,500 in week 6, 1,200 in week 7 and 2,000 in week 9.
Period 1 has no receipt, so it holds 6,200 less the 3,000 due before the week 2 receipt lands. Available to promise 3,200.
Period 2 carries the 4,000 receipt less everything due before week 5, which is 1,800 plus 1,000 plus 2,400, or 5,200. Available to promise minus 1,200.
Period 5 carries 5,000 less the 3,500 and 1,200 due before week 8. Available to promise 300.
Period 8 carries 4,000 less the 2,000 due in week 9. Available to promise 2,000.
Net the minus 1,200 backwards against period 1, which falls from 3,200 to 2,000. Cumulative availability then runs 2,000 through week 4, 2,300 from week 5, and 4,300 from week 8.
The customer wanted 4,000 next week. On-hand said 6,200 and the answer looked like yes. The correct answer is 2,000 next week with the balance in week 8, or the whole 4,000 in week 8, and the difference between saying that on the call and discovering it in week 3 is most of what this calculation is worth.
One more choice has to be made explicitly, and most systems make it silently. Does the calculation net against safety stock, or promise into it? Netting against it reserves the buffer permanently, so it never gets used for the thing it was sized for, which is demand variability rather than commitment. Promising into it leaves the buffer protecting nothing, because every unit will have been sold before the variability turns up.
The workable arrangement excludes safety stock from standard promising and exposes it through an explicit override with an approval attached, so using the buffer becomes a decision somebody made rather than a side effect of the sort order. Whichever way you go, write it down, because a sales team that discovers the answer by experiment will discover it in the direction that suits them.
When there is not enough
Available to promise answers whether you can ship from planned supply. When the answer is no, there are two further questions.
Capable to promise asks whether you could make more. This means querying the production schedule for whether unallocated capacity exists in the required window, and if so, what completion date it implies. The interface is a check against the scheduling engine, and it returns a date and a cost rather than a yes or no. Whether to accept the cost is a commercial decision that should surface to a human on anything material.
Profitable to promise asks who should get the units when supply falls short of the requests. This is where the calculation stops being arithmetic and becomes policy, and the policy needs stating explicitly.
Three allocation policies
Proportional. Everyone gets the same percentage of what they asked for. Feels fair, is easy to explain, and is usually the worst commercial outcome, because it leaves every customer short and none satisfied. When the shortfall is small, this is fine. When it is large, giving everybody eighty percent of a critical component may mean nobody can build anything.
Note the rounding trap: proportional allocation of integer units will not sum to the available total unless you handle remainders deliberately. The largest remainder method gives the leftover units to the customers with the largest fractional part, and it guarantees the parts sum to the whole.
Priority. Rank customers by tier and fill in order until supply runs out. Top customers get everything, the tail gets nothing. Commercially rational and it produces a very difficult conversation with the customers at the bottom, so the ranking has to be defensible and consistently applied.
Margin ranked. Fill in order of contribution, so the scarce units go where they earn most. Maximises short-term profit, ignores relationship value entirely, and will systematically starve strategic accounts that happen to buy lower-margin products.
The allocation question has a literature of its own that planners rarely borrow from. Talluri and van Ryzin's treatment of revenue management, published as a book in 2004, works the same structure: a fixed quantity of a perishable resource, several customer classes worth different amounts, and requests arriving over time so you have to decide whether to accept a low-value request now or hold the unit for a higher-value one later. Their answer is a bid price, a threshold below which you decline. Translated into allocation, that says a scarce component should carry a shadow price and requests should clear against it, rather than being filled in arrival order until the pile runs out.
Most businesses want a blend, typically priority tiers with proportional allocation inside each tier, and contractual commitments honoured ahead of everything. The important thing is that whatever the rule is, it is written down and applied by the system rather than negotiated per shortage by whoever picks up the phone. Inconsistent allocation teaches customers to escalate, and once they learn that, every shortage becomes an escalation.
Re-promising after a supply change
Supply changes. A receipt slips, a batch fails quality, a supplier short-ships. Every promise made against the old timeline is now potentially invalid.
The correct response is to re-promise the entire backlog against the new supply position, in a stable order, and report which orders changed. Two properties matter.
Stability. Orders that can still be met on their original date should keep it. A re-promise that reshuffles everything because the sort was not deterministic will generate a wave of customer notifications for orders that were never actually affected.
Deltas. The output should be old date against new date per order rather than a fresh promise list. The customer service team needs to know exactly which twelve of four hundred orders to call about, and reconstructing that by comparing two lists by hand is how the process falls apart in practice.
The data that has to be right
Available to promise is only as good as its supply timeline, and two things commonly corrupt it.
Optimistic receipt dates. If purchase orders carry the original promised date rather than a realistic expectation, the timeline shows supply arriving on days it will not arrive. Every promise made from it inherits the optimism. Using a supplier's demonstrated reliability rather than their stated date is more honest and less popular.
Planned orders treated as supply. If the receipts feeding the calculation include MRP planned orders rather than only firm scheduled receipts and firmed master schedule quantities, availability evaporates every time MRP runs. The symptom is a promise made on Tuesday that cannot be honoured on Wednesday with nothing having changed in the physical world. Check the order status filter on the supply query. A calculation that includes unfirmed planned orders is forecasting availability, and the customer heard a commitment.
Phantom commitments. Orders that were cancelled but never closed, quotes sitting in the system as if they were orders, and internal reservations nobody remembers making. These consume availability that is actually free, so the calculation refuses business you could have taken. A periodic clean-up of the committed demand file is unglamorous and frees real capacity.
Where it does not apply cleanly
Made-to-order businesses with no finished stock have nothing to net against, and the whole question collapses into capable to promise, which is a scheduling problem rather than an inventory one.
Configured products with deep option trees make the calculation combinatorial, because availability depends on which configuration is chosen and components are shared across configurations. The workable approach checks availability at the constraining component level rather than the finished item level, and it is meaningfully harder than the standard case.
Long-lead project business does not fit either, because the promise is negotiated against a project schedule rather than computed from a supply timeline, and pretending otherwise produces a number nobody uses.
There is also a limit worth being clear about with commercial colleagues. A correct available to promise calculation will refuse business that an optimistic one would have accepted. Some of that refused business would have been delivered late and some would not have been delivered at all, and the second group is the reason to do it. If service levels are already good and the sales team believes the system is too conservative, check the receipt date quality before assuming the calculation is wrong.
Start by counting how many committed orders in your system are older than their due date and still open. That number tells you how much of your availability is being consumed by fiction.