Програма для оформлення замовлень: рахунки й оплати

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

Ця стаття — для власника або операційного директора компанії на 5–100 людей, яка продає під замовлення: виробництво, монтаж, оптові поставки, послуги. Розберемо весь шлях від замовлення до закритого рахунку. Які дані збирати на вході. Як нумерувати рахунки. Як система зіставляє платежі з рахунками і коли нагадує. Що вимагає українське законодавство щодо рахунку, накладної, акта й податкової накладної.

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

Коротко:

Рахунок — лише середина процесу. Гроші губляться до нього, коли замовлення оформлене неповно, і після нього, коли оплата прийшла без номера рахунку або ніхто не нагадав.
Звірку оплат можна автоматизувати правилами. Номер рахунку в призначенні, код ЄДРПОУ, сума — система закриває точні збіги сама, а неясні платежі віддає людині.
Рахунок не є первинним документом. Операцію підтверджують накладна або акт, а платнику ПДВ ще потрібна податкова накладна, зареєстрована вчасно.
ШІ не рахує ціну і не відправляє гроші. Він розбирає вільний текст: заявки, призначення платежів, рахунки постачальників — і готує чернетки для людини.
Почніть з опису процесу, а не з вибору програми. Без єдиних статусів і умов оплати автоматизація просто швидше повторює ті самі помилки.

Що робить програма для оформлення замовлень, крім друку рахунку

Слово «оформлення» в бізнесі означає більше, ніж заповнити бланк. Замовлення оформлене, коли зафіксовано: що продаємо, кому, за якою ціною, на яких умовах оплати і які документи клієнт отримає. Від цього залежить усе, що станеться з грошима далі.

У фінансах цей ланцюжок називають Order-to-Cash — «від замовлення до грошей». Для компанії на 5–100 людей він складається з шести кроків:

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

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

Вихідні й вхідні рахунки — два різні процеси

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

Ця стаття переважно про вихідні рахунки, бо саме вони визначають, коли гроші прийдуть у компанію. Вхідним присвячена окрема тема — автоматизація відділу постачання: заявки, постачальники, закупівлі й оплати. Нижче, у розділі про ШІ, коротко покажемо, як система читає рахунки постачальників.

Де межа між програмою для замовлень і бухгалтерією

Програма для оформлення замовлень не замінює бухгалтерську програму. BAS, M.E.Doc чи онлайн-бухгалтерія лишаються там, де вони сильні: проведення, звітність, реєстрація податкових накладних. Програма для замовлень відповідає за операційну частину. Хто що замовив. Чи виставлено рахунок. Чи прийшли гроші. Кому нагадати. Між двома системами йде обмін даними: реквізити, суми, номери й дати документів.

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

Де губляться гроші між замовленням і оплатою

Втрати рідко виглядають як одна велика помилка. Це десяток дрібних розривів, кожен з яких «нічий». Ось де вони виникають найчастіше.

Рахунок виставили пізно. Менеджер узгодив замовлення в п’ятницю, а рахунок відправив у середу. Клієнт платить за своїм графіком, і ваш строк оплати зсувається на тиждень, хоча робота вже йде.
Старі реквізити клієнта. Клієнт змінив адресу, статус платника ПДВ або перейшов з ФОП на ТОВ. Рахунок на старі дані повертають на переоформлення, оплата чекає.
Оплата без номера рахунку. У призначенні платежу «за товар» або «згідно рахунку» без номера. Бухгалтер шукає, що це за гроші. Менеджер тим часом нагадує клієнту про оплату, яку той уже зробив.
Часткову оплату закрили як повну. Клієнт переказав частину суми, хтось поставив позначку «оплачено». Залишок більше ніхто не бачить.
Ніхто не нагадав. Нагадування — нічия робота: менеджеру ніяково, бухгалтер вважає, що це справа продажів. У нашій компанії з виробництва на верстатах з ЧПК система в перші тижні показала замовлення, яке програли саме через те, що вчасно не нагадали клієнту.
Робота почалася без передоплати. Коли умови оплати не записані в замовленні, виробництво стартує «під слово». У тій самій компанії одне замовлення програли через безкоштовні візуалізації без обмежень. Висновок — передоплата й ліміт правок, записані в умовах замовлення.
Аванс прийшов, а податкову накладну не склали вчасно. Для платника ПДВ передоплата — подія, від якої рахують податкові зобов’язання. Пропущений строк реєстрації коштує штрафу. Детально — у розділі про українську специфіку.

