A Prototype for Free, Trustworthy Tax Filing

First, like all the work we do at Code for America, we are guided by basic notions of accessibility and human-centered design. We focus on using plain, conversational language at or below an eighth grade reading level, rather than inaccessible tax jargon. We include help text and explainers for frequently asked questions.

We create multilingual products. (The illustrations you will see are English only, but every page has the option to switch to Spanish; supporting additional common languages would be even better.)

Because most people using the internet—even those accessing the IRS website—use mobile phones, our designs are not just mobile-friendly but mobile-first. All of the illustrations in this prototype are displayed as they would appear on a phone, not a desktop computer.

Methodologically, we base our design decisions on research and testing with our clients. While these specific designs were not tested with clients, they are based on our extensive testing and research in developing and refining our existing products, GetYourRefund and GetCTC.

A tool that aims to eventually serve all (or at least most) tax filers could focus on many different populations. We believe the tool should initially be designed around the needs of low-income and marginalized households. In this prototype, you will see designs for a tax situation that is typical for a low-income household, and with special attention paid to issues—like conflicting family claims—that may be more common in more marginalized populations.

There are a few reasons for this focus. First, from a technology perspective, focusing on low-income filers and simple tax situations makes for a good “minimum viable product,” or MVP. An efile tool won’t serve every tax case in its first year; it will start with a set of tax cases and expand. Simple cases common to low-income filers make for a good MVP. Starting with a bare-bones MVP and iterating over time is how we built GetCTC and GetYourRefund, and it is a wise model for any large technology product.

Second, lower-income households at the margins of the tax system have the most to gain from a federal efile tool. If they currently pay for private tax assistance, they are the ones who can least afford it. If they do not file at all, they stand to gain most from a simple and accessible way to do so.

Third, and most notably, we believe that designing for the hardest-to-serve is the best way to create a system that works for everyone. This is sometimes called the curb-cut effect. Curb cuts were designed for people with disabilities to more easily cross the street, but they ultimately benefited many populations: parents pushing strollers, people lugging groceries, and older people. By the same token, design choices that explicitly address the needs of families not well connected to the tax system will make the tax system simpler and more intuitive for others, too.

An IRS efile tool should use IRS data to make the filing experience easier for tax filers. Using IRS data removes barriers to filing, reduces filer confusion, and saves filers time—all while saving the IRS time reviewing and adjusting incorrect filer-entered data.

Income data is the most important case. Our experience with GetCTC shows that reporting income is the hardest part of filing a return. Employers already report income records to the IRS. This income should be pre-populated for filers’ review and confirmation.

But income isn’t the only IRS data element that can be used to streamline the filer experience. Basic information like name, Social Security Number (SSN), and address—as well as filing status, spouse SSN, and dependents—can be pre-populated based on prior year tax returns. Filers can generally enter this information themselves—but why not make life easier for them, and for IRS submission processing?

It isn’t just pre-population; the principle extends to more esoteric data. The IRS can use returns already filed this year to warn filers up front about fatal errors. For example, the IRS can dynamically warn a filer who already efiled that they cannot efile again, or that they were claimed as a dependent and cannot claim various credits. The IRS can use data from the filer’s IRS account to prompt various forms. For example, if the filer is subject to an unresolved ban under 26 USC 32(k), the tool can prompt them to file Schedule 8862. If the tool does not support certain types of income, it can use the IRS’s income records to warn a filer that they are out of scope.

Data pre-population and automation aren’t magic: The IRS’s data about a given filer may be inaccurate. Given the tax law’s reliance on information the IRS has no independent record of, and given the realities of IRS data collection, filers will generally have to review—and often amend—the IRS’s data. Dependents move between households. Employers are late in filing W-2s. People earn money in cash, or they move out of the country. All of these scenarios will cause pre-populated data to be incomplete or outdated. It means that a truly automated tax return, with trivial or zero filer involvement, isn’t feasible, at least in the medium term. But these problems are solvable with good design. Good design allows us to use IRS data to make the process easier for filers, without a requirement that it be perfect. The data can be pre-populated, with filers responsible for correcting it. In other words, IRS data can be used to streamline tax filing even if that data is incomplete or inaccurate.

