Как вести журнал криптотранзакций в 2026 году: TxID, себестоимость, документы и сверка

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

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

Для частного пользователя такой регистр особенно полезен, когда операции распределены между несколькими биржами, кошельками и банками. Блокчейн видит адреса и транзакции, но не знает, какие адреса принадлежат одному владельцу, зачем совершён перевод и каким банковским платежом была оплачена покупка. Биржа видит внутренние ордера, но не всегда показывает дальнейшую историю self-custody. Банк видит рубли, но не видит весь криптовалютный маршрут. Журнал соединяет эти источники в одну проверяемую цепочку.

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

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

Журнал, история кошелька и налоговый расчёт — не одно и то же

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

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

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

В использованных разъяснениях ФНС нет универсальной обязательной формы под названием «журнал криптотранзакций» для обычного физического лица. Поэтому структура регистра является практической методикой, а не утверждённым государственным бланком. Это даёт свободу выбрать таблицу или программу, но не отменяет требования к достоверности: суммы, даты и документы должны воспроизводиться из первичных источников.

Кому нужен журнал и когда простого списка операций уже недостаточно

Если человек один раз купил небольшую сумму на бирже и не выводил её, достаточно сохранить отчёт площадки и платёж. Журнал становится критически полезным, когда появляются разные источники и маршруты. Первый признак — актив перемещается между биржей и личными кошельками. Второй — покупки делаются частями по разным курсам. Третий — возникают продажи через P2P, обменники или несколько банков. Четвёртый — пользователь получает криптовалюту как оплату, подарок, вознаграждение или доход от деятельности.

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

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

• Более одной биржи или кошелька
• Покупки и продажи в разные даты
• Переводы между собственными адресами
• Обмен токена на токен
• P2P и банковские поступления
• Получение криптовалюты за работу или услугу
• Крупные суммы и запросы Source of Funds
• Необходимость готовить налоговый расчёт

Сначала определите единицу учёта

Наиболее частая методическая ошибка — пытаться вести журнал только по банковским платежам или только по блокчейн-транзакциям. У этих источников разные границы. Один P2P-ордер может быть оплачен двумя банковскими переводами. Один сетевой перевод может содержать несколько выходов, как в Bitcoin. Одна EVM-транзакция может запустить swap и породить несколько событий токенов. Поэтому единицей учёта лучше считать экономическое событие, а технические идентификаторы хранить как связанные реквизиты.

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

У каждой записи полезно иметь внутренний номер, например `2026-00417`. Если операция состоит из цепочки, добавляют родительский номер маршрута: `ROUTE-2026-031`. Тогда депозит, обмен и P2P-продажа остаются отдельными строками, но легко собираются в один кейс. Не используйте TxID как единственный внутренний номер: внутренние переводы биржи и банковские операции TxID не имеют, а один экономический маршрут может включать несколько хэшей.

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

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

Дата должна включать время и часовой пояс, когда это существенно. Биржа может показывать UTC, банк — московское время, а обозреватель — локальное время браузера. Для сверки лучше хранить исходную дату и нормализованное время UTC. Актив записывают не только тикером: для токенов полезны сеть и контракт. Два токена с названием USDT в разных сетях — разные технические объекты, хотя экономически они могут отражать один вид актива.

Количество фиксируют до комиссии и после неё. Стоимость — в валюте расчёта и в рублях по принятой методике. Для покупки указывают полные расходы, для продажи — фактический доход. Адреса записывают полностью, но в публичных копиях журнала можно маскировать середину. Ссылку на обозреватель лучше хранить отдельно от TxID, чтобы при смене сервиса сохранить сам идентификатор.

Справочник типов операций: не позволяйте свободному тексту разрушить учёт

Если в одной строке написано «перевод», в другой «вывод», а в третьей «отправка на биржу», автоматическая сверка становится ненадёжной. Создайте закрытый справочник типов и выбирайте значение из списка. Свободное описание оставьте в отдельном поле. Минимальный справочник обычно включает покупку, продажу, собственный перевод, внешний перевод, получение, swap, депозит, вывод, комиссию, вознаграждение, возврат, staking, bridge и корректировку.

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

