ASC 606 за SaaS стартъпи: Моделът от пет стъпки, приходи за бъдещи периоди и грешките, които провалят одитите

Основател събира 120 000 долара под формата на годишни предплащания в последния ден на декември и ги отчита изцяло като приходи за четвъртото тримесечие (Q4). Бордът празнува. Шест месеца по-късно, по време на проверката (due diligence) за Серия А, одиторската фирма преизчислява годината, прехвърля 90 000 долара от приходите обратно в графа „отложени приходи“ и рундът се забавя с два месеца. Сделката все пак се затваря — но при по-ниска оценка от първоначалния документ с основни условия (term sheet).

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

Ако управлявате бизнес с абонаменти, ето какво всъщност изисква ASC 606, петстепенният модел, през който вашият одитор ще премине ред по ред, и повтарящите се грешки, които тихо разрушават чистите данни за приходите.

Защо ASC 606 съществува и защо основателите на SaaS трябва да ги е грижа

Преди ASC 606, софтуерните и SaaS компаниите следваха сбор от специфични за индустрията правила за приходите, които водеха до коренно различни резултати за компании, продаващи сходни продукти. Два SaaS бизнеса с идентични договори можеха законно да отчитат много различни числа за приходите в едно и също тримесечие, в зависимост от това кои наследени насоки прилагаха техните счетоводители.

ASC 606 — издаден от Съвета за финансови счетоводни стандарти (FASB) и влязъл в сила за частни компании от 2019 г. — замени този „кръпеж“ с една универсална рамка. Основният принцип е прост: признавайте приходите, докато прехвърляте контрола върху стока или услуга на клиента, в размер, който отразява това, което очаквате да получите в замяна.

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

Три причини, поради които това е важно дори преди да имате одитор:

1. Инвеститорите четат отчетите по GAAP. Опитните инвеститори моделират вашата икономика на единица продукт (unit economics) въз основа на вашите финансови отчети. Ако вашите данни за MRR, ARR и брутен марж идват от политика за признаване, която не е по GAAP, ще прекарате проверката в тяхното преструктуриране.
2. Преизчисленията плашат бордовете. Чистата политика за приходите от първата година е много по-евтина от преструктурирането на тригодишна история по време на Серия А.
3. Данъците и счетоводството се различават. Книгите на касова основа може да работят за ранно подаване на данъци, но в крайна сметка ще ви трябват финансови отчети на база текущо начисляване (accrual-basis). Започването с коректно начисляване от първия ден предотвратява болезнени ретроактивни почиствания.

Петстепенният модел, преведен за SaaS

ASC 606 предписва точно пет стъпки за признаване на приходи. Всеки договор, колкото и прост да е той, преминава през тази рамка. Ето как всяка стъпка се отнася до реален SaaS договор.

Стъпка 1: Идентифициране на договора с клиента

Договорът по ASC 606 трябва да има одобрение от двете страни, идентифицируеми права и задължения, дефинирани условия на плащане, търговска същност и вероятна събираемост на възнаграждението. За повечето SaaS бизнеси подписан формуляр за поръчка, електронно споразумение с кликване или рамков договор за услуги плюс задание за работа (statement of work) са достатъчни.

Внимавайте за два капана:

• Безплатни пробни периоди и пилотни проекти. 30-дневен безплатен пробен период обикновено не е договор съгласно ASC 606, тъй като клиентът няма задължение да плаща. Договорът започва, когато започнат платените условия.
• Автоматични подновявания. Ако вашият клиент е на автоматично подновяване месец за месец, третирайте всеки период на подновяване като съответния срок на договора, освен ако не съществува приложима неустойка за анулиране.

Стъпка 2: Идентифициране на задълженията за изпълнение

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

За типична SaaS сделка, общите задължения за изпълнение включват:

• Основният SaaS абонамент (достъп до платформата)
• Услуги по внедряване, въвеждане (onboarding) или миграция на данни
• Обучение, премиум поддръжка или услуги за клиентски успех
• Интеграции по поръчка или дейности по разработка
• Еднократни такси за настройка или активация

Трудната част е да се прецени дали всяко обещание е наистина отделно. Дейностите по настройка, които само позволяват на клиента достъп до платформата — подготвяне на инстанция, генериране на идентификационни данни, основна конфигурация — обикновено не са отделни. Те се консумират при предоставянето на самия абонамент и всяка свързана такса се отлага и признава през периода на абонамента (или очаквания живот на клиента, ако е по-дълъг).

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

Стъпка 3: Определяне на цената на трансакцията

Цената на трансакцията е възнаграждението, на което очаквате да имате право в замяна на прехвърлянето на обещаните стоки или услуги. За фиксиран годишен абонамент от 24 000 щ.д. без променливи компоненти, това е лесно за определяне.

Става по-трудно, когато договорът съдържа:

• Отстъпки и кредити (трябва да бъдат разпределени между задълженията за изпълнение)
• Променливо възнаграждение като такси на база потребление, стъпаловидно ценообразуване или отстъпки за обем
• Права на възстановяване на суми или кредити за ниво на обслужване, които ефективно ограничават възнаграждението
• Значителни компоненти на финансиране при многогодишни предплатени сделки

За променливо възнаграждение ASC 606 изисква да оцените сумата, като използвате или метода на очакваната стойност (среднопретеглена вероятност от възможните резултати), или метода на най-вероятната сума (единственият най-вероятен резултат). Също така трябва да приложите ограничение — включвайте само суми, за които е силно вероятно да не доведат до значително сторниране на приходи на по-късен етап.

За ценообразуване, базирано изцяло на потреблението, където фактурите съответстват директно на предоставената стойност за всеки период, стандартът предлага практическо облекчение: признаване на приходите в размера на фактурираната сума. Повечето софтуерни услуги (SaaS) с таксуване на база потребление попадат удобно в това облекчение.

Стъпка 4: Разпределяне на цената на трансакцията към задълженията за изпълнение

Ако вашият договор има само едно задължение за изпълнение, пропускате тази стъпка. Ако има повече от едно, разпределяте общата цена на трансакцията към всяко задължение за изпълнение пропорционално на неговата индивидуална продажна цена (SSP) — сумата, която бихте таксували за този артикул, ако се продава отделно.

Примерен сценарий: Клиент подписва едногодишен договор за:

• 20 000 щ.д. годишен абонамент
• 5 000 щ.д. проект за внедряване
• Обща стойност на договора: 25 000 щ.д.

Ако продавате абонамента самостоятелно за 20 000 щ.д. и внедряването самостоятелно за 5 000 щ.д., индивидуалните продажни цени (SSP) съвпадат с договорените цени и не е необходимо преразпределяне. Приходът от внедряването в размер на 5 000 щ.д. се признава, когато внедряването приключи; приходът от абонамента от 20 000 щ.д. се признава по 1 666,67 щ.д. на месец за дванадесетмесечния период.

Но да предположим, че предлагате същия договор в пакет за фиксираната сума от 22 000 щ.д., за да спечелите сделката. Сега имате отстъпка от 3 000 щ.д. за разпределяне. Използвайки относителната SSP, разпределяте отстъпката пропорционално: 2 400 щ.д. към абонамента и 600 щ.д. към внедряването. Внедряването се признава за 4 400 щ.д. при завършване; абонаментът се признава за 17 600 щ.д., разпределени за дванадесет месеца.

Ако не можете директно да наблюдавате индивидуалните продажни цени, защото никога не продавате артикулите отделно, ASC 606 ви позволява да ги оцените чрез подходи като коригирана пазарна оценка, очаквани разходи плюс марж или остатъчен метод (разрешен само в тесни обстоятелства).

Стъпка 5: Признаване на приходите при (или след като) изпълнение на задължението

Накрая, вие действително осчетоводявате прихода. Спусъкът е прехвърлянето на контрола — когато клиентът получи способността да управлява употребата и да извлича по същество всички оставащи ползи от стоката или услугата.

За SaaS абонамент контролът се прехвърля непрекъснато, докато клиентът консумира услугата. Следователно приходът се признава във времето, обикновено чрез линейния метод за срока на абонамента, освен ако друг модел не отразява по-точно предоставянето на услугата.

За услуги по внедряване или обучение контролът се прехвърля или във времето (според положения труд), или в определен момент (когато крайният резултат е приет), в зависимост от естеството на работата.

Тук се появява механиката на приходите за бъдещи периоди във вашия баланс. Паричните средства, събрани за услуги, които още не са предоставени, стоят в пасивна сметка, наречена приходи за бъдещи периоди (или договорно задължение съгласно терминологията на ASC 606). Всеки месец рекласифицирате вече спечелената част като признат приход.

Графикът на приходите за бъдещи периоди — разшифрован

Графикът на приходите за бъдещи периоди (deferred revenue schedule) е документът, който вашият одитор ще проверява най-подробно. Това е и документът, който повечето SaaS компании в ранен етап поддържат в сложни електронни таблици, на които никой не се доверява напълно.

Една чиста справка показва за всеки активен договор:

• Дата на започване и дата на завършване на договора
• Общата цена на трансакцията, разпределена към всяко задължение за изпълнение
• Моделът на признаване (линеен месечен, в определен момент, процент на завършеност)
• Натрупаната призната сума до момента
• Остатъчния баланс за бъдещи периоди

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

Три правила, които поддържат графика надежден:

1. Равнявайте месечно, а не тримесечно. Грешките се натрупват. Улавяйте ги в месеца, в който възникват.
2. Свързвайте графика с договорите, а не с фактурите. Фактурите са събития по таксуване; договорите дефинират задължението за признаване. Винаги използвайте договора като източник на истината.
3. Документирайте промените незабавно. Надграждания, намаляване на пакети, анулирания и удължавания на договори изискват специфично счетоводно третиране. Промяна, която удвоява обхвата и срока, обикновено се третира като нов договор; промяна, която се добавя към съществуващ договор, обикновено е продължение. Документирайте кое третиране сте избрали и защо.

