Your Warranty Spreadsheet Has an Expiry Column — and That Is the Bug

Almost every small business that sells physical things keeps a warranty register, and almost all of them keep it the same way: a spreadsheet with a row per item and a column called Expires.

That column is the bug. Not the spreadsheet — the column.

Three ways a stored expiry goes wrong

Somebody corrects the sale date. An invoice date was keyed as 6 March when the goods actually went out on 6 May. Fixing it is one keystroke. The expiry column does not move, because nothing tells it to, and from that moment the register disagrees with its own inputs.

Somebody changes the term. You move the standard cover on a product line from 12 months to 24. Every item already registered under it still carries the old date. There is now no single answer to "how long is this covered for" — there is the term, and there is the column, and they differ.

A row gets copied. The most common one. Somebody duplicates last year's sheet to start this year's, and a hundred expiry dates come along for the ride, attached to sale dates that have since been overwritten.

None of these announce themselves. The register keeps looking exactly as authoritative as it did before, right up to the moment somebody reads a date off it in a dispute.

The fix is not discipline. It is arithmetic: do not store the answer, store the inputs. Keep the sale date and the term, and work the expiry out every single time it is asked. Correct a sale date and everything downstream corrects itself — because there is no downstream. There is one calculation, run on demand.

The cost of doing it this way is real and should be stated: editing a term genuinely re-dates every item registered under it, so the software had better tell you how many that is before you press save. That is the honest trade. A number that can go stale, versus a number that can move under you when you change the rule it depends on. The second is far easier to live with, because it is visible.

The month-arithmetic trap

Here is a bug that ships in a startling amount of software, including software people pay real money for.

An item is sold on 31 August with a 6-month warranty. When does the cover end?

The answer is 28 February. What most date libraries hand you, if you ask them naively, is 3 March — because there is no 31st of February, so the calculation overflows into March and keeps going. The customer has just been given three extra days of cover they were never sold. Multiply by every item sold on a 29th, 30th or 31st.

The correct behaviour is to clamp to the last day of the target month. 31 August plus six months is 28 February; in a leap year, 29 February. The customer does not get extra days because the calendar is awkward, and does not lose any either.

A related trap, and a nastier one, sits a layer down. Ask a date library to parse 2026-02-31 — a date a human can type into a form in about a second — and a surprising number of them will not fail. They roll it forward to 3 March and return it as though nothing happened. Every date that flows from it is then plausible, precise, and three days wrong. Checking that a date exists before doing arithmetic on it is not defensive programming; it is the difference between a register you can quote and one you cannot.

"In warranty" — measured against which day?

A claim comes in on the last day of cover. Your assessment takes three weeks. Is it in warranty?

If your system answers by comparing the expiry to today, then the claim was in warranty when it arrived and out of warranty by the time you looked at it — and being slow has quietly become a way of rejecting claims. Nobody designs that on purpose. It is what you get by default, when the question is asked at the wrong moment.

The answer should be frozen at the date the claim was raised, and stored with the claim. Slow assessment then costs you what it should cost you, and nothing else.

This has one consequence worth knowing before you adopt it: if the sale date turns out to have been wrong, correcting it afterwards does not move a claim already raised against it. The claim has to be raised again. That is a real limitation and the right one — a frozen fact that can be silently un-frozen is not a frozen fact.

The field the whole thing turns on

Of everything in a claims record — dates, status, RMA number, photographs — the field that decides whether the record is worth keeping is the one people leave optional: the reason.

A claim marked rejected with nothing written on it is not a record. It is a note to yourself that you will not be able to read in six months, and it is worthless the moment somebody disputes the decision. The same is true of approved: goodwill granted with no reason recorded is indistinguishable, later, from an error.

Make the reason mandatory at every step that changes the answer to the customer — assessed, approved, rejected — and make it mandatory on every door into the system, not just the form. A field that is required in the UI and optional in the API is optional.

What the software that does this properly costs

There is warranty software that does all of the above, and it is worth knowing what it costs, because the number is surprising in a specific way. Both figures below were read off the vendor's own pricing page on 22 August 2026.

Vendor	Entry price	Sized by
WarrantyHub	$549/mo	~1,000 claims a month
Claimlane	$800/month	2,000 tickets a year

Both read off the vendor's own pricing page, checked 2026-08-22. Claimlane also quotes €700/month and bills annually. There is deliberately no three-year column here: see the next paragraph for why that arithmetic would mislead.

Read the scale before you read the price. WarrantyHub's entry tier buys a thousand claims a month. Claimlane's buys two thousand tickets a year. These are platforms for manufacturers, builders and home-warranty administrators, and at those volumes the prices are entirely reasonable — WarrantyHub prices "by claim volume, not per seat" and includes unlimited users, which for a claims department is the fair way round.

So the interesting finding is not a saving. It is the shape of the market: the cheapest price published anywhere in this category is $549 a month, and below that the market publishes nothing at all. A workshop registering four hundred items a year and handling a claim a fortnight is not being served expensively. It is not being served.

Which is why the register is a spreadsheet.

And it is why, if you go looking for a smaller tool, the things to check are not features. They are these four:

1. Is the expiry computed from the sale date and the term, or stored in a column?
2. Does 31 August plus six months give you 28 February?
3. Is in warranty frozen at the date the claim was raised?
4. Can a claim be rejected with an empty reason — through any door, including the API?

A tool that gets those four right and has no other features is a better register than a tool that gets them wrong and has fifty.

Warrantora is our attempt at exactly those four and very little else: one payment, your own server, every expiry computed, and a decision that will not save without a reason written on it. It has no customer portal, no shipping labels and no money in it at all — that is the trade being made, not an omission.

A note on the numbers

Both prices above came from the vendors' own pricing pages, fetched on 22 August 2026, with the quoted phrases checked back against the fetched page. A third vendor in this category was left out entirely: two major software directories published two different prices for the same product on the same day — $69 per user per month, and $299 — and the vendor's own site returned nothing to repeated fetches. Two aggregators disagreeing is not a price, so no figure was published for it here at all.

If you are comparing tools in this category, open each vendor's own page. Directory listings in warranty software go stale quietly, and there is not enough traffic in the niche for anyone to notice.