Импорт выписки: что человек должен проверить до сохранения

Олжас Азирали, основатель AZIRAL. Портрет и обложка подготовлены с помощью ИИ.

Олжас Азирали / Olzhas Azirali, основатель AZIRAL с 2019 года и разработчик приложений.

Материал подготовлен с помощью AI-ассистента по опубликованным описаниям Finance Bro и документации поддержки.

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

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

Разделить прочитанное и предложенное

В качестве конкретного примера можно взять Finance Bro в App Store. Описание приложения предлагает проверять суммы, даты, направление операций и категории перед сохранением поддерживаемой выписки.

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

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

Показать последствие на коротком примере

Рассмотрим условную запись: 5 000 тенге, магазин, 30 октября. Это учебный пример, а не данные пользователя или результат измерения качества Finance Bro.

Прочитано: сумма и дата из выбранной строки.
Предложено: направление «расход» и подходящая категория.
Требует решения: счёт, к которому относится операция.

Проверка должна помогать ответить на практический вопрос: что окажется в моём учёте после сохранения? Если выбран другой счёт, даже верно прочитанная сумма создаёт другую запись. Если операция похожа на перевод между собственными счетами, один лишь ярлык «расход» не объясняет её смысл.

Такое представление не требует сложного отчёта о работе распознавателя. Часто достаточно показывать исходный фрагмент рядом с редактируемыми значениями и ясно обозначать действие подтверждения. Это предложение к дизайну, а не описание каждого экрана текущей версии приложения.

Дать сомнению видимое место

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

Поддержка Finance Bro объясняет, что категории предлагаются по локальным словам в названии продавца; незнакомое название может остаться без категории. Это конкретный пример ограниченного правила, назначение которого можно объяснить пользователю.

Для разработчика отсюда следует полезный вопрос: умеет ли интерфейс сообщить «здесь нужно ваше решение»? Поле может оставаться незаполненным, строка может требовать проверки, а подсказка - объяснять причину. Важно, чтобы такое состояние отличалось от ошибки чтения файла и от уже подтверждённой операции.

Считать повтор вопросом к данным

Один и тот же документ можно выбрать дважды. Записи из разных источников могут описывать одно событие. При проектировании импорта стоит заранее определить, что человек увидит при возможном повторе и какие признаки помогут ему сравнить строки.

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

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

Не смешивать запись и оплату

Автоматическое заполнение учёта и исполнение банковской операции - разные действия. По текущему описанию, Finance Bro не проводит банковские платежи. Созданная запись отражает информацию в приложении; она не означает новое списание денег банком.

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

Проверять понятность завершения

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

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

Другие продукты и материалы: Олжас Азирали / AZIRAL. Finance Bro развивается на открытой Flutter-основе; происхождение приложения раскрыто в продуктовой заметке.

Описания проверены 30 октября 2026 года. В App Store показана версия 1.0.9. Поддерживаемые форматы и доступность функций нужно сопоставлять с установленной версией приложения.