IRS TIN Matching: e-Services Enrollment to Bulk Sweeps

IRS TIN Matching is a free pre-filing service inside IRS e-Services that lets a payer validate a vendor's name and TIN against IRS records before the first payment is released. The Principal of the firm submits the TIN Matching Application, and the firm has to be on the IRS Payer Account File (PAF) — meaning it has filed at least one qualifying information return (1099-MISC, NEC, INT, DIV, OID, K, B, G, or PATR) in the prior two years. Once enrolled, AP teams run matches in one of two modes: Interactive (up to 25 name/TIN combinations per session, real-time results on screen) or Bulk (up to 100,000 per file, results delivered within 24 hours). Each row comes back with a numeric response code from Pub 2108A — codes 0 through 6 — and that code drives the next AP step, from clearing the vendor for payment to requesting a fresh W-9 to holding the payment until the mismatch is resolved.

TIN matching is the prevention step. A vendor TIN check before a payment goes out is what keeps the firm off CP2100 / B-Notices later, when the IRS reconciles filed information returns and starts billing the payer for backup withholding. The work belongs at vendor onboarding (Interactive, before the first payment) and in a periodic vendor-master sweep (Bulk, before 1099 filing season), not late January when there's nothing left to do but write out corrected forms. This IRS TIN matching e-Services walkthrough takes an AP team from "we've never enrolled" through eligibility, the application, the Interactive vs Bulk choice, the Bulk file format, the Pub 2108A response codes mapped to concrete AP actions, cadence, and the in-house-versus-wrapper economics so the breakeven can be computed at your own volume.

Eligibility: the Payer Account File and the Principal of the firm

Two gates decide whether a firm can enroll: the Payer Account File rule, and the Principal-of-the-firm requirement.

The Payer Account File (PAF) is the IRS's internal list of firms eligible to use TIN Matching, populated from the information returns those firms have already filed. To appear on it, the firm must have filed at least one qualifying information return in the prior two years — a 1099-MISC, 1099-NEC, 1099-INT, 1099-DIV, 1099-OID, 1099-K, 1099-B, 1099-G, or 1099-PATR. A firm that has been operating but never filed any of those returns (common at very small or very new businesses, or at firms that pay only employees) is not yet on the PAF and cannot enroll; the fix is to file the next qualifying return that comes due. Per IRS TIN Matching service eligibility guidance, TIN Matching is a pre-filing service offered only to payers and authorized agents listed on the IRS Payer Account File (PAF) database, available in Interactive or Bulk modes. Payer Account File PAF eligibility is the precondition; nothing else matters until it is met.

The second gate is who submits the application. The IRS means "Principal of the firm" literally: a 5% or greater owner, a partner, a corporate officer, or another person with the legal authority to bind the firm. A staff accountant, an AP manager, or a 1099 specialist cannot submit the TIN Matching Application themselves; the Principal has to. This is the friction point most AP teams underestimate — the application requires the time and attention of someone near the top of the firm's org chart, not an IT-style request the team can file and forget. The Principal's involvement is largely one-off: once enrolled, they can add Authorized Users — typically AP staff or 1099-compliance specialists — under their own consent, and those Authorized Users do the day-to-day matching.

One scope clarification belongs at this gate. TIN Matching applies to W-9 vendors (US-person payees who provide a US TIN on Form W-9), not to W-8 vendors. Foreign-vendor validation is a separate control layer running against W-8 documentation, treaty-rate logic, and Form 1042 reporting; if your vendor population includes W-8 suppliers, the right starting point is foreign-vendor withholding for W-8 suppliers. Everything that follows assumes the vendors in question are on W-9.

The enrollment process: ID.me, the TIN Matching Application, and the SOR

Enrollment runs in three stages: the Principal creates an e-Services account and clears identity verification through ID.me, the Principal submits the TIN Matching Application from inside e-Services, and the firm waits for IRS review. Plan for days, not minutes — promising the CFO that TIN matching will be live by Friday is the most common scoping error.

