Matchpoint | Exception workflow для AP-команд

1. Контекст

Matchpoint — сервис для команд, которые обрабатывают счета от поставщиков.

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

Проблема не в самом факте расхождения, а в том, что система обычно показывает только красный флаг и не объясняет, что именно пошло не так.

Конкуренты — Bill.com, Tipalti, Coupa — оптимизируют happy path и трактуют исключения как warnings: система поднимает флаг, а причину, владельца и следующий шаг человек находит сам. Matchpoint я строил от обратного: расхождение здесь не ошибка в таблице, а управляемый объект с жизненным циклом Detect → Diagnose → Route → Resolve → Trace. Скоуп этого кейса — Detect и Diagnose, то самое слабое место, которое конкуренты оставляют пользователю.

Домен. Основной пользователь — AP-специалист, который обрабатывает 200–500 счетов в месяц по 50–100 поставщикам. Каждый счёт проходит 3-way matching: сверку инвойса с заказом на закупку (PO) и приёмкой (goods receipt). Исключение — это любое место, где три документа не сходятся.

Что считается успехом

Рамка «зачем» держится на двух ярусах. Метрики конкретных решений вынесены отдельно в блок 10.

• Бизнес. DPO, стоимость обработки одного счёта, доля оплат в срок, штрафы за просрочку, аудиторская готовность.
  • Операционная декомпозиция: time-to-resolve исключения, доля исключений, закрытых без эскалации, false positive rate флагов, доля исключений, закрытых пакетом.
• Для пользователя. AP закрывает исключение, не выходя из системы: быстро понять, что расходится, кому адресовать и каким действием закрыть — без ручной сверки в трёх окнах и переписки на стороне.

Пользователи

• Специалист по счетам разбирает исключения каждый день. Главная боль — постоянное переключение между документами и системами.
• Менеджер подключается, когда сумма высокая или решение рискованное.
• Закупки и склад не работают в системе постоянно, но получают вопросы, когда ошибка связана с заказом или приёмкой.

2. Ограничения и скоуп

Концепт, сделан соло, без реальных данных и живых пользователей — все baseline-значения требуют проверки на пилоте.

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

3. Дискавери

Я начал с desk research: посмотрел отзывы о Bill.com, Coupa и Tipalti, публичные кейсы по AP-automation и обсуждения AP-специалистов. В разных источниках повторялась одна проблема: система находит расхождение, но дальше человек всё равно сам выясняет причину, владельца и следующий шаг.

Ключевые инсайты

• Флаг без объяснения.
  Система сообщает, что счёт «не сходится», но не показывает достаточно контекста: какая строка вызвала проблему, с чем именно она расходится и кто должен это исправить. В итоге AP, закупки и склад разбирают такие случаи вручную — через письма, чаты и созвоны.

• Автоматике не доверяют без объяснения уверенности.
  Если система просто поднимает флаг, но не показывает, насколько надёжно он обнаружен, пользователь начинает перепроверять всё вручную. Особенно это критично для нестандартных шаблонов, новых поставщиков и спорных данных.

• Контекст утекает из системы.
  Когда решение уходит в почту и мессенджеры, история быстро теряется: кто проверил, что решил, почему согласился или отклонил счёт. В конце месяца это усложняет аудит и замедляет закрытие периода.

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

4. Допущения

Без доступа к реальным данным я зафиксировал допущения явно: что предположил, почему и как проверил бы.

• Чаще всего расходятся цена и количество. Предположил это по desk research, поэтому построил главный экран вокруг построчной дельты. При доступе к данным проверил бы аналитикой по типам исключений.
• Без объяснения уверенности автоматику отключают. Предположил, что AP перепроверяет флаг вручную, если не видит, насколько тот надёжен, поэтому сделал confidence сквозным сигналом. Проверил бы через adoption и долю отключивших автоматику.
• По новому поставщику нет baseline. Предположил, что первое исключение не с чем сравнить, поэтому заложил честный cold-start вместо ложной уверенности. Проверил бы на первых счетах реальных новых поставщиков.

5. Сценарии

Критическое расхождение перед дедлайном

Массовая обработка однотипных исключений

Первый счёт нового поставщика

6. Приоритизация

Я расставил сценарии по осям частота × стоимость.

• Сценарий 1 — редкий, но дорогой за случай: один сорванный платёж превращается в пеню и задержку поставки.
• Сценарий 2 — частый и дешёвый за случай, но 34 повтора складываются в 100+ минут рутины.
• Сценарий 3 — не про частоту, а про риск решения без истории.

Все три сходятся в одну точку — диагностику единичного исключения. Если сделать её сильной, она же обслуживает сценарий 2 (та же диагностика × N через bulk) и снижает риск в сценарии 3. Поэтому ядро продукта — hero-экран Exception Detail, а не общий список счетов.

7. Формулировка проблемы

• AP не может быстро определить источник расхождения, потому что система флагает несовпадение без атрибуции, — что ведёт к ручной сверке в трёх окнах и срыву срока оплаты.
• AP не может закрыть однотипные исключения пакетом, потому что очередь не распознаёт их как один тип, — что ведёт к 100+ минутам рутины и риску пропустить реальную аномалию.
• AP не может оценить риск по новому поставщику, потому что нет baseline, — что ведёт к лишним согласованиям или закреплению ошибки как нормы.

8. Решение

Весь интерфейс держится на едином белом фоне без цветного бренда: цвет несёт только семантику статусов (tomato / amber / jade), а расхождения выделяются жирным, а не заливкой.

Модель сигналов

