Бухгалтерія для розробників розширень Chrome: узгодження виплат після того, як Google скасував платежі в додатку

Відкрийте сьогодні панель розробника Chrome Web Store — і ви помітите, що чогось бракує: вкладки «платежі». Google закрив власну систему платежів у додатку для розширень ще у 2021 році, і вона так і не повернулася. Якщо ви хочете стягувати плату за розширення Chrome у 2026 році, вам доведеться самостійно розбиратися з виставленням рахунків, підписками, поверненнями коштів, стягненням податків і — про що майже ніхто не думає заздалегідь — з узгодженням того, що фактично надійшло на ваш банківський рахунок, з тим, що ви продали.

Саме останній пункт спантеличує розробників-одинаків частіше, ніж будь-яке питання ціноутворення. Магазин одного розробника, що веде три-чотири розширення через Stripe, Paddle чи обгортку на кшталт ExtensionPay, зрештою отримує депозити виплат, які не мапляться чітко на жоден окремий продукт, сплески повернень, що виникають нізвідки після затримки модерації в Chrome Web Store, і банківський баланс, який ніколи точно не збігається з тим, що показує панель продажів. Жодна з цих речей не є помилкою у вашому бізнесі. Це передбачуваний результат того, що ви самостійно зшиваєте платіжний стек, яким раніше керував за вас Google.

Ось як побудувати бухгалтерський облік, який це витримає.

Чому Google вийшов з платіжного бізнесу​

Chrome Web Store Payments запустили на початку 2010-х років, коли для розробника-одинака існувало небагато хороших варіантів стягувати плату за браузерне розширення. До 2021 року Stripe, Braintree та хвиля сервісів «продавця-реєстратора» (merchant of record) достатньо дозріли, щоб Google вирішив, що йому більше не потрібно самостійно керувати власною системою оформлення замовлень, ліцензійних ключів і виплат. Компанія припинила підтримку Chrome Web Store Payments і змусила кожне платне розширення обирати між переходом на безкоштовну модель або переходом на стороннього процесора.

Практичний наслідок для розробників такий: кожен долар, зароблений розширенням, тепер проходить через платіжний стек, який ви зібрали самі, і кожну проблему узгодження, яку створює цей стек, вам доведеться вирішувати самостійно. Більше не існує єдиного «звіту про виплати Chrome Web Store» — є те, що надає ваш процесор, плюс те, що показує власна аналітика лістингу Chrome Web Store, плюс ваша банківська виписка, і ці три джерела рідко збігаються з першого погляду.

Платіжний процесор чи продавець-реєстратор — оберіть один варіант для кожного розширення​

Перш ніж узгодження взагалі почнеться, вам потрібно знати, на якому боці угоди ви юридично перебуваєте, оскільки це визначає, що потрапляє у ваш облік.

Платіжний процесор (безпосередньо Stripe або обгортка на його основі, як-от ExtensionPay) робить продавцем вас. Ви збираєте гроші, ви є продавцем-реєстратором для податкових цілей, і саме ви відповідаєте за визначення зобов'язань з податку з продажів і ПДВ у кожній юрисдикції, де проживає клієнт. Комісії нижчі — базова ставка Stripe становить 2,9% + $0,30 за транзакцію, а обгортка на кшталт ExtensionPay зазвичай додає власну частку зверху — але тягар відповідності лягає на вас.

Продавець-реєстратор (Paddle, Lemon Squeezy, Fungies та подібні) юридично стає продавцем замість вас. Він збирає ПДВ чи GST, подає декларації у понад 140 країнах, які нині вимагають цього для цифрових товарів, обробляє чарджбеки та виплачує вам чистий дохід. Ви віддаєте 4–8% доходу замість приблизно 3%, але ціла категорія бухгалтерської та податкової роботи зникає. Повний розбір компромісів і того, як порахувати, коли перехід окупається, читайте в нашому гайді з продавців-реєстраторів.

Для більшості розробників-одинаків з доходом нижче кількох тисяч доларів на місяць додаткові 3–5%, які бере продавець-реєстратор, — це дешева страховка від необхідності реєструватися на ПДВ у десятці країн вручну. Щойно ви почнете отримувати реальний регулярний дохід із кількох розширень, перерахуйте це порівняння знову — математика змінюється зі зростанням обсягу.

