How to Verify a Japan T-Number on Supplier Invoices

A Japan T-number is the letter "T" followed by 13 digits, printed on a qualified invoice as the registration identifier of a qualified invoice issuer (適格請求書発行事業者, tekikaku seikyūsho hakkō jigyōsha). To verify a Japan T-number on a supplier invoice, AP enters the 13 digits without the "T" prefix on the National Tax Agency's public registry at invoice-kohyo.nta.go.jp. Higher-volume teams can use the NTA Web-API for scheduled or batch checks. A printed T-number is only a claim; the registry lookup is the evidence that the number belonged to an active qualified issuer on the transaction date and matched the invoice issuer, which is what supports the buyer's input tax credit (仕入税額控除, shiire zeigaku kōjo).

Manual Verification on the NTA Public Registry

Before lookup, capture the T-number exactly: the literal letter "T" followed by 13 digits, validated by ^T\d{13}$. A real T-number takes the shape T1234567890123 — 14 characters total, no spaces, no separators, prefix uppercase. On standard and simplified qualified invoices, it sits near the issuer's legal name and address, although supplier layouts vary. Some suppliers print it beside the company seal block; some place it in the footer; some label it "登録番号" (registration number). For the surrounding document-reading layer — issuer-name kanji, address layout, and by-rate tax breakdown — see reading Japanese invoice kanji fields and locating the T-number on a qualified invoice.

For corporations, the 13 digits after "T" usually match the supplier's corporate number (法人番号, hōjin bangō). Sole proprietors and some other qualified issuers receive a separately issued number. Both verify the same way on the invoice-kohyo registry; the distinction only matters when an AP system cross-checks the registration number against a stored corporate number.

The registry is the NTA Qualified Invoice Issuer Publication Site — formally the 適格請求書発行事業者公表サイト (tekikaku seikyūsho hakkō jigyōsha kōhyō saito) — and it is the authoritative source for qualified invoice issuer status. Japan's National Tax Agency operates the public registry of qualified invoice issuers at invoice-kohyo.nta.go.jp, where buyers verify a T-number by entering the 13-digit registration number without the "T" prefix. That input convention is the single most common manual-lookup mistake to avoid: pasting T1234567890123 from the invoice into the search box returns no result, because the registry indexes on the digits alone. Strip the prefix, paste the 13 digits, submit.

A successful lookup returns the registered issuer's name, the address of the principal office, the registration effective date, the last-updated timestamp on the record, and (where applicable) a deregistration date. The registry is the qualified-issuer publication system specifically — it is not a third-party mirror, and it is not the same as the corporate-number system at houjin-bangou.nta.go.jp, which covers all Japanese legal entities rather than the qualified-issuer subset. For buyer-side T-number verification, invoice-kohyo is the system; the corporate-number registry is a different tool with a different scope.

The four checks an AP buyer performs against the returned record are individually simple, but each one matters:

1. The 13 digits resolve to a registered issuer. If the registry returns no result, the supplier is not a qualified issuer at this number, and the AP team is into exception handling.
2. The registered name matches the issuer printed on the invoice. Watch for the difference between a legal name and a trading name, for kanji versus kana renderings of the same name, and for romanised or abbreviated forms. A close match is not always a clean match — the registry's record is the legal name, and the invoice may show a trade name that legitimately differs.
3. The registration was active on the invoice transaction date. Compare the transaction date (typically the issue date on the invoice or the supply date for the goods or services) against the registration effective date on the registry record. An invoice issued before the supplier's registration took effect cannot support the input tax credit as a qualified invoice.
4. No deregistration date posted on the record falls before the transaction date. This is the qualified-issuer lookup check AP teams most often miss. A supplier who was registered when you onboarded them last year may have deregistered last quarter; the deregistration date sits on the same registry record, and an invoice issued after that date is no longer a qualified invoice, even if the supplier kept printing the T-number on it.

