Проверка налогового номера: что можно и чего нельзя

Проверка налогового номера — задача, у которой нет универсального решения. В одних странах номер устроен так, что ошибку в нём можно поймать арифметически, в других он просто присваивается по порядку, и никакой алгоритм не отличит верную запись от выдуманной. Ниже разберём, какие слои проверки вообще существуют, что каждый из них доказывает и как не превратить проверку в ложную уверенность.

Что такое налоговый номер

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

Устройство номера определяет страна. Где-то он чисто цифровой, где-то включает буквы, где-то содержит код региона или признак года. Название тоже различается: в разных языках это разные термины, и переводить их дословно не стоит.

Важно, что налоговый номер нельзя вывести из названия организации или из её адреса. Он не вычисляется и не наследуется: это отдельное присвоенное значение, и знание названия ничего не даёт для его предсказания.

Есть и ещё одна особенность. Налоговый номер присваивается один раз и, как правило, не меняется при смене адреса, названия или владельцев. Организация может переехать и переименоваться, а номер останется прежним — именно поэтому он удобен как ключ для сверки записей, пришедших из разных источников.

Почему не все номера можно проверить алгоритмом?

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

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

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

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

Три слоя проверки

Слои удобно разделить, потому что каждый отвечает на свой вопрос.

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

Полезно помнить, что слои стоят по-разному. Формат проверяется мгновенно и без обращения наружу. Контрольный разряд считается так же быстро. А обращение к официальному источнику — это сетевой вызов: он занимает время, может отказать и обычно ограничен по частоте. Поэтому первые два слоя почти всегда идут перед третьим, чтобы не тратить внешние запросы на заведомо испорченные строки.

Что означает «проверка не прошла»

Одно и то же сообщение может скрывать три совершенно разные ситуации.

Первая — в строке опечатка. Это самый частый случай, и он исправляется пользователем за несколько секунд.

Вторая — для этой страны правило не реализовано, и система отвергает номер, который на самом деле верен. Это ошибка системы, а не данных, и она особенно неприятна тем, что наказывает добросовестного пользователя.

Третья — номер действительно не зарегистрирован. Это единственный случай, когда проверка даёт содержательный отрицательный результат.

На практике полезна и четвёртая ситуация: данных недостаточно. Пустое поле, номер из одного знака или значение, состоящее из недопустимых символов, — это не отказ, а именно нехватка входных данных, и сообщение должно приглашать к заполнению, а не сообщать о непригодности.

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

Какие ошибки встречаются чаще всего?

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

Вторая — потеря ведущих нулей. Номер, начинающийся с нуля, при сохранении в числовое поле этот ноль теряет, и корректная запись становится неотличима от испорченной.

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

Четвёртая — предположение, что номер уникален во всём мире. Он уникален внутри системы своего органа, и совпадение строк в разных странах ничего не означает.

Чем это отличается от проверки VAT

Номер VAT — это регистрационный номер в системе налога на добавленную стоимость. Он уже, чем налоговый номер вообще: в некоторых странах это один и тот же идентификатор, в других — два разных.

Практическое следствие простое: нельзя переносить правила одного на другой. Если система считает, что налоговый номер и номер VAT всегда совпадают, она будет ошибаться в обе стороны — и отвергать корректные данные, и принимать неверные.

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

Подробнее об этой паре рассказано в статье о форматах номера VAT.

Для разработчиков: сообщения об ошибках и следы

Формулируйте ошибки по слою, который их породил. Неверная длина и отсутствие подтверждения в реестре — разные сообщения, и пользователь должен видеть то, которое соответствует причине.

Храните с результатом проверки, какой слой её выполнил и когда. Без этого невозможно разобрать спорный случай: вы не сможете сказать, была ли запись отвергнута правилом формата или ответом внешнего источника.

Различайте состояния «недействительно» и «неизвестно». Сетевой отказ, таймаут и отсутствие правила для страны — это не отрицательный результат, а отсутствие результата, и интерфейс обязан показывать именно это.

Не считайте проверку разрешением. Успешная проверка номера не означает, что организация проверена, что счёт будет оплачен или что сделку можно проводить без дополнительного контроля.

И ведите след. Кто и когда менял номер, когда он проверялся и с каким результатом — эти сведения нужны и поддержке, и тем, кто разбирает инциденты. След стоит дешевле, чем восстановление истории задним числом.

Отдельно стоит решить, что делать с историческими записями. Если правило проверки поменялось, старые строки нельзя молча переоценивать: результат, полученный в момент занесения, и результат, полученный сейчас, могут различаться, и оба имеют смысл. Храните их отдельно, чтобы не потерять первоначальное состояние.

Что делать дальше

Возьмите три номера — короткий цифровой, с ведущим нулём и с разделителями — и прогоните через свою форму. Затем посмотрите, какие сообщения об ошибках вы получили и отличается ли причина в каждом случае. Это самый быстрый способ найти смешение слоёв. Собрать образцы для такой проверки можно в разделе генератора тестовых данных компании.

О родственных реквизитах рассказано в статьях о номере VAT и об идентификаторах LEI и DUNS, а о том, как это встраивается в проверку контрагента, — в чек-листе по проверке компании.

Материал описывает общие принципы проверки и не содержит налоговых консультаций; примеры вымышлены и приведены для тестирования программных форм.