Quick Answer: Every 1099 you file is decided by four fields — the vendor's name and taxpayer identification number, their tax classification, the type of each payment, and the year-to-date reportable total across every payment rail. None of the four is a tax problem. All four are captured, or lost, inside ordinary AP work months before anyone opens a filing tool. Fix them at vendor onboarding and at payment coding, and January is a filing event. Leave them until December and January is an investigation. The window that decides which one you get closes in October.

The date that matters is not January 31

January 31 is the deadline. It is not the date that decides the outcome.

By the time you reach it, every fact the forms depend on is already fixed. The W-9 you did not collect in March is now a request to a vendor with no reason to answer. The contractor coded as a corporation in the vendor master because someone read "Ltd" in a trading name has been coded that way for ten months. The card-paid consultant who never entered the AP system is still invisible.

The teams who file in the first week of January are not the ones with better filing software. They are the ones for whom filing is a report over data that was already correct. Everything below is about getting to that position from where you are in September.

The four fields that decide a 1099

Strip away the form types and boxes, and every 1099 outcome is a function of four values. Each one is captured at a different moment, breaks in a different way, and is caught by a different control.

Field	What it decides	Where it breaks	The control that catches it
Name and TIN	Whether the form can be filed at all	Collected after the first payment, when the vendor no longer needs you	Hard payment block at onboarding, plus real-time TIN matching
Tax classification	Whether a form is required, and which carve-out applies	Inferred from the trading name rather than read from the W-9	Structured entity type captured from the form, not a free-text note
Payment type	Which form and which box	GL coding done for the P&L, which does not map cleanly to 1099 boxes	A GL-account-to-box mapping applied at payment time
Reportable total	Whether the threshold is crossed	Card and bank rails never aggregate against one vendor	One reportable total per TIN, across every rail

Name and TIN: collect it while they still want something from you

The single highest-leverage control in the whole process is refusing to release the first payment until a W-9 is on file.

This is not because collecting later is impossible. It is because the response rate collapses. A vendor waiting on their first invoice answers a W-9 request the same day. The same vendor in December, paid in full, with your email sitting under a hundred others, answers eventually or not at all. You already know this from your own December.

The control is a hard block in the AP system, not a policy in someone's memory, and not a soft warning an AP clerk can click past under month-end pressure. Pair it with TIN matching at onboarding: the IRS name and TIN combination either matches or it does not, and finding out on the day you create the vendor costs a phone call. Finding out via a B-notice eighteen months later costs a correction, a re-filing, and backup withholding of 24% on everything you pay that vendor until it is resolved.

Collect on every vendor, regardless of what you expect to pay them. Anticipated-amount gating was always fragile; with a threshold that moves it is worse. See vendor master data management for how the TIN and address fields should be structured once you have them.

Tax classification: read the form, do not read the name

A 1099 is generally not required for a corporation, with the well-known exception of legal and medical services. That carve-out is not the part that catches teams out. What catches them out is that the classification in the vendor master was never taken from the W-9 at all.

Someone typed the vendor name, saw "Ltd" or "Inc" or "Group" in it, and set the entity type accordingly. A single-member LLC trading under a company-sounding name is taxed as an individual and is reportable. A sole proprietor operating as "Northfield Consulting Group" looks incorporated in every screen you will ever see them in.

The control is that entity type is a structured field populated from the W-9, and nothing else can populate it. Not the AP clerk's judgement, not the vendor's letterhead, not a spreadsheet import. If your vendor master allows entity type to be set without a W-9 attached, that is the gap, and it is worth an afternoon to close before October.

Payment type: your GL was not designed for this

Payment classification is the field that fails quietly, because nothing about it looks wrong until the totals are compared.

Your general ledger accounts exist to produce a P&L. The 1099 boxes exist to describe income to a recipient. The two overlap without agreeing. Non-employee compensation, rent, other income and gross proceeds to an attorney are four different destinations, and a single vendor can generate payments into more than one of them in the same year.

Two specific errors account for most of the damage. Reimbursed expenses paid to a contractor are generally not reportable — they return out-of-pocket costs rather than paying for services — but a system that treats every payment to a contractor as services will inflate the reportable total. And card-paid spend often carries no useful coding at all, because it was reconciled against a statement rather than an invoice.

The control is a mapping from GL account and expense category to form and box, applied when the payment is coded rather than reconstructed in January. The practical test of whether you have it: can you produce today's year-to-date reportable total for any vendor, in under a minute, without opening a spreadsheet?

Reportable total: aggregate by TIN, not by vendor record

The threshold is per calendar year, per taxpayer, across payment methods. Note what that sentence does not say. It does not say per vendor record, and it does not say per system.

A contractor paid partly through AP and partly on a corporate card crosses the threshold on the combined figure. If your 1099 workflow only sees invoices processed through AP, the card spend is invisible and you under-report. The fix is either to route all contractor payments through AP, which is cleaner and slower to implement, or to reconcile card statements against the reportable vendor list monthly, which is faster and needs someone to own it.

The aggregation key is the TIN. That is the point of the next section.

Two failures a threshold check will not catch

Both of these pass every automated threshold report, because the report is asking the wrong question.

One vendor, two records. The same contractor was set up twice: once as "J. Alvarez" when they invoiced the marketing team, once as "Alvarez Design" when procurement raised a PO. Each record shows payments under the threshold. The taxpayer behind both is over it. Nothing in a per-record threshold report will ever surface this, because each record is individually compliant.

The detection is a duplicate scan on the TIN, not on the vendor name, run against the vendor master rather than against the payment file. Where the TIN is missing on one of the records — which is usually why the duplicate was created — the fallback is a match on bank account details, then on address. Run it in October, when there is still time to merge records and chase the missing W-9. The wider case for this kind of periodic vendor-file review is in the vendor risk assessment checklist.

