Track HVAC Equipment Serial Numbers from Supplier Invoices

A supplier invoice carries the model number, the serial number, and the dated proof of purchase together — the same three things every major HVAC manufacturer wants to see at warranty registration. Extract them once into a per-unit register and each PDF becomes the documentary record you actually need: warranty evidence on day one, service history three years later, and HST documentation whenever CRA asks.

That combination is why HVAC equipment serial number tracking from supplier invoices is best treated as a register problem, not a lookup problem. The data you need is already on the bills sitting in your inbox or your shared drive; what's missing is a durable per-unit row that survives accounting close, the next service callback, and the warranty window.

The window is real. According to Trane's 60-day warranty registration window, residential HVAC products must be registered within 60 days of installation to qualify for the Registered Limited Warranty, which typically lasts 10 years; without registration, the product falls back to a 5-year Base Limited Warranty, and Trane points installers and owners to find the serial number on the unit itself or on the supplier invoice. Most major brands operate a similar registered-versus-base distinction with the registration window measured from install date, which is why a dated supplier bill matters: it's what proves the install-window timing later, regardless of whose portal you're submitting to.

The contractor-side problem is different from the homeowner-side problem the rest of the search results address. A small-to-mid HVAC or mechanical-contracting shop is not looking up one serial on one unit to register one warranty. The bills come in steadily from Wolseley, Master, EMCO, and Ferguson Canada and direct from brand suppliers like Lennox, Trane, Carrier, Goodman, and Mitsubishi. Each bill carries equipment for one or several active jobs. Each serialized unit on each bill needs a register row, a job link, an install date, a warranty status, and an audit-friendly trail back to the source PDF and page.

The rest of this guide walks the workflow end to end: the field schema your register needs, the multi-serial expansion rule that breaks naive line-item exports, the extraction step that populates the schema from a folder of PDFs, the job-and-site separation the register has to carry, the HST and input-tax-credit evidence that comes along for free, and the warranty payoff at the other end.

---

The Register Field Schema, Layer by Layer

The register has two layers. Invoice-level fields belong to the supplier bill itself and repeat across every row that came from that bill. Equipment-level fields belong to a single serialized unit and vary row by row. Keeping the layers distinct is what lets one supplier invoice for five rooftop units become five register rows, each carrying its own serial while still pointing back to the same dated, taxed, audit-anchored bill.

Field	What it carries
Invoice-level — repeats per row from the same bill
Invoice number	Supplier's invoice or document number, exactly as printed
Invoice date	The bill's issue date — your warranty-window anchor when no install date is recorded yet
Supplier	Distributor or brand-direct supplier, recorded as the bill names them
Supplier GST/HST number	The supplier's nine-digit registration number where the bill prints it
PO / work order / job reference	Whichever of these the bill carries — store all that appear
Customer or site reference	Your internal identifier for the customer or site the equipment is going to
Delivery address	Physical ship-to on the bill, even when it differs from the AP customer's address
HST amount	Tax recorded on the bill; allocated proportionally per unit on multi-serial lines (covered in the next section)
Source file	File name or stable identifier of the original supplier PDF
Source page	Page within that PDF where the line and serial are recorded
Equipment-level — one row per serialized unit
Equipment type	Furnace, condenser, air handler, mini-split head, RTU, boiler, heat pump, and so on
Brand / manufacturer	Lennox, Trane, Carrier, Goodman, Mitsubishi, and the rest
Model number	Manufacturer model exactly as printed
Serial number	One serial per row — never a comma-joined list
Quantity	Almost always 1 once the line is expanded; carry it explicitly so a totals reconciliation against the original bill still works
Unit cost	Per-unit cost; line totals split proportionally when the supplier billed at the line level
Install date	Populated when the unit is commissioned; left blank at extract time when not yet known
Warranty registration status	Unregistered, registered, or claim-in-progress, updated as the unit moves through its lifecycle

The source file and source page columns deserve their own note. They aren't business data about the equipment; they're the audit anchor that turns the register from a flat extract into a defensible record. A CRA reviewer asking for the bill behind a claimed input tax credit, or a brand portal asking for proof of purchase against a serial, gets one cell that names the PDF and the page. That round-trip is what separates a register from a spreadsheet of typed-in facts.

Treat install date and invoice date as different things and keep both. The invoice date is when the supplier billed you — a hard timestamp that anchors the warranty window only when no install date has been recorded yet. The install date is when the technician commissioned the unit on site, which is the date most manufacturers actually want for registration. The practical rule: leave install date blank at extract time, fill it in from the work order or commissioning report when the unit is energized, and use the invoice date as the warranty-window anchor only as a last resort when the install date is genuinely lost.

