> Как можно реально обеспечить ввод одного клиента не более чем один раз?

Решения в общем виде не существует. Можно уменьшить количество ошибок.

> Как не допустить «ООО Днепр» вместе с «Днепр ООО» или "Общество с
> ограниченной ответственностью "Днепр""?

1. Стандартизовать организационно-правовые формы (т. е., хранить их отдельно и выбирать, а не вводить);
2. Явно описать информационный стандарт (как именно описываются предприятия, сотрудники, какие сокращения допустимы, какие - нет etc);
3. Использовать маркер "достоверности" записи: вновь созданная запись недостоверна, пока не проверена администратором (не только на соответствие имени и организационно-правовой форме предприятия, но и сопутствующие атрибуты (телефоны, url'ы, mail'ы, сотрудников etc).

> То есть, вопрос в использовании внешних ключей и в том, откуда их брать.

Факультативно - идентификатор налогоплательщика (он есть в любой стране) с дополнительными признаками. Imho не как ключ, а как _дополнительный_ идентификатор.

> надо что-то иное в качестве ключа использовать

Естественно, суррогатный ключ. Независимо от наличия/отсутствия естественных ключей.

> Мы пошли другим путем... решили не бороться с неправильным вводом,

Imho напрасно. Тупым манагерам тяжело объяснить про количество информации, ошибки ввода и пр. Практически невозможно.

> Пользователи всегда найдут способ обойти все ограничения. Какой бы супер
> навороченный механизм защиты не был придуман.

Хм... ну, если специально будут искать, - скорее всего найдут, конечно. Но нужно будет очень постараться. Фишка в том, что правильный ввод - это не только программное решение, а еще и информационная политика (информационные стандарты) + штрафы за искажение информации. Ага. И только так.

> Как один из вариантов - можно делать разбор как в поисковиках, по вхождению
> слов. При этом забить слова исключения (все те же ООО, АО и пр.).
> Одновременно проверять и телефоны. При совпадении хотя бы на 70%
> предупреждать и предлагать выбор...

Крайне низкая эффективность. Организационно-правовую форму обычно можно выделить, а ориентироваться на телефоны, факсы, мейлы как на источник надежной информации я бы не стал. Абсолютно реальная ситуация: регистрируется новое предприятие с теми же телефонами, адресом и пр., отличающееся от старого множественным числом имени. Причем, некоторое время (иногда значительное) работает и старое предприятие. Imho здесь один выход: получить полный перечень реквизитов и сравнить их со старыми.

> Это не дело программеров. Это дело политики предприятия в которую мы
> зачастую не можем вмешиваться, а только давать рекомендации. Наше же дело
> как можно лучше предусмотреть потенциальные ошибки.

Есть техническое задание, которое _уже_ учитывает информационный стандарт. Задача кодера - его реализовать. Без затей и отсебятины. И не нужно предусматривать потенциальных ошибок, - консультанты предметной области знают предметную область как бы сильно лучше кодера. Ы?

> Ну правовую форму то выделить можно, только пользователи ее все равно иногда
> вводят (на всякий случай).

Дружище, это одноразовая акция: такой пользователь при первой ошибке предупреждается, при второй - увольняется. Ибо незачем платить деньги даунам.

> Чем больше элементов сравнения, тем естественно, большая достоверность.

В случае предприятий единственный критерий достоверности - соответствие регистрационным данным и уставным документам. Все. И никакие дополнительные проверки достоверности Вам не добавят.

> дык я-то не "кодер".

Тогда Вы должны бы иметь представление о том, что печать юридического лица не обязана быть уникальной. Теоретически их может быть вообще любое количество.

> надеюсь именно на советы по организации, а не по кодированию!

В Вашем случае изобретать нечего. Типовая задача, типовая реализация.