Как да изградим мащабируема система за фактуриране на SaaS услуги

1. Защо фактурирането на SaaS услуги се различава от традиционното фактуриране

Много бизнеси издават фактури за отделни продажби или завършени услуги.

SaaS бизнесите обаче често работят с продължаващи търговски отношения.

Един клиент може да се абонира за услуга за 49 евро на месец, да премине към план за 99 евро, да купи допълнителни възможности и по-късно да избере годишно таксуване.

Всяка промяна може да повлияе на начисляваните суми и на това какво трябва да се документира.

Често срещаните сценарии при SaaS таксуването включват:

• Месечни и годишни абонаменти.
• Безплатни пробни периоди, които преминават в платени планове.
• Преминаване към по-висок или по-нисък план по време на активен период на таксуване.
• Такси според използването или потреблението.
• Отстъпки, промоционални периоди и суми за приспадане.
• Няколко абонамента в един клиентски акаунт.
• Прекратяване на абонаменти и възстановяване на суми.

Не всяко събитие при таксуването изисква нова фактура, а приложимите изисквания зависят от трансакцията и юрисдикцията.

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

Предизвикателството нараства, когато тези събития възникват автоматично, вместо чрез ръчни административни процеси.

2. Отделете управлението на абонаменти от фактурирането

Едно от най-важните архитектурни решения е разграничаването на абонамента на клиента от фактурите, издадени за него.

Абонаментът представлява търговска договореност.

Той може да определя плана, честотата на таксуване, цената, включените услуги, датата на подновяване и текущия статус на абонамента.

Фактурата, от своя страна, е финансов документ, който отразява конкретна начислена сума или трансакция.

Да разгледаме клиент с месечен план за 100 евро.

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

Ако клиентът премине към по-скъп план, данните за абонамента могат да се променят веднага, докато свързаните корекции в таксуването трябва да се отразят в подходящите финансови документи.

Това са свързани, но различни записи.

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

Защо това разделение е важно

То позволява на бизнеса да:

• Променя абонаментните планове, без да пренаписва стари фактури.
• Поддържа ясен запис на фактурираното за всеки период.
• Прилага корекции при таксуването според последователни правила.
• Проследява независимо статусите на абонамента и фактурата.
• Интегрира фактурирането с различни системи за управление на абонаменти.

Системата за абонаменти определя какво трябва да бъде начислено на клиента според търговската договореност.

Системата за фактуриране документира тези суми според приложимите бизнес и правни изисквания.

Разделянето на тези отговорности прави и двете системи по-лесни за поддръжка.

3. Установете надежден жизнен цикъл на фактурата

Фактурата не трябва да се третира като редактируем документ, който може да се променя неограничено.

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

Един опростен оперативен жизнен цикъл може да включва:

Подготовка

Системата събира клиентските данни, информацията за таксуване, облагаемите суми и другите данни, нужни за създаване на фактурата.

Документът може да остане чернова, докато тази информация се проверява.

Издаване

Фактурата се издава официално, получава необходимите идентификатори и става част от финансовите записи на бизнеса.

Проследяване на плащанията

Бизнесът записва дали фактурата остава неплатена, е платена или е частично платена, когато това е приложимо.

Корекции

Ако документът се нуждае от корекция, системата следва подходящата законова процедура и запазва връзката между първоначалния документ и последващите корекции.

Това разграничение е особено важно за бизнесите, които издават фактури автоматично.

Създадената фактура не трябва да се смята за валидна само защото PDF файлът е генериран успешно.

Системата трябва също да гарантира, че основните данни са правилни и че издаването следва съответните изисквания.

Запазвайте първоначалната финансова история

След като фактурата е издадена, промяната на историческите ѝ данни без подходящ процес за корекция може да създаде несъответствия.

Например, ако на клиент са фактурирани 100 евро и по-късно получи намаление от 20 евро, тихата промяна на първоначалната фактура на 80 евро може да не е приемлив подход.

Според приложимите правила може да е необходимо кредитно известие или друг коригиращ документ.

Надеждната система за фактуриране трябва да запазва първоначалния запис и причината за последващите промени.

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

4. Обработвайте промените в абонаментите, без да губите точност при таксуването

Промените в абонаментите са сред най-честите източници на сложност при фактурирането на SaaS услуги.

Да разгледаме клиент с месечен план за 60 евро, който преминава към план за 120 евро по средата на периода на таксуване.

Бизнесът трябва да определи как промяната влияе на начисляваните суми.

Възможните подходи включват:

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

Подходящият подход зависи от ценовата политика на бизнеса, договора с клиента и настройките за таксуване.

След това системата за фактуриране трябва правилно да документира получените суми и корекции.

Пример: преминаване към по-висок план по средата на периода