Проблема не лише українська. У дослідженні платіжної практики Atradius 2026 року для Центральної та Східної Європи прострочені платежі зачіпають 83% постачальників, а простроченим стає майже кожен третій рахунок. З відстрочкою там продають 46% B2B-обсягу (Atradius, червень 2026). Це дані по ринках регіону, а не окремо по Україні. Але логіка та сама: чим більше ви продаєте з відстрочкою, тим більше грошей залежить від дисципліни нагадувань і звірки.

Як порахувати, скільки коштує ручне оформлення рахунків

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

Час: формула

Години на місяць = (кількість рахунків × хвилини на оформлення, відправку й перевірку оплати + кількість нагадувань × хвилини на нагадування + кількість неясних платежів × хвилини на пошук) / 60.

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

Гроші: вартість простроченої дебіторки

Вартість очікування = сума простроченої дебіторки × середня кількість днів прострочення / 365 × річна ставка.

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

Приклад розрахунку

Приклад з умовними числами, не дані конкретної компанії. Компанія виставляє 150 рахунків на місяць. Оформлення одного рахунку займає 5 хвилин, відправка — 2, перевірка оплати у виписці — 3. Кожен п’ятий рахунок потребує нагадування, на нього йде 10 хвилин. Ще 20 платежів на місяць приходять без номера рахунку, на кожен бухгалтер витрачає 15 хвилин.

Оформлення, відправка й перевірка: 150 × 10 хв = 1 500 хв, тобто 25 годин.
Нагадування: 30 × 10 хв = 300 хв, тобто 5 годин.
Пошук неясних платежів: 20 × 15 хв = 300 хв, тобто 5 годин.

Разом 35 годин на місяць — майже тиждень роботи однієї людини. Помножте їх на повну вартість години цих співробітників (зарплата плюс податки) — це прямі витрати. Вартість прострочень додайте за другою формулою.

Будьте чесні з собою: автоматизація не обнуляє всі ці години. Лишаються неясні платежі, спірні клієнти, контроль. Розділіть хвилини на дві групи: що система забирає повністю (оформлення, відправка, точні збіги у виписці) і що лише скорочує (пошук, нагадування проблемним клієнтам). Як порахувати прибуток з кожного замовлення, а не лише витрати на рахунки, — у статті як порахувати рентабельність бізнесу.

Як працює автоматичне оформлення: 6 кроків від замовлення до звірки

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

Крок 1. Замовлення з повними даними

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

Чекліст полів, без яких рахунок не створюється:

платник: юрособа чи ФОП, назва, код ЄДРПОУ або РНОКПП, адреса;
статус платника ПДВ — від нього залежить, чи буде ПДВ у рахунку і чи потрібна податкова накладна;
договір: номер і дата, якщо працюєте за договором;
склад замовлення: позиції, кількість, одиниці, ціна;
умови оплати: передоплата, частинами чи з відстрочкою, і на скільки днів;
контакт для документів: пошта або Telegram людини, яка платить, а не лише того, хто замовляв;
відповідальний з вашого боку.

Правило: система не дає перевести замовлення у статус «рахунок виставлено», поки обов’язкові поля порожні. Реквізити клієнта зберігаються в його картці один раз і підставляються автоматично. Змінилися реквізити — ви міняєте їх у картці, а не в кожному рахунку.

Домовтеся, який саме статус запускає рахунок. Якщо в компанії є «в роботі», «погоджено», «підтверджено» і «до оплати», а менеджери ставлять їх по-різному, автоматика не знатиме, коли діяти. Один статус — одна подія.

