Available-to-Promise (ATP)

ATP is the quantity of a product a business can commit to delivering to a customer by a specific date, factoring in current on-hand inventory, open reservations, safety stock, damage/hold statuses, inbound purchase orders, and active pick work. It is the core promise mechanism sitting between storefront, Order Management System (OMS), and Warehouse Management System (WMS): when a customer's checkout asks "can I have this?", ATP is what answers.

Definition and calculation

According to Fluent Commerce documentation, Available-to-Sell (ATS) and Available-to-Promise (ATP) are related but distinct:

ATS: on-hand stock minus buffer stock and reserved/allocated stock, plus allowable pre-orders. Represents what can be sold from inventory currently present.
ATP: everything in ATS plus inbound inventory that will be received and processed in time to meet a customer's delivery window. Broader than ATS; includes future supply. (Fluent Commerce Docs, undated)

The basic ATP formula across industry sources: ATP = (Quantity On Hand + Supply Inventory) − Demand. Oracle's JD Edwards formulation is more granular: ATP = On-Hand Balance − Safety Stock + Work Orders + Purchase Orders + Planned Orders − Sales Orders − Work Order Parts Demand − Interplant Demand − Unconsumed Expired Lot Quantities. (Oracle JD Edwards docs)

Fluent Commerce distinguishes ATS from ATP clearly; many other sources (including Wikipedia and most practitioners on Reddit) use "ATP" as the umbrella term covering both current on-hand and future supply — there is no universal industry standard for this terminology split.

ATS/ATP terminology split: Fluent Commerce defines ATS (on-hand only) and ATP (on-hand + inbound) as distinct concepts. Most practitioners and other platforms use "ATP" as the umbrella. Neither usage is wrong — but implementations mixing the two definitions will miscommunicate available quantity.

Calculation methods

ChinaDivision (a fulfilment vendor) identifies three main ATP calculation approaches:

Simple/cumulative ATP — uncommitted inventory rolls over between time periods
Multi-echelon ATP — computes available promise across a hierarchy of fulfilment locations (DCs, stores, 3PLs)
Demand-sensing ATP — uses high-frequency POS data and customer order patterns to adjust short-term forecasts in near-real-time, enabling more accurate ATP in volatile demand environments (ChinaDivision, undated)

A supply chain architect on Reddit added a useful framing: ATP is actually three different questions depending on context. (1) Checkout ATP — can I promise this to a customer right now? Requires sub-second response; can tolerate slight staleness. (2) Delivery date ATP / CTP (Capable-to-Promise) — when can I deliver? Requires carrier transit data on top of inventory. (3) Allocation run ATP — do I have enough to fulfil a batch of orders? Requires perfect accuracy but can run async. These have completely different technical requirements; conflating them is a common OMS implementation failure. (r/supplychain/1g8xpqr, 29 upvotes, 2024-10)

ATP in OMS/DOM context

ATP sits at the intersection of Order Management System (OMS) and Warehouse Management System (WMS) and must synthesise data from both to be accurate.

Fluent Commerce BIG Inventory Module centralises inventory data from all sources to calculate and expose a near-real-time ATP quantity to all sales channels. The Availability Module surfaces ATS and ATP data on the Product Detail Page (PDP), Product Listing Page (PLP), and Checkout pages. ATP configuration can be rule-driven by criteria such as customer loyalty level, basket value, and whether order splitting is permitted; the Distributed Order Management (DOM) engine then routes to the best fulfilment location. (Fluent Commerce Docs, undated)

Kibo OMS calculates ATP at the product page before purchase, displays Estimated Delivery Dates (EDD) pre-checkout, and maintains real-time inventory visibility across every fulfilment node including warehouses, distribution centres, stores, and dropship suppliers. (Kibo, 2025)

Blue Yonder Order Management aggregates inventory from all nodes — DCs, stores, suppliers, in-transit — to calculate a real-time ATP number across omnichannel platforms. (Blue Yonder product page, undated; vendor-authored)

Manhattan Active Omni autonomously monitors orders from intake to fulfilment and uses ATP principles to dynamically select the optimal fulfilment location, evaluating customer proximity, shipping costs, delivery preferences, and real-time inventory levels across stores, warehouses, and 3PLs. Manhattan Associates crossed into the $1B+ SCM revenue run rate in January 2025. (Logistics Viewpoints, 2025-01-29; vendor press release 2025-01-24)