Для сложных событий полезно иметь два поля: технический тип и экономический тип. Например, технически это `withdrawal`, экономически — `own transfer`. Технически — `token transfer`, экономически — `payment received`. Такой двойной классификатор особенно полезен при импорте из разных источников: исходное значение сохраняется, а нормализованное позволяет строить отчёты.

Как отражать покупку криптовалюты

Покупка создаёт основу будущей себестоимости, поэтому её документируют особенно подробно. Запишите количество актива, цену, общую сумму оплаты, комиссию площадки, банковскую комиссию и способ расчёта. Если USDT куплены через P2P, свяжите ордер с банковским переводом. Если через обменник — сохраните заявку, адрес приёма, TxID поступления и чек. Если карта списала сумму в иностранной валюте, храните исходную валюту, курс конвертации банка и рублёвый эквивалент.

Не объединяйте несколько покупок по средней цене сразу. Каждая операция остаётся отдельной партией. Средняя цена может рассчитываться в отчёте, но первичная детализация нужна для проверки. Если в один день куплено 500 USDT на бирже и 700 USDT через обменник, различаются контрагенты, комиссии и доказательства. Объединённая строка скрывает эти различия.

Если актив поступил не прямо на кошелёк, а сначала на внутренний баланс площадки, покупка завершается по правилам сервиса в момент исполнения ордера. Последующий вывод на свой адрес — отдельная операция. Это позволяет не включать withdrawal fee в цену покупки автоматически дважды. В журнале можно связать комиссию вывода с партией или маршрутом, но методика должна быть последовательной.

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

Как отражать продажу и рублёвое поступление

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

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

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

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

Переводы между своими кошельками: как не превратить перемещение в ложную продажу

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

В строке собственного перевода указывают адрес отправителя, адрес получателя, TxID, сумму до комиссии и фактически полученный объём. Комиссия является отдельным расходом актива или нативной монеты. Если отправлено 1 BTC и получено 0,9998 BTC, нельзя считать, что 0,0002 BTC продано неизвестному лицу. Это fee, который должен быть классифицирован как комиссия.

Перемещение с биржи на личный кошелёк включает внутренний источник: withdrawal ID, адрес вывода и сетевой TxID. Обратный депозит включает TxID и Deposit ID. Эти две записи связывают биржевую историю с блокчейном. Если площадка использует omnibus-кошелёк, адрес отправителя может не совпадать с вашим депозитным адресом; это нормальная особенность кастодиальной инфраструктуры, которую фиксируют в примечании.

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

Обмен криптовалюты на криптовалюту и DeFi-swap

Swap меняет состав портфеля, поэтому журнал должен сохранить обе стороны: сколько исходного актива списано и сколько нового получено. На бирже данные берут из trade history. В DeFi одна транзакция может содержать approve, обмен через несколько пулов, возврат остатка и комиссию. Записывать только итоговый токен недостаточно: без исходного объёма невозможно восстановить экономику операции.

В EVM-сетях TxID относится к транзакции, но внутри неё происходят события контрактов. Для журнала полезно сохранить receipt или ссылку на обозреватель, где видны token transfers и swap events. Если интерфейс показал 1 ETH → 3 120 USDT, а фактически получено 3 108 USDT из-за price impact и fee, в регистр попадает фактический результат. Котировка до подписи хранится как дополнительный документ, а не как окончательная цифра.

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

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

P2P-сделки: журнал должен соединить escrow и банк

P2P является одним из самых сложных источников данных, потому что криптовалютная и банковская части находятся в разных системах. Площадка показывает ордер, объём и контрагента. Банк показывает рублёвый перевод. Запись должна соединить эти данные по сумме, времени и назначению. Если продано 1 000 USDT, а деньги пришли двумя платежами, оба банковских ID привязываются к одному P2P Order ID.

Для покупки фиксируют рублёвый расход и поступление токенов на Funding Account. Для продажи — списание USDT из escrow и фактическое банковское поступление. Отметка «оплачено» не является доказательством денег; в журнал вносится банковская операция после проверки. Если открыт спор, статус сделки меняют на `disputed`, а окончательное решение добавляют отдельной датой.

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

