Skip to main content

Available-to-Promise (ATP)

Available-to-Promise (ATP) is the availability check inside an ERP system that answers, in real time, how much of an item can be firmly committed for a given date. It looks past what is physically on the shelf: planned receipts count toward availability, and quantities already promised to other orders count against it. The output is the number a salesperson can state without checking with anyone.

The calculation

Conceptually ATP is a running balance across a time axis. On the plus side sit physical on-hand stock and planned receipts — open purchase orders, production orders, inbound transfers. On the minus side sit commitments: sales orders already confirmed, reservations, allocations. What remains in each time bucket is promisable without breaking an existing commitment.

Two variants exist and behave differently. Discrete ATP evaluates each period separately, so a shortage in week two cannot be covered by surplus in week three. Cumulative ATP carries surplus forward, which produces friendlier dates and is less conservative. Which one your system uses is a configuration decision that quietly determines how often you disappoint customers.

ATP, CTP and the difference that matters

ATP asks whether the goods exist or are already scheduled to exist. Capable-to-Promise (CTP) goes further: if the stock is not there, could we make it, given free capacity and available materials? CTP therefore reaches into capacity planning and is substantially more computation-intensive, which is why it typically lives in APS systems rather than in core order entry.

For a distributor, ATP is usually enough. For a make-to-order manufacturer, ATP alone answers the wrong question — the honest response to "when can I have it" depends on the shop floor, not the warehouse. Companies that promise from ATP while producing to order are the ones whose promised dates and actual ship dates diverge systematically.

Where it sits in the process

The check runs at order entry, which is the point where a promise becomes expensive to break. Done well, it prevents the pattern where sales commits, production discovers the conflict, and someone calls the customer back. Done badly — stale data, optimistic supplier dates, no allocation logic — it produces confident promises that are wrong, which is worse than no promise at all.

Most enterprise and mid-market systems ship rule-based ATP with backorder handling: SAP S/4HANA with advanced ATP, NetSuite, Dynamics 365 Supply Chain Management, and the distribution-focused systems where availability accuracy is the product. Depth varies considerably at the edges — multi-site sourcing, substitution rules, allocation by customer tier — and those edges are where evaluation should focus.

Related topics

Frequently asked questions

Why does ATP promise a date we then miss?

Almost always because the ATP calculation trusts a planned receipt that does not arrive on time. ATP is arithmetic on the data it is given: if purchase orders carry optimistic dates, the promise inherits the optimism. The fix is upstream — supplier date reliability and honest lead times — not a different ATP configuration.

What is the difference between ATP and allocation?

ATP answers whether inventory is free to promise. Allocation decides who gets it when it is not. Allocation rules reserve quantities for a channel, region or customer tier ahead of demand, so a large order cannot consume stock earmarked for key accounts. Most distribution systems support both, and using allocation without understanding its effect on ATP is a classic source of phantom shortages.

Does ATP work across multiple warehouses?

In most mid-market and enterprise systems yes, and the interesting question is what the system does when the stock exists but in the wrong location. Options range from promising against the nearest site to proposing a transfer with its own lead time. Whether the promised date includes that transfer time is worth verifying in a demo, because both behaviors exist and one of them produces angry customers.

Is a real-time ATP check always better?

For order entry with a customer on the phone, yes. For high-volume automated order intake it can be a performance problem, which is why some systems cache availability and refresh on a schedule. The trade-off is a small window in which two orders can be promised the same unit — acceptable at low volume, less so in e-commerce peaks.