Новости криптомира

Легальный платёж в USDT — это не один txid, а целых пять версий одной сделки, которые обязаны совпасть. На практике операция срывается не столько из-за «грязного» актива, сколько из-за того, что договор, банк, комплаенс, бухгалтерия и налоговая функция описывают один и тот же перевод по-разному. Это фундаментальная проблема, которая требует системного подхода.

Возьмём сквозной пример: российская компания импортирует оборудование за $100 000, а поставщик готов принять 100 000 USDT. Для генерального директора это один платёж, но для каждой внутренней функции — отдельное событие со своим объектом, датой, стоимостью и набором доказательств.

Версия 1. Договор: момент платежа должен существовать не только в блокчейне

Хэш транзакции лишь подтверждает, что токены переместились между адресами. Он не отвечает на четыре юридических вопроса: кому принадлежал адрес получателя, в счёт какого обязательства выполнен перевод, какая сумма долга погашена и что происходит, если токены заморожены, возвращены или недоступны. Записи «оплата в USDT» в договоре недостаточно. Минимальная модель должна связывать цену товара, расчётный актив и доказательство исполнения, а также фиксировать валюту цены, конкретный токен, сеть, тип адреса, источник котировки, комиссии и момент исполнения обязательства. Особого внимания требуют реквизиты: адрес-идентификатор и блокчейн-сеть нужно прописывать в соглашении, а при смене — предусматривать процедуру согласования и запрет на замену одним письмом.

Версия 2. Валютный контроль и банк: экономический смысл важнее хэша

С 2024 года ЦБ РФ может устанавливать экспериментальный правовой режим для цифровой валюты во внешнеторговых расчётах, но это не общее разрешение платить с любого кошелька. Для банка сделка начинается с внешнеторгового договора, экономического основания и рублёвого денежного следа. Уполномоченный банк должен понимать, почему компания перевела рубли посреднику, какой актив приобрела, в каком количестве, кому и по какому контракту его передала. Если каждый документ существует отдельно и не содержит общего идентификатора, операция распадается на несвязанные фрагменты. В Инструкции ЦБ № 181-И уже есть коды для расчётов с цифровой валютой (99080, 99081), но код не заменяет экономическое содержание.

Версия 3. AML/KYT: надёжный контрагент может получить рискованный актив

В традиционном ВЭДе проверяют юрлицо, его владельцев, санкционный статус и деловую цель. В крипто-ВЭДе добавляется анализ адресов и истории движения актива — KYT. Качественный KYB не очищает историю токена, а низкий риск адреса не подтверждает реальность поставщика. Свести KYT к «цветному» индикатору нельзя: аналитические системы считают риск по собственной методологии, поэтому две системы могут дать разный результат. Проверку нужно выполнять минимум в трёх точках: при выборе источника ликвидности, перед приобретением актива и перед переводом получателю, так как история адреса может измениться. Особый риск USDT связан с эмитентом: заморозить адрес можно на уровне самого токена, поэтому «транзакция подтверждена» и «получатель окончательно располагает ценностью» — не всегда одно и то же.

Версия 4. Бухгалтерия: актив нужно увидеть до того, как его списать

Российские стандарты учёта пока не дают универсальной модели для всех видов цифровых активов. Учёт начинается с профессионального суждения: соответствует ли объект признакам актива, кто его контролирует, для какой цели он приобретён и как будет оцениваться. Это решение закрепляют в учётной политике до операции, а не после запроса аудитора. Для бухгалтерии важен полный жизненный цикл: компания перечисляет рубли посреднику, получает право на цифровой актив, контролирует его напрямую или через депозитарий, несёт комиссии и только потом передаёт актив поставщику. Если учёт отражает лишь рублёвый платёж и закрытие кредиторской задолженности, цифровой актив на коротком промежутке «исчезает».

Версия 5. Налоги: платёж поставщику — это выбытие имущества

С 1 января 2025 года цифровая валюта признаётся имуществом для целей НК РФ. Её реализация не образует объект НДС, налоговая база формируется отдельно по статье 282.3 НК РФ, переоценка не производится, а расходы требуют документального подтверждения. Передачу актива поставщику нельзя автоматически учитывать только как оплату оборудования. Если объект квалифицирован как цифровая валюта, его выбытие формирует самостоятельный налоговый результат: сравниваются стоимость приобретения и величина дохода. Критическая точка — источник цены и дата оценки: договор может фиксировать курс на момент выставления инвойса, посредник — на момент покупки, блокчейн — время включения транзакции, а налоговый регистр — дату реализации. Даже при стабильном USDT разные временные точки дают разные рублёвые суммы.

Мой экспертный вывод: одна операция — это пять рублёвых сумм, и расхождение само по себе не доказывает ошибку. Проблема возникает, когда компания не может построить мост между ними. Рекомендую формировать сводный реестр, который отдельно показывает курс, источник, дату, спред, комиссии и назначение каждой оценки. Тогда разница становится объяснимой частью модели, а без реестра она выглядит как неподтверждённый расход. Бизнесу стоит провести «сухой прогон» сделки на документах до движения денег: создать условный контракт, заявку, комплект проверок и проводки, а затем найти расхождения. Это дешевле заблокированной операции и полезнее общей политики на десятки страниц.