Налоговую логику P2P и подготовку 3-НДФЛ лучше сверять с отдельным руководством о налогах с P2P. Журнал даёт исходные данные, но не определяет автоматически правовую квалификацию каждой операции.

Биржи и кастодиальные сервисы: не ограничивайтесь общей выгрузкой

Централизованная площадка обычно хранит несколько историй: deposits, withdrawals, trades, convert, internal transfers, P2P, earn и fees. Одна общая CSV-выгрузка может не включать все разделы. Перед сверкой составьте карту доступных отчётов и выгружайте каждый отдельно. Проверьте период, часовой пояс, статус операций и формат чисел. Запятая и точка в десятичной части могут превратить 0,15 BTC в ошибочное значение при импорте.

Внутренний перевод между Spot и Funding не имеет сетевого TxID, но нужен для объяснения, почему токены стали доступны P2P. Deposit ID и Withdrawal ID не заменяют TxID, когда операция вышла в блокчейн. Храните оба. Если биржа выполнила пакетный вывод, один TxID может включать несколько получателей; ваша запись связывается с конкретным output или token transfer.

Earn, staking и rewards требуют отдельной классификации. Перевод в Earn может быть внутренним перемещением, а начисленная награда — новым поступлением. Не записывайте всю сумму возврата из продукта как новый доход: часть является возвратом собственного principal. Площадка может дать отдельный rewards report — сохраните его.

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

Self-custody: адрес не равен человеку

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

Не полагайтесь на подпись контакта в приложении как на единственный источник. Кошелёк можно переустановить, а адресная книга — потеряться. Храните назначение адреса в регистре и периодически подтверждайте его. Для биржевого депозитного адреса указывайте площадку и дату, потому что сервис может менять реквизиты.

Мультиаккаунтные кошельки могут производить разные адреса из одной seed-фразы. Это не значит, что все адреса автоматически обнаружатся в любой программе: derivation path и поддерживаемые сети различаются. В журнале фиксируют не секрет, а публичные адреса и приложение, через которое они использовались.

Если на адрес пришёл неизвестный токен или dust, не создавайте доходную запись без анализа. Это может быть spam token или address poisoning. Отметьте техническое поступление как `unclassified/spam`, сохраните контракт и не взаимодействуйте с подозрительным активом.

TXID, хэш, подпись и внутренний ID: какие идентификаторы не взаимозаменяемы

TXID или transaction hash позволяет найти операцию в конкретной сети. Для Bitcoin TXID идентифицирует транзакцию и связывает входы с предыдущими выходами. В Ethereum транзакция получает hash, а receipt показывает результат выполнения и события. В TRON используется txID. В Solana интерфейсы часто используют подпись транзакции как идентификатор. Эти значения относятся к разным сетям и не должны храниться без поля network.

Внутренний Order ID биржи не является TXID. Если куплены USDT внутри площадки, блокчейн-транзакции может не быть. Trade ID относится к торговой сделке. Deposit ID связывает сетевой перевод с зачислением. Bank transaction ID относится к фиатному платежу. Журнал должен хранить каждый идентификатор в своей колонке, а не складывать их в поле «номер операции».

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

Bitcoin: UTXO требует учёта входов, выходов и сдачи

Bitcoin-транзакция может расходовать несколько предыдущих UTXO и создавать несколько новых выходов. Если пользователь отправляет 0,1 BTC, кошелёк может использовать вход 0,15 BTC, направить 0,1 BTC получателю, 0,0498 BTC — на адрес сдачи владельца, а 0,0002 BTC — комиссии. Наивный импорт способен принять весь вход за расход или считать сдачу новым поступлением.

В журнале экономическое событие отражает 0,1 BTC внешнего перевода и 0,0002 BTC комиссии. Сдача является продолжением собственного владения. Для точной сверки храните TxID, номера выходов `vout`, адреса сдачи и связь с собственным кошельком. Если используется CoinJoin или сложная схема объединения UTXO, автоматическая классификация требует дополнительной проверки.

При покупке BTC на бирже и выводе на свой кошелёк себестоимость создаётся торговой сделкой, а не сетевым переводом. Withdrawal fee площадки фиксируется отдельно. При последующем депозите на другую биржу журнал связывает UTXO-историю с Deposit ID. Это помогает доказать, что монеты не получены от неизвестного третьего лица.

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

