Who Is Responsible for Compliance When eSignature Is Embedded in Tax Software?
Verdocs Team
Three companies touch a single Form 8879 signature: the accounting firm that prepares the return, the practice management platform the firm works in, and the signing provider embedded inside it. Ask each who owns the compliance obligations and you will often get the same answer, which is one of the other two.
The IRS does not allocate these duties by contract. It allocates them by role, and a role attaches to what your company actually does. This article sets out where the lines fall, labelled by kind: Required where the source says must, Guidance where it says should, Reading where a conclusion depends on interpretation, Recommended practice for our engineering opinion, and Uncertain where the published sources do not settle it.
Roles come from activity, not from agreements
Required. The authoritative statement is in Publication 3112, IRS e-file Application and Participation (Rev. 11-2025): "The roles and responsibilities of Providers relate to the e-file activity the firm is conducting. The firm identifies its e-file activity by selecting the appropriate Provider Option in the IRS e-file Application. Each Provider Option is a different role and may have different responsibilities that relate specifically to the e-file activity of the firm."
And, decisively for anyone in an embedded arrangement: "Providers must adhere to all IRS e-file rules and requirements applicable to their multiple e-file roles."
The e-file application offers seven Provider Options. Five matter for individual income tax returns.
| Role | What it is, per Publication 3112 | Usually who |
|---|---|---|
| Electronic Return Originator (ERO) | "begins the process of the electronic submission of tax returns to the IRS" | The accounting firm |
| Software Developer | "writes either origination or transmission software according to the IRS e-file specifications" | The platform, and often the signing vendor |
| Intermediate Service Provider | "processes tax return data, typically from an ERO or an individual taxpayer, and forwards to a transmitter" | The platform, sometimes |
| Transmitter | "sends the electronic return data directly to the IRS" | The platform or a third party |
| Online Provider | Lets taxpayers self-prepare; "a secondary role," so it never stands alone | Self-serve tax products |
Required. Publication 3112: "Applicants may choose more than one Provider Option." Publication 1345 assumes the same, referring to "Providers with multiple roles." So the question is never "which one are we." It is "which of these do we do."
White-label resale is now its own answer, and both revisions say so
This is the part most likely to be news, and it moved in the current editions of both handbooks.
Required. Publication 1345 (Rev. 12-2025) added a section on resellers, listed in its own "What's New": "Providers that resell software (e.g., rebranding, white label, etc.) are also considered by the IRS as Intermediate Service Providers as they provide package deals that usually include additional services to EROs such as education and support." A reseller is "a firm that purchases software with the intent of selling it to a Tax Preparer or ERO instead of using it." Three duties follow: select the Intermediate Service Provider role on the e-file application, do not provide an EFIN with the software package, and ensure the firm's own EFIN is in the return data.
Required, and pointing the other way. Publication 3112 (Rev. 11-2025) puts a matching duty on the developer who sells into resale, both in its Stay Informed reminders and among Software Developer responsibilities: "When selling software for resale (re-branding, white label, etc.), the software developer must ensure that the original purchaser does not resell the software with the original purchaser's EFIN... The person buying the resold software must obtain their own EFIN."
Read together, the white-label boundary carries obligations in both directions. The party rebranding takes on a role, and the party enabling the rebrand has to police how its software is passed on. Neither duty can be satisfied by the other party's contract.
Uncertain, and worth real advice. Whether embedding a signing component inside your own product, sold under your own name, is "reselling software" in this sense is a judgment call. The definition turns on purchasing software "with the intent of selling it to a Tax Preparer or ERO instead of using it," and an embedded component inside a larger product you also operate is not obviously that. We are not aware of published IRS guidance resolving the embedded case. Do not settle this one by analogy to your commercial model.
The responsibility matrix
Reading, built from the requirement text and normal embedded architecture. Owns means the requirement lands on you. Enables means you must make it possible for the owner to meet it. Evidences means you hold the proof. A cell reading Depends means the answer changes with your architecture, most often with who stores the form.
| Requirement | Accounting firm (ERO) | Vertical SaaS platform | Signing provider |
|---|---|---|---|
| Confirm the taxpayer's identity | Owns | Enables | Enables |
| Record name, SSN, address, date of birth (remote) | Owns | Enables | Depends |
| Verify that data against record checks | Owns | Enables | Enables |
| Enable KBA questions | Enables | Enables | Owns |
| Disable identity verification after three attempts | Not involved | Enables | Owns |
| Identity verification in a secure portal | Not involved | Enables | Owns |
| Record the six signature data elements | Enables | Enables | Owns and evidences |
| Produce that record to the IRS on request | Owns | Enables | Evidences |
| Signed record is tamper-proof | Not involved | Depends | Owns |
| Storage access controls and indexed retrieval | Depends | Often owns | Depends |
| Reproduce legible hardcopies | Enables | Often owns | Enables |
| No transmission until Form 8879 is signed | Owns | Owns | Enables |
| Retain the form three years | Owns | Often enables | Evidences |
| Obtain a handwritten signature after KBA failure | Owns | Enables | Enables |
| Select correct Provider Options on the e-file application | Owns | Owns | Owns |
Two rows deserve attention. "Produce that record to the IRS on request" is owned by the firm but evidenced by the signing provider, which is the single most common gap: the party with the obligation is not the party holding the data. And the last row is owned by everyone, separately, because each company declares its own roles.
What a contract cannot move
Required. Some duties sit with the ERO by definition, and no vendor agreement relocates them. Publication 1345 for remote transactions: "the ERO must record the name, social security number, address and date of birth," and must verify that information "through record checks with the applicable agency or institution or through credit bureaus or similar databases." Form 8879's Important Notes for EROs: "Confirm the identity of the taxpayer(s)," retain the form "for 3 years from the return due date or IRS received date, whichever is later," and receive the signed form "before the electronic return is transmitted."
Contracts do useful work here. They allocate effort, set service levels, and apportion liability between companies. What they do not do is change which Provider Option describes your activity, or move a role's duties onto someone who does not hold that role.
Eight questions that indicate which roles you hold
Recommended practice. Answer these honestly, then compare against what your e-file application actually says.
- Does your software format return information to IRS e-file specifications, or transmit it? If yes, Software Developer.
- Does your software transmit return data directly to the IRS? If yes, Transmitter as well.
- Do you receive return data from a firm, process it, and forward it onward? If yes, consider Intermediate Service Provider.
- Do you purchase another company's software and sell it on to preparers or EROs under your own brand? If yes, Publication 1345's reseller section is about you.
- Do you sell your software to others who rebrand and resell it? If yes, you carry the Publication 3112 duty about EFINs travelling with the software.
- Do taxpayers self-prepare in your product? If yes, Online Provider, which must be paired with another role.
- Does any EFIN ship inside your software package or default configuration? If yes, that conflicts with a stated requirement, and it is worth checking today.
- Do your Provider Options on file match every answer above? If not, that mismatch is the finding.
What this means for product teams
- Ask what you do, not what you sell. Roles follow activity. A signing feature can make you a Software Developer in the IRS's sense without changing anything about how you market the product.
- Assume you hold more than one role. Publication 3112 says requirements apply across all of them.
- Close the produce-on-request gap first. The obligation is the firm's and the data is usually yours. That mismatch causes real problems at audit and it is cheap to fix with an export.
- Audit the EFIN question if you white-label in either direction. Both handbooks moved here in their current revisions, and the requirement is specific.
- Write the matrix down with your customer, and date it. An undocumented split becomes a dispute during a security review.
- Have counsel confirm the roles, not just the contract. Whether an embedded component counts as resale is genuinely unresolved, and it is the kind of question where the answer depends on your arrangement.
Frequently asked questions
If the accountant is the ERO, is compliance entirely their problem? No. The ERO holds specific duties, including confirming the taxpayer's identity and retaining the form, but Publication 1345 states separate requirements for Software Developers who enable electronic signatures, and Publication 3112 assigns responsibilities to every Provider Option a firm selects.
Can we contract our way out of these requirements? You can allocate work and liability between companies. You cannot change which Provider Option describes your activity, and duties attach to roles rather than to agreements.
Does embedding a third-party signing component make us a reseller? Unresolved. Publication 1345 defines a reseller as a firm that purchases software "with the intent of selling it to a Tax Preparer or ERO instead of using it," which does not obviously describe a component inside a product you also operate. Get advice on your specific arrangement rather than reasoning from your pricing model.
We have never filed an e-file application. Does any of this apply? That is the question to take to counsel first. Publication 3112 ties Provider Options to the e-file activity a firm conducts, so the analysis starts with what your software does, not with whether an application exists.
Where Verdocs fits
Verdocs is embedded signing infrastructure, which puts us in the right-hand column of that matrix: the identity step, the recorded elements, the sealed record and the evidence export are ours to build, and the roles your company holds are yours to determine. What compliance should an eSignature vendor give you is the same question from the other end: what to demand of the vendor whose column that is.
What we can do is be concrete about it. Before you build, we will tell you in writing which of these requirements our platform addresses, which we enable, and which stay with you or your customer, so the matrix above is filled in with facts rather than assumptions. If that is useful, start a conversation or read how we approach accounting and tax. The Form 8879 build spec and the identity assurance question cover the two rows people underestimate most.
Sources
Read 2026-08-22. Revision dates are as printed on the documents.
- IRS Publication 3112, IRS e-file Application and Participation, Rev. 11-2025, Catalog Number 25992L. Provider Options and the choice of more than one; Provider Roles and Responsibilities, including the Software Developer duty on software sold for resale; the same resale point in Stay Informed.
- IRS Publication 1345, Authorized IRS e-file Providers of Individual Income Tax Returns, Rev. 12-2025, Catalog Number 64382J. Specific Requirements for Intermediate Service Providers Participating as Resellers: page 28. Additional Requirements for Software Developers Enabling Electronic Signatures for Forms 8878 and 8879: pages 29 to 30. Electronic Signature Via Remote Transaction and Identity Verification: pages 16 to 17. Providers with multiple roles: page 4.
- Form 8879, IRS e-file Signature Authorization, Rev. 01-2021, Catalog Number 32778X. Important Notes for EROs, including confirming taxpayer identity, the three-year retention period, and receipt before transmission: page 2.
- Form 8878, IRS e-file Authorization for Form 4868 or Form 2350, 2025, Catalog Number 32777M. Important Notes for EROs: page 2.
This article is provided for general informational purposes and does not constitute legal, tax, security, or compliance advice. Requirements may vary depending on your organization's role, technology, and workflow.
