Сверка криптоплатежей — это подтверждение того, какие проверенные поступления относятся к каким заказам, и объяснение всех оставшихся расхождений. Один лишь баланс кошелька не показывает, что вы продали, какой клиент заплатил и был ли конкретный перевод вообще связан с продажей.
Используйте три взаимосвязанные записи: заказ, платежную запись провайдера и перевод, полученный вашим бизнесом. Это руководство предлагает небольшой команде продавца процедуру ежедневного закрытия, а не бухгалтерскую или налоговую консультацию. Описанные контрольные меры — рекомендации по ведению ваших собственных записей, а не утверждение о том, что Yolfi автоматически выгружает, сверяет или отражает платежи в учете.
Ведите заказы, платежные записи и переводы отдельно
Заказ описывает коммерческую договоренность. Платежная запись — запрос на оплату и его обработку. Перевод в блокчейне подтверждает движение актива. Эти записи связаны, но не взаимозаменяемы.
У одного заказа может быть несколько попыток оплаты. Одна транзакция может содержать несколько переводов токенов. Перемещение средств между вашими кошельками — не еще один платеж клиента. Храните эти связи, а не пытайтесь втиснуть каждую строку в модель «один заказ — один хеш».
| Запись | Минимальный набор сохраняемых полей | На какой вопрос отвечает |
|---|---|---|
| Заказ | Номер заказа, идентификатор клиента, валюта и сумма счета, состояние заказа | Сколько должен был заплатить клиент? |
| Запрос на оплату | Идентификатор у провайдера, связанный заказ, запрошенные актив и сеть, адрес назначения, сумма и срок действия, если применим | Какие инструкции были выданы? |
| Проверенный перевод | Сеть, идентификатор актива, хеш транзакции, позиция перевода, если применима, получатель, сумма, блок и доказательства подтверждения | Что фактически поступило? |
| Распределение | Идентификатор перевода, номер заказа, зачтенная сумма, проверяющий и время | Какое поступление погасило какое обязательство? |
| Корректировка | Идентификатор возврата или внутреннего перевода, причина, согласование и связанная запись | Почему движение средств отличается от продаж? |
Храните персональные данные клиентов в деловых записях с ограничением доступа, а не в публичных примечаниях в блокчейне. Никогда не сохраняйте приватные ключи или фразы восстановления в таблице сверки.
Идентифицируйте перевод, а не только тикер или хеш
Для токенов сохраняйте не только тикер, но и сеть, а также проверенный адрес контракта или mint-адрес. Надписи USDC недостаточно, чтобы различить активы в разных сетях или посторонний токен с тем же обозначением. Прежде чем принимать поступление, проверяйте идентификаторы по авторитетному источнику данных об активе.
Для перевода токена в EVM практичный уникальный идентификатор состоит из идентификатора сети, хеша транзакции и индекса лога вместе с проверенным контрактом токена. Сам по себе хеш транзакции недостаточно точен, если транзакция создает несколько событий перевода. В других сетях нужны соответствующие им идентификаторы инструкций или событий; не навязывайте формат EVM всем сетям.
Документация Ethereum JSON-RPC разграничивает квитанции транзакций, статус и логи. Для платежа ERC-20 проверяйте нужное событие перевода токена: получателем на верхнем уровне транзакции может быть контракт, а не адрес продавца. Успешная транзакция сама по себе не доказывает поступление ожидаемого актива в нужной сумме.
Если вы используете сервис истории переводов, сохраняйте параметры выборки и все страницы результатов. Метод Etherscan для переводов токенов предоставляет фильтры по сети, адресу, контракту, диапазону блоков и страницам. Первая страница — не полный реестр за день. Данные обозревателя блокчейна служат вспомогательным доказательством, но не заменяют распределение поступлений по заказам.
Выполняйте ежедневное закрытие в установленном порядке
1. Задайте границы периода и соберите записи
Выберите часовой пояс бизнеса и точный отчетный интервал, включая начальный момент и исключая конечный. Сохраните и сам интервал, и временные метки UTC, использованные в запросах. Укажите, группирует ли отчет переводы по времени блока, времени подтверждения провайдером или другому документированному основанию.
Соберите заказы и платежные записи за период, а также незакрытые позиции прошлых периодов. Получите переводы по каждому адресу приема средств и поддерживаемой сети из доступных вам записей или проверенных данных блокчейна. Не предполагайте наличие конкретной функции экспорта в панели управления или API, пока не проверите это.
Сохраняйте время получения данных и диапазон блоков. Перевод, замеченный у границы периода, может удовлетворить вашей политике подтверждений лишь позже; оставьте его в ожидании, а не меняйте доказательства за предыдущий день без объяснения.
2. Приведите данные к единому виду без потери точности
Храните количество актива отдельно от стоимости счета в местной валюте. Суммы токенов сохраняйте точно: в минимальных единицах либо в десятичном виде с проверенной точностью. Не складывайте USDC в разных сетях в один баланс без пояснений и не смешивайте USDT с USDC лишь потому, что оба ориентированы на стоимость доллара.
Если для учета нужна стоимость в местной валюте, сохраняйте источник оценки, временную метку и метод, предусмотренный вашей учетной политикой. Тикер стейблкоина — не указание учитывать каждое поступление строго по одному доллару США. Узнайте у бухгалтера, как учитывать комиссии и изменения стоимости в вашей юрисдикции.
3. Сопоставляйте и распределяйте без повторного зачета
Начните с надежных идентификаторов заказа и провайдера. Прежде чем зачесть поступление, проверьте актив, сеть, получателя, сумму и доказательства подтверждения. Если в нескольких заказах запрошена одинаковая сумма, одной суммы и времени недостаточно для установления личности клиента.
Обеспечьте уникальность каждой записи перевода и не допускайте распределения сверх доступной суммы. Одно поступление можно разделить между несколькими согласованными зачетами только тогда, когда это допускает ваш бизнес-процесс и контролируется общая сумма. Повторное получение одного уведомления не должно создавать второе поступление или повторно разрешать исполнение заказа.
4. Отделите исключения от итогов закрытия
Не скрывайте несопоставленные поступления, неоплаченные заказы и ожидаемые подтверждения. Назначьте для каждого расхождения ответственного, укажите причину и следующее действие. Разбирайте споры о сумме по руководству по недоплатам и переплатам, а не создавайте на ходу еще один запрос на полную оплату.
При несовпадении актива или сети обращайтесь к руководству по платежам в неверной сети. Исключение не считается устраненным только потому, что кто-то изменил цвет ячейки в таблице.
5. Сверьте движение средств и подтвердите закрытие
Для каждого актива в каждой сети объясните переход от начального остатка к конечному с помощью проверенных поступлений и списаний. Отдельно классифицируйте поступления от продаж, возвраты, внутренние переводы и прочие движения. Учитывайте сетевые комиссии в том активе, который фактически потрачен; не вычитайте незаметно комиссию за газ в нативной монете из поступления в стейблкоине.
Используйте эту сверку остатков для проверки полноты данных, а не для расчета выручки. Даже если остатки сходятся, это не доказывает правильность распределения по каждому заказу; признание выручки может подчиняться другим правилам учета.
Пример закрытия без выдуманных данных клиентов
В этом условном примере используется один актив USDC в одной сети. Все движения соответствуют выбранным границам периода и политике подтверждений.
| Движение средств | USDC |
|---|---|
| Начальный остаток | 400 |
| Проверенные поступления от клиентов | +250 |
| Перевод с другого кошелька компании | +100 |
| Согласованный возврат клиенту | -20 |
| Перевод на другой кошелек компании | -150 |
| Конечный остаток | 580 |
Остаток вырос на 180 USDC, но поступления от клиентов составили 250 USDC. Ни одна из этих сумм автоматически не равна признанной выручке. Внутренние переводы меняют баланс этого кошелька, не создавая продаж; возврат остается связанным с исходным заказом. Сетевые комиссии в нативной монете относятся к отдельной сверке остатков этого актива.
Проверяющий также должен убедиться, что каждая часть 250 USDC распределена по заказам либо явно отнесена к неразрешенным позициям. Согласованность начального и конечного остатков не выявит поступление, ошибочно зачтенное другому клиенту.
Место Yolfi в цепочке записей
На странице платежных ссылок Yolfi описаны создание платежных ссылок, отслеживание платежей и получение средств непосредственно на свой кошелек. Это дает продавцу контекст запроса на оплату вместе с поступлениями на кошелек, но не отменяет необходимости связать эти записи с заказами.
Перед приемом реального платежа проверьте актив, сеть и адрес получения, предлагаемые в вашей фактической конфигурации. Сохраняйте доступный вам идентификатор платежа и собственный номер заказа. Прежде чем проектировать автоматическую сверку, проверьте, какие записи предоставляет ваша текущая интеграция. Не делайте выводов о форматах экспорта, бухгалтерских интеграциях или правилах сопоставления по публичной маркетинговой странице.
Для сервисных компаний, принимающих авансы или оплату по этапам, коммерческая сторона описана в руководстве по платежным ссылкам для фрилансеров. Храните согласованный объем работ вместе с доказательствами оплаты, чтобы не принять аванс за полную оплату проекта.
Частые вопросы
Можно ли сверять платежи только по балансам кошельков?
Нет. Балансы помогают проверить движение средств, но не объясняют, к какому заказу относится поступление, где внутренние переводы, какие обязательства еще не погашены и является ли поступление выручкой.
Всегда ли один хеш транзакции означает один платеж?
Нет. Одна транзакция может включать несколько переводов. Сохраняйте сеть и подходящий для нее идентификатор перевода, а затем зачитывайте нужное поступление по правильному заказу.
Что делать, если платеж подтвердился после границы отчетного дня?
Сохраните исходную запись о наблюдении и проведите позицию через документированный переход от ожидания к подтверждению. Используйте единое основание для отчетности и сохраняйте историю исправлений, вместо того чтобы незаметно переписывать закрытый период.
Нужно ли для сверки автоматизированное бухгалтерское ПО?
Не обязательно. При небольшом объеме подойдет таблица с надлежащим контролем, если в ней сохраняются точные суммы, уникальные идентификаторы, доказательства и история проверки. Переходите к базе данных или бухгалтерской интеграции, когда объем операций или риск ошибок делают ручной контроль ненадежным.
Закрывайте день по доказательствам, а не ради нулевого расхождения
Полезный результат ежедневного закрытия — сопоставленные поступления, классифицированные движения кошелька и короткий список исключений с назначенными ответственными. Для этого не нужно скрывать нерешенные позиции. Начните с понятных инструкций по оплате через платежную ссылку, сохраняйте связь с заказом и определяйте возможность закрытия по проверенным доказательствам перевода.
