Продавець print-on-demand відкриває свою форму 1099-K від Shopify Payments у лютому і бачить цифру, яка зовсім не схожа на те, що він насправді заробив. У формі вказано $50 000 валових платежів. Його банківський рахунок за рік зріс приблизно на $14 000. Нічого не зламалося — але якщо він задекларує ці $50 000 як дохід, не розуміючи, куди поділися інші $36 000, він або значно переплатить податковій службі (IRS), або запанікує, що щось було вкрадено.
Цей розрив — найпоширеніша помилка обліку, яку роблять продавці print-on-demand (POD), і вона виникає через деталь, яку майже ніхто чітко не пояснює: платформа, на якій ви продаєте, визначає, які податки ви маєте сплачувати і як вам дозволено обліковувати свої витрати. Переплутайте цю відмінність — і все, що йде далі: ваша собівартість товарів (COGS), ваші декларації з податку з продажу, ваш Schedule C — ламається так, що це важко помітити заднім числом.
Дві бізнес-моделі, дві абсолютно різні податкові картини
Print-on-demand охоплює широкий спектр варіантів організації бізнесу, але з погляду бухгалтерського обліку насправді існує лише дві моделі, і поводяться вони абсолютно по-різному.
Модель А: ви — мерчант обліку (merchant of record). Ви керуєте власною вітриною — Shopify, WooCommerce або власним магазином на базі Etsy — і підключаєте партнера з виконання замовлень, такого як Printful або Printify, через інтеграцію. Клієнт платить безпосередньо вам. Потім ви сплачуєте компанії-фулфілменту базову собівартість виробництва за одиницю товару. Юридично продавцем є саме ви, а це означає, що на вас лежить обов'язок зі сплати податку з продажу, і ви маєте право відраховувати реальну собівартість реалізованих товарів.
Модель Б: ви — отримувач роялті. Ви завантажуєте дизайни на маркетплейс, такий як Redbubble, Merch by Amazon, TeePublic, Society6, Zazzle або Spring. Маркетплейс встановлює ціну на товар, обробляє транзакцію, виготовляє й відправляє його, а вам сплачує роялті за кожен продаж. Ви ніколи не подаєте декларацію з податку з продажу, і — саме тут продавці найчастіше помиляються — у вас немає права на відрахування собівартості товарів, оскільки ви ніколи не платили за самі товари. Уся ваша «собівартість продукту» вже закладена в комісію маркетплейсу ще до того, як ви отримаєте роялті.
Плутанина між цими двома моделями — це те, звідки починається більшість помилок обліку в POD. Продавець, який вважає, що дохід від роялті на Redbubble обліковується так само, як дохід від магазину на Shopify, або вигадає собі відрахування COGS, на яке не має права, або не зареєструється на дозволи з податку з продажу, які йому насправді потрібні.
Як насправді працює COGS для продавців за моделлю А
Якщо ви керуєте власною вітриною через Printful або Printify, плата, яку ви сплачуєте за заготовку товару, друк і пакування, є законною собівартістю реалізованих товарів — але вона має потрапити на правильне місце у ваших книгах обліку.
У формі Schedule C це означає таке:
- Базова собівартість виробництва вноситься в Частину III, рядок 36 (закупівлі).
- Витрати на доставку, які стягує партнер з виконання замовлень, зазвичай належать до Частини III, рядка 38 (інші витрати) або включаються до COGS — залежно від того, як їх класифікує ваше бухгалтерське програмне забезпечення. Головне тут — послідовність, а не конкретний рядок.
- Залишок товарних запасів на кінець періоду становить $0. Print-on-demand за визначенням працює за принципом виготовлення на замовлення. Ви ніколи не тримаєте фізичних запасів, тож наприкінці року немає етапу оцінки товарних запасів, який має проходити традиційний роздрібний продавець.
Практична помилка, на яку варто зважати: багато продавців фіксують дохід від продажу в момент, коли Shopify Payments зараховує кошти, але забувають окремо зафіксувати рахунок за виконання замовлення, який Printful або Printify виставляють через кілька днів, часто в іншій партії, а іноді й в іншому місяці. Якщо ваш облік фіксує лише сторону надходжень, ваш звіт про прибутки та збитки виглядає штучно прибутковим, доки рахунок за фулфілмент не наздожене його — а на той момент ви вже могли подати квартальні орієнтовні податкові платежі на основі завищеної цифри.
Виправлення механічне, але важливе: звіряйте кожну виплату з відповідним рахунком за виконання замовлення до закриття обліку за цей період, а не після.
Податок з продажу на кількох платформах: чому «нексус» означає різне на кожному каналі
Саме тут спотикаються продавці, які продають ті самі дизайни через кілька каналів одночасно — скажімо, магазин на Shopify і магазин на Etsy і акаунт на Redbubble.
Маркетплейси (Модель Б) є маркетплейс-фасилітаторами. Etsy, Redbubble, Amazon Merch та подібні платформи юридично зобов'язані розраховувати, стягувати і перераховувати податок з продажу від вашого імені у кожному штаті, де це вимагається. Вам не потрібно реєструватися, подавати декларації чи якось цим займатися.
Ваша власна вітрина (Модель А) автоматично не покривається. Сам Shopify не є маркетплейс-фасилітатором для замовлень, зроблених через ваш власний домен — ви самі несете цю відповідальність, у кожному штаті окремо, залежно від того, де ви перетнули пороги економічного нексусу. (Окремий канал додатку «Shop» від Shopify почав стягувати й перераховувати податок за відповідними замовленнями з 2025 року, але це стосується лише продажів, здійснених саме через цей канал, а не вашої основної вітрини.)
Це означає, що один і той самий продавець може цілком законно бути зобов'язаним зареєструватися й подавати декларації з податку з продажу в певному штаті через свій магазин на Shopify, водночас не маючи жодних зобов'язань щодо ідентичного товару, проданого через Etsy або Redbubble в тому самому штаті. Облік має відстежувати, який саме канал згенерував кожен продаж, а не лише загальний дохід — інакше ви або зареєструєтеся на дозволи, які вам не потрібні, або — що гірше — пропустите ті, які потрібні насправді.
Є ще один рівень, специфічний саме для POD: сама плата за виконання замовлення може оподатковуватися. Якщо ви не подасте сертифікат перепродажу (resale certificate) до Printful або Printify, вони стягнуть з вас податок з продажу на оптову собівартість виробництва — податок, який ви потім не зможете законно повернути, оскільки ви не є кінцевим споживачем. Подання сертифіката перепродажу (через податкові налаштування платформи, використовуючи або специфічний для штату сертифікат, або уніфіковану форму Multistate Tax Commission, яку приймають у більшості штатів) запобігає такому подвійному оподаткуванню, і зробити це варто ще до першого продажу, а не після того, як ви помітите незрозумілу суму в рахунку.
Звірка виплат із рахунками за виконання замовлень без втрати глузду
Основна операційна складність в обліку POD — це не складна математика, а розбіжності в часі між системами, які ніколи не були розроблені для чіткої взаємодії між собою:
- Клієнт платить через Shopify або Etsy. Цей платіж розраховується через Shopify Payments, Stripe або Etsy Payments за власним графіком (часто через 2–5 робочих днів, партіями разом з іншими замовленнями).
- Замовлення передається до Printful або Printify, які виставляють вам рахунок окремо — іноді за кожним замовленням, іноді партією — часто за іншим графіком, ніж виплата.
- Якщо ви продаєте через кілька каналів, кожен із них генерує свій власний звіт про виплати, свою структуру комісій і свій графік, і всі вони посилаються на того самого партнера з виконання замовлень.
Без свідомо вибудуваного процесу легко зафіксувати виплату як дохід і так і не простежити далі, чи справді відобразилась відповідна вартість виконання замовлення. Проста звичка, яка вирішує більшість цих проблем: перед закриттям кожного місяця вивантажуйте звіт про витрати на рівні замовлень від партнера з виконання замовлень і звіряйте його рядок за рядком зі звітами про виплати каналів за той самий період. Усе, що не збігається — замовлення, за яким видно платіж клієнта, але немає відповідного нарахування за виконання, або навпаки — це або тимчасова розбіжність, яка вирішиться наступного періоду, або реальна помилка, яку варто розслідувати зараз.
Це саме той тип звірки, який виграє від записів, які реально можна перевірити, а не від панелі-«чорної скриньки». Коли ваші рахунки за виконання замовлень, виплати каналів і зібраний податок з продажу зафіксовані як транзакції у форматі простого тексту з чіткими посиланнями на вихідне замовлення, пошук розбіжності займає хвилини, а не цілий день експортування CSV-файлів із трьох різних платформ.
А що з формами 1099?
Оскільки продавці за моделлю А є мерчантами обліку, Printful і Printify взагалі не видають вам форму 1099 — ваша форма 1099-K, якщо ви її отримуєте, надходить від вашого платіжного процесора (Shopify Payments, PayPal, Stripe) на основі валового обсягу транзакцій, а не чистого доходу. Саме цю цифру потрібно скоригувати описаним вище відрахуванням COGS, щоб отримати точний показник прибутку.
Маркетплейси за моделлю Б відрізняються між собою: Amazon Merch і Zazzle видають форми 1099 безпосередньо за дохід від роялті, що перевищує поріг звітності; інші, зокрема Redbubble, TeePublic і Society6, проводять виплати через PayPal або Payoneer, які натомість видають форму 1099-K, якщо поріг досягнуто. У будь-якому разі поріг звітності визначає лише те, чи має платформа надіслати вам форму — він жодним чином не впливає на те, чи оподатковується цей дохід. Кожен долар доходу від роялті чи власної вітрини підлягає декларуванню незалежно від того, чи опиниться форма 1099 у вашій поштовій скриньці.
Ще одна деталь класифікації, яку варто зазначити: хоча маркетплейси часто називають виплати за моделлю Б «роялті», податкова служба (IRS) розглядає дохід від постійної торговельної чи підприємницької діяльності як дохід від самозайнятості, що підлягає податку на самозайнятість, а не як пасивний дохід від роялті — якщо ви активно завантажуєте дизайни й ведете магазин як бізнес, а не ліцензуєте одноразовий об'єкт інтелектуальної власності.
Тримайте облік print-on-demand звіреним за задумом
Незалежно від того, керуєте ви однією вітриною на Shopify через Printful чи одночасно жонглюєте п'ятьма маркетплейсами, продавці, які уникають несподіванок наприкінці року, — це ті, хто звіряє витрати на виконання замовлень із виплатами щомісяця, а не щоквітня. Beancount.io надає облік у форматі простого тексту з версійним контролем, який дозволяє легко відстежувати COGS, зібраний податок з продажу та виплати з кількох каналів як чітко позначені, перевірювані транзакції — без прив'язки до постачальника, без чорної скриньки. Почніть безкоштовно і подивіться, чому розробники та продавці, орієнтовані на фінанси, переходять на облік у форматі простого тексту.
