Inventory Turnover and Days on Hand by Warehouse

The network report says inventory turns 3.9 times a year, and nobody at the regional distribution centres recognises the figure. The national hub shows 109 days on hand because most of what it ships goes to other DCs rather than to customers, so its sales cost looks tiny against a large building of stock. The spoke looks fast. A planner trims safety stock at the hub on that evidence, and the spoke runs short three weeks later.

Turnover by warehouse only helps when every DC is measured on the same numerator, the same averaging method and the same ownership rules, and when the DC figures add back to the company figure that finance publishes. Fix those four choices and the hub and the spoke can be compared honestly, and a change in one DC's days on hand can be traced to a movement in that building rather than to an accounting artefact.

• Definitions covered: cost of goods issued versus sales cost, unit turns versus cost turns, two-point versus thirteen-point averages, and the stock that belongs outside a DC's balance.
• Worked material: a two-DC network in USD ($) and a two-GSTIN network in INR (₹), a SQL query against a movement ledger, an in-transit incident and a reporting checklist.

Why the company turnover figure hides what each DC is doing

A company ratio answers a finance question: how long cash sits in stock before it becomes cost of sales. A DC ratio answers an operations question: how long goods stay in one building before they leave it, whether to a customer or to another site. Those questions need different numerators, and using the company numerator at DC level is what makes feeder sites look idle.

At entity level the inputs come straight from the accounts. Cost of goods sold sits in the income statement, and Ind AS 2 paragraph 36(d) requires the amount of inventories recognised as an expense to be disclosed. Average inventory comes from the balance sheet. Nothing in either standard defines turnover itself; the ratio is a management measure, so the definitions in this guide are policy choices that you should write down and keep stable.

• Hub or national DC: receives from suppliers and ports, ships a large share to other DCs. Judged on sales cost alone, it always looks slow.
• Spoke or regional DC: receives mostly transfers and ships to customers. Its sales cost is close to its total issues, so the two methods agree.
• Flow-through or cross-dock site: holds stock for hours. Turnover becomes a very large number that tells you little; dock-to-stock time is the better measure.
• Forward stocking location: a small site near customers with high service targets. Low days on hand are the design goal, not a sign of good practice elsewhere.

Turnover assumes the balances themselves are right. Our guide to measuring inventory accuracy by location and status covers that earlier question of whether the counted stock matches the record. This article starts once the balance is trusted and asks how quickly it moves through each building, and how to make the per-site numbers reconcile to the published one.

Choosing the numerator: sales COGS, cost of issues or units shipped

Use cost of goods issued for DC turnover: sales cost shipped from the site plus transfers out to other company sites, both at inventory cost. Keep sales-only turnover as a second line for finance, and keep unit turns for single-SKU or single-family analysis only, because units mix cheap and expensive items into one meaningless count.

Cost of goods issued measures what the building actually pushes out the door. A hub that sends half its volume to spokes is doing real work with that stock, and the ratio should show it. Sales-only cost still matters because it is the figure that ties to the income statement, so the report carries both and labels them plainly. Never mix a cost numerator with inventory valued at selling price; retail-value balances inflate the denominator and flatten every ratio.

Per-DC inventory turnover divides cost of goods issued, meaning sales cost plus inter-DC transfers out at cost, by a thirteen-point average of month-end ERP balances; ASC 330-10-30 and Ind AS 2 paragraph 25 set the cost basis, and the DC issues less transfers should reconcile to entity COGS within 0.5%.

Unit turns look attractive because the WMS has units and not costs. They fail as soon as the assortment is mixed. A DC that ships 1,000,000 units of a $2 fastener and 20,000 units of a $300 pump, holding 50,000 fasteners and 8,000 pumps on average, shows 17.6 unit turns. Valued at cost, the same flows give $8.0 million issued against $2.5 million on hand, or 3.2 turns. The pumps hold almost all the money and almost none of the units.

