Продаж доступу до вашого MCP-сервера: Бухгалтерський облік доходу від використання та підписок

Ви опублікували MCP-сервер, який робить щось справді корисне — скажімо, структурований доступ до каталогу деталей або інструмент для резюмування документів — і одного ранку ви прокидаєтеся від 40 000 викликів інструментів, які надійшли за ніч від AI-агентів, яких ви ніколи не зустрічали. Це мрія, поки ви не усвідомите, що ваш білінговий лічильник, ваші книги та ваша податкова конфігурація були всі розроблені для людей, які натискають кнопки з людською швидкістю. Агенти не поводяться як люди-користувачі: один запит може запустити десятки викликів інструментів за секунди, зациклитися на тисячах запитів для вирішення однієї інструкції та спричинити витрати на кожному кроці. Якщо ви стягуєте плату за доступ, вам потрібне вимірювання, яке відповідає тому, як споживають агенти, записи доходу, які відповідають моменту надання цінності, та відстеження витрат, яке зберігає вашу маржу видимою. Цей посібник розглядає всі три аспекти.

Як насправді надходить дохід від MCP​

Model Context Protocol відкриває ваш сервер як набір інструментів і ресурсів, які AI-клієнти викликають через JSON-RPC. Оскільки кожен виклик є програмним, у вас більше варіантів ціноутворення, ніж у традиційного SaaS за місця — і кожен з них обліковується по-різному.

За виклик інструмента. Найпростіша модель: кожен виклик методу коштує фіксовану суму. Його легко виміряти та легко пояснити, і він добре працює, коли ваші інструменти мають приблизно однакову вартість. Він руйнується, коли один легкий пошук метаданих майже нічого вам не коштує, тоді як робочий інструмент розгалужується на десяток нижчих викликів API.

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

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

За сесією або пам'яттю. Сервери, які зберігають розмовний стан між викликами, можуть стягувати за створену сесію, за хвилину активного часу сесії або за блок збереженого контексту. Це підходить для асистентів і тривалих агентів, які покладаються на ваш шар пам'яті.

Гібридна підписка плюс перевищення. Базова місячна плата, яка включає квоту, з вимірюваними стягненнями після порогу. Це найпоширеніша форма в бізнесі продуктивних API, оскільки база покриває ваші фіксовані витрати, тоді як перевищення масштабуються з важкими користувачами.

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

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

Мікроплатежі, рідні для агентів. Протоколи, як-от x402, дозволяють агенту платити за запит у стейблкоїні через HTTP, без реєстрації облікового запису та без рахунку-фактури. Якщо ви підете цим шляхом, кожен виклик інструмента може стати окремим крихітним продажем, що має реальні наслідки для того, як ви фіксуєте дохід і базу витрат. (Для ознайомлення з тим, як працюють ці машинні платежі, дивіться наш посібник про AI-агентів, які платять одне одному через x402.)

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

Ваш лічильник — це ваш первинний документ обліку​

У бізнесі на основі використання потік подій використання — це те, чим є табелі для юридичної фірми: первинний запис, який обґрунтовує кожен долар у рахунку-фактурі. Ставтеся до нього відповідно.

Стандартна схема виглядає так. Ваш сервер генерує подію використання на кожну одиницю, що підлягає оплаті — назва методу, ідентичність клієнта, кількість, часова мітка, успіх або невдача. Ці події надходять до шару вимірювання (Stripe Billing Meters, платформа білінгу на основі використання або ваш власний агрегатор), який приписує їх кожному клієнту та зводить у рахунок-фактуру на кінець періоду. Вимірюваний білінг Stripe слідує саме цій формі: ви звітуєте про використання протягом циклу, і в кінці періоду він підсумовує записи та виставляє рахунок на загальну суму.

З цього конвеєра випливають три бухгалтерські дисципліни:

1. Звіряйте лічильник з рахунком-фактурою кожен цикл. Вимірювані одиниці, помножені на ставку, мають дорівнювати виставленому доходу від використання, так само як відвантажені одиниці, помножені на ціну, мають дорівнювати продажам. Будь-яка розбіжність — це або безкоштовне використання, яке ви мали на увазі, або невдалі виклики, які ваше ціноутворення за результатом пробачило, або витік — використання, яке ваш лічильник ніколи не бачив. Витік — тихий убивця: неавтентифікована кінцева точка або невимірюваний інструмент — це дохід, який ви заробили і ніколи не стягнете.
2. Зберігайте необроблені журнали використання як ваш аудиторський слід. Агрегати — це те, що ви виставляєте до сплати; журнали на рівні подій — це те, що ви показуєте, коли клієнт оспорює сплеск або бухгалтер запитує, з чого складається число доходу. Зберігайте їх принаймні стільки, скільки триває вікно оспорювання рахунків, в ідеалі — стільки, скільки ваші податкові записи.
3. Приписуйте ідентичність на периферії. Вирішіть, чи платником є кінцевий користувач за запитом, чи власник API-ключа, який інтегрує ваш сервер, і зафіксуйте це рішення в події. Коли один корпоративний ключ розгалужується на агентів п'ятдесяти співробітників, «хто є клієнтом» — це бухгалтерське питання з податковими наслідками, а не просто деталь білінгу.

