Reconciliation KPIs: coverage, age and closureKPI сверки оплат: охват, возраст и закрытие

Define the population and reporting cutoffЗафиксируйте группу операций и срез

Choose the unit: a payment operation, order or reconciliation issue. Do not mix them in one denominator; an order may contain several payments, while an issue may involve multiple source records. Define entity, channel, currency, period, event type and inclusion rule. Preserve those parameters and the data-refresh cutoff with each metric.Выберите единицу анализа: отдельную платёжную операцию, заказ или вопрос сверки. Не смешивайте их в одном знаменателе: один заказ может содержать предоплату и доплату, а один вопрос — несколько записей источников. Для группы задайте компанию, канал, валюту, период, тип события и правило включения. Каждый показатель должен сохранять эти параметры вместе с моментом обновления данных.

For reconciliation coverage, the denominator is every unique operation in the selected population requiring review at the cutoff. The numerator contains operations satisfying the agreed checks, not merely a plausible match. Do not remove exceptions or unknown outcomes to improve the rate. Display incomplete sources separately; a high match rate does not make an incomplete dataset complete.Для охвата сверки знаменатель — все уникальные операции выбранной группы, подлежащие проверке на момент среза. Числитель — операции, для которых выполнены согласованные проверки, а не просто найден похожий платёж. Исключения и неизвестные результаты нельзя убирать ради улучшения процента. Если часть источника ещё не загружена, показывайте неполноту отдельно: ограниченный набор данных не превращается в полный только от высокой доли совпадений.

Compare count coverage with value coverageСравнивайте охват по числу и по сумме

Measure age from a stable starting pointСчитайте возраст по неизменному началу

Define the clock’s start, such as first detection of the exception. Do not replace it with the latest comment, reassignment or reimport time. You can separately measure lateness against an assigned deadline. These answer different questions: how long the case has existed and whether the action plan is overdue. Show external waiting even when an internal deadline uses another rule.Установите начало часов: например, первое обнаружение исключения. Не заменяйте его временем последнего комментария, переназначения или повторного импорта. Отдельно можно измерять просрочку относительно назначенного срока. Эти интервалы отвечают на разные вопросы: сколько случай существует и нарушен ли план действий. Пауза ожидания внешнего ответа должна быть видна, даже если внутренний срок считается по другому правилу.

An illustrative grouping is under twenty-four hours, twenty-four to under seventy-two hours, and seventy-two hours or more. These are reporting buckets, not promised provider timelines. Specify boundary treatment so a case exactly twenty-four hours old is neither lost nor counted twice. Show count, value by currency and owners of the largest or oldest cases in each bucket.Для примера можно разделить возраст на интервалы менее 24 часов, от 24 до 72 часов и 72 часа или больше. Это иллюстративная группировка, не обещанный срок провайдера. Определите включение границ, чтобы случай ровно в 24 часа не потерялся и не попал сразу в две группы. В каждой группе показывайте количество, сумму по валюте и владельцев крупнейших или самых старых случаев.

Supplement mean or median age with the oldest open case. A wave of new issues can improve the average while a difficult case remains untouched. Measure completion time for closed cases, but display it alongside the open backlog. Otherwise the review highlights quick resolutions and misses accumulating waits for operations that have never entered the completion statistics.Дополните среднее или медиану возраста самой старой открытой записью. Несколько недавно созданных случаев могут улучшить средний показатель, хотя тяжёлый вопрос остаётся без движения. Время закрытия считайте по завершённым случаям, но показывайте его рядом с открытым остатком. Иначе команда увидит быстрые решения и не заметит накопившееся ожидание по операциям, которые ещё ни разу не вошли в статистику завершения.

Check the open-work balanceПроверьте баланс открытой работы

Reconcile opening backlog, new issues, reopened cases and verified closures. Suppose twelve were open, seven new cases arrived, two reopened and nine closed. Twelve remain. An unchanged backlog hides both work completed and incoming demand, so show the components. Reclassification or duplicate merging needs its own count-adjustment reason and must not masquerade as resolving a genuine discrepancy.Сопоставьте начало периода, новые вопросы, повторные открытия и подтверждённые закрытия. Условно было 12 открытых случаев, добавились семь новых, два вернулись в работу, девять закрыты. В конце снова 12. Неизменный остаток скрывает выполненную работу и поступившую нагрузку, поэтому показывайте составляющие. Переклассификация или объединение дублей имеют отдельную причину изменения числа и не подменяют закрытие реального расхождения.

Closure needs evidence: a verified match, corrected record or completed required check. Track cases reopened because the resolution was incomplete and cases returned after quality review. Do not make closure speed the employee’s sole objective. Cause identified, resolution approved and outcome verified are different stages; the final stage depends on the workflow and source evidence.Закрытие требует доказательства: подтверждённого сопоставления, исправленной записи или результата нужной проверки. Отдельно считайте случаи, повторно открытые из-за неполного решения, и возвраты на проверку качества. Не превращайте скорость закрытия в единственную цель сотрудника. Причина установлена, решение согласовано и результат подтверждён — разные этапы; последний из них определяется вашим процессом и источником данных.

Make every metric manually reconstructableСделайте метрику проверяемой вручную

A reviewer should open any metric, inspect its population and recalculate it from source records. Test a period boundary, empty source, two currencies, duplicate event and reopened case. Version the definitions and explain changes before comparing periods. Do not present a result as improvement when it arose solely from excluding inconvenient records from the denominator.Проверяющий должен открыть любой показатель, увидеть его группу операций и пересчитать результат из исходных записей. Проверьте случай на границе периода, пустой источник, две валюты, повтор события и повторное открытие. Зафиксируйте версии правил и объясняйте изменения определения до сравнения периодов. Нельзя представлять улучшением результат, который появился только после исключения неудобных записей из знаменателя.

The current SABSUS payment process provides order, source, status, terminal and shift context for review. Verify the exact formulas, aging buckets and control fields separately. Start with one channel and several manually checked cases. A usable review leads to the open operation, its owner and next action; it does not replace reconciliation or perform payment changes.Текущий платёжный процесс SABSUS даёт контекст заказа, источника, статуса, терминала и смены для разбора. Конкретные формулы, возрастные интервалы и поля контроля подтвердите отдельно. Начните с одного канала и нескольких вручную сверенных случаев. Готовый обзор ведёт к открытой операции, ответственному и действию; он не заменяет сам процесс сверки и не выполняет платёжных изменений.

Reconciliation workflowПроцесс сверки оплат · Returns and refund metricsПоказатели возвратов

Quick answersКороткие ответы