Supplier names move around. Distributors get acquired, regional brands get consolidated, and the name on a 2023 invoice may not be the name on the same supplier's 2026 invoice. Store the supplier name as it appeared on the original bill rather than retrofitting current branding onto historical rows. A register that quietly rewrites history loses the audit trail it exists to preserve.

One Row Per Serialized Unit: Handling Multi-Serial Lines

The rule is simple to state and easy to break: one row per serialized unit. A supplier line that reads "5 × Lennox EL296V-070XV48C-04" with five distinct serial numbers expands into five register rows. Each of those rows carries the same invoice number, invoice date, supplier, PO, site, and proportionally-allocated HST. Each carries the same model and equipment type. Each carries one — and only one — serial number, with the line cost split across the five.

Concretely, picture the input line as it shows up on a Wolseley or Master bill:

Line 4: 5 × Lennox EL296V-070XV48C-04 furnace, $2,400.00 each, $12,000.00 line total. Serial numbers: 5824H12345, 5824H12346, 5824H12347, 5824H12348, 5824H12349.

That single line becomes five rows in the register. Invoice number, invoice date, supplier, PO, site, and delivery address are identical across all five — they came from the same bill. Equipment type, brand, and model are identical because the line itself was a single SKU. What differs row to row is the serial: 5824H12345 on row one, 5824H12346 on row two, and so on. Quantity on each row is 1, unit cost is $2,400.00 on each row, and the line's HST is divided proportionally across the five units so the register's HST column sums back to the original line tax.

Proportional HST allocation deserves a moment. When the bill records a single tax amount against the five-unit line — say $1,560.00 of HST on a $12,000.00 line in Ontario — divide it evenly per unit ($312.00 each in this case, since the line splits cleanly). When the math doesn't split cleanly — for example, $1,557.65 of HST across five units — round to the nearest cent and absorb the remainder on the last row so the per-row column still sums back to the original line tax exactly. This is a register convention, not an accounting restatement: AP entry can keep the line-level tax total against the original bill. The register is a parallel record built for warranty and service questions, not a replacement for the AP system.

Where the serial actually lives on the supplier paperwork is where naive exports go wrong. Some distributors print the five serials directly under the line description in the body of the invoice. Others attach a separate serial sheet — sometimes inside the same PDF, sometimes as a delivery slip referenced on the invoice header — and leave the line itself describing only the SKU and the count. The register's source-file and source-page columns should point to whichever document carries each serial. If the serials live on page 3 of a delivery-slip PDF, that's the source reference for those rows, even when the invoice itself is page 1 of a different file. The audit trail follows the data.

Sometimes the serials simply aren't on the bill at all. A supplier pulling stock from a contractor's own warehouse will often invoice the SKU and the count without recording serials, leaving serial capture to the field tech at install. When that's the case, write the missing-serial state into the register explicitly: a flag column, a note, or a sentinel value that downstream queries can pick up. A blank serial cell is a signal that the row is incomplete and that the unit needs serial capture before any warranty work can be done — which is more useful than a register that quietly looks finished.

---

Populating the Register from Supplier PDFs

The workflow is short. Collect supplier PDFs in a single folder — Wolseley, Master, EMCO, Ferguson Canada, brand-direct, mixed formats, mixed scan quality. Run a structured extraction that produces the schema directly, with one row per serialized unit and source-file and source-page columns built in. Review the output for missing serials, missing install dates, and any rows the extraction flagged as ambiguous, then save the result as the register.

The middle step is where the work happens. Generic line-item exporters break on the multi-serial expansion rule from the previous section, and manual keying is exactly what the contractor is trying to escape. What's needed is a step that reads the bill, applies the schema, expands the multi-serial lines, and writes the source-file and source-page references into every row. Invoice Data Extraction handles this layer: it provides automated extraction for HVAC supplier invoices, processes batches of supplier PDFs and image scans together, takes a natural-language prompt that names the fields and the multi-serial rule, and returns the spreadsheet — XLSX, CSV, or JSON — with the source-file and source-page columns native to every row.

Below is a worked prompt that produces the register schema from the previous section. Paste it in as a starting point and adjust the field list to whatever your accounting and service systems actually need.