Turns_DC   = COGI_DC / AvgInv_DC
COGI_DC    = SalesCost_DC + TransfersOut_DC          (both at inventory cost, pre write-down)
AvgInv_DC  = SUM(B0 through B12) / 13               (13 month-end balances at cost)
DOH_DC     = 365 / Turns_DC                          (calendar days, trailing 12 months)
DaysContrib_DC = AvgInv_DC / (EntityCOGS / 365)      (additive: sum over DCs = network DOH)

Check: SUM(COGI_DC) - SUM(TransfersOut_DC) = EntityCOGS  within 0.5% of EntityCOGS
Variables: B0 = opening balance of the 12-month window, B12 = closing balance;
transfers are counted once as an issue at the sender and never as an issue at the receiver.

Average inventory that matches the period, not just two snapshots

Average the twelve month-end balances plus the opening balance, giving thirteen points, or use daily balances where the ERP stores them. The textbook average of opening and closing balances only works when stock is flat through the year, and distribution networks with a seasonal build are never flat.

Take the US hub in the worked example later in this guide. Its 1 January balance was $4.2 million and its 31 December balance $4.4 million, so the two-point average is $4.3 million. Through July to October it carried $6.5 to $7.1 million for the peak season, and the thirteen-point average is $5.4 million. Dividing $27.6 million of issues by $4.3 million gives 6.42 turns; dividing by $5.4 million gives 5.11. The shortcut overstates speed by about 26%.

• Trailing twelve months: the default for published figures. It smooths seasonality and matches a 365-day days-on-hand calculation.
• Single-month annualised: monthly issues times twelve over the month's average balance. Useful for spotting change, but label it, because a peak month will look like a crisis.
• Daily average balance: the most accurate denominator where the ERP keeps daily valuation snapshots; it also catches mid-month builds that month-ends miss.
• Calendar versus operating days: use 365 calendar days. A DC closed on Sundays still holds stock on Sundays, and finance's days inventory outstanding uses calendar days.

The query below builds both inputs from a movement ledger instead of from a reporting cube, which lets the analyst prove each figure. It assumes one row per goods movement with a site code, a movement class and an extended cost, plus a month-end valuation table per site. Adjust the movement classes to the codes your ERP uses for sales issues and transfer issues.

-- Trailing 12 months to 2026-10-31, per DC, at inventory cost
WITH issues AS (
  SELECT site_code,
         SUM(CASE WHEN movement_class = 'SALES_ISSUE'    THEN ext_cost ELSE 0 END) AS sales_cost,
         SUM(CASE WHEN movement_class = 'TRANSFER_ISSUE' THEN ext_cost ELSE 0 END) AS transfers_out
  FROM inventory_movements
  WHERE posting_date > DATE '2025-10-31' AND posting_date <= DATE '2026-10-31'
    AND owner_type = 'COMPANY'                -- excludes consignment and client-owned stock
  GROUP BY site_code
), balances AS (
  SELECT site_code, AVG(value_at_cost_pre_reserve) AS avg_inv   -- 13 rows per site
  FROM month_end_valuation
  WHERE period_end BETWEEN DATE '2025-10-31' AND DATE '2026-10-31'
  GROUP BY site_code
)
SELECT i.site_code,
       (i.sales_cost + i.transfers_out) / b.avg_inv          AS turns_issue_basis,
       365 * b.avg_inv / (i.sales_cost + i.transfers_out)    AS days_on_hand,
       i.sales_cost / b.avg_inv                              AS turns_sales_basis
FROM issues i JOIN balances b ON b.site_code = i.site_code;

Inter-DC transfers, GST stock-transfer invoices and double counting

Count a transfer once, as an issue at the sending DC, at the cost that leaves the sender's books. The receiving DC counts it only when it later ships the goods on. Then the sum of all DC issues minus all transfers equals company cost of sales, which is the reconciliation that makes finance trust the per-site numbers.

The additive check also gives a better comparison tool than turns. Days on hand by DC cannot be summed, because each ratio has its own numerator. Divide each DC's average inventory by the company's daily cost of sales instead, and you get the days each building contributes to the network figure. Those contributions add up exactly, so a board pack can show that the hub holds 72 of the network's 93 days and the spoke holds 21.

