When Stock Becomes an Asset: Assetization Without Losing the Trail
You bought twenty laptops as stock and now four of them are staff equipment. That is not an edit — it is a unit of inventory leaving your stock ledger and reappearing as a tracked asset, in two phases, with an approval in the middle and a cost basis inherited from your weighted average.
A distributor in Industrial Area buys laptops to resell. Twenty arrive, they go into stock at a cost per unit, and everything is orderly. Then the operations manager takes one for the new accounts assistant, the sales lead takes another as a demo unit, and two go out on long-term loan to a key customer. Nobody did anything wrong. But four units have stopped being stock, and if the only thing that happened was somebody adjusting the quantity down, then four laptops have simply evaporated from the records — while continuing, awkwardly, to exist.
This situation is extremely common in Kenya and almost never handled properly, because handling it properly requires two modules to agree about one physical object. There is a dedicated path for it, and it is more careful than most people expect.
What actually has to happen
Converting stock into an asset — assetization, in the system's own vocabulary — is not a status change on a record. It is a stock issue and an asset registration that have to be the same event, or the two ledgers disagree forever. The flow reflects that.
The two phases, and what exists after each
Phase one — the request
You pick a specific stock row: an item, in a warehouse, in a location, with a batch. That row is locked while the request is created, and the available quantity is checked against what you are asking for, so two people cannot assetize the same last unit.
What phase one creates
A pending stock adjustment of the checkout type, with an "Assetization" reason created automatically if it does not exist, a reference beginning ASSETIZE-, a checkout line for the quantity, and a conversion record holding the intended asset's full details as a stored payload. Note what does not exist yet: the asset.
The gap in the middle — approval
The adjustment sits pending and goes through whatever your stock adjustment process is. This is the deliberate part: the asset is not created on request, it is created when the stock actually leaves. Until then you have an intention on record and nothing has moved.
Phase two — finalisation
When the adjustment is processed, the stored payload becomes a real asset — but the quantity used is the approved checkout quantity, not the requested one. Ask for five, have three approved, and you get an asset for three. The record keeps both numbers.
The link that survives
The finished asset holds the source item, and its metadata records the originating stock row, item, warehouse and location, plus the adjustment and checkout it came from and both the requested and approved quantities. Eighteen months later you can still establish exactly which stock this asset used to be.
Reversal
There is no un-assetize. An asset created from stock cannot be converted back into inventory as a single operation — you would retire the asset and receive the stock separately, as two deliberate entries.
The two-phase design is the thing to appreciate here. A single-step conversion would let somebody create an asset out of stock that had not actually been issued, which is precisely how the two ledgers drift apart — and it would put asset creation outside whatever approval your stock adjustments already require. Splitting it means the asset comes into existence at the moment the stock genuinely goes, and inherits your existing controls rather than bypassing them.
The cost basis question, which finance will ask
When the asset is created, its purchase cost is not left blank and is not asked for again. It defaults to the item's weighted average cost, falling back to the buying price if no weighted average exists.
That is the correct default and it is worth understanding why. The unit you took out of stock does not have its own price — it was one of twenty received across possibly several purchases at different landed costs, which is exactly what weighted-average costing exists to resolve. Carrying that figure across means the value leaving inventory and the value arriving in the asset register are the same number, which is what makes the movement reconcilable. Had it inherited the retail price or been left empty, you would have a gap somebody has to explain.
You can override the cost at request time if you have a reason to. Mostly you should not, and if you do, write the reason in the notes — a cost that differs from the weighted average is exactly the sort of thing that looks like an error to whoever finds it later.
One quantity rule that trips people up
An individually tracked asset must resolve to exactly one approved unit. Request three laptops as one individual asset and finalisation refuses it, with a message telling you to use quantity pool tracking for multiple units — which is the right answer, because three laptops are three assets with three serial numbers, not one asset with a quantity of three.
For genuinely interchangeable items — fifty plastic chairs moving from stock to the events store — pool tracking is available on conversion, and the approved quantity becomes the pool quantity with a balance opened at the destination. If you need three individually tracked laptops, that is three conversions. Tedious, and correct: see pooled versus individual tracking for which one you actually want.
What has to cross the boundary
Inventory and assets, at the moment of conversion
What the item was
A quantity in a place, valued at a weighted average, expected to be sold.
- One of N identical units in a stock row
- Held in a warehouse, location and batch
- Valued at weighted average cost
- Counted in stock reports and valuation
- No custodian, no serial, no condition
- Destined for a customer
What the asset is
A specific thing, with somebody responsible for it, expected to be used.
- One record with a code and barcode
- A custodian, a department, a location
- A serial number, a condition, a warranty date
- Out of stock valuation, into the asset register
- A movement history from this point onward
- Destined for retirement, not sale
What genuinely carries across, and what you must add
- Carried automatically: the item link, the name, description and category, the weighted average cost as purchase cost, the source warehouse and location, and an auto-generated barcode if your settings enable it.
- You must supply: the serial number, the custodian, the condition and — if it matters — the warranty expiry. None of these existed on the stock row, because stock does not have them.
The right-hand column of the crossing is the part to plan for. A conversion carries across everything that existed on the inventory side, which is more than people expect — but a serial number is the one field that genuinely cannot be inherited and is the one you will most regret leaving blank, because it is legible on the device now and considerably harder to obtain once the laptop is in a bag in Kisumu.
What AWRA OpsHub does today
- A dedicated conversion from a specific stock row, with that row locked and its available quantity checked before anything is created.
- A two-phase flow — a pending checkout adjustment first, the asset created only when the stock actually leaves.
- An "Assetization" adjustment reason created automatically, and a traceable ASSETIZE- reference on the adjustment.
- Purchase cost inherited from the item's weighted average cost, falling back to buying price.
- Name, description, category, source warehouse and location all defaulted from the item and stock row, with an auto-generated barcode if enabled in your asset settings.
- The approved quantity honoured rather than the requested one, with both retained in the asset's metadata.
- Full provenance in metadata — source stock row, item, warehouse, location, adjustment and checkout.
- Individual or quantity-pool tracking, with a pool balance opened at the destination on finalisation.
- One conversion per adjustment, enforced, so a single stock issue cannot produce two assets.
What it does not do
- No reverse conversion. An asset cannot be turned back into stock — you retire it and receive the stock as two separate deliberate entries.
- No bulk conversion into individual assets. Ten individually tracked laptops from stock is ten conversions, because each needs its own serial number.
- No accounting journal posted on conversion, so moving value from inventory to fixed assets in the ledger is a manual entry.
- No prompt for the serial number, warranty date or condition — the fields exist and nothing insists you fill them at the moment you easily could.
- No conversion of an asset into a different item, or from one pool into another.
- No warning when the item still has stock and the asset has been created, which is normal but occasionally worth noticing.
The absent journal is the one to build a habit around. The physical and custody sides are handled properly — stock genuinely leaves, the asset genuinely appears, and the trail connects them — but nothing tells the ledger that inventory went down and fixed assets went up. That is a journal somebody has to post, and the amount is on the conversion record waiting to be used. Assetizations in a period are extractable as a report, which makes it a monthly task rather than a running one.
Why the alternative is worse than it looks
The common workaround is a stock write-off and a fresh asset typed in by hand. It produces almost the same two records and loses the one thing that matters: the link. Six months later the write-off says "adjustment, twelve thousand shillings" and the asset says "laptop", and nothing establishes that they are the same object. Which means an auditor asking why stock was written down gets a shrug, and the asset's cost is whatever somebody typed rather than what the unit actually cost you. The provenance is the entire value of doing this properly, and it is invisible until the day somebody asks.
Our take
Use the conversion rather than a write-off plus a hand-typed asset, because the link between the two records is the whole point and it cannot be reconstructed afterwards. Understand that it is two phases: your request creates a pending checkout adjustment and nothing else, and the asset comes into existence when the stock actually leaves — which is why asset creation inherits your existing stock controls instead of sidestepping them. Expect the approved quantity to win over the requested one, and expect an individual asset to require exactly one unit, since three laptops are three assets. Fill in the serial number while the device is in front of you. And post the inventory-to-fixed-assets journal yourself, monthly, from a report of the period's assetizations — that is the one part of the chain nothing does for you.
Stock that becomes an asset, traceably
A locked, quantity-checked conversion from a specific stock row through a pending checkout adjustment, with weighted average cost carried across, the approved quantity honoured, and full provenance back to the item, warehouse, location and adjustment it came from.
See plans & pricingFrequently asked questions
What happens when I convert stock into an asset?
Two things, in order. Your request locks the chosen stock row, checks the available quantity, and creates a pending checkout adjustment with an "Assetization" reason, a checkout line and a stored payload describing the intended asset. The asset itself is created only when that adjustment is processed — so the asset appears at the moment the stock genuinely leaves, rather than on request.
What cost does the new asset carry?
The item's weighted average cost, falling back to the buying price if no weighted average exists. This is the right default: the unit you removed was one of several received at possibly different landed costs, so the weighted average is the only figure that makes the value leaving inventory equal the value arriving in the asset register. You can override it, but a cost that differs from the weighted average will look like an error to whoever finds it later, so note why.
Can I convert five units into one asset?
Only as a quantity pool. An individually tracked asset must resolve to exactly one approved unit, and finalisation will refuse anything else with a message pointing you at pool tracking. That is correct — five laptops are five assets with five serial numbers. For genuinely interchangeable items like chairs, pool tracking takes the approved quantity as the pool quantity and opens a balance at the destination.
What if fewer units are approved than I requested?
The approved quantity wins. Request five and have three approved, and you get an asset for three — and both numbers are kept in the asset's metadata, so the difference is visible rather than lost. This is a consequence of the asset being created at finalisation rather than at request.
Can I convert an asset back into stock?
Not as one operation. You would retire the asset and receive the stock separately, as two deliberate entries with notes explaining the connection. Because there is no reverse path, it is worth being reasonably sure before converting — although in practice items that become assets rarely go back to being saleable stock.
Does the conversion post an accounting entry?
No. The physical and custody sides are handled — stock leaves, the asset appears, and the trail connects them — but nothing tells the ledger that inventory decreased and fixed assets increased. That journal is manual. Assetizations in a period are extractable as a report, so treat it as a monthly close task with the amounts already sitting on the conversion records.
