Продажба на достъп до вашия MCP сървър: Счетоводство за приходи от използване и абонаменти

Публикували сте MCP сървър, който върши нещо наистина полезно — да речем, структуриран достъп до каталог с части или инструмент за обобщаване на документи — и една сутрин се събуждате с 40 000 извиквания на инструменти, пристигнали през нощта от AI агенти, които никога не сте срещали. Това е мечтата, докато не осъзнаете, че вашият измервателен механизъм за таксуване, вашите книги и вашата данъчна настройка са били проектирани за хора, натискащи бутони с човешка скорост. Агентите не се държат като човешки потребители: една подкана може да свърже десетки извиквания на инструменти за секунди, да премине в цикъл през хиляди заявки, за да разреши една единствена инструкция, и да задейства последващи разходи при всяка стъпка. Ако таксувате за достъп, имате нужда от измерване, което съответства на начина, по който агентите консумират, записи за приходи, които съответстват на момента, в който стойността се доставя, и проследяване на разходите, което поддържа маржа ви видим. Това ръководство разглежда и трите.

Как всъщност пристигат приходите от MCP​

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

На извикване на инструмент. Най-простият модел: всяко извикване на метод струва фиксирана сума. Лесно се измерва и лесно се обяснява, и работи добре, когато вашите инструменти имат приблизително еднаква цена. Разпада се, когато една лека справка за метаданни не ви струва почти нищо, докато работен инструмент се разклонява на дузина последващи API извиквания.

Според обема на данните. Когато методите връщат големи полезни товари — съдържание на документи, вграждания, резултати от заявки — таксуването на мегабайт върнати данни или на хиляда токена alignира цената с разходите, точно както доставчиците на модели ценообразуват собствените си API.

Според резултата. Вместо да таксувате на опит, таксувате на завършено действие: на успешно обобщен документ, на изпълнена команда за устройство, на заявка, която връща валидни резултати. Клиентите го обичат, защото неуспешните или празни извиквания са безплатни; вие се нуждаете от измерване, което може да различи успех от неуспех, преди да отчете единица.

Според сесия или памет. Сървъри, които поддържат разговорно състояние между извикванията, могат да таксуват на създадена сесия, на минута активно време на сесията или на блок задържан контекст. Това пасва на асистенти и дълготрайни агенти, които разчитат на вашия слой памет.

Хибриден абонамент плюс превишения. Основна месечна такса, която включва квота, с измервани такси над прага. Това е най-често срещаната форма в производствените API бизнеси, защото основата покрива фиксираните ви разходи, докато превишенията се мащабират с интензивните потребители.

Предплатени кредити. Клиентите купуват блокове използване предварително и ги изчерпват. Чудесно за паричния поток, по-сложно за счетоводството (повече за това по-долу), защото получените пари не са спечелен приход, докато кредитите не бъдат консумирани.

Изплащания от маркетплейси. Листингите и маркетплейсите около MCP сървъри вземат дял от приходите и ви превеждат остатъка — същата форма като продажбата чрез всеки маркетплейс за приложения, със същия счетоводен въпрос за бруто спрямо нето.

Микроплащания, естествени за агентите. Протоколи като x402 позволяват на агент да плаща на заявка в стейбълкойн през HTTP, без регистрация на акаунт и без фактура. Ако поемете по този път, всяко извикване на инструмент може да стане отделна мъничка продажба, което има реални последици за начина, по който записвате приходите и данъчната основа. (За контекст как работят тези машинни плащания вижте нашето ръководство за AI агенти, които си плащат взаимно чрез x402.)

Изберете измервателния показател, който клиентът възприема като стойност — това е продуктово решение — но знайте, че всеки избор по-горе създава различен счетоводен модел. Останалото от това ръководство проследява парите през всеки от тях.

Вашият измервателен механизъм е вашият първичен счетоводен документ​

В бизнес, базиран на използване, потокът от събития за използване е това, което са часовите листове за адвокатска кантора: първичният запис, който обосновава всеки долар във фактурата. Отнасяйте се към него по този начин.

Стандартната схема изглежда така. Вашият сървър излъчва събитие за използване на всяка таксуема единица — име на метод, идентичност на клиента, количество, времеви печат, успех или неуспех. Тези събития се вливат в слой за измерване (Stripe Billing Meters, платформа за таксуване според използването или ваш собствен агрегатор), който ги приписва на клиент и ги обобщава във фактурата в края на периода. Измерваното таксуване на Stripe следва точно тази форма: отчитате използването през цикъла, а в края на периода то обобщава записите и фактурира общата сума.

Три счетоводни дисциплини произтичат от този pipeline:

1. Сверявайте измервателния механизъм с фактурата всеки цикъл. Измерените единици по ставка трябва да се равняват на фактурирания приход от използване, точно както изпратените единици по цена трябва да се равняват на продажбите. Всяка разлика е или използване от безплатния план, което сте предвидили, неуспешни извиквания, които ценообразуването според резултата е опростило, или изтичане — използване, което вашият измервателен механизъм никога не е видял. Изтичането е тихият убиец: неавтентикиран endpoint или неизмерван инструмент е приход, който сте спечелили и никога няма да съберете.
2. Пазете суровите логове за използване като ваша одиторска следа. Агрегатите са това, което фактурирате; логовете на ниво събитие са това, което показвате, когато клиент оспори скок или счетоводител попита от какво е съставено дадено число за приходи. Запазете ги поне толкова дълго, колкото е вашият прозорец за оспорване на фактури, в идеалния случай толкова дълго, колкото данъчните ви записи.
3. Приписвайте идентичност на входа. Решете дали таксуемата страна е крайният потребител зад подканата, или притежателят на API ключа, който интегрира вашия сървър, и запишете това решение в събитието. Когато един корпоративен ключ се разклонява към агентите на петдесет служители, „кой е клиентът" е счетоводен въпрос с данъчни последици, а не просто детайл по фактурирането.

Записване на приходите от използване по правилния начин​

Тук операторите на MCP най-често сгрешават: парите пристигат в Stripe, те ги записват като приход и книгите тихо се отдалечават от реалността. Съгласно ASC 606 — стандартът за признаване на приходи — правилото за ценообразуване според консумацията е ясно: признавайте приходи, докато клиентът консумира, защото всяка консумирана единица е изпълненото задължение за изпълнение. Таксите за използване са променливо възнаграждение, което означава, че признавате това, което действително е било използвано през периода, а не това, което се надявате, че договорът струва.

Чисто плащане според потреблението е лесният случай. Агентите са консумирали 100 000 извиквания през септември по вашата обявена ставка; приходът за септември е 100 000 по ставката, дори ако фактурата не бъде платена до октомври. Запишете вземане, когато фактурирате, приход, когато е настъпило използването. Ако искате пълното третиране на измерване на токени и използване съгласно ASC 606, нашите ръководства за таксуване на токени и признаване на приходи за SaaS според използването навлизат по-дълбоко.

Хибридна основа плюс превишение се разделя на две. Основният абонамент се признава равномерно през периода на обслужване — една тридесета на ден при месечен план — докато превишенията се признават, когато настъпи излишното използване. Дръжте ги в отделни приходни сметки. Смесването им скрива двете числа, които всъщност управляват бизнеса ви: предвидимия абонаментен MRR и накъсания приход от консумация.

Предплатените кредити създават задължение, а не приход. Когато клиент купи блок кредити, дебитирайте пари и кредитирайте отсрочен приход. Всеки път, когато използването изчерпи баланса, прехвърлете консумираната стойност от отсрочен приход към спечелен приход. Остатъкът, който клиентите никога не осребряват — breakage — има свое собствено правило: ако историята ви позволява надеждно да оцените неизползвания дял, признавате този очакван breakage постепенно пропорционално на действителното използване; ако сте твърде нови, за да го оцените, изчаквате, докато кредитите изтекат или осребряването стане малко вероятно, след което признавате остатъка. Новите MCP сървъри почти винаги попадат във втория лагер, така че не записвайте очакван breakage предсрочно, за да разкрасите даден месец.

Ценообразуването според резултата добавя времева особеност: приходът се признава, когато резултатът е постигнат и измерим, а не когато извикването започне. Ако вашият измервателен механизъм брои само успешните завършвания, записите ви за приходи трябва да следват същия брояч — измервателният механизъм и главната книга трябва да са съгласни какво е „продажба".

Два практични навика правят всичко това оцеляемо. Първо, водете отделна приходна сметка или таг за всеки измервателен механизъм (инструменти на извикване, обем данни, сесии, превишения), така че проблем с маржа в един инструмент да не се скрие вътре в смесен тотал. Второ, наложете прекъсване в края на месеца: използване с времеви печат през септември принадлежи на септември, дори ако фактурата се финализира на 2 октомври. Pipeline-и за измерване със закъснения на партиди правят грешките при прекъсването най-честото неправилно отчитане в бизнесите, базирани на използване.

Страната на разходите: какво всъщност струва един MCP сървър​

Приход на извикване на инструмент не означава нищо без разход на извикване на инструмент. Изградете цената на продадените стоки отдолу нагоре:

• Изчисления и хостинг. Сървърите, контейнерите или serverless извикванията, изпълняващи вашите инструменти, плюс изходящата честотна лента за методите с тежък полезен товар.
• Последващи API и разходи за модели. Всяко извикване на LLM, справка за вграждане, заявка за търсене или удар в API на трета страна, които вашите инструменти правят от името на клиента. Ако вашият инструмент за обобщаване извиква доставчик на модели на документ, този passthrough е най-големият ви променлив разход и трябва да се проследява на инструмент, а не като месечна обща сума.
• Разходи за данни и лицензи. Роялтита или такси на заявка за патентовани данни, които вашият сървър излага.
• Дял от приходите на маркетплейса. Делът на платформата от продажбите в маркетплейса е разход за продажби (или намаление на нетното изплащане — изберете едно третиране и се придържайте към него), никога приспадане, скрито вътре в приходите.
• Обработка на плащания. Такси за карти при абонаментно таксуване, такси за шлюзове при фактури, мрежови такси при сетълмент в стейбълкойн. В мащаба на микроплащанията тези хапят: фиксирана такса на транзакция може да надвиши маржа на извикване на инструмент за под един цент, което е точно причината протоколите за плащания между агенти да се спрат на релси с ниски такси.

Направете изчислението на единица на инструмент, преди да го ценообразувате. Да предположим, че вашият инструмент за справка в каталог ви струва $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. Продажбите през маркетплейс може да са покрити. Когато маркетплейсът се квалифицира като facilitator на маркетплейс, той събира и внася върху вашите продажби чрез него. Директните продажби от собствения ви сайт или собствения ви x402 endpoint са изцяло ваша отговорност.
3. Автоматизирайте събирането рано. Данъчен двигател (Stripe Tax и неговите конкуренти), включен в касата, струва много по-малко от регистриране, подаване и внасяне в дузина щати на ръка — и поддържа доказателството за местоположението на клиента, което одиторите искат.
4. Следете календара. С датата на влизане в сила на Калифорния през 2027 г. и подобни разширения, движещи се през други законодателни органи, позицията „твърде малки сме, за да се тревожим" изтича бързо.

Изплащания от маркетплейси и данъчни формуляри​

Ако част от приходите ви пристигат като изплащане от маркетплейс, отчитайте ги както разработчиците на магазини за приложения: запишете брутната продажба като приход и дела на платформата като разход. Вашият 1099-K (или 1099-NEC, в зависимост от класификацията на платформата) ще отчете брутната цифра и IRS сверява това число с вашата декларация — отчитането само на нетния депозит е начинът, по който започват известията за недодеклариране. Сверявайте брутните извлечения за изплащане с нетните банкови депозити всеки месец и пазете тарифата с таксите, която обяснява разликата.

Внимавайте също за времевата разлика: датата на изплащане от платформата не е вашата дата на прихода. Приходът принадлежи на периода, когато агентите на крайния клиент са консумирали вашите инструменти, дори ако маркетплейсът преведе две седмици по-късно. За директните продажби важи същият принцип — периодът на използване управлява, датата на сетълмент не.

Контролен списък в края на месеца за оператори на MCP​

Затваряйте книгите си по същия начин всеки месец и крайните случаи спират да се натрупват:

1. Извлечете измереното използване на клиент на измервателен механизъм и го свържете с фактурирания приход от използване. Разследвайте всяка разлика над вашата базова линия за безплатен план и опрощаване на неуспехи.
2. Разделете хибридните фактури в приходни сметки за основа (равномерна) и превишение (според консумацията).
3. Извадете изчерпванията на предплатени кредити от отсрочения приход; прегледайте остаряващите салда на кредити за третиране на breakage.
4. Осчетоводете последващите API, хостинг и разходи за данни на инструмент; преизчислете брутния марж на измервателен механизъм.
5. Сверете брутните извлечения от маркетплейси с нетните депозити; архивирайте извлеченията с месечните записи.
6. Запишете постъпленията в стейбълкойн по справедлива пазарна стойност и проследете данъчната основа през конверсията.
7. Прегледайте тоталите за местоположение на клиента спрямо щатските прагове за нексус; потвърдете събирането на данък, където се изисква.
8. Запазете суровия експорт на използването с месечния пакет за приключване — това е първичният документ, който бъдещото ви аз (или одитор) ще поиска.

Опростете финансовото си управление​

Измерени приходи, отсрочени салда по кредити, passthrough API разходи и облагаемост в петдесет щата са много движещи се части за страничен проект, започнал като weekend MCP сървър. Beancount.io ви дава счетоводство на обикновен текст с пълна прозрачност и контрол върху финансовите ви данни — всяка фактура за използване, изчерпване на кредит и такса за маркетплейс, записани като версионирани, готови за AI транзакции, които наистина можете да одитирате. Започнете безплатно и поддържайте книгите на вашата икономика от агенти толкова програмируеми, колкото е и вашият сървър.