Asset Numbering Scheme: How to Number Equipment That Moves (2026)

There are two kinds of code in a working operation, and almost every numbering argument comes from confusing them.

The first is the address of a place. A shelf, a bay, a bin. It does not move, it sits in an order, and it has neighbors on either side. Naming those is a solved problem and a separate one, covered in the warehouse bin location guide — that page opens with "every item needs an address," and that is exactly the job it does.

This guide is about the other kind: the identity of a thing that moves. The number on a drill, a scaffold tower, a laptop, a generator. It has no position and no neighbors. Asset 0044 is not physically between 0043 and 0045, and it never will be.

That single difference generates every rule below. An address is ordered, so you leave room in it. An identity is unordered, so you pad it, never reuse it, and keep every changeable fact out of it. Once you see which kind of code you are designing, the rest stops being a matter of taste.

And it is worth an afternoon before you assign number one, because an identity is one of the few decisions in a small operation that you make once and live with for a decade.

Why the scheme outlives everything around it#

The reason an asset number is so hard to change is that it leaks. You assign it in your system, but within a month it exists in places you do not control: a maintenance log, a lease schedule, a photo caption, an email to a supplier, a repair ticket at a shop across town. You can renumber your own records in an afternoon. You cannot renumber theirs.

An address does not leak the same way. Nobody outside your building has an opinion about shelf S04. A tag number ends up etched on the thing, written on a work order, quoted in an insurance schedule, and remembered by the person who has been there twelve years. Change it and every one of those goes stale at once.

That leakage is why an identity has to be designed for the organization you will be in five years, not the one you are in now. The failure is never "we ran out of numbers on day one." It is "we ran out in year four, and the workaround we invented in a hurry is now permanent."

Smart numbers versus dumb numbers#

This is the central argument, and most people get it wrong in the same direction.

A smart number encodes meaning in the digits. Something like DRL-WH2-0043 — a drill, in warehouse 2, item 43. It reads beautifully. You can look at a tag and know three things without touching a computer. Every instinct says this is the better design.

A dumb number is just a number. 0043. It means nothing at all. Everything you want to know — what it is, where it lives, who has it — lives in columns next to it in your list.

The smart number is a trap, and here is the precise mechanism. Meaning encoded in a number is a snapshot of one moment, frozen into an identifier that is supposed to be permanent. The moment anything changes, the number becomes a lie that nobody has authority to correct.

Warehouse 2 closes and everything moves to the new building. You now have forty tags reading WH2 in a warehouse that does not exist. You have three options and all of them are bad: renumber everything (breaking the leakage described above), leave the numbers wrong (and train every new hire that WH2 does not mean WH2), or start a second scheme alongside the first (and now you have two conventions, which is how schemes really die — not in one collapse but by budding).

Notice what happened there. Encoding a location into an identity welds an unordered thing to an ordered one. The address was allowed to change, because that is what addresses do when you reorganize, and it dragged the identity with it. The reorganization is not hypothetical either. Businesses that buy equipment are businesses that grow, and growth is exactly what moves things around. Any encoded attribute that can change is a scheduled failure with an unknown date.

A dumb number cannot go wrong, because it never claimed anything. The drill moves to the new building; you change the location column; the number 0043 is exactly as true as it was yesterday. Attributes belong in columns because columns are editable and numbers are not.

The counter-case, made honestly

There is one place a prefix genuinely earns its keep, and it is worth stating properly rather than waving away.

A prefix is defensible when it encodes something that is fixed for the life of the thing, and when it needs to be told apart at a glance, physically, by someone not holding a phone.

The classic case is asset class where the classes are handled by different people. If your ladders, harnesses and lifting slings are inspected on a legal schedule and your hand tools are not, then a LIFT- prefix is doing real work: the inspector walking the yard can see at a distance which tags are theirs, and no lifting sling ever becomes a hand tool. The prefix names something that cannot change.

Contrast that with a category prefix like PWR- for power tools. It sounds equally fixed until the day you reclassify, or acquire a thing that is genuinely two categories, or someone argues for twenty minutes about whether a bench grinder is PWR- or SHOP-. If people can argue about which prefix applies, the prefix is not fixed and does not belong in the number.