Notably, data pre-population and automation need not be restricted to an IRS efile tool. The IRS may make this data available through an API to private tax preparation companies as well (provided they identity-proof their customers, secure appropriate consent to query data, and use it in accordance with applicable privacy laws).

Some of the pre-population and automation discussed above will likely require tax filers to verify their identities. Sensitive data cannot be displayed back to a filer who has not verified that they are the person they say they are.

But identity verification can be very difficult, especially for low-income populations. Verification systems based on credit checks can block those without credit histories; verification systems based on video files can block those without a working camera; and all types of verification systems can be a challenge for anyone with variable addresses or contact information. In some real-world implementations, outright majorities of high-need populations have failed to make it through verification. Unaddressed, this would be a first-order problem.

Providing flexible identity verification options that are accessible to a wide range of filers through multiple pathways would increase the probability that any filer can get through one of them. The pathways should include in-person as well as online options.

It is just as important to offer filing functionality for those who cannot verify their identity through any of the flexible methods. Currently, one can file a return without any verification other than providing an SSN. The IRS efile tool should preserve this option. In the prototype below, you’ll see a few different filing options available for tax filers who cannot verify their identity—including one that still allows such filers to benefit from income automation.

We sometimes speak of designing a holistic service—of which any particular product is just a part. In this case, the service is allowing a tax filer to fulfill their obligations with the IRS—and while the efile tool ought to be the centerpiece of the service, it is not the only element. Other IRS programs that assist in filing a return—or understanding tax code provisions, setting up payment plans, or checking the status of payments—should not truly be considered independent products or programs. All of these efforts are part of a single service for every American to interact seamlessly with the IRS in fulfilling their tax obligations and receiving their tax benefits.

In practice, this means integrating other tax filing assistance into the efile tool itself. For example, filers could access IRS customer service directly through the filing tool, with assistance provided by agents who are able to see the data that filers have entered into the tool, as well as the data in their IRS records.

It also means empowering the tool to provide filers warm handoffs to other filing resources, in cases where the tool is not appropriate for them. For example, perhaps a tool user with a complex case could schedule an appointment with a local Volunteer Income Tax Assistance (VITA) site or Low-Income Taxpayer Clinic (LITC) from within the tool itself—and sites would be instructed to prioritize such appointments according to the filer’s level of need, as determined by the tool. The IRS should be thinking holistically about ways to situate the efile tool as a central element of a wide constellation of efforts that support tax filing.

Of course, even the best tool is worthless if nobody knows that it exists and nobody uses it. The IRS should consider promotion and marketing to be a core component of the tool.

Thankfully, we have learned a lot in the last several years about how to promote tax resources—and some of the most important opportunities are well within the IRS’s control. The efile tool needs to be easy to find throughout the IRS website, and it should be promoted as the recommended default option for tax filing. Pages linking to the tool should be tested with filers just as much as those in the tool itself, and they should be optimized to come up in search results for tax filing products. It is not enough to present the IRS tool alongside a laundry list of other options; choice overload can prevent tax filers from taking action or from trying the new product.

The IRS should not only make the tool easy to find, but also perform proactive direct outreach to filers. (Again, throughout this report, we use “filers” to refer to anyone who could file a return, whether or not they do.) For filers who have used the tool before and consented to such communications, these outreach nudges could be via text or email. For filers who have not yet used the tool or have not consented, the outreach could be by mail—like the IRS’s autumn outreach to households who had not yet filed in the last three years. Missing non-filers can be identified based on prior year returns or on information returns. Outreach nudges should continue well past the filing deadlines, targeting households who still have not filed returns.

In line with our findings from running GetCTC, these IRS efforts should also be supplemented where possible by outreach efforts led by other trusted government actors, including state and federal benefits agencies.

A landing page with a clear overview of the tool and what to expect

We begin with a clear and thorough landing page that helps filers understand what the tool is. This should be part of a broader IRS web strategy that prioritizes promoting the IRS efile tool and explains in plain language who can use it. The landing page—and the broader promotion strategy—are especially important as the IRS helps filers get accustomed to a world where they can file taxes directly with the IRS. The strategy should be informed by user research about filers’ views and attitudes on IRS-provided filing software.

