Does the IRS really need addresses on W-2s and 1099s

[LCP]

LCP,

Data Sharing in Ultra Tax and other TR/CS products could be a great time saver. Unfortunately, it isn't capable of ignoring simple differences such as PO vs P.O. or 5-digit vs. 9-digit zip codes. The result is lots of unnecessary alerts.

This has been discussed quite a bit on the ARNE forum. How soon TR will get the message is anyone's guess. But the more users who complain, the more TR is likely to make datasharing usefull rather than the PITA it has become. So I urge you to join the discussions on ARNE.

MichaelG pretty much sums it up. In fact it is a major time saver in most cases......except with 1099R entry.

I've talked to Ultratax about it as well as their diagnostic alert system. They should offer a way to manually clean up your database.

My orignal question was whether the IRS even needed that info (address of payer). As if there is any liklihood of them deciding they don't and changing things !?!?!?!?!?

[Burke]

I've talked to Ultratax about it as well as their diagnostic alert system. They should offer a way to manually clean up your database.

My orignal question was whether the IRS even needed that info (address of payer). As if there is any liklihood of them deciding they don't and changing things !?!?!?!?!?

1. ATX allows you to delete entries from the database.

2. Apparently the software people think so, as an efile cannot be created (in ATX) without the info being input.

3. I note on CP2000's for unreported income, the IRS lists the name of the payor and their address. But they might be getting that from the payor too. Perhaps it helps in their matching program????

[DonPriebe]

... They should offer a way to manually clean up your database. ...

The problem is not the database, it's the issuers like State Street Retiree Services who use the same EIN with different addresses for all their different clients. Or even some banks (like M&T) who use a single EIN but show local or regional addresses.

[LCP]

The problem is not the database, it's the issuers like State Street Retiree Services who use the same EIN with different addresses for all their different clients. Or even some banks (like M&T) who use a single EIN but show local or regional addresses.

I think that if you saw the data in our database you'd agree that it is a problem and cleaning it up would be nice. To be clear....... we create our database when we enter info....Ultratax doesn't provide the data.

I think you may be on to something when you stated that having the address info is helpful when they send out notices to taxpayers.

[Lion]

Someone told me long ago, and it worked then but maybe not now, that all the address fields need are four characters. He managed one of those volunteer sites, so they try to get people through as fast as possible; also worked at HRB Premium so was not in a hurry there. I've made use of that when doing an amendment not in my system, for instance, but that case wouldn't include e-filing. Yes, I think you do have to include a zip code that matches the town. But, if you're creating the database, do it in a way that benefits you. If it's no benefit to have full information for an employer you'll never see again or a fund manager who manages multiple retirement accounts, then don't put them in your database, or use short cuts. My usual for speed (that amendment, for instance) is UNKNOWN.

[Koss]

Addresses

This has been a very active thread, and all of the comments have been very interesting, particulary with respect to managing your tax software, and suppressing or overriding unwanted default behavior.

Lion wrote:

Someone told me long ago, and it worked then but maybe not now, that all the address fields need are four characters. He managed one of those volunteer sites, so they try to get people through as fast as possible

When it comes to actually transmitting an electronic return...

My reading of current IRS guidelines is that the payer's address on Forms W-2 and 1099-R is a required field, and that the tax pro has a responsibility to ensure that the address entered into that field is the address that appears on the form itself.

If you leave that field blank, or incomplete, or if you negligently allow your software to autopopulate an address that is different from what appears on the form, that is arguably an e-file compliance failure. The fact that someone who was running an IRS VITA/TCE site suggested this does not mean that it is, or ever was, an acceptable practice.

This is almost the same issue as the taxpayer's address on Form W-2. Almost every program automatically imports the taxpayer's current address from Form 1040 into each Form W-2. The IRS does in fact expect us to manually enter the address from Form W-2, if it is different.

I sometimes fail to catch this. I'm as guilty as anyone else. In an older thread, someone asked if this sort of mistake could lead to penalties or sanctions under the e-file program. In other words, could you get a warning, or potentially get booted from the e-file program, and lose your EFIN?

My answer was that the IRS e-file compliance folks probably would not impose a sanction for this type of error if it was occasional or isolated, and if you took steps to remedy it. But if it was part of a larger pattern of e-file noncompliance, with other violations, such as missing signatures, or using pay stubs without Form W-2, and the ERO was already on some kind of warning, then it could be a cumulative thing, i.e., the last straw.

BMK

[Lion]

When I'm trying to match a prior return that's not in my system, for an amendment or as a double-check, and don't have the original documents just the return, I take shortcuts. When preparing a return to e-file, or even for a client to mail, I type in full information where needed so it'll roll over next year. I use the detail screens for W-2s and 1099-Rs. But, I use the summary screens for interest and dividends and do not enter EINs, addresses, etc.

If your database is slowing down your data entry instead of speeding it up, then spend some time this off-season to clean it up. That was one pain at HRB. If the first person to add an employer or whatever to the database made a typo or other error, we were stuck with it appearing each time we typed in that EIN. Sometimes it's slower to correct what's there than to do it from scratch yourself. As I learned which ones had errors, I would not put the EIN first so it wouldn't trigger the wrong entry; I'd start with the name or address or whatever was wrong and work my way backward through the fields. Too much of a bureaucracy to get corrections made to the database during the busy tax season.

[joanmcq]

In ATX I start typing in the payor manager box to find the correct database entry. For some banks, like Wells Fargo, I might have two or three entries depending on whether it's Wells Fargo Investments or a mortgage paying interest or a bank account. I just arrow down the list until I get to the right EIN. Since addresses don't have to be entered for interest/dividends, I don't enter it, and therefore have no issues with a match. I just look at the 1099 and think, ok, I need the BofA entry that ends in '630'. I have common ones pretty much memorized.

