AUT-0467· Фінанси
Розгляд винятків Positive Pay для виданих чеків
Фінансист перевіряє чекові винятки банку за реєстром виданих чеків і передає своєчасне погоджене рішення уповноваженому користувачу банку.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Банк показує чек, який не збігся з реєстром виданих чеків, але сповіщення губиться або рішення приймають без перевірки рахунку, номера, суми, отримувача та підстави виплати.
02 / Результат
Кожний виняток має джерельний запис, причину розбіжності, доказ перевірки, уповноваженого погоджувача, передане до банку рішення та підтверджений результат до банківського строку.
03 / Процес
ТригерБанк надіслав Positive Pay виняток щодо чека, якого немає у файлі видачі або чиї реквізити не збіглися. · Потрібно перевірити повторний номер, суму, статус скасування, дату чи ім’я отримувача до рішення банку.
Отримати виняток із банківського порталу або погодженого каналу та записати рахунок, номер чека, суму, дату, отримувача, причину й строк рішення.
Зіставити його з авторитетним реєстром випущених і скасованих чеків, затвердженим рахунком постачальника, рахунком-фактурою та документом погодження.
Якщо доступне зображення, перевірити лицьовий і зворотний бік, отримувача, індосамент і ознаки зміни; невідомий, дубльований або змінений чек передати на ескалацію.
Визначити маршрут: підтверджений чек, виправлення файлу видачі, перевірка скасування або потенційне шахрайство. Не створювати оплату з задачі й не змінювати банківський запис автоматично.
За розділенням обов’язків фінансовий reviewer перевіряє висновок, а окремий уповноважений користувач ухвалює `pay` або `return` у порталі банку до фактичного строку.
Зафіксувати рішення, підставу, особу, час і банківське підтвердження; якщо рішення не передано, негайно ескалувати за фактичною політикою банку.
Після обробки звірити результат із банківським звітом і реєстром видачі; несподіване проведення повідомити банку й передати до окремого процесу реагування на платіжне шахрайство.
Зберігати лише потрібні метадані й захищені посилання на зображення; не копіювати повний номер рахунку або банківські облікові дані в загальні задачі.
04 / Реалізація2 варіанти
Приклад · Ручний розгляд із банківським рішенням
Банк знайшов чек на 18 400 USD без збігу в issue file. Фінансист перевірив номер, суму й отримувача за затвердженим рахунком, не знайшов дозволу на видачу й передав підтверджене рішення `return` авторизованому користувачу до банківського строку.
Спосіб реалізації
- Вести задачу з банківським ID винятку, рахунком, номером чека, сумою, причиною та часом cut-off.
- Додати контрольний список джерел звірки й окремі ролі reviewer та банківського approver.
- Зберігати обране рішення, час передачі й ідентифікатор банківського підтвердження; звірити його наступним звітом.
Що потрібно для реалізації
- Банк пропонує Positive Pay для рахунку та повідомляє чинні формати реєстру, типи винятків, строки й наслідки відсутності рішення.
- Є повний і актуальний реєстр чеків, ідентифікатори рахунків, одержувачі, суми, причини видачі та статуси скасування.
- Визначені різні ролі підготовки, перевірки та банківського рішення; доступ до зображень і фінансових даних обмежено.
- Погоджені порядок перевірки підозрілих винятків, резервний контакт банку, часовий пояс та канал ескалації до cut-off.
- Є доступ до порталу банку, актуальний реєстр чеків і резервний відповідальний на час відсутності основного.
Обмеження
- Positive Pay, payee matching, типи винятків, строки й результат бездіяльності залежать від конкретного банку, рахунку та договору; не задавати універсальне рішення за замовчуванням.
- Банк зіставляє представлені чеки з реєстром клієнта й показує невідповідності; фінансовий фахівець має визначити, чи платити або повертати чек.
- PlanFix може координувати відповідальних, дедлайн, докази й ескалацію. Остаточне рішення виконує уповноважений користувач у банківському каналі.
- Не підключає банківський портал без окремого підтвердженого інтерфейсу й правил безпеки; не гарантує відшкодування збитків.
- Години попередні; доступність функцій, обсяг чеків, кількість рахунків і спосіб передавання даних потрібно перевірити з банком.
- Користувачі вносять і перевіряють винятки вручну; у разі високого обсягу потрібен додатковий контроль зміни.
Що потрібно уточнити (2)
- Чи потрібно вести винятки для кількох банківських рахунків?
Потрібно звірити окремі ролі, часові пояси, календарі та дедлайни кожного рахунку.
- Чи потрібно передавати issue file та отримувати винятки автоматично?
Спочатку підтвердьте з банком формат, підтриманий канал, тестування й права користувачів.