Казначейство й податки в реальному часі між ERP і банками

Двадцять років корпоративні фінанси жили із затримкою. ERP (SAP S/4HANA, Oracle чи Odoo) закривала облік за день. Заплановане завдання надсилало плоскі файли CSV чи MT940 до банку через SFTP. Команда чекала до наступного ранку, щоб дізнатися, що банк прийняв, а що відхилив.

Цей спосіб роботи перестає працювати в країнах GCC, Європі, на Близькому Сході й в Африці. Дві зміни перетворили пакетні файли на прямий бізнес-ризик.

Чому нічні файли перестали працювати

• Податки тепер перевіряються в реальному часі. Друга фаза ZATCA в Саудівській Аравії, рамкова програма PINT-AE в ОАЕ і європейська ініціатива VAT in the Digital Age (ViDA) вимагають, щоб кожну фактуру перевіряли як XML і криптографічно штампували в реальному часі чи майже в реальному часі, перш ніж її можна законно виставити чи сплатити.

• Платежі тепер передають розширені дані. ISO 20022 замінює короткі поля посилань повністю структурованими даними призначення платежу в платіжних дорученнях (pain.001) і в повідомленнях управління грошовими коштами (camt.053 і camt.054).

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

Чому стандартні конектори не справляються в промисловій експлуатації

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

• Дані губляться в перекладі. Нетипові таблиці ERP рідко зіставляються чисто зі строгими схемами ISO 20022 чи електронними фактурами UBL 2.1 без ретельного шару зіставлення на основі правил.

• Дублікати під час повтору. Коли банк чи податковий шлюз не встигає відповісти під навантаженням, простий повтор може надіслати той самий платіж двічі чи подати ту саму фактуру двічі.

• Дві системи, дві істини. ERP позначає фактуру як проведену, а податковий орган відхиляє її штамп. Фінансова команда вручну сторнує записи в системах, які не розмовляють одна з одною.

Як ми це будуємо

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

1. Кожна подія зафіксована один раз

Ми не опитуємо базу даних ERP. Ми фіксуємо кожну зміну, коли вона відбувається, через патерн transactional outbox чи власну подієву сітку ERP. Кожна фінансова подія отримує стабільний ключ на основі походження документа, тож її обробляють рівно один раз у банківських і податкових системах.

2. Перевірки до того, як щось вийде

Перш ніж повідомлення дійде до банку чи податкового порталу, окремий рушій перевірки звіряє XML зі схемою, накладає криптографічний підпис (CSID чи X.509) і створює потрібний QR-код і ланцюг хешів. Усе це займає менш ніж 50 мілісекунд.

3. Один внутрішній формат для всіх банків

Між ERP і зовнішнім світом лежить версіонована внутрішня модель даних. Додавання нового банку чи перехід з повідомлень MT на MX не означає переписування коду ABAP чи PL/SQL в ERP.

4. Банківські виписки зіставляються автоматично

Банківські виписки (camt.053) і повідомлення про миттєві платежі (camt.054) читаються й зіставляються з відкритою дебіторською заборгованістю за чіткими правилами. Понад 99% позицій звіряються без ручного кроку, і до людини потрапляють лише справжні винятки.

З чого почати

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