I have more information on the coding issue: The problem lies with my software company, not the IRS. It seems that in a limited number of cases, my software (ProSeries, made by Intuit) returns a code “5” indicating that an electronic payment has been rejected when the actual transmission from the IRS is a code “4” indicating that the payment was accepted.
What is making me upset is that when I called Intuit this morning that they were aware of the problem and were working on it. They apparently do not consider this serious enough to proactively tell their user base about it. I asked for a supervisor to call me back; I have yet to get that call today.
Consider a hypothetical client, John Smith. Mr. Smith owes the IRS at the extension deadline $20,000. He chooses to have the funds electronically debited. His return is filed electronically and accepted, but the electronic funds payment is supposedly rejected. You tell Mr. Smith he needs to mail a check to the IRS for the $20,000 which he dutifully does. However, the payment was really accepted.
The client discovers two days later that the IRS has debited his account. Meanwhile, does he put a stop-payment on the check he sent the IRS (incurring fees from the IRS and his bank)? Or perhaps the check is cashed by the Treasury and now Mr. Smith is out an additional $20,000 for a few weeks. (The IRS will send a refund for the double-payment, but Mr. Smith loses the use of that money for a while.) Or perhaps the check bounces as Mr. Smith only had $30,000 in his bank account. Is Intuit going to cover Mr. Smith’s fees?
As best as I can determine, I had four clients impacted by this. I assume there are hundreds if not thousands impacted nationally. It will be very interesting to see how Intuit responds to this major issue.