Manual lookup against this procedure is realistic for an AP function processing roughly a dozen Japanese invoices a month, workable up to a few dozen with discipline, and impractical past that. A team handling 100 invoices a month who try to check T-number NTA registry entries one at a time will either skip checks under load or fall behind on posting; neither is a failure of the manual path, just an operational ceiling. Past that ceiling, the NTA Web-API is the path that keeps verification at the intake gate without grinding the team to a halt.

The NTA Web-API for Bulk and Scheduled Verification

Two NTA APIs sit close enough in name that scoping conversations frequently confuse them, and getting the wrong one started costs weeks. The 適格請求書発行事業者公表システム Web-API — the invoice-kohyo Web-API, hosted under web-api.invoice-kohyo.nta.go.jp — is the API for buyer-side T-number verification. The 法人番号システム Web-API at houjin-bangou.nta.go.jp/webapi is the corporate-number system, a separate API covering all Japanese legal entities. The corporate-number API does not return registration status for the Qualified Invoice System, and the invoice-kohyo API does not return data on entities that are not qualified issuers. For NTA Web-API T-number lookup work specifically, the invoice-kohyo Web-API is the right system; the corporate-number system is useful only as supplementary data.

Access is not on-demand. The invoice-kohyo Web-API requires an Application ID issued by NTA on application; there is no self-service key generation. Applicants submit a form on the NTA Web-API page, and practitioner queries route to [email protected]. Lead time belongs in the integration plan, not as a sprint surprise.

The call mechanics that matter for AP planning are tight. The API is REST-based and returns the same field set as the registry UI: registered issuer name, principal office address, registration effective date, deregistration date if applicable, and last-updated timestamp. A single lookup request accepts up to 10 registration numbers, so bulk T-number verification is a 10-per-call loop, not a single bulk endpoint. Backfilling an existing Japan vendor master is a scheduled control job, not an ad hoc clerk task.

Two request modes are worth understanding clearly because they map onto different AP workflows.

Point lookup verifies a specific number, optionally as of a specific date. This is the natural call from a pre-posting hook in AP intake: an invoice arrives, the T-number is extracted, the hook calls point lookup with the T-number and the invoice transaction date, and the response gives back the four data points needed to evaluate the four checks from the manual procedure. The pre-posting position is what makes the verification gate meaningful — a point lookup at posting time would already be too late if the registry has changed since receipt.

Differential update returns all changes (new registrations, updates, deregistrations) since a given timestamp. This is the call that makes T-number deregistration monitoring against the AP vendor master practical at scale. Rather than re-verifying every active Japan vendor every night and burning calls on the 99% of records that did not change, a nightly differential job pulls the changes since yesterday's high-water mark, joins them against the vendor master, and surfaces only the records where status moved. A supplier registered today can deregister later, and a vendor master that does not pick up the change goes blind to a real shift in input-tax-credit treatment from the deregistration date forward.

Most AP functions combine a pre-posting hook with a nightly differential-update job against the active Japan vendor master, and reserve a full reverify of every active Japan vendor for an annual control rotation as a backstop against missed differentials and clock skew.

Cadence is a policy choice. Very low volume can justify manual verification at receipt. Mid-size teams usually verify each new Japanese supplier at onboarding and reverify the active vendor master monthly, quarterly, or biannually. High-volume teams should move the check into the pre-posting API gate and run differential updates against the vendor master. The weak option is verifying only when something looks odd, because deregistration does not change the surface of the invoice. The transitional-credit schedule raises the cost of missing deregistrations over time; for the non-registered supplier treatment, see handling non-registered supplier invoices in Japan AP.

The Four-Stage AP Intake Gate: Receipt, Extraction, Verification, Posting

The control model is four stages in sequence — receipt, extraction, verification, posting — each with a clear input, a clear pass condition, and a defined failure handling. Mapping a current intake against this sequence is usually the fastest way to see where the verification step is missing or out of position.

