№15111-д і DAC7 — важлива тема для команд, які розвивають маркетплейси, сервіси бронювання, платформи для замовлення послуг або інші цифрові продукти, де користувачі отримують дохід. В українському інформаційному просторі такі зміни часто називають «законом про податки на платформах», але для оператора платформи питання ширше: дані користувачів, процеси перевірки, звітність, договори, інформаційна безпека та комунікація з продавцями.

Спершу зафіксуйте правильну версію документа

У пошуку можна побачити №15111, альтернативні проєкти та доопрацьований №15111-д. Для правил щодо міжнародного автоматичного обміну інформацією про доходи через цифрові платформи потрібно дивитися саме на редакцію, яка пройшла розгляд, і на подальші офіційні акти. Верховна Рада повідомляла, що №15111-д було прийнято в другому читанні та в цілому 9 червня 2026 року. Однак дизайн процесів не варто будувати на переказах: перевіряйте картку, текст і хронологію документа, а також офіційне опублікування та роз’яснення.

DAC7 і Модельні правила ОЕСР стосуються звітності операторів цифрових платформ у різних юрисдикціях. Українська імплементація має власний текст, строки та винятки. Тому міжнародний досвід корисний для підготовки, але не замінює аналіз українських вимог.

Складіть карту даних продавця

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

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

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

Розділіть дані, виплати та податки

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

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

Оновіть договори та комунікацію

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

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

Не забудьте про безпеку і тестування

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

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

Призначте відповідального за міжкомандні рішення

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

Що це означає для невеликого сервісу

Невелика дошка оголошень або платформа послуг не повинна самостійно вигадувати юридичну модель. Але вже зараз можна підтримувати якість профілів, логувати ключові події, зберігати історію виплат і не будувати процеси, які залежать від ручних повідомлень у месенджері. Для публікації пропозицій на Kram використовуйте зрозумілу форму додавання оголошення, а для сервісних пропозицій — точну категорію «Бізнес та послуги».

Найкращий результат дає не одна «юридична галочка», а спільна робота продукту, розробки, фінансів, безпеки та юристів над одним прозорим процесом.

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