Most of us are familiar with the tried-and-true IRS Filing Information Returns Electronically (FIRE) system, which creates a user-friendly, readable flat-text error file that contains T, A, B, C, K and F records. Yes, this file may look like alphabet soup — and is nowhere close to state of the art — but it’s reliable, easily produced by mainframes and just as easily consumed and processed by the IRS.
Unfortunately, even all good things that work just fine must eventually be upgraded or replaced at some point. So does that mean FIRE’s days are numbered?
If you’re familiar with the Affordable Care Act Information Returns (AIR — wait, shouldn’t it be ACAIR? Never mind…) system for processing IRS 1095 forms, you’ll know that its filing system is radically different from the FIRE system. The flat file has been shoved aside for the fancy new XML schema.
XML, which stands for eXtensible Markup Language, was designed to be both human- and machine-readable. But don’t be fooled by the “human-readable” part; it’s actually quite complicated.
In order to understand XML, you first need to understand Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL). Then, as the code evolves, so do the WSDLs — and you have to be prepared to make quick changes.
During AIR’s first year, the IRS made many changes. And as you may remember, each time they made a change, you had to do so as well. Since the programming is so different and less forgiving, the IRS actually required filers to test with the IRS. If you wrote your own code, you had to have that tested, too. As a result, companies that initially thought they’d develop an in-house system to create their AIR file quickly discovered that it was a very big endeavor that fell far short of cranking out the 1220 flat file like the good ol’ mainframes.
I know this is pretty technical, but what I’m trying to illustrate is that the IRS didn’t necessarily stay on the common standard path. They also put a few ingredients into their secret code sauce that made coding a challenge for many.
All right, so at this point you’re probably wondering where I’m going with this. Well, here’s the payoff: the bugs have been worked out of the AIR system for the most part, and the IRS is now eyeing their next move.
Last year, the IRS announced at a forum that they were working on a new Information Return Intake System (IRIS). This system will be modeled on AIR, and will eventually replace both AIR and FIRE.
Wait! What? They’re putting out FIRE? (Sorry, I couldn’t resist.) That’s right; the IRS is looking to replace the legacy FIRE system with the faster and more technologically advanced IRIS XML SOAP and WSDL processing system.
There are a lot of good things that will come out of this, but I’m not going to sugarcoat it — there will also be some challenges.
On the positive side, the XML processing system will be faster and more secure. The IRS will also be able to process files and return an error file to the filer within minutes of filing — including the most coveted error of all, the Name/TIN error.
Yes, the IRS will be able to tell you immediately if the recipient or payer Name/TIN do not match the IRS records. That’s HUGE. Within minutes of filing, you’ll know if you have a TIN mismatch and can immediately start working on resolving it, instead of waiting until August for the dreaded CP-2100 Notice. If the stars align, you may have the opportunity fix all of your TIN mismatches and be able to minimize or eliminate the need for B-Notices. You have to admit, this is pretty cool, plus it also has the potential to save you a lot of money.
Now, for the downside: I noted before that the code is complex. It’s not something that the mainframe will adapt to without a lot of programming. So many have tried, but few have succeeded. Even if you’re one of the successes, there’s a high likelihood that the IRS will periodically make code changes that will cause your IT group to scramble to keep up.
That’s because sometimes the changes come out with little notice — so if your IT team needs a few weeks to schedule coding, you could be caught in a bad predicament. With the FIRE system, the code was simple and there was no need to make changes. However, as you know, AIR gave you many opportunities to test your IT department.
How should you prepare for this change? That’s a difficult question to answer. There’s no doubt that at some point, this will happen. The IRS has been working on IRIS for a while, and there’s great incentive for them to get it done: faster and more secure receipt and consumption of data on their end.
While the IRS won’t provide a timeline, I would guess we’ll see this before 2020. That means in the next couple of years, filers will have to determine whether they want to spend the resources to allow their IT department to code and test with the IRS — and be permanently on call when the IRS makes last-minute changes.
There is another option: Surrender the in-house pet project.
In my long career, I’ve often favored in-house options, but in this case I really do believe that continuing with in-house filing could be a disaster. The internal costs from making these changes can easily outweigh the costs of outsourcing.
You need to seriously consider whether information tax reporting is a core competency. If it’s not, then you shouldn’t be doing it. Focus on what you do best, and let your vendors focus on what they do best. Then, if (or more likely, when) the IRS makes a change, it’s not your problem anymore — plus, you won’t have to worry about missed tasks that can leave you subject to IRS penalties.
If you’re a 1099 filer and use that mainframe to generate the 1220 flat file for FIRE, you really need to make the decision about whether to spend the resources to continue in-house filing. Finding a processor that has the experience to handle filing for you won’t cause you to reinvent the wheel.
I also want you to think about the timing. If you consider shifting the workload to a vendor, sooner is definitely better than later. When AIR debuted, many companies tried to code on their own or waited until the last minute to consider outsourcing — but by that point, most of the processors were saturated with new clients.
Some raised their prices considerably, and some vendors actually shut their doors to new clients because they weren’t able to serve the enormous volume of companies shopping for a vendor. Needless to say, it’s not a good position for a processor or a prospect to be in.
In the end, it really comes down to a simple question: Is tax information reporting a core competency for your company? If it’s not, I strongly suggest you reconsider your strategy.
Your revenue depends on it.