Поддържането на точни финансови записи от първия ден е от съществено значение — графикът на приходите за бъдещи периоди е невъзможно да бъде възстановен впоследствие, ако вашата история на трансакциите е разхвърляна. Plain-text accounting прави този вид дисциплина естествена, защото всеки запис подлежи на одит, контрол на версиите и преглед чрез сравняване на разликите (diff).

Шестте грешки, които провалят одитите

По-долу са описани повтарящите се грешки, които се появяват в констатациите от одити на SaaS компании, оповестяванията за преизчисляване на отчети и докладите за забавяне на проверката (due diligence). Всяка една от тях е предотвратима с дисциплинирано счетоводство.

Грешка 1: Отчитане на годишното авансово плащане като приход в първия ден

Годишно авансово плащане в размер на $24,000 не е $24,000 приход. Това са $2,000 признат приход на месец и $24,000 паричен поток, влизащ в приходи за бъдещи периоди в деня на инкасирането. Това е най-често срещаната грешка сред SaaS компаниите с приходи под $10 млн. и е тази, която най-често води до преизчисляване на финансовите отчети.

Грешка 2: Признаване на стойността на многогодишен договор предварително

Тригодишен договор за $360,000 генерира $10,000 месечен приход в рамките на тридесет и шест месеца. Той не генерира $360,000 приход в годината, в която е подписан договорът, дори ако клиентът е предплатил цялата сума.

Грешка 3: Неправилно класифициране на услуги по внедряване

Много SaaS учредители отчитат приходите от внедряване при получаване на плащането или при пускане в експлоатация (go-live), без да проверят дали внедряването е отделно изпълнително задължение. Ако внедряването служи само за осигуряване на достъп до платформата, таксата се разсрочва за периода на абонамента — което обикновено означава много по-бавен модел на признаване, отколкото основателите очакват.

Грешка 4: Пропуск при отчитането на модификации по договорите

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

Грешка 5: Небрежни оценки на променливото възнаграждение

Компаниите с ценообразуване на база потребление често отчитат това, което пише във фактурата, без да прилагат теста за ограничение. Ако потреблението е силно променливо и клиентът има клаузи за минимален ангажимент или нива на обем, признаването трябва да отразява ограничена, очаквана стойност — а не максимално възможното фактуриране.

Грешка 6: Неадекватна документация

Когато одиторът попита „защо разпределихте $4,400 от отстъпката за внедряване?“, отговорът трябва да бъде писмено мемо с обективни SSP данни, а не „така ни се стори правилно“. Недостатъчната документация принуждава одитора да приеме консервативно третиране, което обикновено означава по-ниски признати приходи.

Изграждане на процес за приходи, готов за одит, от първия ден

Повечето SaaS компании в ранен етап чакат докато се нуждаят от одит — обикновено провокиран от Серия А — за да се заемат сериозно с ASC 606. Дотогава те реконструират две или три години история под натиска на крайни срокове. По-добър план за действие:

На етап "seed":

• Приемете счетоводство на база текущо начисляване още от първия си плащащ клиент.
• Поддържайте график за приходи за бъдещи периоди от първия ден, дори ако е само чиста електронна таблица.
• Документирайте писмена политика за признаване на приходите. Една страница е достатъчна.
• Маркирайте всеки договор с дата на започване, дата на приключване и модел на признаване.

Докато мащабирате към Серия А:

• Преместете графика за приходи за бъдещи периоди от електронните таблици в система, която се свързва с данните ви за фактуриране.
• Изградете ARR бридж, който се съпоставя с GAAP приходите всеки месец.
• Поискайте дипломиран експерт-счетоводител (CPA) да прегледа политиката ви за признаване на приходите и основните шаблони за договори.
• Направете „пробна проверка“ — представете си, че отговаряте на въпросите на одитор за вашите десет най-големи договора.

Преди набиране на капитал:

• Наемете услуга за преглед на качеството на печалбата или предодиторски преглед най-малко шестдесет дни преди стартирането на рунда. Рискът от преизчисляване на отчетите, открит преди проверката, е просто забележка; открит по време на проверката, той води до преоценка на сделката.

Поддържайте чисти записи на приходите си от първия ден

Чистото признаване на приходите започва с чисти счетоводни книги. Всеки договор с клиент, всяко авансово плащане, всяка модификация трябва да попаднат в система, на която можете да се доверите и която подлежи на одит. Beancount.io предоставя текстово базирано счетоводство, което ви дава пълна прозрачност и контрол на версиите върху вашите финансови данни — всеки запис е четим от човек, всяка промяна е проследима в git, а вашият график за приходи за бъдещи периоди никога не се разминава с основните транзакции. Започнете безплатно и изградете основа, готова за одит, преди първият инвеститор да я поиска.