Як імпортувати банківські виписки в трекер витрат

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

Безпечний спосіб імпортувати банківські виписки в трекер витрат — зберегти оригінальний файл банку, доручити AI-агенту підготувати чернетку для перевірки, схвалити лише зрозумілі вам рядки, а потім звірити кожен рахунок, якого торкнувся імпорт.

В Expense Budget Tracker немає вбудованого майстра завантаження CSV або PDF в один клік, і застосунок не підтримує постійне з’єднання з вашим банком. У цьому процесі зовнішній AI-агент або скрипт читає виписку та взаємодіє з трекером. Агент працює з файлом, а ви перевіряєте й контролюєте, що саме потрапить до реєстру.

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

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

За можливості один файл має відповідати одному рахунку й одному періоду виписки. Якщо банківський експорт об’єднує дві картки, змішує транзакції в обробці з проведеними або охоплює кілька періодів, розділіть перевірку на чіткі розділи до нормалізації транзакцій. Інакше потім буде надто складно знайти причину розбіжності в балансі.

Для імпорту за закритий період використовуйте проведені транзакції. Сума, опис або дата транзакції в обробці можуть змінитися. Додайте такі транзакції до окремого списку спостереження, а не вважайте їх завершеною історією.

Формат файлу впливає на ризик помилок під час вилучення даних. Імпорт банківської виписки CSV починається зі структурованих полів, а імпорт банківської виписки PDF може починатися з вилученого тексту або пікселів.

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

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

Використовуйте саме цю таблицю перевірки

Спочатку агент має створити чернетку поза реєстром — рівно з одним рядком перевірки для кожної проведеної транзакції з джерела, включно з дублікатами й винятками. Використовуйте ці стовпці в такому порядку:

Стовпець	Що в ньому має бути
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/

Дотримуйтеся вказівок із discovery-відповіді, пройдіть авторизацію за кодом з електронної пошти й збережіть отриманий 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-підключення.

В обох варіантах один запит повертає не більше 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)

Переведіть специфічне для банку подання дебету, кредиту або карткового боргу в правила знаків трекера й покажіть цей перерахунок. Після цього очікуваний баланс трекера має дорівнювати нормалізованому кінцевому балансу виписки для цього рахунку. Також порівняйте посилання на джерело для імпортованих рядків із таблицею перевірки: кожен проведений рядок виписки має бути вставлений, зіставлений із наявним рядком або явно виключений.

Якщо під час імпорту створено або зіставлено обидві частини внутрішнього переказу, звірте обидва задіяні рахунки з їхніми виписками або надійними контрольними точками балансу. Те, що баланс вихідного рахунку збігається, усе одно може приховувати вигадану чи дубльовану частину на рахунку призначення.

CSV-експорт транзакцій може не містити початкового й кінцевого балансів. У такому разі використовуйте окремий наданий банком баланс станом на точний момент або попередню надійну точку звірки. Без одного із цих орієнтирів можна перевірити охоплення рядків і підсумки, але не можна заявляти про повну звірку банківської виписки.

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

Перевірте, куди потрапляють дані виписки

Це трекер витрат без підключення до банку, а не обіцянка, що виписка залишиться на вашому комп’ютері.

Обраний вами AI-клієнт або постачальник моделі може обробляти CSV чи PDF і текст фінансової виписки, який вони містять. Ознайомтеся з умовами обробки даних цього постачальника та надайте йому лише той доступ до файлу, який потрібен для роботи. У цьому процесі агент надсилає до трекера SQL-запити й схвалені структуровані запити на запис, а у відповідь отримує вибрані структуровані рядки. Оригінальний файл виписки до трекера не завантажується.

Якщо ви самостійно розгорнули Expense Budget Tracker, це ще не означає, що AI-агент, інструмент OCR або постачальник моделі також працюють на вашій інфраструктурі. Це окремі системи з власними межами обробки даних. Якщо головне для вас — уникнути постійного доступу до банку, дізнайтеся, як бюджетний застосунок може працювати без підключення до банку, і з огляду на це виберіть кожен компонент процесу.

Запит, який можна використовувати повторно

Імпортуй закриту банківську або карткову виписку з [file path or attachment] до Expense
Budget Tracker. Імпорт призначений для робочого простору [name] і рахунку [name] за період [dates].

Поки нічого не записуй. Збережи оригінальний файл. Визнач, чи це структурований CSV,
текстовий PDF або PDF зі сканами чи лише із зображеннями, і повідом про всі обмеження
вилучення даних. Виключи транзакції в обробці. Побудуй саме таблицю перевірки з цієї
статті, зберігаючи посилання на джерело, необроблений опис, оригінальну суму,
нормалізовану суму реєстру й невизначеність для кожного проведеного рядка.

Для прямого HTTP почни з https://api.expense-budget-tracker.com/v1/, виконай інструкції
з discovery-відповіді, використай повернений або збережений 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. Повторно отримай саме ці рядки й порівняй їх зі схваленим
попереднім переглядом. Звір кожен задіяний рахунок із кінцевим балансом його виписки
або точною надійною контрольною точкою балансу. Зупинися, не додаючи балансувального
рядка, якщо щось залишиться непоясненим.

Результат конкретний: незмінене першоджерело, рішення для кожного рядка джерела, схвалена зміна реєстру й баланси, які ви можете пояснити.