Free the working capital sitting in excess stock.
marql finds stock above target cover per SKU and location, prices the excess from your own cost data, and turns it into a plan with an owner, a deadline and a review date.
Found
€2,728
capital at cost price
- ranked in €
- computed from source data
- effect only after measurement
Screens from the Maison Marché demo tenant. The interface is shown in English in every market; the figures in it are generated.
It is selling. The stock is still excessive.
At Maison Marché the mineral water is not dead stock: the last sale was today. But cover reached 110 days against a 7-day target buffer. marql computed the excess against the buffer plus the lead time, priced the capital tied up in it at cost, and put the options on the table.
- 110
- days of cover
- 7
- target buffer
- €2,728
- capital at cost
- 35
- days deviating
From a deviation to a measured effect.
Signal, diagnosis, management action and result assessment are one process — with no gap between the analysis and the thing somebody actually does.
Excess stock is visible before the period closes.
A daily run over SKU × location finds where days of cover exceed the target and ranks the deviations by the capital each excess is holding.
Automatic monitoring · SKU × location
It shows the cause, and the ways to act on it.
marql separates dead stock from a selling SKU with too much cover, reading sell-through, the weather factor and availability in the other locations. Then it offers: pause replenishment, accelerate sell-through with a promotion, transfer between locations, or change the threshold.
7 factors read · arithmetic checked against the data
The recommended quantity comes from an inventory model.
ShelfSense reads stock on hand, average daily usage, lead time and the target buffer. The AI explains the reasoning; the excess quantity and the capital in it are computed deterministically.
On hand 4,625.6 · forecast 39.2 units/day
An effect counts only after the control period.
Once an action is confirmed, marql fixes the baseline period and the measurement window. The Impact Ledger keeps six states apart — «found», «measuring», «proven», «no effect», «inconclusive» and «worse» — and freezes the revenue the effect is measured against at the moment the decision is committed, so the result cannot be inflated afterwards.
Baseline · control where available · change history
110 days can be the correct answer.
The arithmetic above is not in question: 4,076.8 units are above target cover and the capital in them prices at €2,728 from cost. What is in question is whether that is a mistake. In at least five ordinary situations the cover is high on purpose, and an operator who acts on the signal anyway is destroying a decision somebody already made well.
Seasonal build
You buy the season, not the week. Cover measured against a 7-day norm halfway through a build for a peak six weeks out is arithmetically correct and operationally meaningless — the stock is in front of demand, not behind it.
Same SKU, same weeks last year: if the run rate then was several times the current one, the cover is a build. If last year looks like this year, it is not.
Supplier minimum order quantity
When the MOQ is a pallet and the location sells forty units a week, the smallest order the supplier will accept is already eleven weeks of cover. Nothing is wrong with the purchase. The norm was written for SKUs that can be ordered in the quantity you actually need.
MOQ divided by average daily usage. If that alone exceeds the norm, no order the supplier accepts can meet it, and the norm is the thing to change.
A price-locked buy
A confirmed increase, a supplier promotion, or currency exposure can make buying ahead cheaper than buying to cover. The stock is not idle capital; it is a hedge with a known payoff and a date.
Saving per unit against carrying cost per unit over the holding period. And whether the decision is written down anywhere other than the buyer's memory — an unrecorded hedge is indistinguishable from an over-order.
Pre-build for a booked promotion
Cover ahead of a campaign that has a date, a mechanic and a forecast is not excess. It is the campaign. The alert is early, not wrong.
A promotion on the calendar whose forecast consumes the cover, and a named owner for the tail if it does not sell through.
Deliberate cover against supply risk
A single-source SKU, a customs delay, a supplier who has already missed twice — carrying extra weeks is buying availability, and an out-of-stock on a staple usually costs more than holding it.
Whether the lead time in the system is the contracted one or the one actually observed. A norm set against a contract nobody meets will flag prudence as waste every week.
In short
None of these makes the money reappear: the capital is genuinely tied up in all five, and that is worth knowing. What changes is that the answer is «keep it, and here is why» rather than «release it». marql can only recognise the reason where the reason is in the data — a promotion calendar, an order quantity, an observed lead time. Where it is not, the SKU is flagged and the buyer overrides it, and the override is the useful record.
The signal was right. The decision still failed.
Five ways an excess-stock decision goes wrong once the deviation is real, in the order they occur: the cause read wrong, the wrong destination, the wrong price, the wrong fix, and the wrong bookkeeping. These are constructed, not observed — no chain's numbers are behind them.
One action for dead stock and for a fast SKU
Two rows sit next to each other in the same list, both over 100 days of cover. One has not sold a unit in six weeks. The other sold this morning. A markdown clears the first and gives away margin on the second, which would have sold at full price — slower than you wanted, but at full price. Pausing replenishment fixes the second and does nothing for the first, because nothing is on order.
Read the cause before choosing the action. Date of last sale, sell-through across the window, and whether anything is on order: three fields that separate a stopped SKU from an over-covered one, and they point at opposite actions.
A transfer to a location that also cannot sell it
The excess is real and the fix looks obvious — move it to a location that stocks the same SKU. But the receiving location is at 40 days against the same 7-day norm; it is only less visibly wrong. The stock arrives, the alert clears on the sender, and the same capital is frozen one address away with the transfer cost added to it.
A transfer only counts as a fix if the receiving location's own cover stays inside its norm after the stock lands. That is that location's demand, not the network average. If no location clears the test, this is a markdown or a purchasing problem, not a distribution one.
A markdown that costs more than the carrying
A discount deep enough to clear four thousand units in a fortnight gives away more gross margin than the excess was costing to hold. Two different numbers are in play — the capital sitting in the excess, and what it costs per week to keep it sitting there — and the discount has to beat the second, not the first. Held against the capital almost any markdown looks justified. Held against the weekly carrying cost, most deep ones do not.
Compare margin given away against carrying cost over the period you would otherwise hold the stock, plus write-off risk if it expires. On a shelf-stable SKU with no expiry date, doing nothing is often the cheapest available action.
Raising the threshold instead of cancelling the order
The norm is 7 days, cover is 110, and the fastest way to make the alert stop is to decide the norm was wrong. Sometimes it was — that is the previous section. But when the norm was right, moving it converts a purchasing problem into a reporting one: the capital stays exactly where it was, the signal stops arriving, and the next over-order is invisible.
A threshold change is a legitimate outcome only when it is argued from demand, lead time or order quantity, and only when it leaves a record of who changed it, from what, and why. If the norm moves and the open purchase order does not, nothing has been fixed.
Booking the saving before the window closes
The action is taken, cover falls, and the €2,728 is written down as recovered. Then it emerges that the week the stock moved was the week a competitor shut for refurbishment, or that a heatwave sold the water without help. Attributing that to the decision inflates the ledger, and every figure recorded after it inherits the error.
Baseline period and measurement window are fixed when the action is confirmed, never chosen once the result is known. The Impact Ledger has to be allowed to return «no effect» and «not enough data» — a ledger that only ever says «proven» is not measuring anything.
In short
None of the five is a failure of the arithmetic — the signal was right in all of them. Four are a wrong action chosen from a right number, and the fifth is a right action recorded dishonestly. Which is why the sections either side of this one exist: one asks whether the number means what it looks like, the other says who is allowed to act on it.
Start with the one that matters
Which SKUs are tying up working capital without turning fast enough?
Any anomalies in the last 7 days?
1 anomaly detected — no active alerts.
DATA FRESHNESS · POS synced 6 min ago · accounting 4 h ago
- 01Where is the excess stock concentrated — by SKU, category and location?
- 02Is this dead stock, a slow-turning SKU, or a temporary surplus?
- 03Where do we pause replenishment, mark down, promote, or transfer?
- 04Which locations can take the SKU, given their demand and their own stock?
- 05How much working capital can be released without pushing up out-of-stocks?
- 06Draft the plan: action, owner, deadline and review date.
What it takes to price the excess.
Sales by SKU × location
Quantity, revenue, date of the last sale, location and category.
Stock on hand + cost price
Without cost prices the excess quantity can still be counted, but the capital tied up in it cannot be priced — so the money column stays empty rather than estimated.
Lead time + stock on order
Supplier, open purchase orders, distribution centre, shelf life, and which transfers between locations are actually possible.
How this was computed
The scan, the window and the arithmetic.
A SKU-level scan walks the daily per-product rows — sales, cost, stock — and names the exact SKUs behind the money, so each one carries its own contribution rather than a share of a total.
Daily per-SKU rows over a 7–28 day window, the length depending on the check. Trend checks compare two adjacent windows of equal length.
- excess units = stock on hand − average daily usage × (lead time + target buffer)
- capital in the excess = excess units × unit cost
- POS / ERP sync
- product_sales_daily · inventory_daily
- SKU scan
- incident
- inventory_daily
- qty_in_stock, cost_value, category_name
- product_sales_daily
- items_count, cost, category_name
The two equations above reproduce the screens exactly. Days of cover does not follow from them: it is not the stock on hand divided by the forecast printed beside it, because a deviation check and an inventory model read usage over different windows of the same daily rows. That is why this block prints the model rather than a single division — and why the figure it produces is capital priced at cost, not an expense. What holding that capital costs per week is a separate number, and the one a markdown has to beat.
Check it on your own numbers
The two equations above, with the fields exposed. It opens on this playbook's inputs, so the first figure it prints is the one in the hero — change any field and the arithmetic follows.
- Excess units
- 4,076.8
- Capital in the excess
- €2,728
It does not compute days of cover, and it does not compute what holding the stock costs per week. The first needs the usage window this page has not pinned down; the second needs a carrying-cost rate, and inventing one to make a calculator feel complete is the kind of number this playbook exists to refuse.
An action needs a name. The name follows the scope.
The cycle ends on an action with an owner, a deadline and a review date — and the owner is the part this page used to leave blank. Which one it is turns out not to be a question of seniority. What a role may decide is bounded by what that role can see, and marql ships three scopes that see different things: the same morning puts an overstock in one inbox and not in another.
Store manager
Own stores only, and a fraction of the network's open incidents. It is also the one scope that gets cohort percentiles — where each store's margin and average check sit against an anonymous network of comparable stores.
- The ground truth: whether the stock is physically there, sellable, and in the condition the system believes it is.
- Executing a markdown or one leg of a transfer, once the depth and the destination are set.
- Raising a counter-case: the promotion nobody logged, the pallet that could not be split, the delivery that arrived twice.
The transfer, the markdown depth and the threshold. Each needs a figure from outside this scope — most plainly the transfer, whose entire test is what the receiving store's cover looks like afterwards, and that store is not in this inbox.
Whether cover in their own stores returns inside the norm, and whether the counter-case they raised held up.
Region manager
A group of stores, carrying incidents the store scope below it cannot see — including, in the demo tenant, an overstock at a store outside that store manager's own list.
- The transfer, because this is the first scope that can see both ends of one.
- The choice between moving the stock and discounting it — the comparison failure mode 02 turns on.
- Which store's excess is the network's problem and which one is local.
The purchase that created the excess, and the norm itself where it is set centrally. A region can rebalance stock it already holds; it cannot un-order it.
Cover across the group, and how much of the excess moved rather than got discounted.
Owner
The whole network, and no cohort block — at this scope there is nothing left to compare against except itself.
- Pausing replenishment and cancelling what is on order: the only actions that touch the cause rather than the symptom.
- The threshold, and the record of who moved it, from what, and why — failure mode 04 is what happens without that record.
- The ledger's honesty: the decision not to book a saving before the control window closes.
The thing this scope most often reaches for anyway — the judgment about whether a specific pallet in a specific back room is sellable. That is the one fact the smallest scope holds and the largest does not.
Working capital released across the network, and whether the same SKU comes back next quarter.
NETWORK REVENUE · LAST 30 DAYS
354 000 €−1.2%
City Center
54 000 €−0%−2%Westside
39 900 €+2%−0%North Park
39 500 €−16%−17%—In short
These are the three scopes the product ships, not a claim about how a chain ought to be organised. A chain with a buying office has a seat none of the three describes — a category buyer owns the order in a way no store role does — and this playbook is not going to invent that seat. Map your own titles onto the scopes rather than the other way round: the scope is what bounds the decision, and a title that cannot see the receiving store does not own the transfer whatever it is called.
Everything above, on one spreadsheet.
None of this needs marql. The scan, the ranking and the ledger are what the product automates; the method underneath is four decisions and about two dozen fields, and it runs on paper. Take it. If you work it by hand for a quarter and the arithmetic keeps being worth the afternoon it costs, that is the case for automating it — and if it does not, you have spent an afternoon rather than a subscription.
Is it dead, or only over-covered?
Failure mode 01 is one action applied to two different problems. Three fields separate them, and all three are in a sales export.
When did this SKU last sell in this location?
- Not within the lead timeTreat it as dead stock. Replenishment is not the lever — there is nothing left to pause. Go to part 03 and compare a markdown against writing it off.
- Recently, at a steady rateIt is over-covered, not dead. Continue.
Is anything still on order or in transit?
- YesThat is the cause. Cancel or pause it before anything else — every other action treats the symptom, and the next delivery undoes it.
- NoThe excess is already on the shelf. Continue.
Does one of the counter-cases in section 03 apply — a build, an order quantity, a price lock, a booked promotion, supply risk?
- YesRecord which one, who decided it, and when it should be reviewed. Take no action. The record is what stops this arriving as a surprise every week.
- NoContinue.
Is there a location whose own cover stays inside its norm after receiving the excess?
- YesTransfer. Check the receiving location's cover after the move, not the network average — that is failure mode 02.
- NoDistribution will not fix this. Go to part 03.
One of five endings: cancel the order, transfer, mark down, write off, or record a reason and do nothing.
Can the norm be met at all?
Counter-case 02 in worksheet form. One row per SKU class rather than per SKU — the answer is the same for everything you buy by the pallet.
- Average daily usage
- Units per day over a window you trust. Write the window down beside it: the number means nothing without it.
- Lead time
- Observed, not contracted. If the last three deliveries ran late, the observed one is the real one.
- Target buffer
- Days of cover you want on top of the lead time. This plus the lead time is what the excess is measured against.
- Minimum order quantity
- The smallest quantity the supplier will actually accept, in the same units as the usage.
- MOQ ÷ average daily usage
- Days of cover the smallest legal order already creates, before anyone has over-ordered anything.
- Is the norm reachable?
- Compare the line above against lead time plus buffer. If it is larger, no order the supplier accepts can meet the norm — and the norm is what has to change, not the buyer.
Either a norm you can hold somebody to, or a norm you now know is unreachable and should stop raising alerts.
Is discounting cheaper than holding?
Failure mode 03 in worksheet form — the comparison that gets skipped, because held against the capital every discount looks justified.
- Units above the norm
- On hand minus average daily usage times (lead time plus buffer), from part 02.
- Capital in the excess
- Those units at unit cost. This is the number not to compare the discount against.
- Carrying cost per week
- What holding the excess costs weekly — capital, storage, insurance, shrink. With no rate to hand, write down the one you are assuming and label it an assumption.
- Weeks you would otherwise hold it
- At current usage, how long until the excess clears on its own.
- Carrying cost over that horizon
- Weekly cost times the weeks. This is the number a discount has to beat.
- Margin given away
- Discount per unit times the units you expect to move, at the depth you are considering.
- Write-off risk
- Zero on a shelf-stable SKU with no expiry date. On anything perishable, the units likely to expire, at unit cost.
If the margin given away exceeds the carrying cost over the horizon plus the write-off risk, doing nothing is the cheaper action — and worth recording as a decision rather than an omission.
Fix the measurement before you act.
Failure mode 05 in worksheet form, and the only part with a deadline: every field here is filled in before the action, because once the result is known none of them can be chosen honestly. The hints name what marql's own ledger requires, so a spreadsheet run to this standard and a product run to it are answering the same question.
- The action, in one sentence
- What is being done, to which SKU, in which locations.
- Owner
- A name, holding a scope that can actually see what the action needs — section 07.
- Baseline, frozen now
- The figure the effect will be measured against, written down and not recalculated later. marql freezes it at the moment a decision is committed; on a spreadsheet, freezing it means pasting the value rather than leaving a formula that will move.
- Measurement window
- Exact dates after the action, chosen now rather than when the numbers start looking good. Lines in marql's ledger run about four weeks — long enough to contain whole weekly cycles.
- The metric
- Days of cover on this SKU in these locations. One metric — a second one is how a favourable result gets picked after the fact.
- Matched controls
- Comparable locations not receiving the action. marql will not call a line proven on fewer than four matched control stores; with no peers at all it falls back to the unit's own volatility, which is a weaker claim and should be labelled as one.
- The bar that beats noise
- marql's test is a Student-t prediction interval at one-sided α = 0.10 against those controls. On a spreadsheet the honest equivalent is a threshold written down before you look — anything decided afterwards is a preference, not a result.
- What would void the window
- A promotion covering more than half of it, a price change, a supplier change, a stock-out, or a discount spike. Any of these and the honest verdict is inconclusive rather than proven.
- What counts as no effect, and as worse
- Both, written before you know them. A protocol with no way to come back negative is not measuring anything.
A row that can close in any of six directions — found, measuring, proven, no effect, inconclusive, worse. If the last three are unreachable in your version, the first three are not worth having.
In short
That is the whole method. What marql adds is not a better equation: it runs the scan daily across every SKU and location rather than the one somebody noticed, ranks the deviations by the capital in them so the afternoon goes to the largest, and keeps the ledger so a closed row cannot quietly be reopened and improved. The arithmetic above is the same either way.
09 · The line proof stops at
Releasable potential
≠ a proven effect.
€2,728 is the capital sitting in stock above the target level, priced at cost. It is not what holding that stock costs per week, it is not a realised saving, and it is not marql's ROI.
A proven effect is recorded only after the action is executed, the baseline period is set and the control window closes. Where the data is insufficient or an outside factor distorted the result, the Impact Ledger marks the effect unproven.
Where these screens live
The four surfaces this decision passed through
Ready to see
the euros it found?
The walkthrough is built around the tills and accounting you already run. Leave your details and pick a time.