Білінг агенції: як виставляти рахунки клієнтам за обслуговування

Перше число, 09:00. Початок місяця, і замість того, щоб вести клієнтів, власниця агенції відкриває таблицю й починає найнудніше: виставляти рахунки за обслуговування. Сорок клієнтів — сорок рахунків. У цього тариф фіксований, у того плюс доплата за працівників, у третього минулого місяця була складна операція, за яку домовлялися окремо. Копіювати шаблон, міняти назву, суму, реквізити, номер рахунку, надсилати, ставити позначку «виставлено». До обіду половина зроблена, і десь там уже закралася помилка — комусь поставили торішню суму.

А ще ж треба пам'ятати, хто заплатив. Цей перерахував, той ні, а он той платить частинами. Наприкінці місяця складати, хто скільки винен, — окрема історія на пів дня з тією ж таблицею, у якій половина клітинок давно неактуальна.

Білінг — рахування плати за власну роботу — парадоксально найгірше поставлений процес у багатьох агенцій. Ми автоматизуємо облік клієнтам, а собі виставляємо рахунки руками, у таблиці, з помилками. У цій статті розберемо моделі тарифікації бухгалтерських послуг, покажемо, як прайс-листи й автоматичні драфти рахунків прибирають ручну рутину початку місяця, і як облік нарахувань дає відповідь на головне питання — хто скільки винен.

Як агенції рахують плату за обслуговування

Перш ніж автоматизувати білінг, треба визначитися з моделлю тарифікації. Агенції зазвичай використовують одну з трьох або їхню комбінацію.

Фіксована модель найпростіша: домовилися на суму — щомісяця виставляєте її. Мінус — не враховує, що один клієнт цього місяця надіслав п'ять документів, а інший п'ятдесят. Хтось переплачує, хтось недоплачує за реальний обсяг.

За операціями справедливіша: базова абонплата плюс складова за фактичний обсяг. Але вона вимагає рахувати цей обсяг щомісяця — руками це ще одна рутина.

За складністю враховує профіль клієнта: ФОП без ПДВ і без працівників коштує одне, ТОВ на загальній системі з зарплатою — інше. Це найточніша модель, але й найскладніша для ручного адміністрування, бо тариф залежить від кількох ознак одразу.

Приклад. Агенція веде клієнта — ФОП 3 групи. Базовий тариф обслуговування 2 500 грн/міс. У нього з'явився найманий працівник — за домовленістю це +800 грн за зарплатну звітність. Цього місяця була разова консультація щодо зміни виду діяльності — ще 500 грн. Разом до рахунку: 2 500 + 800 + 500 = 3 800 грн. Тепер помножте цю арифметику на сорок клієнтів з різними тарифами й доплатами — і стане зрозуміло, чому початок місяця з'їдає день, а помилки неминучі. Саме таку арифметику й має рахувати система, а не людина в таблиці о дев'ятій ранку першого числа.

Незалежно від моделі, механіка одна: є прайс-лист (базові тарифи й доплати), є профіль клієнта, і на їхньому перетині щомісяця народжується сума до сплати. Це ідеальний кандидат на автоматизацію — правила відомі наперед, змінюються рідко, а рахунок треба формувати регулярно.

На вибір моделі варто дивитися ще й з погляду власної економіки агенції. Фіксований тариф простий в адмініструванні, але з часом «відстає» від реального навантаження: клієнт розрісся, документів побільшало, а платить він ту саму суму, що й два роки тому. Модель за складністю, навпаки, автоматично підлаштовує ціну під профіль — з'явився працівник чи ПДВ, і тариф зростає без окремих перемовин. Тому багато агенцій приходять до гібриду: фіксована база плюс надбавки за ознаки, які реально збільшують роботу. Головне — щоб ці правила були зафіксовані в системі, а не трималися в пам'яті засновника, інакше будь-яка модель складніша за плаский фікс стає джерелом помилок і суперечок про суму.

Біль ручного виставлення рахунків

Розберемо, чому ручний білінг такий болючий, — не щоб поскаржитися, а щоб точно побачити, що саме має закрити автоматизація.

