Ви надсилаєте спонсорований випуск у вівторок вранці. До середи ваша панель аналітики показує 4 200 відкриттів і 380 кліків за посиланням спонсора. За вашою узгодженою ставкою $2 за клік це $760 — цифра, яку ви бачите в реальному часі прямо у своїй аналітиці.
Тож ви проводите цю суму в обліку. Ви додаєте $760 до доходу за липень, бо реклама вийшла в липні й кліки сталися в липні. Здається, це очевидно.
Але насправді це не те, що ви заробили, і не той момент, коли ви це заробили. Якщо ви продаєте спонсорство через рекламну мережу на кшталт beehiiv або самостійно продаєте пряму рекламу в розсилці за моделлю CPC, розрив між моментом "реклама вийшла" і моментом "дохід реальний" ширший — і має суттєвіші наслідки для вашого обліку — ніж усвідомлює більшість соло-видавців.
Три цифри, які насправді не однакові
Рекламні мережі розсилок, що платять за моделлю "оплата за клік" (cost-per-click), не платять за сирі кліки. Вони платять за підтверджені кліки — а перевірка займає час.
Ось послідовність подій на конкретному прикладі рекламної мережі beehiiv (механіка схожа на більшості CPC-платформ для розсилок):
- День відправлення. Спонсорований випуск виходить. Ваша аналітика одразу починає показувати відкриття та кліки. Ця цифра попередня і зазвичай найвища з усіх, які ви коли-небудь побачите для цієї кампанії.
- Приблизно через 96 годин. Мережа проводить додаткову перевірку кожного кліка — відфільтровуючи бот-трафік, повторні кліки від того самого користувача та кліки, після яких відвідувач миттєво покинув цільову сторінку (сильна ознака бота або випадкового кліка). Ви отримуєте фінальний звіт про ефективність. Ця підтверджена цифра дуже часто менша за те, що показувала ваша сира аналітика в день відправлення.
- 20-те число наступного місяця. Мережа групує весь підтверджений рекламний дохід за попередній місяць і виплачує його одним переказом.
Три дати, три різні цифри — і лише одна з них є тією, яку варто фактично проводити як дохід. І це не та цифра, яку ваша панель аналітики показує в день відправлення.
Чому інстинкт "проводити дохід у день виходу реклами" є помилковим
Стандартний принцип нарахування — визнавати дохід тоді, коли він зароблений, а не тоді, коли готівка надходить на рахунок, — правильний за суттю, але вказує на неправильну дату, якщо зупинитися на "реклама вийшла". За стандартом визнання доходу US GAAP (ASC 606) дохід визнається, коли виконано зобов'язання з виконання договору, а не коли підписано контракт чи технічно надіслано матеріал.
Для спонсорства розсилки з фіксованою оплатою зобов'язання з виконання просте: ви надіслали випуск, вам належить фіксована плата — усе. Проводьте це в день відправлення.
Для спонсорства за моделлю CPC зобов'язання з виконання — це не "надіслати випуск з посиланням у ньому". Це "забезпечити визначену кількість кваліфікованих кліків". Ви фактично не знаєте, скільки кваліфікованих кліків ви забезпечили, доки не завершиться процес перевірки — а це, за власною документацією beehiiv, відбувається приблизно через 96 годин після відправлення, а не одразу.
Ця відмінність має значення з трьох практичних причин:
Кількість сирих кліків — це не ваша цифра доходу. Фільтрація ботів і виявлення миттєвих відмов існують саме тому, що кількість сирих кліків завищена порівняно з тим, за що рекламодавці справді готові платити. Проведення доходу за цифрою з панелі аналітики в день відправлення означає проведення числа, яке сама мережа не вважає остаточним, — і ви коригуватимете його в бік зменшення протягом тижня, а це саме той тип сюрпризу "чому дохід за липень щойно зменшився", який підриває довіру до звіту про прибутки та збитки.
Відправлення, що припадає на межу місяця, створює реальне нарахування, а не похибку округлення. Якщо ви надсилаєте спонсорований за CPC випуск 29 липня, вікно перевірки закриється лише на початку серпня — вже після того, як ваш липневий облік мав би закритися. Якщо чекати виплати 20-го числа, щоб хоч щось зафіксувати, ви перенесете дохід за липневу кампанію в облік вересня (адже виплата того місяця покриває активність за серпень, а не за липень). Правильніший підхід: під час закриття місяця оцінити нарахований дохід для будь-якої кампанії, вікно перевірки якої вже закрилося, але яка ще не виплачена, використовуючи підтверджений звіт, якщо він у вас є, або консервативну оцінку, якщо його немає, а потім скоригувати цю суму, коли надійде звіт про фактичну виплату.
Дата виплати — це подія отримання готівки, а не подія визнання доходу. Отримання оплати 20-го числа повідомляє вам, коли готівка надійшла на рахунок, — корисно для планування грошових потоків, але не має значення для визначення того, який саме місяць фактично заробив ці кошти. Змішування цих двох понять — найпоширеніша помилка в бухгалтерському обліку серед невеликих операторів розсилок, адже роками більшість із них укладали лише угоди з фіксованою оплатою, де дата відправлення, дата заробітку та (майже) дата оплати припадали на один і той самий тиждень.
Практична схема обліку
Якщо ви продаєте спонсорство через рекламну мережу на основі CPC, ось робочий процес, який утримує ваш облік чесним без потреби вручну звіряти кожен окремий клік:
- У день відправлення: ще нічого не проводьте, або, якщо потрібна видимість щодо перспективи, зафіксуйте сиру оцінку в полі приміток — не як проведений дохід.
- Під час перевірки (приблизно через 96 годин): зафіксуйте запис нарахованого доходу (дебіторську заборгованість, оскільки готівка ще не надійшла) на суму підтвердженої кількості кліків, помножену на вашу ставку CPC. Це ваша реальна дата заробітку, узгоджена з GAAP.
- Під час виплати (20-го числа наступного місяця): закрийте дебіторську заборгованість грошовим надходженням. Якщо сума виплати відрізняється від нарахованої — мережі час від часу вносять коригування через спори щодо звітів або компенсаційні виплати — проведіть різницю як невеликий коригувальний запис, а не переоформлюйте показники попереднього місяця.
- Під час закриття місяця завжди перевіряйте кампанії, що припадають на межу періодів: будь-яке відправлення в останні 4-5 днів місяця, звіт про перевірку якого ще не надійшов, потребує оцінки нарахування, а не відмовки "врахуємо наступного місяця".
Якщо ви продаєте спонсорство кільком рекламодавцям у межах кількох відправлень за місяць — що стає дедалі поширенішим, оскільки рекламні мережі дозволяють розсилкам середнього розміру запускати кілька кампаній за випуск або за тиждень — така звірка стає справді виснажливою в електронній таблиці. Кожна кампанія має свою дату відправлення, свою дату перевірки та свій рядок у підсумковому пакеті виплат, а електронні таблиці не гарантують, що долар нарахованого доходу за липень справді буде зіставлений з доларом готівки за серпень.
Це саме той тип багатоетапної, прив'язаної до дат звірки, для якої простий текстовий облік із контролем версій підходить краще за статичну електронну таблицю: кожна операція — нарахування, дебіторська заборгованість, остаточне закриття готівкою — це окремий, придатний до аудиту запис, пов'язаний за датою та рахунком, тож ви завжди можете простежити рядок "дохід від спонсорства" за конкретний місяць до тих самих звітів про підтверджені кліки, з яких він утворився, замість того щоб довіряти єдиній вручну оновлюваній сумі.
Це стосується не лише CPC — перевірте кожну модель, яку ви використовуєте
Якщо ваша розсилка монетизується за допомогою кількох цінових моделей, застосуйте той самий тест "коли зобов'язання з виконання фактично виконане" до кожної окремо:
- CPM (оплата за тисячу відкриттів/показів): Зазвичай визначається швидше, ніж CPC, оскільки відкриття відстежуються прямолінійніше, ніж якість переходів за посиланням, — але уточніть, чи ваша мережа рахує унікальні відкриття на момент відправлення, чи за плаваючий період (деякі рахують відкриття протягом 30+ днів після відправлення, що відсуває вашу справжню дату заробітку далі, ніж ви очікуєте).
- Фіксована плата: Найпростіший випадок — визнавайте дохід у день відправлення, оскільки зобов'язання ("доставити спонсороване розміщення вашій аудиторії") виконується в момент виходу випуску, незалежно від результативності.
- CPA (оплата за конверсію): Найдовша затримка з трьох моделей. Вам нічого не належить, доки рекламодавець не підтвердить конверсію, а це може зайняти дні чи тижні після самого кліка, і рекламодавці іноді відкликають "конверсії", які пізніше скасовуються чи повертаються. Ставтеся до доходу за CPA як до найменш визначеного з трьох, поки не надійде власне підтвердження рекламодавця — проводьте його консервативно.
Ставки спонсорства розсилок сильно варіюються залежно від розміру списку та ніші: невеликі списки з менш ніж 5 000 підписників часто заробляють $50–$250 за одне розміщення, тоді як усталені розсилки з десятками тисяч підписників можуть отримувати $500–$3,000 і більше — але описана тут механіка визнання доходу застосовується за будь-якого масштабу. Видавець, що проводить одну кампанію на місяць, і видавець, що проводить десяток, стикаються з однаковим базовим питанням: коли ви фактично заробили ці гроші й чи відображає ваш облік саме цю дату, а не просто дату, коли кошти випадково надійшли на ваш рахунок?
Тримайте дохід від спонсорства у повній відповідності
У міру того як монетизація розсилок зміщується від простих угод із фіксованою оплатою до результативних моделей CPC і CPA, розрив між "коли реклама вийшла" і "коли дохід став реальним" перетворюється на справжню бухгалтерську проблему, а не просто на технічну деталь обліку. Beancount.io надає простий текстовий облік, який дає вам повну прозорість і контроль над вашими фінансовими даними — кожне нарахування, коригування та закриття готівкою є відстежуваним записом із контролем версій, а не клітинкою, яку ви перезаписали минулого місяця. Почніть безкоштовно і дізнайтеся, чому розробники, незалежні автори та фінансові фахівці переходять на простий текстовий облік.