Якщо ви продаєте через магазини Facebook або Instagram, а ваш облік досі виходить із того, що Meta приймає платежі, обробляє повернення й видає акуратний звіт про розрахунки, ви звіряєтеся із системою, якої більше не існує. Meta закрила вбудовану оплату всередині застосунків Facebook та Instagram Shops, і тепер кожне замовлення переходить на власний сайт продавця для завершення покупки. Для малого бізнесу, який побудував свій облік навколо старої універсальної комерційної екосистеми Meta, це не косметична зміна інтерфейсу — це переписування того, де саме фіксуються продажі, комісії, податки й повернення.
Самі платформи все ще виконують чимало роботи: теги товарів, Reels із можливістю покупки, вкладка «Магазин», а реклама в Instagram та Facebook і далі стимулює перегляд і натискання кнопки «купити». Чого Meta більше не робить — це не приймає гроші, не керує замовленням, не обробляє повернення й не оскаржує чарджбек від вашого імені. Уся ця друга половина транзакції — та, яка насправді цікавить ваш облік, — тепер існує там, де живе оформлення замовлення на вашому сайті: Shopify, WooCommerce, BigCommerce, Squarespace або власний кошик.
Що насправді змінилося
Поступове згортання функцій Meta прибрало конкретний набір можливостей, які раніше жили всередині Commerce Manager:
- Вбудована оплата та обробка платежів на платформі. Покупці більше не завершують покупку, не покидаючи Facebook чи Instagram — кожна кнопка «Купити зараз» тепер веде на сайт продавця.
- Керування замовленнями. Відстеження статусу, масові дії із замовленнями та редагування окремих замовлень зникли з Commerce Manager; панель замовлень вашої платформи електронної комерції тепер є єдиним джерелом істини.
- Обробка повернень і суперечок. Запити на повернення й оскарження чарджбеків більше не проходять через Meta — вони йдуть через той платіжний процесор і процес повернення, який використовує ваш сайт.
- Внутрішні повідомлення покупцям, пов'язані з транзакціями. Повідомлення про конкретне замовлення у вхідних більше не пов'язані з активним процесом оформлення замовлення.
Це розворот власної вимоги Meta від 2023 року, яка свого часу підштовхувала продавців до вбудованої оплати. Найправдоподібніше пояснення — вартість і відповідальність: обробка платежів, розрахунок податку з продажів у кожній юрисдикції США та вирішення спорів у масштабі — дороге і юридично вразливе заняття, яке Meta, вочевидь, вирішила не тримати на собі. Є й правдоподібний антимонопольний аспект — регулятори як у США, так і в Європі уважно стежили за прямим контролем Meta над комерційними транзакціями, а відхід від оформлення замовлення зменшує цю площину уваги.
Для продавців, які пройшли цей перехід, практичний результат уже усталений: Instagram і Facebook — це канали відкриття та реклами на верхівці воронки, а не платіжні процесори. Кожен долар, який раніше розраховувався через Meta Pay, тепер проходить через той шлюз, що стоїть за оформленням замовлення на вашому сайті.
Ставки в цьому питанні лише зростають. Продажі через соціальну комерцію в США вперше, за прогнозами, перевищать $100 мільярдів у 2026 році, і малий бізнес формує помітну частку цього зростання — сам лише Instagram Shopping охоплює приблизно 70% активних користувачів платформи, а публікації з можливістю покупки генерують удвічі більше показів, ніж звичайні публікації про товар. Більший трафік через канал, чия платіжна інфраструктура змінилася в продавців буквально під ногами, означає, що більше малих компаній виявлятимуть прогалини у звірці через кілька місяців після факту — часто лише тоді, коли декларація з податку з продажів чи річне закриття обліку не сходяться.
Яку бухгалтерську проблему це створює
Якщо у вашому плані рахунків чи звичках звірки й досі є рядок — умовний чи буквальний — для «виплат від Meta», у вас є три конкретні проблеми, які треба виправити.
1. Дохід тепер надходить через ваш загальний платіжний процесор, а не через звіт про розрахунки Meta
Раніше єдиний звіт про виплату з Meta Commerce Manager показував, що продалося, яка комісія Meta й що надійшло на ваш банківський рахунок. Тепер цей дохід нічим не відрізняється на рівні платіжного процесора від будь-якого іншого продажу на сайті — він потрапляє у пакет розрахунків Stripe, Shopify Payments чи PayPal упереміш із прямим трафіком, трафіком з розсилок і всіма іншими каналами.
Це добра новина для простоти (одна система розрахунків замість двох), але погана — для видимості. Якщо ви хочете знати, скільки доходу насправді принесли Instagram і Facebook, більше не можна просто прочитати це зі звіту про виплату — вам потрібні UTM-параметри, налаштоване в Commerce Manager місце конверсії «Сайт» на боці платформи або атрибуція джерел трафіку у вашій платформі електронної комерції, щоб відновити ці дані. Не дивуйтеся, якщо цифри не збігаються ідеально: задокументовано розбіжність у 20–40% між конверсіями, які показує Meta Ads Manager, і тим, що фактично фіксує аналітика вашого сайту, — це поширене явище, спричинене обмеженнями відстеження в iOS і різницею в моделях мультиканальної атрибуції. Для обліку й податкових цілей це не має значення — продаж є продажем незалежно від каналу, — але якщо ви оцінюєте окупність рекламних витрат, не сприймайте жодне з цих чисел як абсолютну істину: вважайте дані про замовлення з вашого сайту обліковим джерелом істини, а цифри Meta — орієнтовним сигналом.
2. Відповідальність за податок з продажів перейшла від «можливо, Meta» до «точно ви»
Це зміна з реальними наслідками для комплаєнсу. Згідно із законами про фасилітаторів маркетплейсів, платформи, які контролюють оформлення замовлення — Amazon, Etsy, TikTok Shop, — зазвичай зобов'язані розраховувати, стягувати й перераховувати податок з продажів від імені продавця. Коли Meta керувала вбудованою оплатою, вона умовно потрапляла в ту саму категорію принаймні для частини транзакцій. Тепер, коли оформлення замовлення відбувається на вашому власному сайті, саме ви є однозначно роздрібним продавцем за документами, і збір та перерахування податку з продажів — це повністю ваша відповідальність, з урахуванням власних зобов'язань щодо податкового зв'язку («nexus») у кожному штаті, де у вас є покупці.
Якщо раніше ви продавали через суміш справжніх маркетплейсів (які перераховують податок за вас) і магазинів Meta (де це могло бути так чи ні), вам, імовірно, потрібно:
- Переконатися, що ваша платформа електронної комерції (Shopify, WooCommerce тощо) налаштована правильно розраховувати й стягувати податок з продажів у кожному штаті, де у вас є податковий зв'язок.
- Відокремити продажі, «оформлені через маркетплейс», від продажів, «зібраних самостійно», у своїх записах — більшість штатів вимагають звітувати про валові продажі, а потім вираховувати суми, оформлені через маркетплейс, тож змішування продажу через сайт, ініційованого Meta, із продажами через маркетплейс Amazon спотворить вашу оподатковувану базу.
- Звіряти рахунок зобов'язань з податку з продажів щомісяця з фактичними деклараціями, а не з припущеннями, перенесеними зі старого процесу оформлення замовлення.
3. Комісії змінилися — відстежуйте нові
Вбудована оплата Meta мала власні комісії за транзакції, які вираховувалися перед виплатою. Тепер, коли оформлення замовлення проходить через ваш сайт, ці комісії замінені на те, що стягує ваш платіжний процесор і платформа електронної комерції: комісії за обробку від Stripe/Shopify Payments, плюс будь-яка платформна комісія Shopify чи WooCommerce, плюс комісії платіжного шлюзу, якщо ви не на універсальній платформі. Витрати на рекламу не змінилися — ви й далі платите Meta за розміщення реклами, — але рядок комісії за транзакцію у вашому звіті про прибутки й збитки має перейти з рахунку «комісії Meta» на рахунок комісій вашого процесора. Якщо не перепозначити це, категоризація витрат почне «пливти» й спотворить аналіз маржинальності продажів, які приходять із соціальних мереж.
Практичний приклад: де раніше сходилися цифри
Уявіть невеликого продавця товарів для дому, який раніше отримував одну щотижневу виплату з Commerce Manager: $4,200 продажів через Facebook/Instagram, мінус комісія Meta за транзакцію, зарахована єдиною сумою з доданим детальним списком замовлень. Облік був майже механічним — одне зарахування, один запис у журналі, один рядок комісії.
Сьогодні ці самі $4,200 доходу, отриманого із соціальних мереж, надходять як частина набагато більшого щотижневого зарахування Shopify Payments, яке також включає продажі з прямого трафіку, продажі з поштових розсилок і продажі з Google Ads — усе об'єднане в один пакет розрахунків із усередненою комісією за обробку. Продавцю доводиться заходити в список замовлень Shopify, фільтрувати за каналом переходу (або за джерелом UTM, якщо рекламні посилання позначені), і вручну відновлювати, яка частина цього зарахування прийшла з Instagram, а яка — звідусіль ще. Загальний дохід не змінився, але його розкладання по каналах тепер вимагає свідомого кроку, який раніше відбувався автоматично. Пропустіть цей крок протягом кварталу — і ви все одно правильно закриєте книги загалом, але не матимете надійної відповіді на питання «чи виправдовує Instagram витрати на рекламу?» — а це, для продавця, який платить за розміщення на платформі, і є весь сенс окремого відстеження каналу.
Вибір (або аудит) налаштувань оформлення замовлення на вашому сайті
Якщо ви ще завершуєте цей перехід або вперше налаштовуєте соціальну комерцію за новою моделлю, платформа оформлення замовлення, на яку ви спрямовуєте трафік із Meta, має значення більше, ніж раніше, оскільки тепер саме вона несе всю вагу обробки платежів, розрахунку податків і обліку замовлень:
- Універсальні платформи (Shopify, BigCommerce, Squarespace Commerce) об'єднують розрахунок податку з продажів, обробку платежів та облік запасів в одній системі, що мінімізує прогалини у звірці — компроміс полягає в платформних комісіях поверх комісій платіжного процесора.
- Самостійно розміщені рішення (WooCommerce, власні кошики) дають більше контролю і зазвичай нижчі платформні комісії, але за підключення сервісу розрахунку податків (Avalara, TaxJar чи подібного) відповідаєте ви самі — автоматично цього ніхто не робить.
- У будь-якому разі підключіть місце конверсії «Сайт» у Meta Commerce Manager (єдиний підтримуваний варіант тепер, коли гібридне налаштування «Сайт і магазин» більше не діє), щоб звітність про рекламу та відстеження конверсій на основі пікселя вказували на реальне оформлення замовлення, а не на застарілий процес усередині застосунку.
Незалежно від того, яку платформу ви використовуєте, бухгалтерське питання одне й те саме: чи кожне замовлення, повернення та комісія з цієї платформи потрапляють у ваш облік як окрема, позначена транзакція — а не просто як одне сумарне зарахування? Якщо відповідь «ні», виправте це до того, як зросте обсяг ваших транзакцій, адже розплутувати рік змішаних зарахувань заднім числом набагато болючіше, ніж правильно позначати канали з першого дня.
Практичний чекліст звірки
Для малого бізнесу, який ще прибирає цей безлад, або перевіряє, чи все зроблено правильно під час переходу:
- Переконайтеся, що ваш план рахунків відображає реальність. Якщо у вас усе ще є проміжний рахунок «Meta Commerce» чи «Facebook Payments», або перепризначте його виключно для рекламних витрат, або закрийте — дохід і комісії тепер проходять через рахунок вашого основного платіжного процесора.
- Звіряйте зарахування за розрахунками, а не звіти по каналах. Спершу зіставляйте банківські зарахування зі звітом про виплати вашого платіжного процесора; атрибуцію рекламної платформи використовуйте лише як другорядну перевірку ефективності каналу, ніколи як джерело обліку.
- Перевірте налаштування податку з продажів для штатів із податковим зв'язком. Переконайтеся, що оформлення замовлення на вашому сайті справді розраховує й перераховує податок усюди, де у вас є зобов'язання — не припускайте, що старе налаштування епохи Meta все ще діє.
- За потреби перепозначте історичні транзакції. Якщо рахунки чи записи в журналі з перехідного періоду 2025 року були закодовані під категорію «виплата від Meta», якої більше не існує, перекласифікуйте їх, щоб звітність по каналах рік до року залишалася порівнянною.
- Слідкуйте за синхронізацією запасів. Якщо раніше магазини Meta напряму зменшували кількість товару на складі, переконайтеся, що тепер саме платформа вашого сайту (а не Meta) є єдиним джерелом істини щодо рівня запасів, який живить розрахунок собівартості проданих товарів — застаріла синхронізація тут непомітно занижує або завищує собівартість.
Звіряйте продажі з усіх каналів із самого початку
Соціальна комерція лише зростає — і стає складнішою для відстеження — оскільки продавці одночасно працюють з Instagram, TikTok Shop, прямим трафіком сайту й традиційними маркетплейсами, кожен із яких має власний графік виплат, структуру комісій і податковий режим. Beancount.io дає вам простий текстовий облік, який є прозорим і контролюється версіями, тож транзакції з кожного каналу потрапляють в один аудитований журнал замість розрізнених звітів платформ. Почніть безкоштовно і подивіться, чому розробники та власники бізнесу, які орієнтуються на фінанси, переходять на простий текстовий облік.