• Issue reconciliation: add every DC's cost of goods issued, subtract every transfer out, and compare the result with entity cost of sales for the same twelve months. A gap above 0.5% usually means a transfer posted without a site code or a sales issue booked to a central plant.
• Days contributed: divide each DC's thirteen-point balance by entity cost of sales per calendar day. The figures add up to network days on hand, so they can be stacked in one bar and compared month by month.

India adds a tax layer that tempts analysts into the wrong number. Section 25(4) of the CGST Act treats each GST registration of the same company as a distinct person, and paragraph 2 of Schedule I makes a supply between distinct persons in the course of business a supply even without consideration. A transfer from a Maharashtra warehouse to a Tamil Nadu warehouse therefore moves on a tax invoice, while two buildings under one registration move stock without a supply.

Keep three numbers for every inter-state transfer: inventory cost at the sender, taxable value on the transfer invoice, and integrated tax charged. Only the first goes into turnover. The taxable value is a compliance figure; the integrated tax is input tax credit at the receiving registration and never part of inventory cost. In the rupee example below, using a 10% higher invoice value lifts the Bhiwandi hub from 4.80 to 4.94 turns without a single extra case leaving the building.

Inter-state stock transfers between two GST registrations of one company are supplies under CGST Act Section 25(4) and Schedule I paragraph 2, valued under CGST Rule 28; per-DC turnover should still count the transfer at inventory cost; in the worked Bhiwandi case a 10% mark-up overstates hub turns by 3%.

Stock that sits in a DC but should not count against it

Only company-owned stock that the DC can issue belongs in its average balance, with quarantined stock shown on a separate line. Goods owned by suppliers or clients, and goods travelling between sites, distort every ratio when they are left in or dropped out by accident.

• Supplier consignment stock: held in the building but owned by the supplier until consumed or sold. It is not your inventory, so exclude it from the denominator and the numerator alike.
• Client-owned stock at a 3PL site: a 3PL measures turns on its clients' behalf by owner, never across owners. Our article on reconciling a 3PL stock report with the ERP explains how owner and status fields drift apart.
• In transit between DCs: owned by the company, in neither building. Assign it to the receiving DC from the moment of goods issue, or report it as its own line; never let it vanish.
• Quality hold and returns awaiting decision: owned and physically present, but not issuable. Include it, and show turns with and without it so a growing hold area is visible.
• Excess and obsolete stock: include it in the main figure, because it is real money in the building, and publish a second figure without it so planners can see the active-range speed.

The in-transit rule causes the most month-end noise because the ERP usually moves value out of the sender at goods issue and into the receiver at goods receipt. The trace below shows how one late-evening transfer changed three published figures, and how a single assignment rule fixes it without any manual adjustment.

1. 30 Sep, 21:15: the Memphis hub posts goods issue for transfer order TO-88214, 26 pallets valued at $412,000 at cost, bound for the Reno DC. Memphis inventory falls by that amount.
2. 30 Sep, 23:59: the month-end valuation snapshot runs. The truck is near Amarillo; Reno has not received, so the $412,000 sits in the transit account, attached to no DC.
3. 1 Oct, 07:30: the KPI pack shows network days on hand down 5.5 days, because $412,000 divided by $74,795 of daily cost of sales is 5.5. Memphis looks leaner; Reno is unchanged.
4. 3 Oct, 14:10: Reno posts the receipt against TO-88214. The October snapshot shows Reno heavier, and the September figures are now out of line with every other month.
5. Control applied: the valuation job now assigns open transfer orders to the receiving site, so the September snapshot carries the $412,000 at Reno and network days stay level.

A worked twelve-month dataset for two DCs in dollars and rupees

Run the method on a small network before trusting it on twenty sites. The figures below are illustrative: one US company with a hub in Memphis and a spoke in Reno, and one Indian company with a hub in Bhiwandi registered in Maharashtra and a spoke in Hosur registered in Tamil Nadu. All values are trailing twelve months at inventory cost.

The reconciliation holds in both currencies. In the US network, issues of $27.6 million and $9.3 million total $36.9 million; subtracting the $9.6 million transfer leaves $27.3 million, the entity's cost of sales. Daily cost of sales is $74,795, so Memphis contributes 5.40 / 0.0748 = 72.2 days and Reno 20.7 days, which sum to the network's 92.9 days.