Що б ви не обрали, зафіксуйте це письмово. Ваш облік потребує чіткої відповіді на питання «хто є юридичним продавцем-реєстратором для цього розширення», оскільки це визначає, чи взагалі з'являється зобов'язання зі сплати податку з продажів у вашому балансі.

Проблема узгодження — структурна, а не помилка​

Ось що застає розробників зненацька: навіть при правильно налаштованому процесорі отримана виплата майже ніколи не дорівнює доходу, згенерованому за цей період. Три фактори руйнують точну відповідність:

• Пакетні виплати. Stripe і більшість продавців-реєстраторів виплачують кошти за плаваючим графіком (часто через 2–7 днів після оплати, іноді щотижня), тому виплата, що надходить 5-го числа місяця, містить продажі за останні кілька днів попереднього місяця. Якщо ви обліковуєте виплати як дохід у день їх надходження на банківський рахунок, ви щомісяця неправильно відносите дохід не до того періоду.
• Кілька розширень, один обліковий запис процесора. Якщо ви ведете кілька розширень через один і той самий обліковий запис Stripe чи Paddle — типова ситуація для розробників, які випускають кілька невеликих інструментів замість одного флагманського продукту — виплата являє собою єдину загальну суму, що охоплює їх усі. Без розмітки за кожним розширенням окремо (метадані Stripe або окремі товари/ціни для кожного розширення) ви не зможете визначити, яке саме розширення принесло дохід, а отже, і зрозуміти, яке з них варте вашого часу на підтримку.
• Комісії, повернення та конвертація валют вже вирахувані до того, як ви бачите суму. Сума виплати вже є чистою — за вирахуванням комісій за обробку, будь-яких повернень, здійснених за цей період, і конвертації валют, якщо ви продаєте на міжнародному рівні. Облік виплати як валового доходу завищує вашу верхню лінію доходу і приховує реальну маржу.

Рішення — це потрійне звірення, яке слід проводити щонайменше щомісяця:

1. Звіт про продажі процесора — валові транзакції, деталізовані за продуктом/розширенням, якщо ваш обліковий запис це підтримує, до вирахування комісій і повернень.
2. Звіт про виплати процесора — чисті суми, що фактично надійшли на ваш банківський рахунок, з окремими рядками для комісій і повернень.
3. Банківська виписка — депозити, що фактично зараховані.

Звірте всі три джерела. Звіт про продажі показує, скільки ви заробили (дохід, визнаний у момент, коли клієнт оплатив період обслуговування). Звіт про виплати показує втрати на комісіях та активність повернень, які слід обліковувати як витрати та контр-дохід. Банківська виписка підтверджує, що кошти дійсно надійшли. Коли будь-які два з трьох джерел не збігаються — це сигнал, що варто щось розслідувати: невдалу виплату, оскаржений чарджбек чи комісію процесора, якої ви не очікували.

Специфічний для Chrome ризик: затримки модерації та зняття з публікації​

У кожного платіжного стеку є звичайна активність повернень. У розширень Chrome є додатковий тип збою, який варто відстежувати як окрему статтю: затримки модерації та зняття з публікації через порушення політики Chrome Web Store.

Коли команда модерації Google позначає опубліковане розширення за порушення політики, ви отримуєте або негайне зняття з публікації (при помірних і серйозних порушеннях), або період попередження приблизно на 7–30 днів для виправлення незначного порушення. У будь-якому разі користувачі втрачають доступ до розширення, за яке активно платять, а це породжує передбачуваний сплеск запитів на повернення коштів, чарджбеків і звернень у підтримку — розробники повідомляли про втрату двозначного відсотка місячного доходу від підписок саме через цю схему, окрім прямих повернень.

Дві бухгалтерські звички роблять цю ситуацію керованою, а не несподіванкою:

• Позначайте повернення та чарджбеки за причиною. Повернення через те, що клієнту не сподобалося розширення, — це звичайна витрата ведення бізнесу. Повернення через те, що ваше розширення зняли з публікації на тиждень, — це окремий, відстежуваний бізнес-ризик. Розділення їх (навіть просто через поле нотатки чи субрахунок) дозволяє побачити протягом року, скільки волатильності доходу пояснюється платформним ризиком, а скільки — відповідністю продукту ринку.
• Розглядайте очікувану модерацію чи відкрите попередження про порушення політики як подію, вартою розкриття, так само як ви позначили б ризик відтоку ключового клієнта. Якщо ви рахуєте цифри, щоб вирішити, чи піднімати ціни, наймати допомогу чи брати кредит, розширення, яке наразі перебуває під 30-денним попередженням про відповідність, — це не «стабільний регулярний дохід»; моделюйте його як такий, що перебуває під загрозою, доки воно не пройде модерацію.