Ethereum и EVM-сети: receipt важнее красивого названия операции

Транзакция Ethereum содержит отправителя, получателя, nonce, value, параметры gas, data и подпись. Для простого перевода ETH поле value показывает сумму. Для ERC-20-перевода value может быть нулевым, а фактическое движение токена происходит через вызов контракта и событие Transfer. Поэтому журнал, построенный только на основном value, пропустит USDT, USDC и другие токены.

Сохраняйте contract address и decimals. Поддельный токен может иметь тот же символ и название. Обозреватель отображает результат транзакции и token transfers, но интерфейс иногда агрегирует несколько событий. При swap полезно хранить transaction receipt или экспорт из протокола, чтобы видеть входы, выходы и fee.

Nonce помогает понять последовательность операций одного адреса и случаи замены транзакции. Если pending-транзакция была speed up или cancel, старый hash может остаться в журнале со статусом replaced. Окончательной записью становится исполненная транзакция, а не первоначальная попытка. Не удаляйте попытку полностью: она объясняет историю и отсутствие движения по старому хэшу.

Layer 2 и другие EVM-сети используют похожий формат адреса `0x`, но это разные сети. Поле network обязательно. Совпадение адреса не означает, что актив находится в Ethereum mainnet. При bridge храните hashes обеих сторон и контракт моста.

TRON, TON и Solana: особенности, которые нужно вынести в отдельные поля

В TRON txID является хэшем транзакции, но перевод TRC-20 выполняется вызовом контракта. Для журнала фиксируют адреса, контракт токена, сумму и результат исполнения. Комиссия может выражаться в сожжённом TRX или использовании Energy и Bandwidth. Если приложение показывает «нулевую комиссию» благодаря ресурсам, это не означает отсутствие экономических затрат в маршруте — ресурсы могли быть арендованы или делегированы.

В TON переводы jetton могут включать комментарий, payload и несколько сообщений. Биржа может требовать memo/comment для привязки депозита. Журнал должен хранить не только hash, но и комментарий, если он использовался. Отсутствие комментария не всегда уничтожает актив, но может потребовать ручного восстановления и отдельного Deposit ID.

В Solana идентификатором часто служит signature. Одна транзакция может содержать несколько инструкций и работать с token accounts. Получатель токена может быть associated token account, а не основной wallet address в привычном смысле. Для сверки сохраняйте mint токена, владельца token account и фактические изменения балансов.

Не пытайтесь привести все сети к одному набору технических полей ценой потери данных. Базовый журнал хранит общие атрибуты, а отдельный лист `Network Details` — специфические: vout для Bitcoin, nonce и receipt для EVM, Energy для TRON, comment для TON, signature и token account для Solana.

Комиссии: отдельное событие, часть стоимости или и то и другое

Комиссии встречаются на разных уровнях: банковская, торговая, сервисная, withdrawal fee, network fee, gas, bridge fee и spread. Их нельзя складывать без классификации. Торговая комиссия может удерживаться в купленном активе, котируемой валюте или токене площадки. Сетевая комиссия оплачивается нативной монетой. Спред не всегда отображается отдельной строкой, но влияет на эффективный курс.

В журнале храните исходный fee asset и количество. Рублёвую оценку рассчитывайте по выбранной методике. Если биржа удержала 1 USDT из покупки, поле gross показывает 1 000 USDT, fee — 1 USDT, net — 999 USDT. Если комиссия оплачена BNB, нельзя механически уменьшить количество USDT; это отдельное выбытие BNB.

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

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

Себестоимость: журнал хранит факты, а метод распределения выбирается отдельно

Журнал должен сохранить каждую партию приобретения в исходном виде: дату, количество, полную цену и подтверждения. Затем отдельный расчёт распределяет себестоимость на проданный объём. Не уничтожайте партии после применения FIFO, средней цены или иной методики. Налоговые правила и практика могут требовать конкретного подхода или пояснения; исходная детализация позволяет пересчитать результат.