Правильне фіксування доходу від використання​

Ось де оператори MCP найчастіше помиляються: гроші надходять у Stripe, вони фіксують їх як дохід, і книги тихо відхиляються від реальності. Згідно з ASC 606 — стандартом визнання доходу — правило для ціноутворення за споживанням прямолінійне: визнавайте дохід у міру споживання клієнтом, тому що кожна спожита одиниця є зобов'язанням, що виконується. Плата за використання є змінним відшкодуванням, що означає, що ви визнаєте те, що фактично було використано за період, а не те, чого ви сподіваєтеся від вартості контракту.

Чиста оплата за фактом використання — це легкий випадок. Агенти спожили 100 000 викликів у вересні за вашою вказаною ставкою; дохід за вересень — це 100 000, помножені на ставку, навіть якщо рахунок не сплачено до жовтня. Зафіксуйте дебіторську заборгованість, коли виставляєте рахунок, дохід — коли відбулося використання. Якщо ви хочете повного розгляду вимірювання токенів і використання згідно з ASC 606, наші посібники з білінгу за токени та визнання доходу SaaS на основі використання заглиблюються далі.

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

Передплачені кредити створюють зобов'язання, а не дохід. Коли клієнт купує блок кредитів, дебетуйте гроші та кредитуйте відкладений дохід. Щоразу, коли використання зменшує баланс, переміщуйте спожиту вартість з відкладеного доходу до заробленого доходу. Залишок, який клієнти ніколи не використають — втрати, — має власне правило: якщо ваша історія дозволяє надійно оцінити невикористану частку, ви визнаєте очікувані втрати поступово пропорційно фактичному використанню; якщо ви занадто нові, щоб це оцінити, ви чекаєте, поки кредити не закінчаться або використання не стане малоймовірним, а потім визнаєте залишок. Нові MCP-сервери майже завжди належать до другого табору, тож не фіксуйте очікувані втрати заздалегідь, щоб прикрасити місяць.

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

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

Сторона витрат: скільки насправді коштує MCP-сервер​

Дохід за виклик інструмента нічого не означає без витрат за виклик інструмента. Побудуйте свою собівартість проданих товарів знизу вгору:

• Обчислення та хостинг. Сервери, контейнери або безсерверні виклики, які запускають ваші інструменти, плюс пропускна здатність вихідного трафіку для методів із великими навантаженнями.
• Витрати на нижчі API та моделі. Кожен виклик LLM, пошук вбудовування, пошуковий запит або звернення до стороннього API, які роблять ваші інструменти від імені клієнта. Якщо ваш інструмент резюмування викликає постачальника моделі на кожен документ, цей наскрізний потік є вашою найбільшою змінною витратою, і його потрібно відстежувати для кожного інструмента, а не як місячну суму.
• Витрати на дані та ліцензії. Роялті або плата за запит за пропрієтарні дані, які відкриває ваш сервер.
• Частка доходу маркетплейсу. Частка платформи від продажів на маркетплейсі є витратою на продаж (або зменшенням чистого платежу — виберіть один підхід і будьте послідовними), ніколи не заліком, похованим усередині доходу.
• Обробка платежів. Комісії за картки при білінгу підписок, комісії шлюзу за рахунками, мережеві комісії при розрахунках стейблкоїнами. У масштабі мікроплатежів вони кусаються: фіксована комісія за транзакцію може перевищити маржу від виклику інструмента за частку цента, що саме тому протоколи платежів агентів зупинилися на рейках із низькими комісіями.

Проведіть юніт-розрахунок для кожного інструмента, перш ніж призначати ціну. Припустімо, ваш інструмент пошуку в каталозі коштує вам $0,004 за виклик на обчислення плюс нижчі запити, і ви стягуєте $0,01. Це виглядає як 60 відсотків валової маржі — поки підтримка, інфраструктура вимірювання та пробачення невдалих викликів не знизять її. Призначайте ціну від виміряних витрат, а не від відчуттів, і повторюйте розрахунок щоразу, коли постачальник нижчого рівня змінює свої ставки.