Окремо — ціна. Якщо вона рахується за формулою (площа, матеріал, складність), формула має жити в системі, а не в голові менеджера чи в окремому Excel. Тоді в рахунок потрапляє та сама сума, яку клієнт бачив у комерційній пропозиції.

Крок 2. Рахунок за правилом, а не вручну

Коли замовлення переходить у потрібний статус, система створює рахунок сама. Що важливо налаштувати:

Нумерація. Лічильник веде система, окремо для кожної юрособи чи ФОП, від яких ви виставляєте рахунки. Номер не правлять вручну. Скасований рахунок не видаляють, а позначають скасованим — так не буде дірок і дублів.
Реквізити й суми. Реквізити вашої компанії й банку, сума прописом, ПДВ окремим рядком для платників ПДВ — підставляються з налаштувань і з картки клієнта.
Зберігання. PDF лежить у картці замовлення, а не в папці «Завантаження» на ноутбуці менеджера.
Перевірка. Для типових замовлень рахунок створюється автоматично. Для нетипових — знижка, нестандартна ціна, новий платник — система готує чернетку, а виставляє її людина.

Крок 3. Відправка і дата очікуваної оплати

PDF іде на пошту або в Telegram контакту для документів. У картці фіксуються дата відправки і дата, до якої чекаємо оплату, за умовами замовлення. Статус змінюється на «рахунок виставлено». Менеджер бачить це без питань до бухгалтера.

Банки теж скорочують шлях від рахунку до оплати. ПриватБанк описує інтеграцію облікового сервісу з «Інвойсингом Приват24»: документ «рахунок-акт» автоматично передається в банк, контрагент отримує push-сповіщення в застосунку й оплачує в кілька дотиків (ПриватБанк). Якщо ваші клієнти платять через цей банк, варто перевірити, чи підтримує таку передачу ваш обліковий сервіс.

Крок 4. Надходження оплат: виписка файлом або напряму з банку

Є два способи дізнатися, що гроші прийшли.

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

Банківський API. Система сама забирає нові операції за розкладом. ПриватБанк повідомляє, що його відкриті API-сервіси використовують понад 85 000 бізнес-клієнтів, зокрема для автоматичного отримання виписок обліковими сервісами (ПриватБанк). У monobank публічний API працює для рахунків ФОП, і в ньому можна встановити webhook — сповіщення про нові операції (документація monobank API).

Як обрати:

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

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

Крок 5. Нагадування й ескалація

Графік нагадувань записують в умовах, а не вигадують щоразу. Приклад графіка — підберіть під свої умови оплати:

Коли	Що робить система	Хто отримує
За 2–3 дні до строку	Нейтральне нагадування з PDF рахунку і реквізитами	Клієнт
У день строку	Нагадування зі строком і сумою	Клієнт
Через 3 дні після строку	Друге нагадування і задача менеджеру в Telegram	Клієнт, менеджер
Через 7 днів після строку	Дзвінок менеджера, позначка «проблемна оплата», рішення про наступні відвантаження	Менеджер, власник

Три правила, які рятують від незручних ситуацій:

Перед кожним нагадуванням система перевіряє нерозібрані платежі від цього клієнта за кодом ЄДРПОУ. Якщо гроші вже є, але без номера рахунку, нагадування не йде, а платіж іде на розбір.
Ескалацію робить людина. Перші листи можна відправляти автоматично. Розмову про борг веде менеджер.
Часткова оплата змінює суму нагадування. Клієнт отримує нагадування про залишок, а не про всю суму рахунку.

Для розмови з клієнтом у Telegram підходить той самий механізм, що працює в нашій системі для виробництва: ШІ-асистент у призначений день пише клієнту, розбирає відповідь і записує її в картку, а якщо відповідь неясна — перепитує. Там він уточнює деталі замовлень; так само його можна налаштувати питати про очікувану дату оплати. Як влаштувати нагадування й оцінку клієнтів у гуртовій торгівлі, ми розбирали в статті про управління дебіторкою в оптовій компанії.

Крок 6. Звірка і закриття рахунку

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