Визнавайте дохід тоді, коли заробляєте його, а не коли надходить виплата​

Розширення з підпискою та разовою покупкою потребують різного підходу до обліку, і плутанина між ними — найпоширеніша бухгалтерська помилка в цій ніші:

• Щомісячні або щорічні підписки: визнавайте дохід рівномірно протягом періоду, за який платить клієнт, а не одразу в момент списання коштів. Річний план, оплачений наперед, створює зобов'язання з відкладеного доходу — вам заплатили, але ви ще не надали одинадцять із дванадцяти місяців обслуговування, тому доходом у місяць продажу є лише 1/12, а решта поступово списується з балансу місяць за місяцем.
• Довічні угоди (популярна модель ціноутворення саме для розширень, оскільки користувачі насторожено ставляться до постійних підписок за браузерний інструмент): вони все одно являють собою зобов'язання безстроково надавати оновлення та підтримку, тому визнання 100% готівки як доходу в перший же день завищує ваш фактичний зароблений дохід за цей місяць. Більш обґрунтований підхід визнає дохід від довічної угоди протягом розумного оціночного періоду обслуговування (багато компаній використовують 12–36 місяців як орієнтир), а не одразу.
• Разові покупки без подальших зобов'язань: визнавайте повністю в момент поставки — це найпростіший випадок.

MRR (щомісячний регулярний дохід) — корисна метрика зростання, але це не те саме число, що визнаний дохід у вашому обліку. MRR показує темп активних підписок; ваш облік має відображати те, що ви фактично заробили за цей період після відкладень.

Структура обліку, яка витримує кілька розширень​

Якщо ви ведете облік у форматі простого тексту з подвійним записом, рішення проблеми «одна виплата, кілька розширень» — це план рахунків, який з самого початку розділяє дохід за продуктом, плюс окремі рахунки для відрахувань, які звіт про виплати вже вираховує:

2026-07-05 * "Stripe payout - batch #4471"
  Assets:Bank:Checking                      842.17 USD
  Income:Extensions:FocusTimer             -510.00 USD
  Income:Extensions:TabArchiver            -390.00 USD
  Expenses:PaymentProcessing:StripeFees      41.83 USD
  Expenses:Refunds:FocusTimer                16.00 USD

Кожна виплата стає однією транзакцією, що узгоджує банківський депозит із доходом за кожним розширенням, комісіями та поверненнями як окремими проведеннями — замість одного непрозорого рядка «депозит Stripe», який нічого не каже про те, який продукт насправді прибутковий. Оскільки файл є звичайним текстом, ви можете виконувати grep або запити по ньому за розширенням, за місяцем чи за причиною повернення — саме ту прозорість, якої не дає загальний звіт про виплату однією сумою.

Щомісячний чекліст​

1. Отримайте звіт про продажі процесора за місяць (валовий, деталізований за продуктом, якщо можливо).
2. Отримайте звіт про виплати та розділіть комісії, повернення й чарджбеки на окремі рядки.
3. Звірте депозити виплат із банківською випискою.
4. Обліковуйте дохід від підписок і довічних угод за графіком визнання, а не в момент надходження.
5. Позначайте будь-яке повернення, пов'язане із затримкою модерації чи зняттям з публікації в Chrome Web Store, окремо від звичайного відтоку.
6. Якщо ви продаєте на міжнародному рівні через прямий платіжний процесор (а не через продавця-реєстратора), перевірте, чи не перевищили ваші сукупні продажі в якійсь країні поріг реєстрації на ПДВ/GST.

Ведіть облік вашого бізнесу з розширеннями так само чисто, як і ваш код​

Ви ж не випустили б розширення без контролю версій — ваші фінанси заслуговують на таку саму дисципліну, особливо коли виплати розділені між кількома продуктами й процесорами. Beancount.io пропонує облік у форматі простого тексту з контролем версій, що дозволяє позначати дохід за розширенням, відстежувати відкладений дохід і звіряти виплати з банківською випискою з тією самою точністю, яку ви застосовуєте до свого коду. Почніть безкоштовно і подивіться, чому розробники ведуть свій облік так само, як і все інше, що вони створюють.