Інтеграція TokenTax: податкова звітність для DeFi та NFT

Інтеграція TokenTax: де рветься звітність за DeFi та NFT

Податкова звітність DeFi ламається не на етапі розрахунку, а на вході — у момент збору подій. Один обмін на агрегаторі розгортається в кілька переказів токенів у межах однієї транзакції, а крос-чейн міст переносить актив між мережами двома записами, не пов'язаними між собою. Без наскрізної зв'язки ці події потрапляють у звіт як незалежні операції.

Зведення угод за мережами — перший розрив. Списання в одній мережі та зарахування в іншій не мають спільного ідентифікатора, крім адреси та часу, а внутрішні перекази контрактів часто взагалі не віддають подію про переказ. У результаті актив вибув, але не надійшов, і сальдо за портфелем розходиться з реальністю.

Облік операцій з NFT додає другий розрив: база вартості мінту, роялті, передача обгорнутого або дробового токена не відновлюються з одного запису. Потрібен весь шлях активу — від мінту до поточного власника, інакше прибуток рахується від нуля.

Третій розрив — пропущені перекази та дублі угод. Разові ручні вивантаження збираються щоразу зі своїм зрізом: частина періодів випадає, а повторний імпорт тієї ж адреси дає задвоєння.

Ключа зіставлення між мережами в таких вивантаженнях немає, тому розходження накопичується і не перевіряється.

Закривається це не форматом файлу, а способом збору: дані тягнуться неперервно по всіх мережах і зв'язуються в один ланцюжок до розрахунку. Розбираємо, як TokenTax вбудовується в цей контур і що саме доводиться зшивати на вході.

Що змінюється в звітному контурі після впровадження

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

На потоці в кілька тисяч операцій за квартал таке розмічування розтягувалося на тижні, а один неправильно зрозумілий рядок тягнув за собою перерахунок усієї бази витрат.

TokenTax закриває категоризацію правилами: модуль імпорту зіставляє контрагента, тип події контракту та пару активів, після чого позначає операцію як обмін, дохід, переказ між своїми гаманцями або реалізацію.

На типовому потоці 9 із 10 рядків проходять без правки руками, а на розбір залишаються спірні випадки — розрахунок частки при виході з пулу, нагороди в нестандартних токенах, перекази між мережами. Їхній список короткий і з зазначенням джерела даних, а не «перевірити все».

Звірка балансів іде від факту: система бере залишки на початок і кінець періоду за кожною адресою та рахунком на біржі, показує розходження і трасує його до конкретної транзакції. Це знімає класичну проблему звіту, коли цифри не сходяться і незрозуміло, де загубилася сума.

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

Кожен рядок зберігає посилання на джерело, тому перевіряючий бачить не підсумок, а ланцюжок «транзакція → категорія → проводка». Зміна методики обліку фіксується окремою версією, і попередній розрахунок залишається відтворюваним.

Варіанти інтеграції TokenTax: порівняння підходів

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

Нижче — порівняння за інженерними критеріями: хто відповідає за зіставлення транзакцій, що відбувається при збої і як рішення поводиться при зростанні обсягів.

Окрема складність — розходження між джерелами: та сама операція приходить з мережі, біржі та гаманця в різному вигляді.

TokenTax закриває розрахунок податкової бази, але зіставлення та дедуплікацію записів усе одно потрібно проєктувати — інакше підсумок не зійдеться з фактичним рухом коштів.

Етапи вбудовування податкового контуру в продукт

Податковий контур не підключається одним модулем: спочатку потрібно зрозуміти, звідки в продукт приходять операції і в якому вигляді вони зберігаються.

Нижче — послідовність, за якою ми ведемо вбудовування TokenTax, щоб звітність збігалася з реальними даними користувача, а не з тим, що вдалося зібрати на око.

1. Аудит джерел даних. Проходимо по всіх точках, де виникають операції: біржові акаунти, підключені гаманці, мости, стейкінг, торгові майданчики. Фіксуємо формати вивантажень, глибину історії, дублі та розриви — саме ці прогалини визначають, що взагалі піддається розрахунку.

