Wilson <
nowhere@nearyou.com> wrote:
. . .
My software is H&R Block Business. If I try to put a SSN in the Payer's TIN, >111-11-1111 will be recorded by the software as 11-1111111. This isn't just >for this year, the software has required the latter format since 2021.
I can get a TIN in the latter format from the IRS in short order. I can't >imagine H&R Block hasn't heard of this 'glitch' in their software by now. >Thanks.
Waitaminit. The person performing data entry MUST NOT be required to enter
the hyphens. If entering hyphens is optional, then the hyphens should
be removed before parsing the number to see if it's an SSN or EIN. The
hyphens, which makes the number more human readable, should be used for
display only. But they are not part of the number itself.
TINs that aren's SSNs are assigned from reserved blocks of numbers that
aren't assigned as SSNs. A long long time ago, the first group of numbers
in the SSN indicated which office had assigned the number. After Social Security card issuance was centralized in 1972, the first three digits
were assigned to a specific state based on the ZIP code in the mailing
address. It was a hint as to where the person was living at the time he
first got a job or applied for driver's license training. The two middle
digits indicated which blocks of serial numbers were available for
assignment at a given time and was a vague hint about whether the number
was genuine. The geographic indicator went away with randomization,
starting in 2011, and the middle two digits no longer represented blocks
of serial numbers that were open for assignment at a specific period of
time.
Similarly, the first two digits of the EIN indicated which IRS district
or key district assigned the EIN in the days in which the employer was
assigned a specific office to apply to based on its location. However,
if an application or return required an EIN and the employer didn't yet
have one, the IRS office that received the application or return would
assign an EIN out of its own pool of numbers and the employer would end
up with an EIN from a different geographical pool. Due to the possibility
of an employer being assigned a number from multiple offices, one could
end up with more than one number. This happened to me. I had to ask for a letter from IRS instructing me to use one number and not the other number.
Today, EINs from a pool of numbers of whichever office did the work when
the application was received.
But the ranges of number from which SSNs are not assigned are well known.
A quick pattern match of the first five digits is sufficient to tell
that the number isn't an SSN and therefore assigned by IRS. Within the
ranges of numbers assigned by IRS, blocks of numbers are reserved for
all the other TINs that aren't EINs assigned by IRS. ATINs and ITINs are
each assigned from reserved ranges. An ATIN is used only for a dependant
on an individual tax return and no where else. If it's used on a 1099,
it must be rejected in software.
I can't think of a scenario in which an ITIN would appear on a 1099, but
a foreign national without a visa allowing him to work (which means he's ineligible for Social Security) can receive interest belonging to
someone else as a nominee.
As far as a PTIN, that is NOT a taxpayer identification number for the
purpose of reporting payments, as either payee or payor, on a 1099. It
appears ONLY on a tax return prepared by a third party.
Why are PTINs assigned from reserved ranges of nine-digit numbers?
That's outrageous.
Yes, I know why IRS did it, as their computers were programmed to use
the preparer's SSN initially, but that the number identifying the
preparer should have been entered into a separate block during the
transition between use of the preparer's SSN and the new identifying
number. With 20-20 hindsight, obviously the preparer's SSN never should
have been required to begin with for privacy reasons.
--
<< ------------------------------------------------------- >>
<< The foregoing was not intended or written to be used, >>
<< nor can it used, for the purpose of avoiding penalties >>
<< that may be imposed upon the taxpayer. >>
<< >>
<< The Charter and the Guidelines for submitting posts >>
<< to this newsgroup as well as our anti-spamming policy >>
<< are at www.asktax.org. >>
<< Copyright (2011) - All rights reserved. >>
<< ------------------------------------------------------- >>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)