Almost every organization starts the same way. A clipboard by the storeroom door, or a shared spreadsheet with columns for name, item, date out, date back. It holds up fine until somebody asks a question the sheet cannot answer.
Who has the good projector? Not "a projector." The one that actually works, as opposed to the two that need a bulb.
That question is where checkout sheets fall over, and it is worth understanding why, because the answer decides what kind of system you actually need.
"One of them" is not an answer
A spreadsheet tracks quantities. You had six laptops, four are out, two are here.
That is fine for consumables. Nobody needs to know which box of gloves went to the third floor. It falls apart the moment the things you loan out are different from each other, and loaned equipment almost always is.
Laptop 4 has the cracked hinge. Drill 2 is the one that came back with a dead battery. Camera 7 is the one that belongs to the grant-funded program and cannot leave the building. If your record says "4 of 6 checked out," you have lost all of that, and the only way to get it back is to walk to the shelf and look.
The fix is not a better spreadsheet. It is deciding that each physical thing is its own record, with its own identifier, its own history, and its own condition. Once every unit is distinct, "who has the good projector" stops being a question you answer by memory. We have written about why every inventory item deserves its own record if you want the longer version of that argument.
Four facts every checkout record has to carry
A row that says "Dave, laptop, 3/14" is missing most of what you will eventually need.
Which unit. Not the model. The specific one, by asset tag or serial.
Who has it, as a person in your system. Not a name typed into a cell. "D. Martinez," "Dave M" and "dave" are three different people to a spreadsheet and the same person in real life, which is how a search for outstanding items comes back empty while the item is sitting on someone's desk.
When it is expected back. Not just when it left. A checkout without an expected return date cannot be overdue, and anything that cannot be overdue will never appear on a list of things to chase.
What condition it went out in. This is the one that gets skipped and the one that causes arguments. Without it, every piece of damage is a dispute about whether it was already like that.
Overdue is a people problem, and the system decides how awkward it is
Here is the pattern in every organization that loans equipment: nobody wants to chase.
Asking a colleague to return a laptop feels like an accusation. So the sheet quietly accumulates rows that never got a return date, everyone stops trusting it, and eventually somebody does a full physical count and discovers three items nobody has seen in a year.
What changes this is not stricter policy. It is making the reminder come from the system rather than from a person. An automatic note that an item was due back on Tuesday is administrative. The same sentence from a coworker is personal. Same information, completely different conversation, and the only difference is who appears to be asking.
That is also why an expected return date matters more than it looks. It is not there to enforce anything. It is there so nobody has to be the one who noticed.
Condition is a second record, not a checkbox
Most systems treat return as a single action: the item comes back, the row closes.
In practice a return has two parts. The item is physically back, and the item is fit to go out again. Those are not the same event and collapsing them into one is how a broken drill gets checked out to the next person.
The useful pattern is that a return can put a unit into a state that is not "available." Back, but needs a battery. Back, but needs cleaning before it goes to a client site. Back, but flagged for someone to look at. The unit is in the building and off the outstanding list, and it still will not appear as available to the next person who needs one.
This costs nothing to record at the moment of return, when the person handing it back is standing right there and remembers what happened to it. It costs a great deal to reconstruct three weeks later.
The question that decides what you need
Everything above is operational. Here is the one that decides whether you need a real system or a better spreadsheet:
Who had this in March?
If the answer never matters to you, a sign-out sheet is genuinely fine and you should not buy software.
It starts mattering for specific reasons, and you usually discover them in the worst way. A laptop with client data on it needs a documented chain of custody. A piece of test equipment needs to show when it was last calibrated and who used it since. A grant-funded asset needs to prove it stayed inside the program it was bought for. Something got damaged and the insurer wants to know who had it.
A spreadsheet answers these questions only if nobody ever overwrote a row, which is exactly what a spreadsheet is for. The row for laptop 4 shows where laptop 4 is now. It does not show the last nine people who had it, because each of them typed over the one before.
History is the thing you cannot add retroactively. Either it was recorded as it happened or it does not exist.
What to actually look for
If you have decided the sheet is not holding, the shortlist is shorter than most software comparisons suggest.
Each physical unit gets its own record and its own identifier, so "which one" is always answerable. Checkout is tied to a real person, not a typed name. Every checkout has an expected return, so overdue is a state the system knows about rather than something a human notices. Returns can record condition, so a unit can be back without being available. And the history stays, so the question about March has an answer.
Everything else is preference. Barcode scanning is a convenience, and a good one, but a system that gets the five above right and has no scanner beats a scanner attached to a system that only tracks quantities.
Knowledge ERP tracks each unit individually and keeps the loan history with the unit rather than overwriting it, which is the part a spreadsheet structurally cannot do. You can see how that works on the asset check-in and check-out page, or start a trial and check something out to yourself to see what the record looks like.
The honest summary: if you loan out things that are interchangeable and nobody ever asks about the past, keep the clipboard. The moment the specific unit matters, or last March matters, the clipboard has already stopped working and you probably have not noticed yet.