One vendor, two classifications. A sole proprietor incorporates in June. Payments made in the first half of the year are reportable; payments after the change may not be. Most vendor masters hold entity type as a single current value with no effective date, so the moment you update the record, the first half of the year is retrospectively described by the new classification and the reportable total is wrong.

The control is that entity type changes are versioned with an effective date, and the reportable total is computed against the classification in force at the time of each payment. If your system cannot do that, the manual equivalent is a log of every mid-year classification change, reviewed in November against payments made before the change date. It is a short list in most companies, and it is the kind of error that produces a form nobody can explain.

What the $2,000 threshold changed, and what it did not

The 1099-NEC and 1099-MISC reporting threshold is $2,000 for payments made in calendar year 2026, up from $600, and it is indexed to inflation from 2027.

It changes filing volume. A team that issued 400 forms last year on the old threshold might issue a fraction of that. It changes nothing at all about the four fields above, because the work per vendor is identical and only the last step — generating and transmitting forms — scales with count.

Three things follow, and they are all in the direction of more care rather than less:

Do not use the threshold to gate W-9 collection. A vendor under it this year can cross it next year, and you will not know in advance which. Collect on every vendor at first payment.
Find every hard-coded $600 in your stack. In AP software this is a configuration change. In a spreadsheet-based process it is a search-and-replace across files that other files reference.
Do not hard-code $2,000 either. It moves from 2027. A system that reads the current threshold from a maintained reference will keep working; one with a number typed into a formula will under-file quietly, which is the worst kind of failure because nothing alerts.

What to do between now and January

The window is open and it is not open indefinitely. Everything here assumes you are reading this in September.

When	What to do	What it costs to skip
September	Payment block on missing W-9 live for new vendors. GL-to-box mapping in production so every new payment is classified as it is coded.	Every vendor onboarded from here is another January phone call
October	Backfill. Pull vendors with year-to-date payments over $1,500, check W-9 status, run the TIN duplicate scan, chase the gaps.	Vendors still respond in October. In December they are on holiday
November	Dry run. Generate draft forms from year-to-date data and have the AP team review a sample against the source documents. Reconcile card spend against the reportable list.	You discover the classification errors during the real run
December	Freeze. Confirm recipient addresses, log any mid-year classification changes, stop making structural changes to the mapping.	Late changes are the ones nobody tests
January	File. Nothing here should be a surprise.	—

The October step is the one most often skipped and the one that pays for the rest. It is also the only step where the cost of a gap is a phone call rather than a correction.

What automation can enforce, and what stays a judgement call

Be clear-eyed about the split, because vendors will not draw it for you.

A system can enforce: the payment block on a missing W-9; TIN matching at onboarding; the GL-account-to-box mapping at payment time; aggregation of reportable totals by TIN across every rail; the current threshold value; duplicate detection on TIN, bank details and address; and effective-dated classification history.

A person still decides: whether a specific payment is a reimbursement or a fee; whether the legal and medical carve-out applies to a particular corporate vendor; whether two records with different TINs are genuinely the same taxpayer or a legitimate restructure; and how to treat a payment that spans a mid-year classification change. These are not gaps in the software. They are questions where the answer depends on facts that are not in the payment record, and a tool that answers them confidently is guessing.

Automation is worth buying for the first list. Assume the second list stays on your desk, and staff for it.

What to ask a 1099 automation vendor

Does it block payment on a missing W-9 — a hard block, not a warning an AP clerk can dismiss?
Does it validate the name and TIN pair against the IRS at onboarding, in real time?
Does it aggregate reportable totals by TIN across AP, card and bank rails, or only across invoices it processed?
Does it detect duplicate vendors on TIN, bank account and address, not on name?
Does it hold entity type with an effective date, so a mid-year change does not rewrite the year?
Does it map GL accounts to form and box automatically at payment time?
Does it file electronically and handle corrections and B-notices, including the re-filing path?
Does it read the threshold from a maintained reference rather than a configured number?

Questions three, four and five are the ones that separate tools built for the filing event from tools built for the year. Most demos will cover one, six and seven well.

FAQ

When should I start preparing for 1099 filing?

September, if you want a clean January. The onboarding controls only affect vendors created after you switch them on, so every week of delay is another cohort of vendors whose W-9 you will be chasing in December. The backfill and TIN duplicate scan belong in October, while vendors still respond.

What is the 1099 threshold for 2026?

$2,000 for both 1099-NEC and 1099-MISC on payments made in calendar year 2026, up from $600, indexed to inflation from 2027. Treat the number as a variable in your systems rather than a constant, because it will move again.

Do I still need W-9s from vendors paid under the threshold?

Yes, as a matter of practice. You cannot know in advance which under-threshold vendor will cross it, and the response rate for a W-9 request collapses once the vendor has been paid. Collecting on every vendor at first payment also catches name and TIN mismatches early, which is where the expensive errors start.

How do corporate card payments affect 1099 reporting?

They count toward the threshold whenever the vendor is otherwise reportable, and they are the most common source of under-reporting because card spend usually sits outside the AP workflow. Either route contractor payments through AP, or reconcile card statements against the reportable vendor list every month. Doing it once in January does not work, because the coding needed to classify the spend is no longer in anyone's head.

Why did a vendor under the threshold still trigger a problem?

Almost always one of two reasons: the same taxpayer exists twice in the vendor master under two names, so each record looks compliant while the taxpayer is over; or the entity classification changed mid-year and the total was computed against the current value rather than the one in force at the time of payment. Both pass a standard threshold report.

1099 Vendor Reporting Automation: The Data You Need in the File, and When to Fix It