Например, приобретено 500 USDT по 90 ₽ и 700 USDT по 96 ₽, затем продано 600 USDT. При FIFO продажа затрагивает первую партию полностью и 100 USDT второй. При средней стоимости результат будет другим. Журнал не должен скрывать этот выбор. Поле `Cost Basis Method` и версия расчёта помогают понять, почему получена конкретная база.

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

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

Рублёвая оценка: фиксируйте источник курса и не путайте USDT с долларом

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

Записывайте валюту исходной операции. Если биржа показывает цену в USDT, а банковская карта списывает евро, не перескакивайте сразу к рублям без сохранения промежуточных данных. Поля могут включать native amount, native currency, exchange rate to RUB, source and timestamp. Это позволяет повторить расчёт и объяснить расхождение.

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

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

Сверка остатков: формула, которая обнаруживает большинство ошибок

Для каждого актива и места хранения используйте простую сверку: начальный остаток + все входы − все выходы − комиссии = конечный остаток. Если результат не совпадает с фактическим балансом, журнал неполон или операция классифицирована неверно. Сверку делают по каждому адресу и аккаунту, затем по портфелю в целом.

Разница часто возникает из-за пропущенной комиссии, перевода между внутренними счетами, staking reward, dust, округления или дублированного импорта. В Bitcoin причиной может быть сдача. В EVM — token transfer внутри contract call. На бирже — актив в Earn или открытом ордере. Не исправляйте разницу строкой `прочее`, пока не исследовали источник.

Полезно иметь статус сверки: `matched`, `temporary difference`, `unexplained`. Временная разница допустима для pending withdrawal или депозита, который ещё не зачислен. После завершения маршрута статус должен быть закрыт. Неразъяснённые расхождения выносят в отдельный список и не скрывают.

Ежемесячная сверка лучше годового восстановления

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

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

Для активного пользователя полезно установить контрольные показатели: число необъяснённых операций, доля записей без документов, несверенные остатки и крупные операции без Source of Funds. Такой dashboard не заменяет анализ, но показывает, где риск растёт.

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

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

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

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

Не редактируйте оригиналы. Для передачи создавайте копии с маскированием лишних данных. Хэш файла, дата получения и название источника помогают доказать неизменность внутреннего архива, хотя сами по себе не создают юридической силы. Не храните seed-фразы, приватные ключи, коды 2FA и API-secret рядом с документами.

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

Структура папок и имена файлов

Архив лучше строить по году и внутреннему ID, а не по названию биржи. Тогда одна операция, затронувшая банк, биржу и блокчейн, хранится вместе. Пример: `/CryptoLog/2026/2026-00417/`. Внутри: `01_order.pdf`, `02_bank_statement.pdf`, `03_txid.txt`, `04_explorer.pdf`, `05_notes.md`. Исходные массовые выгрузки хранятся отдельно в `/Sources/Exchange/2026-07/`.

Не используйте в имени файла только `screenshot_1234.png`. Через год такой файл невозможно найти. Добавляйте дату, ID, источник и вид документа. Для автоматизации избегайте запрещённых символов и слишком длинных имён. Отдельный manifest может перечислять файлы, размер и контрольную сумму.

Версии журнала именуйте датой закрытия, например `crypto_journal_2026-07_closed.xlsx`. Рабочая версия может меняться, закрытая — только дополняться корректировками. Храните резервную копию минимум в двух независимых местах, одно из которых офлайн или защищено от синхронного удаления.

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

Налоговый контур: какие поля особенно важны

ФНС в разъяснении 2026 года указывает, что при продаже криптовалюты налоговая база рассчитывается как положительная разница между доходом от реализации и документально подтверждёнными расходами, связанными с приобретением и реализацией. Поэтому журнал должен сохранять количество, стоимость покупки, стоимость продажи и комиссии вместе с документами. Итоговая таблица без первичных подтверждений слаба.

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

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

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

AML и комплаенс: журнал помогает объяснить маршрут, но не присваивает риск

Провайдеры виртуальных активов применяют customer due diligence, record keeping и мониторинг операций. Пользовательский журнал не заменяет их системы и не определяет официальный risk score. Его роль — быстро показать источник и маршрут актива. Если биржа видит депозит от адреса с высоким риском, владелец может представить историю приобретения, собственные перемещения и сделку, в результате которой актив получен.

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

