За пределами пакетов: казначейство и налоги в реальном времени

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

Этот способ работы рушится в странах Персидского залива, в Европе, на Ближнем Востоке и в Африке. Две перемены превратили пакетные файлы в прямой бизнес-риск.

Почему ночные файлы перестали работать

• Налоги теперь проверяются в реальном времени. Фаза 2 ZATCA в Саудовской Аравии, схема PINT-AE в ОАЭ и европейский цифровой НДС (ViDA) требуют, чтобы каждый счёт проверялся как XML и криптографически подписывался, в реальном времени или почти в нём, до законного выставления или декларирования.

• Платежи теперь несут подробные данные. ISO 20022 заменяет короткие поля назначения полностью структурированными деталями перевода, в платёжных поручениях (pain.001) и сообщениях управления наличностью (camt.053 и camt.054).

Когда компании добавляют налоговый контроль в реальном времени и ISO 20022 поверх старого промежуточного ПО, результат такой: деньги застревают в пути, сверка идёт вручную, а выставление счетов останавливается при каждой неудачной проверке.

Почему стандартные коннекторы не годятся в эксплуатации

Стандартные коннекторы интеграции хорошо справляются с беспроблемным сценарием. Они не рассчитаны на то, чтобы держать финансовые записи согласованными, когда одновременно приходят тысячи транзакций. В зрелом предприятии снова и снова возникают три проблемы:

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

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

• Две системы, две правды. ERP-система помечает счёт как зарегистрированный, а налоговая отклоняет его подпись. Финансовая команда вручную сторнирует записи в системах, которые не общаются друг с другом.

Как мы это строим

В XSIS мы относимся к интеграции как к инженерии, а не настройке. Надёжный механизм казначейства и соответствия в реальном времени опирается на четыре части.

1. Каждое событие фиксируется один раз

Мы не опрашиваем базу данных ERP по расписанию. Мы фиксируем каждое изменение в момент, когда оно происходит, через транзакционный outbox или собственный event mesh ERP. Каждое финансовое событие получает стабильный ключ по происхождению документа, поэтому обрабатывается ровно один раз в банковских и налоговых системах.

2. Проверки до того, как что-то уйдёт

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

3. Один внутренний формат для каждого банка

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

4. Выписки сверяются автоматически

Выписки по счёту (camt.053) и уведомления о мгновенных платежах (camt.054) читаются и сверяются с открытой дебиторской задолженностью по чётким правилам. Более 99 % строк сверяются без ручного шага, и до человека доходят только настоящие исключения.

С чего начать

Не нужно заменять ERP, чтобы покончить с задержками пакетной обработки. Начните с диагностики существующей системы: за одну или две недели мы картируем, где теряются данные между ERP, промежуточным ПО и вашими банками. Затем переведите в реальный режим сначала самые болезненные циклы сверки.