A sales coordinator at a contract manufacturer pulls up the inventory screen to answer a customer's question about lead time. The system shows 4,200 units of the requested finished good in the dispatch bay. The coordinator commits to shipping 3,000 next week. Two hours later, a different coordinator takes a similar call and sees the same 4,200 number, because nothing has physically moved yet, and commits another 2,500 units. By Friday, the production planner discovers that 5,500 units have been promised against 4,200 units of actual stock, with a confirmed production order for 3,000 more units stuck waiting on a chemical input that has not arrived. The customer commitments are real. The math is not.
This is the gap that available-to-promise is supposed to close. Knowing how to calculate ATP correctly is the difference between commitments that hold and commitments that quietly slip into expedites and apologies. The naive answer is on-hand stock minus reservations, which is correct as far as it goes but misses most of what makes a real ATP calculation useful. A defensible available to promise calculation has to handle in-flight reservations across multiple users, multi-level bills of materials that constrain finished good availability through their components, and network-wide visibility that prevents over-commitment when stock at one site is being counted against demand at another.
Why Naive ATP Fails on the First Order
The simplest ATP formula is on-hand stock minus reserved quantities. This works in a single-product, single-location, single-user environment where reservations are durable and stock movements are atomic with the orders that drive them. The conditions are rare. Most operations have multiple users querying the same stock simultaneously, multi-step processes between commitment and dispatch, and stock positions that change continuously as production and shipping happen in parallel.
The first failure mode is the race condition that opens the article. Two users see the same stock number, both commit against it, and the system accepts both commitments because the reservations were not applied atomically with the stock query. Naive ATP does not address this because the reservation step is conceptually separate from the availability check. The fix is to make availability a function that includes pending and confirmed commitments at the moment of query, not a snapshot that gets stale between query and commit.
The second failure mode is more subtle. Even with atomic reservations, a finished good ATP that only considers finished good stock misses the production capacity that depends on raw material availability. A customer who needs 8,000 units might be satisfied by 4,000 from stock plus 4,000 from a production run that the operation can complete this week, provided all the materials are available. The naive formula sees only the 4,000 in stock and turns down a viable order, or accepts the order without checking whether the production run can actually happen.
The Reservation Netting Problem
Reservation netting is the discipline of correctly subtracting committed quantities from available stock without double-counting or missing anything. It sounds straightforward and is one of the most common sources of ATP errors. The complexity comes from the variety of ways inventory can be committed: confirmed customer orders, production orders that will consume the stock as a raw material, transfers in flight to other locations, holds for quality investigation, allocations for known recurring demand.
A correct netting calculation enumerates every category of commitment and applies it consistently. On-hand stock minus customer order reservations minus production order material reservations minus outbound transfer reservations minus quality holds equals available stock. Each subtraction has to come from a real, queryable record rather than a manual estimate. Reservations also have to be released correctly when the underlying commitment is cancelled or fulfilled, or available stock will appear lower than reality.
The deterministic netting that holds up in practice treats every reservation as a typed record with a status, quantity, target item, target location, and reference to the source event. The ATP query joins against this table at read time and produces a current number that reflects every commitment in the system. The availability is computed from the data, not stored as a derived field that might be out of date.
Multi-Level BOM Explosion in the ATP Formula
For manufacturers, the most important extension to the basic ATP formula is the explosion through the bill of materials. A finished good's ATP is constrained by both the finished good stock on hand and the production capacity that the available raw materials can support. The right calculation considers both and reports the larger of the two, because the operation can satisfy a commitment from either source.
The component check requires walking the BOM tree. For each component of the finished good, the system computes the available quantity at the relevant location, accounting for any reservations against that component. The available quantity divided by the per-unit requirement from the BOM gives the number of finished good units that this component can support. The same calculation runs for every component. The minimum across all components is the production capacity, because the component with the lowest support is the one that will run out first.
For multi-level BOMs, the calculation recurses. A sub-assembly that itself has a BOM is treated as a finished good with its own ATP, and that ATP becomes an input to the parent calculation. The constraint cascades from the deepest level back up to the top-level finished good. The post on the metric of available to promise on the factory floor goes deeper into how this changes the conversation between sales and production.
Bottleneck Material Identification Changes the Conversation
The most useful output of an ATP calculation is not the availability number itself. It is the identification of the specific material that is constraining production. When the calculation determines that the operation can produce 1,200 units of a finished good before running out of materials, the question that immediately follows is which material limits the run. Without that answer, the production planner has a number but no leverage to change it.
Bottleneck material identification falls out of the ATP calculation naturally if the calculation is structured correctly. The minimum-supporting component across all the BOM lines is, by definition, the bottleneck. The system can report it explicitly along with the current available quantity, the per-unit requirement, and the deficit needed to support a target production quantity. This transforms a vague capacity statement into a specific procurement or transfer signal: 850 kilograms of this raw material would unlock another 5,000 units of finished good capacity.
The procurement implications are significant. A procurement team that knows which materials are constraining production can prioritize expediting and reorder activity against actual production impact rather than against generic stock thresholds. The post on moving from reactive to predictive procurement covers the broader pattern, but ATP-derived bottleneck signals are one of the cleanest inputs to it. Each bottleneck identification carries the production demand it is blocking, which converts directly into a business case for the expedite cost or transfer effort required to clear it.
Network ATP Across Multiple Locations
Operations with multiple locations face an additional complication: stock at one location may or may not be available to support demand at another. The simplest model treats each location independently, with its own ATP calculation. This is correct for material that genuinely cannot move, such as bonded inventory or items with regional regulatory constraints. It is wrong for material that can be transferred, because it understates the network capacity to support a commitment.
A network ATP calculation considers the full inventory across all locations that can serve the demand point, subject to transfer time and cost. For a same-day commitment, only the local location matters. For a commitment that ships in five days and the inter-location transfer takes two, stock at any location reachable within three days is available. The calculation extends the basic ATP formula by adding a time dimension and considering reservations and transfers already in flight.
The network ATP calculation also has to handle the fact that the same physical stock cannot be promised to two different demand points. If stock at Location A is being counted toward a commitment at Location B, it cannot simultaneously be counted toward a different commitment at Location C. The reservation netting has to be network-aware, which means reservations are tracked at the source location even when they support demand at a different destination location. Without this, network ATP overstates availability and produces the same kind of overcommitment that single-location naive ATP produces, but with longer lead time impact when the gap is discovered.
Real-Time Recalculation Is Not Optional
ATP that is calculated once a day and cached is wrong for most of the day. The factory floor moves continuously: production runs complete, raw materials are received, transfers are dispatched, customer orders are confirmed. Each of these events changes the ATP for some set of products. A daily calculation captures none of this until the next batch run, by which point new commitments may have been made against stale data.
The right model recalculates ATP after every relevant event. A material movement that affects raw material stock triggers recalculation for every finished good that uses that raw material. A new customer order reservation triggers recalculation for the affected finished good. A BOM activation triggers recalculation for every finished good using the changed BOM. The recalculation is incremental rather than wholesale, because rebuilding the entire ATP table on every event would not scale, but the relevant subset is updated immediately.
This is also where the ATP system needs to support both pull and push patterns. Pull means a user query gets a current ATP number computed at read time. Push means downstream consumers, such as the sales system or the production planning dashboard, get notified when ATP for a watched product changes significantly. Both patterns have valid use cases. The pull pattern is essential for ad-hoc queries; the push pattern is essential for proactive alerts when an ATP drops below a level that requires action. The 13-alert system in FalOrb fires when ATP for a product reaches zero or falls below a configured warning threshold, with the bottleneck material identified in the alert payload.
What a Defensible ATP Number Actually Means
A correctly calculated available to promise number says: at this moment, considering all current stock, all confirmed commitments, the locked bills of materials for the products in question, the network of locations that can serve demand, and the transfer times between them, this is how many units of this product can be promised against this delivery date with this confidence. The number includes the bottleneck material if production is the binding constraint. It updates whenever any input changes.
This is a meaningfully different number from on-hand stock. It is also a meaningfully different number from a static MRP output, which the post on MRP planning horizons explores in detail. ATP is the real-time, demand-side view of what the operation can commit to. MRP is the planning-side view of what the operation needs to procure to support a future demand pattern. Both are important. They answer different questions, and an operation that runs only one is half-blind.
The plants that take available to promise calculation seriously stop having the conversation that opens this article. The sales team gets a number that holds up. The production planner gets a bottleneck signal that turns into a procurement priority. The customer gets a commitment that ships when promised. None of this requires a sophisticated forecasting model or a large analytics team. It requires the discipline to compute the formula correctly, with reservation netting, multi-level BOM explosion, and network awareness, and to keep the calculation current as the operation moves underneath it. That is most of the work, and it is enough.
FalOrb helps manufacturers calculate real-time ATP with reservation netting, multi-level BOM explosion, network awareness, and bottleneck material identification. Book a 30-minute walkthrough or email us at [email protected] to see how it applies to your operation. More at falorb.com.