Продавець гортає свою панель керування Shopify і бачить 60% валової маржі на свій найкращий продукт. Він почувається чудово. Потім його бухгалтер витягує підсумкові цифри за рік, і реальна маржа стає ближчою до 38%. Інші 22 відсоткові пункти були тихо з’їдені вхідним фрахтом, митами, зборами за комплектування 3PL, доплатами в пік сезону та втраченими одиницями на складі Amazon, які ніхто не спромігся списати. Ласкаво просимо до найдорожчої сліпої зони бухгалтерського обліку в електронній комерції: «фантомної» собівартості реалізованих товарів (Phantom COGS).
Багатоканальні продавці отримують приблизно на 190% більше доходу, ніж роздрібні торговці з одним каналом, але вони також успадковують на 190% складнішу бухгалтерію. Запаси знаходяться в п’яти місцях одночасно, звіти про розрахунки надходять у трьох різних форматах, збори мають 14 видів, а одиниці товару щодня губляться, повертаються або перекласифікуються між маркетплейсами. Якщо у вас немає продуманої системи для повної собівартості (landed costs), зарезервованих запасів, узгодження розрахунків та фінального коригування наприкінці року, ваш звіт про прибутки та збитки (P&L) — це вигадка.
Цей посібник описує чотири кроки, які перетворять вигадку на чисту Головну книгу.
Що вважається собівартістю реалізованих товарів для онлайн-продавця
Собівартість реалізованих товарів (COGS) — це прямі витрати на виробництво або придбання товарів, які ви фактично продали за певний період. Для продавця фізичних товарів формула виглядає просто:
COGS = Початкові запаси + Чисті закупівлі + Вхідний фрахт + Мита + Прямі витрати на оплату праці − Кінцеві запаси
У простоті криється пастка. Більшість продавців вносять у «Чисті закупівлі» лише рахунок від постачальника і на цьому зупиняються. Усе інше — витрати, які ви фактично заплатили, щоб довести продукт до стану готовності до продажу у вашому вузлі виконання замовлень — скидається в кошики різних витрат і ніколи не повертається до собівартості одиниці товару. Ось як маржа 60% стає 38% без того, щоб хтось це помітив.
IRS очікує включення повної собівартості (landed cost) у запаси, так само як і ваші інвестори, кредитори та ви самі в майбутньому, коли намагатиметеся встановити ціну для нового маркетплейсу.
Крок 1: Розрахуйте справжню повну собівартість (Landed Cost) на SKU
Повна собівартість (landed cost) — це сума, яку фактично коштує доставка однієї одиниці товару до місця, звідки вона буде відвантажена, готовою до продажу. Для більшості операцій в електронній комерції компонентами є:
- Вартість постачальника: ціна за рахунком після об’ємних знижок та рибейтів.
- Вхідний фрахт: морські, авіаційні, залізничні або автомобільні перевезення від заводу до порту і далі до вашого складу або доку приймання 3PL.
- Мита та тарифи: ставки мита за класифікацією HTS, тарифи Розділу 301, де це застосовно, і збори за митне оформлення вантажів.
- Митне брокерство та страхування: фіксовані збори за кожну декларацію плюс страхові премії за вантаж.
- Збори за приймання товару: 3PL зазвичай стягують плату за палету, за коробку або за годину роботи за приймання та розміщення товарів.
- Підготовка та маркування: пакування в пакети, бандлювання, етикетки FNSKU, наклейки з датою придатності — усе, що вимагає маркетплейс призначення.
- Пакувальні матеріали: брендовані конверти, амортизаційні матеріали, вкладиші та подарункові карти, якщо вони відправляються з кожною одиницею.
Ви розподіляєте ці витрати на одиниці товару, використовуючи метод, що відповідає чиннику витрат. Вартість постачальника та підготовка розраховуються на одиницю. Вхідний фрахт і мита зазвичай розподіляються за вагою, об’ємом або вартістю рахунку між одиницями в поставці. Збори за приймання можуть бути розраховані за палету та розподілені між одиницями на цій палеті.
Математика проста, але дисципліна — ні. Рішення, яке працює майже для кожного продавця з доходом понад 1 мільйон доларів, — це єдиний власний каталог витрат. Кожне нове замовлення на закупівлю (PO) перераховує повну собівартість для кожного SKU, якого воно стосується, і нова собівартість одиниці стає шаром запасів для отриманих одиниць. Таблиці працюють до певного моменту; якщо у вас понад 200 SKU у більш ніж одному каналі виконання замовлень, вам потрібне програмне забезпечення.
Крок 2: Відстежуйте запаси, де б вони не перебували
У багатоканальній системі один і той самий SKU може існувати в п’яти різних станах інвентарю одночасно:
- У дорозі від постачальника: право власності могло перейти в порту, тому це ваші запаси, але вони ще не готові до приймання.
- На вашому 3PL, доступно для продажу: робочий запас, з якого комплектуються замовлення для DTC, eBay, Walmart, Shopify тощо.
- На Amazon, доступно для продажу (FBA): запас, доступний для замовлень Prime, що враховується у ваших лімітах на поповнення.
- На Amazon, зарезервовано: одиниці, позначені як такі, що перебувають у дорозі між центрами виконання замовлень, у процесі обробки замовлення клієнта або коригування запасів. Цей кошик невидимий для вашої системи поповнення, але він є вашим активом.
- На Amazon, непридатне для продажу: повернуті, пошкоджені або протерміновані одиниці, що очікують на розпорядження.
Кожен із цих станів має відповідати субрахунку у вашому балансі або, як мінімум, аналітичному розрізу в книзі обліку запасів. Коли продавці звалюють усе в один рядок «Запаси», вони втрачають можливість побачити, що Amazon тримає зарезервованих товарів на 80 000 доларів, які не рухалися 21 день — справжня проблема грошових потоків, що ховається в сліпій зоні бухгалтерського обліку.
Зокрема для кошика «зарезервовано FBA» (FBA reserved), робіть звірку зі звітом Amazon Inventory Ledger Report та звітом Manage FBA Inventory принаймні щомісяця. Зарезервовані одиниці, термін перебування яких перевищує кілька тижнів, зазвичай вказують на проблему з маршрутизацією, яку ви можете виправити; зарезервовані одиниці, які ніколи не з’являються знову, мають стати об’єктом претензії на відшкодування.
Крок 3: Узгоджуйте розрахунки на маркетплейсах, а не банківські депозити
Найбільша помилка нових бухгалтерів у сфері електронної комерції — сприйняття загальної суми виплат від Amazon або Shopify Payments як доходу. Це не дохід. Це залишок доходу після того, як маркетплейс вирахував з нього десятки видів операцій.
Типовий двотижневий розрахунковий депозит Amazon може бути алгебраїчною сумою наступних показників:
- Валові продажі товарів
- Дохід від доставки, зібраний з покупців
- Дохід від пакування подарунків
- Промо-знижки, надані покупцям (від’ємне значення)
- Повернення коштів (від’ємне значення)
- Комісії за залучення (referral fees) (від’ємне значення)
- Комісії FBA за виконання замовлень (від’ємне значення)
- Щомісячні комісії за зберігання (від’ємне значення)
- Комісії за довготривале зберігання (від’ємне значення)
- Комісії за вхідні поставки (від’ємне значення)
- Комісії за вилучення та утилізацію (від’ємне значення)
- Витрати на рекламні послуги (від’ємне значення)
- Податок з продажів, зібраний та перерахований (наскрізний платіж)
- Утримання в резерв (від’ємне у цьому періоді, додатне при вивільненні)
- Відшкодування за втрачені або пошкоджені одиниці товару (додатне значення)
Якщо ви записуєте чистий депозит як «Продажі Amazon», кожен із цих рядків зникає з вашого обліку. Ваш дохід занижений, ваші комісії ніколи не розподіляються за категоріями, а собівартість реалізованих товарів (COGS) не співвідноситься з правильним каналом продажу.
Правильний підхід полягає в тому, щоб імпортувати звіт про розрахунки, відносити кожну категорію комісій на власний рахунок витрат, а валовий дохід і повернення відображати окремо. Більшість інструментів бухгалтерського обліку, орієнтованих на e-commerce, роблять це шляхом узагальнення кожного розрахунку в журнальну проводку на 10–30 рядків, яка після проведення точно дорівнює банківському депозиту. Потім цей депозит узгоджується з банком одним кліком, і ви вперше бачите свій реальний валовий дохід, реальне навантаження комісій та прибутковість каналу.
Окремий рахунок оборотних активів «Amazon Reserves» містить утримані кошти. Коли Amazon вивільняє резерви в наступному розрахунку, ви переміщуєте кошти з рахунку Reserves на рахунок Cash. Саме так ви ведете чесний балансовий звіт, замість того щоб вдавати, що гроші, до яких ви не можете доторкнутися, вже лежать у банку.
Точний бухгалтерський облік на маркетплейсах з першого дня — це те, що відрізняє продавців, які можуть впевнено підвищувати ціни, погоджуватися на умови венчурного боргу (term sheet) або продавати свій магазин, від продавців, які за тиждень до податкового дедлайну в паніці відновлюють дані про комісії за рік.
Крок 4: Вистежуйте «фантомну» собівартість (COGS) наприкінці року
Фантомна собівартість — це розрив між тим, що про продажі кажуть ваші книги, і тим, що кажуть дані про фізичні запаси. Вона виникає з трьох надійних джерел:
Необлікована нестача (shrinkage) на складі 3PL або FBA. Товари неправильно підраховуються, пошкоджуються під час комплектування або губляться під час переміщення між центрами виконання (FC). Якщо ваша система управління запасами показує 1000 одиниць у наявності, а циклічна інвентаризація складу виявляє 940, у вас є 60 одиниць «фантомних» запасів, які роздувають ваш баланс і занижують COGS. Поки ви не зафіксуєте списання, кожен звіт, який ви створюєте, буде неправильним.
Необроблені повернення. Покупець повертає товар, маркетплейс повертає гроші клієнту, але товар або ніколи не повертається на ваш склад, або приходить у непридатному для продажу стані. Якщо ви реєструєте лише скасування доходу без реєстрації додавання запасів або списання, рівень COGS для цієї одиниці зникає назавжди.
Відхилення рівнів вартості (cost layer drift). Якщо ви змінюєте постачальників, спосіб доставки або стикаєтеся зі зміною митних тарифів, ваша реальна повна собівартість (landed cost) може суттєво змінюватися між замовленнями (PO). Якщо ваш облік все ще оцінює наявні запаси за тогорічною вартістю, поки ви продаєте за цьогорічною ціною, ваші маржі виглядатимуть чудово протягом двох кварталів, а потім обваляться, коли реальність наздожене вас.
Рішення полягає у проведенні фізичної інвентаризації наприкінці року та порівнянні її результатів із книжковим обліком запасів з подальшим внесенням однієї журнальної проводки для узгодження розбіжностей. Якщо коригування становить понад 10% вартості запасів, причина є системною, а не разовою подією, і виправленням має стати робота над процесами в каталозі витрат і робочих процесах 3PL, а не ще більше коригування наступного року.
Податкові наслідки помилки в цьому питанні не є малими. Завищені кінцеві запаси занижують COGS, що роздуває оподатковуваний дохід. При заниженні на 50 000 доларів переплата федерального податку для прибуткового продавця у 22-відсотковій ставці плюс податок на самозайнятість може становити від 10 000 до 18 000 доларів. Це реальні гроші, які лежать у кишені податкової (IRS) лише тому, що склад ніколи не надсилав вам результати інвентаризації.
Зразок щомісячної процедури закриття періоду
Чітке закриття періоду для багатоканального продавця з оборотом від 500 тис. до 5 млн доларів на рік поміщається на одній сторінці:
- Імпортуйте кожен розрахунок маркетплейсу та проведіть багаторядкову журнальну проводку. Узгодьте кожен валовий депозит із банком.
- Імпортуйте інвойси 3PL та проведіть комісії за виконання замовлень за кожним каналом.
- Сформуйте звіт FBA Inventory Ledger і узгодьте зарезервовані, придатні для продажу та непридатні залишки з вашими книгами. Відкрийте претензії на відшкодування для будь-яких тривалих нестач.
- Сформуйте звіт 3PL про циклічну інвентаризацію або залишки на кінець місяця та узгодьте їх із вашою системою обліку запасів.
- Розрахуйте COGS за період, використовуючи середньозважену вартість або рівні FIFO. Підтвердьте валову маржу за каналами відповідно до ваших очікуваних показників і розслідуйте будь-які відхилення за межами норми.
- Проведіть оновлення повної собівартості (landed cost) для всіх замовлень (PO), отриманих у цей період.
- Перемістіть вивільнені резерви Amazon з рахунку Reserves на рахунок Cash.
Ця рутина займає зосереджену половину дня, якщо ваші системи поєднані між собою, і кілька болючих днів, якщо ні. Результат проявиться вже тоді, коли ви вперше зможете відповісти на запитання «яка моя реальна маржа на цей артикул (SKU) на Walmart порівняно з Amazon та Shopify?», не дивлячись розгублено в порожнечу.
Текстовий облік робить мультиканальність зрозумілою
Чим глибше ви занурюєтеся в мультиканальну електронну комерцію, тим більше вам потрібна система обліку, до якої можна створювати запити, писати скрипти, проводити аудит і застосовувати контроль версій як до коду. Комісії за продаж, зіставлення маркетплейсів, методологія повної собівартості та політика списання — це ті рішення, які ви переглядатимете щороку. Вони заслуговують на те, щоб зберігатися в чомусь кращому, ніж крихкий план рахунків у реєстрі із закритим кодом.
Ведіть чесний складський облік з першої ж одиниці товару
Продавці, які виживають під час масштабування мультиканальності, — це ті, чий облік відображає фізичну, фінансову та операційну реальність бізнесу, а не лише банківські надходження. Beancount.io пропонує текстовий облік з контролем версій, який робить P&L за каналами, повну собівартість та стан запасів прозорими та доступними для перевірки. Жодних звітів-«чорних скриньок», жодної залежності від постачальника та жодних несподіваних звірок наприкінці року. Почніть безкоштовно і дізнайтеся, чому розробники та фінансово грамотні оператори переходять на текстовий облік для свого комерційного стеку.