Автоматизація заявок на оплату: погодження в Telegram

Автоматизація заявок на оплату потрібна тоді, коли власник уже не пам’ятає, який рахунок погодив, бухгалтер не знає, що з купи PDF платити сьогодні, а постачальник телефонує втретє. Рахунки приходять на пошту, у Viber, у Telegram і фотографією з паперу. Погодження звучить як «так, плати» в коридорі. Реєстр живе в Excel, і в ньому завжди є рядок «уточнити».

Стаття для власників і фінансистів компаній на 5–100 людей: виробництво під замовлення, будівництво й монтаж, сервіс, проєктні компанії. Ми пройдемо маршрут одного рахунку постачальника: заявка з рахунком, прив’язка до замовлення чи закупівлі, погодження власником у Telegram, реєстр платежів на день і відмітка про оплату. Покажемо, які поля потрібні, які перевірки ставити до погодження, які пороги задати і що тут робить штучний інтелект.

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

Коротко

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

Заявка на оплату і рахунок постачальника: у чому різниця

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

Рахунок пише постачальник, заявку — ваша людина

Рахунок на оплату — документ постачальника. У ньому його реквізити, перелік товарів чи робіт, сума, ПДВ і строк оплати. Рахунок відповідає на питання «скільки і куди платити».

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

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

Що має бути в заявці: чекліст полів

Почніть із мінімуму. Кожне поле має відповідати на питання, яке власник інакше поставить голосом.

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

Більше полів на старті не потрібно. Довгий бланк заповнюють погано, і заявки знову йдуть повз систему.

Як сьогодні оплачують рахунки і де губляться гроші

Згадайте останні десять оплачених рахунків і те, як вони йшли насправді.

Типовий шлях рахунку без системи

Постачальник надсилає рахунок менеджеру з постачання або виконробу: поштою, у месенджер, іноді фотографією.
Менеджер пересилає рахунок бухгалтеру з коментарем «треба оплатити» або взагалі без коментаря.
Бухгалтер вносить рядок в Excel-реєстр і питає власника: «Оплачуємо?»
Власник відповідає в месенджері, голосом або на нараді. Часто — не бачачи самого рахунку.
Бухгалтер формує платіж у банку, підписує сам або чекає підпису власника.
Хтось має сказати менеджеру, що оплачено. Найчастіше він дізнається це від постачальника.
Накладна, акт і податкова накладна приходять пізніше. Хто перевіряє, що вони прийшли, ніхто точно не скаже.

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

Шість місць, де губляться гроші

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

Для малої компанії одна така помилка помітна в прибутку. За даними Опендатабота, у малому бізнесі рентабельність продажів понад 5% має лише половина компаній. За такої маржі подвійна оплата одного великого рахунку з’їдає прибуток кількох замовлень.

Автоматизація заявок на оплату: маршрут рахунку в 7 кроків

Ось маршрут, який ми закладаємо в систему. Кожен крок має одного відповідального і статус, який видно всім, кому дано доступ.

Крок 1. Заявка з рахунком — в одному місці

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

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

Крок 2. ШІ читає рахунок і заповнює поля

ШІ розбирає PDF, скан або фото рахунку. Він виписує постачальника, код ЄДРПОУ, IBAN, номер і дату рахунку, позиції, суму, ПДВ і строк оплати, якщо його вказано. Заявник бачить заповнену чернетку й виправляє, якщо щось не так.

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

Крок 3. Прив’язка до замовлення чи закупівлі

Кожна заявка прив’язується до того, що пояснює витрату. Для виробництва й монтажу — до замовлення клієнта або закупівлі під нього. Для загальних витрат — до статті.

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

Крок 4. Перевірки до погодження

До власника заявка йде вже перевіреною. Система не забороняє, а попереджає й пише, що саме не так:

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

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

Крок 5. Погодження власником у Telegram

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

Крок 6. Реєстр платежів на день

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

Крок 7. Відмітка про оплату і закриття

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

Оплата — ще не кінець. Заявку закривають, коли прийшли товар чи роботи і документи: видаткова накладна або акт, а для платника ПДВ — зареєстрована податкова накладна. Поки документів немає, заявка лишається в списку «оплачено, чекаємо документи».

Погодження в Telegram: що бачить власник і що він натискає

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

Що є в повідомленні

Приблизно так виглядає повідомлення власнику (дані умовні):