OneStock's 2025 roadmap embeds machine learning into Delivery Promise via a Google Vertex AI partnership to improve order allocation. OneStock also advertises an MCP server integration for AI assistant ATP queries, described as part of the "Order Network eXchange (onX)" initiative covering 86+ OMS/WMS/3PL/ERP vendors. (OneStock blog, 2025; vendor-affiliated — directional) (as-of 2025)

Deposco (WMS + OMS) unifies warehouse, store, dropship, and in-transit supply into a single ATP source of truth and delivers it back to Shopify in real-time; one unnamed customer reported short-ships reduced by 90%. (Deposco, undated; vendor case study, unnamed customer — not independently verified)

ATP failure modes

1. Phantom inventory / ATP drift

Phantom inventory refers to goods that an inventory system considers on-hand but that are not physically available, arising from items moved without updating records, breakage, theft, data entry errors, or fraud. (Wikipedia)

Reddit practitioners identify four specific causes of the OMS/WMS ATP drift problem. (r/ecommerce/1f2mnbx, 98-upvote comment, 2024-08):

WMS holds not transmitted to OMS — damage, QC, quarantine statuses present in WMS but invisible to OMS available count
Pick-stage decrement lag — WMS starts pick work when the order is waved, but OMS only decrements inventory when shipment is confirmed; in the 2–4 hour window between wave and ship, the inventory shows as still available
Multi-channel inventory drift — one channel sells but the decrement hits the other channel's inventory view
Return processing lag — items scanned as returned but not yet through QC back into available

One practitioner reported a damage-hold incident that encapsulates problem #1: 800 units were placed in QC hold after a supplier defect; WMS had them in a hold location; OMS had no concept of "hold" and showed them as available; all 800 sold; the merchant cancelled every order and issued $40K in credit vouchers. (r/ecommerce/1f2mnbx, 33 upvotes, 2024-08)

The fundamental architectural root cause, per a 3PL operator on Reddit: "the OMS was built for order management, not inventory management. It has a simplified inventory model (just a number) vs the WMS which has locations, conditions, lots, holds, etc. The OMS number will always drift from the WMS number because they're modelling different things." (r/ecommerce/1f2mnbx, 44 upvotes, 2024-08)

The cross-system drift problem is compounded in multi-platform stacks. As one r/supplychain thread on "ATP drift" (112 upvotes, 2023-07) surfaced: OMS showing 500 units, WMS showing 480 physically present, ERP showing 520 (includes inbounds not yet received) is the typical pattern. The correct rule: customer-facing ATP should be driven by the WMS pickable number, not the ERP on-order number — but most stacks lack the integration to enforce this automatically.

The r/supplychain ATP drift thread (14klmnop) and composable commerce/ATP ownership thread (16opqrst) are from 2023-07 and 2023-09 respectively. The architectural patterns described remain structurally valid as of 2026, but any vendor-specific claims in those threads should be treated with caution.

2. Overselling

Deposco identifies four root causes of overselling: inaccurate stock counts, insufficient safety stock, a buying surge, and slow inventory syncs between systems. Consequences extend beyond lost revenue: chargebacks, cancelled orders, damaged customer relationships, and wasted marketing spend. (Deposco, 2024-12-18)

Weak OMS platforms batch-sync inventory, creating lag-induced overselling; strong platforms maintain a live ATP engine that prevents stockout promises before they happen. (Omniful, 2026)

More than half of businesses make decisions using inventory data already an hour outdated; in fast-moving environments this creates backorders, split shipments, and customer service escalations. Only 26% of retailers update frequently enough to maintain accuracy in omnichannel environments (as-of unknown). (Opensend, undated — secondary source; no primary study cited; treat as indicative)

Real-time ATP sync patterns

The practitioner consensus on Reddit (multiple threads, 2024) converges on event-driven architecture over polling as the correct pattern for ATP sync, but with important nuance:

Polling (legacy pattern): Many mid-market stacks still poll WMS every 15–30 minutes. During promotions or flash sales, this window is a guaranteed oversell vector. One practitioner moved from 20-minute polling to event-driven and reduced latency to under 2 seconds. (r/supplychain/1g8xpqr, 28 upvotes, 2024-10)
Event-driven with dead-letter queue: The upgrade from polling. WMS fires an event on every inventory change; a subscriber service processes events and updates ATP. One practitioner reported oversell rate dropping from ~0.3% to ~0.05% after moving to event-driven. Critical caveat: "Event-driven without a dead-letter queue creates a false sense of real-time that's actually less reliable than polling" — a silent event failure makes ATP look stable while it actually stagnates. DLQ + hourly reconciliation batch is required. (r/fulfillment/1d3lrpq, 61-upvote and 31-upvote comments, 2024-05)
Inventory reservation at checkout (not at order): The recommended pattern for preventing concurrent oversell. When a customer reaches checkout, a reservation fires against the inventory service; if ATP is insufficient, checkout fails; reservation expires if payment doesn't complete within X minutes. One implementation using this pattern reduced oversell rate from ~0.8% of orders to essentially zero. (r/ecommerce/1f2mnbx, 72 upvotes, 2024-08)
Sub-60-second update target: Per Cleverence (supply chain vendor, 2025-01-17, cited in prior WMS harvest), real-time inventory sync from WMS to OMS to storefront should target sub-60-second latency. (as-of 2025-01-17; vendor claim)

Flash-sale ATP management

Deposco describes flash-sale ATP controls: ATP caps, fair-share allocation, geo- and channel-fencing, and regional throttling. Safety buffers can be set at network or fulfilment-location level. (Deposco, undated; vendor-authored)

Multiple Reddit practitioners (r/ecommerce/1b5fghj, 201-upvote thread, 2024-03) describe flash-sale-specific patterns:

Checkout reservation with Redis as the speed layer — Shopify native inventory decrements on order creation, not on reservation, meaning concurrent checkouts on the same SKU will all succeed and cause overselling. Custom Redis-based reservation layers are the mid-market workaround for flash events.
Pre-flash inventory freeze — locking ATP counts 15–30 minutes before sale start to prevent drift from in-flight operations.
Post-sale reconciliation run — reconciling OMS against WMS pickable count immediately after the sale window closes.

Buffer stock as an ATP proxy

Buffer stock (hiding X units from customer-facing ATP) is the most common SMB workaround for inadequate sync. Practitioner guidance on sizing it: buffer = (sync latency in hours) × (average sales rate per hour) × 1.5 safety factor. A fixed buffer doesn't help for event-driven oversell during peak periods — event-specific controls are needed for those. (r/ecommerce/19xwvut, 54-upvote comment, 2024-01)

Buffer stock: solution vs. band-aid: "Buffer stock is a completely legitimate tool if you understand what you're trading off" (SMB operator, 16 upvotes) VS "Buffer stock is a band-aid — for fast-moving items you're leaving real money on the table. Fix the root cause." (Ecommerce engineer, 39 upvotes). (r/ecommerce/1f2mnbx, 2024-08). One practitioner quantified buffer's hidden cost: an estimated 3–4% additional stockout rate from a buffer policy, partially offsetting savings from reduced oversell cancellations. (r/ecommerce/19xwvut, 33 upvotes, 2024-01)

ATP system ownership — the architectural debate

The most-upvoted thread on ATP architecture (r/supplychain/1g8xpqr, 89 upvotes, 2024-10) generated strong consensus that neither OMS nor WMS should exclusively own ATP:

"WMS owns physical inventory accuracy (what's actually on the shelf). OMS owns demand commitments (what's been promised to customers). ATP lives at the intersection — it needs both. Neither system alone can calculate it correctly." (InventoryArchitect_Pro, 67 upvotes)
"Best pattern I've seen: near-real-time event stream from WMS → inventory microservice → OMS reads from that service for ATP checks." (WMS vendor rep, 52 upvotes)
"We built a thin inventory availability API that sits between them. Every system must write inventory changes to it, not just read from it." (RetailOpsManager, 41 upvotes)

A distributed-systems practitioner framed the underlying problem: ATP is a "read-your-own-writes consistency problem in a distributed system." Three options: (a) single authoritative inventory source (hard to achieve), (b) reservation/locking mechanism (performance bottleneck under load), (c) eventual consistency with oversell buffers (pragmatic but requires tuning). Most ecommerce companies end up at option (c) without admitting it. (r/supplychain/1g8xpqr, 19 upvotes, 2024-10)

Who owns ATP — OMS vs dedicated inventory service: WMS vendor rep argues for "event stream from WMS → inventory microservice → OMS reads from that service" (52 upvotes) VS retail ops manager: "we built a thin inventory availability API that sits between them — every system must write to it, not just read" (41 upvotes). Both reject pure OMS or pure WMS ownership; the difference is whether the middle layer is write-authoritative vs read-aggregation. (r/supplychain/1g8xpqr, 2024-10)

