Фінансовий документообіг: від рахунку до підтвердженої оплати

Електронний документообіг (ЕДО) має пов'язати документи й дії людей із записами в інших системах. Для цього потрібні окремі відповіді: що отримано, що перевірено, яке рішення ухвалено та чим підтверджений стан оплати. Саме такі переходи варто проєктувати й перевіряти під час автоматизації.

Матеріал оновлено 24 вересня 2026 року. Нормативні й технічні джерела перевірено на цю дату.

З'ясуйте, яку операцію описують документи

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

Стаття 1 Закону № 996-XIV визначає первинний документ через відомості про господарську операцію. Стаття 9 встановлює первинні документи підставою бухгалтерського обліку та визначає вимоги до їх оформлення. Паперова й електронна форми допускаються за застосовних умов. Тому назва «рахунок» сама не вирішує, чи достатньо документа для конкретного облікового відображення.

Практичний початок перевірки — пов'язати рахунок із замовленням або договором та потрібними підтвердними матеріалами. Для нашої поставки пропонуємо виділити такі відомості:

• Постачальник. Хто виставив документ і з ким пов'язане замовлення.
• Предмет поставки. Які матеріали очікували та які надійшли.
• Кількість і вартість. Одиниці виміру, ціни, суми та умови їх визначення.
• Підстава. Договір, замовлення або інший документ, із яким зіставляють операцію.

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

Дайте кожному статусу зрозуміле значення

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

Microsoft у документації Dynamics 365 Finance описує двостороннє звірення ціни рахунку із замовленням, а тристороннє доповнює його перевіркою кількості за надходженням. Політики й допуски налаштовуються. Це приклад механізму конкретної ERP, а не готова функція будь-якої системи документообігу чи законодавчий обов'язок застосовувати саме таку схему.

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

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

Погоджуйте конкретну дію, а не файл загалом

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

За частиною 6 статті 18 Закону № 2155-VIII кваліфікований електронний підпис (КЕП) має силу власноручного підпису та презумпцію відповідності йому. Це правило про підпис. Сам результат його перевірки не встановлює, скільки матеріалів фактично прийнято або чи виконаний платіж.

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

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

Перевірте, що саме прийняла облікова система

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

У Dynamics 365 Finance окремо налаштовуються передавання імпортованих рахунків у процес погодження та зіставлення їхніх рядків із надходженнями. Microsoft описує й фонове виконання цих кроків. Отже, сам факт імпорту не підтверджує проходження всіх потрібних перевірок; окремі перевірки можуть виконуватися і під час імпорту.

• Зіставте записи. Пов'яжіть ідентифікатор документа в ЕДО із записом в ERP.
• Перевірте передані дані. Звірте сторону, суму, валюту, кількість і потрібні посилання.
• Отримайте результат. Збережіть відповідь системи, час та причину відмови, якщо вона є.
• Перевірте повторну спробу. З'ясуйте долю попереднього запиту й погодьте спосіб повтору без нового дубля.

Виробник Megapolis.DocNet описує електронні картки, облік дій і відкритий API для інтеграції з ERP та обліковими системами. Наявність API дає основу для обміну, але склад полів, відповіді й обробку помилок потрібно узгодити для конкретного впровадження.

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

Підтверджуйте оплату за конкретною операцією

Документація Microsoft щодо банківського звірення описує імпорт і перевірку виписки та зіставлення її рядків з обліковими банківськими операціями. Це механізм Dynamics 365 Finance, а не правило українського банку. Для нашого процесу корисний принцип — пов'язати стан оплати з конкретним підтвердним записом.

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

Для обговорення з IQusion підготуйте одну тестову поставку: документи, розбіжність, погодження, обмін з ERP і потрібне підтвердження оплати. Пройдіть її за ролями та запишіть, де бракує відповіді, зв'язку між записами або відповідального. Це стане конкретним завданням для автоматизації.

Поширені питання

Джерела

• Закон України «Про бухгалтерський облік та фінансову звітність в Україні» № 996-XIV
• Закон України «Про електронну ідентифікацію та електронні довірчі послуги» № 2155-VIII
• Деталі і функціонал системи Megapolis.DocNet
• Accounts payable invoice matching overview
• Submit invoices to the workflow system and match product receipt lines
• Reconcile bank statements by using advanced bank reconciliation