Stage one — e-Services account and ID.me. ID.me is the identity-proofing service the IRS uses for sensitive online accounts, and the Principal personally has to complete it. The flow involves a government-issued photo ID, a selfie or short video match, and supplementary documents in some cases (Social Security number, a recent utility bill, sometimes a brief video call with a verification agent if the automated checks do not clear). For a Principal with documents to hand and a working webcam, this can be a single sitting; for one who has to find their passport or schedule the video-agent step, longer. Block real time on the Principal's calendar — this step is happening to a person, not to the firm.

Stage two — the principal of firm TIN matching application. Once the e-Services account is active, the application is submitted from inside e-Services. The Principal enters identifying information for the firm, attests to its eligibility (the PAF rule above), and submits. There is no useful "expedite" lever; the IRS reviews on its own schedule. While waiting, the Principal can identify which AP staff should be added as Authorized Users — they can be added during the application or after activation, but the Principal's consent is what authorizes them.

Stage three — the wait, and where results will live. Bulk TIN matching results are delivered to the firm's Secure Object Repository (SOR), a secure inbox inside e-Services; each completed Bulk submission produces a downloadable response file there, typically within 24 hours of upload. Interactive results do not use the SOR — they appear on screen in real time. A firm planning a December Bulk sweep before the 1099 filing window should kick off enrollment no later than early November to leave room for verification steps that need a second pass.

Choosing between Interactive and Bulk: a workflow decision, not a feature comparison

Once a firm is enrolled, both modes are available. The choice is not which one to enable but which one fits the work in front of you.

Interactive is the right mode when the AP team is onboarding one new vendor, has the W-9 in hand, and needs an answer before the first payment is scheduled. Paste the name and TIN into the form, submit, get the response code on screen, log it against the vendor record, decide. Up to 25 rows per session is more capacity than a typical onboarding queue needs in a single sitting; real-time response means the vendor is cleared or held the same minute.

Bulk is the right mode when the AP or 1099-compliance team is sweeping the vendor master against IRS records — pre-1099 filing season, after a backlog of newly collected W-9s has built up during a refresh, or as a periodic check against the full active-vendor list. Up to 100,000 name/TIN combinations per file; results delivered to the SOR within 24 hours and worked through as a batch. The practical constraint is usually how to produce the file, not how many rows the IRS will accept.

The decision rule is short. One new vendor in front of you right now, W-9 to clear for payment: Interactive. A list of vendors to validate as a group against IRS records: Bulk. If both are true at the same time — mid-sweep when a new vendor arrives at the onboarding queue — use both; the modes are not exclusive, and firms running TIN matching seriously use them in parallel. Interactive sits in the daily AP work; Bulk sits on the calendar.

Running Interactive TIN Matching for vendor onboarding checks

Interactive is the mode AP teams use most once enrolled, because it slots directly into the onboarding queue. From inside e-Services, the Authorized User opens TIN Matching and enters name/TIN combinations one row at a time, up to 25 per session. For each row: the TIN type indicator (EIN for entities, SSN for individuals using their personal Social Security number — a common pattern with sole proprietors), the 9-digit TIN with no dashes, and the name exactly as it appears on the W-9. The TIN type indicator matters; an EIN submitted as an SSN (or vice versa) is what produces the alternate-file match code covered in the codes section. Submit, and the response code returns on screen immediately.

The cadence inside the onboarding queue: every new W-9 gets an Interactive TIN match before the first payment is released. If the response code is anything other than a clean match, the payment is held until the underlying issue — wrong TIN, wrong name, missing TIN, mismatched name — is resolved with a fresh W-9. TIN matching is one control inside a broader vendor-master governance routine, not a substitute for it; W-9 collection, vendor banking validation, address verification, internal approval workflow, and duplicate-vendor or fraud-detection checks all sit alongside, framed by the broader vendor master data governance controls.

For audit purposes, record three things per match: the date, the response code, and the Authorized User who ran the check. An internal auditor or SOX team reviewing AP controls a year later wants a contemporaneous record showing the check was performed before payment, by a named person, with a documented result.

Running Bulk TIN Matching: the file format and the W-9 extraction step