В журнале отделяйте факт от оценки. Факт: адрес взаимодействовал с конкретным сервисом по данным отчёта. Оценка: операция требует review. Решение: принять, запросить документы или отказаться. Как интерпретировать exposure и risk score, описано в материале о том, как читать AML-отчёт. Для конкретного TxID используйте отдельную AML-проверку транзакции.

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

Source of Funds: как превратить тысячи строк в понятную хронологию

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

Хронология должна сходиться по количеству. Если куплено 2 BTC, затем 0,5 BTC продано и 1,2 BTC отправлено на биржу, нужно объяснить остаток и комиссии. Нельзя приложить покупку 2021 года на 1 BTC к депозиту 2026 года на 3 BTC без промежуточных источников. Журнал выявляет такой разрыв до отправки документов.

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

Если часть истории недоступна из-за закрытия биржи, честно укажите пробел и приложите косвенные доказательства: выписку, email, blockchain data. Не создавайте поддельный отчёт. Крупный или спорный кейс лучше согласовать с профильным специалистом.

Банк и 115-ФЗ: зачем связывать рубли с криптовалютной операцией

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

Поле `Bank Sender/Recipient` помогает обнаружить платежи от третьих лиц. Поле `Economic Purpose` объясняет, является ли поступление продажей собственной криптовалюты, возвратом или личным переводом. Не используйте вымышленное назначение. Несоответствие между ответом банку, P2P-ордером и налоговой таблицей повышает риск дополнительных вопросов.

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

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

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

Не заменяйте исходную запись итоговым статусом. Если P2P-ордер сначала был спорным, затем решён в пользу продавца, сохраните обе даты и документы. Если обменник вернул криптовалюту, первая отправка и возврат остаются отдельными сетевыми событиями, связанными одним case ID. Это позволяет понять комиссии и временный разрыв.

Ошибочный перевод в другой сети или без memo отражают как фактическую транзакцию со статусом `recovery pending`. Если площадка восстановила депозит за комиссию, добавляют recovery event и fee. Если актив утрачен, запись закрывают только после подтверждения невозможности восстановления или решения владельца, не удаляя исходный TxID.

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

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

Автоматизация: что можно импортировать, а что нужно проверять вручную

API и CSV хорошо собирают дату, актив, количество, fee, hash и status. Они хуже определяют владельца адреса, экономический смысл, связь с банковским платёжом и документы. Поэтому полностью автоматический журнал без review обычно содержит ложные продажи, дубли и нераспознанные собственные переводы.

Автоматизацию начинайте с нормализации. Сохраните raw source, затем преобразуйте названия колонок, часовые пояса и числа. Создайте ключ дедупликации: network + txid + event index для блокчейна, platform + order ID для биржи, bank + transaction ID для фиата. Не используйте только дату и сумму: одинаковые операции возможны.

Правила можно применять к известным адресам и типам. Например, перевод между двумя собственными адресами классифицируется как own transfer. Но новые адреса, contract interactions, bridge и неизвестные поступления отправляются в очередь review. Каждое автоматическое правило должно иметь версию и журнал изменений.

Если используется сторонний portfolio tracker, не передавайте API-ключ с правом торговли или вывода. Для импорта достаточно read-only, а seed-фраза не нужна никогда. Экспортируйте локальную копию: сервис может изменить доступ или модель расчёта.

Таблица, база данных или специализированный сервис: как выбрать инструмент

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

База данных полезна при большом объёме и множестве источников. Она разделяет транзакции, адреса, документы и курсы, поддерживает связи many-to-many. Но без удобного интерфейса пользователь может потерять контроль над смыслом данных. Специализированный tax tracker ускоряет импорт, однако его классификацию нужно проверять и сохранять исходные отчёты.

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

Безопасность журнала: финансовая прозрачность без раскрытия ключей

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

Seed-фразы, private keys, backup codes и API secrets не записывают в журнал и не прикладывают к документам. Для доказательства владения адресом существуют безопасные методы, но они не требуют передачи секрета. Если специалист просит seed-фразу для «проверки учёта», это мошеннический запрос.

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