Да приемем, че бизнесът използва опростен 30-дневен период на таксуване и клиентът променя плана точно по средата му.

Илюстративно изчисление без данъци, разлики от закръгляване и специфични за доставчика правила за таксуване.

Примерът показва защо системата за фактуриране се нуждае от повече информация от текущата цена на абонамента на клиента.

Може да са нужни също предишният план, датата на влизане в сила на промяната, началото и краят на периода на таксуване и приложимите правила за корекции.

Без тези данни създадената фактура може да не отразява точно трансакцията.

Пример при конкретен доставчик има в документацията на Stripe за пропорционални начисления при абонаменти ↗ (отваря се в нов раздел).

5. Изградете автоматизацията върху надеждни събития

Ръчното създаване на фактури може да работи за малък SaaS бизнес, но става все по-неефективно с увеличаването на броя клиенти.

Автоматизираното фактуриране може да намали повтарящата се работа, ако основният процес е надежден.

В много SaaS архитектури фактурирането се задейства от бизнес събития.

Примери за такива събития са:

• Започва абонамент.
• Започва нов период на таксуване.
• Приключва период за отчитане на платено потребление.
• Закупена е допълнителна услуга.
• Одобрена е корекция при таксуването.
• Необходим е коригиращ документ.

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

Автоматизираният процес на фактуриране трябва да проверява всяко събитие, преди да създаде документ.

Предотвратявайте дублирането на фактури

Особено важно предизвикателство е обработката на едно и също събитие повече от веднъж.

Да си представим, че събитие за подновяване на абонамент е доставено два пъти заради повторен опит след мрежов проблем.

Ако системата безусловно създава фактура за всяко получено събитие, клиентът може да получи две фактури за един и същ период.

Надеждната реализация трябва да използва идемпотентни операции: повторната обработка на една и съща логическа заявка не трябва да създава дублирани финансови документи.

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

Целта е временните мрежови грешки или повторените известия да не водят до дублирани фактури.

Обработвайте неуспехите, без да губите трансакции

Автоматизацията трябва да отчита и неуспешните операции.

Ако създаването на фактура е неуспешно поради непълни клиентски данни или недостъпна външна система, неуспехът трябва да бъде записан.

Според ситуацията системата може безопасно да опита отново или да изисква ръчна намеса.

Мащабируемото решение прави тези изключения видими, вместо да ги пропуска без следа.

Документацията на Stripe за идемпотентни заявки ↗ (отваря се в нов раздел) показва как повторените заявки могат да избегнат двукратното изпълнение на една операция.

6. Свържете фактурите с платежните записи

Фактурирането и събирането на плащания са тясно свързани, но не са една и съща операция.

Фактурата представлява документирана начислена сума или трансакция.

Платежният запис представлява опит или събитие, свързано с прехвърлянето на пари.

Мащабируемата система трябва да запазва връзката между тези записи, без да предполага, че всяка фактура има точно едно плащане.

Например:

• Клиентът може да плати една фактура чрез няколко частични плащания.
• Едно плащане може да покрива няколко фактури.
• Опитът за плащане може да е неуспешен и по-късно да успее след повторен опит.
• Клиентът може да получи частично възстановяване след плащането.
• Плащането може да бъде потвърдено преди съответното изплащане от доставчика.

Тези сценарии стават трудни за управление, когато системата за фактуриране съхранява само прост признак „платено/неплатено“.

По-гъвкав подход е поддържането на отделна платежна информация и свързването ѝ със съответните фактури чрез разпознаваеми референции и разпределение на плащанията.

Статусът на плащането не е статус на сетълмента

За бизнесите, които използват външни платежни доставчици, успешното клиентско плащане не означава непременно, че средствата вече са постъпили по банковата сметка на бизнеса.

Потвърждението на плащането, сетълментът и изплащането могат да се случат в различни моменти.

Тези събития трябва да остават разграничими.

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

За повече подробности вижте статията ни Как протича едно онлайн плащане: от авторизация до сетълмент.

7. Включете нормативните изисквания в процеса на фактуриране

С разрастването на SaaS бизнеса изискванията за фактуриране могат да станат по-сложни.

Различните държави могат да имат правила относно:

• Задължителната информация във фактурите.
• Номерирането и идентифицирането на фактурите.
• Третирането на ДДС и данъчната информация.
• Процедурите за коригиране на документи.
• Форматите и предаването на електронни фактури.
• Съхранението и достъпността на записите.
• Изискванията за език и валута.

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

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

Направете правилата за отделните юрисдикции конфигурируеми

Мащабируемият подход отделя общия процес на фактуриране от правилата, приложими за конкретни юрисдикции.

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

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

Самата софтуерна конфигурация обаче не установява съответствие със закона.

Бизнесът трябва да определи приложимите задължения за своите трансакции и да гарантира, че системата ги прилага правилно.

