Чем отличаются Settlement и Reconciliation в EWA?
Settlement и Reconciliation — связанные уровни с разными целями. В архитектуре EWA Settlement завершает и фиксирует финансовый результат операции или расчётного периода, а Reconciliation сопоставляет независимые источники, чтобы подтвердить одинаковое отражение результата в учёте рабочего времени, банковских операциях и расчёте зарплаты.
Прежде всего: оба процесса связаны с деньгами, но отвечают на разные вопросы
Эти термины часто смешивают, поскольку оба процесса возникают после создания операции.
Однако их можно чётко разделить:
- Settlement: «Как это финансовое обязательство окончательно исполнено и отражено?»
- Reconciliation: «Отражают ли независимые системы одинаковый результат?»
Если объединить эти процессы, система может считать записанный результат верным, хотя независимая сверка ещё не проводилась.
Что означает Settlement в этой статье?
Банки, платёжные шлюзы и зарплатные системы могут по-разному использовать термин «settlement».
Здесь Settlement означает этап, на котором устанавливается окончательный финансовый результат операции или рабочего периода.
Например, для операции EWA:
- создаётся запрос;
- банк подтверждает результат;
- система определяет фактически выплаченную сумму;
- реестр операций фиксирует полученную сумму;
- обновляется остаток зарплаты.
На уровне расчётного периода Settlement также включает:
- суммирование подтверждённых выплат EWA;
- отражение правильной общей суммы в расчёте зарплаты;
- определение остатка к выплате в периоде;
- закрытие исполненных обязательств.
Таким образом, Settlement сосредоточен на исполнении финансового обязательства.
Что означает Reconciliation?
Reconciliation — процесс сопоставления двух или более независимых источников данных, чтобы определить, совпадают ли они.
Например:
- реестр EWA отражает выплату 500 000 вьетнамских донгов;
- в банковской выписке должна быть соответствующая операция;
- расчёт зарплаты в конце периода должен учитывать уже полученную сумму;
- в расчётном листке она не должна удерживаться дважды.
Если источники совпадают, операция или период считаются сверенными.
Если они не совпадают, расхождение должно попасть в очередь исключений.
Reconciliation не создаёт операции и не должен менять цифры только ради совпадения отчётов.
Сравнение Settlement и Reconciliation
| Критерий | Settlement | Reconciliation |
|---|---|---|
| Главный вопрос | Как исполнено финансовое обязательство? | Совпадают ли реестры? |
| Время | Во время/после жизненного цикла операции или в конце периода | После появления данных из нескольких источников |
| Основные данные | Статус операции, сумма, период | Реестр EWA, банк, зарплата |
| Результат | Выплаченная/урегулированная/оставшаяся сумма | Совпадение или исключение |
| Создаёт операцию? | Может участвовать в завершении операции | Нет |
| Выявляет расхождения? | Возможно, но это не главная цель | Да, это главная цель |
| Закрывает период? | Может помочь закрыть обязательства | Подтверждает данные до закрытия |
| При неопределённости | Сохраняет подходящий статус | Направляет в очередь исключений/расследования |
Эти уровни должны быть связаны, но не могут заменять друг друга.
Как операция проходит через Settlement?
Типовой процесс может выглядеть так:
- запрос соответствует условиям;
- Payment Orchestration создаёт операцию;
- банк обрабатывает её;
- определяется окончательный статус;
- успешная операция проводится в реестре «получено»;
- соответствующая сумма блокируется от повторного использования;
- обязательство по операции считается исполненным.
Если банковский статус неясен, Settlement не должен самостоятельно делать вывод.
Здесь применяется принцип fail-closed: если результат неясен, не закрывать операцию ни как успешную, ни как неуспешную.
Как операция проходит через Reconciliation?
Когда становятся доступны независимые данные, система сопоставляет:
- внутренний ID операции;
- банковский код или ссылку;
- сумму;
- получателя;
- время;
- статус;
- расчётный период;
- сумму, отражённую в зарплате.
Если всё совпадает, операцию можно отметить как успешно сверенную.
Если отличается хотя бы одно поле, система создаёт исключение.
Ключевой момент: Reconciliation использует независимый источник для проверки результата, записанного системой.
Почему ответа API недостаточно, чтобы считать сверку выполненной?
Банковский API может вернуть статус «успешно» в ходе обработки.
Это важный сигнал, однако финансовая система всё равно должна позже выполнить независимую сверку.
Причины:
- ответ в реальном времени может потеряться или оказаться ошибочным;
- внутренняя система может записать неверный статус;
- операция может быть зарегистрирована дважды;
- банковская выписка может содержать отсутствующую во внутренней системе операцию;
- зарплатная система может использовать неверный период.
Reconciliation обеспечивает окончательную проверку.
Чем Settlement в конце периода отличается от Settlement отдельной операции?
Возможны два уровня.
Уровень операции
Определяется, была ли выполнена конкретная выплата, в каком размере, и результат записывается в реестр операций.
Уровень расчётного периода
Суммируются все операции периода и определяются:
- общая уже полученная сумма;
- возвраты или корректировки;
- сумма, которую нужно отразить в расчёте зарплаты;
- остаток зарплаты.
На обоих уровнях нужны прослеживаемые данные.
Почему нельзя «сверять, изменяя цифры до совпадения»?
Опасная ошибка возникает, когда при расхождении двух реестров оператор вручную меняет один из них, чтобы итоговые суммы совпали.
Это уничтожает доказательства причины.
Правильный процесс:
- сохранить исходные данные;
- создать исключение;
- определить причину;
- установить, какой реестр неверен;
- внести прослеживаемую бизнес-корректировку;
- получить утверждение;
- выполнить сверку повторно.
У каждой корректировки должен быть аудиторский след.
Типичные исключения между Settlement и Reconciliation
Система отражает успех, но в банковской выписке операции нет
Нужно исследовать операцию и банковские подтверждения.
В выписке есть списание, а в системе статус pending
Ответ API мог потеряться. Не следует отправлять новое платёжное поручение.
Операция успешна, но не отражена в зарплате
Уже полученная сумма может быть повторно выплачена в конце периода.
В зарплате сумма удержана, но операция не удалась
Зарплата работника может быть уменьшена, хотя деньги он не получил.
Операция относится к неверному периоду
Проверьте правило cut-off и соответствующий расчётный период.
Есть дублирующая операция
Сохраните обе записи, определите причину и обработайте их по надлежащей процедуре.
Кто должен отвечать за эти два уровня?
Они не обязательно принадлежат одной команде.
Ответственность можно разделить так:
- Payment Operations: контроль Settlement на уровне операций;
- бухгалтерия/Reconciliation: сверка с банком;
- Payroll: Settlement и сверка в конце периода;
- Engineering: корректная обработка статусов, идемпотентность и журналы;
- Product Operations: координация исключений.
При любом расхождении ответственность должна быть определена ясно.
Какие данные связывают два уровня?
Как минимум следует хранить:
- ID операции;
- ID работника;
- счёт получателя;
- сумму;
- время;
- клиента;
- расчётный период;
- статус операции;
- банковскую ссылку;
- сумму, отражённую в зарплате.
Reconciliation не должен в основном опираться на имена или произвольные описания переводов.
Когда период можно считать «закрытым»?
Период нельзя закрывать только потому, что расчёт зарплаты уже выполнен.
До закрытия работодатель должен знать, что:
- записи рабочего времени имеют окончательные статусы;
- успешные операции просуммированы;
- для операций pending есть план обработки;
- банковский и внутренний реестры сверены;
- в зарплате отражена правильная сумма;
- у оставшихся исключений есть ответственные;
- связующий отчёт сохранён.
Не каждое исключение должно исчезнуть немедленно, но каждое открытое исключение должно быть выявлено и контролироваться.
KPI, которые следует отдельно отслеживать для Settlement и Reconciliation
Settlement
- время определения окончательного статуса;
- количество операций pending;
- доля операций, требующих вмешательства;
- количество повторных попыток;
- количество дублирующих операций.
Reconciliation
- доля автоматических совпадений;
- количество исключений;
- возраст исключений;
- количество расхождений с банком;
- количество расхождений с зарплатой;
- время закрытия сверки.
Если объединить их в один KPI, работодателю будет трудно понять, связана ли проблема с обработкой операций или сравнением реестров.
Заключение
Settlement и Reconciliation — разные звенья одной контрольной цепочки. Settlement завершает и фиксирует финансовое обязательство, а Reconciliation использует независимые источники, чтобы подтвердить согласованность результата. Разделение уровней упрощает управление операциями pending, расхождениями, cut-off и расчётом зарплаты, сохраняя прослеживаемость от операции до расчётного листка.
Автор: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.
Консультации по доступу к заработанной зарплате для работодателей: горячая линия 0937.022.655 · Email info@nhankiet.vn · Доступ к заработанной зарплате для работодателей
Частые вопросы
Settlement — это то же самое, что Reconciliation?
Нет. Settlement устанавливает и отражает финансовый результат, а Reconciliation проверяет его совпадение между источниками.
Если API сообщил об успехе, нужна ли дальнейшая сверка?
Да. Независимая сверка должна подтвердить совпадение внутреннего реестра, банка и зарплаты.
Можно ли выполнить Settlement операции со статусом pending?
Её нельзя считать окончательной, пока статус не является достаточно определённым.
Может ли Reconciliation автоматически менять исходные данные?
Не должен. Reconciliation выявляет расхождения, а исправления должны проходить контролируемую и аудируемую процедуру корректировки.