SSN and other Tax IDs

[IohannesIohannium]

There does not seem to be a recognized way to input lifelong tax identification numbers in a Gedcom file, unless they're U.S. SSN numbers. A.I. advises me to use IDNO, but that seems to me to be an I.D. number in the sense of the number tied to a government-issued card with its expiry date (e.g., a Real I.D. or a passport) and where the number is not meant to be lifelong.

As it currently stands, I've unofficially used for myself the SSN tag also for other countries' lifelong tax identification numbers and I'd wager the following syntax could make it unambiguous:

1 SSN RSSMRA61C17L219F
2 CTRY Italia
2 DATE FROM 23 DEC 1976

This should be parsed to mean that the person has had that Codice Fiscale (the Italian tax I.D. number) since the 23rd of December 1976 (the day of introduction of such numbers in Italy; this fake code would be of a person born in 1961). The date is optional and, if not written out, it'd be presumed to mean that the tax I.D. number was assigned to them at birth.

[albertemmerich]

The 7.0 spec states for SSN (see chapter Individual Attributes): It is a type of IDNO.

By this the standard defines the two codes to be equivalent:

1 SSN ...

1 IDNO ...
2 TYPE SSN

or may some more detailed TYPE payload as

1 IDNO ...
2 TYPE social security nr (USA)

The example given for Italy breakes the standard 7.0 (as it contradicts the definition of SSN "A number assigned by the United States Social Security Administration, used for tax identification purposes") and therefore should not be used!

The definition of IDNO has no restriction which would exclude to use it for the US social security number, or Italian codice fiscale.

As in other situations we are going to have only one way to exchange data by GEDCOM I propose to deprecate SSN and to eliminate it from the standard in version 8.0. It would be no good idea to redefine SSN to cover other countries, too. As up to now the definition is clear, and the payload of SSN has to be the US SSN. If we redefine it, we would not know the exact meaning of SSN in the future if there is no substructure - and up to now there is no TYPE (or CTRY) used to clarify SSN.

By the way: CTRY is not allowed as substructure of SSN. If we would follow Iohannes' proposal we had to take 2 _CTRY.

My solution for Iohannes example is

1 IDNO RSSMRA61C17L219F
2 TYPE Italian Codice Fiscale

[albertemmerich]

The date is optional and, if not written out, it'd be presumed to mean that the tax I.D. number was assigned to them at birth.

This is not the usual interpretation of a missing substructure: If there is no substructure there is no information.

Example:

1 OCCU teacher

has no DATE, and therefore you do not know, when the person had been a teacher. It should be clear: the person did not become a teacher at birth...

[IohannesIohannium]

Shouldn't there be a way to distinguish I.D. numbers meant to be lifelong from ones that are instead tied to a paper or a card that expires? My passport number was issued to me in 2020 and expires in 2030; my tax I.D. was issued to me at birth and is meant to be valid at least up to my death (and Italy actually keeps it running even after death, just to ensure it can be used in inheritance filings). My passport number does not identify me, it identifies the passport onto which my data was printed; my tax I.D. identifies me, not the card I got it printed on. Il Sab 25 Lug 2026, 15:42 Albert Emmerich ***@***.***> ha scritto:

…