In the short term, the landing page also has an important role in describing who is eligible to use the tool. For at least the first several years, the tool will not support every filer’s situation and, in fact, may be fairly limited. This design anticipates such a situation, describing succinctly what tax situations are and are not supported by the tool. The illustration shows a filer clicking for more information about the types of income that are not supported in the tool.

Electing to verify identity, or continue without verification

In accordance with our principle of flexible and optional identity verification, the login page offers filers an informed choice. They can elect to fully verify their identity, thereby getting the full benefit of the tool’s pre-population and automation functionality, or they can continue without verifying.

In this second option, they will create an authenticated account but will not have to prove that they are who they say they are. (The National Institute of Standards and Technology, or NIST, the body that manages federal authentication and verification standards, refers to this as an IAL1 level account; someone who verifies their identity is authenticated at the IAL2 level.) We’ll come back to this a little bit later.

For now, let’s suppose the filer elects to verify their identity.

The IAL2 identity verification page will likely be within the auspices of an identity service like Login.gov and subject to the details of the service. This design merely illustrates the principle of offering multiple different verification options. The design offers both online verification and in-person verification at post offices (as Login.gov currently offers at a small scale). Note that this verification most likely need not be done more than once. Once their secure account is created at the IAL2 level, the filer can continue to use it in future years.

Let’s suppose the filer elects online verification and completes the requirements.

Automated checks on eligibility to use the tool, and warm hand-off off-boarding for ineligible filers

Once the filer’s identity is verified, the tool can now utilize IRS data and display it back to the filer, who is authorized to view the information the IRS knows about them. Off the bat, we can use IRS data to check if this filer is likely in scope to use the tool. Perhaps the tool does not yet support Schedule C income but the IRS has a record of a 1099-NEC; perhaps the tool does not yet support amended returns and the individual has already filed; perhaps the tool does not yet support Form 8862 and the filer has an unresolved 32(k) ban on their account. (See Leibel et al regarding 32(k) account flags.) The tool can alert the filer now, before they’ve wasted time entering any additional information. In future editions of the software, when such special cases are accommodated, the same eligibility check could automate the process of selecting which forms and schedules the filer should include in their return. Someone who has already filed, for example, could seamlessly be guided to a 1040-X, while a filer subject to the 32(k) ban could be prompted to fill out Form 8862.

Note that this automated screening relies on the IRS checking a variety of data sources: the current year efile system, current year information returns, and the tax account. This is an example of creative and aggressive use of myriad IRS data elements to streamline the tax filing process as much as possible.

If the filer does not qualify for the tool, they would see this offboarding page, which embodies the principle of situating the tool within an ecosystem of tax filing assistance. The page explains why the filer is not eligible to use the tool and provides a variety of concrete options to determine next steps. In this illustration, these include warm hand-offs to IRS-funded Volunteer Income Tax Assistance (VITA) and Low-Income Taxpayer Clinic (LITC) sites, as well as the possibility to schedule a call for guidance from an IRS customer service representative. The design also includes an option to have IRS data shared with the external partner of their choice, so that the filer need not start from scratch with the partner.

For now, let’s suppose the filer is eligible to use the tool. In that case, they do not see this off-boarding page, and instead they continue with the tool.

Basic information about the filer, pre-populated from prior-year return

On the next several pages, information about the filer and their family is pre-populated from the information on last year’s return—or, if they didn’t file last year, the prior year’s return. (If the filer has never filed, they must start from scratch.) Note that filers always have the option of editing their data if anything has changed. For items that may be especially likely to change—for example, in this illustration, six months’ residency in the United States—the data item can simply not be pre-populated, forcing the filer to actively answer the question. The design also highlights in red the tax filer’s responsibility for confirming information is correct.

Marital and filing status, pre-populated from prior-year return

On this page, filing status is pre-populated from last year’s return. Because this person filed Married Filing Jointly last year, their spouse’s information appears for review as well, and the tool asks for confirmation that their marital status is still consistent with this filing status. If the filer were to say no, they would see a series of screens to correctly determine their filing status. (Note that a Head of Household filing status would presumably be confirmed later in the flow, after ensuring the filer is claiming a dependent who is a Qualifying Person under 26 CFR 1.2.)

