Как импортировать банковские выписки в трекер расходов

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

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

В Expense Budget Tracker нет встроенного мастера для загрузки CSV или PDF в один клик и постоянного подключения к банку. В этом процессе выписку читает внешний ИИ-агент или скрипт, который затем взаимодействует с трекером. Агент обрабатывает файл, а вы проверяете и контролируете, какие именно данные попадут в журнал.

Начните с одного источника, к которому можно вернуться

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

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

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

Риски извлечения данных зависят от формата файла. При импорте банковской выписки CSV агент начинает со структурированных полей, а при импорте банковской выписки PDF — с извлеченного текста или изображения.

• Структурированный CSV обычно служит самой чистой отправной точкой, но агенту все равно нужно подтвердить разделитель, формат даты, десятичный разделитель, валюту и то, представлены ли суммы отдельными столбцами дебета и кредита или одним полем со знаком.
• PDF с текстовым слоем может сохранить читаемый текст операций, но потерять выравнивание столбцов. Для каждой строки черновика укажите номер страницы, а также порядковый номер операции или ссылку на строку, чтобы ее можно было найти в источнике.
• Для отсканированного PDF или PDF, состоящего только из изображений, нужны OCR либо распознавание изображений. Обрезанные страницы, бледная печать и слившиеся столбцы могут сделать точное извлечение невозможным. Если дата, сумма, валюта или баланс неясны, остановитесь и запросите более качественный файл или ручное подтверждение.

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

Используйте именно эту таблицу проверки

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

Столбец	Что в нем должно быть
source_ref	Номер строки CSV либо номер страницы PDF вместе с порядковым номером операции или ссылкой на строку
posted_at	Дата и время проведения, если они есть в источнике; добавляйте часовой пояс, только если он указан в источнике или подтвержден пользователем
raw_description	Исходный текст без изменений, точно как в выписке, без очистки названия продавца
statement_amount	Исходная сумма дебета или кредита либо сумма со знаком — точно в том виде, как она указана в источнике
currency	Валюта источника; никогда не определяйте ее молча только по символу
ledger_amount	Сумма, приведенная к правилам знаков трекера
target_account	Конкретный существующий счет, выбранный из рабочего пространства
proposed_kind	Точное значение, разрешенное актуальной схемой для этого движения средств
proposed_category	Точная существующая категория или значение «без категории», которого актуальная схема требует для перевода
transfer_match	Счет второй стороны и ссылка на источник либо unresolved
duplicate_candidate	Совпадающая строка журнала и подтверждающие данные либо none found
uncertainty	Любая неразрешенная проблема с текстом, датой, суммой, счетом, валютой или классификацией
decision	insert, match existing, exclude или needs review

Например, операция, уже записанная по чеку, должна остаться в таблице со значением match existing. Она не должна исчезнуть из подтверждающих данных или превратиться во вторую запись журнала.

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

Подключите агента, а затем проверьте реальные данные

Для терминального агента или прямого HTTP-скрипта начните с:

GET https://api.expense-budget-tracker.com/v1/

Следуйте инструкциям в ответе на этот запрос, пройдите процедуру с кодом из письма и сохраните полученный ApiKey длительного действия вне памяти чата. Для аутентифицированных запросов используйте заголовок Authorization: ApiKey <key>. Полная последовательность подключения описана в руководстве по настройке агента.

Прежде чем составлять SQL, агент должен:

1. Подтвердить аккаунт, в который выполнен вход, и конкретное рабочее пространство.
2. Выбрать нужное рабочее пространство или передать его ID в запросе.
3. Проверить через GET /v1/schema, какие отношения и столбцы доступны сейчас.
4. Запросить нужный счет, его валюту, существующие категории и последнюю надежную точку сверки через POST /v1/sql/query.
5. Прежде чем предлагать запись, запросить существующие операции журнала за период выписки и дополнительный диапазон для проверки дубликатов.

Не копируйте список столбцов из этой статьи в скрипт импорта. Контрактом служит актуальная схема. В справочнике API описаны конечные точки и правила SQL, а /v1/schema сообщает агенту, что можно записать сейчас.

Клиент с поддержкой MCP вместо этого может подключиться к:

https://mcp.expense-budget-tracker.com/mcp

Этот путь использует OAuth в браузере, а не ApiKey. Запросите область действия expenses:read, чтобы использовать list_workspaces, get_schema и sql_query. Добавляйте необязательную область действия expenses:write, только когда клиент готов вызвать sql_execute. Модель подключения и одобрения описана в руководстве по MCP Connector.

В обоих вариантах один запрос возвращает не более 100 строк. Прямой API также ограничивает число затрагиваемых строк до 100 на один запрос изменения. Если период содержит больше строк, разделите чтение по непересекающимся границам дат или источников и покажите, что каждая проведенная строка выписки встречается в таблице проверки ровно один раз.

Выберите разумный диапазон для поиска дубликатов

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

Считайте существующий постоянный банковский идентификатор операции веским подтверждением дубликата, если он есть и в источнике, и в журнале. Если такого идентификатора нет, отмечайте потенциальный дубликат, когда совпадает все перечисленное:

• целевой счет
• валюта
• точная сумма со знаком
• дата в пределах трех календарных дней

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

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

При подготовке черновика ориентируйтесь на категории журнала

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

Помещайте неясные строки в needs review. Не придумывайте категорию только ради того, чтобы таблица выглядела заполненной. Полезный результат — короткий список неопределенностей, привязанный к конкретным ссылкам на источник, а не уверенная догадка среди одобренных строк.

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

Не позволяйте переводам превращаться в фиктивные расходы

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