The test: would you renumber the asset if this attribute changed? If yes, it can be a prefix. If you would leave the number alone and edit a field, it must be a field.

And keep it to one prefix. LIFT-0043 is fine. LIFT-YRD-2024-0043 is a smart number wearing a disguise, and two of those four segments will be wrong eventually.

How many digits, and why running out is the real risk#

Pick a width and pad it. If you have sixty assets today, four digits looks absurd — 0043 for the forty-third of sixty items. Use four anyway, or five.

The reason is asymmetric cost. Looking silly costs you nothing; a leading zero on a tag bothers no one. Running out costs you the scheme. When you assign 999 and the next thing arrives, you have to invent something on the spot: 1000 (now your widths are inconsistent and every sort breaks), or 999A (now you have letters in a numeric field), or you restart at 001 with a new prefix (now you have two schemes).

Sit down and estimate honestly: assets today, plus what you buy in a year, times ten years, and then double it because you always end up tracking more categories than you planned — the furniture, the IT kit, the tooling nobody thought was worth tracking until something walked. Take that number and add a digit. Four digits covers 9,999 assets and is right for the large majority of small operations. Five if you track consumable-adjacent things or expect to acquire another business.

Why you do not leave gaps here

If you have set up shelf and bin codes before, you have met the opposite rule: leave gaps in your numbering — use S01, S02, S05 instead of S01, S02, S03, so you can insert S03 and S04 later without renaming everything. That advice is correct, and it is correct for exactly the reason this section gives you the opposite one.

A shelf has an order and it has neighbors. There is a real physical space between S02 and S05, and one day a unit goes into it. The gap in the numbering is holding that space open, so the code still reads in order when the new shelf arrives.

An asset has neither. Asset 0044 is not between 0043 and 0045 in any sense that survives the morning — the three of them may be in different buildings by Friday. So a gap in an asset sequence is holding a space open that nothing can ever occupy. It buys you nothing, it makes people wonder what happened to the missing numbers, and it spends the digit width you just carefully sized.

Both rules come from the same principle: put the slack where the order lives. Addresses are ordered, so leave gaps in them. Identities are not, so pack them tight and pad them.

And never reuse a number. When an asset is scrapped, its number retires with it. Reissuing 0043 to a new item means every historical record of the old one now points at the wrong thing, and the maintenance history of a machine you sold gets silently attached to one you still own. This is the one place identities are stricter than addresses: a bin can be emptied and refilled all day, because the address describes the space and not the contents. An identity describes one thing and retires with it.

What never to encode#

Four attributes turn up constantly in home-grown schemes, and all four are mistakes for the same reason: they change.

The location. Things move. This is the most common encoding and the most reliably fatal, because moving things is what a working operation does every day. Location is the definitive column-not-digit attribute — and it already has a perfectly good code of its own, which is the point. The address is a separate field, and keeping it separate is what lets it be updated.

The owner or the department. People leave. Departments merge and get renamed. An asset numbered for the person who requested it becomes a small archaeology problem the moment they resign, and worse, it discourages reassigning the thing at all because the number says whose it is.

The year purchased. This one is seductive because the year genuinely does not change — 2024 will always be 2024. But it is still wrong, for three reasons. It publishes the age of your kit to anyone who reads a tag, including someone valuing it. It creates a psychological pressure to retire on the number rather than on condition. And it forces an awkward decision every time something is rebuilt, transferred in from an acquisition, or bought used — is that the year you bought it or the year it was made? Put the acquisition date in its own column — in our items an attribute or a line in notes; there is no date field.

The price. Never. It goes out of date immediately, it is nobody's business who reads the tag, and it invites theft to be targeted rather than opportunistic.

The pattern across all four: if you would ever want to *update* it, it is not part of the identity.

Leading zeros and the spreadsheet trap#

If you pad your numbers — and you should — you will meet this one, and it destroys data quietly.

Open a CSV in a spreadsheet program and a column of values like 0043 gets read as a number. Numbers do not have leading zeros, so the program helpfully removes them. 0043 becomes 43. Save the file. The zeros are gone permanently, and now half your records are 0043 and half are 43, and no lookup matches. Nobody notices at the time because the sheet looks fine on screen.