In this case, the filer says yes—they are still married and would like to file with their spouse. As such, they are asked to have their spouse verify their identity, via the same process the primary filer just went through a few screens earlier. This verification would allow the spouse’s income data, too, to be pre-populated. If the spouse did not verify identity and the primary filer did, information from the prior-year return (like payment information and dependents) could still be pre-populated—but the spouse’s income would have to be manually entered. But let’s suppose that the spouse, too, verifies their identity.

Pre-populating dependents poses additional challenges: The dependents a tax filer can claim very often change year over year, and confirming dependency according to 26 USC 152 is more complex than confirming marital status or address. But good design can address these challenges. In the illustration here, both dependents are Qualifying Children under the age of 19; the filer confirms the children still pass the Qualifying Child Support and Residency tests under 26 USC 152 (c). If a prior-year dependent had been a Qualifying Relative, or had passed one of the exceptions for the age test, different criteria could be shown for confirmation.

Our research and experience working with low-income filers has shown that the word “dependent” itself can be jargony and opaque. Some people using GetCTC opted not to add a dependent and then wondered, later, when they would be asked to report their children. In GetCTC, we avoided the word dependent and asked filers if they wanted to add a child or family member they supported. The design here, likewise, clarifies what a dependent is, and that it is here that filers should report their children.

Using IRS data to flag dependent conflicts in real time

The dependent functionality presents another opportunity to make creative use of IRS data and streamline the filing experience. Currently, if a filer attempts to claim a dependent who was previously claimed (perhaps erroneously) on another return, the experience can be frustrating. The filer completes and efiles their entire return, just to later get a rejection message back from the efile system that the return cannot be accepted as filed due to the conflicting dependent claim. Then, the filer must log back into their tax software, remove the conflicted dependent, and try again. If they want to contest the dependent claim, they must file on paper—a burden to the filer and the IRS alike.

Using IRS data in real time can make this experience much more straightforward. Immediately upon claiming a dependent, the tool can check the current year master file for a conflicting claim and alert the filer immediately—long before completing, much less submitting, the return. (Keep in mind this alert reveals no more information than the current system; it simply reveals it earlier in the process.) The alert could—to the degree consistent with the other filer’s privacy protections—reveal relevant information about the claim, including, for example, when the claim was made. The tool could even show such warnings in other cases, to try and ward off conflicts before they occur. Suppose a filer starts to claim a dependent whom they have never claimed, and who in every prior year was claimed by another filer—even though that other filer has not yet submitted a return this year. The tool can warn the filer that it looks like they may be trying to claim someone else’s dependent, and ask if they are sure they want to continue. It could also offer a plain-language summary of the tiebreaker rules, which govern which family member can properly claim a dependent in cases of competing claims.

The illustration here shows an option to “Dispute this dependent”—which is preferable to the current process. Implementing this option would likely require an amendment to the backend Modernized eFile system, not just the front end filing software. The current resolution process starts with letters sent to both claimants of the disputed dependent; the tool could implement the beginning of the process immediately, for the filer now making the conflicting claim.

Pre-populated based on information returns

Income is pre-populated not from the prior-year return, but from information returns (Forms W-2 and 1099) that the IRS receives for the tax year in question. Pre-populated income data may be incomplete, so it is important that filers understand that they are legally required to add any missing income. The design requires the filer to actively confirm that the income listed is complete. If it isn’t, the filer can select “Add additional income” and add any other income sources they may have.

The language on the pages a filer would see upon clicking “Add additional income” is especially critical. While most filers know what they earned, many don’t know how to classify that income. The tool must help filers walk through the steps of properly categorizing and reporting their income, including using common vernacular terms for types of income. For example, our research has shown that many filers refer to their self-employment income as “contract work.”

Note that the pre-population of W-2s, by default, only shows a relatively small amount of summary information, rather than showing every box. For most filers, the more limited information should be enough, and displaying more could well be overwhelming. Filers who want to confirm the accuracy of every box can click “See more details” and view every box on the W-2.

User testing and iteration will be especially critical for this page.

A display of common additional credits that filers may try to claim

