A Register Is a Rhythm, Not a Record
You can record that an asset was verified. You cannot start a verification, assign it, track what is outstanding or close it. The stock module can do all four for a count — which makes this a design inconsistency rather than a missing feature.
The difference between an asset register that is trusted and one that is quietly ignored is not the data in it. It is whether anybody has looked at the physical objects lately, and whether the system knows who has not.
The event exists
Verification is one of nine movement actions this product genuinely records. Somebody physically confirms an asset is where the register says, and that becomes a row with a person and a timestamp against it. That part is real and it is properly built.
What is missing is everything around the event. There is no verification round, no assignment of a location to a person, no list of what is still outstanding, no due date, and no closing moment where the exercise is declared finished and its exceptions dealt with.
The stock module already solved this
Inventory has the entire structure. A count plan. A session created from it. Per-line statuses as counting proceeds. A recount request that carries a reason and writes an audit entry. And a session that cannot be closed while any line is still submitted or awaiting recount.
That last constraint is the one that makes the difference, and it is worth stating on its own: the system refuses to let you declare a count finished while it contains an unresolved disagreement. That is not a feature you notice in a demonstration. It is the feature that makes the number mean something six months later.
Counting stock versus verifying assets, in this product
| Capability | Stock count | Asset verification |
|---|---|---|
| A single recorded event with an actor and a time | Yes | Yes |
| A plan that groups what is to be checked | Yes | No |
| A session with a start and an end | Yes | No |
| Per-line progress, so you can see what is outstanding | Yes | No |
| A dispute path with a reason recorded | Yes | No |
| A refusal to close while something is unresolved | Yes | No |
| A variance that becomes an approved correction | Yes | No |
Built and maintained Configurable by you, not maintained by us Not built
Seven rows, one match. The asset module has the atom and none of the molecule.
A verification you can record but cannot organise is a verification that happens when somebody remembers, which is another way of saying it happens after the loss.
How to run one anyway
This is a discipline problem with a workable manual answer, and it is worth writing down because the manual answer is genuinely most of the value.
-
Scope by location, not by category
A person can walk a floor. Nobody can walk a category. Export the register filtered to one location and that is the round.
-
Set a date and name a person per location
The system will not hold this, so it lives in whatever you already use to assign work. The scan itself is fast — every asset carries a scannable label.
-
Record each confirmation as a verification movement
This is the part the product does properly. The result is a dated, attributed record per asset that survives everybody who was there.
-
Close the round by exception, from a filter
Anything in that location whose last verification predates the round start was not seen. That filter is your outstanding list, and reconstructing it is the manual cost of the missing session.
-
Deal with what was not found, explicitly
Lost and damaged are both recorded movement actions. Use them. An asset quietly left unverified for three rounds is how a register stops being believed.
The one thing to do on day one
Decide what "verified recently" means for you — ninety days, six months, a year — and write it down. Without a stated interval, "last verified" is a date with no meaning attached, and a register full of dates that mean nothing is indistinguishable from a register nobody checks.
Our position
The verification event is properly built and the campaign around it is not, so this is a rhythm you run rather than a process the system drives. Run it by location, on a stated interval, and use the last-verified date as your exception filter. If you are audited on custody — donor-funded equipment, regulated plant, anything at a client site — raise the campaign requirement before a trial, because the manual version is real work and you should price it.
What AWRA OpsHub does today
- Verification as a first-class recorded movement, with the person and the time.
- Scannable labels on every asset, so confirming one is a scan rather than a search.
- Lost and damaged as recorded movement actions, so an exception has somewhere honest to go.
- Location filtering on the register, which is what makes the manual round workable.
- Full movement history per asset, so "when was this last seen" is always answerable.
What it does not do
- A verification plan, round or session of any kind.
- Assignment of a verification to a person or a team.
- An outstanding list, a completion percentage or a due date.
- Any refusal to consider a round finished while assets remain unseen — there is no round to finish.
- A verification variance that becomes an approved write-off, the way a stock count variance becomes an adjustment.
- Any scheduled prompt to verify anything, ever.
Not ours, by choice
- The stock module has the whole structure this one lacks. That is an inconsistency in our product rather than a considered position, and we would rather name it than explain it away.
- The manual round described above is what we would actually tell a customer to do, not a face-saving suggestion. It works. It costs somebody an afternoon a quarter.
- Nothing here is Malaysian. Malaysia is here as a market of multi-site operations where the equipment is in a building nobody from head office visits monthly.
What is not built for Malaysia today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Malaysia. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a MyInvois connection, an SST engine, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
MyInvois submission and validation
Submission to the MyInvois portal or API with the validated document and its QR returned onto the invoice, the seventy-two-hour rejection and cancellation window tracked, consolidated invoices assembled where the relaxation period still allows them, and buyer TIN and identification captured at the point of sale rather than chased afterwards. Sales tax and service tax handled as the two different taxes they are, at the rate and band each service actually carries.
DuitNow, FPX and bank feeds
DuitNow and FPX collection matched to the invoice, bulk payment files in the format your bank accepts, and statement feeds wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
EPF, SOCSO, EIS and monthly tax deduction computed on live records, with the contribution schedules and the annual forms produced in the layout each body expects rather than rebuilt in a spreadsheet each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
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. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions about verification in any asset system
Show me the assets not verified this year.
A good answer sounds like
A filter, with rows.
What it actually means
This is the whole question. If the answer needs an export and a spreadsheet, the register records verifications and does not manage them.
Can I assign a verification round to somebody?
A good answer sounds like
Yes, by location, with a due date.
What it actually means
Without assignment there is no accountability, and the round becomes whoever has time.
What stops a round being closed with items unseen?
A good answer sounds like
A refusal, and a named exception path.
What it actually means
The strongest control in any counting system, and the one most often absent. Ours is absent for assets and present for stock.
What happens to something that is never found?
A good answer sounds like
A recorded loss, with an actor.
What it actually means
If the answer is "it stays on the list", the register will grow a permanent tail of fiction.
Pick an interval and hold it
The register is only as good as the last time somebody looked. If you want help designing the round — or the campaign structure built properly — that is a conversation worth having early.
Talk about asset verificationFrequently asked questions
Can I scan assets on a phone to verify them?
Assets carry scannable labels and the verification is a recorded movement, so the confirm step is quick. What is not there is the round holding those confirmations together, which is the subject of this page.
Why does stock have sessions and assets do not?
Because stock counting was rebuilt and asset verification was not. It is a history rather than a design, and the honest thing is to say so — the structure that stock uses is the structure assets would need.
Does an unverified asset show up anywhere on its own?
No. Nothing prompts, nothing alerts and nothing escalates. The last-verified date is a fact you have to go and look at, which is why deciding what interval you hold yourself to matters more here than in a system that nags.
