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 Japan T-number on supplier invoices, an accounts payable buyer enters the 13 digits without the "T" prefix on the National Tax Agency's public registry at invoice-kohyo.nta.go.jp; at higher AP volume, the NTA also offers a Web-API for batch lookups. The verification confirms three things: that the issuer is registered, that the registered name matches the issuer printed on the invoice, and that the registration was active on the invoice transaction date. Together those three checks are what make the buyer's input tax credit (仕入税額控除, shiire zeigaku kōjo) supportable if the position is later challenged.

That framing matters because "the invoice has a T-number printed on it" is not the same as "the issuer is registered, currently active, and the name matches." Only the registry lookup answers the second question. An AP team that treats the printed identifier as evidence in itself has confirmed nothing — verification is the structural control that converts a printed string into evidence the registration was active at the moment the transaction occurred.

What follows walks the format you can validate at capture, the manual and Web-API lookup paths and where each fits, the four-stage AP intake gate, the exception cases AP teams hit in practice, cadence as a policy decision, and the controls that sit alongside verification rather than inside it.

What the T-Number Is and Where to Find It on a Japanese Invoice

The format is precise: the literal letter "T" followed by exactly 13 digits, validated by the regular expression ^T\d{13}$. A real T-number takes the shape T1234567890123 — 14 characters total, no spaces, no separators, the prefix always uppercase. Anything that does not fit that shape will not resolve on the NTA registry, so format validation at capture is the cheapest first filter.

The 13 digits are issued differently depending on issuer type. For JCT-registered corporations (法人, hōjin), the 13 digits after "T" match the supplier's corporate number (法人番号, hōjin bangō) — the same identifier the National Tax Agency assigns to the legal entity in the corporate-number system. For sole proprietors (個人事業主) and certain other qualified issuers, NTA issues the 13 digits separately on registration. Both forms are equally valid Japan invoice registration numbers and verify the same way on the invoice-kohyo registry; the difference matters only when an AP system cross-checks the registration number against a stored corporate number, which works for incorporated suppliers and silently fails for sole proprietors.

On a standard qualified invoice (適格請求書, tekikaku seikyūsho), the T-number sits in the issuer identification block, near the issuer's legal name and address. On a simplified qualified invoice (適格簡易請求書, tekikaku kan'i seikyūsho) — the form retail, restaurant, taxi, and certain other businesses are permitted to issue — the T-number appears in the same issuer-identification location. Layout, however, is not standardised across supplier ERP outputs. Some suppliers print the T-number adjacent to the company seal block; some run it into the address footer; some give it its own labelled "登録番号" (registration number) field; some stamp it across the header. Buyers receiving PDFs or scanned invoices from a varied supplier base will see all of these.

The practical consequence sits at the intake. Most inbound Japanese supplier invoices arrive as PDF email attachments, scans, or images rather than as structured EDI or Peppol payloads, which means the T-number has to be captured into a structured field before any registry lookup is possible. Format-validating against ^T\d{13}$ at capture catches the easy failures fast — a missing digit, a transposed letter, an OCR artefact that read "T" as "1" — so they fail at extraction rather than failing later as a "not found" against the registry, where the failure mode looks like a registration problem rather than a capture problem. For readers who want the surrounding context — issuer-name kanji, address layout, by-rate tax breakdown — our guide on reading Japanese invoice kanji fields and locating the T-number on a qualified invoice covers the document-reading layer in depth.

Manual Verification on the NTA Public Registry

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 invoice issuer lookup Japan check that is most easily missed. 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's Web-API page, and practitioner queries route to [email protected]. Lead time should be planned for as part of the integration timeline rather than discovered during a sprint — an AP lead scoping a Q3 go-live needs the application in flight well before development starts, not after.

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, which means bulk T-number verification AP work is a loop at the 10-per-call batch size, not a single bulk-endpoint call. Sizing matters: backfilling an existing Japan vendor master of, say, 4,000 active suppliers is 400 calls — fine, but worth scheduling against the API's rate-limit posture and the team's window for the backfill rather than running it ad hoc on a Friday afternoon.

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.

---

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. T-number not found NTA what to do, in short, is not "guess" — it is "hold, correct, reverify."

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. The right T-number name mismatch invoice disposition is to hold and clarify with the supplier before posting — get the explanation and the supplier's own confirmation that the registered name and the 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; the goal is to clarify each pattern once rather than re-clarify every month.

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.

Verification Cadence as a Policy Decision

How often verification runs is a policy choice, not a technical given, and the choice has visible consequences for input-tax-credit exposure. Three cadences cover most of the realistic range.

Per-invoice verification at receipt. Every inbound invoice's T-number is verified against the registry before the invoice posts. This is the gold standard, and it is only realistic with automation. A team trying to verify every invoice manually in a 500-per-month flow either skips checks under load or falls behind on month-end posting. With a pre-posting Web-API hook, per-invoice verification is straightforward; without it, the cadence is aspirational.

Per-supplier verification at onboarding plus periodic reverify. Each new Japanese supplier is verified once at onboarding, and the active vendor master is reverified on a fixed cadence — monthly, quarterly, or biannual — typically as a differential-update job rather than a full re-lookup. This is the typical mid-size compromise: it catches new suppliers and flags deregistrations within the cadence window, without requiring per-invoice automation. The exposure is the gap between the reverify runs, which has to be acceptable against the team's tolerance.

Verify only when something looks off. Verification is triggered by clerk-noticed name mismatches, escalations from a tax adviser, or audit prompts. This is the weakest option, and the reason it is weakest is structural: nothing about the invoice itself signals that the supplier deregistered last quarter. The T-number is still printed, the issuer name is unchanged, and the invoice looks identical to the one cleared three months ago. Triggering on visible anomalies will not surface deregistrations that left the invoice surface untouched.

The right cadence is a function of inputs, not a recommendation. Total Japanese invoice volume sets the floor for what is operationally feasible without automation. Per-supplier invoice frequency determines how much exposure accumulates between reverify runs — a vendor sending one invoice a quarter creates different math from a vendor sending 80 a month. Vendor churn rate matters: a stable supplier base ages slowly; a base where new suppliers come on monthly and existing ones change status quarterly needs faster cadence. The team's tolerance for input-tax-credit exposure sets the acceptable gap. And whether automation is in place at the extraction and Web-API layer determines whether per-invoice verification is a real option or just a target.

The 2026 transitional schedule is the lever that pushes cadence upward over time. The transitional rules taper the credit available on invoices from non-registered or deregistered suppliers, and the taper makes deregistration-blindness progressively more expensive as the schedule moves through its phases (covered in depth as a separate topic). A vendor master that does not pick up deregistrations through differential update will quietly accumulate that exposure on the books, surfacing only when someone reconciles the credit position back to the registry state at the relevant transaction dates. What matters here is that the schedule makes the cadence question worth taking seriously now, rather than parking it as "we will tighten this when we have time."

---

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.