A warranty check on one laptop takes a minute. Doing it across a fleet built from four manufacturers, bought over six years, through two resellers and one acquisition is a different job, and no manufacturer's website is designed for it.
This article is about that second job. It covers why warranty data drifts out of date, what each manufacturer actually lets you do, and how to end up with one expiration date per asset regardless of which of those routes it came through.
Why warranty data goes stale
Warranty information has an unusual failure mode. It is captured accurately, once, and then quietly stops matching reality while everyone assumes it still does.
Two separate things cause that, and they need different fixes. One is a process problem inside your organization, and the other belongs to the manufacturer.
It gets captured once and never again
New hardware arrives and goes into the inventory before the paperwork does, so the coverage fields stay empty and nobody circles back. Extended warranties get purchased months after the original order and land in a procurement folder rather than on the asset record.
Machines move between people and sites, get repaired, get replaced under warranty, and none of that updates a date that was typed in two years ago. The result is an inventory that reports coverage confidently and is wrong about a growing share of it.
The dates the manufacturer reports can be wrong
This one surprises people, because it happens even when the process is clean. Manufacturers anchor coverage to the date the unit shipped from them, which is the date they can verify. Buying direct, that lines up closely enough with your purchase.
Buying through a distributor or reseller, it does not. The shipping date belongs to the first leg of the journey, so a machine that sat in a warehouse for two months shows coverage starting two months before your company owned it. This is not specific to one manufacturer, and correcting it means going back to the vendor with the purchase documentation.
Checking warranties by vendor
Manufacturers are usually compared by whether they have a warranty lookup page, which is the wrong question because almost all of them do. The useful question is what each one lets you do at scale, and the answers differ more than you would expect.
Here is where the major manufacturers stand. The last column is the one that decides how much manual work your process ends up carrying, because only some of them expose a warranty application programming interface (API) that a third-party tool is allowed to use:
| Vendor | Identifier it asks for | Bulk lookup |
| DELL | Service Tag | Warranty API, 100 per request |
| Lenovo | Serial number | Batch tool, 1,000 per query |
| IBM | Serial number | Through Lenovo |
| HP | Serial number | Warranty API, own fleet only |
| Acer | Serial number or SNID | None published |
| ASUS | Serial number | None published |
| Fujitsu | Serial number and model | None published |
How to check a Dell warranty
Dell identifies each machine by a seven-character Service Tag, which is also what the machine reports as its serial number. Its warranty API is open to third-party tools querying on your behalf, which is what makes automatic synchronization possible:
- For one machine, open Dell's support services page and enter the Service Tag.
- For a list, query the TechDirect warranty API, which accepts up to 100 Service Tags per request.
- For coverage that stays current, connect that API to your inventory.
Where to find the Service Tag, the bulk options and the integration setup are covered in full in the Dell warranty check guide. That guide also gives the command that reads the Service Tag off a running machine, which is how the list gets built in the first place.
How to check a Lenovo or IBM warranty
Lenovo uses the serial number, and IBM-branded hardware resolves through the same service because the two share a warranty backend. Lenovo is the most generous of the major manufacturers here, publishing a bulk tool that anyone can use without a partner agreement:
- For one machine, open Lenovo's warranty lookup and enter the serial number.
- For a list, use the batch query, which takes up to 1,000 serial numbers and needs the machine type alongside each one.
- For coverage that stays current, request warranty API access through your Lenovo account manager or reseller.
All three routes are covered in the Lenovo warranty check guide, including the template the batch tool expects and the two fields Lenovo asks for on the API request. What changes for IBM-branded hardware is covered in the IBM warranty lookup guide.
How to check an HP warranty
HP publishes a warranty API as well, with a restriction that decides how you can use it. HP states it is intended for businesses checking their own fleet of HP devices and explicitly excludes IT service companies and third-party software vendors querying warranties on behalf of their customers:
- For one machine, use HP's free product warranty check and enter the serial number.
- For your own fleet, ask your HP account manager to sponsor an API access request.
- Expect a review by HP's customer advocacy group before access is granted.
The practical consequence is worth stating plainly: you can automate HP warranty checks for hardware your company owns, and no asset management tool can do it on your behalf. If HP is a meaningful share of your fleet, that request is worth starting early.
How to check an Acer, ASUS or Fujitsu warranty
These three share a pattern, which is a public lookup page, one machine at a time, and no bulk path published. Acer asks for a serial number or SNID, the identifier printed alongside it on the label, and ASUS runs a warranty status inquiry that takes the serial number.
Fujitsu adds regional fragmentation on top. Its warranty information sits under regional support sites rather than one global tool, so the right page depends on where the hardware was sold. For all three the answer is the same: capture the identifier at intake, look the coverage up once, and record the date rather than planning to look it up again later.
Hardware with no manufacturer lookup
The last group has no lookup at all. Custom-built desktops, network switches and access points from manufacturers that never built a customer-facing tool, peripherals, and anything inherited through an acquisition all fall here.
For these the warranty date exists only in your own records: the purchase order, the invoice, or the reseller's contract. That is worth saying plainly rather than treating it as a gap, because a date typed in from an invoice is exactly as useful downstream as one pulled from an API.
Centralizing warranty tracking
Read the table and the sections above it together and the pattern is clear. The same fleet produces warranty dates through several completely different routes, and the difference between them matters enormously while you are collecting the data and not at all afterward.
That is the argument for putting the date on the asset itself rather than leaving it wherever it came from. Once every machine in the IT inventory carries an expiration date in the same field, nothing downstream needs to know whether that date arrived through an API, a bulk export or an invoice. It is also where a collection of lookups becomes Warranty Management as a practice, feeding renewal decisions and the hardware budget rather than only answering questions after something has already broken.
Alerts before expiration
A date sitting in a field still requires someone to look at it. The step that turns warranty data into something operational is deciding what should interrupt a person, and when.
Most teams set one alert, for coverage about to expire, and stop. That covers the obvious failure and misses the more common one.
What to alert on
Expiring coverage is the alert everyone builds, and ninety days is a more useful horizon than thirty. Three months leaves room to compare an extension against a replacement, get a quote, and put it in a budget cycle, while thirty days leaves room to react.
The alert almost nobody builds is for missing data. An asset with no expiration date recorded looks identical to a covered one on most reports, which means the gaps in your coverage data are invisible precisely because they are gaps. Surfacing assets with an empty warranty field catches the machines that entered the inventory without paperwork.
Who the alert goes to
An alert without a named recipient becomes noise, and noise gets filtered. Routing matters more than frequency: expiring coverage on end-user laptops usually belongs to whoever runs the refresh cycle, while the same alert on a server belongs to whoever would be woken up if it failed.
The same applies to the missing-data alert, which belongs to whoever onboards hardware rather than to the person who reports on it. Sending both to a shared mailbox is the most common way a working alert stops working.
Warranty checks across vendors with InvGate Asset Management

