Guidance on using the US-DOS org identifier

Community Zone Codelists
#1

Hello

Has anyone used the US-DOS code for referencing US registered corporations? As far as I can see, many US organisations are using US-EIN instead.

A further question to this would be any recommended practice in terms of identifying the state registries.

Picking a random example:

Acme Company: https://opencorporates.com/companies/us_de/947909 - registered in Delaware.

For using US-DOS would the reference be, for example, US-DOS-DE947909 ?

#2

Hi Steven,

I think it makes more sense for organizations to use US-EIN. I could be wrong, but isn’t US-DOS just an identifier that the US government created for reporting to IATI? I don’t think there is a DOS registry (I’m pretty sure that’s just meant to refer to the Department of State, which is responsible for publishing all USG data to IATI).

Laia

#3

HI @laia_grino thanks, that makes sense, although what has thrown me is the description text for US-DOS:

Corporation registration is the responsibility of each state (see link)

…with the link: http://www.companieshouse.gov.uk/links/usaLink.shtml then talking about corporations (rather than the US government).

As far as I can see, the change log for the non-embedded codelists has not been updated: http://iatistandard.org/201/upgrades/nonembedded-codelist-changelog/ - so if this US-DOS is a new code, the reasons for it are not linked to…

#4

(i’ve created an issue for the non update of the code list at https://github.com/IATI/IATI-Guidance/issues/220 - but this shouldn’t confuse the main subject - using US-DOS!)

#5

Hi Steven

US-DOS is misleading and we should remove it (if it is not being used). The related url on the codelist points to advice on the UK Companies House website which is advising UK companies to approach the US Dept of State. US company registers are maintained at state level but I can’t find any consistent way of referring to them based on state practices.

I think we have three options in referencing company registrations:

  1. Replace US-DOS with, say US-SCR (State company registry) and add state prefix to registration as per Steven’s example - US-SCR-DE947909

  2. Create a separate registration agency code for each state. that properly reflects each’s identity, eg (US-DEDC-947909 = Delaware Division of Corporations) (US-ALSOS-000000 = Alabama Secretary of State)

  3. Use opencorporates as a registration agency. XI-OC-US_DE_947909

#6

Hi @stevieflow – I misspoke. I thought US government was using the US-DOS identifier to publish to IATI, but they’re not – they’re using US-USAGOV (this might have changed recently – I’m pretty sure it used to be US-DOS, as that’s the IATI id we’d been using for the purpose of publishing US govt grants to IATI).

Afraid that’s all the light I can shed on this!

#7

I would suggest a variation of (1) and (2), in which the pattern is:

US-{STATE}_SCR-{identifier}

e.g:

US-SCR_DE-947909

This assumes their is just one main company registry per-state.

This might be a good issue to put to the joined up data group for insights.

#8

Thanks @laia_grino @bill_anderson @TimDavies

Re: US-DOS - that does seem like it needs a change proposal - should we post this in the relevant forum @bill_anderson ?

My understanding is that an organisation could be referenced through any of the suggested methods, but we want to place emphasis on those that can more easily be dereferenced. I’m not sure how easy this is via EIN numbers, but haven’t also checked each and every state registry either! Regardless - this looks to be new and important developments, so we have a way forward

#9

There’s no two ways about it, identification of US companies is problematic. Companies (including nonprofits) are created/registered at state level, and so the obvious thing is to use state-level identifiers, and this is what OpenCorporates uses.

Having said this, these are not without problems, and certainly don’t satisfy every single one of those qualities you’d want from good identifiers:

  • stable (i.e. they don’t change) – in general this is true, but not in all cases. For example, we’ve found several registers (for example Georgia), which have changed the identifier system without notice, or documentation. This causes problems for users of the identifiers, although we come up with a transparent and effective system for handling this, listing previous numbers, and performing redirects for the URIs (we are also writing public reports listing what we’ve done)
  • 1:1 mapping with the entity to which they relate. This in general is true, although we have come across situations where the identifiers are not unique across the state (see this report on Minnesota) but only to a a particular company type.
  • well-known, i.e. they are widely used/distributed. This is a significant problem in the US – unless the UK company number or say the French Sirete, the numbers are not put on letterheads, or invoices, for example.
  • open - no proprietary licence. This at least is not a problem, unlike for example the hated DUNS number.

On the other hand they are issued by the government that creates the entities, and do relate the the legal entities themselves (unlike the EIN – see below – or the DUNS number).

The DUNS can be ruled out, being both proprietary, and mapping not to legal entities, but to records inside D&B’s proprietary block-box database, and could be a company, a building, a division, or frankly, from an end-user’s perspective, anything at all.

EINs are superficially attractive, being issued by the IRS (i.e. Federal level). However, in general these are not a matter of public record, and they are not necessarily persistent or 1:1 mapping to legal entities. In addition, not all legal entities have EINs. They are, however, usually known by the entity themselves – the challenge, however, is mapping to legal entities (which are at the state level).

So not easy solutions, and we think in reality this will be solved by a) either us mapping different identifier systems together (we are already doing with EINs, where we can), and creating URIs that are transparent, have well-thought-out and public principles (see our blog – sorry won’t let me add another URL in this post) for how we handle the changes and issues, or b) a move to a universal identifier system such as the LEI, or most likely a combination of the two.