Сключихте пет годишни сделки през март и $60 000 влязоха в сметката ви в Stripe. Таблото ви сияе, банковият ви баланс изглежда героично — а счетоводителят ви току-що ви каза, че приходите за март са $5 000. Никой не греши. Гледате две различни числа, които просто живеят в една и съща сметка в Stripe: парите, които сте събрали, и приходите, които действително сте спечелили. Докато не съгласувате двете, всяко изплащане, което Stripe ви изпраща, е загадка, която счетоводството ви трябва да реши.
Това ръководство показва как SaaS компаниите, които фактурират годишно, но признават приходите месечно, осчетоводяват изплащанията на Stripe без двойно отчитане на приходите, без изопачаване на отложените приходи и без да се подвеждат по метриката, която скрива цялата разлика.
Защо изплащанията на Stripe са грешната отправна точка за приходите
Едно изплащане на Stripe изглежда като приход. Пристига в банковата ви сметка като един депозит, има дата и се усеща като печалбата за месеца. Не е нито едно от тези неща. Изплащането е нетно разплащане: брутни такси минус такси за обработка, минус възстановявания, минус удръжки за спорове, обединени по графика за изплащания на Stripe, а не по вашия.
Това създава две отделни изкривявания, ако осчетоводите изплащанията като приходи.
Първо, подценявате приходите. Ако клиент е платил $12 000 за годишен план, Stripe задържа приблизително $348 плюс 30 цента и изплаща остатъка. Осчетоводяването на изплащането записва нетната сума като вашите продажби и заравя таксата там, където никога не можете да я анализирате — или да я приспаднете чисто.
Второ, и много по-опасно при годишното фактуриране, изопачавате времето. Пълните $12 000 пристигат в едно изплащане през януари, но съгласно принципа на начисляване (accrual accounting) ги спечелвате по $1 000 на месец, докато предоставяте услугата. Осчетоводете изплащането като приход за януари и януари изглежда впечатляващо, докато от февруари до декември изглеждат мъртви, въпреки че бизнесът е правил абсолютно същото всеки месец.
Решението е да третирате изплащането като това, което е — паричен превод — и да признавате приходите на напълно отделна писта, водена от договорите ви, а не от депозитите ви.
Трите числа, които основателите объркват: Bookings, Billings и приходи
Всяко съгласуване при годишно фактуриране започва с разграничаването на три числа:
- Bookings (сключени сделки) са общата стойност на подписаните договори. Клиент подписва годишен договор за $12 000 през януари: $12 000 в bookings за януари. Booking-ът е ангажимент, не пари и не печалба.
- Billings (фактурирани суми) са това, което фактурирате и събирате. Ако договорът се фактурира годишно предварително, billings за януари са $12 000. Ако се фактурира месечно, billings за януари са $1 000, въпреки че booking-ът е бил $12 000.
- Приходи са това, което сте спечелили чрез предоставяне на услугата. Един месец от дванадесетмесечен договор печели една дванадесета: $1 000 приходи за януари и в двата случая.
Разликата между billings и приходи е отложен приход (наричан още неспечелен приход), пасив в баланса ви, представляващ услуга, която все още дължите. Съберете $12 000 през януари и признайте $1 000, и пренасяте $11 000 отложен приход в февруари. Този пасив не е проблем — той е доказателството, че счетоводството ви е честно. Той се разгръща с $1 000 всеки месец, докато договорът приключи.
Казано просто: bookings ви казват как се справят продажбите, billings ви казват как се справят парите, а приходите ви казват как действително се е представил бизнесът. Съгласуването се разпада в момента, в който позволите на едно от тях да замести друго.
Изградете графика на отложените приходи, който движи месечното признаване
Графикът на отложените приходи е двигателят на целия процес. Това е проста таблица по договори — клиент, начало на договора, срок, обща стойност на договора, месечна сума за признаване, признати приходи до момента, остатъчен отложен баланс — и е единственият документ, който трябва някога да задейства счетоводна статия за приходи.
За годишен план от $12 000, започващ на 1 януари, статиите изглеждат така:
On collection (January):
Dr Stripe clearing $12,000
Cr Deferred revenue $12,000
Each month, January–December:
Dr Deferred revenue $1,000
Cr Subscription revenue $1,000Забележете какво липсва: изплащането не се появява никъде в статиите за приходи. Събирането на пари кредитира отложен приход, пасив. Приходът се ражда по-късно, месец по месец, от графика.
Две дисциплинарни точки правят или развалят графика. Първо, всеки нов годишен договор, подновяване и разширяване трябва да попадне в него през месеца, в който започва — договор, липсващ в графика, е приход, който никога няма да бъде признат. Второ, съгласувайте графика с главната книга всеки месец: начален отложен баланс, плюс нови billings, минус признати приходи, трябва да е равно на крайния отложен баланс. Ако не е, нещо е заобиколило графика — обикновено възстановяване, промяна в средата на цикъла или изплащане, което някой е осчетоводил директно като приход.
Съгласувайте самото изплащане чрез клирингова сметка
Докато графикът се грижи за времето на приходите, все още трябва да осчетоводите парите, движещи се през Stripe. Чистият метод е клирингова сметка на Stripe — активна сметка, която представлява „пари, намиращи се вътре в Stripe“.
Всяко събитие в Stripe се записва в клиринговата сметка по брутна стойност:
Customer charged $1,000:
Dr Stripe clearing $1,000
Cr Deferred revenue $1,000
Stripe fee of $29.30 on that charge:
Dr Processing fees $29.30
Cr Stripe clearing $29.30
Payout of $970.70 lands in your bank:
Dr Bank checking $970.70
Cr Stripe clearing $970.70Възстановяванията и удръжките за спорове се записват по същия начин, но в обратна посока. Когато изплащането се осребри, клиринговата сметка се нулира за позициите на това изплащане — което точно я прави инструмент за съгласуване, а не просто счетоводна конвенция. Ненулев остатък означава, че такса, възстановяване или корекция са останали неотчетени.
За да обвържете всяко изплащане със съдържанието му, използвайте отчета за съгласуване на изплащанията на Stripe, който детайлизира всяка такса, възстановяване, такса за обработка и корекция в рамките на изплащане, и проверете дали брутната сума минус таксите минус възстановяванията е равна на банковия депозит. Правете това изплащане по изплащане, а не месец по месец: изплащанията постоянно пресичат края на месеца и месечното групиране е откъдето идват загадките „банката никога не съвпада със Stripe“. Ако обемът ви е малък, седмичен ритъм с клиринговата сметка хваща малките несъответствия, докато все още са лесни за проследяване.
Корекции: промените в средата на цикъла, които развалят графиците
Годишните договори рядко стоят неподвижни дванадесет месеца и всяка промяна изисква коригираща статия спрямо отложения график:
- Ъпгрейди и разширяване на места добавят към остатъчния отложен баланс. Клиент, който се ъпгрейдне от $12 000 на $18 000 годишно с шест месеца остатък, добавя приблизително $3 000 нов отложен приход (шест месеца при допълнителните $500 на месец), върху неразпознатия остатък.
- Даунгрейди го намаляват. Намалете плана с шест месеца остатък и премествате разликата извън отложените приходи — често като кредит към бъдещи фактури вместо парично възстановяване, което все още изисква счетоводна статия, въпреки че не се движат пари.
- Пропорционалните изчисления са механизмът: Stripe обработва промените в абонамента с кредити за неизползвано време, а тези кредити ви казват точно колко отложен приход да преместите между стария и новия план.
- Анулирания с възстановяване на предплатено време намаляват отложените приходи, никога приходите за текущия месец. Възстановяването на шест неизползвани месеца от план за $12 000 е дебит от $6 000 към отложените приходи — осчетоводяването му срещу приходите за този месец би подценило месец, който не е направил нищо лошо.
- Неуспешни плащания при годишни подновявания трябва да се наблюдават в обратната посока: не са събрани пари означава няма нов отложен баланс, така че графикът не трябва да продължава да признава приходи за договор, който е спрял да бъде финансиран.
Практическото правило: никаква промяна в абонамента в Stripe без съответстващо обновяване на графика през същия месец. Екипите, които позволяват на двете да се разминат, прекарват всяко тримесечие в реконструиране на случилото се от PDF-и на фактури.
SaaS метриката, която скрива всичко: MRR на таблото не е приход
Ето капана, който цялата тази подредба прикрива. Таблото ви в Stripe показва MRR, който се изкачва красиво — годишните планове се преобразуват в месечни еквиваленти, ъпгрейдите добавят разширяващ се MRR моментално и графиката се накланя нагоре и надясно. Основателите съвсем естествено започват да мислят за това число като „това, което печелим на месец“.
Не е така. MRR е нормализирана метрика за темп на растеж: месечната стойност на активните абонаменти, ако нищо не се промени. Признатият приход е това, което действително сте спечелили съгласно принципа на начисляване този месец. Те се разминават постоянно — годишните предплащания, събрани този месец, едва ли са приходите за този месец, разширяващият се MRR от ъпгрейд в средата на месеца е само половин месец печалба, а нито едно от числата на таблото не знае за отложения ви график, възстановяванията ви или корекциите ви.
Разминаването е невидимо, докато не ухапе. Облагаемият доход следва признатия приход, а не MRR, така че едно тримесечие с огромни bookings може да произведе данъчна сметка, която изненадва основатели, които са гледали таблото. А приобретателите и кредиторите правят дю дилиджънс върху GAAP приходите, не върху MRR — всеки долар „приход“, който всъщност е бил непризнати billings, се коригира извън разговора за оценката.
Пазете и двете числа, но никога не позволявайте на едното да върши работата на другото. Полезна месечна проверка за здравия разум: признатият приход за месеца, плюс промяната в отложения ви баланс, трябва да се съгласува обратно с billings. Ако MRR казва, че сте растели, а това уравнение казва друго, вярвайте на уравнението.
Вашият контролен списък за месечното приключване за Stripe SaaS
Изпълнявайте това всеки месец и частите ще останат свързани:
- Обвържете изплащанията с банката. Експортирайте данните за съгласуване на изплащанията, потвърдете, че брутната сума минус таксите минус възстановяванията е равна на всеки депозит, и осчетоводете прехвърлянето през клиринговата сметка.
- Нулирайте клиринговата сметка за всяко изплащане. Всеки остатъчен баланс е неотчетена такса, възстановяване, спор или корекция — намерете го преди края на месеца.
- Развийте отложения график. Добавете новите договори и подновявания, осчетоводете статиите за признаване за месеца и потвърдете, че началният баланс плюс billings минус признатите приходи е равен на крайния баланс.
- Коригирайте промените в средата на цикъла. Съпоставете всеки ъпгрейд, даунгрейд, пропорционално изчисление, анулиране и възстановяване в Stripe със съответната корекция в графика.
- Съгласувайте MRR с признатите приходи. Обяснете разликата между темпа на растеж на таблото и спечелените приходи; проучете всичко, което не можете да обясните с едно изречение.
- Преглеждайте таксите и възстановяванията отделно. Брутните приходи, таксите за обработка и възстановяванията разказват всеки своя собствена история — нетното им обединяване скрива и трите.
Правено последователно, това превръща края на месеца от съдебно-медицинско разследване в рутина: страната на изплащанията доказва, че парите ви са пълни, а страната на графика доказва, че приходите ви са спечелени.
Поддържайте SaaS приходите си готови за инвеститори
С нарастването на годишното фактуриране поддържането на признатите приходи, отложените баланси и парите в Stripe свързани всеки месец е това, което прави числата ви достоверни за счетоводители, данъчни власти и бъдещи приобретатели. Beancount.io предоставя счетоводство на обикновен текст, което ви дава пълна прозрачност и контрол върху финансовите ви данни — без черни кутии, без обвързване с доставчик. Започнете безплатно и вижте защо разработчиците и финансовите специалисти преминават към счетоводство на обикновен текст.
