How to Build an Asset Register From Nothing in an Afternoon

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.

Start with the free hundred assets and see whether the

first twenty fit how you work.