Drupal Commerce stock management: what the module does and when teams implement it
Commerce Stock is the contributed Drupal Commerce module for recording stock against product variations, so the store can decide whether an item can be sold at the moment a customer adds it to a cart or checks out. Stock tracking becomes a project when the authoritative count lives somewhere else, such as a warehouse management system or an ERP, when several locations ship from the same catalog, or when the website has already sold items that were not on the shelf. The work is in three areas: configuring stock levels and locations, building the sync that keeps the website's figures current, and deciding what checkout does when stock is low or zero. Before you plan that work, confirm on the module's Drupal.org project page which stock behaviors and integration points the release you intend to run supports, because these details change between releases and should not be assumed from the module name.
Drupal and its contributed modules on Drupal.org are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself, so the module carries no license fee. The cost sits in the people who do the implementation and integration work: mapping where stock is held, building and testing the connector to your ERP or warehouse system, writing error handling and reconciliation reports, and maintaining the sync after launch as the ERP changes. Most of that effort is one-time build. Hosting a test environment with realistic warehouse data, monitoring the sync and handling upgrades of the module and the ERP connector recur. When you request a quote, ask for each integration step, the sync method and frequency, how failed updates are retried and reported, and who owns the connector after handover, so you can compare the scope with your own team's capacity. The Drupal.org licensing page sets out the license terms that apply to these modules.
The decision to implement is usually a question of where stock truth lives and how fast it changes. If a single warehouse counts stock a few times a day and orders are few, a scheduled sync may be enough. If stock moves within minutes across several sites, the design has to close the gap between the last sync and checkout, which is where overselling happens. Decide early whether stock is held when an item enters the cart, when the order is placed, or when payment succeeds, and how returns, backorders and manual adjustments in the ERP are written back to the store. A useful first check is to take a sample of recent orders and compare the stock the website recorded at the time of sale with the warehouse count at the same time. The size of the mismatch tells you whether the project is a configuration task or an integration build.
What Commerce Stock provides and what to confirm on Drupal.org
Commerce Stock is a contributed module, so its feature set is defined by its Drupal.org project page and the release you install, not by Drupal core. The cards below separate the capabilities to confirm on that page from the checks your team should run before relying on them for stock decisions.
Stock tracking per purchasable entity
Commerce Stock is designed to keep stock levels against purchasable entities, which in Drupal Commerce are usually product variations. Confirm on the project page that it tracks stock at the variation level, since SKU-level counts drive every other inventory decision. Then test it with a product that has several variations and a parent product that is not purchasable, so you can see how the module reports quantities for each one.
Stock enforcement at add-to-cart
Confirm whether the module blocks or limits quantities when a shopper adds an item to the cart. Enforcement at this point is the first defense against overselling, but it does not reserve units. Two shoppers can add the last unit at the same moment, so test concurrent carts and decide whether a lower-stock message, a hard block or a cart update is the behavior your business needs.
Stock enforcement at checkout
Checkout is where stock must be checked again, because stock can change between cart and payment. Confirm on the project page whether stock is validated when an order is placed and what happens when validation fails after payment has been authorized. Your test plan should cover a stock change between cart and checkout and a payment step that completes after another order takes the last unit.
Stock service plugins
Stock service plugins determine where availability figures come from. Confirm which plugins ship with the release you plan to use and whether a custom plugin is the documented way to read stock from an ERP or warehouse system. Check the plugin interface in the code before you commit, since the availability call is the point where a remote system's answer must be trusted.
Compatibility with the Drupal 11 baseline
Drupal 11 is the current major version, so confirm that the Commerce Stock release and the Drupal Commerce version you choose both list Drupal 11 support on Drupal.org. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so check whether the module has a stated plan for that release. A module without a Drupal 11 release is a reason to pause the build.
Maintenance and security response
Contributed modules receive fixes from their maintainers, and security issues in contributed projects are handled through the Drupal Security Team process. Check the project page for the release date of the latest stable version, the open issue queue and whether maintainers respond to security reports. Plan a named owner for applying updates, because stock logic that falls behind Drupal core creates overselling risk over time.
Which stock model fits your warehouse setup
This table compares the main stock design choices for a Drupal Commerce store: where stock is authoritative, how locations are modeled, when stock is reserved and how backorders are handled. Read each row against your own warehouse count, ERP and sales channels, then check the operational cost in the right-hand column before you agree a scope.
| Decision | Option | When it fits | Operational cost |
|---|---|---|---|
| Source of truth | Drupal holds stock | One storefront, one warehouse, and no ERP that must own inventory counts | You own stock adjustments, receiving and cycle counts inside Drupal and must reconcile them with finance manually |
| Source of truth | ERP holds stock, Drupal mirrors it | An ERP already controls purchasing, warehouses and accounting | Continuous sync jobs, a defined sync frequency and a plan for what happens when the sync fails or lags |
| Locations | Single location | One stock pool shared by all products and one fulfillment point | Simple to run, but adding a second warehouse later usually means reworking stock records and product data |
| Locations | Per-location stock | Several warehouses, stores or regional stock pools that ship separately | Every product and location pair needs a stock figure, so data volume and sync logic grow with the number of locations |
| Reservation timing | Reserve at add to cart | Limited, high-demand items where shoppers must not lose a unit mid-checkout | Carts that are abandoned hold units until a release rule expires them, which can understate available stock |
| Reservation timing | Reserve at order placement | Most catalogs, where stock should be held only once payment or order intent is confirmed | Short windows of overselling are possible during simultaneous checkouts, so you need a clear rule for failed or late payments |
| Backorders | Allow backorders | Products whose supplier lead time is known and the business accepts delayed shipment | Customer messaging, promised dates and order-level exception handling by support staff |
| Preorders | Accept preorders against future stock | Launches or seasonal lines with a confirmed inbound date from a supplier | Expected-date updates, cancellation and refund workflow if the inbound shipment slips |
How a stock implementation runs from inventory audit to go-live
The sequence moves from understanding where stock lives today to a Drupal Commerce site that only sells what the system of record says is available. Each step produces a written artifact so the client can see what was decided, what was tested and what is being watched in production.
Audit current stock sources and SKU identifiers
The team inventories every place stock is recorded today, such as the ERP, a warehouse management system, spreadsheets or marketplace feeds, and documents which system is the source of truth for each location. The same pass maps how SKUs, variations and warehouse codes are named in each system, because most sync failures start with mismatched identifiers. The output is a stock source inventory and a draft SKU mapping that the client's operations and finance owners sign off on before any design begins. Confirm with your ERP or warehouse vendor which identifiers and update methods their API exposes.
Design the stock model
Using the audit, the team decides how stock is tracked per purchasable entity and per location, how reserved and committed quantities are represented, and which events (order placed, payment failed, order cancelled, return received) change availability. It also records what happens to a shopper's cart when stock drops between add-to-cart and checkout, and who owns backorder and preorder rules. The output is a stock design document covering entities, locations, events, rules and exception handling, reviewed with the client's operations lead.
Configure Commerce Stock and checkout enforcement
The team installs and configures the Commerce Stock module from Drupal.org, sets up stock locations and the initial stock service behavior, and enables checks that stop an order from completing when requested quantities exceed available stock. Configuration is kept in version-controlled code so that it can be reviewed and deployed to staging and production the same way. The step closes when a configuration review confirms that each rule in the design document maps to a setting or a custom service, and any gaps are logged as build tasks.
Build or configure the ERP or warehouse sync
The integration is built against the agreed SKU mapping and event list, covering how stock levels flow from the ERP or warehouse into Drupal, how order events flow back out, how failed messages are retried and how conflicts are resolved when both sides change a quantity. The team defines which direction is authoritative for each field and what happens during an outage of either system. The output is a tested integration with an interface specification, an error handling runbook and a list of data fields that will be checked during reconciliation.
Load opening balances and reconcile
Opening stock quantities are loaded from the source system at a fixed cut-off time, and every SKU and location is compared between Drupal and the ERP or warehouse. Differences are classified as mapping errors, timing differences from in-flight orders or genuine count discrepancies, and each class has a named owner for resolution. The output is a reconciliation report showing matched, unmatched and explained variances, signed off by the client before the sync is allowed to write live quantities.
Test overselling scenarios under concurrent orders
The team runs a planned set of test cases, including two shoppers buying the last unit at the same moment, a payment that fails after stock is reserved, a cancelled order that should release stock, a warehouse update arriving mid-checkout and a sync outage. Concurrent tests are run against a staging environment that matches production's database and cache layers, since locking behavior often differs between environments. The output is a test log recording each scenario, expected result, actual result and the fix or accepted risk for every failure, with the client confirming which residual risks they accept.
Go live with monitoring and a stock runbook
The cutover is scheduled with a rollback plan, and the sync and checkout are switched on in production with the reconciliation repeated shortly after launch. Monitoring is configured for sync failures, stock values that stop changing, negative or out-of-range quantities and checkout errors, with alerts routed to named owners. The step closes when the client has a stock runbook covering routine reconciliation, manual adjustments and escalation, and the first post-launch reconciliation report shows no unexplained variances.
What drives stock project effort and how to keep it down
This table lists the factors that most change the effort of a Drupal Commerce stock project, with a way to reduce each one. Read each row as a question to settle before the build starts, since most of the cost of a stock integration comes from decisions made late. The main takeaway is that clean SKU data and one agreed source of truth reduce effort more than any single module choice.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of warehouses or locations | Each location adds a stock level per SKU, a sync path to test and a fulfillment rule to define. | Confirm the list of locations and which ones sell online before the build. Start with the locations that matter for launch. |
| Quality of SKU and product data | Duplicate, inconsistent or missing SKUs force manual mapping and corrupt stock counts from the first sync. | Agree a clean SKU mapping and a unique identifier for each variation before build. Run a data audit on the ERP and catalog exports. |
| ERP or warehouse API maturity | Limited endpoints, rate limits, batch-only access or unclear error codes add custom work and extra testing. | Request API documentation, sandbox access and sample payloads early. Confirm whether the system supports incremental or delta updates. |
| Sync frequency and conflict rules | Real-time sync, nightly batches and manual adjustments each need different queues, retries and reconciliation logic. | Decide the sync interval per data type and which system wins when counts disagree. Write these rules down and test each conflict case. |
| Variations and bundles | Stock for a bundle depends on component stock, and variations need stock tracked at the right level. | List every bundle and its components in the scope. Decide whether bundles are sold from components or from their own stock record. |
| Returns handling | Restocking, damaged goods and partial returns each change the stock count in a different way. | Define return statuses and which ones add stock back. Agree who signs off on restocking and how returns reach the ERP. |
| Multi-currency or multi-store catalogs | Several stores may share stock but show different prices, currencies or availability rules. | Decide whether stores share one stock pool or hold separate allocations. Keep prices out of the stock sync where possible. |
How stock sync prevents overselling during peak orders
Overselling happens when two or more shoppers are allowed to buy the same last unit, so the stock decision has to be made at the moment of purchase, not only when a product page loads. In Drupal Commerce, a stock check at add-to-cart tells a shopper whether an item is available, but it does not reserve anything. Two carts can pass that check at the same moment, and both can then reach checkout with the same unit. For that reason the availability check must run again at checkout, and the stock service must decrease or reserve quantity in the same step that completes the order. Confirm with the Commerce Stock module documentation exactly where its checks and reservations run, and whether a checkout reservation is created when an order is placed or only when it is completed.
Sync latency is the second source of oversell. If the warehouse or ERP system is the system of record, Drupal holds a copy of the quantity that is only as current as the last import or push. During a sale, orders placed in Drupal can consume units the warehouse has already shipped or allocated elsewhere, and the gap grows with the interval between syncs, the volume of orders and the number of sales channels. Decide which system owns the number, how often deltas are sent, and what happens when a sync fails halfway. Ask your integration partner or internal team to document the expected window for a full sync and a delta sync at your peak order volume, and test it with real order traffic before the peak season.
Reconciliation and audit logs are what let you find and repair the gaps that remain. A scheduled job should compare Drupal's stock levels with the warehouse count, flag differences above a threshold you set, and record each adjustment with its source, timestamp and reason. Audit records of stock movements also support customer service when a cancelled order must be restored and finance when inventory is valued. Confirm with the module and your database setup how transactions and row locks behave under concurrent checkouts, and load test that behavior on the database engine you run, because guarantees depend on the module version, the database and the isolation level in use.
Connecting stock to ERP, warehouse, checkout and reporting
Stock in Drupal Commerce is only as accurate as the systems it touches. The cards below cover the Commerce entities that hold quantities, the order workflow that consumes them, the ERP or warehouse exchange that replenishes them, and the checkout, payment and reporting paths that read them. Decide the system of record for each number before choosing any module or connector.
Product variations as the stock unit
In Drupal Commerce, stock is attached to purchasable product variations, not to the parent product. Each SKU your warehouse counts needs one variation with a stable, unique SKU value that matches the ERP item code. Check how variations are created, whether they are ever deleted or re-keyed, and how a renamed SKU in the ERP maps back to the existing variation so history and stock levels are not split across two records.
Order workflow and stock deduction
Stock should move at a defined point in the order lifecycle, such as when an order is placed, when payment is captured, or when items are fulfilled. Each choice changes how much stock is held during checkout and how cancellations and refunds return it. Document the transition that deducts stock, the one that releases it, and what happens to draft carts that never complete.
ERP or warehouse exchange
Decide whether the ERP or warehouse system pushes stock levels through its API, publishes files on a schedule, or receives order exports from Drupal. Each method has different failure modes: a dropped API call, a half-written file, or a delayed batch can all leave Drupal showing stock that does not exist. Agree on the frequency, the identifiers used on both sides, the handling of partial failures, and who investigates a mismatch.
Payment and shipping dependencies
Payment and shipping modules read order state and may depend on whether items are available. The configuration of gateways and carriers is covered on sibling pages, so this card addresses only the stock interaction: confirm which order states trigger a capture or a shipment, and whether a stock failure after payment authorization can be reversed cleanly. Test those paths together rather than in isolation.
Reporting and reconciliation
Finance, operations and the warehouse usually read different stock figures. Build a reconciliation report that compares Drupal quantities with ERP on-hand counts, lists orders that reserved stock without a shipment, and flags SKUs with negative or unexplained movements. Ask who owns the report, how often it runs, and which discrepancies stop sales for that SKU until resolved.
Audit trail for stock changes
When a customer disputes an order or an auditor asks how a count changed, the answer should come from a log, not from memory. Confirm which stock changes are recorded with a source, timestamp and reason, whether those records are kept in the Drupal database or exported to a central store, and how long they are retained. Plan access to the log so that operations staff can investigate without being able to edit quantities.
Questions buyers ask before hiring help with Drupal Commerce stock
What does help with Drupal Commerce stock cost, and what drives the price?
Cost depends on the written scope, not on a standard package. The main drivers are how many stock sources you have (one warehouse or several), whether an ERP or warehouse system must be integrated, how many SKUs and variations carry stock, and how many checkout and order flows must respect availability. Pre-orders, backorders, bundles and reservations each add design and test work. Most engagements are fixed-scope, so the quote follows from a written scope agreed before work starts. Ask the partner to separate one-time build work (configuration, custom code, integration, testing) from recurring work (monitoring, module updates, support retainers). DeployOpen does not publish a price list.
How long does a Drupal Commerce stock project usually take?
Duration follows the same drivers as cost: the number of stock sources, the depth of the ERP or warehouse integration, and the volume of data to map and clean. A project with one storefront and a manual stock feed is generally shorter than one that reserves stock across several warehouses and syncs every few minutes. Timelines should appear in the written scope with milestones for design, build, integration testing and a controlled launch. Ask for the assumptions behind any date, especially the availability of your ERP team, sandbox access and the accuracy of your product data. No general duration is stated here because it depends on your environment.
What must our team provide before stock work can start?
The partner will need a clear set of inputs before design begins. Expect to provide:
- A SKU master list with product identifiers, variations and units of measure, plus a plan for duplicates and retired products.
- Read and write access to the ERP or warehouse system in a non-production environment, with API documentation and a named technical contact.
- Warehouse rules: stock locations, safety stock, reservation timing, cut-off times, and how returns and damaged goods are recorded.
- Decisions on backorders, pre-orders and what the storefront shows when stock is low.
- Staging hosting in the infrastructure you control, and a test plan owner who can sign off results.
Missing inputs are the most common cause of schedule slips, so ask for this list in the scope document.
Can our in-house team build Drupal Commerce stock management alone?
Often yes, if the team already runs Drupal and has developers familiar with Drupal Commerce entities, order workflows and custom modules. Commerce Stock is a contributed module on Drupal.org, so the platform work is open and documented. The harder parts are usually the ERP integration, concurrency control at checkout and the test effort needed to prove that overselling cannot happen under load. Ask whether your team has done a queued or event-driven integration before and who will own the code after launch. A partner can take the full build, a specific piece such as the integration or the test harness, or a review of an in-house design. Each option should be written into scope with clear responsibilities.
How do you test that Drupal Commerce will not oversell stock?
Overselling is tested as a concurrency problem, not only as a functional one. A typical test plan covers single-customer add-to-cart and checkout, two customers buying the last unit at the same moment, payment failures that release or hold reserved stock, order cancellations and returns, and an ERP sync that arrives late or out of order. Load testing should reproduce peak order rates in a staging environment that matches production as closely as possible. Acceptance criteria should be agreed in advance and recorded, so the team can show what was tested and what remains a known risk. Ask the partner to show the test cases and results, not only a summary.
How is stock kept accurate after the store goes live?
Accuracy after launch depends on monitoring, reconciliation and clear ownership. Set up a scheduled reconciliation between the storefront and the ERP or warehouse system, alert on sync failures and stale data, and log every stock change with its source. Plan for periodic physical counts and a documented process for correcting differences. Operational runbooks should name who responds to an alert and how stock is frozen during a warehouse incident. Module updates and ERP upgrades can change behavior, so include them in a maintenance routine. Ongoing monitoring, updates and support are available as retainers, and their scope should be written separately from the build.
Which Drupal versions and modules should we plan around for stock?
Confirm the Drupal core version first, because contributed modules must support it. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Check the Commerce Stock project page on Drupal.org for its supported core versions, release status and open issues before committing to it. If the store runs on Drupal 7 or an older Commerce release, plan a migration rather than an update, because Drupal 6 and 7 sites are moved into a new site. Ask the partner which module versions it will pin and how it will test them during core upgrades.
What you receive at handover and how stock stays accurate
The handover package for a Drupal Commerce stock integration is the set of records your team needs to run stock accuracy without us: a configuration record of the Commerce Stock settings, stock service and location setup, and the sync design showing which system owns each quantity; mapping tables that tie each product variation SKU to the ERP or warehouse item and location identifier; test evidence from the agreed scenarios, including oversell attempts, partial shipments, returns and failed sync calls; and runbooks for reconciliation failures, such as a count mismatch between the storefront and the warehouse. Access documentation lists which service accounts, API credentials and queue workers exist, where their secrets live in your infrastructure, and who can rotate them. All of it is delivered into your repositories and environments, so no part of the stock flow depends on DeployOpen systems.
Stock accuracy then depends on routine operations. Ask for the sync monitoring design before build starts: which queue or cron job pushes and pulls quantities, what alert fires when a run fails or falls behind, and who receives it. Ask for a reconciliation report that compares storefront availability against the warehouse count on a schedule you set. Drupal updates also affect stock logic, so agree a routine that follows the core release schedule (bugfix releases on the first Wednesday of each month, security releases on the third Wednesday) and a test pass on the checkout and stock paths before each update reaches production. Confirm the Commerce and Commerce Stock module versions you are running against their release notes before each upgrade.
Ongoing support is available as a retainer, covering update routines, sync monitoring review, reconciliation follow-up and changes to mappings when the ERP or warehouse changes its item model. Before you sign, ask for the retainer scope in writing, including response expectations and who handles security advisories for contributed modules. Your own team will still need named owners for stock data, for the sync service and for the on-call response, because a retainer supports those owners rather than replacing them.
How DeployOpen scopes and delivers Drupal Commerce stock work
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Drupal Commerce stock and inventory, we start from a written scope covering stock locations, sync rules and oversell controls, then build and hand over the system in your environment.
How we scope
- Map stock locations, SKUs, variations and which sales channels draw from each location.
- Define the ERP or warehouse system of record and the direction, frequency and failure handling of each sync.
- Agree in writing how checkout reserves, releases and decrements stock, and how backorders are handled.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts.
How we build
- Configure Commerce Stock and related contributed modules, reviewing each for maintenance status before adoption.
- Build custom sync code for the agreed ERP or warehouse interfaces, with logging and idempotent retries.
- Test oversell scenarios under concurrent checkout, partial shipments, returns and failed sync jobs.
- Review custom modules against Drupal coding standards so later core and module upgrades stay manageable.
How we hand over
- Deliver a runbook covering stock sync schedules, reconciliation reports and manual correction steps.
- Document the stock model, module versions, configuration exports and credentials handling for your team.
- Run a handover session with administrators and warehouse staff on exceptions and stock discrepancies.
- Provide test evidence showing which oversell and sync failure cases were tested and their results.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after launch.
- Track Drupal core release windows and contributed module updates that touch commerce and stock code.
- Review sync logs and stock discrepancy reports on an agreed cadence to catch drift early.
- Plan Drupal version moves with your team, including checks against the Drupal 12 timeline when relevant.