Three defenses, in order of how well they work:

1. Use a prefix. AST-0043 is unambiguously text and no spreadsheet will touch it. This is the single strongest reason to run a prefix even when you do not need it for category. It also makes your asset numbers searchable and instantly recognizable in an email.
2. Import, do not open. Use your spreadsheet's import-text function and set the column type to Text before it loads, rather than double-clicking the CSV.
3. Never round-trip a file. If a CSV has been opened and saved by a spreadsheet, treat its ID column as suspect and check a padded value before you rely on it.

The same trap catches anything that *looks* like a number but is not — long digit strings get rendered in scientific notation and lose their last digits, and things like 1-2 get read as dates. A text prefix protects you against all of it.

Worth knowing: the damage happens in the spreadsheet, not on the way in to a system. A well-built importer reads every column as text precisely so padded codes and long barcodes arrive intact. What it cannot do is restore zeros that a spreadsheet already ate before the file was saved. So the order matters — protect the file first, import second.

Where the number lives#

The same number needs to exist in three places, and they need to match exactly.

On the thing. Physically attached, durable enough to outlast the asset, positioned where someone can read it without dismantling anything. This is the part that is a materials question rather than a numbering one.

In the list. One row per asset, with the number as the identity column, and every attribute you were tempted to encode sitting in its own field beside it: category, current location, condition, acquisition date, serial, supplier, notes.

On the label, as a scannable code. So people read it with a camera rather than by eye, because a hand-typed asset number is a typo waiting to happen — 0 and O, 1 and I, and transposed digits that produce another valid number rather than an error.

That last point deserves a caveat most numbering guides skip. Number and label the thing, not the place. It is very easy for a numbering project to drift into numbering shelves and bins, because they are stationary and easy to label and it feels like progress. That work is worth doing, but it is the address problem, not this one, and it does not get you an asset register at the end of it. The thing that moves is what you actually need to identify — it is what gets borrowed, needs service, and goes missing. The place is best handled as something you pick from a list of your locations rather than something you scan. In practical systems that is exactly how it works: items carry a scannable code, and the location is chosen from a list of locations you have already set up. Design your scheme on that assumption and it will fit how the work actually runs.

Equipment that arrives with a manufacturer serial#

Every machine of any value arrives already numbered by whoever built it. The temptation is to use that as your asset number, since it is unique, permanent and already physically attached.

Do not. Use both, in different places.

The manufacturer's serial is theirs, not yours. It is inconsistent in format between vendors, sometimes twenty-two characters of mixed case, sometimes duplicated across product lines, and occasionally re-issued. It is unreadable aloud over a phone. It is often stamped somewhere that requires a flashlight and a mirror. And crucially, plenty of your assets will not have one — workbenches, ladders, custom fixtures, offcuts of tooling — so building your scheme on serials means inventing a fallback for everything unserialized, which means two schemes again.

The right shape: your asset number is the identity, the serial is an attribute. Record the serial verbatim, exactly as printed including any dashes and letter case. You need it for warranty claims, recalls, service calls and insurance, and in every one of those conversations the other party will ask for their number, not yours. Our item search matches name, item code and barcode, so a serial in notes is read off the item or an export, not typed into search.

Before you tag anything, decide which field will hold it. Many item records carry a code field and a barcode field and nothing named for a manufacturer serial — ours included. Put it in the notes field, or add a Serial attribute of your own to the item (Attributes, then Add attribute) — both hold it, but they are not equivalent later. Notes is a field an importer can fill from a spreadsheet column; a field you add yourself is filled one item at a time — by hand or via the Assistant. If you ever expect to bulk-load assets from a sheet, use notes. Either way use the same one on every asset — a serial recorded in three different places is a serial nobody can find. Finding that out halfway through a tagging afternoon means going back over everything you already did.

Same logic for anything with a UPC or EAN from the factory — that is a manufacturer code identifying a product type, not your individual unit. Two identical drills share a UPC and are still two different assets with two different histories. Keep the manufacturer code separate from your own item code; conflating them is how one repair record ends up attached to both drills.

