Распознавание платежей с помощью кода УИН
В российской практике банковские платежи идентифицируются чаще всего только по ИНН плательщика, а назначение платежа не кодируется и может быть заполнено любым образом. Особую сложность составляют входящие платежи. Так, многие крупные корпорации создают целые отделы бухгалтерии, занимающиеся исключительно расшифровкой таких операций. Поэтому корректное и автоматическое отслеживание входящих платежей открывает перед компаниями новые возможности для сокращения расходов и снижения неопределенности.
Для упрощения идентификации входящих платежей было выделено поле 22 платежного поручения, которое предусматривает указание специального кода – так называемого кода УИП или УИН. Часто происходит путаница в этих двух идентификаторах, тем более что указываются они в одном и том же поле и имеют одинаковую длину (двадцать или двадцать пять цифр).
Определение кодам УИН и УИП дается в Приказе Минфина № 107н от 12.11.2013.
УИН — уникальный идентификатор начисления, используемый при оплате взносов, пошлин, штрафов, налогов и пр. Поэтому чаще всего данный код указывается при переводе платежей в госорганы.
УИП — это уникальный идентификатор платежей, используемый при переводе денег бюджетным учреждениям или если получатель платежа указал этот код по своей инициативе. Разница заключается в том, что сведения об УИН предоставляются получателем средств, в отличие от УИП, который помогает идентифицировать платеж среди других аналогичных перечислений. Этот уникальный реквизит присваивается платежке непосредственно госорганом, которому переводят суммы. УИП используется для определения платежа в банковской системе. Исходя из этого, можно сделать вывод, что для распознавания входящих платежей внутри организации необходимо использовать код УИН.
Важно указать, что не существует перечня, который содержит все УИНы той или иной организации. При формировании платежа указывать этот код следует только в том случае, если он известен. Ошибочное указание кода может повлечь за собой неверный перевод денежных средств. Если код неизвестен, необходимо указывать «0». Оставлять поле 22 платежного поручения без заполнения недопустимо, поскольку платеж может не пройти из-за требований банка.
Формирование кода УИН выполняется непосредственно получателем платежа. Т. е. компания формирует код и передает его контрагентам-плательщикам, которые могут указывать его при выполнении оплаты через банк. Для каждого платежа разрабатывается своя уникальная комбинация символов, которая никогда больше не повторяется. Как пример, на рис. 1 изображен вариант формирования УИН для теплоэнергетического холдинга.
Рис. 1. Формирование кода УИН в теплоэнергетическом холдинге
При переходе на использование такого идентификатора, как УИН, чаще всего используются основные принципы для генерации кодов:
1. Код УИН генерируется только для определенных расчетных счетов предприятия
2. Код УИН генерируется при создании карточки доходного договора сразу после ввода платежных реквизитов и сохранения
3. Система автоматически контролирует уникальность кода УИН
4. Для всех действующих договоров код УИН формируется автоматически (в случае, если указан нужный расчетный счет).
Для автоматического определения входящих платежей при загрузке банковской выписки в ERP-систему предполагается указание кода УИП в конкретном договоре, который сопоставляется при разнесении позиций выписки в систему. При совпадении кода УИП в платеже и в договоре внутри системы выполняется автоматическая проводка платежа. При нахождении позиций для выравнивания проводится выравнивание с необходимым документом по найденному договору.
Однако, несмотря на все существенные плюсы использования идентификатора УИП, существует и достаточно большая проблема на пути его внедрения. Для перехода к использованию данного кода необходимо осуществить большую подготовительную работу. Следует в том числе переговорить со всеми (или большинством) контрагентов, чтобы при работе с вашей организацией они использовали данный идентификатор. Также необходимо обучить их алгоритму формирования идентификатора, и, скорее всего, это повлечет дополнительные расходы со стороны контрагента, которому потребуется потратить ресурсы на доработку своего программного обеспечения.