• Повторюваність. Кожен місяць — ті самі сорок рахунків з майже тими самими сумами. Робота, яка на 90% однакова від місяця до місяця, але щоразу робиться заново.
• Помилки копіювання. Виставляючи рахунок за шаблоном, легко забути змінити суму, номер чи назву клієнта. Одна одруківка — і клієнт отримує чужу суму або торішній тариф.
• Різні тарифи в голові. Хто на фіксі, у кого доплата за працівників, з ким домовлялися про знижку — це знання розкидане по пам'яті й таблицях, і його легко застосувати неправильно.
• Нумерація рахунків. Наскрізна нумерація вручну — окреме джерело плутанини: пропущені номери, дублі.
• Контроль оплат. Виставити — половина справи. Далі треба звіряти, хто заплатив, і нагадувати боржникам, тримаючи в голові, за який місяць і скільки.

Найдорожче тут навіть не час, а те, що ручний білінг протікає. За завалом місяця легко забути виставити рахунок узагалі — і клієнт місяць обслуговувався безкоштовно, бо про нього забули. Або забути про доплату за нову послугу — і робота зроблена, а не оплачена. У агенції на десятки клієнтів такі протікання накопичуються в помітні суми недоотриманого доходу, яких ніхто навіть не помічає, бо ніде не зведено, скільки мало бути нараховано.

Про те, як має виглядати сам документ рахунку, щоб він був коректним і однаковим, ми писали окремо — див. зразок рахунку-фактури. Правильний шаблон — передумова того, щоб автоматичне формування рахунків працювало чисто.

Прайс-листи й автоматичні драфти рахунків

Автоматизація білінгу будується на двох речах: прайс-листі й автоматичному формуванні драфтів рахунків.

