IRIS TCC Application Roles: Build Your Access Roster

At the organization level, an Issuer transmits its own information returns, a Transmitter sends returns for businesses including others, and a Software Developer creates software that interfaces with IRIS A2A. The application does not allow Issuer and Transmitter to be selected together. Publication 5903, Application Details.

At the individual level, the roster uses Responsible Official, Authorized Delegate, and Contact. A person's title in your company does not automatically select the right application role. An IT administrator might support sign-in problems without having authority to act as an RO.

Write two separate statements: what the organization will do, and what each person needs to do. This prevents a common planning mistake where “our software person” is assigned every role even though the work includes executive authority, account maintenance, and operational response.

For direct A2A, check the identifier arrangement as well. Publication 5718 requires the Issuer role's transmitter and issuer identifiers to match the EIN on the application; it directs a sole proprietor filing under an SSN to select Transmitter. A broad description such as “our own returns” does not resolve that special case. Publication 5718, section 1.3.2 and TCC role table.

The current authority definitions are in IRM 3.42.9.7. An RO or AD may also be listed as a Contact. Treat those entries as separate responsibilities even if one person performs both.

Ask candidates to confirm they understand the work, can respond during the filing period, and know where the relevant operational records live. A formal title without availability creates a fragile roster.

Under current IRM 3.42.9.7, the general requirement is at least two ROs and two Contacts. For a sole proprietor, S-corporation, or single-member LLC/disregarded entity, it specifies one RO and at least one Contact. Up to two ADs are optional; the contact maximum is 250. Current IRS role-count rules.

Use the correct business structure in the application. Do not choose an exception merely because only one employee is available. If your legal structure or the live application behavior is unclear, resolve that with the IRS before finalizing the roster.

The December 2024 tutorial has inconsistent older wording on its authorized-users page. This guide uses the current IRM for counts and the S-corporation exception. The IRS's December 2024 working-group update also documents the introduction of the S-corporation selection.

Build a row for each individual with their proposed role, business authority or operational responsibility, sign-in readiness, and availability. Keep sensitive personal information out of the general roster. Link to the controlled collection process when application details still need to be gathered.

For every recurring activity, identify a responsible person and a continuity plan. Who updates a business phone number? Who coordinates a change in Responsible Officials? Who answers a transmission question when the main payroll contact is absent? Make the plan consistent with the permissions each role actually has.

Do not solve coverage gaps by sharing an account. A second worker should use their own authorized access appropriate to their responsibilities. This also makes a staff handoff easier because the organization can distinguish one person's access from another's.

Fictional example. Summit Example Corporation has two executives with responsibility for the business, an operations manager who maintains filing access, and a payroll specialist who handles return questions. The company is not using one of the single-RO exceptions.

When Executive B later leaves, the operations manager cannot use AD authority to replace that RO. The company routes the change to an appropriate RO and verifies the resulting application state. That permission boundary should be documented before the handoff becomes urgent.

The example demonstrates role design. It does not establish that a real individual qualifies or that the illustrated application has been approved.

Before the initial submission, confirm that the listed ROs can perform their required steps. After approval, check that every operational contact can reach the workflow they need and knows how to escalate a problem. Keep the application roster and the internal responsibility sheet aligned.

When someone changes jobs, review what they actually owned: application administration, return preparation, transmission support, or filing-outcome follow-up. Transfer the work and update the appropriate authorization separately. A successor inheriting a task does not automatically inherit access.

Record the date the roster was checked, what changed, and which follow-up remains. A periodic review can help catch drift, but a known staff change should trigger action when it occurs. Use the companion maintenance guide for a fuller handoff checklist.