AI-сканер чеків для трекера витрат: процес із Claude і Codex
Як використовувати Claude або Codex як AI-сканер чеків для Expense Budget Tracker: розпізнати суму, перевірити точний запит на запис, схвалити його й звірити результат у реєстрі.
У чеку з кафе вказано $27.82, операція за карткою досі «очікує на проведення», а папір уже скручується біля ноутбука. Відкладіть чек на тиждень — і згадати назву закладу, чайові та потрібну категорію буде значно складніше.
Поки чек перед вами, Claude чи Codex може перетворити його фото на чернетку запису. Агент зчитує видимі дані, порівнює запропоновану транзакцію з рахунками, категоріями та недавніми записами у вашому реєстрі й показує точний запит на запис. Нічого не зміниться, доки ви не схвалите саме цей запит.
Тут важливо розуміти межі продукту. Expense Budget Tracker не має вбудованої камери чи сканера чеків і не зберігає зображення чеків. Надане вами зображення інтерпретує Claude, Codex або постачальник моделі у вашій конфігурації. Трекер зберігає лише схвалені структуровані дані реєстру.
Чи зможе агент прочитати зображення, залежить від вибраної AI-конфігурації. Anthropic зазначає в документації, що Claude може обробляти й аналізувати візуальні вхідні дані, а OpenAI Responses API приймає текст, зображення та файли. Проте не кожен клієнт Claude або Codex може автоматично відкрити локальне фото. Клієнт має підтримувати вкладення або мати доступ до шляху файлу, а також отримати ваш дозвіл. Розпізнавання зображень допомагає, але цифри все одно має перевірити людина.
![]()
Як працює «сканер» у цьому процесі
Це перенесення даних із чека до реєстру за допомогою AI, а не вбудована функція камери.
Модель обробляє надане зображення, а Expense Budget Tracker приймає лише схвалені дані для реєстру.
| Етап | Що відбувається |
|---|---|
| Знімок | Ви фотографуєте чек або зберігаєте скан там, де Claude чи Codex матиме до нього доступ. |
| Розпізнавання | Модель зчитує видимі поля: продавця, дату, проміжну суму, знижку, податок, чайові, підсумок, валюту й підказки щодо способу оплати. Усе непевне вона позначає. |
| Перевірка реєстру | Агент читає вибраний робочий простір Expense Budget Tracker, актуальну схему, рахунки, категорії та можливі дублікати. |
| Попередній перегляд | Агент показує розпізнані факти, невизначеності, вибрану категорію й точний запропонований запит на запис. |
| Схвалення | Ви схвалюєте саме цей запит або виправляєте його й просите підготувати новий попередній перегляд. |
| Перевірка результату | Агент записує одну структуровану транзакцію та зчитує її назад із реєстру. |
| Звірка | Коли карткову чи банківську транзакцію буде проведено, ви зіставляєте її із записом за чеком, а не імпортуєте другу копію. |
Саме останній крок робить AI-сканер чеків для трекера витрат корисним для реєстру, який можна перевірити. Правильно зчитати $27.82 — лише початок. Треба також вибрати правильні робочий простір, рахунок, знак суми, валюту й категорію та окремо вирішити, чи немає дубліката.
Якщо вам потрібен застосунок із вбудованою камерою, папкою вхідних чеків і збереженням вкладень, це не той продукт. Expense Budget Tracker призначений для структурованих фінансових даних. Зображення чеків, які потрібно зберегти, і надалі мають лежати у вашій файловій системі, архіві документів або іншому сервісі.
Прямий Agent API або віддалений MCP-конектор
Expense Budget Tracker підтримує два способи підключення. Обидва дають доступ до тих самих типів фінансових даних, але відрізняються способом автентифікації та поведінкою клієнта.
Прямий Agent API для Claude Code, Codex та агентів із підтримкою HTTP
Пряме підключення починається за адресою:
https://api.expense-budget-tracker.com/v1/
Спочатку агент виконує GET /v1/, дотримується інструкцій із початкової відповіді API, проходить підключення за кодом з електронної пошти й зберігає отриманий довготривалий ApiKey поза пам’яттю чату. Потім він викликає /v1/me, отримує список робочих просторів і вибирає потрібний, переглядає /v1/schema, читає дані через /v1/sql/query і надсилає одну схвалену зміну через /v1/sql/execute.
Цей спосіб зручний, коли Claude Code або Codex уже може відкрити файл чека на вашому комп’ютері й виконувати HTTP-запити. Посібник із налаштування AI-агента описує послідовність підключення, а довідник API — актуальний контракт читання й запису. Докладніший сценарій роботи з Claude Code у терміналі наведено в статті про відстеження витрат і керування бюджетом за допомогою Claude Code.
Віддалений MCP із браузерною авторизацією OAuth
Клієнт із підтримкою MCP натомість може підключитися до:
https://mcp.expense-budget-tracker.com/mcp
Цей спосіб використовує авторизацію OAuth у браузері. Для нього потрібні токени доступу й оновлення MCP, а не ApiKey від Agent API. Для читання застосовуються такі інструменти, як list_workspaces, get_schema і sql_query; для запису потрібна окрема область доступу expenses:write, а сам запис виконується через sql_execute.
Віддалений конектор не отримує доступу до фотографій на вашому комп’ютері. Чек усе одно треба передати клієнту або моделі через підтримуване вкладення чи механізм доступу до файлів. Посібник із MCP-конектора пояснює авторизацію OAuth і області доступу.
Незалежно від способу підключення порядок той самий: спочатку розпізнати чек, потім перевірити реєстр, далі показати попередній перегляд і лише після цього окремо схвалити запис.
Повний процес для одного невеликого чека
Розгляньмо чітке фото вигаданого ресторанного чека:
| Надруковане поле | Видиме значення |
|---|---|
| Продавець | North Street Cafe, New York |
| Дата й час | August 31, 2026, 12:17 PM |
| Проміжна сума за їжу | $24.00 |
| Знижка | -$2.00 |
| Податок | $1.82 |
| Чайові | $4.00 |
| Підсумкова сума | $27.82 |
| Підказка щодо оплати | Visa ending 4242 |
Арифметика сходиться: $24.00 - $2.00 + $1.82 + $4.00 = $27.82. Це корисна перевірка, але вона не доводить, який рахунок або категорію слід вибрати. Агенту все одно потрібні дані реєстру.
1. Спочатку підтвердьте робочий простір і рахунок
Попросіть агента визначити й показати:
- контекст облікового запису, у який виконано вхід
- точну назву та ID робочого простору
- цільовий рахунок у реєстрі та його валюту
- дату чека й часовий пояс
- валюту чека
Для цього прикладу припустімо, що користувач підтвердив робочий простір Personal з ID workspace-personal-example, рахунок a-visa_4242-usd, валюту USD і місцевий час Нью-Йорка для цього чека. Це вигадані значення, а не вбудовані назви робочого простору, рахунку чи категорії. Останні чотири цифри картки — лише підказка, а не дозвіл мовчки вибрати рахунок. Якщо дві збережені картки закінчуються на 4242, агент має зупинитися й запитати, якою з них заплатили.
2. Перегляньте актуальну схему
Агент має викликати:
GET https://api.expense-budget-tracker.com/v1/schema
Відповідь зі схемою — головне джерело актуальної інформації про доступні таблиці, стовпці, обмеження й правила запису. Приклади у статті можуть застаріти, тому перед створенням SQL агент має орієнтуватися саме на /v1/schema. У поточній схемі реєстру кожен INSERT повинен явно містити підтверджений workspace_id. Збереження робочого простору для API-ключа задає контекст запиту, але не прибирає цей стовпець із рядка, який додається.
3. Відокремте факти від підказок і невизначеностей
Якісний звіт про розпізнавання може виглядати так:
| Поле | Розпізнане значення | Упевненість або проблема |
|---|---|---|
| Продавець | North Street Cafe | Чітко |
| Час транзакції | 2026-08-31 12:17 local |
Чітко; користувач підтвердив часовий пояс Нью-Йорка |
| Валюта | USD | $ і підтверджене місце; користувач підтвердив валюту рахунку |
| Проміжна сума | 24.00 |
Чітко |
| Знижка | -2.00 |
Чітко |
| Податок | 1.82 |
Чітко |
| Чайові | 4.00 |
Чітко |
| Сплачена сума | 27.82 |
Чітко; арифметика сходиться |
| Спосіб оплати | Visa ending 4242 |
Підказка збігається з рахунком, який підтвердив користувач |
Не перетворюйте непевний текст на впевнено заповнене поле. Якщо остання цифра підсумку може бути 2 або 7, правильна відповідь — «підсумок нечіткий; потрібне інше зображення або ручне підтвердження», а не правдоподібна здогадка.
4. Виберіть один запис або поділ за категоріями
Увесь цей чек стосується витрат у ресторані, тому один рядок реєстру з категорією Dining Out доречний, якщо саме така категорія вже існує в робочому просторі. Податок, знижка й чайові пояснюють підсумкову суму; для звичайного особистого бюджету їх не потрібно записувати окремими рядками.
Чек із супермаркету, в якому є продукти, ліки та кухонний прилад, може потребувати поділу за категоріями. У поточній моделі реєстру це означає кілька рядків з однаковим event_id, зазвичай на одному рахунку. Кожен рядок отримує власну категорію й суму зі знаком, а разом ці суми мають точно дорівнювати початковому платежу: -27.82 для витрати на $27.82.
У попередньому перегляді слід пояснити, як між категоріями розподілено податок, знижки, сервісні збори та округлення, що стосуються всього чека. Для одного чека підійде пропорційний розподіл, для іншого — віднесення знижки до конкретного товару, якщо цей зв’язок очевидний. Універсального правила немає. Якщо розподіл буде довільним, залиште один рядок у ширшій наявній категорії або запитайте користувача.
Агент має отримати список наявних категорій реєстру, а не вигадувати нову класифікацію лише тому, що вона звучить охайніше:
SELECT category, COUNT(*) AS use_count
FROM ledger_entries
WHERE kind = 'spend'
AND category IS NOT NULL
GROUP BY category
ORDER BY use_count DESC
LIMIT 100
5. Перевірте записи за той самий період і покажіть кандидатів, а не остаточний висновок
Перш ніж готувати INSERT, виконайте запит до підтвердженого рахунку за період навколо дати чека. Для нашого прикладу вузька перевірка на дублікати може виглядати так:
SELECT entry_id, event_id, ts, account_id, amount, currency, category, counterparty, note, external_id
FROM ledger_entries
WHERE event_id = 'receipt-2026-08-31-north-street-cafe-2782'
OR (
account_id = 'a-visa_4242-usd'
AND currency = 'USD'
AND ts >= '2026-08-29 00:00:00-04'
AND ts < '2026-09-03 00:00:00-04'
AND amount = -27.82
)
ORDER BY ts
LIMIT 100
Агент надсилає цей запит до POST /v1/sql/query. Тут event_id — буквальне значення, яке агент створив для цієї події; у разі поділу його матимуть усі пов’язані рядки. Воно дає змогу групувати рядки й виконувати точкові запити, але база даних не вважає його унікальним ключем для виявлення дублікатів. Точний збіг event_id — вагома причина перевірити запис, а не дозвіл щось видаляти чи перезаписувати.
Запис із близькою датою, такою самою сумою та схожою назвою продавця теж є лише кандидатом у дублікати. Дві реальні оплати в кафе можуть мати однакову суму, а непроведена карткова операція пізніше може з’явитися з іншою назвою продавця або позначкою часу.
Якщо схожий запис уже існує, попередній перегляд має показати його поруч із даними чека й не пропонувати INSERT, доки користувач не з’ясує, чи це дублікат.
6. Покажіть точний запис і точний запит на запис
Припустімо, що запит не знайшов кандидатів у дублікати, а Dining Out уже існує як категорія. Тоді попередній перегляд без запису може бути конкретним:
| Поле реєстру | Запропоноване значення |
|---|---|
| Робочий простір | Personal (workspace-personal-example) |
| Рахунок | a-visa_4242-usd |
| Позначка часу | 2026-08-31 12:17:00-04 |
| Сума | -27.82 |
| Валюта | USD |
| Тип | spend |
| Категорія | Dining Out |
| Контрагент | North Street Cafe |
| Примітка | Receipt subtotal 24.00; discount -2.00; tax 1.82; tip 4.00 |
| Кандидати в дублікати | Не знайдено у перевіреному діапазоні |
Попередній перегляд також має містити точний SQL, який агент збирається надіслати:
INSERT INTO ledger_entries (
event_id,
ts,
account_id,
amount,
currency,
kind,
category,
counterparty,
note,
workspace_id
)
VALUES (
'receipt-2026-08-31-north-street-cafe-2782',
'2026-08-31 12:17:00-04',
'a-visa_4242-usd',
-27.82,
'USD',
'spend',
'Dining Out',
'North Street Cafe',
'Receipt subtotal 24.00; discount -2.00; tax 1.82; tip 4.00',
'workspace-personal-example'
)
Це все ще лише попередній перегляд. Агент має повідомити очікуваний результат — один новий рядок реєстру в підтвердженому робочому просторі — і дочекатися явного схвалення, наприклад Approve this exact write. («Схвалюю саме цей запис»). Якщо змінюється будь-яке значення, зокрема робочий простір, рахунок, сума, категорія чи примітка, старий попередній перегляд втрачає чинність і потрібен новий.
7. Виконайте лише схвалений запит, а потім повторно зчитайте запис
Після схвалення прямий Agent API надсилає точний запит до:
POST https://api.expense-budget-tracker.com/v1/sql/execute
Потім агент перевіряє результат через /v1/sql/query:
SELECT entry_id, event_id, ts, account_id, amount, currency, kind, category, counterparty, note, workspace_id
FROM ledger_entries
WHERE event_id = 'receipt-2026-08-31-north-street-cafe-2782'
LIMIT 100
Повторне читання має повернути рівно один рядок, що збігається зі схваленим попереднім переглядом. Успішної HTTP-відповіді без такого порівняння недостатньо для повної перевірки.
8. Звірте запис, коли карткову операцію буде проведено
Чек фіксує, що сталося на касі. Проведена карткова транзакція підтверджує, яку суму банк остаточно списав із рахунку. Коли вона з’явиться в пізнішому експорті з картки, виконайте пошук за тим самим рахунком, сумою, діапазоном дат, підказками щодо продавця та будь-яким стабільним ID джерела. Якщо дані вказують на рядок, уже записаний за чеком, не імпортуйте рядок із виписки вдруге.
Якщо проведена сума відрізняється, не створюйте балансувальний запис. З’ясуйте, чи правильно зчитано підсумок чека, чи змінилися чайові, чи попереднє блокування коштів стало остаточною операцією, чи картка конвертувала платіж в іноземній валюті. Підготуйте одне видиме виправлення й попросіть окремо його схвалити.
Для більших пакетів посібник з імпорту банківських виписок пояснює роботу з періодами, що перетинаються, і переказами. Посібник зі звірки бюджету показує, як порівнювати проведені операції на рахунку з відомим правильним балансом.
Де розпізнавання чеків ускладнюється
Фото чеків — неідеальні вхідні дані. Обережний AI-сканер чеків Claude або сканер чеків Codex має показувати такі проблеми, а не приховувати їх упевненими здогадками.
| Складний випадок | Безпечна дія |
|---|---|
| Розмите, темне, складене чи обрізане фото | Позначте нерозбірливі поля, попросіть нове зображення або значення вручну й нічого не записуйте, доки підсумок, дата чи валюта лишаються непевними. |
| Проміжна й підсумкова суми | Перерахуйте видимі складові та використовуйте остаточну суму, яку справді сплачено. Перевірте, чи податок включено або додано окремо та чи сервісний збір уже входить до підсумку. |
| Чайові | Розрізняйте надруковані рекомендовані чайові, чайові, вписані від руки, суму авторизації за карткою й остаточний підсумок. Пізніше порівняйте його з проведеною сумою за карткою. |
| Знижки й купони | Збережіть остаточну сплачену суму. У разі поділу за категоріями покажіть, як розподілено знижку, а не відносьте її до категорії без пояснення. |
| Повернення товарів і коштів | Сприймайте чек повернення як підтвердження очікуваного або завершеного повернення коштів, а не як звичайний дохід. Записуйте повернення коштів окремим структурованим рядком на рахунку-отримувачі лише тоді, коли зрозумілі його статус і сума, а після проведення звірте цей рядок. |
| Чек із кількома категоріями | Надайте пов’язаним рядкам один event_id; покажіть кожну суму зі знаком за категорією, правило розподілу, рішення щодо округлення й загальну суму. Разом рядки мають дорівнювати остаточній сплаченій сумі. |
| Готівка чи картка | Використовуйте фактичний рахунок оплати. Логотип продавця або гаманець на фото не доводить спосіб оплати; якщо рядка зі способом оплати немає, запитайте користувача. |
| Іноземна валюта | Явно зберігайте валюту чека. Якщо картковий рахунок має іншу валюту, не вигадуйте обмінний курс чи остаточну суму списання: дочекайтеся проведеної операції або отримайте точну підтверджену суму. |
| Кандидати в дублікати | Порівняйте дату, суму зі знаком, рахунок, валюту, продавця та будь-який стабільний ідентифікатор джерела. Покажіть кандидатів для рішення користувача замість того, щоб мовчки пропускати або додавати запис. |
Така сама обережність потрібна й із податковими позначками. Чек може бути підтвердним документом для обліку, але модель не повинна оголошувати кожну покупку бізнес-витратою, яку дозволено врахувати для цілей оподаткування, або робити юридичні чи податкові висновки лише за назвою продавця. Документи, потрібні для податкового обліку чи підтвердження відшкодування, зберігайте у власній системі, а щодо питань, які залежать від ваших обставин, звертайтеся по кваліфіковану консультацію.
Готовий запит для Claude або Codex
Вставте цей запит після підключення агента, а потім замініть значення у квадратних дужках. Поки ви освоюєте процес, найкраще працювати з одним чеком за раз.
Використай зображення чека за адресою [exact file path or attachment] і Expense Budget Tracker.
Для прямого API почни з https://api.expense-budget-tracker.com/v1/ та дотримуйся
інструкцій із початкової відповіді API. Використовуй збережений ApiKey поза пам’яттю чату.
Якщо підключення працює через MCP, використовуй MCP-інструменти для робочого простору,
схеми й запитів, але збережи описані нижче правила схвалення.
Поки нічого не записуй. Для прямого API покажи контекст мого облікового запису з /me.
Покажи доступні робочі простори й попроси мене підтвердити точний робочий простір.
Переглянь /v1/schema (або виклич get_schema). Отримай список доступних рахунків і
попроси мене підтвердити точний рахунок та його валюту. Не визначай рахунок лише за
останніми чотирма цифрами картки.
Прочитай зображення й розпізнай продавця, дату й час чека, валюту, проміжну суму,
податок, чайові, сервісний збір, знижки, повернення, підсумкову суму та підказки щодо
оплати. Познач усе розмите, обрізане, неоднозначне або арифметично суперечливе. Ніколи
не вигадуй відсутніх значень. Скажи, чи доречний один рядок реєстру або поділ за
категоріями, і зроби запит до моїх наявних категорій, перш ніж пропонувати назви. Для поділу
використовуй один event_id для пов’язаних рядків і доведи, що сума їхніх значень зі
знаками дорівнює підсумковій сумі.
Запитами лише для читання перевір записи реєстру на підтвердженому рахунку за період,
який перетинається з указаним діапазоном дат. Покажи кандидатів у дублікати разом із
доказами; не вважай, що збіг дати й суми однозначно означає ту саму або нову покупку.
Потім покажи попередній перегляд без запису: підтверджений робочий простір, точний
рахунок, суму зі знаком, точну валюту, позначку часу, тип, наявну категорію,
контрагента, примітку, кожну суму поділу, якщо він потрібний, і кандидатів у дублікати.
Покажи точний SQL-запит на запис, додай підтверджений workspace_id до кожного INSERT і
вкажи очікувану кількість змінених рядків. Не створюй балансувальних записів, вигаданих
конвертацій або додаткових рядків.
Зупинись і дочекайся мого окремого явного схвалення саме цього запиту на запис. Після
схвалення надішли лише погоджений запит через /v1/sql/execute (або sql_execute). Зчитай
рядок назад через /v1/sql/query (або sql_query) і порівняй кожне збережене поле зі
схваленим попереднім переглядом. Повідом про будь-яку невідповідність і не змінюй більше
жодних даних. Пізніше допоможи зіставити цей запис за чеком із проведеною банківською
або картковою транзакцією, не створюючи дубліката.
Запит навмисно суворий. «Сканування чеків за допомогою AI» звучить як просте розпізнавання даних, але найдорожчі помилки зазвичай стаються вже після нього: неправильний рахунок, неправильна валюта, вигадана категорія, повторне додавання або запис без перевірки.
Межі даних простими словами
Відсутність підключення до банку не означає, що жодні дані не залишають ваш комп’ютер. Кожна частина цього процесу має окрему межу.
| Межа | Які дані залучено |
|---|---|
| Ваш пристрій або клієнт | Спочатку чек існує як фото або файл. Клієнт отримує лише той доступ до файлу, який ви надаєте. |
| Claude, Codex і вибраний постачальник моделі | Вміст чека й ваші інструкції обробляються відповідно до умов і налаштувань цього постачальника та клієнта. Перегляньте їх для своєї конфігурації; Expense Budget Tracker не може від імені Anthropic або OpenAI надавати гарантії конфіденційності. |
| Прямий Agent API або MCP-конектор | Агент надсилає лише потрібні для завдання запити про робочий простір і схему, запити до реєстру та схвалені операції запису структурованих даних. Зображення чека не потрібне жодному з підключень до трекера. |
| Сховище Expense Budget Tracker | У цьому процесі трекер зберігає схвалені структуровані фінансові дані: суму, валюту, рахунок, категорію, контрагента й примітку. Зображення чека він не зберігає. |
| Ваш архів чеків | Якщо оригінальне зображення потрібне для повернення товару, гарантії, відшкодування чи обліку, ви зберігаєте його в окремому вибраному вами місці. |
Цей процес може добре підійти, якщо вам потрібен бюджетний застосунок без підключення до банку: постійний банківський канал не потрібен, а кожна запропонована зміна в реєстрі лишається видимою. Ви все одно вибираєте постачальника AI, надаєте доступ до файлу й надсилаєте вибрані фінансові запити на читання та запис через підключення до трекера.
Чи підходить вам такий спосіб сканування чеків?
Якщо «бюджетний застосунок зі скануванням чеків» для вас означає вбудовану камеру телефона, папку вхідних чеків і збережені вкладення, виберіть продукт, створений саме для цього. Описаний процес підійде, якщо ви хочете сканувати чеки за допомогою AI, але кожну операцію запису до реєстру бачити окремо від початкового зображення.
Використовуйте цей процес, якщо вам потрібні:
- внесення чеків без підключення банківського рахунку
- Claude або Codex для розпізнавання зображення й пошуку в реєстрі
- наявні рахунки й категорії як основа для нового запису
- точний попередній перегляд перед кожною операцією запису
- кандидати в дублікати замість мовчазних припущень
- перевірений структурований запис у реєстрі, який пізніше можна звірити
Expense Budget Tracker не намагається замінити архів чеків із пошуком.
Почніть з одного чіткого чека, одного підтвердженого рахунку й однієї знайомої категорії. Перевірте арифметику, схваліть один точний запис, повторно зчитайте його з реєстру та зіставте з операцією, коли платіж буде проведено. Цей короткий цикл залишає зрозумілу історію перевірок.