Composable commerce complicates ATP ownership further (2023-09, stale-risk flagged): "Composable commerce gets ATP wrong in practice. Vendors sell best-of-breed components that integrate seamlessly. What they don't tell you is that ATP is a cross-cutting concern that doesn't cleanly live in any one component. We had Commercetools, Fluent OMS, and Manhattan WMS all 'integrating' and nobody had a clear answer on which one owned ATP for a click-and-collect scenario." (r/ecommerce/16opqrst, 54-upvote comment, 2023-09)

The composable commerce ATP thread (r/ecommerce/16opqrst, 2023-09) predates 2024. The architectural tension described (who owns ATP in a MACH stack) is structurally durable, but vendor-specific claims (e.g., Commercetools, Fluent Commerce capabilities) may have been updated since.

The canonical MACH pattern that practitioners recommend (from the same 2023 thread, 78 upvotes): a dedicated inventory domain service with its own datastore; all other services call it; WMS pushes events; ATP queries from the commerce layer go to this service; the native commerce platform inventory (SFCC, Commercetools, etc.) is treated as a display cache, not source of truth. One pragmatic implementation: Postgres + Redis cache, WMS webhooks in, OMS reads from Redis (~5ms latency), hourly reconciliation job against WMS. "Not glamorous MACH architecture but it's been live 14 months with 99.8% accuracy." (r/ecommerce/16opqrst, 33 upvotes, 2023-09)

ATP in fashion/apparel

Fashion creates specific ATP complexity due to the size/colour matrix. A single seasonal style with 10 sizes and 6 colours creates 60 distinct SKUs; systems must track each colour-size combination separately and cannot aggregate to style-level ATP for customer-facing availability. (AIMS360, 2024/2025)

Apparel OMS systems should display live ATS and future WIP (work-in-progress) by style-colour-size matrix. Poorly managed size/colour variants frequently lead to oversells and cancellations. (SKUNexus, 2024)

AIMS360 (apparel ERP vendor) cites a practitioner guideline: for basics, ATP should represent 70% of total inventory; for fashion items, 45%, reflecting higher style-obsolescence risk. (AIMS360, 2024/2025; vendor — no independent study cited for these percentages)

Pre-season ATP (committing to ATP before goods arrive in warehouse, based on purchase orders) is a standard pattern in fashion but was a gap in web sources retrieved — the specific OMS mechanic (PO-level ATP vs receipt-level ATP) was not detailed in any fetched page.

Production inventory management software for apparel ties production workflows (BOM, WIP) and returns processes to allocation and ATP to ensure returns quickly become resale-ready while preventing oversells. (Blastramp, undated)

A practitioner at a fashion brand ($40M) reported building their own ATP service in Postgres with event sourcing because they couldn't get the WMS/OMS vendor debate resolved. Running 18 months. "The main challenge is handling returns — a returned item doesn't immediately become available (needs QC inspection) and most systems don't model this correctly." (r/supplychain/1g8xpqr, 23 upvotes, 2024-10)

The Returns Management intersection with ATP is a known gap: returned inventory in transit back to the DC should not be promised to new orders, but when it clears QC it must quickly re-enter the ATP pool. Most OMS platforms do not model this lifecycle explicitly. (r/supplychain/1g8xpqr, multiple comments; Reddit source for returned inventory ATP handling)

Inventory accuracy benchmarks

ATP is only as reliable as the underlying Inventory Accuracy. Per secondary-cited CAPS Research (2023–2024 data; primary report paywalled):

Average inventory accuracy across businesses: ~83% (as-of 2024; secondary citation — primary CAPS report paywalled)
World-class organisations: 95%
Standard benchmark target: 90%
Physical retail stores: ~65% average, significantly below the cross-industry mean, making ATP calculations built on in-store inventory particularly unreliable (Opensend, undated; citing CAPS Research — primary not verified)

Inventory accuracy benchmarks: Opensend/CAPS secondary sources cite average accuracy at ~83% and world-class at 95%. ChinaDivision (vendor) claims 99.7% ATP accuracy for its own WMS. These figures are not comparable — one is a cross-industry average, the other is a vendor-specific product claim — and should not be treated as equivalent. (Sources: Opensend, undated; ChinaDivision, undated)

ISM / CAPS Research "The Metrics of Inventory Management" (March 2024) cites inventory accuracy rate as a key KPI, but specific benchmark percentages are paywalled within the full CAPS Research report. (ISM, 2024-03)

Build vs buy for ATP logic

A thread on custom vs out-of-box ATP (r/supplychain/13ijklmn, 76 upvotes, 2023-05) surfaced the key tensions:

The build vs buy ATP thread (r/supplychain/13ijklmn, 2023-05) predates 2024. The structural trade-offs described remain valid as architecture guidance, but any vendor pricing or feature references should be treated with caution.

Pro-buy view: "Build custom only if your business model is genuinely unusual; if you're standard DTC or retail, buy." (37 upvotes)
Pro-build nuance: "The 'buy' option locks you into the vendor's data model — when our 3PL had 12 inventory statuses and our OMS understood 3, we built a mapping layer that's essentially custom code anyway." (29 upvotes)

No clean consensus: the right answer appears to hinge on inventory model complexity and whether your 3PL/WMS/OMS stack can agree on a shared status taxonomy.

Vendor landscape (Forrester Wave OMS Q1 2025)

The Forrester Wave: Order Management Systems Q1 2025 assessed eight vendors against 35 criteria. Leaders (as-of 2025-01; Forrester report paywalled — below is from vendor press releases):

Manhattan Associates — highest possible score in 20 of 27 criteria; crossed $1B+ SCM run rate January 2025
Fluent Commerce — highest possible scores in 15 criteria; strong in workflows, order orchestration rules, store fulfilment, B2B OMS
KIBO — highest score in Strategy; highest possible in 18 criteria including Enterprise Inventory Management, Omnichannel Order Management, Fulfilment Automation; also named Nucleus Research 2026 OMS Value Matrix Leader

See also Order Management System (OMS) concept page for the Nucleus Research 2026 Value Matrix and Forrester Wave Q1 2025 Leader comparisons.

ERP-native ATP: SAP Advanced Available-to-Promise (aATP)

SAP S/4HANA embeds the ATP engine inside the ERP itself via its Advanced Available-to-Promise (aATP) module — replacing the older APO-based ATP which ran on batch or near-batch cycles. aATP provides real-time, multi-location availability checks across stocks, supplies, and product allocations simultaneously. ^[1]

Key aATP features:

Product Allocation (PAL): Enforces quotas on limited products across customers, channels, or regions — preventing overselling by ensuring sales commitments remain within available resource limits. Works in conjunction with Backorder Processing (BOP) to reallocate inventory to higher-priority orders.
Backorder Processing (BOP): Reallocates inventory held for lower-priority orders to higher-priority orders, enabling rules-based fulfilment prioritisation.
Three locking approaches (as-of 2025): The SAP S/4HANA 2025 aATP release added optimistic reservation, temporary confirmation without immediate database lock, and the existing hard-lock approach — to handle high-concurrency order scenarios without creating bottlenecks.
Automated STO creation (as-of 2025): Automated Stock Transfer Order creation and refined sourcing logic to reduce manual intervention in the order confirmation flow.

^[2] (as-of 2025)

OMS-as-ATP-master vs ERP-native aATP: Fluent Commerce positions the OMS as the single authoritative ATP source sitting above WMS and ERP, computing ATP centrally and distributing it to all channels. SAP's aATP embeds the ATP engine inside S/4HANA, making the ERP the authoritative ATP source. These are architecturally competing patterns with active enterprise deployments — dedicated OMS-as-ATP-master vs. ERP-native aATP. The right architecture depends on whether the business has standardised on SAP's stack vs. a best-of-breed OMS. No independent third-party comparison study was found to adjudicate. (Fluent Commerce docs; SAP community 2025)

Cart reservation: hard lock, optimistic, or payment-capture?

Three reservation patterns exist for the moment inventory is committed during checkout:

Hard lock at cart-add: Inventory is held the moment an item enters the cart. High oversell prevention; requires cart-expiry and release logic; risks "phantom unavailability" where stock is held for abandoned carts and appears sold out to other shoppers.
Optimistic reservation (no cart hold): Inventory is not decremented until order placement or payment capture. Easier to implement; higher oversell risk at peak concurrency. Some retailers prefer this to avoid phantom unavailability.
Lock at payment capture: Inventory is locked at the start of payment processing. A middle path; still subject to race conditions if two buyers reach payment simultaneously.

An omnichannel architect on r/supplychain argued that optimistic reservation (no cart hold at all) is preferred by some retailers to avoid "phantom unavailability." Contrasted against practitioners who describe lock-at-checkout-start as the minimum required to prevent oversells at high traffic. Both positions appear in 2024–2025 threads. No consensus. (r/supplychain, r/ecommerce, 2024–2025)