Резервные копии должны защищать от ransomware и случайного удаления. Синхронизация в одном облаке не является полноценным backup: удаление или шифрование может распространиться на все устройства. Храните отдельную офлайн-копию закрытых периодов.

Семейный, наследственный и командный доступ

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

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

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

Как перенести старую историю в новый журнал

Не начинайте с ручного ввода всех строк по памяти. Составьте карту источников: биржи, кошельки, банки, обменники, email и договоры. Выгрузите максимальные периоды и сохраните raw files. Затем определите начальные остатки на дату миграции. Если история до этой даты неполна, пометьте opening balance и источник оценки.

Импортируйте данные по одному источнику и сразу дедуплицируйте. Начните с биржевых trades и deposits, затем добавьте блокчейн, после — банковские операции. Сопоставляйте маршруты по ID, времени и сумме. Не объединяйте источники до сохранения оригинальных колонок.

Старые пробелы классифицируйте по уровню уверенности: confirmed, probable, unknown. Например, адрес, который многократно использовался как собственный и подтверждён withdrawal history, можно считать confirmed. Неизвестный перевод без документов остаётся unknown; не придумывайте контрагента.

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

Практический пример: покупка USDT, вывод и продажа через P2P

Пользователь 10 января купил 1 000 USDT на бирже за 93 000 ₽, комиссия составила 1 USDT. На баланс поступило 999 USDT. Затем он вывел 900 USDT в сети TRON; биржа удержала 1 USDT, на кошелёк поступило 899 USDT. Через три месяца он вернул 500 USDT на другую биржу, заплатив сетевую комиссию в TRX, и продал 500 USDT через P2P за 49 500 ₽.

Журнал содержит не одну строку «купил 1 000 — продал 500», а цепочку. Первая запись — покупка gross 1 000, fee 1, net 999. Вторая — собственный вывод 900, fee 1 USDT, received 899. Третья — собственный депозит 500 и отдельная комиссия TRX. Четвёртая — P2P-продажа 500 USDT и банковское поступление 49 500 ₽. Все записи связаны route ID.

Такой регистр показывает, что депозит не является новым доходом, а проданный актив происходит из январской покупки. Остаток можно сверить: на исходной бирже осталось 99 USDT, на кошельке после отправки 500 — 399 USDT за вычетом только TRX-комиссии, а 500 USDT продано. Если цифры не сходятся, ищут пропущенную операцию.

Практический пример: обмен ETH на USDT через DEX

Пользователь обменял 1 ETH на USDT через DEX. Котировка обещала 3 200 USDT, но после price impact получено 3 176 USDT. Gas составил 0,004 ETH. Транзакция также включала approve в предыдущем хэше. Если журнал записывает только «получено 3 200 USDT», остаток и экономический результат будут ошибочными.

Правильная запись сохраняет фактический расход 1 ETH, фактическое получение 3 176 USDT и gas 0,004 ETH. Approve классифицируется как contract permission и имеет собственный gas, но не является обменом. Contract addresses токенов и DEX сохраняются. Рублёвая оценка определяется по выбранной методике на время операции.

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

Практический пример: оплата в USDT за работу

Фрилансер выставил счёт на 2 000 USDT за проект. Заказчик отправил 2 000 USDT TRC20. Фрилансер заплатил TRX за дальнейший перевод, внёс токены на биржу и продал 1 000 USDT через P2P. В журнале первое событие классифицируется не как покупка, а как получение оплаты с основанием: договор, инвойс и акт, если применимо.

В строке получения сохраняют TxID, адрес заказчика, свой адрес, сумму, сеть, дату и рублёвую оценку по выбранной методике. Дальнейший депозит на биржу является собственным переводом. Продажа 1 000 USDT — отдельное событие с банковской выплатой. Оставшиеся 1 000 USDT продолжают числиться в портфеле с источником `service income`, а не с покупной себестоимостью.

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

Ошибки, которые делают журнал бесполезным

