Току-що сключихте най-голямата сделка в кратката история на компанията си: годишен ангажимент от $120 000 плюс $0,10 за всяко API извикване над включения лимит. Вашата система за фактуриране вече отчита потреблението, а очевидното счетоводно решение изглежда „да признаем прихода, когато клиентът го използва". Този инстинкт е правилен точно за половината от този договор — и достатъчно грешен за другата половина, за да си навлечете корекция от одитора в края на годината.
Ценообразуването на база потребление вече е стандартният начин, по който SaaS компаниите таксуват, а не екзотичното изключение: повече от 59% от SaaS бизнесите имат структура на база потребление през 2025 г., спрямо около 40% две години по-рано. Повечето от тези сделки не са чисто плащане според потреблението. Те са хибридни — фиксирана база, която купува отстъпка, с измервано надвишение отгоре. Съгласно ASC 606 този един подпис се разделя на два потока от приходи с противоположни правила за времето. Базата е фиксирано възнаграждение и се разпределя за срока на договора, независимо дали клиентът прави едно API извикване или нито едно. Надвишението е променливо възнаграждение и чака измервателя. Това ръководство обяснява защо, с осчетоводяванията, които го реализират.
Един договор, две третирания на приходите
Започнете със структурата, защото всичко останало следва от нея. Сделка „фиксирана база плюс надвишение" има три движещи се части:
- Фиксиран минимум. Клиентът плаща $120 000 за годината независимо от всичко. В замяна получава достъп до платформата плюс включен лимит — да речем, 1 милион API извиквания на месец — на ефективна цена, значително под каталожната.
- Измервател на надвишение. Потреблението над лимита се таксува по ставка за надвишение, обикновено месечно в края на периода. В нашия пример $0,10 за извикване.
- Един подпис, един срок. Обикновено дванадесет месеца, често фактурирани предварително или тримесечно, въпреки че услугата се доставя постепенно през годината.
ASC 606 прекарва този договор през своя модел от пет стъпки — идентифициране на договора, идентифициране на задълженията за изпълнение, определяне на цената на сделката, разпределянето ѝ, признаване на прихода при изпълнение на задълженията — и достига до разделено решение. Фиксираните $120 000 са фиксирана цена на сделката за услуга, доставяна непрекъснато през дванадесет месеца, така че се признават във времето, обикновено линейно по $10 000 на месец. Надвишението е променливо възнаграждение: неговият размер зависи от бъдещото потребление, затова се признава, когато потреблението възникне, или се оценява предварително само ако можете да преминете през умишлено висока летва, наречена ограничение. Същият клиент, същата фактура, два часовника.
Практическото следствие е незабавно. В бавен месец, когато клиентът изразходва само 400 000 извиквания, вие все още признавате пълните $10 000 приход от база — клиентът е купил година достъп и една дванадесета от нея за януари е доставена. В месец на пик при 1,5 милиона извиквания признавате $10 000 плюс 500 000 извиквания надвишение по $0,10, или $50 000 приход от потребление. Базата никога не спада с потреблението, а надвишението никога не се изглажда в месеци, в които нищо не се е случило.
Защо базата се признава линейно
Счетоводната логика за базата е по-спокойната половина на историята. Вашето задължение за изпълнение не е „1 милион API извиквания" — а това да сте в готовност да обслужвате клиента през целия месец, серия от отделни дневни или месечни периоди на услуга, които ASC 606 третира като изпълнени във времето. Правилната мярка за напредък е изминалото време, а най-простият точен модел е линейно: една дванадесета от ангажимента всеки месец.
Всеки голям доставчик на база потребление стига до същото място по тази половина. В 10-K на Datadog се казва, че за фиксирана договорна сума, разпределена пропорционално, приходът се признава пропорционално за срока на абонамента, считано от момента, в който платформата е предоставена. Alkami, която продава банков софтуер на база транзакции с месечни минимуми, го формулира още по-ясно: минималните транзакционни такси се признават на линейна база, докато таксите за транзакции над минимума се признават в месеца, в който транзакциите са обработени. Минимумите са за изминаването на времето; надвишенията са за измервателя.
Има един известен несъгласен, когото си струва да познавате, защото вашият одитор ще го направи. Snowflake признава прихода, когато клиентите потребяват изчисления, съхранение и трансфер — дори при многогодишни ангажименти за капацитет — на аргумента, че потреблението, а не времето, е моментът, в който стойността се прехвърля. Тази позиция е оповестена видно и защитена с факти, специфични за компанията. Освен ако не сте готови да напишете този меморандум и да го защитите при одит, признавайте базата линейно. Това е третирането, което одиторите очакват от SaaS компания в ранен етап, а отклоненията изискват писмена позиция, а не свиване на рамене.
Защо надвишенията чакат измервателя
Надвишенията са променливо възнаграждение, а ASC 606 третира променливото възнаграждение с подозрение. Можете да го включите в цената на сделката само до степента, в която е вероятно да не настъпи значително сторниране, когато несигурността се изясни — ограничението. За потребление, което вече се е случило и е измерено, не остава несигурност, така че признаването на приход от надвишение в месеца на потреблението винаги преминава летвата. Ето защо „признай го, когато го използват" е стандартът, който повечето SaaS компании избират, и този, който одиторите оспорват най-малко.
Алтернативата е да се оцени общото надвишение за годината предварително и да се признава линейно заедно с базата. New Relic прави точно това: проектира потреблението над ангажимента от исторически данни плюс прогнозни фактори, ограничава оценката до това, на което очаква да има право, и признава тази сума за срока. Това е съответстващо и води до по-гладък приход — но забележете какво изисква. Нужна ви е достатъчно история, за да проектирате достоверно, документиран метод за оценка, анализ на ограничението и процес за коригиране, когато фактическите стойности се разминават. За стартъп с шест месеца данни от измерване и един голям клиент, чието потребление се удвоява всяко тримесечие, този файл още не съществува. Признавайте надвишенията, когато възникнат, докато историята ви не ви даде правото да оценявате.
Още един елемент от стандарта тихо подкрепя простия подход. Тъй като вашият абонамент е серия от отделни месечни периоди на услуга, таксите за потребление, свързани с конкретен месец, могат да бъдат разпределени изцяло към този месец съгласно изключението за разпределяне на променливо възнаграждение. С прости думи: не е нужно да прогнозирате годината, за да осчетоводите януари правилно. Показанието на измервателя за януари принадлежи на януари, точка.
Последният капан за времето е да се бърка фактурирането с признаването. Ако фактурирате ангажимента от $120 000 предварително през януари, приходът за януари все още е $10 000 — останалите $110 000 стоят в отсрочен приход. Обратно, потреблението над лимита, доставено през януари, но фактурирано едва при фактурирането през февруари, все още е приход за януари; в края на месеца го начислявате като нефактуриран или начислен приход. Паричните средства и фактурите са събития по фактурирането. Изминаването на времето и измервателят са събития по признаването на приход. Списъкът ви за приключване трябва да държи двете отделно.
Осчетоводяванията, с реални числа
Ето примерната сделка в счетоводството. Acme подписва на 5 януари: годишен ангажимент от $120 000, 1 милион включени извиквания на месец, $0,10 за извикване над лимита. Потреблението за януари е 1 021 000 извиквания — 21 000 над лимита, или $2 100. Февруари е спокоен с 800 000 извиквания, така че няма надвишение.
2026-01-05 * "Invoice Acme annual platform commit"
Assets:Receivable:Acme 120000.00 USD
Liabilities:Deferred-Revenue:Acme -120000.00 USD
2026-01-31 * "January: release 1/12 of commit"
Liabilities:Deferred-Revenue:Acme 10000.00 USD
Income:Subscription-Revenue -10000.00 USD
2026-01-31 * "January overage: 21000 calls over allowance at 0.10"
Assets:Receivable:Acme 2100.00 USD
Income:Usage-Revenue -2100.00 USD
2026-02-28 * "February: release 1/12 of commit, usage under allowance"
Liabilities:Deferred-Revenue:Acme 10000.00 USD
Income:Subscription-Revenue -10000.00 USDПрочетете историята, която разказва главната книга. Януари признава $12 100 при фактурирани $120 000 — разликата от $110 000 е отсрочен приход, задължение за все още дължима услуга, а не печалба. Февруари признава фиксирани $10 000, въпреки че потреблението спада с една пета, защото базата плаща за достъп, а не за извиквания. А записът за надвишение съществува само в месеците, когато измервателят превишава лимита. Ако вашата сметка за приходи не показва точно тази форма — фиксирана база плюс пиково потребление — нещо по-нагоре по веригата е свързано грешно.
Обърнете внимание на отделните сметки за приходи. Разделянето на абонаментната база от прихода от потребление не е козметично: то е това, което ви позволява да отчитате нетно задържане на приходите, степен на прикачване на потреблението и покритие на ангажимента от главната книга, а не от електронна таблица. Настройте и двете сметки в първия ден на договора, а не по време на първия си одит.
Четири грешки, които привличат корекция от одитора
Осчетоводяване на ангажимента като приход при подписване. Фактурата от $120 000 изглежда като продажба и търговските екипи ще ви кажат, че е сключена през януари. Но вие сте доставили един месец от дванадесетмесечна услуга. Всичко над $10 000 за януари е отсрочен приход. Компаниите, които осчетоводяват пълния ангажимент предварително, не само изкривяват един месец — те заемат единадесет месеца бъдещ приход и го връщат като смущаващо преизчисление.
Изглаждане на неравномерните надвишения през спокойните месеци. Усредняването на надвишението от $50 000 в пиков месец в околните тримесечия изглежда подредено и е грешно, освен ако не сте оценили общата сума предварително, документирали сте анализа на ограничението и не я коригирате. Без този файл показанието на измервателя за всеки месец остава в собствения си месец. Одиторите проверяват това, като сравняват признатия приход от потребление с измереното потребление по периоди; изгладена линия срещу пиков измервател е най-бързият начин да се провалите на теста.
Оставяне на календара за фактуриране да управлява признаването. Предварителното фактуриране за годината изкушава екипите да признават на дати на фактуриране. Тримесечните коригиращи фактури ги изкушават да признават надвишения само когато са фактурирани. И двете посоки нарушават правилото: базата следва календара на услугата, надвишението следва календара на потреблението, а нито едно от двете не следва календара на фактурирането. Начислението в края на месеца за измерено, но нефактурирано потребление е записът, който липсва на повечето млади финансови екипи — приключвайте книгите няколко дни след края на месеца специално за да е приключил измервателят.
Забравяне на неизползвания ангажимент. Ако Acme завърши годината с 2 милиона извиквания под общия си лимит и договорът казва „използвай или загуби", този недостиг не е автоматично бонус приход през декември. Неизползваните предплатени суми — разпад — се признават само съгласно дисциплинирана политика: пропорционално на потреблението при упражняване на правата или когато вероятността за упражняване стане отдалечена. Напишете политиката преди декември, прилагайте я последователно и я оповестете. Откриването на разпад по време на одита е начинът едно чисто мнение да се забави.
Вашият списък за приключване на месеца за ангажимент плюс надвишение
Превърнете правилата по-горе в повтарящо се приключване. Всеки месец, в този ред:
- Изтеглете експорта от измервателя и го свържете с машината за тарифиране. Оцененото потребление по клиент трябва да се равнява на входните данни за фактуриране от системата за фактуриране до последното извикване. Разследвайте разликите, преди да осчетоводите каквото и да е — прекъсване на измерването е проблем с пълнотата на приходите, а не IT тикет.
- Освободете базата. Една дванадесета от всеки активен ангажимент от отсрочен приход в абонаментен приход. Водопадът на отсрочения приход, който прехвърля началното салдо плюс новите фактури минус освобождаванията към крайното салдо, е контролът, който одиторите искат първо; прегледайте го в Fava, филтриран до вашите сметки за отсрочен приход, и грешките във формата изпъкват.
- Осчетоводете надвишенията от измервателя, след което начислете нефактурираната опашка. Фактурираното надвишение дебитира вземания; потреблението, измерено след последното фактуриране, дебитира начислен приход. И двете кредитират приход от потребление в месеца на потреблението.
- Коригирайте всякакви оценки. Ако оценявате надвишенията пропорционално, сравнете признатото от началото на годината с измереното от началото на годината и осчетоводете доначисляването. Ако признавате при възникване, тази стъпка е проверка за разумност от пет минути вместо това — още една причина стартъпите да започнат оттам.
- Прегледайте покритието на ангажимента. За всеки клиент сравнете стойността на кумулативното потребление с кумулативната освободена база. Клиент, който изразходва много над ангажимента си, е разговор за разширяване; такъв, който е много под него, е риск за подновяване и евентуално бъдещ запис за разпад. Във всеки случай финансите трябва да го забележат преди продажбите.
Започнете с експорта на измервателя за този месец: свържете го с това, което вашата главна книга е признала, разделено на база и потребление, и потвърдете, че двата часовника работят независимо. Ако е така, вашето счетоводство за ангажимент плюс надвишение вече е пред повечето компании с вашия размер — и следващият ви одит току-що стана по-кратък.
