The fastest route to a working asset register depends entirely on where your list currently lives, and all three routes take an afternoon rather than a project. Import a spreadsheet, migrate from another system, or walk the building with a phone and let the walk build the register.
Most companies do not have a register because starting one looks like a project. It is not. Here are the three honest starting points.
If your list is in a spreadsheet
This is the common case. Someone, at some point, made a sheet. It is out of date, it has a column called "notes" doing four jobs, and it is still the most complete record you have.
Download the import template, paste your rows in, and let the importer tell you what it could not read before anything is saved. Two things save real time here.
Do not clean the spreadsheet first. Import it dirty and fix what the preview flags. Cleaning by hand before you know what the system objects to is work you may not have needed to do, and it is the step that turns an afternoon into a fortnight.
Get the dates unambiguous. 03/04/2026 is two different days depending on who typed it. Wurxa reads the whole column to work out whether you write day-first or month-first and tells you which it chose, but a column of ISO dates removes the question entirely.
Nothing is written until you confirm the preview, so a bad file costs you nothing but the attempt. That is worth knowing, because it means the correct approach is to try it rather than to prepare for it.
If it is in another asset system
Do not retype it. Whatever you are moving from, its export is closer to a finished register than anything you will produce by hand at eleven at night.
Ask us to move it. Send the export and we will map the fields and load it. The reason we do this rather than pointing you at a template is that every asset platform names things differently, and the mapping is a five-minute job for someone who has seen the shape before and a lost evening for someone who has not.
Ask specifically whether your custody history comes across, not only the current list. The history is the part that took years to accumulate and the part most migrations quietly drop.
If it exists only in somebody's head
This is the interesting case, and the approach is different: do not start with a list. Start with a walk.
Create an audit for one site, take a phone, and scan or type your way around the room. Every tag that is not already in the register becomes a new asset. By the time you have walked the floor, you have a register of exactly the things that are actually there.
This is the only method that produces a correct register on the first day. A spreadsheet import gives you a register that matches the spreadsheet, including whatever left the building two years ago and was never removed from the sheet.
It is also less work than it sounds. A single floor of a normal office is twenty minutes. A stockroom is ten.
What to record, and what to skip
The temptation is to capture everything. Resist it. For each asset you need:
Purchase cost, useful life, warranty and insurance dates all matter, and all of them can wait. They are the accountant's fields and the accountant has the invoices. What cannot wait is the record that the thing exists and who has it.
A register with four fields filled in for every asset is more useful than one with twelve fields filled in for a third of them.
The step people skip, and regret
Print the labels the same day.
A register whose items are not labelled cannot be audited, and an unaudited register drifts from reality at roughly the rate things get moved between desks and sites. Barcode or QR, print a sheet, stick them on.
The scanning is what makes every future count take an hour instead of a day, and you only get that if the labels went on at the start. Companies that skip this step end up with a register that was accurate once, which is a more frustrating outcome than never having built one.
After the afternoon
You will have a register that is roughly right. It becomes actually right the first time somebody walks a site with it, which is worth doing a fortnight later while the gaps are still obvious and the people who moved things still remember moving them.
From there it maintains itself, provided assignments are recorded at the moment of handover rather than reconstructed later.
Four mistakes that cost an afternoon
Building a category tree first. People spend an hour designing categories before entering anything. Enter fifty assets with rough categories and the right tree becomes obvious. Designing it in advance produces a structure that fits nothing you own.
One row per box rather than per item. "Dell monitors x12" is a purchase record, not an asset record. You cannot assign it to somebody, you cannot audit it, and you cannot tell which of the twelve broke. Twelve rows is the answer, and the importer will generate the tags.
Waiting for the finance data. Purchase costs live with whoever has the invoices, and waiting for them stalls the whole exercise. Enter the assets without costs and let finance fill the column later.
Recording the buyer instead of the holder. The custody field is who has the thing now, not who paid for it. Getting this wrong makes the register look complete while answering the wrong question.
What we learned building the importer
This part is not general advice. It is what happened when we wrote the thing that reads your spreadsheet, and it will save you an afternoon whichever tool you use.
Our parser originally matched thirteen exact header names and nothing else. A file exported from another asset system produced "could not find the header row" and imported precisely zero rows. The file was fine. The parser was being literal.
The fix was a synonym table, and building it taught us something worth passing on: most headers mean the same thing everywhere, and a few do not. "Description" is the asset's name in every asset system we could check. "Serial", "Serial No", "S/N" and "Serial Number" are one column. "Brand" and "Manufacturer" are Make. "Branch" and "Office" are Site. Those are safe.
"Owner" is not, and it is deliberately absent from our table. In some registers it means the person holding the item. In others it means the cost centre that paid for it. Guess wrong and you write a department name into the custodian field across four hundred rows, and nobody notices until somebody leaves and the offboarding list turns out to be nonsense.
So the rule we settled on, and the one worth applying to your own cleanup: map only the headers that are unambiguous, and put everything else in front of a person before it lands. Our importer shows a preview for exactly this reason. The preview is the only thing standing between a hopeful guess and a register you can no longer trust.
Two more things fell out of that work. Read by header name rather than column position, because somebody will insert a column and you do not want serial numbers silently written into Make. And say what you ignored: a file with a column we do not understand should import the rest and tell you what was dropped, not fail whole or, worse, succeed quietly.
If you are doing this by hand in a spreadsheet, the same three rules apply. Rename headers before you import, not after. Look at twenty rows, not two. And treat any column whose meaning you had to stop and think about as a column somebody should check.
Wurxa Assets supports all three starting points: a spreadsheet import with a preview before anything is saved, a migration we map for you, and a walk-the-floor audit from a phone. It is free for up to 100 assets with unlimited users and no time limit, so the first twenty cost you nothing but an afternoon. Start free, no card.
Related reading
Put the workflow into practice.
Start with every Wurxa feature for 14 days. No credit card required.