Номер рахунку в призначенні і сума збігаються — рахунок закривається автоматично.
Код ЄДРПОУ платника збігається з клієнтом, сума дорівнює одному відкритому рахунку — закривається автоматично з позначкою «за сумою».
Код збігається, сума менша — часткова оплата. Залишок лишається відкритим, нагадування йдуть на залишок.
Код збігається, сума дорівнює кільком рахункам разом — система пропонує розподіл, людина підтверджує.
Код не знайдено — платить інша юрособа, власник особисто чи партнер. Платіж іде в чергу «нерозібрані», ШІ пропонує варіант, рішення за людиною.
Переплата — різниця лишається авансом клієнта, бухгалтер отримує сповіщення.

Після закриття система формує видаткову накладну або акт з тих самих даних замовлення, змінює статус на «оплачено» і повідомляє менеджера. Для платників ПДВ дані для податкової накладної передаються в бухгалтерську програму. Саму реєстрацію робить бухгалтер.

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

Українська специфіка: рахунок, накладна, акт і податкова накладна

Автоматизація, яка не враховує правила документів, створює нову роботу для бухгалтера. Ось що варто закласти в процес з першого дня.

Рахунок не підтверджує операцію

За позицією Верховного Суду, рахунок на оплату не є первинним документом: він має інформаційний характер і містить лише платіжні реквізити. Ненадання рахунку не звільняє покупця від оплати, якщо за договором строк рахується від отримання товару. Це постанова від 29.04.2020 у справі № 915/641/19 (огляд ЛІГА:ЗАКОН).

Що з цього випливає для програми:

Факт постачання підтверджує видаткова накладна (товари) або акт (роботи, послуги). Програма має формувати їх з тих самих даних, що й рахунок, без повторного введення.
Строк оплати рахуйте так, як написано в договорі, а не «від дати рахунку» за звичкою. Поле «від чого рахується строк» варто мати в картці договору.
Рахунок без накладної чи акта — незакрите замовлення, навіть якщо гроші прийшли.

Правило першої події: коли виникає ПДВ

Для платника ПДВ дата податкових зобов’язань — раніша з двох подій: зарахування оплати від покупця на ваш рахунок або відвантаження товару. Для послуг замість відвантаження — дата документа, що засвідчує постачання. Це п. 187.1 Податкового кодексу. Платники на касовому методі декларують ПДВ за фактом оплати (розбір DTKT).

Для програми це означає: вона має знати, яка подія настала першою по кожному замовленню.

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

Добре налаштована система показує бухгалтеру список: замовлення, де перша подія вже настала, а дані для податкової накладної ще не передані.

Строки реєстрації і штрафи

Під час воєнного стану і протягом шести місяців після нього податкові накладні за першу половину місяця реєструють до 5 числа наступного місяця, за другу половину — до 18 числа. За порушення строків штраф становить від 2% до 25% суми ПДВ у документі, залежно від тривалості прострочення (buhplatforma.com.ua).

Програма для оформлення замовлень не реєструє накладні сама — це робить бухгалтер у M.E.Doc чи іншій програмі. Але вона може за кілька днів до 5 і 18 числа надіслати бухгалтеру список замовлень, по яких накладна ще не складена. Саме такий список рятує від штрафів, а не ще один календар із нагадуванням «не забути».

Що робить ШІ, а що — формули і правила

Більшу частину процесу виконують правила, а не ШІ. Принцип простий: якщо задачу можна описати формулою або умовою «якщо — то», її робить правило. ШІ потрібен там, де є вільний текст, який треба зрозуміти.

Робить

