LEI и DUNS — два идентификатора, которые часто упоминают вместе, хотя происхождение у них разное. Один задан международным стандартом и ведётся открыто, второй выдаёт частная организация. Ниже разберём, что означает каждый, где они применяются и почему ни один из них не заменяет проверку контрагента.
Зачем компаниям отдельные идентификаторы
Названия плохо подходят на роль опознавательного знака. Организации в разных странах называются одинаково, одно и то же имя переводится несколькими способами, а при смене правовой формы к названию добавляется или убирается сокращение.
Регистрационный номер тоже не решает задачу до конца: он уникален внутри своего реестра, но ничего не говорит о том, как соотнести его с записью в другой стране. Для трансграничных сделок нужен знак, который не зависит от языка, алфавита и национальной системы регистрации.
Таких знаков исторически сложилось несколько, и два из них встречаются в документах чаще прочих.
Есть и прикладная причина. Автоматические системы сверяют контрагентов по номеру, а не по названию: номер короткий, не содержит пробелов и не зависит от того, как написано имя в конкретном документе. Именно поэтому идентификатор удобно использовать как ключ в анкетах, реестрах поставщиков и отчётности.
Что такое LEI
LEI — идентификатор юридического лица, определённый международным стандартом ISO 17442. Он состоит из двадцати знаков, букв и цифр, и включает контрольный разряд, по которому можно отсечь часть случайных опечаток.
Коды выдаются через открытую глобальную систему, и сведения о выданных идентификаторах доступны для публичного поиска бесплатно. Это важно: проверить, существует ли код, может любой желающий, без договора и оплаты.
Внутри этих двадцати знаков части несут разную нагрузку: начальные символы указывают на систему, выдавшую код, следующие относятся к самой организации, а последние служат для проверки. Такое устройство позволяет отличать одну запись от другой, не обращаясь каждый раз к полному реестру.
При этом LEI — не лицензия, не разрешение и не свидетельство качества. Это метка, которая указывает на конкретное юридическое лицо и позволяет сослаться на него одинаково в разных странах.
Что такое DUNS
DUNS — девятизначный номер, который присваивает частная организация, работающая в области кредитной информации. Он не является международным стандартом и не управляется публичным органом: правила присвоения устанавливает сам поставщик.
Чаще всего такой номер встречается в закупках и цепочках поставок. Там он служит быстрым способом сослаться на организацию в анкетах, тендерной документации и системах учёта поставщиков, где удобнее держать одно поле, чем набор национальных номеров.
Поскольку номер выдаёт коммерческая структура, условия доступа к данным о нём тоже определяет она, а не открытый стандарт.
Для поставщика это удобно ещё и потому, что один номер покрывает организацию целиком: он не привязан к отдельной стране и не меняется при переводе названия. Обратная сторона — зависимость от коммерческого держателя базы и от его условий доступа.
Чем они отличаются друг от друга
Различия удобнее всего свести в таблицу.
| Свойство | LEI | DUNS |
|---|---|---|
| Кто задаёт правила | Международный стандарт | Частная организация |
| Длина | двадцать знаков | девять цифр |
| Состав | буквы и цифры | только цифры |
| Контрольный разряд | есть | алгоритмической проверки нет |
| Доступ к сведениям | публичный поиск бесплатно | определяется поставщиком |
| Типичная область | финансы и регулирование | закупки и поставки |
Главное различие — в природе источника. Один опирается на открытый стандарт и публичный реестр, второй — на коммерческую базу. Это не делает один лучше другого, но означает, что и проверяются они по-разному.
Почему идентификатор не подтверждает надёжность?
Наличие кода означает ровно одно: запись о лице существует и ей присвоен номер. Он не сообщает ни о финансовом состоянии, ни о деловой репутации, ни о соблюдении каких-либо требований.
Ошибка, которая встречается регулярно, — принять идентификатор за знак качества. Логика при этом такая: раз номер есть в уважаемой базе, значит, с организацией всё в порядке. Это неверно. Номер есть у всех, кто его получил, включая организации с плохой историей.
Второй вариант той же ошибки — считать, что отсутствие номера означает проблему. Многие добросовестные организации просто не обязаны его получать, и отсутствие кода ничего о них не говорит.
Полезно разделять три разных вопроса. Существует ли такая запись. Совпадает ли она с лицом, которое перед вами. Надёжно ли это лицо как партнёр. Идентификатор помогает только с первым, и то не всегда.
Можно ли проверить идентификатор самостоятельно?
Частично. Для LEI можно сверить структуру и обратиться к публичному реестру, чтобы подтвердить существование записи. Для DUNS алгоритмической проверки нет, поэтому остаётся сверка с источником, который его выдал.
Но и здесь действует то же разделение, что и с налоговыми номерами: проверка формы и проверка существования — два разных утверждения. Первое отвечает на вопрос, похожа ли строка на идентификатор. Второе — есть ли такая запись на самом деле. Совпадение структуры никогда не заменяет обращение к источнику.
Отдельно стоит помнить, что публичный поиск отвечает по состоянию на момент запроса. Запись может быть переведена в неактивное состояние, и сохранённое значение в вашей базе перестанет соответствовать действительности — поэтому у сведений о проверке тоже должен быть срок годности.
Для разработчиков: длина, контрольный знак и кэш
Храните идентификаторы строками. Даже если номер выглядит числовым, ведущий ноль или буквенный символ сделают числовое поле непригодным, а преобразование — разрушительным.
Держите тип идентификатора отдельным полем. Строка «номер» без указания, о каком именно идентификаторе речь, через несколько итераций превращается в источник ошибок: часть команды считает, что там один тип, часть — что другой.
Если реализуете проверку контрольного разряда, помните, что она отсекает опечатки, но не подтверждает существование. И не пытайтесь выводить структуру одного идентификатора из другого: у них разные источники и разные правила.
Кэшируйте результаты внешних запросов с ограниченным сроком и обязательно различайте три состояния: подтверждено, не найдено и неизвестно. Последнее — не ошибка ввода, а временная неопределённость, и пользователю нужно видеть именно её.
И последнее, самое важное с точки зрения безопасности: идентификатор не является удостоверением личности организации и не даёт прав. Не используйте его как признак авторизации в доступе к данным или операциям.
Предусмотрите нормализацию ввода. Пользователи вставляют номер с пробелами, дефисами и в разном регистре, а сверка требует одного вида строки. Без нормализации одна и та же запись будет выглядеть как две разные, и вы получите ложное расхождение.
Что делать дальше
Проверьте, как ваша система ведёт себя с идентификаторами трёх видов: коротким цифровым, длинным буквенно-цифровым и таким, где есть ведущий ноль. Если хотя бы один теряется или искажается, дело в хранилище, а не в данных. Собрать согласованный образец организации, чтобы прогнать эти случаи, можно в разделе генератора тестовых данных компании.
О том, как идентификаторы соотносятся с регистрационными номерами, рассказано в статье про регистрационный номер компании, а о разделении проверок — в материале о правилах проверки налогового номера. Общая рамка допустимого применения тестовых реквизитов описана в статье о тестовых данных компании.
Примеры в материале условны и приведены для проверки программных форм; они не содержат сведений о реальных организациях и не являются подтверждением чьего-либо статуса.