Заявка на оплату — Олена, постачання
Постачальник: ТОВ «Деревпостач» (з довідника, реквізити підтверджені)
Сума: 48 600,00 з ПДВ, рахунок 312 від 28.10
За що: фанера березова 18 мм, 40 листів
Замовлення: кухня для клієнта Коваленко, 1047
Матеріали по замовленню: після оплати — у межах розрахунку
Оплатити до: 31.10, інакше відвантаження перенесуть
Попереджень немає
[Погодити] [Відхилити] [Питання] [Пізніше]

Обов’язковий мінімум: хто просить, постачальник, сума, за що, замовлення чи стаття, стан бюджету, строк і попередження. Окрема кнопка відкриває сам рахунок. Якщо власнику щоразу доводиться відкривати PDF, щоб зрозуміти, про що йдеться, — у повідомленні бракує поля.

Кнопки і що відбувається після натискання

Telegram дозволяє ставити кнопки прямо під повідомленням бота. Натискання такої кнопки не надсилає повідомлення в чат, а передає дію боту, і бот може оновити повідомлення на місці (документація Telegram для ботів). Тому власник не пише «ок», а натискає кнопку, і стрічка лишається чистою.

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

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

Кнопки працюють лише для людей із відповідною роллю. Система впізнає людину за її Telegram-акаунтом, тому переслане повідомлення чуже погодження не дасть.

Хто погоджує яку суму: пороги

Не все має йти власнику. Ось типова схема, яку варто підлаштувати під себе.

Яка оплата	Хто погоджує	Примітка
Повторна закупівля в перевіреного постачальника, у межах розрахунку замовлення, нижче порогу	керівник напряму	власник бачить її у вечірньому підсумку
Будь-яка сума вище порогу	власник	поріг задаєте ви
Новий постачальник або змінені реквізити	власник, завжди	незалежно від суми
Повна передоплата наперед	власник	особливо для нового постачальника
Витрата понад розрахунок замовлення чи бюджет статті	власник	із причиною перевищення
Податки, зарплата, оренда за договором	бухгалтер за графіком	власник погоджує реєстр загалом

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

Як обрати поріг

Поріг — не про довіру до людей, а про увагу власника. Кілька практичних орієнтирів:

Рахуйте від кількості, а не від суми. Поріг ставте так, щоб власнику приходило не більше 5–10 погоджень на день. Більше — він почне погоджувати не дивлячись.
Під порогом — повторюване. Регулярні дрібні закупівлі в постійних постачальників, витратні матеріали, доставка.
Нове — завжди власнику. Новий постачальник, нові реквізити, новий тип витрат.
Переглядайте поріг раз на квартал. Подивіться в історії, скільки заявок власник відхилив або поставив питання. Якщо в якомусь діапазоні сум він ні разу нічого не відхилив — поріг можна підняти.

Відпустка, заміщення і нагадування

Власник не завжди на зв’язку. Тому одразу задайте три правила.

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

Реєстр платежів на день

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

Як збирається реєстр

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

У реєстрі для кожного платежу є:

постачальник, код ЄДРПОУ, IBAN;
сума і призначення платежу, складене з даних заявки;
рахунок компанії, з якого платити, якщо їх кілька;
строк і пріоритет;
посилання на заявку з рахунком та історією погодження.

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

Термінові оплати поза реєстром теж трапляються. Їх не забороняють, але позначають окремо. Якщо термінових багато, проблема не в бухгалтері, а в тому, що заявки подають запізно.

Коли грошей менше, ніж рахунків: черговість

Задайте черговість заздалегідь, а не в день, коли грошей забракло.

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

Власник бачить, що перенесено і чому. Заявник отримує сповіщення й попереджає постачальника заздалегідь, а не тоді, коли той уже телефонує.

Погоджені заявки з датами разом з очікуваними оплатами від клієнтів — це і є платіжний календар. Він показує касовий розрив за тиждень до того, як той настане. Як звести такий календар у звіт власника, ми писали в статті про P&L, Cash Flow і звіт власника без Excel.

Відмітка про оплату: з виписки, а не вручну

Ручна позначка «оплачено» — слабке місце. Її забувають поставити або ставлять наперед. Краще, коли система бере дані з виписки банку.

У ПриватБанку для цього є API: баланс і транзакції за рахунками, а також створення платежів у «Приват24 для бізнесу». Сервіс «Автоклієнт» імпортує вхідні й надсилає вихідні платежі у форматах CSV або DBF. Банк пише, що сервіс безкоштовний для клієнтів, а для юридичних осіб доступний на тарифах «Бізнес Комфорт» і «Бізнес ПРО» (ПриватБанк, інтеграція). У monobank є відкритий API з випискою за особистим рахунком і рахунками ФОП (документація monobank). З іншими банками працює щоденне завантаження файлу виписки.