Розбирає замовлення у вільній формі. Клієнт пише в Telegram: «як минулого разу, тільки 40 штук і доставка на Київ». ШІ знаходить клієнта і минуле замовлення, готує чернетку. Чого бракує — уточнює з клієнтом.
Читає документи. Прайси, специфікації, рахунки постачальників у PDF чи на фото: витягує постачальника, суму, дату, позиції й готує запис на перевірку. Банки теж вбудовують таке розпізнавання: у «Приват24 для бізнесу» можна створити платіж з фото рахунку або з тексту — ШІ розпізнає реквізити, людина перевіряє й підписує (ПриватБанк, грудень 2025).
Пропонує, за що заплатили. Призначення «оплата за фасади, Іваненко» без номера рахунку. ШІ зіставляє його з відкритими замовленнями клієнта і пропонує варіант. Підтверджує людина.
Готує нагадування. Чернетку листа з урахуванням історії: клієнт, який завжди платить на день пізніше, і клієнт, який прострочив уперше, отримують різний тон.
Пише звіти. Щотижня: хто винен, скільки, з якого дня, які платежі не розібрані, по яких замовленнях бракує накладної чи акта.

Не робить

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

Більше прикладів того, що агенти вже виконують у малих компаніях щодня, — у статті ШІ агенти приклади.

Чим оформлювати замовлення: таблиця, бухгалтерська програма, конектори чи система під процес

Чотири варіанти, які реально використовують компанії на 5–100 людей:

Варіант	Коли підходить	Сильне	Слабке
Шаблон в Excel або Google Docs	Рахунки виставляє одна людина, клієнти постійні, платять повністю і вчасно	Нічого не треба впроваджувати	Нумерація, статуси й звірка вручну, нагадувань немає
Бухгалтерська програма (BAS, онлайн-бухгалтерія)	Рахунки виставляє бухгалтер після того, як роботу здано	Документи й облік в одному місці, зазвичай є імпорт виписки	Менеджерам незручно, немає етапів замовлення, розрахунку ціни й задач
Готова CRM плюс конектори (Make, n8n)	Продаж типовий, рахунок за стандартним шаблоном	Швидкий старт, багато готових інтеграцій	Ланцюжки сценаріїв ламаються при змінах, винятки складно описати
Система під процес	Ціна за формулою, кілька юросіб, часткові оплати, виробництво після оплати	Усі правила ваші, один ланцюжок від заявки до звірки	Потрібен тиждень на опис процесу і 2–4 тижні на запуск

Про різницю між Make, n8n і Zapier для українських компаній — у порівнянні платформ автоматизації.

Пороги рішення

Ознаки, що шаблону вже мало:

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

Бухгалтерської програми досить, якщо замовлення прості, без етапів і розрахунку ціни, а рахунок виставляють уже після виконання роботи.

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

Якщо у вас уже є CRM або BAS

Міняти їх не обов’язково. Ми не замінюємо готову CRM клієнта, а додаємо те, чого бракує: розрахунок за формулою, документи з картки, облік оплат, нагадування в Telegram. Як ми впроваджуємо обробку замовлень і заявок на оплату, описано на сторінці послуги автоматизація замовлень і заявок на оплату.

Приклад із наших проєктів: рахунки, оплати й нагадування

Конкретних цифр економії за рахунками ми не наводимо: їх не вимірювали окремо. Нижче — що саме зроблено і що побачили.

Система управління для нашої компанії з виробництва на верстатах з ЧПК

Saloy — наша компанія: меблеві фасади, різьблення, деталі під замовлення. Команда — від 3 до 6 людей. Замовлення змішані: частина з каталогу, частина за кресленням клієнта.

Ціна деталі рахується формулою в системі: площа × ставка × коефіцієнт складності × кількість, плюс заготовка за об’ємом. Рахунок отримує ту саму суму, без перерахунку вручну.
Перша робоча версія з’явилася за 1 день: воронка, картки замовлень і клієнтів, вхід через Telegram, форма з сайту. Рахунки й накладні додали на третьому тижні, разом із виплатами за операції й прибутком власника.
Перед цехом стоять «ворота»: питання до клієнта позначаються на картці, і система попереджає, якщо замовлення з відкритими питаннями намагаються перевести у виробництво. Попереджає, а не блокує. Так само можна налаштувати попередження про відсутню передоплату.
Три ролі: власник, менеджер, виробництво. Прибуток бачить лише власник.

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

Калькулятор для виробника металоконструкцій