The Indian network tells a slightly different story. On sales cost alone Bhiwandi looks almost a third slower than Hosur, but on issues the two buildings move stock at nearly the same speed, 76.0 against 75.5 days. Daily cost of sales is ₹16.27 lakh, so Bhiwandi contributes 76.8 days and Hosur 22.1, totalling 98.9. A planner cutting stock at Bhiwandi on the sales-only view would have been solving the wrong problem.

Valuation rules under ASC 330 and Ind AS 2 that move the ratio

Measure DC turnover on a consistent pre-write-down cost basis, and reconcile LIFO reserves and net realisable value write-downs at entity level. Otherwise an accounting adjustment in one building changes its turnover with no change in physical flow.

US GAAP allows LIFO, and ASC 330-10-35-1C keeps the older lower-of-cost-or-market test for LIFO and retail-method inventory, while ASC 330-10-35-1B, as amended by ASU 2015-11, measures FIFO and average-cost inventory at the lower of cost and net realizable value. LIFO layers are usually kept by pool for the whole entity, not by building, so DC reports normally value stock at FIFO or standard cost and show the LIFO reserve as a reconciling item.

• India cost formulas: Ind AS 2 paragraph 25 permits FIFO or weighted average cost, and specific identification applies only to items that are not ordinarily interchangeable. LIFO is not available, so Indian DC figures and the entity figure share a basis.
• Write-downs to net realisable value: Ind AS 2 paragraph 9 measures inventory at the lower of cost and net realisable value, and paragraph 34 expenses a write-down in the period it occurs. Exclude the write-down from cost of goods issued, because nothing left the building.
• Reserves inside the balance: a $300,000 obsolescence reserve booked against one DC shrinks its denominator and lifts its turns. Use the gross cost balance for operations and the net balance for finance, and label each.
• Standard cost variances: purchase price variances posted to a central account do not belong to any DC. Leave them out of both the numerator and the balance, and state that the figures are at standard.

DC-level turnover in the US should use FIFO or standard cost before the LIFO reserve and before ASC 330-10-35-1B write-downs, while Indian DCs follow Ind AS 2 paragraphs 9 and 25; a write-down equal to 5% of one DC's stock raises that site's turns by roughly 5%.

Which turnover checks the system calculates and which need a planner

Every number in the turnover report should be produced by a fixed, versioned rule, and every explanation of why a number moved should come from a person. Software that drafts commentary can speed up the monthly cycle, but it should never decide which stock to exclude or which transfer to reassign.

The narrative step is where most of the monthly hours go, and it is also where an assistant can mislead. A model that reads the bridge may attribute a drop in days on hand to faster selling when the true cause is a reserve booked on the last day of the month. Keep the assistant's draft attached to the movement-class bridge, so the DC manager can see which line drove the change before signing the commentary.

1. Bridge first: the report splits each DC's change in average balance and issues by movement class before anyone writes a sentence.
2. Draft second: any generated commentary must cite the bridge lines it relies on, by name and amount.
3. Sign-off third: the DC manager approves or rewrites the commentary; the analyst publishes only signed text.

Building a monthly DC turnover report that finance will sign

A DC turnover report earns finance's signature when it reconciles to the ledger every month and when its definitions change only through a dated policy note. Build the reconciliation first and the dashboard second, because the dashboard is easy to rebuild while lost trust in the numbers is not.

Start with three months of history on two or three sites, including one hub. Run the issue-basis and sales-basis figures side by side, prove the additive days-contributed check, and only then add the remaining DCs. The checklist below is the minimum a controller will ask for before co-signing the pack; it pairs naturally with our method for building warehouse cost per order from activities, since both depend on clean site dimensions.

Inventory speed connects to most of the cost and service measures in our logistics and supply chain library, from carrying cost to fill rate. If you are planning a KPI layer that reads directly from movement ledgers across several DCs and registrations, you can outline your sites, ERP and reporting tools through our request for proposal form.