2. Схема зіставлення. Вводимо єдиний ідентифікатор операції та правила зведення переказів між власними адресами. Без цього переказ собі ж перетворюється на дохід і подвоює податкову базу.

3. Правила категоризації. Описуємо, що відносимо до доходу, що до реалізації, як трактуємо комісії, нагороди, випуск і спалювання токенів. Правила тримаємо в конфігурації, а не в коді — їх правлять без релізу.

4. Перевірка на історії. Проганяємо зібраний контур на минулих періодах і звіряємо підсумки з тим, що користувач заявляв раніше. Розходження розбираємо до передачі, а не після звернень до підтримки.

5. Передача контуру. Віддаємо схему даних, довідники категорій, регламент оновлення та інструкції для підтримки, проводимо навчання команди і супроводжуємо перші звітні цикли.

Що залишається в команди після здачі контуру

Контур податкової звітності живе довше, ніж впровадження: додаються мережі, з'являються нові протоколи, в операцій виникають нестандартні типи.

Тому в передачу входить не лише працюючий обмін даними з TokenTax, а й комплект документів, за яким ваша команда зможе розібрати спірну угоду та оновити правила без нашої участі.

• Схема потоків даних — шлях операції від гаманця та біржового вивантаження до категорії і підсумкового звіту, з зазначеними точками, де підключається ручна перевірка.
• Правила категоризації — за якими ознаками угода належить до обміну, дохідності, випуску активу або продажу NFT, і в якому порядку застосовуються винятки.
• Регламент звірки — порядок зіставлення вивантаження з даними контуру, допустимі розходження та дії, якщо розходження вийшло за поріг.
• Інструкція для підтримки — розбір типових звернень: угода не розпізнана, сума розійшлася, з'явився новий протокол; що перевіряється самостійно і коли підключається друга лінія.
• Журнал винятків — операції, не покриті автоматичними правилами, з причиною, прийнятим рішенням і датою перегляду.
• Документація контуру — склад сервісів, зовнішні точки обміну, схема зберігання проміжних даних і порядок їх очищення.
• Порядок оновлення правил — як додати мережу або тип активу і які перевірки прогнати перед введенням змін у роботу.

Такий комплект знімає залежність від підрядника: правки в правилах обліку вносяться за інструкцією, а не через листування, а кожна нестандартна операція залишає слід, за яким видно, чому вона віднесена до тієї чи іншої категорії.

Кейс: DeFi-гаманець закрив звітність без ручних вивантажень

Гаманець із кількома тисячами активних адрес тримав портфель у пулах ліквідності, стейкінгу та NFT і закривав звітність вручну: аналітик вивантажував операції з оглядачів мереж, зводив їх у таблиці та розмічав категорії.

Квартальне закриття займало 3-4 робочі дні, а крос-чейн перекази давали розриви — вартість входу та виходу не сходилася.

До: ручне складання та розходження в даних

Близько 70% рядків розмічалося руками, включно з доходом від стейкінгу та нагородами. Кожен десятий-дванадцятий рядок розходився з фактичним рухом коштів: перекази між своїми гаманцями потрапляли у витрати, а курс брався на дату вивантаження, а не на момент операції. На розбір розходжень ішло більше часу, ніж на саме складання.

Після: інтеграція в обліковий контур

Інтеграція TokenTax дала автоматичний імпорт: перекази між своїми адресами згортаються в один потік, дохід від стейкінгу та нагород розмічається окремими категоріями, вартість береться на момент операції. Історію за минулі періоди прогнали повторно — слід операцій відновлено без прогалин.

Підготовка квартального звіту займає 3-4 години замість 3-4 днів, частка ручних операцій упала до 8%, розходження тримаються нижче 1% і розбираються точково. Розборів вручну стало приблизно в п'ятнадцять разів менше, а в бухгалтерії з'явився відтворюваний набір вивантажень.

Що робити, якщо облік уже ведеться в іншому сервісі?

Перенесення починається з вивантаження накопиченої історії з поточного сервісу: таблиця операцій з ідентифікаторами транзакцій, адресами гаманців, датами та сумами.

