5 помилок, через які фінансовий звіт з CRM показує неправду
Ви відкриваєте дашборд. Дохід за місяць — умовні 400 тисяч. Ви дивитеся на рахунок і розумієте, що таких грошей там не було ніколи. Звіт не зламався. Він чесно показав те, що лежить у вашій CRM.
Data Studio чи Power BI нічого не вигадують самі — вони беруть дані з CRM і відображають їх так, як ви налаштували.
Ми зібрали п'ять помилок, які найчастіше роблять фінансовий звіт із CRM неправдивим. Частину з них ми бачимо в проєктах, частину пройшли самі, коли будували управлінську звітність для власної компанії. Про кожну розкажемо: як виглядає, чому виникає, як перевірити за 10 хвилин і що зробити в CRM, щоб виправити.
Помилка 1. Платежі не прив'язані до угод, а витрати не мають статей
Це найпоширеніша помилка і найдорожча за наслідками. Загальна сума доходу у звіті правильна. Але на питання «а на чому саме ми заробляємо» звіт відповісти не може.
Як виглядає. Ви бачите виручку за місяць, бачите витрати за місяць, бачите різницю між ними. І все. Який напрям прибутковий, а який ви дотуєте, скільки коштує утримання офісу проти прямих витрат на виконання замовлень — цього у звіті немає.
Чому виникає. Дві окремі причини, які зазвичай зустрічаються разом.
Оплата, не прив'язана до угоди, існує у звіті сама по собі. Вона не потрапляє в розріз за воронками, менеджерами, товарами й джерелами клієнтів. Ви не можете сказати, звідки ці гроші.
Витрата без статті не розкладається на групи. А без поділу на прямі та накладні витрати не рахується ні валова маржа, ні операційний прибуток. Залишається тільки різниця між усіма надходженнями й усіма витратами, яка нічого не пояснює.
Типова ситуація. Уявіть агенцію, яка робить сайти і паралельно продає підтримку. У звіті сумарний прибуток позитивний, власник спокійний. Коли платежі нарешті прив'язали до угод і розділили за воронками, виявилося, що підтримка приносить невелику, але стабільну маржу, а розробка сайтів на фіксовану ціну працює майже в нуль через безкінечні правки замовників. Цифра прибутку не змінилася — змінилося розуміння, що з нею робити далі.
Як перевірити. Побудуйте таблицю: сума надходжень за місяць, окремо рядок «без прив'язки до угоди». Якщо другий рядок більший за кілька відсотків, розрізи у вашому звіті не працюють. Так само для витрат: скільки їх без статті.
Як виправити. Прив'язуйте кожну оплату до угоди — у більшості CRM це робиться в один клік із картки угоди. І заведіть довідник статей витрат. П'яти груп вистачає переважній більшості малого бізнесу:
Прямі витрати на виконання — підрядники, матеріали, комісії, винагороди за конкретні замовлення.
Непрямі витрати — оренда, сервіси, маркетинг, команда.
Зарплата власника.
Податки.
Інвестиції — обладнання, те, що купується надовго.
Більше груп на старті не потрібно: деталізацію завжди можна додати всередині кожної.
Помилка 2. Оплата вважається доходом, хоча робота ще не виконана
Ця помилка не технічна, а концептуальна. Саме тому її найважче помітити: у звіті все виглядає коректно.
Як виглядає. Місяці стрибають без видимої причини. У березні ви «заробили» вдвічі більше, ніж у квітні, хоча роботи в обидва місяці було приблизно однаково. Просто в березні два клієнти внесли аванси, а в квітні — ні.
Чому виникає. «Гроші прийшли» і «ми заробили» — це різні події, рознесені в часі. Коли клієнт платить 50% за проєкт на три місяці, ці гроші вже на рахунку, але роботу ви ще винні. По суті, це ваше зобов'язання перед клієнтом, а не дохід.
Поки ви вважаєте доходом надходження, два показники спотворені одночасно: дохід місяця і прибуток кожного окремого проєкту.
Типова ситуація. Уявіть меблеву майстерню, яка працює за передоплатою 70%. У грудні вона отримала багато передоплат під новорічні замовлення і за звітом мала найкращий місяць року. Січень виглядав провальним: виробництво працювало на повну, а надходжень майже не було, бо замовлення вже оплачені. Насправді обидва місяці були нормальними — просто звіт показував рух грошей, а не результат роботи.
Кому це критично. Проєктному бізнесу, виробництву на замовлення, будь-яким послугам із передоплатою або постоплатою. Якщо ви роздріб або інтернет-магазин, де оплата і відвантаження відбуваються майже одночасно, різниця мінімальна і цією помилкою можна знехтувати.
Касовий метод чи метод нарахування
Касовий метод рахує дохід у момент надходження грошей. Метод нарахування — у момент, коли робота виконана або товар відвантажений.
Питання «який із них правильний» поставлене неправильно: вам потрібні обидва. Нарахування відповідає на питання, чи заробляє ваша бізнес-модель. Каса відповідає на питання, чи вистачить грошей заплатити зарплату наступного тижня. Бізнес банкрутує від другого, а в'яне від першого.
Як перевірити. Порівняйте два графіки за той самий період: надходження за місяцями і суму закритих замовлень за місяцями. Якщо лінії розходяться системно, ви дивитеся лише на одну з них.
Як виправити. Фіксуйте в угоді дату фактичного виконання, а не тільки дату створення й дедлайн. Тоді з тих самих даних будуються обидва звіти: дохід за датою виконання і гроші за датою платежу.
Помилка 3. Суми лежать у CRM як текст
Найпідступніша з п'яти, бо звіт не ламається і не показує помилку. Він просто показує інше число.
Як виглядає. Поле є, цифри в ньому видно, а підсумувати їх неможливо. Або ще гірше: звіт мовчки показує середнє значення замість суми. Виглядає правдоподібно, тільки менше в десятки разів.
Чому виникає. Дві причини.
Перша: поле в CRM створене як текстове. Найчастіше це стосується додаткових полів, які компанія завела сама — відсоток партнера, бонус менеджера, сума податку, розмір знижки. Для CRM це просто рядок символів, який не можна додавати.
Друга: поле числове, але в звіті для нього обрана не та агрегація. Середнє замість суми — класика, і помітити її без звірки майже неможливо.
Типова ситуація. Уявіть сервісну компанію, яка завела поле «винагорода партнеру» і вписувала туди суми вручну. У звіті це поле показувало невеликі числа, і виглядало, що партнерам платиться небагато. Коли поле зробили числовим і підсумували коректно, сума за рік виявилася в кілька разів більшою і зайняла помітну частку в прямих витратах.
Як перевірити. Найпростіша перевірка з усіх: візьміть один місяць і порівняйте підсумок у звіті з підсумком у CRM. Якщо числа розходяться в рази, а не на копійки, це майже завжди тип поля або агрегація, а не втрата даних.
Як виправити. У CRM зробіть числові поля числовими, а дати — датами. У звіті перевірте агрегацію кожного грошового поля: має бути сума, а не середнє.
Тут допомагає сам спосіб підключення даних. Adminka Connect віддає додаткові поля CRM у звіт уже в правильному форматі: числа можна підсумовувати, за датами — фільтрувати. Нове поле з'являється у звітах після наступного нічного оновлення.
Помилка 4. Витрати пораховані двічі
Як виглядає. Маржа у звіті занижена. Іноді настільки, що прибуткові замовлення показують мінус, і ви починаєте шукати проблему в ціноутворенні там, де її немає.
Чому виникає. Одна й та сама витрата записана у двох місцях. Собівартість або винагорода вказана в картці угоди — і вона ж проходить окремим платежем, коли ви фактично платите підряднику. Звіт бере обидва джерела і складає їх.
Це типова пастка саме для компаній, які вже навели лад у даних: обидва записи зроблені правильно, кожен сам по собі коректний, помилка виникає лише в момент складання.
Правило, яке це знімає. Два різні звіти, два різні джерела, ніколи в одному показнику:
P&L компанії будується з платежів за статтями витрат.
Маржа окремого замовлення будується з полів угоди.
Змішувати їх не можна навіть «для повноти картини».
Типова ситуація. Уявіть компанію, яка встановлює обладнання. Собівартість обладнання вказували в угоді, а оплату постачальнику проводили платежем. У звіті маржа за кожним проєктом виходила близькою до нуля, і власник уже збирався піднімати ціни. Після того як прибрали подвійний рахунок, маржа стала нормальною, а реальна проблема виявилася в іншому місці — у вартості виїздів, яку взагалі ніде не фіксували.
Як перевірити. Візьміть один місяць і порівняйте дві цифри: суму собівартості з карток угод і суму витрат за відповідними статтями платежів. Вони мають бути приблизно однакові. Якщо у звіті присутні обидві — ви рахуєте двічі.
Як виправити. Визначте одне джерело правди для кожного типу витрат і зафіксуйте це письмово. Регулярна звірка цих двох сум корисна й сама по собі: системне розходження означає, що в угодах поля просто не заповнюють.
Помилка 5. Перекази між рахунками рахуються як дохід
Найпростіша помилка списку — і саме тому її часто пропускають.
Як виглядає. Ви переводите гроші з каси на картку, з картки на рахунок ФОП, між гаманцями — і звіт додає кожен такий рух до виручки. Місяць виглядає кращим, ніж був.
Чому виникає. У таблиці платежів усі рухи грошей лежать разом: оплати клієнтів, витрати, перекази. Якщо тип операції не фіксується в CRM або не фільтрується у звіті, вони складаються в одну суму.
Окремий різновид тієї ж помилки — внесення власних коштів. Коли власник кладе гроші в бізнес, щоб перекрити касовий розрив, це не дохід, а фінансування. У звіті ж воно виглядає як вдалий місяць.
Типова ситуація. Уявіть бізнес, який активно працює з готівкою і щотижня інкасує її на рахунок. Кожна інкасація — це переказ. За рік така компанія може бачити у звіті виручку, помітно більшу за реальну, і не розуміти, чому цифри не сходяться з банком.
Як перевірити. Таблиця «сума за типом операції за місяць» і звірка підсумку надходжень із банківською випискою. Якщо у звіті більше, ніж у банку, шукайте перекази.
Як виправити. Розділіть у CRM типи операцій: надходження, витрата, переказ. У звіті перекази виключаються фільтром із усіх показників, окрім залишків за рахунками — там вони якраз потрібні, бо переносять гроші з одного рахунку на інший.
Чеклист: як налаштувати CRM, щоб цифри були коректними
Усі п'ять помилок виправляються не у звіті, а в CRM. Ось вісім дій, які закривають їх усі.
Розділити типи операцій: надходження, витрата, переказ між рахунками.
Прив'язувати кожну оплату до угоди або замовлення.
Завести довідник статей витрат і проставляти статтю кожному платежу.
Для кожної статті визначити групу: прямі, накладні, власник, податки, інвестиції.
Фіксувати дату фактичного виконання замовлення, а не тільки дедлайн.
Числові поля зробити числовими, дати — датами, зокрема в додаткових полях.
Завести послуги або товари в каталог, щоб був розріз за напрямами.
Визначити одне джерело правди для собівартості: або угода, або платіж.
Якщо більшість пунктів у вас уже виконані, фінансовий звіт збирається за один вечір. Якщо ні, спершу має сенс навести лад у даних — інакше ви отримаєте гарний дашборд, якому не можна вірити.
Що далі
Коли дані впорядковані, з тієї самої CRM збирається повноцінна управлінська звітність: рух грошей і платіжний календар, прибутки та збитки за напрямами, маржа окремих замовлень, дебіторка за віком і прогноз доходу на наступний квартал. Про кожен із цих звітів — які питання він закриває і як його побудувати — ми напишемо окремо.
Щоб дані з KeepinCRM, KeyCRM чи Pipedrive потрапляли у звіт автоматично й оновлювалися щоночі, ми зробили Adminka Connect. Угоди, платежі, клієнти, товари й позиції замовлень приходять у Data Studio або Power BI впорядкованими таблицями — без ручних вивантажень і без копіювання в Excel.
З чого почати фінансовий звіт
Якщо ви будуєте звіти самостійно на основі даних з KeyCRM, KeepinCRM чи Pipedrive — спробуйте Adminka Connect безкоштовно протягом 14 днів.
Якщо не хочете розбиратися самі — ми впроваджуємо CRM і будуємо аналітику з 2019 року. Розберемо ваші дані, покажемо, що в них поправити, і зберемо дашборд під ваші процеси. Отримати консультацію — перша консультація безкоштовна.
Коментарі