InvGate Asset Management is an IT Asset Management (ITAM) platform that discovers hardware, software, cloud assets, and any other IT resources into a single inventory, with no-code automation, custom dashboards, and cloud and on-premises deployment. It covers the asset lifecycle from discovery through disposal, and warranty data lives as an attribute of the assets themselves.
That last point is what makes it relevant to a multi-vendor fleet. Warranty Expiration and Acquisition Date are fields on the asset, so a Dell that synced automatically, an Acer someone looked up by hand, and a switch whose date came off a purchase order all end up in the same place, described the same way.
Everything after that treats them identically. The three sections below cover getting the dates in, alerting on them, and reporting across the whole fleet including the parts that have no dates yet.
Bring the vendor data in
For Dell and Lenovo, including IBM-branded hardware, warranty APIs populate the acquisition and expiration dates automatically once the integration is configured under Settings > Integrations > Warranty APIs. Discovery already records each machine's serial number, so those manufacturers need no list assembled and no lookups run.
Everything else arrives by import. Coverage dates load in bulk during a CSV import or get entered on individual assets, which is the path for the manufacturers that publish a lookup page and nothing more, and for the hardware with no manufacturer source at all.
Set the alerts up
An automation for upcoming warranty expiration ships ready to use and sends reminders as devices approach the end of their coverage. Custom automations built under Settings > CIs > Automations cover any other condition you want watched, emailing a named team with the asset details and a link to its profile.
Smart Tags handle grouping rather than notification, applying themselves to any asset matching a rule you define, such as coverage ending inside the next ninety days across every manufacturer at once. Health rules evaluate warranty expiration alongside criteria like antivirus status, so a machine drifting out of coverage appears in the same view as everything else needing attention.
See the whole fleet, including the gaps
Dashboards break the fleet down by expiration quarter, by location, and by asset type. That is what makes a multi-vendor picture legible in one view rather than four exports opened side by side.
The missing-data problem has its own answer. An Empty filter operator works across every field, so a view of assets with no warranty date recorded takes one filter, and that view can drive an alert, a Smart Tag or a scheduled report like any other.
To sum up
A warranty check stops being a lookup task the moment you have more machines than patience. What replaces it is not a better lookup but a different arrangement: every asset carrying its own expiration date, collected through whichever route its manufacturer allows.
Dell and Lenovo can feed that automatically, HP can if you request access for your own fleet, and the rest arrives by import. Once the dates are in one place the manufacturer stops mattering, which is the whole point. You can set that up against your own fleet with a 30-day free trial, or talk to Sales about what it looks like at your device count.
Frequently Asked Questions
These are the questions that come up most often when a team starts tracking warranties across more than one manufacturer. Each answer assumes business hardware bought through normal procurement rather than consumer purchases.
How do I check a hardware warranty?
Every major manufacturer publishes a lookup page that takes an identifier printed on the device, usually the serial number. Dell asks for a Service Tag, Lenovo and HP for a serial number, and Acer accepts either a serial number or an SNID.
Can I check warranties for multiple vendors at once?
Not on the manufacturers' own sites, since each one only knows about its own hardware. Checking a mixed fleet in one place means collecting the dates into an inventory, automatically where the manufacturer allows it and by import where it does not.
Why can't my asset management tool check HP warranties automatically?
Because HP restricts its warranty interface to businesses checking their own devices and excludes third-party software vendors from querying on a customer's behalf. You can request access for your own fleet through an HP account manager, but the tool cannot request it for you.
What is warranty expiration tracking?
It is keeping a current expiration date on every asset and acting on it before coverage runs out, rather than looking dates up when something breaks. In practice it means one field per asset, an alert with a useful horizon, and a named owner for the alert.
Why does my warranty start before I bought the machine?
Because manufacturers anchor coverage to the date the unit shipped from them rather than the date you were invoiced. On hardware bought through a distributor or reseller those dates can be weeks or months apart, and correcting it means going back to the manufacturer with the purchase documentation.