Payroll and HRIS platforms file information returns the way no single business ever does: many payers, one transmission pipeline, every January at once. On the IRS Information Returns Intake System (IRIS) that scale is an advantage only if you get the structure right — you transmit under your own Transmitter Control Code (TCC), you nest each client as a separate Issuer inside the manifest, and you elect Combined Federal/State Filing on the first submission or not at all. This guide walks the IRS-direct path end to end, then shows where the edges cut. If your platform isn’t already wired into IRIS A2A, a provider that holds a production TCC can transmit on your behalf this season instead of next.
In this story
Why Filing as a Payroll Platform Is a Different Problem
A small business files its handful of 1099-NECs and is done. A payroll or HRIS provider files for hundreds or thousands of employers in a single window, and that changes the shape of the problem entirely — not the math, but the orchestration.
When you file for one company, you are both the business that paid the contractor and the entity transmitting the return to the IRS. When you file as a platform, those two roles split apart. You are the transmitter — the party sending data to IRIS over a secure channel — while each of your clients is a payer, the business that actually made the reportable payments. IRIS calls that payer an Issuer, and it expects every Issuer to be named explicitly inside the transmission you send. Getting this relationship modeled correctly is the difference between a clean Receipt ID and a rejected batch, and almost every payroll-specific gotcha in this guide traces back to it.
The second thing that changes is volume. IRIS offers two channels: a web Taxpayer Portal for manual or modest CSV uploads, and the Application-to-Application (A2A) interface for software that submits programmatically. The portal is fine for a bookkeeper filing a dozen forms; it is not how a platform moves tens of thousands of returns. A2A lets your system authenticate, transmit an XML payload, and poll for an acknowledgement without a human in the loop, with a payload ceiling of 100 MB per submission — large, but a real boundary you will plan batches around at scale. The A2A channel is documented in IRS Publication 5718, and the deeper mechanics of authenticating and transmitting over A2A are worth reading once before you build.
The A2A channel, transmission structure, payload limits, and acknowledgement flow described here come from IRS Publication 5718 (IRIS A2A). The web channel and CSV upload live in Publication 5717. Apply for access through IRS e-Services. These IRS publications are the authoritative sources; this guide is a plain-English summary of them.
The TCC Role That Quietly Governs Everything
Before you can send anything, you need a Transmitter Control Code — a five-character identifier the IRS issues after you complete the IR Application for TCC. For a payroll platform, the single most consequential choice in that application is the role you request, because IRIS enforces a hard rule about who is allowed to file for whom. The role you pick is not cosmetic; it is wired into the business rules that validate every transmission you ever send.
IRIS recognizes a constraint that catches well-meaning platforms off guard: when a TCC carries the Issuer role, the system requires that the Issuer’s taxpayer identification number inside the return match the transmitter’s own TIN. In plain terms, an Issuer-role TCC can only file for itself. That is exactly wrong for a payroll provider, whose entire purpose is to file for other people’s companies whose TINs are, by definition, not yours. To file on behalf of clients you must hold a Transmitter-role TCC, which permits the Issuer TIN in each return to differ from the transmitter TIN in the manifest. Request the wrong role and you will pass testing while filing for yourself, then watch every client submission reject the moment the TINs diverge.
| If your TCC role is… | You may file for… | Right for a payroll/HRIS platform? |
|---|---|---|
| Issuer | Only your own company (Issuer TIN must equal your TCC’s TIN) | No — you can’t file for clients |
| Transmitter | Any payer, with each client named as a separate Issuer | Yes — this is the platform role |
Getting the TCC itself takes time you must budget for. The IR Application goes through a suitability review the IRS conducts on its own clock, and approval is not instant. If you are standing up filing for the first time this season, treat the application as the long pole and start it well before year-end. The full walkthrough of roles, responsible officials, and the review timeline lives in our companion guide on getting an IRIS TCC.
Many Payers, One Pipeline: How the Transmission Nests
The reason a payroll platform can file for a thousand employers in one run is that IRIS transmissions are built to hold many payers at once. Understanding the three-level nesting is the key to batching correctly.
Every A2A transmission is a three-level document. At the top sits the Transmission manifest, which carries your transmitter identity — your TCC, your IRS-assigned Software ID, the schema version, and a count of how many Issuers the transmission contains. Beneath the manifest you place one Submission per payer-and-form-type combination: one client’s 1099-NECs are one submission, that same client’s 1099-MISCs are another, and a second client’s 1099-NECs are a third. Inside each submission sit the individual form records — the recipients and dollar amounts. This nesting is what lets a single transmitted file represent your entire client base for a given form.
Transmission (manifest: your TCC, SoftwareId, IssuerFormCnt)
├── Submission — Client A, Form 1099-NEC
│ ├── IssuerDetail (Client A: name, EIN, phone)
│ ├── Form record — recipient 1
│ └── Form record — recipient 2 …
├── Submission — Client A, Form 1099-MISC
│ └── IssuerDetail (Client A) …
└── Submission — Client B, Form 1099-NEC
└── IssuerDetail (Client B) …Two counts have to be internally consistent or the IRS rejects the whole transmission before it ever looks at a dollar figure. The manifest declares how many Issuers it carries in TotalIssuerFormCnt, and a transmission-level rule rejects the file when that declared total does not equal the actual number of Issuers nested inside. Because a platform assembles these manifests by program rather than by hand, an off-by-one in your batching logic surfaces here, so the count is worth asserting on your side before you transmit.
Each client’s identity also has to survive the trip intact. IRIS validates the Issuer’s name and TIN against its own records: rule SMF018 requires the business name and TIN in IssuerDetail to match what the IRS has on file, and rule S1H001 requires a phone number in IssuerDetail to be present. For a platform, that means the client onboarding data you collected months ago — legal name exactly as registered, EIN, a working phone — is what gets graded in January. Clean payer data is not a nicety; it is a filing prerequisite.
Combined Federal/State Filing, Done in the Same Pass
Many of your clients owe the same 1099 data to a state as well as the IRS, and Combined Federal/State Filing (CF/SF) exists so you do not have to transmit twice. When a payer is enrolled and a form qualifies, electing CF/SF tells the IRS to forward the return to the participating state on the payer’s behalf. For a payroll platform serving employers across dozens of states, this is the feature that keeps year-end from multiplying into fifty separate state jobs.
CF/SF has exact preconditions, and IRIS checks each one. The election itself is set with CFSFElectionInd at the submission level, and rule S1H002 reports an error if you elect CF/SF under a TCC that does not participate in the program — so your TCC must be enrolled for CF/SF, not merely approved for filing. The form has to be eligible, too: per rule S1H003_001, CF/SF applies only to a defined list that includes 1099-NEC, 1099-MISC, 1099-INT, 1099-DIV, 1099-K, 1099-R and a handful of others. When you set a state at the form level with CFSFElectionStateCd, rule SHAREDIRFORM020 requires that the submission-level CFSFElectionInd also equals 1, and rule SHAREDIRFORM022 requires at least one TotalByStateGrp to be present carrying the state totals. Miss the totals group and the state half of your filing quietly fails its rule check.
The election is part of the original submission, not a follow-up step you can add once the federal copy is accepted. If a client’s return goes to the IRS without the CF/SF election in place, the state copy does not travel with it, and recovering means a separate state filing rather than a quiet re-flag. Decide each payer’s state obligations before you build the batch, and carry the election into the first transmission for that payer.
The Year-End Run, Step by Step
Once the TCC, the roles, and the data model are sorted, the season itself is a repeatable loop. Here is the IRS-direct workflow a platform runs for each batch — the same shape whether you are sending one client or a thousand.
Authenticate over A2A
Your system signs a JWT and exchanges it for an access token at the IRS OAuth gateway, then sends that bearer token on every call. The token is short-lived, so a long batch run refreshes it rather than reusing a stale one.
per sessionAssemble the transmission
Build the manifest under your Transmitter TCC and Software ID, then nest one submission per payer-and-form-type, each with its IssuerDetail and form records. Encode as UTF-8 without a byte-order mark — IRIS rejects UTF-16 and UTF-32 outright.
Transmit the payload
POST the XML to the IRIS intake endpoint as multipart form-data, one batch at a time within the 100 MB ceiling. A successful intake returns a Receipt ID and a Unique Transmission ID (UTID) — persist both, because the UTID is your only reliable way to recover a lost Receipt ID later.
secondsPoll for the acknowledgement
Intake acceptance is not acceptance of the data. You poll the status endpoint by UTID or Receipt ID, and the asynchronous acknowledgement tells you, per submission, whether each return was accepted, accepted with errors, or rejected.
minutes–hoursReconcile and correct
Map each acknowledgement back to the client it belongs to, surface rejects to the right account, and queue corrections. At platform scale this reconciliation step — not the transmit — is where the real engineering lives.
ongoingA subtlety worth flagging: IRIS responds at two moments, and they mean different things. The first response is intake — an HTTP result that either hands you a Receipt ID or refuses the transmission with a 400 before any return is saved. The second is the acknowledgement, which arrives later and judges the data itself. A 400 at intake means nothing was stored and you resend the corrected batch as an Original; a reject inside the acknowledgement means that specific return needs a correction. Treating those two as the same event is a common way to either double-file or lose a batch entirely.
Common Rejection Reasons (and How to Avoid Them)
At platform scale the same handful of failures account for most rejected returns, and nearly all of them are structural — the kind a program introduces in bulk, which is exactly why they are worth hard-coding guards against. Here are the ones that bite payroll and HRIS filers most.
Cause: the platform holds an Issuer-role TCC, so IRIS requires every Issuer TIN to equal the transmitter’s own TIN — and rejects the moment you file for a client whose EIN isn’t yours. Fix: apply for a Transmitter-role TCC, which allows the Issuer TIN in each return to differ from the transmitter TIN, and verify the role on the IR Application before testing.
Cause: the TotalIssuerFormCnt declared in the manifest does not equal the number of Issuers actually nested in the transmission, usually from an off-by-one in batch assembly, which a transmission-level rule rejects before any return is read. Fix: compute the count from the same collection you serialize, and assert the two are equal before you transmit rather than trusting a separately maintained tally.
Cause: a client’s business name and EIN in IssuerDetail don’t match what the IRS has on file — a trailing “LLC,” a DBA used instead of the legal name, or a transposed digit. Fix: capture each payer’s legal name exactly as registered with the IRS at onboarding, and TIN-match clients before season rather than discovering mismatches in the acknowledgement.
Cause: a form carries a CFSFElectionStateCd but the submission-level CFSFElectionInd isn’t set to 1, or no TotalByStateGrp is present (SHAREDIRFORM022) — so the state half never validates. Fix: set the election at the submission level and emit the state totals group whenever any record names a state, and resolve each payer’s state elections before building the first batch.
Cause: a payer or recipient field contains a double dash (--) — common in address lines like “Suite 4--Building B” — which IRIS forbids anywhere in data and rejects the transmission over. Fix: normalize a double dash to a single dash on the way out, and XML-escape &, ', <, and " while you’re at it, per the Pub 5718 character rules.
Embedding Filing Without Building the Pipeline
Everything above is buildable in-house, and plenty of platforms do build it. But the work doesn’t end at a working transmit call — you own the ATS testing to get to production, the schema and business-rule updates the IRS ships each year, the token lifecycle, the reconciliation of asynchronous acknowledgements back to client accounts, and the corrections pipeline when a state or recipient flags an error. For a team whose product is payroll, not tax transmission, that is a standing maintenance burden every season.
Want IRIS filing inside your platform without building A2A yourself?
e1099f handles the TCC, the multi-payer XML, CF/SF, and the acknowledgement loop — so your year-end ships on someone else’s production connection.
Skip the Integration: The e1099f Advantage
Multi-payer by design
Each client nests as its own Issuer under one transmission, with the counts and TINs validated for you before submit.
CF/SF on the first pass
State elections are set on the original submission with the totals group emitted, so the state half never falls off.
Production TCC, ready now
File on an already-approved Transmitter connection instead of waiting out a suitability review this season.
Acknowledgements mapped back to the right client — a Receipt ID per payer, not a rule code to decode.
Frequently Asked Questions
Can our platform file for clients under our own TCC?
Do we need a separate TCC for each client?
IssuerDetail for that payer.How many payers can go in one transmission?
TotalIssuerFormCnt must match the actual number of Issuers nested, or a transmission-level rule rejects the file.What is the difference between intake and an acknowledgement?
Can we add Combined Federal/State Filing after we’ve filed federally?
Which forms qualify for CF/SF?
S1H003_001, the eligible list includes 1099-NEC, 1099-MISC, 1099-INT, 1099-DIV, 1099-K, 1099-R, 1099-B, 1099-G, 1099-OID, 1099-PATR, and 5498. Your TCC must also be enrolled in the CF/SF program (rule S1H002).Why did a transmission reject with no return-level errors?
TotalIssuerFormCnt) that doesn’t match the actual count, a Software ID not registered for production, or a forbidden double dash (--) anywhere in the payload.How should we handle client data that doesn’t match IRS records?
SMF018 matches the payer’s business name and TIN against IRS records, so a DBA used in place of a legal name or a transposed EIN digit rejects. Capture the legal name as registered and TIN-match clients ahead of January.How long does it take to get a Transmitter TCC?
Does the IRS portal work for a payroll platform?
Does e1099f require our engineers to understand any of this?
What encoding does IRIS require for the XML?
&, ', <, and ".Not tax advice. This is general information about IRS IRIS procedures and may change as the IRS updates its schemas and business rules; the published IRS publications are authoritative. Consult a tax professional for your platform’s specific filing obligations.