Bulk TIN Matching is two pieces of work: preparing the upload file (what Pub 2108 documents) and producing that file from a stack of W-9s (what AP teams actually find hard).

The bulk TIN matching file format is fixed and published in Pub 2108. The file is plain text, comma-delimited, with no header row. Each line is one vendor, with the field order: TIN type indicator (1 for EIN, 2 for SSN, 3 if unknown), the 9-digit TIN with no dashes, the name as it appears on the W-9, and an optional account number for the requester's own internal reference. The IRS does not interpret the account number column, so AP teams typically use it to carry their internal vendor ID for joining the response file back to the vendor master. Up to 100,000 rows per file. Pub 2108 publishes the character caps, special-character restrictions, and file-naming conventions; refer to it directly when preparing a first file, and trust it over any public source that contradicts it (some confusingly say semicolon delimiter — it is comma).

The upload itself is short. The Authorized User uploads the prepared file through e-Services; the IRS delivers a response file to the firm's Secure Object Repository within roughly 24 hours. The response mirrors the input row-for-row with the response code appended, so a 5,000-row submission produces a 5,000-row response. Download the response, join it back to the vendor master using the account-number column, and work through the codes that need action.

The harder piece sits before the upload. AP teams hold W-9s as PDFs — scanned, emailed, signed digitally, or printed and re-scanned in any combination — and have to extract name plus TIN out of every PDF into the IRS row format. Manual transcription is the predictable failure point: a transposed digit in a TIN, an extra space in a name, an EIN entered as an SSN by reflex. Each of those produces a false mismatch in the response file, and the AP team then chases a vendor data issue that does not exist. AI-powered W-9 data extraction is the document-to-data step that produces the file: a goal-oriented prompt that names what the IRS upload needs (legal name from line 1, TIN, TIN type indicator), a batch upload of W-9 PDFs (the platform handles up to 6,000 files per session, mixed PDFs and images, multi-page PDFs containing several W-9s), and a CSV output that drops directly into the Bulk row format with the account-number column appended as the internal join key. The same prompt produces the same structured output across every W-9 in the batch — the consistency property the IRS Bulk format demands. The product is not a TIN matching wrapper; the IRS service still does the matching. It produces the input file from the source documents the AP team already has.

Response codes 0–6 from Pub 2108A and the AP action for each

Every Interactive submission and every Bulk response file returns a Pub 2108A response code per row. The translation from code to AP action is mechanical once written down. For each code: what it means per Pub 2108A, the AP next-action, and what to record in the audit log.

Code 0 — TIN and name match IRS records. The cleanest result. The vendor's name and TIN combination is on file at the IRS exactly as submitted.

• AP action: clear the vendor for payment. No follow-up document required.
• Log: matched, date of match, mode used (Interactive or Bulk), Authorized User who ran the check.

Code 1 — TIN missing or in an invalid format. The submitted row had no TIN, all zeros, fewer than 9 digits, or non-numeric content. This is a data problem in the input, usually a transcription error or a W-9 that was incomplete.

• AP action: reject the W-9, request a fresh one with a valid 9-digit TIN before any payment is released. If the original W-9 had a valid TIN and the issue is transcription, fix the input row and re-run rather than asking the vendor for a new W-9.
• Log: rejected at TIN matching, awaiting valid W-9 (or awaiting input correction).

Code 2 — TIN is in a valid format but is not currently issued by the IRS. The number looks like a real TIN but the IRS has no record of it. Possibilities: the TIN is wrong, the W-9 was filled in incorrectly, the TIN is fictitious, or it has been retired.

• AP action: request a fresh W-9. Do not pay until resolved. A code 2 is not a clerical issue — it is a "this TIN is not real" answer from the IRS, and clearing payment to it puts the firm directly in line for a CP2100 / B-Notice and a backup-withholding obligation later.
• Log: code 2 mismatch, payment held, fresh W-9 requested.

Code 3 — TIN is valid and issued, but the name on the IRS file does not match the submitted name. The classic case is the sole-prop versus LLC versus DBA confusion: the vendor's EIN belongs to the entity, but the W-9 carries a DBA name; or the vendor used their personal SSN with their LLC's name. This is the single most common substantive mismatch in practice.