Receipt. Inbound channels for a Japanese supplier invoice include PDF attachments arriving in the AP mailbox, EDI feeds from suppliers running structured exchange, supplier portals for organisations that operate one, and Peppol JP PINT for the network-connected. The channel mix matters because it changes the realistic timing of verification. A structured Peppol payload arrives with the T-number already in a discrete field; the gate can read it directly and call the registry. A PDF attachment carries the T-number as text on the page and requires extraction first. The actual channel mix at the receiving end sets the rest of the gate — a function whose inbound is 90% PDF email is solving a different sequencing problem from one running 90% Peppol.

Extraction. The T-number must land in a structured field with format validation against ^T\d{13}$ before the verification call has anything to send. For invoices arriving as PDFs, scans, or images, extraction is a real engineering step rather than a parse: the T-number sits in a position that varies across supplier ERP outputs, and the surrounding context — Japanese kanji issuer name, mixed scripts, simplified qualified invoice variations — has to be handled correctly so the captured value is the registration number and not some neighbouring identifier. This is the natural place for an extraction platform in the workflow. Our product is built to extract T-numbers from PDF or scanned Japanese invoices into structured data by treating extraction as a prompt-driven task: a user describes the fields needed (T-number, issuer name in kanji, transaction date, by-rate tax breakdown), and the platform returns a structured Excel, CSV, or JSON output ready for the verification call. PDF, JPG, and PNG inputs are all supported, including multi-page PDFs with up to 5,000 pages and mixed batches of up to 6,000 files in a single job; East Asian scripts are handled alongside Latin and other scripts in the same output. The point at this stage of the gate is to convert the document surface into a clean structured T-number field; the registry lookup follows.

Verification. The captured number is looked up against the NTA registry — manually for low volume, via the Web-API at shared-services scale. The gate logic at this step splits cleanly into fail-closed and soft-fail cases. Fail-closed cases block posting until resolved: the T-number is missing on the invoice, the captured value fails the ^T\d{13}$ format check, the registry returns no result for the 13 digits, or the registry-name and invoice-issuer-name are unambiguously different entities. Soft-fail cases flag for human disposition rather than block automatically: the most common is kanji-versus-kana name variation where the variant is plausibly the same legal entity (a different writing of the same company name, romanised against kanji, an abbreviated trading name against the registered legal name). The split is itself a policy choice. A stricter AP function may treat soft cases as fail-closed by default; a more permissive one may auto-approve common patterns once they are documented on the vendor master. State that policy explicitly rather than letting it emerge from clerk discretion case by case.

Posting. The invoice books to the ERP only after verification passes or the soft case is human-resolved. Posting before verification reintroduces the exact exposure the gate exists to prevent: a deregistered supplier's invoice posts cleanly, the input tax credit gets taken, and the exposure surfaces only at audit, when reconstructing the registry state at the transaction date is harder than it should have been. A control that runs after the booking is not a gate; it is reporting.

Five Exception Cases and How AP Handles Them

In practice, T-number verification fails in five recognisable ways. Each has a clean disposition; the trick is naming the case correctly so the disposition follows.

Case 1: T-number missing from the invoice. Without a T-number, the invoice is not a qualified invoice, and the buyer cannot claim the full input tax credit on it as one. The disposition splits on whether the supplier is in fact registered. If they are registered and simply forgot to print the T-number, request a corrected invoice with the registration number added — it is a paperwork fix. If the supplier is not registered at all, the invoice cannot become a qualified invoice retrospectively, and transitional-credit treatment applies. Handle the non-registered supplier case under your separate transitional-credit playbook rather than working it case-by-case at the AP gate.

Case 2: T-number present on the invoice but not found in the NTA registry. Three things to rule out, in order. First, re-run extraction on the source document — what reached the registry call may not match what is on the page if a digit was misread or the "T" was dropped. Second, compare the captured value against the printed value on the invoice manually; a single transposed digit by the supplier on the invoice itself is a frequent cause and the supplier needs to correct it. Third, in rare cases, the number on the invoice is fraudulent or fabricated. Across all three, the AP disposition is the same: hold payment, request correction from the supplier with the supplier's own evidence of their registered T-number, and confirm the corrected number resolves cleanly on the registry before releasing the invoice for posting.