Надходження стейблкоїнів заслуговують окремого абзацу. Для податкових цілей стейблкоїни є майном, а не валютою: справедлива ринкова вартість на момент отримання — це ваш дохід, і ця вартість стає вашою базою витрат. Якщо ви тримаєте монети, і прив'язка коливається, або ви пізніше конвертуєте за іншою вартістю, різниця є прибутком або збитком. У масштабі мікроплатежів відстеження за транзакціями є обов'язковим — агрегатні здогадки не витримають перевірки — тож направляйте записи розрахунків у ваші книги автоматично, а не реконструюйте їх наприкінці року.

Податок з продажів: ваш API підлягає оподаткуванню в більшій кількості штатів, ніж ви думаєте​

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

• Каліфорнія підписала SB 122 у червні 2026 року, поширивши податок з продажів на цифрові продукти, включаючи віддалено доступне програмне забезпечення та SaaS, з набранням чинності 1 січня 2027 року — припинивши десятиліттями діюче звільнення на найбільшому державному ринку країни.
• Чикаго оподатковує SaaS і хмарне програмне забезпечення за своїм податком на транзакції оренди особистого майна за ставкою 9 відсотків, хоча Іллінойс не оподатковує SaaS на рівні штату.
• Оклахома пішла іншим шляхом, постановивши, що підписки на SaaS з електронною доставкою звільнені від оподаткування — доказ того, що ви не можете припускати одну відповідь по всій країні.

Пороги економічного зв'язку визначають, де ви повинні стягувати податок: більшість штатів із податком з продажів використовують поріг у $100 000 продажів для віддалених продавців, при цьому Каліфорнія, Техас і Нью-Йорк — на рівні $500 000. Вимірюваний API із загальнонаціональним охопленням може перетнути поріг у штаті, де ви ніколи не ступали, виключно за обсягом транзакцій.

Що з цим робити:

1. Визначте оподатковуваність для кожного штату, де у вас є клієнти, а не лише там, де ви живете. Ваш лічильник уже записує місцезнаходження клієнта для атрибуції — повторно використовуйте ці дані для відстеження зв'язку.
2. Продажі на маркетплейсі можуть бути покриті. Там, де маркетплейс кваліфікується як маркетплейс-фасилітатор, він стягує та перераховує податок за вашими продажами через нього. Прямі продажі з вашого власного сайту або вашої власної кінцевої точки x402 — цілком ваша відповідальність.
3. Автоматизуйте стягнення рано. Податковий рушій (Stripe Tax та його конкуренти), підключений до оформлення замовлення, коштує набагато менше, ніж реєстрація, подання та перерахування в десятці штатів вручну — і він зберігає докази місцезнаходження клієнта, які запитують аудитори.
4. Слідкуйте за календарем. З датою набрання чинності в Каліфорнії у 2027 році та подібними розширеннями, що просуваються через інші законодавчі органи, позиція «ми занадто малі, щоб хвилюватися» швидко втрачає силу.

Виплати з маркетплейсів і податкові форми​

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

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

Контрольний список на кінець місяця для операторів MCP​

Закривайте свої книги однаково щомісяця, і крайові випадки перестануть накопичуватися:

1. Витягніть вимірюване використання за кожним клієнтом за кожним лічильником і прив'яжіть його до виставленого доходу від використання. Дослідіть будь-яку розбіжність, що перевищує ваш базовий рівень безкоштовного рівня та пробачення невдач.
2. Розділіть гібридні рахунки на базовий (рівномірний) і перевитратний (у міру споживання) рахунки доходу.
3. Виведіть зменшення передплачених кредитів з відкладеного доходу; перегляньте старіючі залишки кредитів для обробки втрат.
4. Відобразіть нижчі витрати на API, хостинг і дані для кожного інструмента; перерахуйте валову маржу для кожного лічильника.
5. Звірте валові звіти маркетплейсу з чистими депозитами; підшийте звіти до записів місяця.
6. Фіксуйте надходження стейблкоїнів за справедливою ринковою вартістю та відстежуйте базу витрат через конвертацію.
7. Перегляньте підсумки за місцезнаходженням клієнтів щодо порогів зв'язку зі штатами; підтвердіть стягнення податку, де це потрібно.
8. Збережіть необроблений експорт використання разом із пакетом закриття місяця — це первинний документ, який попросить ваше майбутнє «я» (або аудитор).

Спростіть своє управління фінансами​

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