Чому розрахунок податків ламається без інтеграції Koinly
Угоди на біржі видно в історії, але податковий звіт збирається вручну — і вже на другій сотні операцій він перестає збігатися з тим, що реально відбувалося на рахунку.
Вивантаження за період, зведення в таблицю, порядкове ручне звіряння операцій — і в якийсь момент з'являються розбіжності в податковій звітності, а де загубилася істина, незрозуміло: у біржових даних, у таблиці чи в правилах розрахунку.
Причина в тому, що облік угод на біржі — це не лише купівлі та продажі. Там перекази між власними гаманцями, обмін одного активу на інший, нарахування за зберігання, комісії мережі, дробові залишки. Кожна операція потребує свого трактування: щось є реалізацією, щось — ні.
Вручну правило застосовується по-різному від рядка до рядка, і помилки зіставлення транзакцій накопичуються до кінця періоду.
Найчастіша поломка — подвійний облік. Переказ з біржі на власний гаманець читається як продаж, зворотний переказ — як купівля, і у звіті виникає дохід, якого не було. Або дві частини однієї угоди потрапляють у різні рядки, і операція рахується двічі. Ручна звірка знаходить це вже після того, як цифри пішли у звітність.
Koinly закриває проблему на рівні джерела: операції підтягуються з біржі напряму, зіставляються за адресами та мітками часу, а спірні рядки позначаються для розбору людиною. Нижче — як влаштована така інтеграція і що залишається на боці бухгалтера або власника.
Вимірюваний ефект: швидкість звірки, точність, повнота обліку
Пряме вивантаження з біржі в Koinly замінює ручне перенесення виписок: угоди, нарахування за стейкінгом і перекази між власними рахунками потрапляють в облік у тому вигляді, у якому зафіксовані в журналах торгів.
Далі вмикається автоматична категоризація — правила розмічають типи операцій, а сумнівні позиції не розчиняються у звіті, а йдуть у чергу на розбір.
Заміри за одним і тим самим портфелем до та після інтеграції:
| Параметр | До | Після |
|---|---|---|
| Закриття звітного періоду | 2–3 тижні ручного розбору виписок | 2–3 дні разом із звіркою розбіжностей |
| Повнота обліку угод | частина переказів між власними рахунками губилася | кожна операція з журналів біржі доходить до обліку |
| Категоризація операцій | вручну, помилки на стейкінгу та внутрішніх переказах | за правилами, спірні позиції — в окрему чергу |
| Пошук розбіжностей | порядкове порівняння таблиць | список невідповідностей за рахунком і датою |
Швидкість закриття звітного періоду
Період закривається за готовністю даних, а не у міру ручної звірки: вивантаження йде за розкладом, розбіжності за переказами між рахунками підсвічуються одразу, а не спливають в останній день. Це прибирає штурмівщину в кінці кварталу і робить строк закриття передбачуваним.
Точність категоризації та повнота обліку
Правила розмітки описані явно та версіонуються — при зміні схеми видно, які операції перерозмітилися.
Спірні випадки не «підганяються» під підсумок: вони залишаються в черзі із зазначенням рахунку, дати й типу операції, тому повнота обліку перевіряється, а не декларується на словах.
Інтеграція Koinly: способи підключення та їх обмеження
Підключити біржовий акаунт до Koinly можна трьома способами: пряме підключення до біржі за ключем, імпорт файлів операцій і програмний інтерфейс сервісу.
Вибирають не за зручністю, а за обсягом історії та кількістю майданчиків — у кожного шляху свої обмеження за кількістю операцій і своя ціна помилки в обліку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряме підключення до торгового акаунта | Активна торгівля, сотні угод на місяць, один-два майданчики | Сервіс забирає історію порціями, є стеля за кількістю операцій, частина бірж не віддає угоди старші за певний строк |
| Імпорт файлів операцій | Разові розрахунки, майданчики без підтримки, архівні рахунки | Повторне завантаження дає дублі, стовпці зіставляються вручну, звірку робить людина |
| Програмний інтерфейс сервісу | Нестандартні активи, рахунки поза біржами, регулярний розрахунок | Потрібен свій модуль обміну та його підтримка, є ліміт на частоту запитів |
Пряме підключення до торгового акаунта
Ключ видається лише для читання: торгувати й виводити кошти через нього не можна. Синхронізація йде за розкладом, тому свіжі угоди потрапляють у звіт із затримкою, а глибокий архів біржа часто не віддає взагалі — цю ділянку закриваємо вивантаженням.
Імпорт вивантажень і ручні правила
Вивантаження добирає те, чого немає в підключенні: перекази між власними рахунками, нарахування за зберігання, комісії мережі. Завантаження йде з перевіркою на дублі та правилами зіставлення активів, інакше розрахунок податків роз'їжджається з фактичними залишками за рахунками.
Етапи впровадження: від аудиту операцій до передачі регламенту
Роботи йдуть за етапами, і кожен закінчується артефактом, який можна перевірити: картою операцій, набором правил, протоколом звірки. Порядок однаковий для біржових рахунків, самостійних гаманців і адрес у мережі — змінюється лише спосіб отримання даних.
Аудит операцій і постановка правил
- Інвентаризація джерел. Збираємо біржі, гаманці та мережі, уточнюємо, де достатньо ключа з правом читання, а де потрібні вивантаження.
- Аудит операцій. Розмічаємо типи рухів: угоди, перекази між власними рахунками, винагороди за стейкінг, комісії, виведення у фіат. Переказ між власними гаманцями — не продаж, і найчастіше розрахунок ламається саме на ньому.
- Налаштування правил зіставлення. Задаємо метод списання за кожною парою активів, прив'язку комісій до угод, об'єднання переказів і обробку позицій, за якими немає даних.
- Імпорт і нормалізація. Завантажуємо історію в Koinly і звіряємо підсумкові баланси за кожним рахунком із фактичними — розбіжність одразу показує пропущений період.
- Розмітка спірних операцій. Рішення щодо кожної неоднозначної класифікації фіксуємо письмово, щоб у наступному періоді правило застосовувалося автоматично.
Перевірка на контрольному періоді
Тестова звірка йде на закритому періоді: проганяємо розрахунок, звіряємо результат за вибіркою угод вручну і перевіряємо, що повторний імпорт дає ту саму цифру. Розбіжності зазвичай сидять у трьох місцях — незакриті перекази, комісії без прив'язки та операції з неповними даними.
Після збіжності передаємо регламент: карту джерел і прав доступу, набір правил із поясненнями та порядок щомісячного імпорту. Розрахунок запускається за документом без нашої участі, а зміна правила — це правка одного рядка, а не перезбирання всієї історії.
Комплект передачі: правила зіставлення, схеми, регламенти звірки
Після впровадження у замовника залишається не набір разових скриптів, а робочий комплект: правила зіставлення, схеми потоків і регламенти звірки. За ними розрахунок відтворюється без автора інтеграції — силами штатного бухгалтера або аналітика.
Правила зіставлення та категоризації операцій
- Таблиця правил зіставлення: як операції з вивантажень біржі пов'язуються з угодами, переказами між власними рахунками та зовнішніми адресами, який у кожного правила пріоритет і які винятки зроблено вручну.
- Довідник категорій: комісії, нарахування за стейкінг, airdrop — з ознакою, потрапляє операція в базу оподаткування чи лише у вартість придбання.
- Журнал змін правил: дата, автор, причина правки. Видно, як кожна зміна вплинула на звіти за минулі періоди — розрахунок залишається відтворюваним.
- Набір еталонних вивантажень: тестові дані, на яких правила проганяються після будь-якої правки.
Схеми потоків даних і регламенти звірки
- Схема потоків даних від джерела до Koinly: де нормалізуються ідентифікатори угод, де відсікаються дублі й на якій межі дані вважаються незмінними.
- Інструкція зі звірки: покроковий порядок закриття місяця, контрольні суми за кожним рахунком, порядок розбору при розбіжності.
- Регламент супроводу: періодичність запуску, відповідальний, порядок оновлення довідників при змінах на біржі.
Кейс: як прибрали ручну звірку та розбіжності у звітах
Вихідна ситуація та вузьке місце
Клієнт — біржа з кількома тисячами активних рахунків: облік вівся вивантаженнями в таблиці, а звірку операцій робили вручну.
Через різні формати в однієї й тієї самої операції (торгівля, введення-виведення, нарахування за стейкінгом) з'являлися розбіжності у звітах, а закриття місяця розтягувалося на тижні, і частина періоду йшла на пошук причини розбіжності, а не на сам розрахунок.
Ми забрали вивантаження операцій через програмний інтерфейс біржі й передавали її в Koinly з однозначним зіставленням типів: кожна операція потрапляє у свою категорію, а не в «інше».
Пари угод звіряються автоматично за ідентифікаторами, тому дублі та загублені перекази між рахунками не доходять до бухгалтерії.
Що змінилося у вимірюваних показниках
- Ручні операції при підготовці звіту: було близько 1200 рядків на вивантаження — стало приблизно 40, і лише на розбір винятків.
- Розбіжності між обліком біржі та звітом: з кількох десятків за період до одиниць, кожна закривається із зазначенням причини.
- Закриття місяця: з трьох тижнів до двох робочих днів, включно з перевіркою повноти даних.
- Покриття перевірками: усі введення-виведення та угоди, окремо позначені нарахування за стейкінгом і комісії.
Звітність стала відтворюваною: повторний прогін за тим самим періодом дає той самий результат, а історія змін зберігається поруч із даними.
Чим відрізняється автоматичний розрахунок від вивантаження операцій вручну?
Ручне вивантаження закінчується там, де починається зіставлення операцій. Поки угод десятки, вистачає файлу з історією з особистого кабінету біржі та ручної розмітки рядків: депозит, виведення, торгівля, нарахування.
Але як тільки рахунків стає кілька і між ними ходять перекази, таблиця перестає сходитися: кожна пара «прийшло — пішло» враховується двічі, і це вже не питання зручності, а пряма помилка в базі розрахунку.
Основна трудомісткість ручного обліку — не у вивантаженні, а у звірці. Переказ між власними гаманцями потрібно вручну виключити з розрахунку, винагороду за стейкінг розмітити як дохід, комісії прив'язати до конкретної угоди.
Один невірно розмічений рядок змінює собівартість усієї партії, а розбіжність виявляється в момент звіту, коли перезбирати вже нічого.
Автоматичний розрахунок починається з читання операцій з бірж і гаманців та зв'язування їх за часом, сумою й адресою.
Система сама відрізняє переказ між власними рахунками від продажу, застосовує вибраний метод розрахунку собівартості та перераховує результат, коли підвантажується запізніла транзакція.
Інтеграція з Koinly закриває саме цю частину: операції потрапляють в облік без ручного перенесення, а звірка зводиться до перевірки винятків.
Коротка відповідь: ручне вивантаження відповідає на питання «що було на рахунку», автоматичний розрахунок — на питання «скільки з цього податку». Межа проходить там, де з'являється другий рахунок або гаманець за межами біржі.
Далі ручне перенесення лише дорожчає в трудозатратах і зростає в ймовірності помилки при кожній новій операції.
Часті технічні сумніви перед підключенням
Перед підключенням замовник перевіряє не саме вивантаження, а ризики навколо нього: хто бачить ключі, що буде при збої синхронізації та як рахується рідкісний актив. Зібрали те, що найчастіше спливає на технічному розборі.
Які права потрібні ключам доступу до біржі?
Лише читання: історія угод, баланси, виведення. Торгові та вивідні права не запитуємо — такий ключ фізично не може рухати кошти, навіть якщо потрапить не туди. Якщо біржа не вміє обмежувати права, забираємо історію операцій файлом і імпортуємо за розкладом.
Як зберігаються ключі і що при їх відкликанні?
Ключі передаються в зашифрованому вигляді й лежать у захищеному сховищі секретів, а не в конфігураційних файлах і не в листуванні; доступ до них — за ролями, з журналом звернень.
Відкликання ключа на боці біржі просто зупиняє синхронізацію, а вже завантажені операції залишаються в Koinly — звітність не руйнується.
Кілька бірж і гаманців — в одному звіті?
Так, джерела складаються в єдиний потік операцій: біржі, апаратні та програмні гаманці, мережі. Перекази між власними рахунками розпізнаються як переміщення, а не як продаж, — інакше податок нараховується на актив, який нікуди не йшов.
Що якщо вивантаження обірвалося або актив рідкісний?
Синхронізація йде посторінково й поновлюється з останньої підтвердженої операції, повторний імпорт дублів не створює. Для активів, яких немає в довіднику, додаємо правила зіставлення — обгорнуті та стейкінг-токени.
Правила розрахунку оновлюються без перезбирання інтеграції: змінюється конфігурація, історія перераховується на тих самих даних.
Обговоримо задачу: які дані потрібні для плану робіт
Щоб повернутися з оцінкою обсягу робіт і планом впровадження, повний доступ до майданчиків і вивантаження за всі роки не потрібні. Достатньо описати контур: де зберігаються активи, які сервіси були в обороті та як облік ведеться зараз. Нижче — мінімум, який знімає основну частину невизначеності на старті.
- Список бірж і гаманців, через які реально йшов оборот, — від нього залежить набір з'єднань і парсерів для збору історії.
- Формати, у яких майданчики віддають дані: вивантаження операцій, програмний доступ, експорт із блокчейн-оглядача.
- Облікова політика: як визначається вартість активу на момент отримання і який метод списання ви застосовуєте при продажу.
- Вимоги податкового органу до звітності: які форми і за які періоди потрібно закривати.
- Схема доступу: чи готові видати ключі лише для читання або віддаєте перевагу передачі файлів вивантажень.
- Обсяг історії: скільки років і приблизно скільки операцій потрібно провести через Koinly.
- Поточний облік: таблиці, минулі звіти та ручні звірки, які вже ведуться.
- Хто на вашому боці відповідає за звірку розбіжностей — це прискорює приймання.
За цими пунктами ми описуємо схему зіставлення транзакцій, перелік перевірок на дублі та пропуски, а також етапи впровадження з точками контролю. Опишіть задачу — повернемося з оцінкою та планом робіт.