I'm building an HVAC equipment register from Canadian supplier invoices.
Extract one row per serialized unit. When a single line covers multiple
units with distinct serial numbers, split into one row per serial and
repeat the invoice-level fields verbatim on every row.

Extract these invoice-level fields (repeat on every row from the same bill):
- Invoice Number
- Invoice Date (YYYY-MM-DD)
- Supplier (use the supplier name as printed on the bill)
- Supplier GST/HST Number (leave blank if not on the bill)
- PO / Work Order / Job Reference (capture all that appear)
- Customer or Site Reference
- Delivery Address
- HST Amount (allocated proportionally per unit on multi-serial lines;
  the per-row HST values must sum back to the original line tax —
  absorb any rounding remainder on the last row of the line)
- Source File
- Source Page

Extract these equipment-level fields (one per serialized unit):
- Equipment Type (furnace, condenser, air handler, heat pump, RTU,
  mini-split, boiler, etc. — classify from line description)
- Brand / Manufacturer
- Model Number (exactly as printed)
- Serial Number (one per row — never a comma-joined list)
- Quantity (set to 1 after expansion)
- Unit Cost (line total divided by unit count)
- Install Date (leave blank — this is back-filled at commissioning)
- Warranty Registration Status (set to "Unregistered" by default)

Multi-serial rule:
Some invoices print serials directly under the line description.
Others reference a separate serial sheet or delivery slip — treat
serials on a referenced sheet as serials for that line, and set
the Source Page to the page where the serial actually appears,
even when that's a different page from the invoice header.

Add a Flag column. Set it to "MISSING_SERIAL" for any row where
the line records a serialized HVAC unit but no serial number is
present in the source documents. Set it to "MISSING_INSTALL_DATE"
when install date is empty (this will normally be true at extract
time and is back-filled later). Both flags can apply on the same row.

Skip non-HVAC consumables (filters, sealant, fasteners, copper)
and non-line content (email cover sheets, summary pages, payment
remittance stubs).

Output format: one row per serialized unit, columns in the order
listed above. Date as YYYY-MM-DD. Unit cost and HST as numbers
with two decimal places.

The line-item layer the prompt sits on top of is its own surface, and the upstream sibling guide on how to extract HVAC supplier invoice line items into Excel walks the line-item part end to end — useful when the supplier's billing format is unfamiliar or when the AP team wants the raw line export alongside the per-serial register. The broader workflow, including subcontractor bills and materials beyond HVAC equipment, is covered in the guide on invoice data extraction across the construction industry; HVAC's particular wrinkle, and the reason this article exists as its own piece, is the per-serial register layer that sits downstream of the line-item extract.

The review step is short but worth doing. Sort the output by the Flag column and look first at the MISSING_SERIAL rows — those are the units that won't be registrable until the field tech reports the serials back. Spot-check a handful of rows by clicking through to the source file and page and confirming the serial, the model, and the supplier match what's actually on the PDF. Watch for model numbers that don't match the brand's catalog naming, which usually means the extraction misread a hand-written notation or an OCR-marginal scan; those rows are easier to fix in the register than to discover later when a warranty submission gets rejected.

---

Job, Site, and PO References: Where the Register Hands Off to Job Costing

Three reference dimensions show up on supplier bills, and the register has to keep them distinct. The supplier's PO or work-order reference is what the supplier shipped against — their internal record of what was promised, billed, and packed. The contractor's job or project reference is which active job inside your shop consumed the equipment. The customer or site reference is where the unit will physically be installed. On a clean bill all three appear; on a real bill, only one shows up consistently, a project number is buried inside a line description, and the delivery address is a job-site trailer that doesn't match the AP customer's billing address.

The rule for the register: store all three when they appear, even when they look redundant on a particular invoice. A register that holds the PO without the site can't answer "which units went to that building when the rooftop coil failed two winters later"; a register that holds the site without the PO can't tie back to the supplier's internal record when a warranty dispute needs the supplier's shipment evidence. The PO reference also gives you a clean handoff to the adjacent reconciliation workflow — if you also match HVAC supplier invoices to purchase orders and delivery receipts, the same PO field in the register is the join key, and you don't have to retype the reference into a second system.

A single supplier bill regularly carries equipment for two or three active jobs. A Wolseley delivery for a downtown retrofit can include a rooftop unit for one project, a furnace and coil pair for another, and a couple of mini-split heads for a third — all on one PO, one tax total, one freight charge. The register has to allocate each line, and each serialized unit on each line, to the correct job. That per-unit job allocation is what the register stores. The broader workflow that splits line-level tax, freight, and shared charges across projects belongs in the dedicated guide on how to split a supplier invoice across multiple construction jobs; the register pulls the per-unit job reference forward and lets the allocation workflow handle the rest.