Її зіставляють з даними мережі та з тим, що вже рознесено за категоріями — стейкінг, свопи, додавання та виведення ліквідності, продажі NFT.

Категорії у двох сервісів майже не збігаються один в один, тому на кожен старий тип операції пишеться правило відповідності: як він тепер називається і як обліковується.

Імпорт у TokenTax налаштовується так, щоб пов'язані операції не згорталися в один рядок: переказ на біржу, своп і подальший продаж мають залишитися одним ланцюжком з коректною вартістю придбання. Інакше історія формально завантажилася, а розрахунок бази на ній уже невірний.

Далі — звірка розходжень. Звіряємо три джерела: вивантаження з колишнього сервісу, дані мережі та підсумкові звіти. Розходження зазвичай сидять у трьох місцях: невраховані комісії, дублі при переказах між своїми гаманцями, різна ціна активу на момент операції. Кожне розходження розбирається до конкретного рядка, а не «приблизно сходиться».

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

Зміна сервісу обліку — це перенесення правил, а не перемикання галочки. Вивантаження зі старого сервісу зберігається як еталон, і до неї можна повернутися на будь-якому кроці, поки нові звіти не зійдуться зі старими.

Повторні угоди, перекази між гаманцями та пропуски

Спірні місця спливають не на імпорті, а на звірці. Повторні операції з'являються, коли історію підтягнули двома шляхами — за адресою та вивантаженням з біржі: та сама угода стає в розрахунок двічі і роздуває підсумок.

Усередині однієї транзакції часто лежать обмін, комісія та часткове повернення — без розмітки вони йдуть у звіт як окремі події.

Переказ між своїми гаманцями — не продаж і не дохід, але автоматика бачить два рухи: списання з однієї адреси та зарахування на іншу. Якщо не зв'язати їх у пару, розрахунок покаже реалізацію там, де актив просто переїхав, а собівартість позиції обнулиться.

Як обліковувати операції з NFT: мінт, роялті, перепродаж?

Мінт фіксує вартість отримання активу, роялті — окрема витрата при кожному перепродажі, продаж закриває позицію цілком. Облік ведемо за кожним токеном окремо: у загальному потоці роялті зливаються з комісіями та завищують результат.

Що робити, якщо мережа віддає неповну історію?

У частини мереж і в старих адрес вузли повертають обрізаний список операцій — пропуски дають занижений підсумок, який спливає вже у звіті. Ми звіряємо вивантаження з незалежним джерелом і добираємо відсутні операції, щоб розрахунок не спирався на дірявий набір даних.

Обговоримо ваше завдання: що потрібно для оцінки

Щоб повернутися з оцінкою, а не з уточнювальними запитаннями, нам достатньо набору вхідних.

Обсяг робіт визначається числом мереж і різноманіттям типів операцій, а не кількістю транзакцій: десять тисяч однотипних свапів в одній мережі розбираються швидше, ніж триста операцій у п'яти протоколах із ліквідністю та NFT.

• Перелік мереж: EVM-сумісні, рішення другого рівня, non-EVM — під кожну потрібна своя логіка розбору та зіставлення адрес.
• Типи операцій: свапи, додавання та виведення ліквідності, стейкінг, мінт і продаж NFT, мости, ейрдропи — від них залежить, які події розгортаємо в податкові рядки.
• Приклади вивантажень: одна-дві адреси гаманця або готові файли з біржі та гаманця за звітний період — за ними видно, як дані лягають у TokenTax.
• Поточний процес звірки: як ведете облік зараз — вручну, в таблицях, в обліковій системі; які розходження вже накопичилися і чим вони заважають.
• Цільовий результат: під яку юрисдикцію рахуємо, за які періоди, чи потрібні окремі зрізи за DeFi та NFT.
• Точки обміну даними: звідки забираємо дані і куди віддаємо підсумок — вивантаження, інтеграція з обліковою системою, ручне завантаження.

За цими вхідними ми збираємо оцінку обсягу робіт і план впровадження: етапи, що потрібно з вашого боку, де ризики щодо якості історичних даних. Опишіть завдання і надішліть вхідні — повернемося з оцінкою та планом.