*albertemmerich* left a comment (FamilySearch/GEDCOM#785) <#785 (comment)> The 7.0 spec states for SSN (see chapter Individual Attributes): It is a type of IDNO. By this the standard defines the two codes to be equivalent: 1 SSN ... 1 IDNO ...2 TYPE SSN or may some more detailed TYPE payload as 1 IDNO ...2 TYPE social security nr (USA) The example given for Italy breakes the standard 7.0 (as it contradicts the definition of SSN "A number assigned by the United States Social Security Administration, used for tax identification purposes") and therefore should not be used! The definition of IDNO has no restriction which would exclude to use it for the US social security number. As in other situations we are going to have only one way to exchange data by GEDCOM I propose to deprecate SSN and to eliminate it from the standard in version 8.0. It would be no good idea to redefine SSN to cover other countries, too. As up to now the definition is clear, and the payload of SSN has to be the US SSN. If we redefine it, we would not know the exact meaning of SSN in the future if there is no substructure - and up to now there is no TYPE (or CTRY) used to clarify SSN. By the way: CTRY is not allowed as substructure of SSN. If we would follow Iohannes' proposal we had to take 2 _CTRY. My solution for Iohannes example is 1 IDNO RSSMRA61C17L219F2 TYPE Italian Codice Fiscale — Reply to this email directly, view it on GitHub <#785?email_source=notifications&email_token=AF3JX6CHCKBLBMUMXFC33JD5GS2LNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXHA3TAMRQHE3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5078702096>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF3JX6DWLRZCYDHHXQEQNQD5GS2LNAVCNFSNUABFKJSXA33TNF2G64TZHMZTMMRSG42DANJUHNEXG43VMU5TIOJXGM3DKNJRGQ3KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AF3JX6FHBJQLCRVG5DIZCA35GS2LNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXHA3TAMRQHE3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AF3JX6H3TFQMEQSWCWH4CML5GS2LNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBXHA3TAMRQHE3KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread. Message ID: ***@***.***>

[Norwegian-Sardines]

I agree the SSN and IDNO probably are the same in use and could be combined at some future date. Are you saying that IDNO is special in the sense that it does not need the full “INDIVIDUAL_EVENT_DETAIL” substructure?

We could have:
1 IDNO 9999999999999
2 TYPE USA Social Security Number
2 PLAC United States of America

Or

1 IDNO RSSMRA61C17L219F
2 TYPE Italian Codice Fiscale
2 PLAC Italia

In the USA it was not required for an individual to have a SSN number assigned to them near birth until the 1990’s. Most did not get one until they started working until laws force younger ages at the end of the 1980’s.

[Norwegian-Sardines]

The bigger issue is that we really should have some way to create an IDNO.KIND that can be enumerated so that a majority of known types of national numbers can be grouped together with the same name and allow for better merging! I realize as I say this that this would be a major process that would leave many ID’s without an enumeration!

GEDCOM v5.5.1 wants the number to have a unique tag like the SSN for commonly used national numbers for example a new tag for this example might be ICF, but this gets out of hand as well!

[IohannesIohannium]

Indeed, I wanted to group them without asking for a new tag for each country. I get SSN is reserved for the U.S., but the concept of a lifelong national tax I.D. is pretty much widespread and grouping them together, with simply specifying which country's system we are referring to, seemed to me like a sensible solution.

[IohannesIohannium]

As for the structure, I envision the needed sub-fields to be country and date (because not everybody got it assigned at birth, especially if they were born before the introduction). I can't think of any further information, as date would also cover expirations caused by the country dissolving (e.g. a Yugoslav tax I.D.)

[albertemmerich]

I think we need both DATE and CTRY (for country) as proposed by Iohannes, and an enumerated KIND for the type of ID as proposed by Norwegian-Sardines. In our German systems I see at least 5 IDs: tax ID, tax number, health system ID, pass port ID und identity card ID. I am shure there are more.
Tax is complicated: tax ID and tax number are different, and both are valid at this same time. The tax ID is for a single person, the tax number is for my wife, and me. And tax number was modified, so I need DATE for the old one to show when it ended, and for the new one to show when it started. The tax ID was introduced in Germany in 2008.

[Norwegian-Sardines]

Thanks Albert, I should have figured that most countries had multiple ID’s. The real question for me is, “do I really want SSN managed in my genealogy?” In the software I use I can remove it from any reports, which is good for security, but having the SSN in my genealogy does not really make finding information easier or faster in places like Ancestry. Same would be if we had different tax IDs or my business had an ID and my wife and I had IDs.

What I’m saying is that from a data storage question having the ID is great but how practical is it to a genealogy?

[dthaler]

Discussion during GEDCOM Steering Committee meeting:

• We agree that having IDNO.KIND in the future would be a good thing. We can consider this for 7.1.
• Having a place associated is also useful. CTRY is insufficient for some IDNO's since for example US drivers licenses are issued by states not the country. IDNO.PLAC as @Norwegian-Sardines mentioned would work fine there.
• Having a DatePeriod would be appropriate for IDNO.DATE to capture issuance and expiry dates, when both exist
• We agree that SSN can be deprecated when IDNO.KIND is added