This page allows the filer to elect to claim additional credits. Clicking on any of these options would reveal a series of additional questions to confirm eligibility and calculate the amount of that credit. This page can get increasingly long as the tool supports more and more credits over time.

Note that EITC and CTC do not appear on this page; the tool already has enough information from existing pages to calculate EITC and CTC eligibility and amounts.

Review, refund amount, pre-populated payment information, consent

Then there are just a few final steps to finish submitting the return. The filer has a last opportunity to review all the information they’ve entered; they see a report of what they will get in their refund (or, conversely, what they owe); they enter their payment information (with this information pre-populated from last year’s return, as possible); and they legally consent to the submission of their return. The illustrative language shown here on the consent page is that of a third-party efiler, and it will likely look different for an IRS-run tool.

Note that, unlike in current tax filing, the filer is not asked for their prior year Adjusted Gross Income (AGI) or Identity Protection PIN (IP PIN) as verification measures. Because the filer has already been identity verified at IAL2, these measures should not be necessary.

A post-submission landing page with various useful calls to action

That’s it—for a filer who also filed last year, with one W-2, and without other special circumstances, that’s the entire process of filing a federal tax return. On this page, we include some other possible calls to action that again position the tool as part of an ecosystem of tax filing. Calls to action like filing a state return or applying for other government programs could include functionality that allows filers to consent to the reuse of the data they just entered on their federal return, to streamline the next application process.

Electing not to verify identity

Back at the beginning of the tool, on the login page, a tax filer may elect to “Create an account” (IAL1), rather than selecting “Full verification” (IAL2). Keep in mind that creating an account without full verification is generally how tax filing currently works. A filer who uses third-party electronic filing software or files on paper does not go through any rigorous process to prove they are who they say they are; they do not show identity documents online or in person. They simply provide the information on their tax return. Insofar as there are concerns about tax fraud and identity theft, these are either addressed invisibly in the background or resolved on the back end by the IRS Taxpayer Protection Program. The same would be true for unverified functionality on the IRS efile tool.

When a mature efile tool exists, verifying identity will be preferable, to enable the streamlined filing experience shown above. But some filers will not verify. Some may lack the resources; they may not have the technology to use the online process, or the capacity to visit an in-person verification location. Others may be skeptical of providing the government biometric data that may be used in the verification process. Still others may simply not want to take the time to verify, not yet convinced of the advantages.

Moreover, in the early years of the efile tool, the advanced pre-population functionality we showed above may not be ready yet. If this pre-population does not exist, there is no real advantage to verifying identity. As such, the unverified path is the “minimum viable product” for an efile tool—this is the functionality that will launch first.

Creating an authenticated account without identity verification

Of course, just because a filer does not verify their identity does not mean they will not create an authenticated account. On the contrary, as with existing tax preparation software, non-verified filers will still establish account credentials, complete with multi-factor authentication to ensure unauthorized users do not gain access to the account. This is known as IAL1 authentication (in contrast to IAL2 verification), and could also be done through the auspices of Login.gov. The account creation page might look something like this illustration. Note that filers are providing and confirming their contact information, which they will use to gain access to their account in the future—but not providing identity documents.

Manual entry of basic information for unverified filers

Because the filer on this path has not verified their identity, there is a risk that they are not who they say they are. As such, the IRS cannot directly reveal any of the filer’s data in the tool.

Note that this does not mean the IRS cannot use the filer’s data at all. The IRS likely could, for example, implement the same set of automated tool eligibility screeners we showed above on the Screeners and Offboarding page. That is, once a filer has entered their identification number, the tool could check their tax account and information returns for any characteristics which would make them out of scope to use the tool. Provided there are many characteristics out of scope, so that a scammer could not infer anything concrete, the tool could alert an unverified filer they are out of scope for the service; it simply would not be able to provide the specific reason for being out of scope.

But pre-populating basic information and family information from a prior year return would be too risky for an unverified identity. So, in this path, the unverified filer would enter their own basic information, filing status, and dependents. In this sense, the tool is no different than most extant filing software. The illustration here shows the first page of this manual data entry experience—there would be several more pages to finish recording family structure.

