Бухгалтерия интернет-магазина или продавца на маркетплейсе должна сводить в одну систему заказ, оплату, РРО/ПРРО, наложенный платеж, эквайринг, комиссии площадки, возвраты и склад. Для налогового контроля важно отличать прямой платеж на текущий счет по полным реквизитам IBAN от карточных и других расчетных операций. Для управления бизнесом нужен еще один уровень: выручка и маржа считаются по заказу и каналу продаж, а не только по сумме банковских зачислений.
В e-commerce одна операция почти никогда не равна одной банковской строке. Покупатель оформляет заказ сегодня, платежный сервис отдельно подтверждает оплату, товар передается перевозчику, маркетплейс или эквайер удерживает комиссию, а деньги приходят через несколько дней. Если бухгалтерия берет за основу только payout, часть оборота и расходов теряется из аналитики.
Рабочая модель строится вокруг order-to-cash: номер заказа, канал, способ оплаты, фискальный документ, отгрузка, возврат, комиссия и банковское зачисление должны быть связаны. Для ФОП и ООО/ТОВ налоговые режимы отличаются, но принцип контроля одинаков: по каждой сумме должно быть понятно, какое хозяйственное событие произошло.
Какие e-commerce модели требуют отдельной логики учета
Сайт принимает оплаты, формирует заказы и передает товар службе доставки.
Площадка принимает оплату, удерживает комиссии, может организовывать логистику и перечисляет продавцу net payout.
Продажи идут через сайт, соцсети, маркетплейсы, почтовых операторов и офлайн-точку.
Самая сложная модель — omnichannel, когда один SKU продается через несколько площадок, а отчеты у каждой разные. Тогда появляется master-data задача: единый код товара, единые статусы заказа и сопоставление marketplace report с банком и складом.
Для иностранных платформ отдельно проверяются валюта, договоры, комиссии нерезидентов и возможные налоговые последствия. Это не заменяет полное ВЭД-сопровождение, но e-commerce accounting должен передавать туда корректные первичные данные.
Что входит в бухгалтерское сопровождение интернет-магазина
- реестр заказов и связь с банком, эквайрингом и кассой;
- контроль РРО/ПРРО по способам оплаты и каналам;
- сверка наложенного платежа с реестрами перевозчика;
- учет маркетплейсов по gross-обороту, комиссиям и payout;
- возвраты, частичные возвраты, обмены и корректировки чеков;
- товарные остатки, закупки, списания и себестоимость;
- эквайринговые, marketplace, рекламные и логистические комиссии;
- НДС и налоговые накладные для плательщиков НДС;
- контроль лимитов и условий режима ФОП;
- monthly close с reconciliation заказов, кассы, склада и банка.
Как сверяем продажу от заказа до денег
Ошибки появляются, когда одна система видит заказ, другая — оплату, третья — чек, четвертая — payout.
| Этап | Что фиксируем | Контроль |
|---|---|---|
| Заказ | Номер, SKU, цена, скидка, канал, способ оплаты. | Не считать отмененные заказы продажей. |
| Оплата / чек | Payment ID, дата, сумма, РРО/ПРРО, возврат. | Проверить, требует ли способ расчета фискализации. |
| Отгрузка | Накладная, перевозчик, COD, статус доставки. | Разделить доставленные, возвращенные и незабранные посылки. |
| Payout | Gross sales, комиссии, удержания, net payment. | Сверить statement площадки с банком, не считать payout всей выручкой. |
Платеж на IBAN и карточная оплата — не один сценарий РРО
ГНС в разъяснении от 31.07.2026 указывает: при интернет-продаже наличные, платежная карта и другие расчетные способы требуют РРО/ПРРО, а оплата исключительно на текущий счет по полным реквизитам IBAN не является расчетной операцией в понимании Закона №265. Проверяется реальный payment flow, а не название кнопки на сайте.
Как запускаем учет e-commerce
Фиксируем сайты, маркетплейсы, кассы, эквайеров, доставку и банки.
Унифицируем ID заказа, SKU, payment status и документы.
Сверяем sales report → чек → доставка → payout → банк.
Закрываем возвраты, комиссии, остатки, налоги и channel P&L.
Для небольшого магазина не обязательно сразу внедрять ERP. Достаточно стабильных выгрузок, единых названий и контрольного реестра. Главное — чтобы каждый канал давал воспроизводимый отчет и ручные изменения не уничтожали историю.
При сотнях заказов ручное сопоставление становится отдельной затратой. Тогда определяем, какие поля приходят из CMS/CRM, какие — из ПРРО, какие — из marketplace statement, и где находится «источник истины». Бухгалтер контролирует не только проводки, но и полноту импорта.
Какие данные нужны на старте
Нужны банковские выписки, договоры с эквайерами, маркетплейсами и перевозчиками, отчеты по заказам, способы оплаты, РРО/ПРРО, номенклатура, складские остатки, закупочные документы и правила возврата.
По маркетплейсам отдельно нужны payout statements с расшифровкой удержаний. По наложенному платежу — реестры перевозчика. Для плательщика НДС добавляется схема налоговых накладных и контроль налоговых событий.
Типичные ошибки e-commerce учета
- считать банковское зачисление полным отражением продажи;
- смешивать IBAN и карточную оплату в одном сценарии РРО;
- учитывать net payout маркетплейса как выручку без комиссии;
- не связывать возврат товара, денег и фискального документа;
- иметь разные SKU в CMS, маркетплейсе и учете;
- списывать товар по оплате без контроля отгрузки;
- не разделять рекламу, логистику и комиссии по каналам;
- находить кассовые и налоговые ошибки только при подаче декларации.
Маркетплейс: зачем нужен gross-to-net reconciliation
В одном statement могут быть продажи, возвраты, комиссия, логистика, реклама, штрафы и компенсации. На банковский счет поступает только итоговый payout. Поэтому close начинается со statement площадки: gross sales сверяются с выполненными заказами, удержания классифицируются отдельно, после чего net payout сопоставляется с банком.
Так же строится channel profitability. Две площадки могут давать одинаковый оборот и разную маржу. Управленческий отчет должен показать комиссию, логистику и рекламу отдельно, иначе решения принимаются по выручке, а не по результату.
Возвраты, обмены и незабранные посылки
Возврат — отдельный workflow: товар физически вернулся, его состояние проверено, склад восстановлен, деньги возвращены покупателю, фискальный документ оформлен. Если одна стадия пропущена, склад, касса и банк расходятся. Для наложенного платежа отдельно выделяются незабранные посылки.
При массовых продажах полезен weekly exception report: delivered без оплаты, оплата без чека, чек без заказа, refund без возврата товара, payout без детализации. Бухгалтер работает с исключениями, а не просматривает весь массив вручную.
ФОП или ООО/ТОВ: что меняется
Для ФОП важны лимиты, разрешенные операции, правила дохода и РРО/ПРРО. Для юрлица добавляются полный учет запасов, себестоимость, дебиторка/кредиторка, налог на прибыль и НДС. Базовые контуры — бухгалтерия ФОП и бухгалтерия ООО/ТОВ.
Контрольный календар e-commerce
Ежедневно или автоматически контролируются разрывы между оплатой, чеком и статусом заказа. Еженедельно разбираются возвраты, незакрытый наложенный платеж, отрицательные остатки и marketplace deductions. В конце месяца фиксируется cut-off: какие заказы завершены, какие еще в доставке, какие деньги находятся у платежного провайдера и какие refunds не закрыты.
Для собственника полезен короткий dashboard: gross sales, refunds, net sales, average order, marketplace fees, delivery cost, gross margin и товарный остаток. Бухгалтерские данные не должны дублировать CRM, но обязаны подтверждать финансовый результат. Поэтому reconciliation становится регулярной частью сопровождения.
Интеграции без потери контроля
API и автоматические выгрузки уменьшают ручную работу, но не отменяют контроль. Перед автоматизацией определяются обязательные поля, правила обработки дублей, даты cut-off и способ повторной загрузки. После обновления CMS, маркетплейса или ПРРО делается контрольная сверка, чтобы техническое изменение не создало систематическую ошибку в учете.
Отдельно фиксируется ответственность за master data: кто создает новый SKU, меняет цену, добавляет способ оплаты и подключает новый канал. Изменение без бухгалтерского review может повлиять на РРО, склад, НДС или структуру отчета. Поэтому новый marketplace или payment method вводится через короткий checklist, а не только через техническую интеграцию.
Чем эта страница отличается от бухгалтерии торговли
Бухгалтерия торговли покрывает общий товарный контур — закупки, склад, продажи и НДС. Здесь основной фокус — online order-to-cash: эквайринг, маркетплейсы, наложенный платеж, возвраты и цифровая сверка каналов. При наличии офлайн-магазина оба контура объединяются в одном close.
От чего зависит стоимость
Цена зависит от количества заказов и каналов, маркетплейсов, РРО/ПРРО, склада, НДС, числа ФОП/юрлиц, возвратов, интеграций и качества исходных данных. После data review можно определить fixed monthly scope.
Частые вопросы
Нужен ли РРО/ПРРО при оплате картой на сайте?
Для типового карточного расчета ГНС указывает на необходимость РРО/ПРРО. Конкретный сценарий проверяется по договору и движению денег.
А при оплате на IBAN?
Когда покупателю предоставлены полные банковские реквизиты и деньги поступают исключительно на текущий счет, ГНС отделяет это от расчетной операции по Закону №265.
Как учитывать продажи маркетплейса?
От gross sales: отдельно продажи, возвраты, комиссии и другие удержания, затем net payout сверяется с банком.
Можно вести учет только по банку?
Для e-commerce этого недостаточно: банк не показывает заказ, чек, склад, возврат и структуру marketplace deductions.
Входит ли складской учет?
Да, в согласованном scope: номенклатура, движение товара, возвраты, инвентаризации и себестоимость.
Вывод
Качественный e-commerce accounting связывает заказ, оплату, фискализацию, доставку, склад и payout в один контролируемый процесс. Тогда налоговая отчетность строится на согласованных данных, а собственник видит реальную маржу каждого канала.
Нужна бухгалтерия интернет-магазина или маркетплейсов?
Опишите каналы продаж, способы оплаты, маркетплейсы, ПРРО, склад и примерное количество заказов. Предложим схему данных и monthly close.
Официальные источники
Нормативная часть проверена по состоянию на 25.09.2026. РРО/ПРРО оценивается по фактическому способу расчета и действующей редакции Закона №265 и НКУ.