• AP action: request a fresh W-9 with the correct legal name and the correct TIN type. For a multi-member LLC or a corporation, the name should match the IRS records for the EIN. For a sole proprietor using their own SSN, the name should be the individual's legal name, not their business or DBA name. Without resolution, this vendor is a backup-withholding candidate under IRC §3406 — 24% withheld from each payment until the mismatch is cleared.
• Log: code 3 name/TIN mismatch, payment held, fresh W-9 requested with correct legal name.

Code 4 — invalid TIN matching request. The row itself is malformed — wrong number of fields, an invalid TIN type indicator, a row that the IRS parser could not interpret. This is not a vendor problem; it is a file-prep problem.

• AP action: fix the input row and resubmit. If a Bulk file has many code 4 rows, the file generation step itself has a bug — review the extraction or transcription process before re-running.
• Log: code 4 input error, row corrected and re-submitted (no vendor follow-up needed).

Code 5 — duplicate request. The same name/TIN combination appeared more than once in the submission. The IRS returns the duplicate marker for the second and later occurrences.

• AP action: ignore for the current submission; the underlying vendor was already matched on the first occurrence. Deduplicate the source list before the next run so the response file is cleaner.
• Log: optional — many AP teams record code 5 only as a count, not per row.

Code 6 — match found on the alternate file. The TIN/name combination matched, but on the alternate file from the one indicated in the submitted row. In practice this means the request flagged the TIN as an EIN and the IRS found the match on the SSN file, or vice versa. The combination is real; the TIN type indicator was wrong.

• AP action: clear the vendor for payment — the underlying records check is positive — but log the matched type, and consider re-collecting the W-9 with the correct TIN type for clean future records and consistency with the rest of the vendor master.
• Log: code 6 alternate-file match, cleared for payment, TIN type corrected in vendor master.

Codes 2 and 3 are the ones that decide whether the firm sees a CP2100 notice in the months after 1099 filing. A persistent unresolved mismatch in either code is exactly the pattern the IRS reconciliation flags, and the consequence is the 24% backup-withholding obligation under IRC §3406 plus the remediation paperwork. The discipline at the response-code-handling step — request the fresh W-9, hold the payment, document the mismatch and its resolution — is what keeps the prevention loop closed and the remediation workflow unnecessary.

Cadence and the in-house vs wrapper economics

TIN matching belongs on the AP calendar in three places, not one. Treating it as a one-shot December chore is the single most common mistake — by the time the vendor master is being prepared for 1099 filing, the cheapest fixes (catching a bad W-9 before the first payment, requesting a corrected one while the vendor relationship is fresh) are already off the table.

The first cadence is at vendor onboarding. Every new W-9 received gets an Interactive TIN match before the first payment is released. This is where the cheapest catches happen — the vendor is in active correspondence with the AP team, a corrected W-9 takes a single email, and the firm has not yet built a payment history to a vendor whose data turns out to be wrong. An onboarding queue that processes a handful of new vendors a week is exactly the workload Interactive's 25-rows-per-session capacity is sized for.

The second cadence is the pre-1099 Bulk sweep. The active-vendor master gets validated as a single Bulk submission at the start of the firm's pre-1099 review window, which for most firms means early-to-mid December. The 1099-NEC deadline to recipients and to the IRS is January 31, and 1099-MISC has its own filing schedule; both leave a narrow window between "we know there is a mismatch" and "the corrected W-9 has to be in hand." Running Bulk in early December rather than mid-January is the difference between resolving a code 2 or code 3 mismatch in a 30-day window with the vendor and discovering it the week the forms are due. A firm that is also running an annual W-9 collection refresh — many do — will find that the pre-1099 Bulk sweep is the natural validation step that caps the annual vendor master W-9 refresh cycle, turning a refresh project from "we collected new W-9s" into "we collected new W-9s and validated them against IRS records."

