84.534 
2.665 
Учёт поступлений строится вокруг одного принципа: каждая транзакция должна быть привязана к конкретному клиенту и конкретному счёту, и в блокчейне поступления обезличены — вы видите адрес отправителя и сумму, но не видите, за что платили. Решают эту задачу отдельными адресами под каждого клиента или под каждый счёт, и такой подход экономит недели разбирательств при сверке.
Почему обычная схема не работает
Один адрес на всех клиентов создаёт проблему опознания, а при совпадающих суммах невозможно определить, кто именно заплатил, а при частичных оплатах картина запутывается окончательно. Добавьте сюда переводы с биржевых адресов, где отправитель виден как площадка, а не как ваш клиент.
Ручное сопоставление работает при единичных сделках, и на десятках платежей в месяц оно превращается в источник ошибок.
Сравнение способов идентификации
| Способ | Как работает и что учесть |
|---|---|
| Отдельный адрес на клиента | Поступления сразу опознаются, требует генерации и учёта адресов |
| Отдельный адрес на каждый счёт | Максимальная точность, больше адресов в управлении |
| Уникальная сумма с копейками | Работает без новых адресов, ломается при совпадении сумм |
| Метка назначения в сетях, где она есть | Штатный механизм, поддерживается не всеми сетями |
Как выстроить процесс
Заведите правило: адрес выдаётся под конкретное обязательство и больше не переиспользуется, при этом ведите реестр соответствия между адресом, клиентом, номером счёта и ожидаемой суммой. После поступления сверьте четыре параметра — адрес, сумму, сеть и число подтверждений, затем закройте счёт в учётной системе.
Автоматизируйте сверку при регулярных платежах. Обозреватели отдают данные по адресу в машинном виде, и скрипт справится с рутиной точнее человека.
Что фиксировать по каждому поступлению
- Хэш транзакции и адрес отправителя
- Дату и время зачисления с указанием часового пояса
- Сумму в токенах и рублёвую оценку по курсу на дату
- Номер счёта или договора, который закрывает платёж
Ко мне обращалась компания, принимавшая оплату на один адрес от двух десятков клиентов, причём при квартальной сверке шесть платежей остались неопознанными: суммы совпадали, а отправители переводили с биржевых адресов. Установить плательщиков удалось только перепиской с каждым клиентом, и на это ушло больше недели работы бухгалтера.
Поступления с биржевых адресов
Клиент, выводящий средства прямо с биржи, отправляет их с адреса площадки, а не со своего, и определить плательщика по отправителю в таком случае невозможно, и это ещё один аргумент за выделенные адреса.
Предупредите клиентов заранее. Просьба переводить с личного кошелька упрощает сверку обеим сторонам, хотя и не всегда выполнима.
Частичные оплаты и переплаты
Частичное поступление фиксируют как частичное закрытие обязательства со ссылкой на хэш, а не держат в переписке, тогда как переплату либо возвращают отдельной транзакцией, либо зачитывают в счёт следующего платежа — решение принимают письменно. Комиссию за возврат оговаривают заранее, иначе она превращается в предмет спора.
Автоматизация сверки
При потоке платежей ручная проверка перестаёт справляться. Обозреватели отдают историю по адресу в машинном виде, и простой скрипт способен раз в час опрашивать список адресов, сверять поступления с реестром и отмечать закрытые счета.
Готовые платёжные сервисы делают то же самое с уведомлениями и панелью управления, но берут комиссию и требуют доверия к посреднику. Для небольшого потока собственный скрипт обходится дешевле и не добавляет третью сторону в процесс.
Рублёвая оценка для учёта
Каждое поступление пересчитывают в рубли по курсу на дату перехода прав, а эту величину фиксируют сразу: восстанавливать исторические котировки через месяцы неудобно, а по малоликвидным парам ещё и спорно. Курсовые разницы между датой счёта и датой поступления отражают отдельной статьёй.
Хранение реестра
Реестр соответствия адресов и обязательств — рабочий документ, а не временная таблица, и храните его там же, где остальная учётная информация, с копией вне основного компьютера. Потеря реестра не лишает доступа к средствам, но делает историю поступлений нечитаемой.
Сверка с клиентом
Акт сверки с приложением хэшей транзакций снимает большинство разногласий, при этом клиент видит те же записи в блокчейне, что и вы, и спорить о факте платежа не приходится. Разногласия остаются только по суммам комиссий, и этот вопрос решают формулировкой в договоре о сумме к получению.
Смежные темы разобраны у нас. Вот основные. Общий раздел — платежи и бизнес. Шире — статьи про криптокошельки. Подтверждение платежа разбирает материал как подтвердить поступление оплаты, а курсовые разницы — статья как учитывать курсовые разницы при оплате.
Вопросы и ответы
Сколько адресов нужно заводить?
Зависит от числа клиентов и частоты платежей, причём для небольшой компании достаточно адреса на клиента, для потока счетов — адреса на каждое обязательство, и современные кошельки генерируют адреса из одной seed-фразы, поэтому их количество не усложняет хранение ключей.
Можно ли опознавать платежи по уникальной сумме?
Способ рабочий для небольшого потока: клиенту называют сумму с уникальными копейками, а но при росте числа счетов вероятность совпадения увеличивается, а комиссия, вычтенная отправителем, ломает точное соответствие. Отдельные адреса надёжнее.
Что делать с платежом от неизвестного отправителя?
Не зачитывать его в счёт чьего-либо обязательства до выяснения, при этом запишите поступление как неопознанное и запросите подтверждение у клиентов с открытой задолженностью, причём ошибочное закрытие чужого счёта создаёт расхождение, которое всплывёт при следующей сверке.
Вердикт
Отдельный адрес под каждого клиента или счёт — единственный способ опознавать платежи без ручного расследования, и реестр соответствия ведут с первого дня, а не заводят после первой путаницы. Рублёвую оценку фиксируйте в момент поступления: задним числом это неудобно и спорно. Акт сверки с хэшами транзакций закрывает разногласия с клиентом быстрее любой переписки.
Транзакции проверяйте напрямую. Блокчейн-обозреватель Etherscan и официальные курсы валют Банка России дают данные для сверки поступлений и рублёвой оценки.
Обсуждение
Добавить комментарий