Case 3: T-number resolves to a different issuer name than the invoice issuer. This is the most ambiguous case, because a name mismatch can be entirely legitimate or a sign of a misattached T-number. A trading name printed on the invoice that differs from the registered legal name is common; an abbreviated form, a romanised rendering of a kanji name, or a kanji/kana variation of the same name all show up regularly. Equally, the T-number might genuinely belong to a different entity altogether. Hold and clarify with the supplier before posting: get the explanation and the supplier's confirmation that the registered name and invoice issuer are the same legal entity. Where the variation is a known recurring trade-name pattern for an established vendor, document it on the vendor master so future invoices clear automatically.

Case 4: T-number resolves to a deregistered issuer as of the transaction date. Compare the deregistration date on the registry record against the invoice transaction date. If the deregistration date precedes the transaction date, the supplier was no longer a qualified issuer when the invoice was issued. Two things follow. Transitional-credit treatment applies to that invoice from the deregistration date forward, which means the buyer can no longer take the credit as a full qualified-invoice credit. And the invoice itself should have been issued in non-qualified form from the date of deregistration; if the supplier kept printing the T-number after deregistering, flag the mismatch and confirm the supplier's understanding of their own status. The 2026 transitional schedule sits behind this case as the policy backdrop, which the next section addresses.

Case 5: Simplified qualified invoice (適格簡易請求書) from retail, restaurant, taxi, and similar issuers. A simplified qualified invoice has a different format from a standard qualified invoice — most notably, the recipient name field is not required — but the registration check at the front of the verification gate is identical. The T-number still appears, still must be 13 digits validating against the registry, and still must match the registered issuer name as in Case 3. The mistake to avoid is treating simplified invoices as exempt from verification because they are smaller, more frequent, or more administratively casual than standard qualified invoices. The format is simplified; the registration status check is not.

What T-Number Verification Does Not Protect Against

T-number verification is one control in a stack, not the whole stack. What it confirms is precise: the registration is real, the registered name matches the invoice issuer, and the registration was active on the transaction date. What it does not confirm is everything else that has to be true for the invoice to function as a qualified invoice and for the buyer's retention to be compliant.

The seven mandatory qualified-invoice fields are a separate check. A qualified invoice has to carry a defined set of fields — issuer name and registration number, transaction date, transaction details, by-tax-rate totals, applicable tax rate, recipient name where required — for it to function as a qualified invoice for input-tax-credit purposes. A verified T-number on an invoice that is otherwise missing a required field is necessary but not sufficient: the registration is real, but the document is not a complete qualified invoice. Readers who want the full mandatory-field walk should work from the broader Japan Qualified Invoice System and its mandatory fields, which covers the regime end to end rather than just the registration layer.

The by-rate tax-split arithmetic is a separate check. Japan operates a standard 10% consumption-tax rate alongside an 8% reduced rate for specified categories, and a qualified invoice has to show the by-rate totals correctly. T-number verification does nothing for the math: a registered supplier can still issue an invoice where the rate split is wrong, either through clerical error or because their billing system handled a rate boundary incorrectly. AP teams that automate verification should automate a rate-split arithmetic check on the same intake — confirming each rate's net total times its rate equals the corresponding tax amount, and that the rate-line totals reconcile to the invoice total. The arithmetic check is mechanical; missing it because verification ran cleanly is the easy mistake.

Electronic retention is a separate check. Retaining qualified invoices electronically must comply with Japan's e-Bunsho / EBPA framework — file-integrity requirements, retention period, and search-functionality obligations on stored documents. Verification at receipt does not extend to retention; an invoice can verify cleanly at the gate, post correctly, and still create exposure later because the retention copy was stored in a non-compliant form. AP and finance-ops teams designing the full Japan control framework should treat retention as its own workstream, separate from the verification gate; Japan's e-Bunsho electronic invoice retention rules cover what compliant retention actually requires.