Система зіставляє платіж із заявкою за IBAN отримувача, сумою і номером рахунку в призначенні. Що не зіставилося — бухгалтер розбирає вручну. Це заодно показує оплати, зроблені повз систему. Та сама логіка працює для оплат від клієнтів — про це в статті рахунок, оплата і звірка без ручної роботи.

Скільки коштує ручне погодження: як порахувати

Перш ніж щось змінювати, порахуйте, у що вам обходиться поточний спосіб. Це займе годину.

Формула

Витрати на місяць = кількість рахунків × хвилини всіх учасників на один рахунок ÷ 60 × вартість години + прямі втрати від помилок.

Хвилини рахуйте для всіх: заявник шукає рахунок і пише бухгалтеру, бухгалтер вносить рядок і перевіряє реквізити, власник відкриває, питає й відповідає, бухгалтер платить, хтось повідомляє заявника. Додайте час на дзвінки «а це вже оплачено?».

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

Умовний приклад

Цифри нижче — приклад для розрахунку, а не дані конкретної компанії. Компанія отримує 150 рахунків на місяць. На один рахунок разом іде 25 хвилин часу різних людей. Це 62,5 години на місяць. Якщо година в середньому коштує компанії 250 гривень, лише час обходиться приблизно в 15 600 гривень на місяць.

Тепер припустімо, що після запуску заявник витрачає 3 хвилини, власник — 1, бухгалтер — 3. Разом 7 хвилин на рахунок, тобто 17,5 години на місяць. Різниця — 45 годин, і більша частина з них — час бухгалтера і власника.

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

Що міряти до і після

Не довіряйте відчуттям. Виміряйте на 20–30 рахунках до запуску і через місяць після:

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

Дослідження великих компаній показують той самий напрям. За даними Ardent Partners, найкращі фінансові команди обробляють рахунки на 82% швидше і на 78% дешевше в розрахунку на рахунок, ніж решта (Ardent Partners). Це дані про корпорації, а не про компанію на 20 людей. Але причина та сама: швидкість і ціна залежать від кількості ручних передач між людьми.

Що робить ШІ, а чого не робить

ШІ в цьому процесі економить час на рутині з документами. Рішення про гроші він не ухвалює.

Робить

Читає рахунки в PDF, сканах і на фото. Виписує реквізити, позиції, суми, ПДВ і строк.
Порівнює рахунок із довідником постачальників і з погодженою закупівлею, позначає розбіжності.
Пропонує прив’язку до замовлення за позиціями й заявником. Людина підтверджує.
Розбирає повідомлення у вільній формі. «Оплатіть Деревпостачу за фанеру на кухню Коваленка» перетворюється на чернетку заявки з потрібними полями.
Готує чернетку відповіді постачальнику, наприклад про дату оплати. Надсилає її людина.
Пише звіт: скільки погоджено за тиждень, на які замовлення, що чекає і на кому застрягає.

Не робить

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

Як перевірити ШІ на своїх рахунках

Візьміть 30–50 реальних рахунків за останні місяці: різні постачальники, формати, погані фото. Порівняйте, що заповнив ШІ, з тим, що в документі. Окремо подивіться на поля, де помилка коштує дорого: IBAN, код ЄДРПОУ, сума. Для них правило просте: заявник підтверджує, а IBAN завжди звіряється з довідником.

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

Захист від помилок і шахрайства

Найдорожча помилка в оплатах — гроші, які пішли не туди. Повернути їх важко, а іноді неможливо.

Підміна реквізитів

Схема проста: шахрай пише від імені постачальника, що в того змінився рахунок, або підміняє IBAN у самому рахунку. За звітом IC3 ФБР, який наводить Nacha, у 2024 році заявлені збитки від компрометації ділової пошти склали близько $2,8 млрд за 21 442 скаргами (Nacha). В опитуванні фінансистів AFP 76% організацій повідомили про спроби або випадки платіжного шахрайства у 2025 році (AFP).

В Україні схема та сама. «Економічна правда» описувала, як зловмисники отримують доступ до пошти компанії і вписують у платіжні документи свої рахунки, а працівники не помічають, що цифри змінилися (Економічна правда).

Правила, які варто вшити в систему:

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

Дублі