1. Записывать только итоговый баланс без операций.
2. Считать все входящие переводы доходом, а все исходящие расходом.
3. Не хранить сеть и contract address токена.
4. Использовать один столбец для TXID, Order ID и банковского номера.
5. Удалять отменённые, заменённые и спорные операции.
6. Объединять несколько покупок в одну строку без первичных партий.
7. Не фиксировать комиссии в исходном активе.
8. Считать собственный перевод продажей.
9. Хранить только скриншоты без отчётов и выписок.
10. Записывать seed-фразу или приватный ключ рядом с журналом.
11. Приписывать неизвестной операции удобное назначение без доказательств.
12. Не сверять остатки и закрывать год с необъяснённой разницей.

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

Готовый порядок внедрения журнала за один цикл

1. Соберите список бирж, кошельков, банков и сервисов.
2. Создайте справочник собственных адресов и аккаунтов без секретов.
3. Определите типы операций и обязательные поля.
4. Выгрузите raw data и сохраните оригиналы.
5. Импортируйте операции по одному источнику.
6. Нормализуйте время, активы, сети и числа.
7. Удалите дубли по устойчивым идентификаторам.
8. Классифицируйте покупки, продажи, swaps и own transfers.
9. Свяжите blockchain, platform и bank IDs.
10. Добавьте пути к документам.
11. Сверьте остатки по каждому активу и месту хранения.
12. Закройте необъяснённые расхождения или вынесите их в review.
13. Создайте ежемесячный архив и резервную копию.

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

Каким должен быть журнал, который можно использовать на практике

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

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

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

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

FAQ: вопросы о журнале криптотранзакций

Существует ли официальная форма журнала криптотранзакций?

В использованных разъяснениях ФНС нет единой обязательной формы с таким названием для обычного физического лица. Журнал является практическим регистром. Однако сведения в нём должны подтверждаться реальными отчётами, выписками, договорами и данными блокчейна.

Можно ли вести журнал только в Excel?

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

Нужно ли записывать переводы между своими кошельками?

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

Нужно ли хранить seed-фразу в журнале?

Нет. Seed-фраза, приватный ключ, backup codes и API-secret не относятся к учётным данным и не должны храниться рядом с финансовым архивом.

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

Запишите отдельное списание той монеты, которой оплачена комиссия. Например, перевод USDT ERC20 расходует ETH; нельзя уменьшать количество USDT, если токены фактически не удерживались.

Что делать, если в отчёте биржи нет TxID?

Внутренняя сделка или transfer может не иметь TxID. Сохраните Trade ID, Order ID или внутренний transfer ID. Для внешнего вывода дополнительно ищите сетевой hash в withdrawal history.

Можно ли считать все поступления на кошелёк доходом?

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

Как учитывать Bitcoin-сдачу?

Сдача на собственный адрес не является новым доходом. Разделите внешний выход, change output и network fee, используя данные транзакции и справочник своих адресов.

Как записать swap одного токена на другой?

Сохраните фактически списанный актив, фактически полученный актив, обе рублёвые оценки, комиссии, TxID и контракт протокола. Котировка до сделки не заменяет receipt.

Нужно ли сохранять скриншоты, если есть CSV?

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

Как часто закрывать журнал?

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

Что делать, если остатки не сходятся?

Не добавляйте строку «прочее» без анализа. Проверьте комиссии, дубли, внутренние счета, staking, Bitcoin change, decimals токена и pending операции. Расхождение оставьте в review до объяснения.

Можно ли удалить ошибочную запись?

Лучше создать корректировку или reversal, сохранив первоначальную строку и причину изменения. Это поддерживает audit trail и объясняет различия между версиями отчёта.

Как учитывать P2P-платёж двумя частями?

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

Нужно ли вести рублёвую оценку USDT по курсу доллара ЦБ?

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

Что хранить для Source of Funds?

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

Нужно ли записывать неуспешные транзакции?

Да, если они повлекли комиссию, заменили другую транзакцию или важны для спора. Укажите статус failed/replaced и свяжите с окончательной операцией.

Как учитывать токены, присланные неизвестным адресом?

Не признавайте их доходом автоматически. Проверьте контракт и отметьте как unclassified или spam. Не взаимодействуйте с подозрительным токеном.

Можно ли передать полный журнал банку?

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

Сколько лет хранить архив?

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