A Canadian supplier invoice charging GST or HST is in front of you, and you are about to release payment and book the Input Tax Credit (ITC). Before you do, three things need to be true on the Canada Revenue Agency's free Confirming a GST/HST account number registry: the supplier's registration was active at the invoice's supply date, the legal name registered to the BN15 matches the supplier name on the invoice, and the BN15 itself is structurally valid (the nine-digit business number, the RT program identifier for GST/HST, and the four-digit account suffix, for example 123456789 RT 0001).
Skipping the check has a documented audit price tag. In Comtronic Computer Inc. v The Queen, 2010 TCC 55, the Tax Court of Canada upheld CRA's denial of roughly $500,000 in input tax credits because the registrant did not take reasonable measures to verify the supplier's GST/HST registration. The duty to verify supplier GST/HST registration before paying an invoice is not a best practice borrowed from elsewhere; it is the standard the Tax Court applies when an ITC claim is examined.
If you arrived here looking for CRA's Tier 1, Tier 2, and Tier 3 rules for what fields a tax invoice itself must carry, that material lives in a sibling article. The work below assumes those fields are present and addresses the question that follows: is the registration the invoice cites real, current, and matching what the registry has on file.
How CRA's Confirming a GST/HST Account Number Registry Actually Works
The canonical reference for everything that follows is the Canada Revenue Agency's Confirming a GST/HST account number tool — a free public web tool that returns a yes-or-no answer for one BN15 at a time. The whole verification workflow runs against it. Knowing how it accepts input and what it returns matters more than it looks: each of the three checks corresponds to one input field, and a clean understanding of the response saves the AP team from misreading a successful query as a green light when it isn't.
The registry asks for three inputs. The GST/HST account number is the supplier's BN15 — or, if the AP team has only the BN9 (the nine-digit business number CRA assigns to the legal entity), the registry will accept it and look for a corresponding RT account. The business name is the legal name the registrant has on file with CRA. The transaction date is the supply date, the date the goods were delivered or the services were performed, not the date the AP clerk runs the check. Supply the wrong value in any of the three fields and you get the wrong answer to the check that field controls.
The response is binary on a per-field basis. The registry confirms either that the account is registered for GST/HST and was registered on the date supplied with the business name supplied, or that one or more of those conditions failed. When a query fails, the tool indicates which condition failed without disclosing the registrant's specific details. CRA does not return the registered legal name, the effective date, or any other identifying field to a third-party query — the third party is testing a hypothesis the AP team brought with it, not extracting registry data the team didn't already have.
For every successful query, capture the documentary record. A print-out, a screenshot, or a saved confirmation page that records the date of the check, the BN15 queried, the business name queried, the transaction date queried, and the registry's response is the file the AP team can put in front of an auditor. A query you ran but didn't save defends nothing; the documentation is part of the work, not optional administrative residue.
A supplier that holds multiple GST/HST accounts under the same BN9 (for example RT0001 for the head office and RT0002 for a separate division that issues its own invoices) needs each account verified separately, with the BN15 that names that specific account.
Check 1 — Was the Supplier Registered on the Invoice's Supply Date?
The most common way an AP team gets the supply-date check wrong is by treating "the supplier is registered" as a present-tense fact. It isn't, for ITC purposes. The registry tells you whether the supplier was registered on the date you supply, and if you supply today's date instead of the invoice's supply date, the answer you get back can hide a denial.
Here is the failure mode in plain form. A supplier who was unregistered at the time of supply — who charged GST or HST on the invoice anyway, perhaps in error, perhaps in anticipation of a registration that hadn't yet taken effect — will return a "registered" answer if the AP clerk runs the query against today's date and the supplier registered in the meantime. The invoice still cannot support an ITC. The registration's effective date post-dates the supply, the GST/HST charged on that supply was not properly collected by a registrant, and CRA will deny the credit at audit even though every other field on the invoice is correct.
The registry's mechanics make this a date comparison rather than a status check. The registry returns "registered" only with respect to the transaction date the user supplies. Enter the invoice's supply date and you are asking whether the registrant was active on that date. Enter today's date and you are asking whether the registrant is active today. Same BN15, two different questions, two potentially different answers.
The practitioner action is straightforward: enter the invoice's supply date as the transaction date in the registry, not the date you ran the check. Supply date is generally the date the goods were delivered or the services were performed. On most supplier invoices this is the invoice date itself. Construction holdback billing, progress billing, and any arrangement where the supply was performed in a period earlier than the billing period are the common exceptions where supply date and invoice date diverge — read the invoice rather than assuming.
When the check fails, the registry response indicates the account was not registered on the date supplied. Suppliers who hit this finding sometimes protest that they are registered now, which is true and also irrelevant. The ITC question is whether the registration was effective on the supply date, and a present-tense registration does not retroactively cover a supply that pre-dates it.
The inverse case is rarer but real. A supplier who was registered at the time of supply but whose registration has since been cancelled — because the supplier ceased operations, fell below the small-supplier threshold and deregistered, or had its registration revoked — will return a cancellation answer if the AP team queries against today's date. For an aged invoice (one being processed late, surfaced during a year-end review, or pulled out of a backlog), that cancellation is not the right answer to the ITC question. Always run the check against the supply date, regardless of whether the invoice is a week old or a year old.
Check 2 — Does the Legal Name on the Registry Match the Supplier Name on the Invoice?
The CRA registry returns a confirmation only when the business name supplied to the query matches the legal name registered to the BN15. If the invoice carries an operating name that differs from the legal name on file with CRA, the query fails on the name field — even when the BN15 itself is structurally valid and the registration was active on the supply date. The first time an AP team encounters this, the instinct is to treat it as a registry glitch. It isn't.
The denial pattern at audit is real. The Canadian Bar Association has documented cases where CRA disallows ITCs precisely because the registrant's invoice does not carry the supplier's correct name — either the legal name on file or a properly documented alternative. The question for the AP team is which side of that line a particular mismatch sits on.
A legal name is the name registered to the corporation, partnership, sole proprietor, or other legal entity that holds the BN15. An operating name (also called a trade name or business name) is the name the entity trades under in the market. The two can legitimately differ. A numbered company can hold the BN15 and trade under a brand the public would recognise; a sole proprietor with the legal name "Smith, John" can issue invoices headed "Smith Mechanical" without the world ending. The audit-defensibility question is not whether the names match — it is whether the relationship between the operating name on the invoice and the legal name on the registry is documented in the supplier file.
Acceptable documentation falls into a few well-worn categories. A corporate search returning the legal entity associated with the operating name. Articles of incorporation that name both the legal name and the operating name. A provincial or federal business-name registration tying the operating name to the legal entity that holds the BN15. Supplier-side documentation such as letterhead that shows both names, a certificate of registration, or an explicit statement on the invoice that the operating name is operated by the named legal entity. Any of these, retained in the supplier file alongside a registry confirmation run against the legal name, defends the ITC. The pattern an auditor wants to see is a connecting document — not just an assertion that the supplier said the names belong together.
The line between a documented operating-name relationship and a real red flag is mostly about willingness to substantiate. A supplier who provides the corporate search or business-name registration when asked is the documented case: the AP team holds the documentation, re-runs the registry query against the legal name, gets a clean confirmation, and the ITC is defensible. A supplier who refuses to substantiate, who provides documentation that doesn't connect the names, or whose name family is inconsistent with the BN15 holder (e.g. an operating name in one industry attached to a legal entity registered in an unrelated one) is the red-flag case and should be treated as a failed Check 2 — with the remediation path covered later in this article.
A grounding note before moving on. Slight name differences are common at the small-supplier end of the market. A sole proprietor's legal name on CRA's file may be inverted ("Smith, John" rather than "John Smith"), abbreviated, or rendered with a middle initial the invoice doesn't carry; an incorporated trade may operate under a name that drops "Inc." or "Ltd." in everyday use. None of these is a refusal to substantiate. The verification job is to confirm the documented relationship between what is on the invoice and what is on the registry — not to require that the legal name appear verbatim on every supplier document.
Check 3 — Is the BN15 Itself Structurally Valid?
The BN15 is not an opaque fifteen-character string. Each segment carries a meaning the AP team can read directly off the invoice, and reading it is a five-second pre-screen that catches a meaningful share of failures before the registry query is ever run.
A BN15 has three parts. The first nine characters are the BN9 — the business number CRA assigns to the legal entity itself. The BN9 is unique to the registrant; every program account the entity holds with CRA is built on the same nine digits. The next two characters are the program identifier: RC for corporate income tax, RP for payroll, RT for GST/HST, RM for import-export, among others. The last four characters are the account suffix, which distinguishes multiple accounts the registrant holds within the same program — typically 0001 for the first GST/HST account, 0002 for a second account opened to handle a separate division or operation, and so on.
The canonical format on a Canadian invoice is the segmented form: 123456789 RT 0001. The same number sometimes appears run together as 123456789RT0001, which is fine. Only RT applies for GST/HST verification. A number ending in RC, RP, or RM identifies a different program account altogether — a payroll account, a corporate tax account, an import-export account — and does not register the entity for GST/HST even if the BN9 itself belongs to a real CRA registrant. The presence of any program identifier other than RT on a tax invoice is itself a red flag worth pausing on.
A handful of malformation patterns recur, and each one tends to point to a specific underlying problem. A number with no program identifier — a bare nine-digit BN9, or a thirteen-character string that looks like a BN9 plus an account suffix without the two-letter program code in between — is incomplete and cannot be verified for GST/HST. A number with a program identifier other than RT is a different program account, not a GST/HST registration, regardless of how the supplier described it on the invoice. A number with a non-numeric character anywhere in the BN9 segment is malformed and is unlikely to be a real CRA-issued business number; the BN9 is always nine digits. A number with fewer than four digits in the account suffix is incomplete — registrants do not have RT1 or RT01 accounts; the suffix is always four characters.
The pre-screen this enables is fast. Before running the supplier's BN15 against the registry, look at it for a moment: nine digits, then RT, then four digits. If any segment is wrong, the invoice itself is non-compliant under CRA's documentation requirements and should be returned to the supplier for correction rather than routed to the registry. The registry will not save you from a malformed number; it will simply return a structurally-invalid response and you will have spent a query for nothing.
One connection back to the prior checks. The BN9 is the legal-entity core, but the legal name and the effective registration date attach to the BN15 — to the specific account, not to the BN9 alone. A supplier holding multiple GST/HST accounts under one BN9 (RT0001 and RT0002) is one legal entity with two registrations, and each registration carries its own status and history in the registry. Verify each BN15 separately when the supplier issues invoices from more than one of them.
The Audit Stakes — Comtronic, Section 3 of the ITC Information Regulations, and What "Reasonable Measures" Means
The verification work in the prior sections is not advice borrowed from elsewhere. It rests on a specific regulation that creates a documentation duty and a specific Tax Court decision that defines what discharging that duty looks like. Adding a verification step to an AP procedure is easier to defend internally when the legal anchor is on the page, so here it is.
The regulation comes first. Section 3 of Canada's Input Tax Credit Information (GST/HST) Regulations requires documentation supporting an ITC claim to include the supplier's name and the GST/HST registration number assigned under section 241 of the Excise Tax Act when the total consideration paid or payable is $100 or more. That is the source of the duty to verify. A supplier name and a BN15 on an invoice, by themselves, do not meet the documentation requirement; the registrant claiming the credit needs reason to believe the registration number is real and assigned to that supplier. Without that, the invoice is not supportable as ITC documentation.
The case law follows. In Comtronic Computer Inc. v The Queen, 2010 TCC 55, the Tax Court of Canada upheld CRA's denial of approximately $500,000 in input tax credits on the ground that the registrant did not take reasonable measures to verify the supplier's GST/HST registration. The holding is the part to internalise: good-faith reliance on the supplier's claim of registration is not enough. A registrant who relied on what was printed on the invoice, without checking it against CRA's registry, did not discharge the documentation duty — and lost the credits as a result.
What does "reasonable measures" mean in CRA practice and the post-Comtronic case law? At a minimum, querying the supplier's BN15 against the CRA registry on or near the supply date and retaining the documentary record of the query — the print-out, screenshot, or saved confirmation page covered above. That single step demonstrates that the registrant tested the registration rather than assuming it. For higher-risk supplier categories (new suppliers in the master file, suppliers who issue under operating names rather than legal names, suppliers in sectors flagged for ITC fraud, suppliers whose pricing or volumes look anomalous against peer benchmarks) additional measures are appropriate: independent confirmation of the supplier's existence, on-site verification, or supplementary correspondence that confirms the registration directly with the supplier's bookkeeping function.
The duty falls on the registrant claiming the ITC, not on the supplier issuing the invoice. The supplier may have issued the invoice in good faith with what it believed was a valid registration; that is the supplier's question to answer to its own bookkeeper. The AP team claiming the credit is on the hook for confirming the registration before relying on it. A failure on the supplier's side does not transfer the cost; Comtronic loses the credits whether the upstream supplier acted in good faith or not.
Verifying Registration Across a Whole Supplier Master File
Single-invoice verification solves the per-supply ITC question. The supplier-master question is different in shape: an active list of suppliers carries hundreds or thousands of BN15s, and any of those registrations may have been cancelled since the supplier was onboarded. The CRA's Confirming a GST/HST account number web tool is per-record by design. Verifying a list of 500 suppliers through it one record at a time is not a sustainable AP control, and a control that only runs at first invoice misses the cancellations and corporate-restructuring events that happen to live suppliers between then and now.
There are three honest options, and the framing worth holding through them is that all three query the same underlying CRA data. The choice is operational fit, not authority.
The first option is a quarterly batch run via browser automation or VBA against the same web tool. An internal developer or a competent power user scripts the registry queries against the supplier list, captures the responses to a worksheet, and the AP team reviews the exceptions. Licensing cost is zero; the cost is the team's time and the brittleness of any script that depends on a public web form's HTML staying stable. This works cleanly for supplier lists in the low hundreds and starts to feel ragged past a few thousand records or when the web tool changes shape between sweeps.
The second option is the CRA's GST/HST registry API access path. CRA provides a programmatic verification interface for parties that complete the registration and agreement to use it. This is the production-grade route — the path AP teams or finance systems take when they want verification at scale, audit-grade response logs, or real-time queries embedded in the invoice-receipt workflow rather than batched quarterly. Worth being honest about the access shape: it is not an open public API. There is a registration step, an agreement, and onboarding work an internal developer or integration partner does before the first query lands.
The third option is a commercial verification service — Signzy, Commenda, and others — that wraps the underlying CRA data with batch UX, vendor-onboarding integrations, and per-supplier reporting. These are convenience layers over the same source, not independent registries. They charge subscription or per-query fees in exchange for time savings, integration breadth into AP systems, and turnkey access without the CRA agreement work. For a finance team that wants the workflow operational by next quarter rather than next year, the commercial wrappers are a reasonable purchase; for a team with developer capacity in-house, the CRA API is the lower-cost long-run path.
The trigger that drives the bulk cadence is the cancellation rate. Suppliers cease operations, fall below the small-supplier threshold and deregister, or have their registrations revoked; corporate restructurings reissue BN15s; account suffixes move (RT0001 closes, RT0002 opens). A quarterly cadence is a reasonable default for most master files. High-value suppliers, high-frequency suppliers, and any supplier whose first verification was equivocal warrant a tighter cycle.
Both the bulk pass and the per-invoice query consume the same two facts off the invoice: the BN15 and the supplier-name-as-printed. A team that has those two fields plus the supply date already structured for every invoice that lands has solved the input-data problem for the whole verification workflow; the registry queries become arithmetic on that dataset rather than manual transcription off PDFs. AP automation that captures the BN15 and supplier name from each invoice for registry verification is what closes that gap. The point is the data feed, not the tool: doing the verification work on a structured BN15 column rather than a folder of PDFs is the difference between a workflow that scales and one that doesn't.
The shape of this workflow is not specifically Canadian — AP teams operating across jurisdictions encounter the same registry-verification pattern with different national instruments. The Australian Business Number runs the same kind of registry query; teams that already understand the equivalent ABN verification workflow for Australian supplier invoices will recognise the structure. The instruments and registries differ; the underlying control — pre-payment registry verification with documentary retention — is the same.
What Registration Verification Doesn't Cover — Tier Rules, Bank Details, and Quebec QST
Registration verification authenticates one specific thing: whether the supplier's tax registration was real and active on the date of supply. A reader who has now worked through the three checks may be tempted to file the result as the whole supplier-controls picture, which it isn't. Three adjacent controls share the same supplier-AP surface, and conflating them is what gets AP teams into the trouble that registration verification by itself can't prevent.
The first boundary is the invoice tier rules. CRA prescribes three tiers of documentation requirements for a supplier invoice depending on the consideration involved, with the supplier's GST/HST registration number being one of several required fields. The verification workflow this article walks confirms that the registration number is real and active. It does not confirm that the invoice itself meets the tier rules — the supplier-name format, the tax-rate breakdown, the supply-date or invoice-date fields, the buyer details where a tier requires them. A registration that verifies cleanly on an invoice missing other tier fields still doesn't support the ITC. For the field-level requirements that make an invoice itself compliant, see CRA's three-tier GST/HST invoice field requirements for ITC claims.
The second boundary is bank-detail and Business Email Compromise (BEC) fraud. A clean registration tells the AP team that the legal entity behind the BN15 is a real CRA registrant in good standing. It does not tell the team that the bank account on the invoice belongs to that legal entity, that the invoice was actually issued by the supplier rather than by an attacker who has compromised the supplier's email and substituted their own banking details, or that the supplier's change-of-details request that arrived last week is genuine. Bank-detail and payee-account verification is a separate fraud-control layer with its own instruments — callback verification on a number not pulled from the email, payee-name-match services that test whether the named account actually belongs to the supplier at the bank, and supplier-change-of-details controls that require additional authentication before any banking change is applied. A team that treats a clean registry confirmation as evidence the payment is going to the right account will pay the wrong account; the controls are layered, not interchangeable.
The third boundary is Quebec's Quebec Sales Tax (QST). The CRA registry covers federal GST and the harmonised HST (the latter applying in Ontario and the four Atlantic provinces) only. QST is administered by Revenu Québec on a separate registry. A Quebec supplier can hold a valid BN15 (its federal GST registration) and a separate QST number — the QST format follows a similar shape, with ten digits, a TQ program identifier, and a four-digit account suffix (1234567891 TQ 0001). Verifying the BN15 on the CRA registry does not verify the QST number, and the input tax refund (ITR) claimed on the QST line of a Quebec supplier invoice is supported by the QST registration, not the GST one. For the QST-side of a Quebec supplier workflow — including the Revenu Québec registry the QST number lives on — see verifying Quebec QST numbers on Revenu Québec's separate registry.
When a Check Fails — The Remediation Path Before You Pay
A failed check is a control point, not a payment block. Most failed checks are correctable through supplier follow-up. A minority require treating the GST/HST as unrecoverable. Very few warrant blocking the underlying payment. The actions below are ordered roughly from the cheapest, least disruptive response to the most disruptive — work down the list rather than starting at the bottom.
Action 1 — hold the GST/HST line, not necessarily the whole payment. The trade payable for the goods or services is usually still valid even when the GST/HST line cannot yet be supported. If your AP system permits a split, hold the GST/HST portion pending verification and process the rest of the invoice. For teams that pay or hold invoices as a unit, a short hold while remediation runs is cleaner than processing the full amount and then trying to claw back later.
Action 2 — request a corrected invoice. If the BN15 is malformed (a Check 3 failure), missing, or appears to be incorrect — for example, an RT account that the registry shows belongs to a different legal entity than the one named on the invoice — the supplier issues a corrected invoice with the right registration number. Many failed registry queries resolve at this step. Corrected invoices should reference the original invoice number so the trail is clean in both systems.
Action 3 — request documentation for an operating-name relationship. If Check 2 has failed and the supplier has a credible operating-name explanation, request the corporate-search result, articles of incorporation, or business-name registration that ties the operating name to the legal entity that holds the BN15. Re-run the registry query against the legal name once the documentation is in hand, retain the documentation in the supplier file, and treat the supplier as verified once the connecting document and the clean registry response sit alongside each other.
Action 4 — escalate to the supplier's bookkeeper or finance contact. AP-to-AP communication often resolves cases faster than going through an account manager because the supplier's bookkeeper has the BN15, the effective date, and any operating-name registrations at hand. This step also surfaces the rare cases where the supplier has charged GST or HST without a valid registration — a supplier that is not registered for GST/HST is not entitled to charge it, and the appropriate response is for the supplier to reissue the invoice without the tax line rather than for the AP team to pay tax that no registrant will ever remit.
Action 5 — treat the GST/HST as unrecoverable. If Check 1 has failed (the registration was not active on the supply date) and there is no realistic path to a supply-date adjustment, the GST/HST charged on that supply is not claimable as an ITC. Adjust the booking accordingly: pay the invoice net of the recoverable tax (or the gross amount if the supplier insists, with the unrecoverable portion booked to the appropriate expense account) and document the registry response that drove the adjustment. The arithmetic for backing the recoverable tax out of the invoice total — and the broader question of reverse-checking the tax line on a Canadian supplier invoice — sits in the sibling article on calculating GST/HST on Canadian invoices and reverse-checking the tax line.
The audit trail through all of this is the part that defends the file later. Every failed check, every remediation step, every supplier communication, and every re-run registry query is recorded in the supplier file with its date and the registry response. A file that shows a clean registry confirmation alongside the documentation that resolved each exception is what an auditor wants to see; a file with a failed check and no record of how it was handled is the case that becomes a Comtronic outcome rather than an averted one.
Writing Registration Verification Into Your AP Controls
Registration verification is one control across three operational surfaces in the AP cycle. Each surface has a distinct trigger, a distinct cadence, and a distinct documentary output. Writing the workflow into an AP procedure is mostly a matter of identifying which moments those three surfaces correspond to in the team's existing process and what evidence each one needs to leave behind.
Supplier onboarding. Before adding a supplier to the master file, run the three checks against the supplier's first invoice — or, where the supplier provides one, against a registration confirmation on letterhead. Onboarding is the right place to establish the documentary record of any operating-name relationship, because the AP team is already collecting supplier setup information and a corporate search or business-name registration sits naturally alongside the W-9-equivalent paperwork most AP teams already keep. Collect that documentation now, not the first time a registry query fails. The output of this surface is a complete supplier file before the first payment is released — a file that contains the BN15, the verified legal name, any operating-name documentation, and the initial registry response.
Pre-payment. On every invoice where a registration query is required, enter the invoice's supply date, the BN15, and the legal name into the registry, retain the response, and route the invoice through the remediation path covered above if any check fails. Most teams target a sampling cadence after the first verified invoice rather than re-querying every invoice from a supplier already in good standing in the master file — a sample at every Nth invoice or every M-month interval, weighted by supplier value, is a common shape. The output of this surface is a per-invoice registry response retained against the AP record for that supply, and a closed remediation thread for any invoice whose response was not clean.
Quarterly supplier-master review. Run the bulk-verification approach the team selected from the options walked earlier — quarterly batch via browser automation, the CRA API, or a commercial wrapper — against the full active-supplier list. The review surfaces three patterns the per-invoice control will not catch on its own: suppliers whose registration has been cancelled since the last sweep, suppliers whose legal name has changed (often through a corporate restructuring that re-issued the BN15), and suppliers whose accounts have moved (RT0001 closed, RT0002 opened). The output of this surface is an updated master file and a list of suppliers that need follow-up before the next payment cycle.
For AP teams paying subcontractors in the Canadian construction trades, verifying a Canadian subcontractor's workers' compensation clearance certificate before payment is a parallel onboarding-and-pre-payment control on the same supplier; compiling subcontractor invoices into a CRA-compliant T5018 listing at year-end consumes the same BN15 and legal-name dataset.
Extract invoice data to Excel with natural language prompts
Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.
Related Articles
Explore adjacent guides and reference articles on this topic.
Canada GST/HST Invoice Requirements: CRA Compliance Guide
CRA's three-tiered GST/HST invoice requirements explained. What fields each tier demands, how to validate invoices for ITC claims, and common audit triggers.
Verify Norwegian Organisasjonsnummer and MVA Before Paying
AP workflow for checking Norwegian supplier invoices: MOD-11 organisasjonsnummer, Brønnøysund status, MVA registration, and legal-name match.
How to Calculate GST/HST on Canadian Invoices
Learn the formulas for adding or backing out GST/HST on Canadian invoices. Includes BC/PST, Quebec QST, place-of-supply, and rounding checks.