The third cadence is on-demand, triggered by vendor-side events. A vendor reports a name change after an entity reorganization. A vendor's TIN changes because the firm restructured from a sole prop to an LLC. A vendor sends a corrected W-9 in response to a query. Each of these is a one-off Interactive run on the affected vendor, immediately, before the next payment goes out. A vendor master that does not get re-checked when its underlying entities change drifts out of sync with IRS records over time, which is exactly the failure mode CP2100 notices catch a year later.

Free IRS TIN matching for vendors is, on the IRS side, genuinely free — there is no per-check fee and no e-Services subscription. The cost of the in-house path is staff time, in two places: the Principal's enrollment time at the start (one-off, a few hours over a few days for the application and ID.me) and the Authorized User's ongoing time (a few minutes per Interactive run at onboarding, plus a few hours per Bulk submission for file preparation, upload, and response review). The wrapper-service alternative — Tax1099, Track1099, TINCheck, Sovos, eFileMyForms, and others compete in this slot — bundles the IRS submission, the file format handling, and (in some cases) the W-9 collection itself into a paid service charged either per check or as a subscription that bakes in a TIN-matching allowance.

The breakeven turns on the firm's own monthly check volume and its own staff cost. The inputs to use:

• The wrapper's per-check rate (or its subscription tier divided by the volume it covers).
• The Authorized User's loaded hourly cost.
• Time per Bulk submission — typically under an hour for a clean run on a few hundred vendors once the W-9 extraction process is working.
• Time per Interactive check at onboarding, multiplied by onboarding volume.

A firm running a few hundred vendor checks a year with a working W-9 extraction process almost always finds the in-house path cheaper than per-check wrapper pricing; the same is true at a few thousand. A firm running a handful — say 20 to 30 checks annually — may find the wrapper's per-check fee lower than the friction of standing up the in-house process. There is no universal answer, but the inputs above produce a defensible one.

What TIN Matching does not catch, and the CP2100 boundary

TIN Matching answers exactly one question: does the IRS have the submitted name and TIN combination on its records? Treat the service as a records-match check, not a vendor-quality check. The temptation, especially after enrolling and running the first few clean matches, is to start treating "we ran TIN matching" as shorthand for "this vendor is fine." It is not, and over-claiming the control to a controller, an auditor, or yourself is the error to avoid here.

What TIN matching does not catch, explicitly:

• It does not validate that the vendor is currently active or in good standing with their state of incorporation. A vendor whose corporate registration has lapsed will still match on EIN and name if the IRS records have not yet been updated.
• It does not confirm the vendor's address is current. A code 0 match tells you nothing about whether the address on the W-9 still belongs to the vendor.
• It does not screen against OFAC, the SDN list, or any sanctions framework. Sanctions screening is a separate control with its own data sources and its own legal exposure if skipped.
• It does not flag fraud risk, shell-company patterns, common-address-with-employee anomalies, or duplicate-vendor issues. A clean TIN match on a fraudulent vendor is still a clean TIN match.

Each of those is a separate control layer with its own tooling, cadence, and audit expectations. TIN matching adds the IRS-records check to the onboarding stack; it does not replace anything else already in it. A vendor master governance routine that runs TIN matching but stops doing the other onboarding controls is weaker than one that runs TIN matching alongside them.

The other boundary worth naming is CP2100. TIN matching is the prevention step, and CP2100 / B-Notice handling is the remediation step that fires when prevention misses something or was not run. The IRS issues CP2100 and CP2100A notices to payers whose filed information returns contain mismatched name/TIN combinations — typically months after the filing window has closed and reconciliation against IRS records has run. The remediation workflow has its own discipline (B-Notice solicitation of a corrected W-9 from the vendor, second-notice procedures if the first is ignored, the 24% backup-withholding obligation in the meantime), and it is a separate piece of work from the prevention covered here.

A firm running TIN matching well sees fewer CP2100 notices but rarely zero — vendors change entities, W-9s collected before TIN matching was rolled in stay in the master, and code 2 or code 3 vendors are sometimes slow to send a corrected W-9. Both workflows sit inside the broader 1099 lifecycle the 1099 vendor invoice tracking guide frames end-to-end.