What The Modernized e-File System Means For Tax Preparers
What The Modernized e-File System Means For Tax Preparers
(technical jargon kept to a minimum)
The 1040 Legacy e-file system has officially been retired. It is still technically available for one more year, but will be revived only if the new system experiences a significant failure. This is a huge milestone for the IRS, and for Drake; we have been methodically implementing the massive behind-the-scenes changes and carefully navigating the transition for a number of years now, with the primary goal being to make sure that our challenges didn't become your challenges. Now that we are here, let's take a look at what this ultimately means for tax preparers.
First, I'll digress for a brief history lesson. The Legacy e-file system was utilized for 26 years, from 1986 until 2012. Drake Software, along with four other companies, worked with the IRS to launch the system back in the mid-80s, and it proved to be an efficient and reliable system. I won't dive too deeply into technical details, but basically, each form sent via the Legacy e-file system became a record in the electronic file, and each piece of data in the record was assigned to a numeric field ID, sequentially sorted from the top of a tax form to the bottom. It was simple, easy to maintain, and effective.
As technology - Web-based technology, in particular - has evolved, new methods for transporting and storing data have emerged. One example is Extended Markup Language (XML). This language has become popular because it is easily read by both humans and machines. The IRS chose to use XML for the new system - what we now call "Modernized e-File," or "MeF." While the Legacy system uses the numeric IDs, XML assigns meaningful names, or tags, to data. For example, adjusted gross income is stored:
- in Legacy as: Sequence : 36000
- in XML as: AdjustedGrossIncomeAmt: 36000
Believe it or not, XML was first utilized by the IRS for e-filing corporation tax returns almost 10 years ago, when the MeF era began. Since corporation tax returns were not a part of the original Legacy implementation, it made sense to utilize XML for the initial launch of corporation tax e-file - a way for the IRS to get its feet wet with the new technology and bring more returns into the e-file system.
Okay, enough of the history lesson. Let's take a closer look at what you need to know about the new system.
New terms replace "Reject codes"
The term "reject code" will slowly start to fade from our vocabulary and be replaced by the following terms that basically mean the same thing, but are more specific to the manner in which returns are validated in the "MeF World:"
- Business rule violation:Business rules, which are defined by the IRS and state tax agencies, provide one layer of data validation. Most business rules supersede the Legacy "reject codes," and while the wording might be different, the purpose is the same: to improve accuracy before processing the return. As an example, take a look at Business rule F1040-017: "If Form 1040, Line 8a `TaxableInterestAmt' is greater than 1500, then it must be equal to Schedule B (Form 1040), Line 4 `CalculatedTotalTaxableIntAmt.'"
- Schema validation: An XML schema, in a nutshell, helps define parameters for the overall electronic file structure and for each piece of data; therefore, the schema itself serves as an additional layer of data validation. For example, "SSNType" can be applied to all fields that capture a SSN. This simply means that any data put in this type of field must meet specific formatting rules related to parameters, such as field length and characters allowed.
- Parse error: The data in an XML file is read into a useable format by an XML parser. If a piece of transmitted data does not meet the defined schema parameters, it will fail to "parse," thus resulting in a parse error. A parse error is similar to a reject, in that if a return fails to parse for any reason, the return is "rejected" and must be modified and retransmitted. The most common parse errors occur due to missing data or invalid characters, and we have been working aggressively to prevent these errors from occurring. The bottom line is that MeF is much more strict than Legacy.
In some cases, XML does create a more meaningful feedback loop: business rules and parse errors can be more specific when identifying the piece of data in question. For non-techies, though, they can still be somewhat difficult to understand.
The other main difference that you will notice is the fact that the new MeF system is transaction-based instead of batch-based. In Legacy, returns were batched up with other returns and transmitted to IRS. The batches were then downloaded by the IRS at specific drain times throughout the day; in recent years, it was three times a day. With MeF, each return is a transaction, and each transaction can occur immediately. While it might seem less efficient to process one return at a time, the systems are set up to handle thousands of transactions simultaneously, and acknowledgements can be processed in seconds instead of hours. However, if the system hiccups for any reason and creates a backlog, it can take some time to recover.
Once the MeF system processes the returns, they are now uploaded to the Customer Account Data Engine (CADE), the new e-file database for tax return data. Most of you know that CADE has been in the works for about a decade, and was first mentioned in 2000 as a part of the IRS Modernization Plan. CADE replaces the antiquated processing system that was first used in 1969. CADE is more flexible and secure than its predecessor, it can interface better with other government systems, and it is much more interactive for use internally at the IRS by customer account representatives, compliance officers, and data analysts. Most importantly to taxpayers, it will increase the speed of refund processing. While the IRS is hesitant to publish anticipated processing times, it is feasible that CADE could allow refunds to be direct deposited within 2-3 days after the return is accepted.
For those of us who have been around this business for a while, it is bittersweet to see the Legacy filing system retired. It wasn't perfect, but it was reliable, predictable, and familiar. And so it begs the question, "Why is the IRS replacing something that wasn't broken?" Well, because at some point, it becomes necessary to "modernize" and take advantage of more efficient and more capable technology. It is time to embrace a new system. Some of you, I'm sure, are contemplating how you might adjust your office procedures, especially if you complete returns during the taxpayers' appointments. If acknowledgements can be processed in a matter of minutes, or seconds, it might make sense to keep the taxpayer in your office until you know the return is accepted. It might save you some time in the long run if you are able to correct a minor reject co..um, I mean "business rule violation," with the taxpayer still in the office, rather than having to follow up later. It might also give the taxpayer peace of mind if he or she can walk out the door knowing the transaction is essentially complete. Of course, the big unknown is whether or not the IRS can process acknowledgements in a few minutes or less during the peak filing season. We will certainly learn more about its capabilities during the next couple months.
What is next?
The IRS has accomplished much of its modernization strategy introduced 13 years ago. But the new processing system is considered just the foundation for a broader vision: a real-time tax system. A real-time system would be designed to validate third-party information on W-2s and 1099s before the return is processed. Rather than dealing with inaccurate reporting after the fact, the issues would be addressed on the front end, leading to a higher percentage of accurately filed returns, less backend auditing, and, it is hoped, less fraud. At this time, there is no timetable established for implementing this vision.
Fact: Last year, Drake transmitted more than 98% of all 1040 federal returns through the MeF system, using the Legacy system only in rare cases.
James Stork, Senior Vice President of Drake Software