Where an Asset Comes From
An asset in this product is born one of two ways: entered by hand, or converted from stock. Neither of them remembers the purchase order. For a business buying equipment against a grant, a client project or a capitalisation threshold, that forgetting is the whole problem.
Every asset register eventually gets asked a question it was not designed for: what did this cost, and whose money was it. The first half is usually fine. The second half is where registers quietly fail, and the failure is structural rather than a missing field.
The two doors in
An asset here is created directly, on a form, by a person; or it is converted from an inventory item that was already received into stock. The conversion is a proper, first-class path — it has its own request validation, its own record of the conversion, and it enforces the same ownership rules as the direct route.
What neither door carries is where the thing came from. The purchase order that bought it, the supplier that supplied it, the requisition that justified it and the budget line it was charged to are all upstream facts, and the asset arrives without any of them.
How much provenance survives each hop
Requisition
Who asked, why, against which department
Purchase order
Supplier, price, quantity, approval
Goods receipt
What arrived, when, against which order
Stock
Quantity and a weighted average cost
Asset
A tag, a category, a purchase cost you re-type
The steepest drop is the last one, and it is the one nobody watches, because by then the item is on a screen that looks complete.
The part that makes this odd
This product already knows how to carry a project through a stock movement. When stock is checked out, the check-out can name the job it is for, and that issued cost becomes a component of the project's actual cost. The design decision behind it is a good one: the unit cost is stamped at the moment of issue, so a closed job costs the same amount twice.
So the capability exists, on the neighbouring path, doing precisely the thing an asset conversion would need. It was simply never applied to the conversion, and nobody noticed because the two paths are used by different people for different reasons.
The gap is rarely that a system cannot do something. It is usually that it does it on one path and not on the one beside it.
Who this costs, and how much
| Situation | What breaks | Severity |
|---|---|---|
| Everything bought from one budget | Nothing. Re-typing a cost is a minute. | None |
| Equipment bought against client projects | No link from asset to job. Recovery and rebilling are reconstructed by hand. | Moderate |
| Grant-funded equipment | No funder on the asset. Donor asset registers are assembled from purchase orders, separately. | High |
| A capitalisation threshold policy | Nothing enforces it, because the asset does not know its own purchase document. | Moderate |
| Warranty claims | Supplier and order are not on the asset, so the claim starts with a search. | Low, until it is not |
The grant case is the sharpest, and it generalises well beyond aid work. Any arrangement where somebody else's money bought the machine — a client, a funder, a parent company, a leasing arrangement — needs the asset to remember whose money it was. A register that cannot answer that is answering a different question than the one being asked.
The workaround, and its honest limit
Put the purchase order reference in a custom field on the asset at creation, and make it mandatory in your own process rather than in the software. This works, and it is what we would tell you to do on day one.
Its limit is that it is a string. Nothing validates that the order exists, nothing stops two assets claiming the same one, nothing notices when an order is cancelled, and no report joins the two. It converts an impossible reconstruction into a possible one; it does not make it automatic.
One link, and then two things that fall out of it for free
This is unusually cheap for what it unlocks, because the neighbouring path already proves the pattern works. That is the argument for doing it rather than a reason to assume it is trivial.
The purchase order on the asset
Carried through the stock-to-asset conversion, and settable on direct creation with a picker rather than a typed string. Supplier, order date and order value come with it, so the purchase cost stops being re-keyed.
The project or funder, inherited
Exactly what the stock check-out already does for a job. Once the order is on the asset, the budget line that paid for it is one hop away, and a funder asset register becomes a filter instead of a project.
A capitalisation threshold that can actually run
A received item over a stated value prompting a conversion to an asset, rather than a policy people remember. Only possible once the asset knows its own purchase document, which is why it is third rather than first.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If your assets are bought against grants or client jobs, this is the one to raise before a trial.
Talk to us about asset provenanceWhat AWRA OpsHub does today
- Direct asset creation, with category, purchase details, tag and a printable scannable label.
- Conversion from an inventory item into a tracked asset, as a recorded conversion with its own validation.
- Ownership — owned, leased or borrowed — enforced on both creation paths and on the importer.
- Custom fields on assets, which is what the purchase-order workaround uses.
- A stock check-out that names the project it is for, with the unit cost stamped at issue.
What it does not do
- Any link from a purchase order to an asset. Not on conversion, not on direct creation.
- Supplier on the asset, inherited or otherwise.
- A project, grant or funder inherited by an asset from anything upstream.
- A capitalisation threshold, or any prompt to convert a received item into an asset.
- A warranty record tied to the order that bought the equipment.
Not ours, by choice
- The project-tagging capability exists on the stock check-out path and was simply never extended to the asset conversion. We would rather describe that accurately than present it as a deep architectural limit, because it is not one.
- The custom-field workaround is a string with no referential integrity. It is worth doing and it is not a substitute for the link.
- Nothing here is Indian. Bengaluru is here as a market where equipment is bought quickly, frequently against a client engagement, and the question of whose budget it came from arrives later.
Our position
If every asset you own was bought with your own undifferentiated money, this changes nothing for you and you can stop reading. If any of it was bought against a grant, a client project or a cost centre that will one day ask, put the order number in a custom field from the first asset you create — retrofitting provenance is the single most expensive kind of data work there is.
Ask where the asset came from
In any evaluation, create an asset from a receipt and then ask the register which order bought it. The answer tells you more about the data model than an hour of feature comparison.
Talk about asset provenanceFrequently asked questions
Can I bulk import assets with a purchase order reference?
You can import into a custom field, which is the same workaround at scale. There is no order relationship for the importer to populate, so the import inherits the same limitation as the form.
Does the conversion carry the stock cost onto the asset?
The conversion is recorded and the asset carries purchase details, but treat the cost as something to check rather than something to assume — the honest answer is that the two paths were never designed as one chain, which is the subject of this page.
Is a funder asset register possible today?
By hand, from purchase orders, filtered on whatever you used to mark the funding. That is a real answer and it is a report somebody assembles, not one the system produces.
