If you are filing more than a few hundred information returns, the IRIS Taxpayer Portal will eventually run out of room: each uploaded CSV file is capped at 250 records for processing year 2026, so true high-volume work belongs on the Application-to-Application (A2A) channel, where a single XML transmission can carry up to 100 MB of forms. The trade is that A2A makes you the transmitter — you build the XML, sign every request, and read an asynchronous acknowledgement that reports status separately for the transmission, each submission, and each individual record. This guide walks the whole path the hard, correct way, directly with the IRS. If your deadline won’t wait, a provider that already holds an A2A TCC can file your batch today.
In this story
Where the Portal Ends and Bulk Filing Begins
Bulk filing is less a feature than a threshold. The IRIS Taxpayer Portal and the A2A channel both file the same 1099-series forms to the same system, but they are built for different volumes, and the moment your record count crosses a few hundred, the portal stops being the right tool.
The portal supports two ways to file: you can key forms in one at a time through the web interface, or you can download a template and upload a CSV file of form data. The CSV path feels like bulk filing, and for small payers it is — but Publication 5717, the IRIS Taxpayer Portal User Guide for processing year 2026, sets a firm ceiling on it. As of the 2026 guide, a single uploaded CSV file may contain a maximum of 250 records. There is no setting to raise that number; it is the design limit of the portal’s intake. A filer with 4,000 forms would have to split them into at least sixteen separate CSV uploads, each validated and submitted on its own, with no single confirmation tying them together.
The A2A channel exists precisely for the volume the portal can’t absorb. Instead of a web form, A2A is a machine-to-machine interface: your software builds an XML transmission, authenticates with a signed token, and POSTs the file directly to the IRS intake endpoint. Publication 5718, the IRIS A2A specification, caps a single transmission at 100 MB rather than a fixed record count — and because a 1099 record is small, that envelope holds tens of thousands of forms in one shot. For payroll providers, payment processors, and enterprise filers, A2A is not a convenience; it is the only channel that scales.
| Dimension | IRIS Taxpayer Portal (CSV) | IRIS A2A channel |
|---|---|---|
| Per-file / per-transmission limit | 250 records per CSV (Pub 5717, PY2026) | 100 MB per transmission (Pub 5718) |
| Interface | Browser upload or manual key-in | Signed API call (multipart/form-data) |
| Input format | IRS CSV template | IRIS XML you build and validate |
| Acknowledgement | On-screen, per upload | Asynchronous, machine-readable, per record |
| Best fit | Tens to a few hundred forms | Thousands to millions of forms |
The 250-record CSV ceiling is stated in the “What’s New for Processing Year 2026” summary of IRS Publication 5717, the IRIS Taxpayer Portal User Guide. The 100 MB per-transmission limit and the A2A intake mechanics are defined in IRS Publication 5718, the IRIS A2A specification. Both are the authoritative references for the figures in this post.
What a Bulk Transmission Actually Contains
Before you can batch thousands of forms, it helps to understand how IRIS expects them to be packaged, because the structure is what makes partial acceptance possible later. Publication 5718 describes a three-level hierarchy, and every level has a job. At the top sits the Transmission, a single XML document that opens with a manifest carrying your transmitter identity — your Transmitter Control Code and Software ID — along with the tax year and version information. Inside the transmission are one or more Submission Groups, each one a header that declares a form type and its transmittal data. Within each submission group sit the individual form records, one per recipient, and a transmission can carry many submissions and many thousands of those records at once.
Transmission (manifest)
├── transmitter info (TCC, SoftwareId)
├── VersionNum, VersionDt
└── Submission Groups (1+)
├── Submission Header (form type, transmittal elements)
└── Form records (1+ recipient forms per group)That nesting is the reason a bulk filing can succeed in part and fail in part. Because IRIS evaluates the transmission as a whole, then each submission, then each record, a single bad form does not have to sink the batch around it. The same structure also explains why the manifest counts matter so much: the transmitter has to tell IRIS, up front, exactly how many issuers and how many recipient forms the file contains, and those declared totals are checked against what the system actually finds. Get the count wrong and the entire transmission is rejected before any record is read.
IRIS accepts only UTF-8 without a byte-order mark; transmissions encoded as UTF-16 or UTF-32 are rejected outright. When you are generating one record by hand this rarely bites, but a bulk export pipeline that silently writes a BOM or the wrong encoding will fail every transmission it produces. Pin the encoding once, in the code that serializes the XML, rather than discovering it batch by batch.
Submit, Then Wait: The Asynchronous Acknowledgement
A2A filing happens in two phases, and the gap between them is where most bulk filers get tripped up. The first phase is intake: you POST the XML transmission as a multipart/form-data request with a single file part to the IRIS intake-acceptance endpoint. If the file is well-formed and within the 100 MB limit, IRIS responds almost immediately with a confirmation that the transmission was received.
That first response is not an acceptance of your data — it is a receipt. On success IRIS returns three values you must persist for every batch: a Receipt ID, the Unique Transmission ID (UTID), and a timestamp marking when IRIS received the transmission. The UTID is the durable handle for the whole batch, and for the A2A channel it always ends in the literal suffix :A, which the business rules verify. A subtle but expensive rule applies here: each transmission needs its own fresh UTID. Reusing a prior UTID makes IRIS return the earlier transmission’s result instead of processing your new one, so a bulk pipeline that recycles identifiers will appear to file and silently accomplish nothing.
Build and validate the XML transmission
Assemble the manifest, submission groups, and records into one UTF-8 document, and confirm the declared issuer and recipient counts match the actual records before you send anything.
build phasePOST to intake-acceptance
Send the file as a signed multipart/form-data request. A 200 response carries the Receipt ID and confirms the transmission was taken in; a 400 means it was turned away before any record was stored.
Persist the Receipt ID, UTID, and timestamp
Store all three immediately. The UTID is the only reliable way to recover a lost Receipt ID, and at bulk volume you cannot afford to lose the handle to a 30,000-form batch.
immediatePoll for the acknowledgement
Processing is asynchronous, so the verdict on your data arrives later. Query the status endpoint by Receipt ID or UTID and keep polling until the transmission reaches a terminal status rather than Processing.
The second phase is the acknowledgement, and it is where you learn whether your forms were actually accepted. You request status from the IRIS status endpoint, searching by either the Receipt ID or the UTID. A useful processing-year-2025 change made the UTID the better key: searching by UTID now returns the Receipt ID in the response, so a batch is recoverable even if the original receipt was lost. Acknowledgements do not arrive instantly — they typically lag the transmission by minutes to hours — so a bulk operation polls on an interval and treats Processing as “not done yet,” not as a problem.
Scaling past the portal’s 250-record wall?
e1099f files directly through IRIS A2A and scales to millions of records — XML, signing, manifest counts, and polling all handled, so you read a clean per-record result instead of building the pipeline yourself.
When 29,998 Forms Are Fine and Two Are Not
The single most important thing to understand about bulk filing is that “accepted” and “rejected” are not the only two outcomes. At scale, the normal result is somewhere in between, and the acknowledgement is built to tell you exactly where.
The IRIS acknowledgement reports status at three nested levels, mirroring the structure of the transmission you sent. The transmission as a whole gets a status; each submission within it gets its own status; and where something is wrong, the response drills down to the individual record, naming the error and even the element path that triggered it. This is what makes partial acceptance work: a transmission can be marked Partially Accepted while most submissions are clean and only a few records carry errors, so you fix and resubmit the handful that failed rather than re-sending the entire batch.
| Status value | Reported on | What it means for a bulk batch |
|---|---|---|
Accepted | Transmission / submission | Everything at that level cleared; nothing to resubmit. |
Accepted with Errors | Transmission / submission | Taken in, but some records carry reportable issues to review. |
Partially Accepted | Transmission | Some submissions cleared and some did not — fix only the failed ones. |
Rejected | Transmission / submission | Nothing at that level was accepted; correct and resend it. |
Processing | Transmission / submission | Not finished yet; keep polling, do not resubmit. |
Each failing record arrives with a small block of diagnostics: an error message code, the human-readable error text, the offending value, and the element path where the problem lives. At a volume of two or three forms you could eyeball these, but across thousands of records the only sane approach is to read the acknowledgement programmatically, match each error back to the recipient it belongs to, and queue exactly those records for correction. The structure is doing you a favor — it is telling you precisely which two forms out of thirty thousand to touch — but only if your process is built to listen to it record by record.
Common Rejection Reasons (and How to Avoid Them)
At bulk volume, the failures that hurt most are the transmission-level ones, because a single mistake in the manifest or the identifiers rejects the entire file before any of your thousands of clean records is even read. Each of these maps to a real IRIS business rule, and each is avoidable with a check that runs before you transmit.
Cause: the manifest’s TotalRecipientFormCnt does not equal the number of forms actually in the transmission, or TotalIssuerFormCnt does not match the issuer count — rules FTMFST009 and TMFST026, both of which reject the whole transmission. At scale this almost always comes from a counting bug in the export, not from the data itself. Fix: compute both totals from the records you are actually about to send, as the final step before serializing, so the declared count can never drift from reality.
Cause: two records or submissions share an identifier that IRIS requires to be unique within the transmission — a repeated SubmissionId (FTMFST010), a repeated UniqueRecordId (FTMFST008), or a repeated OriginalUniqueSubmissionId on a replacement (FTMFST007_001). Merging multiple source files into one batch is the usual culprit. Fix: generate identifiers from a single authoritative sequence during the build, and assert uniqueness across the assembled batch before transmitting.
Cause: a double dash (--) appearing anywhere in the data — for example in an address like NoPlaceWay--Suite 4 — rejects the transmission, because the sequence is forbidden in IRIS XML content. In a hand-keyed form it is rare; in a bulk export pulling messy address fields, it is almost guaranteed to appear eventually. Fix: sanitize the data on the way in, collapsing any double dash to a single dash before the value reaches the XML.
Cause: sending to production with a TCC that is still flagged for Test rejects the transmission (SVSR001), and the first two digits of the SoftwareId must match the last two digits of the tax year or the file is rejected (TMFST020). These are configuration mistakes, not data mistakes, which is exactly why they slip into a first production run. Fix: confirm the TCC has cleared Assurance Testing and is in Production status, and verify the Software ID and tax year line up, before the season’s first bulk transmission.
Skip Building the Pipeline: The e1099f Advantage
Batched for you
We assemble valid transmissions within the 100 MB envelope and compute every manifest count, so the file count never drifts from the data.
Per-record results
The asynchronous acknowledgement is parsed down to each record, so you see exactly which forms to fix — not a wall of raw XML.
Polling handled
We poll until each batch reaches a terminal status and surface partial acceptances cleanly, so nothing sits silently in Processing.
Thousands or millions of records — one batch, one clear result per form.
Frequently Asked Questions
What is the maximum number of forms I can file on the IRIS portal at once?
How many 1099s can one A2A transmission hold?
Do I need to split a large batch into multiple transmissions?
What does "Partially Accepted" mean in the acknowledgement?
Why didn't I get my acknowledgement right after submitting?
What's the difference between a Receipt ID and a UTID?
Can I reuse a UTID for a resubmission?
Why was my entire batch rejected when only a few records were bad?
How do I handle corrections on thousands of forms?
Does the portal CSV path support high volume if I just upload many files?
Do I need to understand any of this if I file through e1099f?
Not tax advice. This is general information about IRS IRIS procedures, which may change as the IRS updates the system; the published IRS publications are authoritative, and you should consult a tax professional for your specific situation.