Дубль ловлять двома перевірками. Жорстка: той самий постачальник, номер і дата рахунку. М’яка: той самий постачальник і та сама сума за короткий період. Жорстка зупиняє заявку до пояснення, м’яка лише попереджає. Буває, що постачальник перевиставив рахунок із новим номером на ту саму поставку, — тоді старий треба позначити як скасований.

Розподіл ролей

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

Ролі бачать різне. У системі Saloy, нашої компанії з виробництва на верстатах з ЧПК, три ролі: власник, менеджер, виробництво. Прибуток бачить лише власник. Для заявок на оплату логіка та сама. Заявник бачить свої заявки й статуси. Бухгалтер — реєстр і реквізити. Власник — усе, включно з маржею замовлень.

Доступ до банку і резервні копії

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

Історію погоджень потрібно берегти так само, як бухгалтерію. У Saloy одного разу оновлення зі старої копії затерло свіжий модуль, і відновлювали його вручну. Відтоді правило в усіх наших проєктах: контроль версій і щоденні резервні копії з першого дня.

Українська специфіка: банк, документи, ПДВ

Маршрут заявки однаковий скрізь, але кілька українських деталей варто закласти одразу.

Платіжна інструкція і призначення платежу

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

Платежі в банк: файл або API

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

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

Документи після оплати і ПДВ

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

Система не замінює ні сервіси документообігу, ні програму звітності на кшталт M.E.Doc. Вона показує список «оплачено — немає накладної» і нагадує заявнику, бо саме в нього контакт постачальника. Так документи не збираються в останній день місяця.

Готова програма чи своя система

Заявки на оплату можна вести в кількох видах програм. Чесне порівняння:

Варіант	Що добре	Чого бракує	Кому підходить
Excel або Google Таблиці	безкоштовно, звично	немає погодження з історією, дублі ловить лише уважність	кілька рахунків на тиждень, один заявник
Сервіс фінансового обліку, наприклад Finmap	рух грошей, планові платежі, звіти	головне призначення — облік грошей, а не маршрут заявки від виконроба до власника	компаніям, яким потрібен насамперед звіт про гроші
Облікова програма, наприклад BAS	бухгалтерія, банк, первинні документи, податки	інтерфейс для бухгалтера, а не для виконроба і власника з телефона	компаніям, де весь облік уже веде бухгалтерія в цій програмі
Готова CRM із конструктором процесів, наприклад Bitrix24	можна зібрати маршрут погодження	погодження у їхньому застосунку, прив’язка до вашої собівартості — через налаштування	компаніям, які вже працюють у цій CRM
Своя система під процес	поля, пороги й маршрут під вас, Telegram як інтерфейс, прив’язка до замовлень і собівартості	потрібен опис процесу і підтримка	коли оплати пов’язані із замовленнями, а заявників кілька

Коли досить таблиці

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

У такому разі заведіть таблицю з полями з чекліста вище і правилом: без рядка в таблиці не платимо.

Коли варто своя система

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

Якщо сумніваєтеся, пройдіть короткий тест «Готова CRM чи своя система».

Що вже є в основі наших систем

Документи, оплати, ролі, вхід через Telegram і сповіщення в Telegram уже працюють у наших проєктах. Рахунок, видаткова накладна, акт і PDF формуються з картки. Модуль заявок на оплату збирається з цих блоків: заявка, маршрут погодження, реєстр, відмітка з виписки. Перша робоча версія — за кілька днів, уся система — за 2–4 тижні після опису процесу. Два тижні нова система працює паралельно зі старим способом, щоб звірити результат.

У Saloy Telegram — основний інтерфейс: співробітники заходять у систему через нього і там отримують задачі та нагадування. Рахунки, накладні й прибуток власника додали на третьому тижні. Як ми ухвалювали рішення і що не підійшло в готових програмах, описано в кейсі власної системи управління.

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

Коли автоматизація заявок на оплату не спрацює

Є ситуації, коли система не допоможе або допоможе мало. Краще знати це до запуску.

Власник не відмовляється від погодження голосом

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

Немає розрахунку на замовлення

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

Бухгалтер на аутсорсі

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

Багато готівки і карток

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

З чого почати цього тижня

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

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

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

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

Чи може ШІ сам погоджувати дрібні рахунки? Ми так не робимо. Дрібні рахунки нижче порогу погоджує керівник напряму, а власник бачить їх у вечірньому підсумку. ШІ готує заявку й попереджає про ризики, але рішення про гроші завжди за людиною.

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

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