For an enterprise, filing 1099s through IRIS is less a tax task than an integration task: someone has to pull payment data out of the ERP, shape it into the IRS XML schema, authenticate to the Application-to-Application channel with a pair of signed tokens, submit, and then poll for an asynchronous acknowledgement that may come back clean, accepted-with-errors, or rejected. Building that yourself is entirely possible and this guide walks through it honestly — the OAuth flow, the throughput limits, the security obligations, and the corrections pipeline you will own for years afterward. The deciding question is rarely “can we build it,” but “is owning an IRS integration the best use of the team that could be shipping product.” If the season is close and the answer is no, a provider that already holds a production TCC and has cleared IRS testing can file under your data today.
In this story
What “IRIS A2A” Actually Is to an Engineering Team
IRIS, the IRS Information Returns Intake System, offers two ways in: a browser-based Taxpayer Portal where a person uploads files by hand, and the Application-to-Application channel, known as A2A, where one of your services talks directly to an IRS API. For anyone filing at enterprise scale, A2A is the only path that makes sense — but it is a system integration, not a form, and it should be scoped like one.
The mental model that trips teams up is treating IRIS like a file drop. It is not. A2A is a request/response API with its own authentication scheme, its own document schema, and an asynchronous acknowledgement model: you submit a transmission, IRS returns a Receipt ID immediately to confirm intake, and then — minutes or hours later — you poll a separate status endpoint to learn whether each form inside that transmission was accepted, accepted with errors, or rejected. That two-phase shape means your integration is never “fire and forget.” It needs durable state, a poller, and a place to land results, exactly like any other partner API you operate.
There is also a registration gate in front of all of this. Before a single production submission, your organization needs an IRIS Transmitter Control Code tied to the EIN that will transmit, an approved e-Services Client ID for the A2A OAuth flow, and a pass through IRS Assurance Testing — the sandbox where the IRS confirms your XML and your transport actually conform before they let you near production. If your team has never registered, budget for that lead time before any code ships; the full walkthrough lives in our guide to getting an IRIS TCC.
The A2A channel, its endpoints, the 100 MB transmission cap, and the Receipt ID / UTID response values are defined in IRS Publication 5718 (IRIS A2A Implementation and User Guide). The OAuth authorization model is specified in the IRS e-Services API Authorization User Guide. The Taxpayer Portal is documented separately in Publication 5717.
Buy vs. Build: The Decision Before the Architecture Decision
It is tempting to start sketching the integration before anyone has asked whether it should exist. Resist that. An IRS filing pipeline is not a feature you ship once and forget; it is a system you keep current with annual schema changes, re-test when the IRS publishes a new version, secure to financial-data standards, and staff every January when the volume and the stakes peak. The honest comparison is not “a sprint of work” versus “a subscription.” It is a multi-year operational commitment versus an outsourced one.
| Dimension | Build it in-house | Buy a filing provider |
|---|---|---|
| Up-front work | OAuth client, XML generator, poller, corrections flow, ATS testing | Map your export to an import format |
| Schema upkeep | You re-implement and re-test every IRS version bump | Vendor absorbs schema and rule changes |
| Registration | Your EIN’s own TCC + Client ID + ATS pass before season | File under a provider that already holds a production TCC |
| Security scope | You own the WISP, encryption, mTLS, and audit trail | Provider carries the safeguards obligations for the channel |
| Right fit when | Filing is core to your product, or volume is enormous | Filing is a once-a-year obligation, not a product |
The highlighted row is the one teams underestimate most. Your existing FIRE credentials do not carry over — IRIS requires its own Transmitter Control Code, and the suitability and testing steps behind it have real lead time. If you decide to build, that registration has to start months before your first production transmission, not in the week you planned to go live. Building is the right call when filing is genuinely part of what your company sells — a payroll platform, a marketplace, a payments processor — because then the integration is product. For everyone else, the same engineers are almost always worth more pointed at the roadmap.
Getting Data Out of the ERP and Into the Schema
Most of the real work in a build is not the IRS API at all — it is the mapping layer between your source of truth and the IRS schema. Payment data lives in your ERP, your accounts-payable system, or a data warehouse, keyed the way your business thinks, and IRIS wants it shaped the way the tax form thinks. Reconciling those two worldviews is where most of the engineering hours go, and where most of the rejections are born.
The IRIS XML document is a three-level hierarchy, and understanding it shapes how you batch. At the top is the Transmission, a manifest carrying your TCC, your Software ID, and the schema version. Inside it sit one or more Submission Groups, each pinned to a single payer, tax year, form type, and submission type. Inside each group are the individual forms. Because a submission group cannot mix tax years or form types, your batching logic has to partition records along exactly those seams before it ever serializes a byte.
Transmission (manifest: TCC, SoftwareId, VersionNum)
├── Submission Group (Payer A · TY2026 · 1099-NEC · Original)
│ ├── Form 1099-NEC
│ ├── Form 1099-NEC
│ └── Form 1099-NEC
└── Submission Group (Payer A · TY2026 · 1099-MISC · Original)
├── Form 1099-MISC
└── Form 1099-MISCTwo encoding rules quietly account for a surprising share of first-attempt failures, so bake them into the generator rather than discovering them at the gateway. First, IRIS accepts only UTF-8 without a byte-order mark; UTF-16 and UTF-32 are rejected outright, which in .NET means serializing with a UTF8Encoding constructed to suppress the BOM. Second, person-name fields are stricter than business fields: PersonFirstNm, PersonMiddleNm, and PersonLastNm accept only letters and the hyphen, so a payee named O’Malley is transmitted as OMalley — the apostrophe is stripped, not escaped. A double dash anywhere in the data will reject the whole transmission, so normalize those out in mapping too.
Authentication, Throughput, and the Limits That Govern Your Schedule
A2A authentication is OAuth, but a specific and slightly unusual flavor of it. Rather than a static API key, your service mints two signed JSON Web Tokens for the JWT-bearer grant — a Client JWT whose subject is your registered Client ID, and a User JWT whose subject is the consenting user’s ID — and exchanges them for an access token. Both must be signed with the registered key, and the access token the IRS hands back is short-lived: it expires after 15 minutes, with a refresh token to obtain the next one. Any long-running batch job therefore needs token refresh built in from the start, because a single large filing run will outlive the token that began it.
Throughput is shaped by two hard ceilings you have to design around. Each transmission payload is capped at 100 MB, which for high-volume filers means your batching service has to split a season’s worth of records into many transmissions rather than one heroic upload. And the e-Services gateway enforces a request consumption limit: exceed it and you receive an HTTP 429 with the message that a 10-minute blackout is now in effect. A naive tight-loop poller will trip this and lock itself out for ten minutes at the worst possible time, so your status checks need backoff and your submission cadence needs a rate limiter.
Because acknowledgements are asynchronous, the easy mistake is to ship a fast submission path and bolt on status polling later. Do it the other way around. A poller that respects the 10-minute blackout, refreshes the 15-minute token, and persists every Receipt ID and UTID is what turns a pile of submissions into a defensible filing record — and it is the piece teams most often under-build until it bites them in production.
Whatever you persist, persist the identifiers. Every successful submission returns a Receipt ID and a Unique Transmission ID (UTID); the UTID is the reliable handle for re-querying status if a Receipt ID is ever lost, and both belong in durable storage the moment the gateway returns them. This is the same A2A surface our IRIS A2A API integration guide covers endpoint by endpoint if you want the request-level detail.
Weighing the build against the calendar?
See how a managed IRIS A2A connection handles the OAuth, the throughput limits, and the acknowledgement polling so your team doesn’t have to own them.
Security and Audit: The Obligations That Outlast the Code
The data flowing through this pipeline is exactly the data your security program exists to protect: taxpayer identification numbers, names, addresses, and dollar amounts, at scale. The moment your enterprise files information returns it falls squarely under the IRS guidance for safeguarding taxpayer data, which expects a written information security plan, encryption of that data at rest and in transit, and access controls around it. An IRIS integration is not a side project that escapes those rules; it is one of the most sensitive data flows you operate.
Transport security is non-negotiable on the IRS side: A2A endpoints are HTTPS only, and the channel uses mutual TLS, so your client certificate management becomes part of the integration rather than an afterthought. On your side, the longer-tail obligation is retention and auditability. Filed returns and their acknowledgements must be retained for four years, which means your pipeline needs to archive the exact transmitted XML, its content hash, and the IRS acknowledgement for every submission — an append-only record you can produce on demand if the IRS ever questions a filing. That archive is not optional plumbing; it is the evidence behind any penalty defense.
The obligation to safeguard taxpayer data — written security plan, encryption, and access controls — is set out in IRS Publication 4557 (Safeguarding Taxpayer Data). A2A transport, certificate, and retention requirements are in Publication 5718.
The Corrections Pipeline You Will Run Every Year
A filing system is only half-built if it can submit but cannot correct. In practice a meaningful slice of every season’s returns will need fixing — a wrong amount, a wrong TIN, a duplicated record — and IRIS treats corrections as first-class submissions with their own rules. Some fixes are a single replacement record; others, such as a wrong TIN or wrong name, require a void of the original followed by a fresh record. Your pipeline has to classify which kind a given change is, reference the original submission so the IRS can link them, and never mix originals and corrections in the same submission.
This is where the asynchronous, stateful nature of A2A pays off or punishes you. To correct a return you need its original Receipt ID and submission identifiers on hand, which is exactly why persisting them at submission time matters so much. A correction that cannot point back at its original is one the IRS will reject, and a rejected return cannot itself be corrected — it has to be fixed and resubmitted as a new original. Designing that lineage in from the start is far cheaper than retrofitting it mid-season.
Common Rejection Reasons (and How to Avoid Them)
Most enterprise rejections are not exotic — they cluster around registration mismatches, environment mistakes, and the encoding rules above. Each one below maps to a real IRS business rule, and each is cheaper to prevent in your generator than to debug after the gateway turns a transmission away.
Cause: the TransmitterControlCd in your manifest does not match a TCC on record for the transmitting EIN, or the TCC inside the UTID disagrees with the manifest TCC — rule TMFST002_001 and TMFST039. This usually means a config value was copied wrong or a test TCC leaked into a production build. Fix: source the TCC from a single configuration value used for both the manifest and the UTID, and gate production behind a check that the active TCC is the production one.
Cause: your SoftwareId is missing from the IRS database, is not marked Production, or its first two digits don’t match the last two of the tax year — rules TMFST018, TMFST019, and TMFST020. Software-developer filers must also have passed testing for that form type and year (SMF031). Fix: register and test a Software ID per tax year, confirm its production status before season, and pull the right one per form type from config rather than hard-coding.
Cause: you transmitted a form type your TCC is not authorized to file — rule SMF029 — or the submission’s tax year does not match the manifest’s (SMF007). Both are classic batching bugs where records were grouped along the wrong seam. Fix: partition submission groups strictly by payer, tax year, form type, and submission type, and validate each group’s form type against your TCC’s authorized list before serializing.
Cause: an issuer’s TIN and name pair fails the IRS database check — rules SMF017 and SMF018 — or a payee TIN is malformed. At enterprise scale these multiply quickly and each carries real penalty exposure. Fix: run TIN matching against your recipient roster well before season, resolve mismatches with the payee, and treat the IRS database result as the source of truth your export must reconcile to.
Cause: a byte-order mark on the XML, a double dash in an address, or an apostrophe in a person-name field — any of which the schema rejects regardless of how clean your data looks in the source system. Fix: serialize as UTF-8 without a BOM, strip double dashes everywhere, and restrict person-name fields to letters and hyphens in the mapping layer, not at the end.
Skip the Integration Build: The e1099f Advantage
Already connected
A production TCC and ATS-cleared A2A connection are in place, so there is no OAuth, no certificate, and no testing cycle for your team to own.
Your export, our schema
Map your ERP or warehouse export once; the IRIS XML, batching, and encoding rules are generated and validated for you.
Acks and corrections handled
Receipt IDs, UTIDs, asynchronous acknowledgements, and the corrections lineage are tracked end to end.
An integration your team doesn’t have to maintain through every annual schema change.
Frequently Asked Questions
Can we reuse our existing FIRE credentials for IRIS A2A?
How long can a single IRIS transmission be?
How long does an A2A access token last?
What is the 429 blackout, and how do we avoid it?
Is IRIS acknowledgement synchronous?
Why does authentication need two JWTs?
What character-encoding rules cause rejections?
How do corrections work for an enterprise filer?
What security obligations come with filing at scale?
How far ahead do we need to start if we build in-house?
Does e1099f remove the need to understand any of this?
Not tax advice. This is general information about IRS procedures and integration patterns that may change as the IRS updates IRIS; the published IRS materials are authoritative. Consult a tax professional for your organization’s situation.