Криптовалютные расчёты между компаниями: как выстроить процесс

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

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

Почему одного адреса кошелька для B2B-расчётов мало

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

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

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

• контрагент;
• основание платежа;
• сумма;
• валюта расчёта;
• используемая сеть;
• связанный договор или заказ;
• срок действия реквизитов;
• текущий статус;
• внутренний идентификатор сделки.

Тогда перевод перестаёт быть отдельной записью в блокчейне и становится частью понятного бизнес-процесса.

Платёж должен быть связан с конкретным обязательством

Одна из ключевых задач B2B-расчётов — сопоставить поступившие средства с тем, что происходит внутри компании.

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

При структурированной схеме каждому платежу заранее присваивается внутренний идентификатор. Он может соответствовать номеру договора, заявки, заказа, проекта или счёта. После поступления средств система уже знает, к какой операции относится транзакция.

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

Что должно происходить после оплаты

Подтверждение платежа редко является конечной точкой процесса. Обычно после него запускается следующее действие:

• заказ переводится в оплаченный статус;
• менеджеру приходит уведомление;
• начинается оказание услуги;
• открывается доступ к цифровому продукту;
• запускается очередной этап проекта;
• формируется задача на выплату подрядчику;
• информация передаётся в CRM или другую внутреннюю систему.

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

Инвойс и бухгалтерские документы выполняют разные задачи

В криптовалютных расчётах термин «инвойс» иногда создаёт путаницу. Платёжный инвойс и бухгалтерский документ не всегда являются одним и тем же.

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

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

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

Выбор валюты и сети нельзя оставлять за пределами процесса

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

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

Поэтому контрагенту необходимо заранее и однозначно показать:

• какую валюту нужно перевести;
• какую сеть использовать;
• точную сумму;
• адрес получателя;
• срок действия реквизитов;
• правила действий при отклонении от указанной суммы.

Чем меньше этих параметров передаётся вручную, тем ниже риск ошибки.

Почему реквизиты лучше формировать под конкретный расчёт

Постоянный адрес кошелька удобен своей простотой, но усложняет идентификацию платежей. Отдельный платёжный сценарий позволяет заранее связать реквизиты с конкретной сделкой.

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

Статус платежа должен попадать во внутреннюю систему

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

В корпоративной инфраструктуре статус операции обычно передаётся автоматически. Получателем может быть CRM, ERP, личный кабинет клиента, система управления заказами или собственная внутренняя платформа.

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

Каждый статус должен иметь понятное значение для сотрудников и автоматических процессов.

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

Недоплата и переплата требуют заранее заданных правил

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

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

Компании полезно установить внутренний порядок:

• какое отклонение считается допустимым;
• можно ли автоматически засчитывать небольшую недоплату;
• как учитывается переплата;
• что делать при повторном переводе;
• кто принимает решение в спорной ситуации;
• как фиксируется возврат средств.

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

Криптовалютный расчёт затрагивает не только приём средств

B2B-модель нередко включает движение средств в обе стороны. Компания получает оплату от клиента, а затем рассчитывается с подрядчиком, партнёром или исполнителем.

Такой сценарий характерен для агентств, маркетплейсов, платформ, партнёрских программ и компаний с распределёнными командами. При этом требования к исходящим операциям отличаются от обычного перевода сотрудником с кошелька.

Выплата должна иметь основание

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

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

Это снижает риск случайного перевода на неверный адрес и помогает поддерживать историю действий.

Проверка адресов и AML-процедуры

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

AML-проверка не превращает платёж в полностью безопасный сама по себе. Она является одним из элементов внутреннего контроля и должна использоваться вместе с другими процедурами проверки контрагентов.

Для компании важно заранее определить, что происходит при обнаружении повышенного риска. Простого отображения предупреждения недостаточно, если сотрудники не знают, кто должен его рассматривать и какое решение может быть принято.

В зависимости от внутренней политики операция может:

• пройти дополнительную проверку;
• быть временно приостановлена;
• потребовать подтверждения ответственного сотрудника;
• сопровождаться запросом дополнительных сведений.

Конкретный порядок зависит от характера бизнеса, юрисдикции и уровня допустимого риска.

Интеграция с CRM меняет роль платежа

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

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

Для менеджера это означает, что не требуется вручную искать транзакцию по адресу и сумме. Для руководителя появляется единая история действий по клиенту.

Вебхуки и повторная обработка событий

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

Здесь появляется важная инженерная задача: одно и то же событие не должно запускать операцию несколько раз.

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

Кто отвечает за платёж внутри компании

Даже хорошо настроенная техническая инфраструктура не решает вопрос распределения ответственности.

До запуска B2B-расчётов полезно определить, какие сотрудники выполняют отдельные действия. Менеджер может создавать платёж, финансовый специалист — контролировать поступления, а техническая система — автоматически менять статус сделки.

Для нестандартных ситуаций требуется отдельный порядок. Кто разбирается с ошибочной сетью? Кто принимает решение по возврату? Кто может изменить реквизиты подрядчика? Кто подтверждает крупную выплату?

Без этого спорные случаи начинают решаться через переписку, а действия сотрудников оказываются плохо документированы.

История операций должна быть понятна не только техническому специалисту

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

Сотруднику важно видеть не только хеш транзакции, но и понятное описание:

• какой контрагент участвовал в расчёте;
• с какой сделкой связана операция;
• кто создал платёж;
• какая сумма ожидалась;
• сколько фактически поступило;
• когда произошло подтверждение;
• какие действия система выполнила после оплаты.

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

Юридические и налоговые вопросы остаются отдельной частью работы

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

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

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

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

Что следует определить до запуска B2B-расчётов

Подготовку лучше начинать не с выбора кошелька или API, а с описания полного пути платежа.

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

Перед запуском стоит зафиксировать:

• кто создаёт платёжные реквизиты;
• где хранится связь операции с договором или заказом;
• какие валюты и сети разрешены;
• сколько времени действуют реквизиты;
• какие статусы используются;
• как обрабатываются недоплата и переплата;
• кто разрешает возвраты;
• каким образом проверяются входящие операции;
• как согласуются выплаты;
• какие данные передаются в CRM;
• кто отвечает за нестандартные ситуации.

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

Почему B2B-криптоплатёж — это не просто транзакция

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

Платёж связан с клиентом, договором, внутренним номером сделки, документами, статусами в CRM и последующим исполнением обязательств. Иногда после него возникают исходящие выплаты, проверки или дополнительные согласования.

Именно эта связность определяет качество B2B-процесса. Если сотрудники видят только кошелёк и список транзакций, значительная часть работы остаётся ручной. Если каждая операция имеет понятное назначение, автоматически связывается со сделкой и передаёт актуальный статус во внутренние системы, криптовалютный расчёт становится полноценной частью корпоративной инфраструктуры, а не отдельным способом перемещения средств.