[Burke]

This is almost the same issue as the taxpayer's address on Form W-2. Almost every program automatically imports the taxpayer's current address from Form 1040 into each Form W-2. The IRS does in fact expect us to manually enter the address from Form W-2, if it is different. I sometimes fail to catch this. I'm as guilty as anyone else. BMK

Uh-oh. Well, one more thing to remember for next year. But, why, pray tell, would this be important? Especially if it is an old address, and not current?

[FEDUKE404]

Correct taxpayer address on W2

Uh-oh. Well, one more thing to remember for next year. But, why, pray tell, would this be important? Especially if it is an old address, and not current?

Koss (and I) have previously addressed the issue in this thread and in others.

I have always thought, and I am now supported by reading the cited regs, that for efiled returns it is the responsibility of the preparer to "reproduce" all of the information exactly as shown on the underlying tax document (W2 and/or Form 1099R). The fact that it might be faster or easier for a preparer to let the software autopopulate certain fields - do you also verify the FICA/Medicare amounts? - should not be an issue at all.

When many tax returns were still not being efiled, perhaps this rule fell by the wayside in the opinions of some? I know that well over five years ago this was a topic of discussion with the manager of the firm where I worked at the time. There were some "high-volume" preparers who would often take such shortcuts, including not even signing any of the 8453/8879 forms or the RAL loan document forms, They often had the "why bother?" approach to such.

As for the "why" question you raised, minds wiser than my own would have to address that. My guess is that such accurate information could be used by the IRS as additional information for determining tax home, HOH issues, EITC issues (number of wage earners at a single address), moving expense issues, and similar.

FE

[dtlee]

Koss (and I) have previously addressed the issue in this thread and in others.

I have always thought, and I am now supported by reading the cited regs, that for efiled returns it is the responsibility of the preparer to "reproduce" all of the information exactly as shown on the underlying tax document (W2 and/or Form 1099R). The fact that it might be faster or easier for a preparer to let the software autopopulate certain fields - do you also verify the FICA/Medicare amounts? - should not be an issue at all.

When many tax returns were still not being efiled, perhaps this rule fell by the wayside in the opinions of some? I know that well over five years ago this was a topic of discussion with the manager of the firm where I worked at the time. There were some "high-volume" preparers who would often take such shortcuts, including not even signing any of the 8453/8879 forms or the RAL loan document forms, They often had the "why bother?" approach to such.

As for the "why" question you raised, minds wiser than my own would have to address that. My guess is that such accurate information could be used by the IRS as additional information for determining tax home, HOH issues, EITC issues (number of wage earners at a single address), moving expense issues, and similar.

FE

FE,

I also go back to the dawn of e-filing and remember well the rules as I was taught in those early years. Certain information was not critical (such as the W-2 Control Number) but the name, address (except for the line 1 continuation field) and amounts were important. As I recall, they did not tell us what the box 12 information would be used for but they wanted it. In fact, they told us that if we had an doubts, we could always refer to Publication 1346. They told us that if the field is listed, we needed to enter it and enter it accurately.

I agree that the rules have fallen by the wayside. but not only from times when there was less e-filing, but also because the matching that the IRS envisioned thenmselves doing has been spotty. As mentioned in other threads, some preparers and software vendors believe Line 2a of the 1099-R is optional information and can be manipulated to suit the facts we want to present to the IRS. The fact that the IRS has had trouble building valid matching rules (because the amount can be reported in many different ways by the payer and on the tax return. and since the 1099-R is not transmitted to them unless there is withholding), lulls us into believing that it does not ever need to be accurate.

Few Tax Software vendors differentiate between forms that are actually transmitted to the IRS and those built simply for data entry convenience. Most software products include a facsimile of 1099-SSA for data entry, but that is not transmitted anywhere. Some products include Form 1099-Q or Form 1098 or ask for EINs for Schedule B Interest and Dividends. If you have not studied Publication 1346, you would not know if these are transmitted or not.

The situation only gets worse. While I have found some references for MeF, I have not yet found the Publication 1346 equivalent for MeF. There are quite a few new rules applied for MeF and the only way I have found to learn them is to run into an error myself or read about others encountering as I have here.

[JohnH]

IRS is doing an excellent job of converting us into obedient data entry clerks, aren't they?

I think it may be just a matter of time before they decide they need to regulate our fees, maybe even set limlits on our working hours.

[Gary2]

The closest equivalent to 1346 for MeF is Pub 4164. A good starting place for the schemas and business rules is at http://www.irs.gov/efile/article/0,,id=209615,00.html . If you're not familiar with XML schemas, there will be a learning curve and likely a need for a good tool for browsing the schema files. Personally I use the free version of Microsoft's Visual C# Express, but that may be overkill for most people. A cheap trick is to download the xsd files from the IRS and change the file type to xml, after which IE can display them usefully.

[dtlee]

The closest equivalent to 1346 for MeF is Pub 4164. A good starting place for the schemas and business rules is at http://www.irs.gov/efile/article/0,,id=209615,00.html . If you're not familiar with XML schemas, there will be a learning curve and likely a need for a good tool for browsing the schema files. Personally I use the free version of Microsoft's Visual C# Express, but that may be overkill for most people. A cheap trick is to download the xsd files from the IRS and change the file type to xml, after which IE can display them usefully.

Thank you, Gary.

I have been trying to find out where the IRS keeps this information for several weeks. When I call the IRS, they don't know what I am talking about.