Прайс-лист — це зафіксовані в системі тарифи й доплати: базова абонплата, надбавка за працівників, за ПДВ, за додаткові послуги. Замість того щоб тримати ціни в голові, ви задаєте їх один раз. Коли профіль клієнта змінюється (з'явився працівник, перейшов на ПДВ), сума перерахується за правилами прайс-листа, а не за тим, чи згадав хтось про доплату.

Драфти рахунків — це чернетки, які система готує сама на початок періоду. Механіка така:

1. На початок місяця система бере кожного клієнта і його тариф з прайс-листа.
2. Формує чернетку рахунку з правильною сумою, реквізитами й номером.
3. Ви переглядаєте пакет драфтів, за потреби коригуєте (додали разову послугу — виправили одну суму).
4. Підтверджуєте — рахунки виставлені, нарахування зафіксовані.

Ключова відмінність від ручного процесу: людина не створює сорок рахунків, а перевіряє сорок готових. Це різниця між днем роботи й пів годиною контролю. Реквізити й номери підставляє система — зникає клас помилок «не та сума, не той номер». А оскільки драфти формуються на всіх клієнтів одразу, неможливо когось забути: якщо клієнт є в системі й має тариф, його рахунок буде в пакеті.

Автоматичні драфти особливо добре лягають на регулярний характер обслуговування: плата за ведення — це, по суті, щомісячний повторюваний платіж, і формувати його щоразу вручну так само нелогічно, як вручну набивати однакові платіжки. Система, яка вже веде облік клієнтів, знає їхні профілі й реквізити, — тому їй природно й формувати рахунки за обслуговування.

Облік нарахувань: хто скільки винен

Виставити рахунок — половина білінгу. Друга половина, яку ручні таблиці провалюють найчастіше, — це облік того, що нараховано, що сплачено і хто скільки винен. Без цього агенція не бачить власної дебіторки й фактично не знає свого фінансового стану по клієнтах.

Правильний білінг веде по кожному клієнту стрічку нарахувань і оплат — своєрідний особовий рахунок:

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

Облік нарахувань дає агенції кілька важливих речей:

• Видимість дебіторки. Загальна сума, яку клієнти винні агенції, — на екрані, а не в здогадах. Це прямий показник фінансового здоров'я.
• Адресні нагадування. Видно конкретних боржників і суми — нагадування стає точковим, а не масовою розсилкою «будь ласка, сплатіть».
• Частина оплат. Коли клієнт платить не всю суму, система показує залишок, а не «начебто щось недоплатив».
• Історія по клієнту. Видно, хто платить вчасно, а хто хронічно затримує, — це підстава переглянути умови або тег «проблемний» у CRM.

Останній пункт замикає білінг з рештою роботи агенції. Платіжна дисципліна клієнта — це не лише питання грошей, а й сигнал для ведення клієнта загалом. Клієнта, який стабільно не платить за обслуговування, логічно позначити в CRM і вирішити, чи продовжувати договір. Про те, як вести клієнтів системно — з тегами, договорами й нагадуваннями, — читайте у статті про CRM для бухгалтера.

Чому дебіторка небезпечна саме для агенції

Варто окремо пояснити, чому невидима дебіторка особливо шкідлива для бухгалтерської агенції. Робота вже зроблена: звіти подані, податки пораховані, документи проведені — витрати часу команди понесені незалежно від того, заплатив клієнт чи ні. Тобто кожен несплачений рахунок за обслуговування — це не «недоотриманий майбутній дохід», а прямий збиток за вже виконану роботу. І чим довше борг висить непоміченим, тим складніше його стягнути: за пів року клієнт щиро не пам'ятає, що не доплатив за березень, а агенція не має чим це підтвердити, бо ніде не вела облік нарахувань.

Саме тому облік «нараховано — сплачено — борг» важливіший, ніж здається. Він не просто зручність — це захист доходу агенції. Коли борг видно в день його виникнення, нагадування спрацьовує вчасно й на конкретну суму, поки клієнт ще пам'ятає обставини. Коли борг «спливає» через квартал зі зведення руками, він частіше просто списується — бо сперечатися дорожче, ніж пробачити.

Білінг у системі, де вже є клієнти

Білінг має сенс автоматизувати саме там, де вже ведеться облік клієнтів. Причина та сама, що й з CRM: система, яка знає профіль кожного клієнта, його реквізити й обсяг роботи, має всі дані, щоб самій формувати рахунки за обслуговування. Окремий сервіс для виставлення рахунків цих даних не знає — довелося б переносити їх руками, тобто повертатися до тієї ж рутини.

Doc2Pay містить білінг агенції як вбудовану частину системи. Ви задаєте прайс-листи з тарифами й доплатами, система формує драфти рахунків клієнтам за обслуговування на початок періоду, а ledger нарахувань веде по кожному клієнту облік «нараховано — сплачено — борг». Реквізити й нумерація підставляються автоматично, бо клієнти вже заведені в систему. Оскільки все в одному місці, білінг бачить те саме, що й решта: профіль клієнта для розрахунку тарифу, його оплати, його статус у CRM. Ви перестаєте вести окрему таблицю власних доходів по клієнтах — вона з'являється сама з нарахувань і оплат.

Для агенції це означає, що найнудніший день місяця — виставлення рахунків — стискається до перегляду готового пакета, а питання «хто скільки винен» має відповідь на екрані будь-якої миті, а не раз на місяць після пів дня зведення. Подивіться тарифи Doc2Pay: білінг входить у систему як один з модулів для агенцій, без окремих доплат за користувачів команди.

Коротко: білінг бухгалтерської агенції

• Визначте модель тарифікації. Фіксована, за операціями чи за складністю — від неї залежить, як будувати прайс-лист.
• Ручний білінг протікає. Забуті рахунки й доплати — це недоотриманий дохід, якого ніхто не помічає без зведення нарахувань.
• Прайс-листи + драфти. Система формує рахунки сама, людина перевіряє готове — день роботи стискається до пів години контролю.
• Облік нарахувань відповідає, хто скільки винен. Дебіторка на екрані, адресні нагадування, облік часткових оплат.
• Білінг живе в системі обліку. Там, де вже є профілі й реквізити клієнтів, рахунки формуються самі — без подвійного введення.

Білінг замикає цикл роботи агенції: клієнта привели й провели по воронці, обслужили — і виставили за це рахунок, не забувши нікого. Щоб вибудувати цей цикл цілком, читайте про процеси бухгалтерської агенції і про CRM для бухгалтера: разом вони перетворюють ведення клієнтів і плату за них з ручної рутини на керований процес.