Організовуємо облік онлайн-продажів і надходжень від платіжних систем, перевіряємо комісії та повернення, визначаємо ПДВ для вашої моделі торгівлі.
У бухгалтерському обліку електронної торгівлі документи та інформація про строки можуть бути розподілені між кількома людьми. Саме з такою ситуацією зіткнувся клієнт ARG. Команда спочатку перевірила вже виконану роботу, потім організувала збір відсутніх даних і визначила відповідальних за кожен етап. У результаті бухгалтерські завдання більше не залишалися без зв’язку між собою, а весь процес супроводжувала одна команда.
Для інтернет-магазину в Болгарії це має практичне значення. Продажі через Shopify, Amazon або інші платформи потрібно пов’язати із замовленнями, платежами, поверненнями, закупівлями та податковими строками. Окремо слід визначити, чи є бізнес звичайним продавцем, чи може платформа мати спеціальну роль для цілей ПДВ. Від цього залежить подальший облік, оцінка OSS і підготовка річної звітності.
ARG може допомогти, коли вам потрібно
Потрібні юридичний продавець, договори платформ, склади та фактичні країни відправлення для класифікації продажів.
Розділіть готівку, картки, перекази й кур’єрські розрахунки; перевірте чеки, повідомлення магазину та допустимість альтернативи.
Надайте записи замовлень, повернень, комісій, резервів і виплат, які узгоджуються з банківськими та платіжними залишками.
Контролюйте внутрішній оборот, іноземні послуги й країни продажу; розділіть місячні, спеціальні та річні обов’язки.
Електронний магазин за § 1, пунктом 87 додаткових положень ЗДДС — це програмне забезпечення у браузері чи застосунку для дистанційного продажу, вибору товару або послуги та надання контактів, адреси доставки й способу оплати. Рекламна сторінка та оформлення замовлення можуть мати різний статус. Додатково перевіряють, чи приймає продавець платежі, для яких потрібен фіскальний чек: це впливає на обов’язок повідомлення НАП. Для бухгалтерії зберіть приклад замовлення, договір платіжного провайдера, документ продажу й маршрут товару; назва сайту не визначає податковий режим. Збережіть також підтвердження фактичного виконання замовлення та повернення коштів.
Закон Болгарії про податок на додану вартість [ЗДДС] регулює, коли виникає реєстрація і які операції враховуються для цієї мети. За ст. 96 ЗДДС обов’язкова реєстрація стосується особи, установленої в Болгарії, яка здійснює оподатковувані поставки товарів або послуг. До оподатковуваного обороту входять також авансові платежі, одержані після настання податкової події. Тому звіт про замовлення або виставлені рахунки сам по собі не дає достатньої відповіді. Бухгалтер має зіставити дату поставки, оплату, передоплату, повернення коштів і фактичний статус замовлення.
Практична помилка часто виникає тоді, коли власник магазину підсумовує лише виплати від платіжного сервісу. Виплата може бути меншою за суму продажів через комісії, повернення або утримання коштів, а дата зарахування на рахунок не завжди збігається з датою, значущою для ПДВ. Так само закупівля партії товару в іншій державі ЄС має аналізуватися окремо від виручки магазину.
Спосіб оплати перевіряють за фактичним механізмом. Банківський переказ і звичайна карткова оплата мають різні наслідки для фіскального чека. Післяплата не автоматично є поштовим грошовим переказом через ліцензованого оператора: потрібні договір кур’єра та розрахунковий документ. За відповідного поштового винятку клієнт усе одно отримує документ із установленими відомостями. Передайте опис кожного платіжного каналу й приклад розрахунку, щоб узгодити чек, рахунок, звіт перевізника та обліковий запис.
Власнику інтернет-магазину варто підготувати перелік товарних потоків, країни покупців, дані про закупівлі в ЄС і вивантаження операцій за період, що перевіряється. Це дозволяє встановити обов’язок до того, як помилка в класифікації продажу або авансу вплине на ПДВ-облік.
Звичайний продавець продає товар покупцеві від власного імені та за власною моделлю постачання. Оператор електронного інтерфейсу забезпечує або полегшує укладення продажів через маркетплейс чи іншу цифрову платформу. Ці ролі не збігаються автоматично, а їх правильне розмежування визначає, хто повинен аналізувати ПДВ за конкретною операцією.
Магазин на Shopify зазвичай не стає оператором електронного інтерфейсу лише через використання цього технічного рішення. Якщо бізнес розміщує власний каталог, приймає замовлення на власні товари та сам є стороною продажу, він залишається продавцем. Для такого бізнесу слід насамперед аналізувати його власні поставки, покупців, рух товару та платежі.
Офіційне роз’яснення Національної агенції з доходів щодо спеціальних режимів ПДВ пояснює іншу, вужчу ситуацію. Оператор електронного інтерфейсу може нести ПДВ-відповідальність, коли він полегшує продажі від постачальника, не установленого в ЄС, кінцевим споживачам у ЄС. Цей підхід має значення переважно для маркетплейсу або платформи, яка фактично бере участь у ланцюгу відповідних продажів. Сам факт, що продавець отримує кошти через платіжний сервіс або користується готовою вітриною магазину, не доводить такого статусу.
ПДВ-відповідальність не можна визначити за комерційною назвою сервісу. Потрібно встановити фактичну роль кожної сторони. Для цього ARG перевіряє:
Це розмежування не слід змішувати з правилами дистанційних продажів. Дистанційний продаж описує вид операції та її податковий зв’язок із державою покупця. Статус оператора інтерфейсу стосується того, чи може платформа мати власну ПДВ-відповідальність за визначені поставки. У певній бізнес-моделі обидва питання можуть виникнути одночасно, але відповідь на одне з них не замінює відповіді на інше.
Практичний наступний крок полягає в перевірці договору з платформою, публічних умов продажу, даних про продавця та звітів за операціями. Якщо документи показують, що бізнес є звичайним продавцем, облік має відображати його власну виручку і податкові наслідки. Якщо ж платформа виконує роль, яка може охоплюватися спеціальними правилами, необхідно окремо визначити операції, за які вона може відповідати, не переносячи цей висновок на всі продажі магазину.
Розкажіть про свою ситуацію та плани в Болгарії. Допоможемо визначити, які питання потрібно вирішити та з чого почати.
Добровільна ПДВ-реєстрація може бути доцільною, але режим OSS не є її заміною. Спочатку слід встановити, чи вже виникла обов’язкова реєстрація за характером і обсягом операцій. Якщо так, бізнес не обирає між добровільною реєстрацією та відсутністю реєстрації. Якщо обов’язку ще немає, ст. 100 ЗДДС допускає добровільну реєстрацію. Рішення має спиратися на фактичну модель продажів, а не лише на намір працювати з покупцями з інших держав ЄС.
Добровільна реєстрація потребує окремої оцінки комерційного наслідку. ARG аналізує, де перебувають покупці, звідки відправляється товар, чи продає бізнес переважно кінцевим споживачам, які країни створюють найбільший обсяг замовлень та як це відображено в платіжних і товарних даних. Також важливо відокремити продажі від закупівель, оскільки придбання товару в ЄС може мати власні наслідки для реєстрації.
Режим «у Союзі» за ст. 156 ЗДДС охоплює, зокрема, внутрішньоспільнотові дистанційні продажі товарів і визначені B2C-послуги. Офіційне роз’яснення Національної агенції з доходів підтверджує, що цей спеціальний режим стосується саме таких транскордонних операцій. Він не скасовує потреби встановити загальний ПДВ-статус продавця та не перетворює всі продажі магазину на операції за OSS.
Від 1 січня 2026 року НАП також зазначає виняток для поставок, щодо яких у відповідній державі-члені застосовується режим малих підприємств ЄС. Особа, зареєстрована в режимі «у Союзі», не декларує через нього такі поставки в цій державі. Це правило вимагає окремої перевірки країни покупця та застосовного до продавця режиму. Його не можна застосувати лише тому, що покупець проживає в ЄС.
Наприклад, якщо болгарський магазин відправляє товари споживачам у кількох державах ЄС, ARG спочатку розділяє продажі за країною призначення, датою, сумою та статусом повернення. Лише після цього можна оцінити, чи відповідають операції умовам OSS і чи не діє для частини з них режим малих підприємств ЄС.
Альтернатива фіскальному чеку для відповідних дистанційних карткових платежів за Н-18 має окремі умови. Потрібні належне програмне забезпечення, повідомлення про магазин і платіжні рахунки, передбачений документ продажу з даними замовлення та транзакції, а також щомісячний файл додатка 38 до п’ятнадцятого числа наступного місяця. Саме використання Stripe або PayPal не підтверджує відповідності. Перевірте зразок документа й експорт до запуску; цей спеціальний файл не слід плутати із загальною програмою SAF-T.
Указана вартість супроводу становить 180. До початку роботи погодьте перелік магазинів, платформ і платіжних рахунків, обсяг операцій, формат вивантаження та відповідального за повернення. Окремо визначте потребу у відновленні минулих записів, ПДВ-реєстрації, налаштуванні фіскальних документів і спеціальній транскордонній звітності. Узгоджений обсяг дає змогу організувати регулярне передання даних і не залишити поза обліком додатковий канал продажів.
Для правильного обліку електронної торгівлі недостатньо бачити лише суму, що надійшла на банківський рахунок. Бухгалтерові потрібен зв’язок між замовленням, поставкою, оплатою, комісією платіжного сервісу, поверненням і фактичним зарахуванням коштів. Саме цей ланцюг дозволяє відокремити виручку магазину від утримань посередника та встановити дати, значущі для ПДВ-обліку.
ARG організовує звірку за єдиним переліком ідентифікаторів. Замовлення в інтернет-магазині має співвідноситися з операцією у Stripe або PayPal, банківською випискою, рахунком або іншим документом продажу, інформацією про відправлення товару та записом про повернення. Коли один запис не має номера замовлення, дати, валюти або даних про покупця й країну призначення, його неможливо безпечно класифікувати лише за сумою.
Для щомісячної звірки доцільно надати:
Комісія платіжного сервісу не зменшує автоматично суму продажу. Якщо покупець сплатив одну суму, а сервіс переказав менше після утримання комісії, облік повинен показати обидва елементи окремо. Так само повернення може означати повне скасування продажу, часткове коригування або виплату, яка ще не відображена у банку через часову різницю. Без перевірки первинного запису бухгалтер не повинен прирівнювати банківський рух до доходу від конкретного замовлення.
Особливої уваги потребують передоплати. Вони можуть бути зараховані платіжним сервісом раніше, ніж товар відправлено, а виплата магазину може надійти пізніше через графік сервісу. Дані мають дозволяти відрізнити дату оплати покупцем від дати виплати продавцеві та дати виконання замовлення. Це важливо, оскільки для ПДВ не завжди визначальною є дата банківського зарахування.
Коли повідомлення НАП про електронний магазин обов’язкове, його подають до початку продажів, а зміни відомостей чи припинення — протягом семи днів. Продавці, які приймають лише платежі без обов’язку фіскального чека, не зобов’язані подавати таке повідомлення, хоча можуть зробити це добровільно. Під час зміни домену, платформи, хостингу або провайдера зіставте фактичні дані з поданими. Збережіть підтвердження прийняття; технічний підрядник може підготувати інформацію, але відповідальну особу має визначити продавець.
Річне звітування потрібно планувати як окремий корпоративний процес, а не залишати його на завершення ПДВ-обліку. Закон Болгарії про бухгалтерський облік [ЗСч] регулює підготовку та оприлюднення річної фінансової звітності. За ст. 38 ЗСч підприємства публікують річний фінансовий звіт, річний звіт про діяльність, а за наявності консолідації також консолідовані звіти, до 30 вересня наступного року. Для торговців подання відбувається через Торговий реєстр.
Цей строк має конкретну передумову. До публікації звіти повинні бути прийняті загальними зборами або іншим компетентним органом підприємства. Підготовлена бухгалтером звітність ще не є поданою звітністю. Потрібне корпоративне рішення про її схвалення, після чого формується пакет для оприлюднення. Якщо підготовку цифр, внутрішнє погодження і подання не розподілити завчасно, строк до 30 вересня може бути пропущений навіть за наявності готових облікових даних.
ARG допомагає визначити робочий розподіл між власником або органом управління, працівниками, які збирають документи, та бухгалтером. Бухгалтерська частина охоплює перевірку повноти облікових даних, підготовку звітності та виявлення операцій, які потребують пояснення або коригування. Орган, уповноважений компанією, приймає звіти. Подання через Торговий реєстр завершує процес оприлюднення.
Для інтернет-магазину річна підготовка часто залежить від того, чи звірені виплати платіжних сервісів, залишки товару, повернення та документи постачальників. Невідповідність між обліком продажів і зведеними виплатами платформи не є дрібною технічною проблемою. Вона може вплинути на показники річного фінансового звіту та вимагати з’ясування до схвалення звітності.
ARG рекомендує встановити внутрішній календар. У ньому окремо визначають дату завершення звірки за рік, строк передачі відсутніх документів, особу для погодження проєкту звітності, орган для корпоративного схвалення та відповідального за подання. Це не змінює законодавчого строку, проте дає змогу виявити нестачу даних до фінального етапу.
Якщо компанія має кілька власників, рішення про прийняття звітності варто планувати так, щоб усі необхідні корпоративні дії були завершені до подання. За наявності групи компаній необхідність консолідованої звітності перевіряється окремо, оскільки ЗСч прямо передбачає її публікацію за наявності консолідації. Наступне предметне рішення для власника e-commerce-бізнесу полягає у призначенні відповідальних за річний пакет уже під час регулярного обліку, а не після закриття року.
Порівняйте пов’язані процедури в цій категорії: їхні вимоги та етап, на якому вони потрібні для вашого завдання.
.svg)
.svg)
