Розпізнавання та погодження вхідних первинних документів
Демонстраційний сценарій: скануємо рахунки, акти й накладні, витягуємо реквізити, перевіряємо правила. Якщо модель не впевнена — віддаємо оператору.
Опис бізнес-ситуації
Компанія отримує десятки рахунків, актів виконаних робіт і товарних накладних від різних постачальників. У PDF, сканах, на фото. І бухгалтер щодня до 4 годин вносить суми руками, перевіряє ЄДРПОУ, номери рахунків IBAN і шукає, до якого договору що прив’язати.
Схема потоку даних та архітектура
Роль людини в контурі (Human-in-the-loop)
Якщо хоч по одному полю система впевнена менше ніж на 95% або сума документа перевищує ліміт, документ підсвічується. І бухгалтер обов’язково підтверджує його в зручному вебінтерфейсі.
Приклад вхідного запису та відповіді системи
Обмеження демонстраційного сценарію
- ✕Без підпису ЕЦП/КЕП бухгалтера система гроші з рахунку не спише
- ✕Пошкоджені чи нечитабельні скани отримують позначку «Потребує повторного запиту оригіналу»
- ✕Якщо змінилися договірні ціни, система звіряє їх із зафіксованими умовами специфікацій
Що вимірювати під час пілотного тестування
- ✓Точність витягування обов’язкових полів (ЄДРПОУ, сума, номер, дата) — ціль: > 98%
- ✓Скільки часу йде на один документ (ціль: < 15 секунд)
- ✓Частка документів, які пройшли без жодного ручного виправлення
Автоматизація оброблення документів
Цікавить схожа архітектура?
Підлаштуємо логіку цього сценарію під ваші внутрішні програми, структуру баз даних і регламенти.
Обговорити адаптаціюАдаптація сценарію: Розпізнавання та погодження документів
Опишіть процес, який з’їдає час вашої команди. Ми підкажемо, що тут можна автоматизувати, які дані для цього потрібні і з чого почати.