THE MECHANISM
A controlled path from inventory signal to recovered value.
Dead Stock sits between your operational data and qualified B2B demand. It reads what your systems already hold, proposes what could be recovered, prepares it to a standard an external buyer can act on, and hands every release decision back to you. It does not replace your ERP or your warehouse system. It adds the recovery layer neither of them was built to provide.
Written for operations, procurement, IT and ERP owners.
A three-layer diagram: the seller's ERP, warehouse system, file export and API feed at the top; the Dead Stock recovery layer with detect, enrich, approve, price, match and fulfil in the middle; qualified B2B demand at the bottom; and a dashed path returning events to the seller's system of record.
FULL LIFECYCLE
Ten steps, and who owns each one.
Each step declares what goes in, what comes out, who decides, and which risk that decision controls. If a step has no owner, it is not a step. It is a hope.
PilotIn development
- 01
Connect
Bring inventory data in from an approved export, a scheduled file drop or an API feed. A one-off controlled sample is a valid starting point.
- 02
Detect
Score records against ageing, movement, safety-stock and demand rules agreed with you, and shortlist recoverable candidates.
- 03
Understand
Complete product identity: manufacturer, identifiers, category and technical attributes, with documents and images where they exist.
- 04
Approve
You confirm the product identity, the releasable quantity, the visibility level and any buyer or channel restriction.
- 05
Price
A pricing policy sets a start price, a floor, a cadence and the conditions under which the price may move.
- 06
Distribute
Make the offer available at the visibility level chosen: private, restricted to approved buyers, or open to verified businesses.
- 07
Match
Compare captured buyer demand with approved offers on normalised identifiers and product attributes, and alert the buyer.
- 08
Confirm demand
The buyer reviews condition, documentation and quantity, and confirms intent. The seller confirms the sale.
- 09
Fulfil
Confirmed demand becomes a warehouse task: reserve, pick, pack, ship, with status visible to both sides.
- 10
Synchronise and measure
Send the resulting stock and sale events back to your system of record, and report the recovery against the agreed baseline.
Ten lifecycle steps from connect to synchronise, each showing its owner, with the steps owned by the seller highlighted and labelled as the seller's decision.
STARTING POINT
You do not need an integration to start.
The first exchange can be a file. Integration is a later optimisation, not an entry requirement, and it is the single most common reason inventory recovery projects never get past the meeting.
Pilot
- CSV export
- XLSX export
- Scheduled SFTP drop
- REST API feed
- ERP extract prepared by your team or your partner
- PDF datasheets
- BOM files
- Product photographs
- Manufacturer documentation
Named ERP vendor connectors are not listed here. A vendor name will appear only when a connector has run end to end in a live deployment and the status has been verified. Until then, the path is the file or the feed.
Six inventory data sources, from CSV export to product photographs, converging into a single panel of normalised inventory records, annotated that no vendor connector is required.
PRODUCT UNDERSTANDING
From a warehouse label to a product a buyer can evaluate.
Enrichment is not description writing. It is identity resolution: establishing what the item actually is, which manufacturer made it, which identifiers it answers to, and which attributes a buyer will filter on. Every field carries a confidence score, and you review before anything is published.
Pilot
What the record holds
- Internal material number
- Abbreviated internal description
- Quantity and storage location
- Last movement date
- No manufacturer, no external identifier
- No attributes, no documents
What enrichment produces
- Manufacturer and manufacturer part number
- EAN or GTIN where one exists
- Legacy and superseded identifiers
- Normalised category and product type
- Technical attributes with units normalised
- Condition, packaging state and quantity available
- Datasheet, certificate and photograph where available
- Per-field confidence score, flagged for seller review
Illustrative data
A comparison of a bearing record before and after enrichment, showing manufacturer, part number, EAN, a superseded legacy identifier, normalised dimensions, condition, documents and a confidence score flagged for review.
APPROVALS
Seven decisions that stay yours.
The approval step exists because the alternative, an automated system publishing your inventory on your behalf, is not something any operations manager should accept.
Pilot
Product identity
Confirm or correct what the system concluded the item is before it can be offered.
Releasable quantity
Release part of the stock and keep the rest. The released quantity is a ceiling, not a target.
Visibility
Private, restricted to approved buyers, or open to verified businesses, decided per item.
Buyer and channel restrictions
Exclude named buyers, buyer types, regions or channels where your commercial agreements require it.
Price floor
The minimum acceptable price. It is enforced by the system, not by a person remembering it.
Withdrawal rule
Define in advance when an item comes back off the market, so nothing lingers by accident.
Manual override
Change any of the above at any moment, including while an offer is live.
An approval panel for a candidate item showing an enrichment confidence score, a seller identity confirmation toggle, a releasable quantity of 40 out of 148, a visibility selector set to verified buyers, an enforced price floor, and a publish state reading awaiting approval.
PRICING POLICY
Prices move on a policy, inside a floor you set.
Ageing stock loses value whether or not anyone adjusts the price. A pricing policy makes that decline deliberate and bounded instead of accidental, and it records every step.
PilotIn development
Pilot
Start price and floor
You set both. The floor is absolute: no automated step and no buyer negotiation crosses it.
Pilot
Cadence
How often the price may move, and by how much. A monthly step of a few percent behaves very differently from a weekly one, and that is your decision to make.
In development
Demand signals
Views, requests and matches inform whether a price should hold or move. A signal proposes; the policy decides.
Pilot
Manual override
Set any price at any time, or freeze an item entirely.
Pilot
Audit log
Every price change records what changed it, when, and against which policy. Finance can reconstruct any price on any date.
Pilot
No uncontrolled discounting
There is no mode in which the system discounts freely to close a sale. The floor is the floor.
A chart showing a price stepping down at a fixed cadence over several months and flattening when it reaches a dashed price floor, which it never crosses. Axes carry no values.
DEMAND ACTIVATION
Demand is captured before it is matched.
A network with supply and no demand is a catalogue nobody visits. Buyer requests are collected from the start, which is why the buyer page exists before a public catalogue does.
PilotIn development
- 01
Buyer submits an identifier
Manufacturer, part number, EAN, an internal legacy identifier, or a whole bill of materials as a file.
- 02
Identifier is normalised
Formatting, separators and known superseded numbers are resolved so that two spellings of the same part meet.
- 03
Supply is checked
Current approved offers and incoming candidate inventory are both examined.
- 04
Buyer is alerted
When a matching approved offer exists, the buyer is notified with condition, documentation and quantity.
- 05
Buyer reviews and decides
Nothing is presented as available before a seller-approved offer exists behind it.
A diagram showing identifier types feeding a normalisation step and a supply check, which branches either to a match that alerts the buyer or to no match today with the request staying active, annotated that nothing is shown as available before a seller-approved offer exists.
WAREHOUSE AND ERP LOOP
A sale ends where operations begin.
The step most surplus projects forget. If a confirmed sale does not become a warehouse task and a stock event, someone reconciles it by hand, and the recovery quietly stops being worth the effort.
In development
- Trigger
Demand confirmed
Buyer and seller confirm quantity, condition and terms.
- Immediate
Stock reserved
The quantity is reserved so it cannot be committed twice.
- Same day
Pick task issued
The warehouse receives a task with location, quantity and packing requirements.
- Per your process
Packed and dispatched
Packing is confirmed and the shipment reference is recorded.
- On dispatch
Event synchronised
The stock movement and the sale are sent back to your system of record.
- Exception path
Mismatch handled
If physical stock does not match the record, the task enters an explicit error state and both sides are notified. Nothing is silently cancelled.
A timeline from confirmed demand through stock reservation, pick task, dispatch and synchronised stock event, with a branch showing that a stock mismatch raises an explicit error state rather than being silently cancelled.
RESPONSIBILITY MODEL
Who does what, written down before the project starts.
Most integration disputes are not technical. They are unstated assumptions about who owns a step.
| Stage | Dead Stock | Seller | Buyer | ERP partner |
|---|---|---|---|---|
| Data import | Receives and normalises | Provides the export or feed | — | Supports mapping |
| Detection | Proposes candidates | Defines and confirms the rules | — | — |
| Enrichment | Suggests product identity | Verifies and corrects | — | Optional support |
| Approval | Routes for decision | Approves or rejects | — | — |
| Pricing | Applies the policy | Sets the floor and can override | — | — |
| Matching | Activates demand | Approves visibility | Submits the request | — |
| Fulfilment | Provides the workflow | Picks, packs and ships | Receives and confirms | — |
| Synchronisation | Emits events | Remains the source of truth | — | Builds or maintains the connector |
Dead Stock never becomes the source of truth for your stock. It reconciles to your system, which is what keeps a failed integration recoverable.
Technical questions we are asked before a pilot.
Do we need an ERP connector to start?
No. A controlled export is enough for a first pilot, and it is what most pilots actually run on. A connector becomes worth building once the workflow has proven itself on your data and you want it to run without anyone exporting anything.
Can we start with a CSV?
Yes. A CSV or XLSX export of one category, with the fields you already have, is a valid starting point. Missing fields are expected and are what the enrichment step is for.
Who approves AI-enriched data?
You do. Enrichment produces a proposal with a confidence score per field. Nothing enters an offer without a named person on your side accepting it. Low-confidence fields are surfaced rather than quietly published.
Can we keep listings private?
Yes. Visibility is set per item: private, restricted to a named group of approved buyers, or open to verified businesses. Private is a valid end state, not a temporary step.
Can we exclude categories, buyers or channels?
Yes, and the exclusions are enforced at publication rather than checked afterwards. Category exclusions, named buyer exclusions and channel exclusions are all supported.
How does pricing avoid mistakes?
Three ways. A floor that the system cannot cross, a cadence that bounds how fast a price may move, and an audit log that records every change with its cause. If a price ever looks wrong, it can be traced rather than argued about.
Does the platform write back to our ERP?
Write-back of sale and stock events is In development. Today the events are available to be consumed, and how they reach your system depends on the path you choose. This is deliberately not described as finished, because it is not.
What happens if physical stock does not match the record?
The fulfilment task enters an explicit error state, both sides are notified, and the offer is suspended. Silent cancellation is the failure mode that destroys buyer trust fastest, so it is not an option in the workflow.
See the workflow against your own data.
An inventory review walks one category of your stock through the first four steps, using a sample you control. It is the fastest way to find out whether the mechanism fits your environment.