Пересічний продавець на Amazon втрачає від 1 500 до 3 000 доларів щороку через незатребувані відшкодування та помилки в узгодженні. Багатоканальні продавці, які одночасно працюють на Amazon, Shopify, Walmart та eBay, можуть спостерігати, як неузгоджені депозити в дорозі зростають понад 500 000 доларів, якщо ніхто не стежить за звітами про розрахунки. Проте більшість засновників e-commerce ставляться до обліку запасів як до другорядної справи — поки щорічний аудит не виявить, що баланс відхилився від фізичної реальності на десятки тисяч доларів.
Проблема не у відсутності досвіду. Сучасні оператори електронної комерції керують кількома складами, сторонніми логістичними провайдерами (3PL), центрами виконання Amazon (FBA), запасами в дорозі та комісіями маркетплейсів, які вираховуються ще до того, як долар потрапить на операційний рахунок. Кожна з цих точок дотику — це можливість для розбіжності бухгалтерських записів із дійсністю. Цей посібник розповідає про те, як тримати їх узгодженими: як розрахувати справжню повну собівартість (landed cost), як відстежувати запаси в розподілених локаціях, як узгоджувати розрахунки з маркетплейсами рядок за рядком і як запобігти коригуванням фіктивної собівартості реалізованих товарів (COGS), які бухгалтери виявляють у купі справ під час закриття року в січні.
Чому облік запасів в e-commerce принципово відрізняється
Традиційний облік товарних запасів у роздрібній торгівлі передбачає просту модель: ви купуєте товари, зберігаєте їх на одному складі, продаєте через один канал і визнаєте собівартість реалізованих товарів, коли клієнт платить. Майже нічого з цієї моделі не витримує зіткнення з сучасним брендом direct-to-consumer (DTC).
Типовий середній e-commerce бізнес може мати 2 000 одиниць на своєму основному складі, 1 500 одиниць у кількох регіональних центрах виконання FBA, 1 000 одиниць у 3PL, що обслуговує замовлення Shopify, і ще 500 одиниць у дорозі на океанському судні від постачальника з В'єтнаму. Кожна з цих одиниць має різне фізичне місце розташування, різну базу витрат (залежно від того, з якою поставкою вона прибула) і різну ймовірність бути пошкодженою, втраченою або застаріти до моменту продажу.
Поверх фізичної складності накладається фінансова складність. Amazon стягує реферальні комісії, комісії за виконання FBA, плату за зберігання, надбавки за тривале зберігання та комісії за утилізацію з валових продажів ще до того, як продавець побачить депозит. Замовлення Shopify, що проходять через MCF (Multi-Channel Fulfillment), мають зовсім іншу структуру комісій. Кожен маркетплейс розраховується за власним графіком — Amazon зазвичай кожні 14 днів, Shopify щодня, Walmart двічі на місяць — і кожен звіт про розрахунки містить сотні або тисячі рядків, які потрібно зіставити з операційним банківським рахунком і рознести за правильними рахунками головної книги.
У результаті прості бухгалтерські методи, які працюють для малого ритейлера — запис чистих депозитів як доходу, трактування доставки як витрат, об'єднання комісій FBA у "комісії та послуги" — непомітно руйнують точність фінансової звітності. На той час, коли засновник запитує "чому наша валова маржа постійно падає?", відповідь уже похована під річними нашаруваннями неправильних класифікацій.
Повна собівартість (Landed Cost): правильне визначення витрат з самого початку
Перше і найважливіше рішення, яке приймає оператор електронної комерції щодо обліку запасів, — це те, що вважати "собівартістю" товару. Загальноприйняті принципи бухгалтерського обліку (GAAP) вимагають, щоб запаси обліковувалися за повною вартістю їх доставки до місця продажу, що включає:
- Ціна постачальника в інвойсі (найбільш очевидний компонент)
- Міжнародний фрахт (морський, повітряний або автомобільний від місця походження)
- Митні збори та тарифи (часто 5–25% залежно від країни та коду HTS)
- Послуги імпортного брокера та комісії за оформлення
- Страхування під час транзиту
- Внутрішній фрахт від порту до складу
- Витрати на обробку, палетування та підготовку
- Комісії 3PL за приймання вхідних товарів
Цей пакет називається повною собівартістю (landed cost), і для багатьох імпортних товарів він становить на 15–30% більше, ніж лише ціна в інвойсі постачальника. Засновник, який вважає COGS лише ціну постачальника, буде систематично завищувати валову маржу, недооцінювати рішення про поповнення запасів і зрештою зіткнеться з болісною дооцінкою запасів наприкінці року, коли аудитор перекласифікує витрати на фрахт.
Розподіл спільних витрат між SKU
Важко не визнати важливість фрахту — важко вирішити, як розділити один рахунок за фрахт між декількома SKU в одній поставці. Існує чотири загальних методи розподілу:
- За кількістю одиниць. Розділіть загальний фрахт порівну на кількість одиниць. Просто, але неправильно, коли одиниці сильно відрізняються за розміром або вартістю.
- За вагою. Розподіл на основі фізичної ваги кожного SKU. Найкраще підходить для морських перевезень, де ціноутворення зазвичай корелює з вагою або об'ємом.
- За об'ємом (кубічні метри). Краще, ніж за вагою, для громіздких, легких товарів, які займають непропорційно багато місця в контейнері.
- За вартістю. Розподіл на основі вартості інвойсу кожного SKU у відсотках від загальної суми. Концептуально чисто і відповідає тому, як зазвичай розраховуються митні збори.
Практичний компроміс, який працює для більшості імпортерів, — це розподіл на основі вартості для митних зборів (оскільки мита самі по собі є відсотком від вартості) та розподіл на основі об'єму для фрахту (оскільки перевізники беруть плату за місце). Виберіть один метод для кожної категорії витрат, задокументуйте його та послідовно застосовуйте — аудиторів більше цікавить послідовність, ніж те, який саме метод ви обрали.
Облік повної собівартості (Landed Cost) у книгах
Шаблон журнального запису для повної собівартості є простим, але в ньому легко помилитися. Припустимо, ви отримуєте партію товару вартістю $50,000 згідно з інвойсом постачальника, $8,000 за фрахт, $3,500 мита та $1,000 комісії митного брокера. Правильна проводка:
Дт Запаси $62,500
Кт Кредиторська заборгованість $50,000 (постачальник)
Кт Нарахований фрахт $8,000 (перевізник)
Кт Нараховані мита $3,500 (митниця)
Кт Нараховані брокерські послуги $1,000 (брокер)Поширена помилка — дебетувати «Витрати на фрахт» замість «Запасів» на суму $8,000. Це миттєво визнає витрати, які мали бути капіталізовані в запаси та списані через собівартість реалізованих товарів (COGS) у міру продажу одиниць. Протягом кварталу така помилка може занизити вартість запасів на шестизначну суму.
Відстеження запасів у різних локаціях: Реальність мультиканальних складів
Після того, як повна собівартість одиниці зафіксована, наступною проблемою стає відстеження фізичного місцеперебування цих одиниць. Для мультиканального продавця SKU може одночасно перебувати у:
- Власному складі або офісі компанії
- Вітчизняному 3PL, що обслуговує канал Shopify для прямих продажів споживачам
- Кількох центрах фулфілменту Amazon FBA (іноді понад 30)
- Складах Walmart Fulfillment Services (WFS)
- Товарах у дорозі від постачальника
- «Зарезервованих» запасах: одиницях, закріплених за замовленнями, але ще не відправлених
Кожна локація потребує власного субрахунку, щоб баланс можна було звірити з фізичними залишками. Розгляд «запасів» як одного кошика — найпоширеніша причина розбіжностей при аудиті, оскільки помилки в одній локації компенсують помилки в іншій, і їх стає неможливо розслідувати після факту.
Пастка зарезервованих запасів FBA
Панель керування запасами Amazon розрізняє «Fulfillable» (одиниці на складі, готові до відправлення), «Reserved» (виділені під замовлення клієнта, у процесі переміщення між центрами фулфілменту або на тимчасовій обробці), «Inbound» (у дорозі до FBA від продавця), «Researching» (Amazon розслідує розбіжність) та «Unfulfillable» (пошкоджені, дефектні або заблоковані).
Для цілей бухгалтерського обліку все це залишається вашими запасами — вони відображаються у вашому балансі за їхньою повною собівартістю — але вони мають різні профілі ризику. Одиниці в статусі «Researching» часто перетворюються на списання або відшкодування; «Unfulfillable» — майже завжди. Продавці, які об’єднують усе в один рахунок «Запаси FBA», пропускають сигнал про те, що кілька тисяч доларів запасів тихо «зависли» на шістдесят днів і наближаються до крайнього терміну подання заявки на відшкодування.
Більш чіткий підхід до плану рахунків передбачає поділ запасів FBA як мінімум на три субрахунки:
- Запаси — FBA Доступні
- Запаси — FBA В дорозі/Зарезервовані
- Запаси — FBA Непридатні/На перевірці
Це робить аналіз термінів зберігання тривіальним і перетворює претензії на відшкодування на рутинний щомісячний процес, а не на панічну метушню наприкінці року.
Вхідні запаси та товари в дорозі
Запаси, які були оплачені, але ще не отримані, мають десь відображатися в балансі. Найкращий підхід — це спеціальний рахунок «Товари в дорозі», який дебетується, коли постачальник відправляє товар, і кредитується (з відповідним дебетом у «Запаси — Склад»), коли товар прибуває. Відокремлення товарів у дорозі запобігає двом типовим помилкам: визнанню товарів, якими ви ще не володієте, як доступних залишків, і забуванню про товари, які перетинають Тихий океан вісім тижнів.
Розрахунки з маркетплейсами: де ховаються гроші
Поширена віра засновників полягає в тому, що дохід дорівнює сумі банківських депозитів від Amazon. Це не так. Депозит Amazon — це чиста сума валових продажів мінус комісії за продаж (referral fees), збори за фулфілмент FBA, збори за зберігання FBA, транспортні збори за доставку на склад FBA, повернення, відшкодування, чарджбеки, витрати на рекламу (якщо ви підключені до системи утримання коштів Amazon), промо-знижки та ще пів десятка інших категорій. Запис лише чистого депозиту як доходу робить звіт про прибутки та збитки марним.
Як насправді виглядає звірка розрахунків
Належна звірка розрахунків з маркетплейсом складається з трьох кроків:
- Розкладіть звіт про розрахунки. Звіт про розрахунки Amazon можна завантажити з Seller Central у форматі CSV або XML. Він містить кожну транзакцію за період розрахунку, кожна з яких позначена типом (Замовлення, Повернення коштів, Збір за запаси FBA, Сервісний збір, Коригування тощо).
- Зіставте кожен тип транзакції з рахунком головної книги. Замовлення спрямовуються до валового доходу; реферальні комісії — до «Витрат на комісію маркетплейсу»; збори за фулфілмент FBA — до «Витрат на фулфілмент»; збори за зберігання — до «Витрат на зберігання»; повернення відображаються як контр-дохід; повернені комісії — як контр-витрати.
- Зіставте чистий підсумок із банківським депозитом. Сума всіх компонентів у звіті про розрахунки має дорівнювати грошовому депозиту, зарахованому на операційний рахунок (з точністю до кількох центів округлення). Якщо це не так, значить, є пропущений тип транзакції або неправильно класифікований збір.
Принцип, завдяки якому це працює, — не включати збори у валову маржу. Реферальні комісії, збори за фулфілмент і збори за зберігання — це змінні витрати, які йдуть після валової маржі у структурі маржинального прибутку (contribution-margin waterfall). Якщо ставити їх вище валової маржі, то валова маржа Amazon виглядає гіршою за Shopify, навіть якщо юніт-економіка ідентична, і це руйнує порівнянність, яка необхідна засновникам для прийняття рішень щодо вибору каналів продажу.
Антипатерн «Списання різниці»
Коли бухгалтер не може звести звіт про виплати (settlement) до копійки, спокусливим швидким рішенням стає занесення різниці на загальний рахунок «Коригування маркетплейсу». У чотирьох каналах продажів протягом дванадцяти місяців ці невеликі списання зазвичай накопичуються у п’ятизначні дефіцити. Дисципліна, яка запобігає цьому, — це жорстке правило: кожен розрахунок має бути узгоджений із депозитом із точністю до $5, а будь-яка більша розбіжність має бути розслідувана та задокументована до закриття книг за місяць. Заявки на відшкодування втраченого або пошкодженого інвентарю FBA зазвичай мають 60-денне вікно для подання, тому непояснена розбіжність часто є втраченою можливістю отримати відшкодування.
Фантомна COGS наприкінці року: проблема від’ємних залишків
Найпідступніша проблема з інвентарем наприкінці року виникає через те, що користувачі NetSuite називають «фантомною COGS». Це трапляється, коли облікова система фіксує продаж (і відповідний запис COGS — собівартості реалізованих товарів) у момент, коли наявний інвентар у системі дорівнює або менше нуля. Система не може опублікувати реальну суму COGS, тому вона створює тимчасовий запис — іноді нульовий, іноді застарілу вартість з попереднього періоду. Через тижні або місяці коригування запасів нарешті робить наявну кількість додатною, і система «вирівнює» дані, публікуючи наздоганяючий запис COGS, часто з вартістю, яка не має жодного відношення до початкового продажу.
Ці фантомні коригування мовчки накопичуються протягом року. До грудня рядок COGS у звіті про прибутки та збитки за рік може відхилятися на десятки тисяч доларів у будь-який бік, тенденції валового прибутку виглядають хаотично, а баланс інвентарю в балансовому звіті непомітно віддалився від фактичної фізичної кількості.
Запобігання від’ємним залишкам на початковому етапі
Структурне рішення полягає в тому, щоб не допускати від’ємних залишків інвентарю в системі. Це означає:
- Своєчасне узгодження вхідних поставок. Коли FBA отримує поставку, панель продавця показує отримані одиниці, але поки оператор не зафіксує отримання у своїй обліковій системі, система вважає, що ці одиниці все ще перебувають у дорозі.
- Фіксація виконання замовлень маркетплейсів у режимі реального часу. Щоденна синхронізація Amazon з обліковою системою (за допомогою таких інструментів, як A2X, Webgility, Link My Books або Entriwise) запобігає багатотижневій затримці, через яку продажі випереджають наявну кількість.
- Обережне поводження зі змішаним інвентарем (commingled inventory). Програма змішаного інвентарю Amazon (де ваші SKU об’єднуються з ідентичними SKU інших продавців) створює проблеми з часом фіксації, які виглядають як від’ємний інвентар, навіть якщо з фізичної точки зору все гаразд. Найчистішим рішенням є відмова від змішування для будь-якого SKU, де важливий контроль якості.
Річна інвентаризація та вирівнювання
Навіть за ідеальної щоденної гігієни обліку, єдиний спосіб підтвердити, що книги відповідають фізичній реальності, — це річна інвентаризація запасів. Перевірки мають проходити в кожному місці зберігання:
- Фізичний підрахунок на складі компанії
- Завантаження звіту про інвентар з Amazon Seller Central (звіт Inventory Ledger)
- Завантаження звіту про інвентар з порталу 3PL-провайдера
- Підтвердження кількості товарів у дорозі від постачальника та експедитора
Загальна сума має збігатися з рядком інвентарю в балансі. Якщо вони не збігаються, різниця розслідується; те, що неможливо пояснити, списується як нестача журнальним записом на «Витрати на нестачу інвентарю». Нестача понад 2% від вартості інвентарю зазвичай свідчить про системну проблему (крадіжка, помилки підрахунку у 3PL або постійні прогалини у відшкодуваннях FBA), а не про разову розбіжність.
Методи оцінки запасів: FIFO, середньозважена вартість, і чому більшості продавців e-commerce варто обрати середньозважену вартість
GAAP дозволяє три основні методи оцінки собівартості запасів: First-In-First-Out (FIFO), Last-In-First-Out (LIFO) та середньозважена вартість. LIFO рідко використовується за межами США і несумісний з Міжнародними стандартами фінансової звітності (МСФЗ), тому практичний вибір стоїть між FIFO та середньозваженою вартістю.
FIFO зіставляє вартість найстарішого інвентарю з наступною проданою одиницею. Цей метод забезпечує найточнішу валову маржу в періоди стабільних витрат, але вимагає від системи відстеження вартості кожної партії окремо та присвоєння продажів спочатку найстарішій партії.
Середньозважена вартість перераховує змішану вартість одиниці щоразу, коли надходить нова поставка. Цей метод математично простіший, добре працює зі змішаним інвентарем FBA (де фізичні партії все одно неможливо розрізнити) і є стандартним у більшості сучасних інструментів для обліку в e-commerce.
Для більшості брендів, що працюють за моделлю direct-to-consumer і продають споживчі товари в помірних обсягах, середньозважена вартість є правильним вибором. Вона достатньо точна для фінансової звітності, легко автоматизується і стійка до часових розбіжностей між вхідними та вихідними потоками, які притаманні мультиканальним операціям. FIFO вартий додаткової складності лише тоді, коли вартість продукту дуже волатильна (літій, напівпровідники, певні сільськогосподарські товари) або коли оператору необхідно відстежувати дані про партії чи терміни придатності з міркувань комплаєнсу.
Прибутковість каналів: фінальна винагорода за правильний підхід
Причина, чому вся ця дисципліна має значення, полягає в тому, що e-commerce бізнес не може приймати правильні рішення про зростання без точних звітів P&L (прибутків та збитків) за каналами. Чи варто направляти більше інвентарю на FBA чи на ваш 3PL? Чи ваш канал Shopify насправді прибутковіший за Amazon, чи Shopify просто виглядає краще, тому що в книгах комісії FBA приховані на неправильному рахунку? Оптова торгівля субсидує direct-to-consumer чи навпаки?
Відповідь на ці запитання вимагає плану рахунків, який розділяє дохід, повернення, COGS, витрати на виконання замовлень, комісії маркетплейсів та витрати на рекламу по кожному каналу. Більшість сучасних облікових платформ підтримують це за допомогою комбінації класів, локацій, департаментів або тегів — конкретний механізм залежить від інструменту, але принцип однаковий: кожна транзакція має бути позначена тегом каналу, з якого вона походить, а звіт про прибутки та збитки повинен мати можливість фільтрації за каналами.
Результат є значним. Керівники, які підтримують чисті P&L на рівні каналів, регулярно виявляють, що їхній «найкращий» канал насправді є найгіршим за показником маржинального доходу, або що невеликий, непомітний канал приносить надмірний грошовий потік на кожен долар оборотного капіталу. Ці інсайти з'являються лише тоді, коли базові дані чисті — тобто, коли повна собівартість (landed cost) розподілена правильно, розрахунки узгоджені, а фантомна COGS не псує загальну картину.
Ведіть бездоганний облік запасів з першого дня
Точний облік запасів — це різниця між розумінням власного бізнесу та здогадками про нього. Оскільки ваша діяльність розширюється на різні склади, фулфілмент-центри та маркетплейси, єдиним стабільним способом узгодження бухгалтерських книг із фізичною реальністю є прозора, аудитована система з контролем версій. Beancount.io забезпечує текстовий облік (plain-text accounting), розроблений саме для цього: кожна транзакція — це зрозумілий запис із можливістю порівняння змін (diff), кожна ієрархія рахунків чітко відповідає структурі відстеження запасів у багатьох локаціях, а ваші історичні дані належать вам назавжди без прив’язки до конкретного постачальника. Почніть безкоштовно і дізнайтеся, чому фінансові команди, які керують складними багатоканальними операціями, переходять на текстовий облік.