Електронното фактуриране е повече от PDF

Фактура, създадена като PDF, не е непременно равностойна на структурирана електронна фактура.

Структурираното електронно фактуриране обикновено включва машинночетими документни формати, които могат да бъдат обменяни и обработвани автоматично.

С развитието на европейските изисквания за електронно фактуриране и цифрово отчитане бизнесите може да се нуждаят от допълнителни документни формати или механизми за предаване.

Мащабируемата архитектура за фактуриране не трябва да прави PDF документа единствения си източник на финансова информация.

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

Вижте насоките на Европейската комисия за правилата за фактуриране за целите на ДДС ↗ (отваря се в нов раздел) и структурираното електронно фактуриране ↗ (отваря се в нов раздел) относно разграничението между общите европейски изисквания, националните правила и структурираните фактурни данни.

8. Поддържайте надеждни клиентски данни и информация за таксуване

Точността на фактурите зависи в голяма степен от качеството на основните клиентски данни.

За B2B SaaS бизнесите съответните данни могат да включват:

• Официалното наименование на компанията.
• Адреса за фактуриране.
• Приложимите данъчни идентификатори.
• Държавата и юрисдикцията.
• Данните за контакт относно фактурирането.
• Предпочитанията за получаване на фактури.

Тези данни могат да се променят с времето.

Например клиентът може да актуализира регистрирания си адрес или данъчните си данни, след като вече са издадени няколко фактури.

Системата трябва да използва правилната информация за новите документи, без тихо да пренаписва вече издадените фактури.

Запазването на данните, използвани при издаването, помага да се поддържа точен исторически запис.

То улеснява и обясняването на разликите между документи, издадени в различни моменти.

9. Осигурете видимост и контрол върху фактурирането

Мащабируемостта не се изчерпва с бързата обработка на хиляди фактури.

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

Бизнесът трябва да може да отговори на оперативни въпроси като:

• Кои фактури са създадени по време на даден цикъл на таксуване?
• Кои документи не са преминали проверка или не са били издадени?
• Има ли събития за таксуване, които очакват обработка?
• Открити ли са дублирани заявки?
• Кои фактури изискват ръчно внимание?
• Кои документи са коригирани или са получили кредитни известия?

Тези възможности стават особено важни, когато фактурирането премине от ръчна административна задача към автоматизиран бизнес процес.

Полезните оперативни показатели включват дела на успешно създадените фактури, забавянията при обработката, неразрешените изключения и броя документи, изискващи корекция.

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

10. Планирайте растежа без ненужна сложност

Изграждането на мащабируема система за фактуриране не означава непременно разработване на голяма финансова платформа от самото начало.

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

Основните компоненти са:

Надеждна информация за таксуване

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

Структурирани фактурни записи

Последователни данни за фактурите, подходящи идентификатори на документите и запазена история на издаването.

Контролирана автоматизация

Надеждна обработка на събития, предотвратяване на дублиране, проверки и обработка на неуспехи.

Свързана платежна информация

Възможност фактурите да се свързват с плащанията и последващите финансови събития.

Адаптивни правила за нормативните изисквания

Структура, която може да отчита изискванията на поддържаните юрисдикции.

Оперативна видимост

Инструменти и записи, които правят изключенията лесни за откриване и проверка.

Бизнесът може да реализира тези възможности в едно приложение или да ги разпредели между няколко интегрирани услуги.

Най-важното е отговорностите и връзките между данните да останат ясни.

Как A3BSS подхожда към фактурирането

Разгледаните предизвикателства показват защо фактурирането трябва да се третира като част от свързан финансов процес, вместо просто като функция за създаване на документи.

A3BSS се разработва, за да помага на бизнесите да управляват фактурирането и свързаните финансови записи, с първоначално покритие за фактуриране в България в EUR и планирана поддръжка на допълнителни юрисдикции.

Възможностите му за фактуриране и плащания са предназначени да се използват самостоятелно или заедно.

Това позволява на бизнесите да подхождат към фактурните документи и платежната интеграция според конкретните си оперативни нужди, без да е необходимо да приемат и двете възможности едновременно.

Можете да научите повече за планираната функционалност на страниците Фактуриране с A3BSS и Плащания.

Заключение

Мащабируемото фактуриране на SaaS услуги не е преди всичко въпрос на създаване на повече фактури.

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

Разделянето на абонаментите от фактурите, запазването на документната история, правилната обработка на корекциите и свързването на платежните записи допринасят за по-надежден процес на фактуриране.

Автоматизацията може да намали административната работа, но трябва да бъде подкрепена от подходящи проверки, обработка на изключения и оперативна видимост.

За растящите SaaS бизнеси тези основи помагат да се изградят процеси на фактуриране, които могат да се развиват, без да се жертват последователността и проследимостта.