Бухгалтерія для інтернет-магазинів і маркетплейсів

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

Робоча модель будується навколо order-to-cash: номер замовлення, канал продажу, спосіб оплати, фіскальний документ, відвантаження, повернення, комісія та банківське зарахування повинні бути зв’язані. Для ФОП і ТОВ податкові режими різні, але вимога до контрольованого потоку даних однакова: за кожною сумою має бути зрозуміло, що саме відбулося.

Які e-commerce моделі потребують окремої бухгалтерської логіки

Найскладніший варіант — omnichannel, коли один SKU продається через кілька майданчиків і всі вони по-різному передають звіти. Тоді до бухгалтерії додається master-data задача: єдиний код товару, єдині правила для статусів замовлення та зіставлення marketplace report із банком і складом.

Для міжнародних платформ окремо перевіряються валюта, договори, місце постачання послуг, комісії нерезидентів і можливі податкові наслідки. Ця сторінка не замінює повний ЗЕД-супровід, але e-commerce accounting має передати туди правильні первинні дані.

Що входить у бухгалтерський супровід інтернет-магазину

• налаштування реєстру замовлень і зв’язку з банком, еквайрингом та касою;
• контроль РРО/ПРРО за способами оплати та каналами продажу;
• звірка післяплати з даними перевізника і фактичними зарахуваннями;
• облік продажів через маркетплейси за gross-оборотом, комісіями та payout;
• повернення покупців, часткові повернення, обміни й коригування чеків;
• облік товарних запасів, закупівель, списань і собівартості;
• еквайрингові, marketplace, рекламні та логістичні комісії;
• ПДВ і податкові накладні для платників ПДВ;
• контроль лімітів і умов системи оподаткування для ФОП;
• щомісячний close із reconciliation замовлень, каси, складу та банку.

Як запускаємо облік e-commerce

На старті не обов’язково будувати складну ERP. Для невеликого магазину достатньо дисциплінованого експорту замовлень, правил назв і контрольної таблиці. Критично, щоб кожен канал давав стабільний звіт і щоб дані не редагувалися вручну без сліду.

Для магазину з сотнями замовлень ручне зіставлення швидко стає дорожчим за автоматизацію. Тоді погоджуємо, які поля передаються з CMS/CRM, які — з ПРРО, які — з маркетплейсу, і де формується «джерело правди». Бухгалтерія контролює не лише проводки, а й повноту імпорту.

Які дані потрібні на старті

Потрібні виписки банків, договори з еквайєрами, маркетплейсами і перевізниками, звіти за замовленнями, список способів оплати, РРО/ПРРО, номенклатура товарів, залишки складу, закупівельні документи та правила повернення.

Для маркетплейсів окремо збираємо payout statements із розшифровкою комісій. Для післяплати — реєстри перевізника. Якщо магазин є платником ПДВ, додаємо правила формування податкових накладних і контроль дат податкових подій.

Типові помилки e-commerce бухгалтерії

• вважати банківське зарахування повним відображенням продажу;
• змішувати IBAN-переказ і карткову оплату в одному сценарії РРО;
• обліковувати net payout маркетплейсу як виручку без комісії;
• не звіряти повернення товару з поверненням грошей і фіскальним документом;
• мати різні SKU одного товару в CMS, маркетплейсі та обліку;
• списувати товар за оплатою, не контролюючи фактичне відвантаження;
• не розділяти рекламу, логістику й комісію платформи за каналами;
• помічати податкові та касові помилки лише під час декларації.

Маркетплейс: чому потрібен gross-to-net reconciliation

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

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

Повернення, обміни та незабрані посилки

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

Для масових продажів корисний weekly exception report: замовлення зі статусом delivered без оплати, оплата без чека, чек без замовлення, refund без повернення товару, payout без розшифровки. Бухгалтер працює з винятками, а не переглядає вручну весь масив.

ФОП чи ТОВ: що змінюється

Для ФОП важливі ліміти, дозволені види діяльності, правила доходу та РРО/ПРРО. Для юридичної особи додаються повноцінний бухгалтерський облік, запаси, собівартість, дебіторка/кредиторка, податок на прибуток та, за наявності, ПДВ. Базові сторінки — бухгалтерія ФОП і бухгалтерія ТОВ.

Контрольний календар e-commerce

Щодня або автоматично контролюємо критичні розриви між оплатою, чеком і статусом замовлення. Щотижня переглядаємо повернення, незакриті післяплати, негативні залишки та marketplace deductions. Наприкінці місяця фіксуємо cut-off: які замовлення завершені, які ще в доставці, які кошти зависли у платіжного провайдера та які повернення ще не завершені.

Для власника корисний компактний dashboard: gross sales, refunds, net sales, average order, marketplace fees, delivery cost, gross margin і залишок товару. Бухгалтерські дані не повинні дублювати CRM, але вони мають підтверджувати фінансовий результат. Саме тому reconciliation є частиною послуги, а не разовою перевіркою перед декларацією.

Чим ця сторінка відрізняється від бухгалтерії торгівлі

Бухгалтерія для торгівлі охоплює загальний товарний контур — закупівлі, склад, продажі та ПДВ. Ця сторінка відповідає за специфіку онлайн-продажу: order-to-cash, еквайринг, маркетплейси, післяплату, повернення та цифрову звірку каналів. Якщо бізнес одночасно має офлайн-магазин, обидва контури об’єднуються в одному close.

Від чого залежить вартість

На ціну впливають кількість замовлень і каналів, число маркетплейсів, РРО/ПРРО, складський облік, ПДВ, кількість юридичних осіб/ФОП, повернення, інтеграції та якість вихідних даних. Після короткого data review можна визначити фіксований щомісячний scope.

Часті запитання

Чи потрібен РРО/ПРРО при оплаті карткою на сайті?

Для типового карткового розрахунку ДПС вказує на необхідність застосування РРО/ПРРО. Конкретний платіжний сценарій перевіряється за договором і рухом коштів.

А якщо покупець платить на IBAN?

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

Як обліковувати продаж через маркетплейс?

Від gross sales: окремо виручка/продаж, повернення, комісії та інші утримання, після чого net payout звіряється з банком.

Чи можна вести облік лише за банком?

Для e-commerce це ризиково: банк не показує повну історію замовлення, склад, чек, повернення й структуру marketplace deductions.

Чи входить складський облік?

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