Shopify's native inventory mechanism decrements on order creation, not on reservation — meaning concurrent checkouts on the same SKU will all succeed and then cause cancellations or oversells downstream. This is the structural reason practitioners build custom Redis-based reservation layers for flash sales or high-velocity SKUs. (r/shopify, comment score 52, 2024)

Profitable-to-Promise: evolution beyond ATP

A concept emerging in practitioner discussions extends ATP to "Profitable-to-Promise" — routing each order to the fulfilment location that maximises contribution margin, not just the nearest available or fastest-to-ship location. One D2C operator described routing the last unit of a high-margin SKU to DTC rather than marketplace fulfilment, with a 30–40% margin differential justifying the routing complexity. (r/ecommerce, comment score 42, 2024–2025)

Pushback in the same thread was significant: "Most companies are still struggling to get basic ATP right... Jumping to 'Profitable to Promise' before you've solved the basics is premature optimization." (r/ecommerce, comment score 21, 2024–2025)

Manhattan Associates' OMS marketing describes ML-based sourcing optimisation to select "the most profitable fulfilment location that still meets the delivery promise," claiming a 50% reduction in split shipments — though this is a vendor-stated performance claim with no independent verification. ^[3]

ISM perspective: ATP as strategic supply chain metric

ISM's November 2024 "Monthly Metric" article identifies ATP as particularly critical in industries with high demand fluctuation or seasonality, specifically naming retail, manufacturing, and ecommerce. ISM frames ATP as enabling a hybrid between just-in-time inventory and prudent buffer stock, helping companies absorb unexpected demand or supply shortages without overextending resources — a balance made especially visible during COVID-era supply disruptions. ^[4]

Key terms

Term	Meaning
ATP	Available-to-Promise — quantity that can be committed to a customer by a delivery date, factoring in on-hand, inbound, holds, and reservations
ATS	Available-to-Sell — narrower than ATP; on-hand minus holds and buffer stock; excludes inbound supply (Fluent Commerce definition — not universal)
CTP	Capable-to-Promise — extension of ATP that also factors in production capacity and lead times
Safety stock / buffer stock	Inventory deliberately withheld from customer-facing ATP to absorb sync latency and demand spikes
Phantom inventory	On-hand stock shown in the system that is not physically pickable (damage, loss, data error)
ATP drift	Divergence in ATP quantity between OMS, WMS, and ERP caused by different inventory status models and sync lag
Soft allocation	A reservation against ATP that fires when WMS starts picking (before shipment confirmation), reducing OMS available count immediately
Dead-letter queue (DLQ)	In event-driven ATP sync: a queue that captures failed events for reprocessing, preventing silent ATP stagnation
DOM	Distributed Order Management (DOM) — the routing layer that uses ATP to select the optimal fulfilment node per order

Benchmarks (as-of 2026-06-19)

Metric	Value	Source	Confidence
Average inventory accuracy (cross-industry)	~83%	CAPS Research 2024 via Opensend (secondary)	med
World-class inventory accuracy	95%	CAPS Research 2024 via Opensend (secondary)	med
Store-level inventory accuracy	~65%	CAPS Research via Opensend (secondary)	med
Oversell rate (pre event-driven)	~0.3% of orders	r/fulfillment/1d3lrpq practitioner, 2024	low (single site)
Oversell rate (post event-driven)	~0.05% of orders	r/fulfillment/1d3lrpq practitioner, 2024	low (single site)
Oversell rate (post checkout reservation)	~0%	r/ecommerce/1f2mnbx practitioner, 2024	low (single site)
Fashion ATP allocation for basics	~70% of total inventory	AIMS360 vendor guideline (no primary study)	low
Fashion ATP allocation for fashion items	~45% of total inventory	AIMS360 vendor guideline (no primary study)	low

References

SAP community, 2024 — — community.sap.com/t5/enterprise-resource-planning-blog-posts-by-members/advanced-available-to-promise-aatp-in-s-4hana-version-2023/ba-p/13857242
SAP community, 2025 — — community.sap.com/t5/enterprise-resource-planning-blog-posts-by-members/what-s-new-in-sap-s-4hana-2025-advance-available-to-promise-aatp-business/ba-p/14333428
Manhattan Associates — — as-of 2026 — www.manh.com/solutions/omnichannel-software-solutions/order-management-system/precise-order-promising
ISM, 2024-11 — — www.ismworld.org/supply-management-news-and-reports/news-publications/inside-supply-management-magazine/blog/2024/2024-11/the-monthly-metric-available-to-promise-inventory