Я оставил только сигналы, которые помогают принять решение и по-разному выглядят в зависимости от того, насколько предупреждение серьёзно: confidence (уверенность системы), severity (критичность), статус поставщика, тип исключения, стадия обработки, причина и метод обнаружения.

Экран 1. Очередь исключений и пакетная обработка

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

Однотипные исключения закрываются пакетом. Группировка строгая — совпадать должны сразу пять признаков: поставщик, тип, направление отклонения (выше или ниже PO), диапазон variance и конкретное поле. Выпадающие значения (outliers) автоматически исключаются из пакета и остаются видимыми поштучно. Пакет выше $50k или больше 20 исключений уходит на approval.

Гипотеза: строгая группировка bulk снижает суммарное time-to-resolve по сценарию 2, не повышая риск закрыть аномалию вместе с рутиной.

Экран 2. Диагностика

Главный экран диагностики. Документы показаны рядом (split-view), а расхождение объясняется прямо у конкретной строки — причину нужно видеть рядом с документами, а не искать в соседнем окне. Система атрибутирует источник: изменение цены у поставщика (vendor pricing change), ошибка в заказе (PO error) или ошибка приёмки (receipt error).

Гипотеза: если показать attribution прямо у строки, time-to-understand cause падает — специалист перестаёт реконструировать причину вручную.

Справа — панель контекста поставщика: средний чек, частота прошлых расхождений, условия договора, связанные документы. Контекст поставщика должен быть на самом экране диагностики, иначе решение снова уходит в переписку.

По умолчанию показываю diff table — только расходящиеся поля. Полная трёхколоночная сверка (инвойс ↔ заказ ↔ приёмка) доступна по запросу, а для проверки исходника есть scan modal с распознанным счётом. Поповер у статуса уверенности объясняет, почему флаг надёжен: показывает триггер, подтверждающие сигналы и правило, по которому он поднят.

Экран 3. Профиль поставщика

Профиль закрывает сценарий, где одного инвойса недостаточно. По новому поставщику истории ещё нет, и интерфейс честно показывает нехватку baseline (cold-start), а не имитирует уверенность. Здесь AP-специалист видит рабочий контекст: сколько компания обычно платит этому поставщику, как часто возникают расхождения, есть ли открытые исключения и были ли недавние изменения.

В профиле собраны данные, которые обычно приходится искать в разных местах:

• статус поставщика и основные контакты;
• типичный размер инвойса и цикл оплаты;
• частота расхождений;
• открытый баланс и открытые исключения;
• банковские данные и условия договора;
• последние события по поставщику.

Это помогает быстрее понять, проблема в конкретном инвойсе или в поведении поставщика. Отсюда же можно написать поставщику, скачать историю, обновить банковские данные или отметить поставщика для проверки.

Основные действия

• Обновить заказ — если счёт верный, а цена в заказе устарела.
• Запросить исправленный счёт — если ошибка на стороне поставщика.
• Одобрить как есть — если расхождение допустимо и его нужно провести.

• Одобрить часть суммы — если подтверждена только часть поставки.
• Отклонить счёт — если это дубль или явная ошибка.
• Назначить владельца — если решать должны закупки, склад или менеджер. Владелец не выбирается вслепую: система подсказывает suggested owner по типу проблемы — расхождение по цене → Procurement Manager, расхождение по количеству в приёмке → Receiving Supervisor.

Допуски

Мелкие расхождения не должны выглядеть как серьёзная проблема. Правило простое: система смотрит не на процент, а на абсолютную сумму — разница в 30 центов не блокирует оплату, даже если процент выглядит большим. Для валюты, налогов и доставки причина показывается отдельно, чтобы пользователю не приходилось считать в уме или искать курс в другой системе.

9. Компромиссы

Diff table по умолчанию. Рассматривал diff table (только расходящиеся поля) против полной трёхколоночной сверки на экране сразу. Выбрал diff table — плотность и фокус на главном. Теряем audit-режим по умолчанию. Ок: полный вид доступен по запросу, а нужен ли режим full 3-column сразу — открытый вопрос под валидацию.

Confidence как явный статус. Рассматривал confidence отдельным статусом с поповером против простого флага. Выбрал явный статус. Теряем место на экране и добавляем сложности. Ок: без объяснения уверенности автоматику отключают — это прямой вывод из research, то есть вопрос adoption, а не украшения.

Строгая группировка bulk. Рассматривал строгую группировку (пять критериев + auto-exclude outliers) против мягкой. Выбрал строгую. Теряем часть исключений, которые проходят мимо пакета. Ок: строгость защищает от закрытия аномалии вместе с рутиной, а outliers остаются видны поштучно.

10. Как я бы мерил успех

Baseline честно неизвестен — замерил бы на пилоте. Target даю порядком величины, а не финальной цифрой.

• Time-to-understand cause — сколько времени нужно, чтобы понять причину расхождения.
• Correct-action rate — как часто выбрано правильное действие.
• False positive rate — доля лишних флагов.
• Доля закрытых пакетом — насколько bulk снимает рутину.

Мост к бизнесу: эти per-solution метрики — ведущие индикаторы; операционные метрики (time-to-resolve, доля эскалаций) — то, во что они конвертируются.

11. Что дальше

Вне итерации остались: общий список всех счетов, полный трёхколоночный audit-режим по умолчанию, зависшие согласования и цепочки утверждения, качество распознавания документов.

Что проверил бы дальше:

1. Валидация основного флоу: открыть исключение → понять причину → выбрать действие.
2. Читаемость построчной дельты без обучения и подсказок.
3. Пустые, загрузочные и ошибочные состояния.
4. Пакетная обработка на реальных данных.