Продажа доступа к вашему MCP-серверу: бухгалтерский учёт выручки по потреблению и подпискам

Вы опубликовали MCP-сервер, который делает что-то действительно полезное — скажем, структурированный доступ к каталогу запчастей или инструмент для суммирования документов — и однажды утром вы просыпаетесь от 40 000 вызовов инструментов, которые за ночь поступили от AI-агентов, которых вы никогда не встречали. Это мечта, пока вы не осознаёте, что ваш биллинговый счётчик, ваши книги и ваша налоговая настройка были рассчитаны на людей, нажимающих кнопки со скоростью человека. Агенты не ведут себя как пользователи-люди: один промпт может запустить десятки вызовов инструментов за секунды, зациклиться на тысячах запросов для выполнения одной инструкции и вызвать сопутствующие расходы на каждом шаге. Если вы берёте плату за доступ, вам нужен учёт, соответствующий тому, как потребляют агенты, записи о выручке, соответствующие моменту оказания ценности, и отслеживание расходов, сохраняющее вашу маржу видимой. Это руководство проходит через все три аспекта.

Как на самом деле поступает выручка от MCP​

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

За вызов инструмента. Самая простая модель: каждый вызов метода стоит фиксированную сумму. Её легко измерять и легко объяснить, и она хорошо работает, когда ваши инструменты имеют примерно одинаковую стоимость. Она ломается, когда один лёгкий поиск метаданных почти ничего вам не стоит, а инструмент рабочего процесса разворачивается в дюжину последующих вызовов API.

По объёму данных. Когда методы возвращают большие объёмы данных — содержимое документов, эмбеддинги, результаты запросов — взимание платы за возвращённый мегабайт или за тысячу токенов приводит цену в соответствие с затратами, так же как поставщики моделей устанавливают цены на свои API.

По результату. Вместо оплаты за попытку вы берёте плату за завершённое действие: за успешно суммированный документ, за выполненную команду устройства, за запрос, вернувший корректные результаты. Клиенты это любят, потому что неудачные или пустые вызовы бесплатны; вам нужен учёт, который отличает успех от неудачи, прежде чем засчитать единицу.

По сессии или памяти. Серверы, сохраняющие состояние диалога между вызовами, могут взимать плату за созданную сессию, за минуту активного времени сессии или за блок сохранённого контекста. Это подходит ассистентам и долго работающим агентам, которые опираются на ваш слой памяти.

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

Предоплаченные кредиты. Клиенты покупают блоки использования заранее и расходуют их. Отлично для денежного потока, сложнее для бухгалтерского учёта (подробнее ниже), потому что полученные деньги — это не заработанная выручка, пока кредиты не потреблены.

Выплаты от маркетплейсов. Листинги и маркетплейсы вокруг MCP-серверов берут долю выручки и перечисляют вам остаток — та же форма, что и продажа через любой магазин приложений, с тем же вопросом учёта валовой vs чистой суммы.

Агентно-ориентированные микроплатежи. Протоколы вроде 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 даёт вам бухгалтерский учёт в виде простого текста с полной прозрачностью и контролем над вашими финансовыми данными — каждый счёт за использование, списание кредитов и комиссия маркетплейса записываются как контролируемые версиями, готовые для ИИ транзакции, которые вы действительно можете проверить. Начните бесплатно и держите бухгалтерию вашей агентной экономики такой же программируемой, как ваш сервер.