Ціну ферм рахував інженер в Excel-книзі на 104 аркуші з понад 2 000 варіантів. Клієнт чекав на розрахунок. За 4 дні ми зробили движок розрахунку і вбудували його в CRM, у якій уже працювали менеджери, — її не міняли. Для кожної заявки система сама формує комерційну пропозицію у фірмовому PDF і розрахунок в Excel із живими формулами.

Перед запуском звірили з Excel на контрольних прикладах — збіглося до копійки. У самому Excel знайшли помилки: для кроку ферм 4,25 м таблиця видавала #Н/Д, у кількох місцях рахувала неточно. Ми не виправляли мовчки, а передали інженеру.

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

ШІ-бот, який відповідає клієнту про борг

Окремий інструмент — бот для клієнтів компанії. Якщо підключені дані клієнта, бот у Telegram чи в чаті на сайті відповідає на питання про статус замовлень і борг, показує ціну для конкретного клієнта і може повторити минуле замовлення. Замовлення бот створює лише чернеткою рахунку, виставляє її менеджер. Скаргу чи складне питання бот передає менеджеру із задачею. Подивитися можна на демо: Telegram-бот @pawlove_demo_bot (вигадана компанія PawLove).

Типові помилки під час автоматизації рахунків і звірки оплат

Автоматизувати хаос

Менеджери по-різному заповнюють замовлення, статуси не стандартизовані, реквізити не перевіряються. Автоматизація такого процесу дає ті самі помилки, тільки швидше. Перед запуском:

залиште один статус, який запускає рахунок;
перевірте реквізити постійних клієнтів;
затвердьте стандартні умови оплати для груп клієнтів;
погодьте один шаблон рахунку для кожної юрособи.

Брати систему «на виріст»

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

Не продумати винятки

Нормальний сценарій «замовлення — рахунок — повна оплата вчасно» автоматизувати легко. Гроші губляться у винятках. Запишіть правило для кожного:

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

Якщо винятків не закласти, через місяць бухгалтер щодня вручну «доналаштовує» систему, і користь зникає.

Віддати відправку повністю автоматиці

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

Запустити без паралельного періоду

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

Не робити резервних копій

Номери рахунків, статуси оплат і історія листування — дані, які неможливо відновити з пам’яті. Щоденна резервна копія і контроль версій потрібні з першого дня, а не після першої втрати.

Коли автоматизація рахунків не потрібна або не допоможе

Чесно про обмеження:

Мало рахунків і постійні клієнти, які платять вчасно. Шаблону й нагадування в календарі досить. Витрати на впровадження не повернуться.
Проблема в умовах, а не в процесі. Якщо пізно платять одні й ті самі клієнти, допоможе передоплата або стоп відвантажень, а не точніші нагадування.
Немає людини, яка розбирає неясні платежі. Черга «нерозібрані» росте, і через місяць ніхто їй не довіряє.
Бухгалтерія на аутсорсі без доступу до даних. Спочатку домовтеся, хто і як завантажує виписки та забирає дані для податкових накладних.
Немає єдиних умов оплати. Поки кожен менеджер домовляється по-своєму, система не знає, коли нагадувати.

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

З чого почати: три кроки

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

Часті питання

Чи потрібен бухгалтер, якщо рахунки й звірка автоматизовані? Так. Система забирає рутину: оформлення, відправку, точні збіги у виписці, нагадування. Бухгалтер лишається відповідальним за облік, податкові накладні, звітність і спірні платежі. Різниця в тому, що він працює з чергою винятків, а не перевіряє кожну оплату.

Чи можна залишити нашу CRM і BAS? Так. Програма для оформлення замовлень може доповнювати їх: брати замовлення з CRM, а в бухгалтерську програму передавати дані документів і оплат. Ми не міняємо готову систему клієнта, а додаємо те, чого бракує. Спосіб обміну визначаємо під час опису процесу.

Чи безпечно давати системі доступ до банку? Для звірки потрібне лише читання виписки, без права на платежі. Код і дані системи належать вам. Ми ставимо її на ваш сервер або на наш, з передачею будь-коли, і робимо щоденну резервну копію.

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