Это охватывает распространенные случаи:

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

Если встречный счет или выписка отсутствуют, оставьте в transfer_match значение unresolved. Не выдумывайте вторую сторону и не одобряйте строку как обычный расход только ради завершения пакета. Подробные границы решения описаны в статье Считаются ли банковские переводы расходами?.

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

Одобряйте конкретный пакет, а не намерение в общих словах

Когда для каждой проведенной строки источника принято решение, даже если это needs review, агент должен показать:

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

Формулируйте одобрение настолько конкретно:

Я одобряю только пакет импорта выписки [number].
Рабочее пространство: [name and ID]
Счет выписки: [account name and ID]
Период: [start through end]
Одобренные ссылки на источник: [exact list]
Ожидаемое количество затрагиваемых строк: [count]
Выполни только тот точный SQL, который показан в последней предварительной версии.
Не изменяй никакие другие строки. После проверки данных повторным запросом остановись.

Если рабочее пространство, счет, SQL, список источников или ожидаемый результат изменились, одобрение больше не действует. Запросите новую предварительную версию и новое одобрение.

Записывайте небольшими пакетами и проверяйте каждый повторным запросом

Для прямого API отправляйте по одному одобренному выражению INSERT, UPDATE или DELETE в каждом запросе к POST /v1/sql/execute. Для MCP используйте sql_execute с областью действия expenses:write. Вставка нескольких строк по-прежнему может быть одним выражением, но делайте пакеты достаточно небольшими, чтобы человек мог сравнить каждую строку с таблицей проверки. Начните с самой маленькой логически цельной группы — одной пары перевода или нескольких обычных строк. Переходите к следующему пакету только после успешной проверки записанных данных и отдельного предварительного просмотра и одобрения следующего пакета.

После каждого пакета снова запросите те же строки через /v1/sql/query или sql_query. Сравните сохраненные данные — счет, метку времени, сумму со знаком, валюту, тип, категорию и связь перевода — с одобренной предварительной версией. Затем сопоставьте каждую полученную строку с одобренной ссылкой на источник. Успешный HTTP-ответ еще не доказывает, что в журнал попали именно запланированные данные.

Не смешивайте очистку данных с импортом. Если контрольный запрос выявил неверное значение или существующая строка требует исправления, подготовьте отдельный точный UPDATE или DELETE, объясните его результат и запросите новое одобрение.

Сверьте баланс каждого счета, которого коснулся импорт

Для выписки с начальным и конечным балансами сначала используйте принятые в самой выписке правила дебета, кредита и баланса:

expected source closing balance = source opening balance + sum(posted source movements)

Для трекера ведите расчет от последней надежной контрольной точки счета, а не предполагайте, что баланс уже сверен на первую дату выписки:

expected tracker balance at cutoff = last known-good tracker balance
                                   + sum(signed ledger movements after that checkpoint through the cutoff)

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

Если в ходе импорта были созданы или сопоставлены обе стороны внутреннего перевода, сверьте оба затронутых счета с их собственными выписками или надежными контрольными точками баланса. Совпадение баланса исходного счета все еще может скрывать выдуманную или продублированную строку на счете назначения.

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

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

Знайте, куда попадают данные выписки

Это трекер расходов без подключения к банку, а не обещание, что выписка останется на вашем компьютере.

Выбранный вами ИИ-клиент или поставщик модели может обрабатывать CSV или PDF и содержащийся в нем финансовый текст. Изучите условия этого поставщика по обработке данных и предоставьте ему только тот доступ к файлу, который нужен для работы. В описанном процессе агент отправляет трекеру SQL-запросы и одобренные команды записи структурированных данных, а в ответ получает выбранные структурированные строки. Исходный файл выписки не загружается в трекер.

Если Expense Budget Tracker развернут на вашем сервере, это не означает, что там же работают ИИ-агент, инструмент OCR или поставщик модели. Это отдельные системы с разными границами данных. Если ваш приоритет — отсутствие постоянного доступа к банку, прочитайте, как приложение для бюджета может работать без подключения к банку, и с учетом этого выберите каждую часть процесса.

Промпт, который можно использовать повторно

Импортируй выписку по банковскому счету или карте за закрытый период из [file path or attachment]
в Expense Budget Tracker. Это рабочее пространство [name] и счет [name] за период [dates].

Пока ничего не записывай. Сохрани исходный файл без изменений. Определи, что это: структурированный
CSV, PDF с текстовым слоем либо отсканированный PDF или PDF из изображений, — и сообщи
обо всех ограничениях извлечения. Исключи ожидающие операции. Построй точную таблицу
проверки из этой статьи, сохранив для каждой проведенной строки ссылку на источник,
исходное описание, исходную сумму, нормализованную сумму журнала и неопределенность.

Для прямого HTTP начни с https://api.expense-budget-tracker.com/v1/, следуй указаниям
из ответа на этот запрос, используй полученный или сохраненный ApiKey длительного действия,
подтверди через /me аккаунт и конкретное рабочее пространство, проверь /v1/schema и читай данные через /v1/sql/query.
Для MCP используй list_workspaces, get_schema и sql_query с expenses:read; запрашивай
expenses:write только для одобренной записи через sql_execute.

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

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

После одобрения выполни только это одно выражение INSERT, UPDATE или DELETE через
/v1/sql/execute или sql_execute. Снова запроси те же строки и сравни их с одобренной
предварительной версией. Сверь каждый затронутый счет с конечным балансом его выписки
или с точной надежной контрольной точкой баланса. Остановись, не добавляя балансирующую
строку, если что-либо останется необъяснимым.

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