Identified assets
One record per physical thing, because each one is distinguishable and the difference matters. A laptop with a serial number, a vehicle with a registration, a generator with a service history.
They are also not inventory — inventory is consumed, and chairs come back. This is the category almost every asset system leaves out: things you own in quantity, that go out and return, that get damaged and lost, and that somebody is nonetheless responsible for. They get a balance per holder and place rather than a record each, and a movement is a transfer between two balances rather than an edit to a number.
Three kinds of thing
This is the modelling gap, and it causes real operational damage because the middle category gets forced into one of the outer two. Forced into individual assets, you create two hundred records for two hundred identical chairs and nobody maintains them. Forced into inventory, they are consumed on issue — so the chairs that came back last Tuesday have to be re-received as though they were a delivery, and nobody can tell you who had them.
One record per physical thing, because each one is distinguishable and the difference matters. A laptop with a serial number, a vehicle with a registration, a generator with a service history.
One record, many units, indistinguishable from each other — but they are returnable and somebody is responsible for them. Chairs, helmets, scaffold frames, tables, radios, high-vis vests, tents.
Quantities that are used up rather than returned. Cement, cable, gloves, printer paper, fuel. Issued out and gone; the question is how much is left and when to reorder.
The test is one question: does it come back? If it does, and you own more than a handful of identical ones, it is a pooled asset. Cement does not come back. Unit 4417 comes back and you need to know which one it was. Two hundred chairs come back and you do not care which two hundred — only how many, from whom, and in what state.
The mechanism
That sentence is the whole feature and it is worth being pedantic about. A system where quantity is a field somebody can change has no history — the number was 240 and now it is 216, and the difference is unexplained forever. A system where quantity is the sum of movements can always tell you why it changed and who made it change.
A check-out. Thirty-six leave the store balance and arrive on a custodian balance. The total owned is unchanged at 240 — nothing has been created or destroyed, it has moved.
A condition change is also a movement between balances, because condition is part of what identifies a balance. Nine damaged chairs are not nine chairs with a note on them — they are a separate balance, in a separate condition, in a separate place, and they can be counted separately in every report.
A transfer between sites. Same asset record, same total, a new balance at the other end — and the movement names both, so a discrepancy at Kisumu has a source balance and a quantity to argue with.
What identifies a balance is the combination of custodian, department, warehouse, location and condition. That is deliberately five dimensions rather than one: “40 chairs” is not useful, and “40 chairs held by the Ops department at Main Store on Shelf B in good condition” is something you can act on. Each balance additionally records when it last moved, so a pile that has not been touched in eight months is visible as such.
Ten movement actions
If the only way to change a balance is one of these ten, then every change has a reason, an actor and a timestamp by construction. There is no eleventh path where somebody types a different number, and that absence is the control.
Bringing a quantity into the system for the first time — the opening balance for a pool, at a place and in a condition. The only action that increases the total owned.
Units leave a store or department balance and arrive on a custodian's. The expected return can be recorded here, which is what makes a pooled asset chaseable.
Units come back. Condition is recorded at this end, which is how nine damaged chairs get separated from the twenty-seven that returned fine.
Units move between two holders or two sites without passing through a store. Both ends are named on the movement.
A quantity moves between warehouses or locations without changing who is responsible. Kept separate from transfer because place and person are different facts.
Somebody physically counted this balance and confirms it. The action that turns a claimed number into a verified one, and the one most often skipped.
A quantity changes condition, which means it moves to a different balance. It also raises a risk event, because damage in quantity is a pattern worth seeing.
Units that cannot be found. Recording three missing chairs honestly, with a date and a holder, is worth more than a total that has been wrong for a year.
A correction, made explicitly. When a count finds 126 where the system says 128, this is the action that reconciles it — as a recorded adjustment with a reason, not an edit.
End of life for a quantity. The units leave service with a date and a decision-maker rather than quietly vanishing from a total.
Each action carries its own permission — checking out, checking in, transferring, relocating, marking damaged, marking lost, retiring and adjusting are eight separate grants, so a storekeeper can issue and receive without being able to write anything off. And every movement records its source: a manual entry, a barcode scan, a QR scan, the mobile app, an import or the API.
Held, signed, receipted
Where a movement needs approval, the balances do not change while it waits. The pending movement exists, it is visible, it can be approved or rejected with a reason — and until somebody with the approving permission decides, the quantity is exactly where it was. A system that moves the stock and then asks for approval has built a notification, not a control.
Three modes — nothing held, high-risk only, or every covered action — with high-risk only as the shipped default and the covered action list under your control. Out of the box it covers check-out, transfer, relocate and retire; check-in is deliberately excluded, because making somebody wait for permission to return equipment is how equipment stays in a van.
High risk is defined by you: a value threshold, a list of categories, a list of asset types, or an individual asset flagged as always requiring approval regardless of the mode.
A pooled movement can take a signature from the person receiving the quantity, with their printed name and the moment recorded. It works with no signal and rides the offline queue, and it locks once the record is decided so it cannot be quietly backfilled to suit an argument later.
Signing is gated on recording the movement rather than on approving it — the person taking the mark at the gate is not the person authorising the handover from an office.
Marking a quantity lost or damaged raises a notification of its own, separate from the ordinary movement alerts. Damage and loss in quantity are a pattern — the same site, the same holder, the same month — and a pattern only becomes visible if the events are distinguishable from routine traffic.
Those alerts are catalogued, which means they have switches. That is worth saying because they once did not: they were tagged for push in code with no row on any preferences screen, so every registered device was paged and nobody could stop it.
All of it, on every movement, whether it needed approval or not
action / statusquantityfrom_balance / to_balancefrom_custodian / to_custodianfrom_department / to_departmentfrom_warehouse / to_warehousefrom_location / to_locationcondition_before / condition_afterexpected_return_atperformed_by / occurred_atapproved_by / approved_atrejected_by / rejected_at / rejection_reasonlatitude / longitude / accuracysource / scan_eventnotes / photos / signatureAnd a printable receipt per movement, so the person walking away with thirty-six chairs has a document naming the quantity, the date, the two parties and their own signature. That is the artefact the argument is settled with three weeks later.
The straight answer
Pooled tracking is a genuine third category and it is not a substitute for either of the other two. Here is the line, and the one question you should ask yourself before choosing it.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Utilisation reporting per pool is the item in that middle column that pays for itself fastest — it is the report that tells you whether you own 240 chairs because you need 240 or because nobody ever counted. Serial ranges within a pool is the other common ask. Tell us what you actually hold in quantity and we will come back with a written spec, a timeline and a price.
Around it
Who the balances belong to — six custodian types, none of which needs a login.
Open featureThe individual-tracking half of the register, for the things where identity matters.
Open featureThe consumable half, where quantities are used up rather than returned.
Open featureThe mark on a pooled handover — what it proves and what it does not claim to.
Open featureWhere the pooled-movement and risk alerts get their switches, and why they needed them.
Open featureIssuing thirty-six chairs at a site gate with no signal, and the queue that carries it home.
Open featureWhat changes
Which sounds trivial until the event, when forty are missing and the only record is a WhatsApp thread. A total that equals the sum of its movements is a total you can defend, and a balance broken out by holder, place and condition is one you can act on.
No more re-receiving your own chairs as though a supplier delivered them.
One asset, many balances, and a register somebody actually maintains.
Nine damaged units are countable, quarantinable and reportable on their own.
Every change is a movement with an actor, a reason and a timestamp. There is no editable field.
An expected return on a pooled check-out turns absence into a dated exception.
Risk events raised separately from routine traffic, with their own switches.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.