Отчет о торговой информации клиентов CARF: какие данные необходимы для обработки от блокчейна до налоговой декларации?

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

Автор: FinTax

Ключевая информация:

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

Отчет о торговой информации клиентов CARF: какие данные нужны помимо блокчейн-транзакций?

Регулирующие положения ЕС DAC8 о отчетности по криптоактивам вступают в силу с 1 января 2026 года, 2026 год станет первым отчетным годом. Торговые платформы должны постоянно собирать данные о клиентах и торговых данных, а также преобразовывать записи, разбросанные по кошелькам, счетам и бизнес-системам, в отчетную информацию. Процесс налоговой декларации по криптоактивам на платформе требует поэтапного определения, к кому относятся записи, какие сделки произошли, какая стоимость была использована и как сформировать окончательный отчет.

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

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

Интеграция данных CARF: связь блокчейн-транзакций с внутренними записями платформы

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

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

Время и идентификация активов должны быть унифицированы при интеграции. Например, если две системы используют местное время и всемирное координированное время (UTC), одна и та же сделка в конце года может отображаться с разными датами; при извлечении данных необходимо сохранить часовой пояс и выполнить унифицированное преобразование. Код актива также соответствует сети, к которой он принадлежит, и адресу контракта. Унифицированные записи используются для последующей связи субъектов, классификации сделок и проверки сумм.

Идентификация клиентов CARF: связь адресов кошельков, счетов и налоговых идентификаторов

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

Связь субъектов также включает идентификацию налоговых идентификаторов. В соответствии с руководством по проверке добросовестности HMRC Великобритании, поставщики услуг по отчетности по криптоактивам должны получить самодекларацию от пользователей и идентифицировать пользователей, подлежащих отчетности. Некоторые юридические лица также должны идентифицировать контролирующих лиц, чтобы определить, являются ли они подлежащими отчетности. Существующие данные по идентификации клиентов (KYC) используются для проверки разумности декларации, информация о налоговом резидентстве в декларации должна быть сопоставлена с данными о регистрации. Компания должна связать декларацию, результаты проверки и дату изменений с основным файлом клиента.

Связь между счетом и субъектом также должна соответствовать конкретному периоду. Например, если клиент получает новый номер счета после миграции системы, исторические сделки все еще сохраняют старый номер, при проверке необходимо подтвердить принадлежность записей через сопоставление старого и нового номеров. Если существуют различия в данных клиента, необходимо проверить причины с помощью декларации и подтверждающих материалов. Руководство HMRC Великобритании требует получения новой декларации для тех, которые больше не соответствуют требованиям разумности, или получения доказательств, поддерживающих оригинальную декларацию. Сопоставление счетов и проверка налоговых данных должны сохранять записи обработки отдельно.

Классификация сделок CARF: отображение изменений активов в категории отчетности

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

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

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

Оценка сделок CARF: определение времени оценки, источника цен и методов пересчета

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

Руководство CARF Великобритании по оценке переводов требует использовать справедливую рыночную стоимость на момент сделки, отчитываясь в единой валюте, и применять методы, основанные на доступных доказательствах, разумных и последовательных. Руководство отдает предпочтение использованию применимых внутренних торговых данных; при отсутствии соответствующих ссылочных значений необходимо последовательно использовать внутреннюю балансовую стоимость, данные агрегирования цен от третьих лиц, последнюю внутреннюю оценку, и только в последнюю очередь использовать разумные оценки. При использовании вышеуказанных альтернативных методов необходимо указать метод в XML-отчете и сохранить источник цен, время котировки и обоснование выбора в рабочем документе.

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

Проверка данных CARF: сверка балансов счетов, классификации сделок и отчетных сумм

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

Для вышеуказанных сделок проверяющий должен быть в состоянии проследить от пополнения ETH через обмен и вывод BTC до того, как эти записи попадают в сводный отчет; также можно проверить сводную сумму, чтобы подтвердить, нет ли пропусков или дублирующих сборов. В случае обнаружения различий необходимо записать причины, область влияния, способы исправления и результаты проверки. Финансовая команда объясняет суммы и обоснования расчетов, команда комплаенса проверяет диапазон отчетности и классификацию, команда данных предоставляет записи извлечения и преобразования, а неразрешенные различия должны быть назначены ответственному лицу и проверяющему.

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

Генерация и подача отчета CARF: сопоставление полей, проверка XML и исправления

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

Согласно руководству по подаче отчетов Великобритании, первый отчет, охватывающий 2026 год, должен быть подан до 31 мая 2027 года. Отчетный документ должен быть в формате XML и одновременно соответствовать требованиям схемы OECD и документам HMRC. После завершения проверки формата команда также должна проверить диапазон пользователей, классификацию сделок и сводные суммы, завершить внутреннее одобрение и подачу. Версия подачи, квитанция и соответствующий рабочий документ должны быть сохранены вместе. HMRC Великобритании четко указывает, что при передаче третьей стороне ответственность за точность и полноту информации все равно остается за субъектом отчета.

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

Различия в отчетности CARF и DAC8: различие между отчетом о торговой информации клиентов и расчетом корпоративного налога

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

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

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

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

Часто задаваемые вопросы FAQ

Можно ли завершить отчет о торговой информации клиентов CARF, полагаясь только на блокчейн-транзакции?

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

Можно ли напрямую исключить записи, помеченные как «внутренний перевод», из классификации сделок CARF?

Ярлык «внутренний перевод» недостаточен для определения обработки отчета. Необходимо подтвердить субъектов, обслуживающих счета, и бизнес-отношения, различая перераспределение собственных кошельков компании и перемещение активов клиентов, а затем классифицировать в соответствии с отчетными правилами.

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

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

Завершение проверки XML-файла отчета CARF означает, что подача завершена?

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