Renumbering a scheme that is already broken#

If you are reading this with an existing scheme that has already turned into a lie, the answer is not a weekend where everything gets a new tag. Big-bang renumbering fails in a specific, predictable way: it takes longer than planned, it gets abandoned partway through, and you finish with a hybrid that is worse than what you started with.

Do it by attrition instead.

Freeze the old scheme. From today, no new asset gets an old-format number. That single step stops the problem growing and costs nothing.

Start the new scheme in a range that cannot collide. If the old numbers run to about 700, start the new ones at 2001, or give them a prefix the old ones never had. Any accidental overlap during a transition is a bad afternoon.

Keep the old number forever, in a column. An "old number" or "legacy ID" column, populated for every renumbered asset. This is what makes the whole approach survivable, because the old number is still out there in maintenance logs, lease documents and people's memory. When someone asks about asset 214, you can find it. Deleting the old number is the mistake that turns a migration into a data loss.

Renumber on contact, not on schedule. Every time an asset comes back from a job, goes in for service, gets counted, or is issued to someone and returned, it gets its new tag then. It is thirty seconds inside work that is already happening, rather than a project competing with real work.

Renumber the highest-value things first, and anything currently under a maintenance or compliance obligation, since those are the records where being able to find the right history actually matters.

Set an end date and accept a remainder. After a year, whatever is still on old tags is either rarely used or has quietly stopped existing — and that remainder list is a useful audit finding in itself.

The check before you commit#

Take your proposed format and write down five assets you actually own. Then walk each of these:

• If this asset moves buildings tomorrow, is the number still true?
• If the person using it leaves, is the number still true?
• If you reorganize your categories next year, is the number still true?
• Can someone read this number aloud over a phone without spelling anything?
• Will a spreadsheet mangle it?
• Assign the last number this format allows — can you honestly say you will never get there?

A format that survives all six is one you can stop thinking about, which is the entire point. Something like AST-0043 — one fixed prefix, four padded digits, nothing else — passes all six and is, deliberately, boring. Boring is what you want in an identifier. All the interesting information belongs in the columns beside it, where you can change it when the world changes.

Setting the scheme up in your list#

Whatever you use to keep the list — and a spreadsheet is a perfectly honest place to start — the shape is the same: one row per asset, the number as the identity column, and separate columns for everything you resisted encoding.

If you bring an existing list into a proper system, two details are worth checking before you import.

First, make sure your asset number column is actually mapped to the SKU field — that is the item code. It is easy to import a file with the code column left unmapped, and systems cope by generating placeholder codes for you — which is technically fine and practically a disaster, because now the numbers on your tags and the numbers in your system are two different sets. Systems vary in whether they tell you; a good importer says so by name and tells you to re-import with your code column mapped. Check the mapping before you commit the import, and check a padded value afterwards to confirm the leading zeros survived the trip.

Second, expect a few of your columns to have nowhere to land. The item code, name, barcode, location, category, supplier, quantity, selling price, cost, min and max stock, description and notes all have a home in our importer. Watch the two money columns — the one labeled selling price is what you charge and cost is what you paid, so map an asset sheet's purchase-price column to cost. A manufacturer serial, a condition rating, an acquisition date and an old legacy number do not — so plan to fold those into the notes column or add them by hand afterwards. A holder's name is not a notes column at all — who has a thing is tracked by check-in and check-out, which is a Pro-plan feature. A good import preview lists any column it cannot place before you commit, so you should see them coming — but it is better to have decided in advance than to be making the call with a half-imported file in front of you.

Download the free asset numbering worksheet — the encode-or-column test, the padding decision and the changeover plan, with the import mapping printed inside the file. A spreadsheet version with eight worked example rows is at asset-numbering-sample.csv. No signup, nothing uploaded.

InventoryQuick keeps your own item code and a separate barcode field on each item, so your scheme and the scannable code do not overwrite one another — and locations are picked from your own list rather than scanned. Start your 7-day free trial.

Related: Warehouse bin location system · Warehouse labeling guide · Print barcode bin labels · QR code inventory management