PO matching itself is adjacent context, not the register's job. The register stores the PO reference as a field so that downstream queries — warranty claims, service history, and supplier disputes — can find the right shipment record. It does not reproduce three-way matching, partial-receipt reconciliation, or PO close-out. Treating those as separate workflows keeps the register focused on what it's good at.

The honest boundary at the end of this section is worth saying out loud. The register is not a job-costing system. It carries enough job and site context to answer warranty, service, and per-unit margin questions, and to feed cleanly into the systems that do own those things. Labour, overhead, change orders, payroll burden, and final billing still live in your job-costing software. The register is the equipment layer that sits underneath it.

HST and Input Tax Credit Evidence as a Register Side Benefit

The same supplier PDFs that populate the equipment register are the documentary evidence CRA expects to see behind a claimed input tax credit. The HST amount, the supplier's GST/HST registration number where the bill prints it, and the dated invoice are already in the register. The source-file and source-page columns make the underlying bill retrievable on demand, which is the actual ITC documentation requirement at audit time.

That changes what an audit response looks like. When CRA asks for the supporting bill behind a claimed credit, the register row points directly to the PDF and the page; you open the file, scroll to the page, and the evidence is on screen. There's no hunt through filing cabinets, no archaeology in a shared drive, no reconstructing what the bookkeeper did six quarters ago. The same data structure that supports warranty work supports the tax evidence trail without extra effort.

A caveat on the GST/HST registration number specifically. Not every supplier prints the number cleanly — it's sometimes squeezed into a footer, sometimes missing entirely on legacy formats, sometimes truncated by a poor scan. The register field captures whatever is on the page. Verifying that the number you captured is genuinely registered against the supplier's legal name is a separate step that's worth doing for any new supplier before you claim the credit, but that verification belongs in its own workflow rather than this article.

For the HST math itself — what counts as taxable, how to handle zero-rated and exempt supplies, and how to reconcile line-level tax against invoice totals — the dedicated guide on how to calculate GST/HST on a Canadian supplier invoice covers the detail. The register's role is narrower: capture what the bill says and keep it tied to the source page.

---

What the Register Pays Off: Warranty Registration, Claims, and Service Callbacks

Warranty registration is the first place the register earns its keep. Within the brand's registration window — Trane's 60 days from install date is the anchor case, and most major manufacturers run their own window measured similarly from install — the register surfaces every unregistered serialized unit with model, serial, install date, and supplier-invoice evidence already sitting in one row. Submitting through the brand portal becomes a copy-paste exercise across whatever fields the portal requires, instead of a forensic exercise that hunts through PDFs, work orders, and AP records to reconstruct the same five facts. A Friday-afternoon batch of registrations covering everything commissioned that week is plausible; without the register, that batch is a half-day project that often gets deferred until something is past its window.

Claim evidence works the same way once a unit fails. Distributors and brand portals typically ask for the serialized unit, the model, the install date, the dated proof of purchase, and sometimes the contractor's licensing or installer ID. The register holds the first four directly and points at the supplier PDF for the fifth piece of evidence (the dated proof itself). The contractor-side credential — installer number, licensing, certifications — sits with the company, not with any individual invoice, and the register doesn't try to absorb it. What the register does provide is HVAC contractor warranty claim invoice evidence at exactly the depth a brand portal asks for, organized so it can be pulled in seconds rather than reconstructed under deadline pressure.

Service callbacks are the third payoff and the most frequent. When a unit fails three years after install, the field tech wants to know what was installed, when, against which job, by which supplier, and what its current warranty status is — five questions answered by one register lookup keyed on the serial number. Without the register, those five answers come from five different places: the AP system for the supplier and date, the job folder for the install date, the work order for the job, a phone call to the supplier for the warranty status, and the original PDF for whatever still hasn't lined up. The register collapses that into a single row.

The boundary at the end of all of this is worth stating plainly. The register is evidence and a register; it is not a warranty submission, and it does not adjudicate claims. Manufacturer portals still require the contractor or owner to submit registration within the brand's window, and warranty validity still depends on manufacturer terms, dealer rules, and install-condition compliance. Extraction builds the evidence trail; everything downstream of that trail is still a human and brand-portal workflow, and selling it as anything more would set up a contractor for a rejected claim later.