Thankfully, we know from experience running GetCTC that even families with no experience in the tax system generally don’t have too much trouble with these types of fields, as long as the design is clear and the instructions are in straightforward plain language. Manual data entry for these items is an unfortunate imposition on the filer—but it is usually not a dealbreaker.

Flexible options for unverified users to complete income reporting

Where things can get trickier for manual data entry is with income data. We know from our experience running GetCTC that income reporting can be difficult. It is easy enough to tell the IRS the name and SSN of your daughter. It can be much harder to track down your W-2s and 1099s, categorize your income, and copy in dozens of esoteric numbers.

This income page has two principal options. First, the filer may elect to verify their identity after all. Perhaps they did not see the purpose of doing so at first, or didn’t yet trust the tool would work for them. Now that they have reached a genuinely challenging task, they may see the value of verification. A filer electing this option would go through the identity verification flow and continue to the pre-populated income page shown above. (Another advantage of verifying identity now is that the filer is already invested in the process and known to the tool. If they elect to verify in person but never follow through, the tool can follow up directly.)

Second, the filer may elect to manually enter their income, much as they entered their family data, and as they would in traditional tax software. After entering income data, the end of the flow for this filer would look much like it did for verified filers—with the added requirement, perhaps, of providing prior-year AGI or IP PINs.

But what about filers for whom both of these options are prohibitive? Consider a W-2-only filer who does not have the resources to verify identity, but also does not have access to their W-2s. Many such filers are in the EITC participation gap. The tool has everything needed to file their return except for income—which the IRS knows from employer reports but cannot disclose to the unverified taxpayer. While it is preferable for the filer to review their income data, it is also better for them to file some return rather than no return at all.

So, for some low-risk, high-need filers, the tool could offer a third option: The filer submits an income-free return, asking the IRS to fill in income data behind the scenes. The return as filed—like simplified returns for TY 2019-2021—would show no income on Lines 1-8. The IRS would “correct” the return according to its own data.

Who is a low-risk, high-need filer? It is a filer who is highly unlikely to owe tax, for whom the IRS’s income data is likely to be accurate, and who is unlikely to successfully file otherwise. For example, the Look Up My Income option would not show for filers with a record of 1099 income; or, perhaps, for filers who had 1099 income in the last three years, since this is likely predictive of 1099 income this year. The IRS can determine the risk tolerance here empirically, based on its data. The option could also be restricted to filers with low incomes or intermittent filing histories, who have higher need and are less likely to successfully complete a full return.

Legal consent for filers electing income look-up

Filers who select the Look Up My Income option would see this consent page. They must actively attest that W-2 income was their only income from the tax year. They must confirm that they are electing to have the IRS prepare their return and that they understand the risks—that this process could delay the refund, and that electing this process does not absolve them of their legal responsibility to fully report their income. They can only continue after they check all three boxes. At the bottom of the page, they still have the option of reverting to one of the standard income entry options.

Privacy-preserving final page for filers electing income look-up

The rest of the flow for a Look Up My Income filer is similar to the flow for others, with an important exception: the tool cannot reveal the refund (or bill) amount to the filer, since this would reveal sensitive information to an unverified user. Instead, the refund amount page would set the filer’s expectations appropriately—that the Look Up My Income option may require additional processing time, and that they will be alerted when the refund is calculated and on its way.

Behind the scenes, the IRS would run fraud checks on Look Up My Income filers like any other unverified filers. Depending on data availability or fraud procedures, the IRS might hold the return to wait for more W-2 data or for conflicting claims. Once the IRS is confident in the data, it would make corrections to the income records and credit amounts based on information from Forms W-2, formally post the return, and issue the refund. (Recall that the Look Up My Income option is restricted to filers who are highly unlikely to owe tax. If, however, a taxpayer does owe, the IRS would issue a bill, much like the agency currently does using the CP14 notice. Any penalties and interest would be accrued only starting at the point that the notice is received.)

The corrections to income and credit amounts would be summarized in a notice and issued to the taxpayer via mail, much like the IRS currently issues CP2000 notices correcting reported income amounts. A fully completed Form 1040 reflecting the income and credit corrections would also be posted to the filer’s online account. If the filer needed to access their complete 1040 for any reason, they could at that point opt to complete IAL2 verification (again, either online or in person) and download the return.