Как цифровой платформе внедрить номинальный счет

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

Для этого нужно заложить:

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

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

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

Использование расчетного счета на старте работы может быть оправданно:

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

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

• ФНС видит дисбаланс: большие обороты по счету и мало налогов. Это повод задуматься почему и капнуть в договорную модель «точно ли вы агент?»;
• любое взыскание может быть обращено и на деньги, которые по сути являются деньгами селлера и лишь временно находятся на счете платформы;

Решить задачи нового этапа позволяет смена способа расчетов и использование «номинального счета».

Внедрение номинального счета мы обсуждали на совместном вебинаре «Зарцын и партнеры»  и Точка Банка.

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

Разберу вопросы, которые задавались чаще всего.

Когда платформе нужен номинальный счет

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

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

За счет этого можно отделить:

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

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

Сначала необходимо определить роль платформы в отношениях пользователей. Она может быть:

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

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

Чем номинальный счет отличается от обычной агентской модели

Номинальный счет и агентский договор решают разные задачи.

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

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

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

Являются ли все поступления доходом платформы

Это один из главных вопросов собственников и финансовых директоров. Ведь это вопрос безопасности собственника в том числе тк налоговые претензии сейчас могут обернуться не просто доначислением, а в том числе уголовными преследованием. 
 Средства бенефициаров на номинальном счете не  становятся  доходом его владельца — это прямо следует из правового режима счета, закрепленного в ГК РФ.

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

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

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

Как учитывать деньги на номинальном счете

На практике встречаются разные подходы:

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

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

Какие данные придется передавать банку

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

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

Платформе может потребоваться собирать и передавать:

• идентификационные данные физического лица (включая паспортные данные, ИНН, дата рождения);
• сведения об ИП или юридическом лице;
• реквизиты для выплаты

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

Во-вторых, в документах необходимо определить основания для передачи данных банку и проинформировать об этом пользователя. Не забудьте синхронизировать эти процессы с законодательством о персональных данных.

В-третьих, нужно разграничить ответственность. Платформа может передавать полученные от пользователя сведения, но она не всегда способна самостоятельно проверить их достоверность в полном объеме.

Можно ли работать с физлицами, самозанятыми, ИП и компаниями

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

Для каждой категории могут отличаться:

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

Особенно внимательно необходимо проектировать работу с самозанятыми.

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

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

Кто должен формировать кассовый чек

Вопрос о чеках участники вебинара задавали особенно часто.

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

Возможны разные конструкции:

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

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

Кроме того, нужно определить, что происходит при:

— полной отмене заказа;

— частичном возврате;

— удержании комиссии;

— изменении состава заказа;

— выплате нескольким исполнителям;

— доплате или корректировке стоимости.

Сплитование платежа усложняет не только исходную операцию, но и все последующие корректировки.

Как организовать возвраты и спорные операции

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

Реальная жизнь сложнее.

Покупатель может отказаться от заказа. Исполнитель может выполнить его частично. Стороны могут спорить о качестве. Часть суммы уже могла быть выплачена, а часть — оставаться на счете.

До запуска необходимо ответить на вопросы:

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

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

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

Как должна выглядеть интеграция с банком

Интеграция — это не только команда на перечисление денег.

Платформа и банк обмениваются данными о:

• создании заказа;
• поступлении оплаты;
• составе платежа;
• бенефициарах;
• размере комиссии;
• готовности к выплате;
• возврате;
• отмене;
• ошибке или приостановлении операции.

Для каждой операции должны существовать понятные статусы и идентификаторы.

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

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

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

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

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

Какие документы нужно изменить

Открытие номинального счета почти всегда требует пересмотра документов платформы.

Ключевая задача документов — не просто упомянуть номинальный счет. Они должны объяснять всю модель:

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

Практический пример: номинальный счет для реферальной программы

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

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

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

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

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

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

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

Этот пример показывает: сам по себе номинальный счет не решает задачу расчетов. Рабочая модель появляется только тогда, когда банк, договоры, бухгалтерский учет и IT-система одинаково описывают движение денег.

Чек-лист внедрения номинального счета 

Последовательность действий для внедрения номинального счета выглядит так: 

1. Описать роли всех участников.

2. Построить схему основной сделки.

3. Разложить движение денег по этапам.

4. Определить принадлежность каждой суммы.

5. Проверить налоги, учет и чеки.

6. Определить требования к данным бенефициаров.

7. Сопоставить модель с возможностями банка.

8. Подготовить документы.

9. Зафиксировать статусы и сценарии интеграции.

10. Протестировать обычные и исключительные операции.

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

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