اسکن رسید با هوش مصنوعی برای ثبت هزینه: گردشکار Claude و Codex
با Claude یا Codex رسید را برای Expense Budget Tracker بخوانید: مبلغها را استخراج کنید، دستور دقیق ثبت را ببینید و تأیید کنید و سپس نتیجه را در دفتر کل راستیآزمایی کنید.
روی رسید کافه مبلغ $27.82 دیده میشود، اعلان کارت هنوز وضعیت «در انتظار» دارد و کاغذ کنار لپتاپ کمکم لوله میشود. یک هفته که بگذرد، بهخاطرآوردن نام فروشنده، مبلغ انعام و دستهبندی درست سختتر خواهد شد.
تا وقتی رسید جلوی دستتان است، Claude یا Codex میتواند عکس آن را به پیشنویس یک تراکنش تبدیل کند. عامل هوش مصنوعی جزئیات روی رسید را میخواند، تراکنش پیشنهادی را با حسابها، دستهبندیها و ثبتهای اخیر دفتر کل مقایسه میکند و دستور دقیقی را که میخواهد اجرا کند برای بازبینی نشان میدهد. تا همان دستور مشخص را تأیید نکنید، هیچ دادهای تغییر نمیکند.
مرز محصول را باید روشن نگه داشت. Expense Budget Tracker دوربین یا اسکنر رسید داخلی ندارد و تصویر رسید را ذخیره نمیکند. این Claude، Codex یا ارائهدهندهٔ مدلِ انتخابشده در تنظیمات شماست که تصویر ارسالی را تفسیر میکند. ردیاب فقط دادههای ساختیافتهٔ دفتر کل را که شما تأیید کردهاید نگه میدارد.
توانایی خواندن تصویر هم به ابزار هوش مصنوعی انتخابی شما بستگی دارد. طبق مستندات Anthropic، Claude میتواند ورودی تصویری را پردازش و تحلیل کند و OpenAI Responses API ورودی متنی، تصویری و فایل را میپذیرد. البته این به آن معنا نیست که هر کلاینت Claude یا Codex خودکار به عکسهای محلی دسترسی دارد. کلاینت باید از پیوست پشتیبانی کند یا به مسیر فایل دسترسی داشته باشد و شما هم باید اجازهٔ لازم را بدهید. درک تصویر کمککننده است، اما بازبینی عددها همچنان بر عهدهٔ انسان است.
این «اسکنر» در عمل چه کار میکند؟
اینجا با یک گردشکار رسید به دفتر کل با کمک هوش مصنوعی طرفیم، نه قابلیتی داخلی برای دوربین.
میتوانید آن را تحویل رسید به ردیاب هزینه در نظر بگیرید: مدل، تصویر در اختیارش را پردازش میکند و Expense Budget Tracker دادههای تأییدشدهٔ دفتر کل را مدیریت میکند.
| مرحله | چه اتفاقی میافتد |
|---|---|
| دریافت تصویر | عکس میگیرید یا فایل اسکن را جایی ذخیره میکنید که Claude یا Codex به آن دسترسی داشته باشد. |
| تفسیر | مدل اطلاعات قابلمشاهده مثل فروشنده، تاریخ، جمع پیش از کسورات، تخفیف، مالیات، انعام، مبلغ نهایی، ارز و نشانههای روش پرداخت را میخواند و موارد نامطمئن را مشخص میکند. |
| بررسی دفتر کل | عامل، فضای کاری انتخابشده در Expense Budget Tracker، ساختار فعلی دادهها، حسابها، دستهبندیها و ثبتهای احتمالاً تکراری را میخواند. |
| پیشنمایش | عامل اطلاعات استخراجشده، ابهامها، دستهبندی انتخابی و دستور دقیق پیشنهادی برای ثبت را نشان میدهد. |
| تأیید | شما همان دستور مشخص را تأیید میکنید؛ یا اصلاحش میکنید و پیشنمایش تازهای میخواهید. |
| راستیآزمایی | عامل یک تراکنش ساختیافته ثبت میکند و آن را دوباره از دفتر کل میخواند. |
| تطبیق | وقتی تراکنش کارت یا بانک قطعی شد، آن را با ثبت رسید تطبیق میدهید تا نسخهٔ دومی وارد نشود. |
همین مرحلهٔ آخر است که یک اسکنر رسید با هوش مصنوعی برای ثبت هزینه را در دفتری قابلحسابرسی واقعاً مفید میکند. درست خواندن $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/ را فراخوانی میکند، مسیر معرفیشده در پاسخ را ادامه میدهد، راهاندازی با کد ایمیلی را به پایان میرساند و ApiKey بلندمدت دریافتی را بیرون از حافظهٔ گفتوگو ذخیره میکند. بعد /v1/me را فراخوانی میکند، فضاهای کاری را میگیرد و یکی را انتخاب میکند، /v1/schema را میخواند، با /v1/sql/query داده میگیرد و یک تغییر تأییدشده را از طریق /v1/sql/execute میفرستد.
این مسیر برای زمانی مناسب است که Claude Code یا Codex از قبل بتواند فایل رسید را روی رایانهٔ شما باز کند و درخواست HTTP بفرستد. راهنمای راهاندازی عامل هوش مصنوعی ترتیب شروع کار را توضیح میدهد و مرجع API قرارداد فعلی خواندن و نوشتن را مستند کرده است. برای نمونهای کاملتر از کار با Claude Code در ترمینال، روش ثبت هزینهها و مدیریت بودجه با Claude Code را بخوانید.
MCP راهدور با OAuth مرورگر
کلاینتی که از MCP پشتیبانی میکند میتواند بهجای مسیر قبلی به این نشانی وصل شود:
https://mcp.expense-budget-tracker.com/mcp
مجوز این مسیر از طریق OAuth در مرورگر صادر میشود. این اتصال بهجای ApiKey مربوط به Agent API، از توکن دسترسی و توکن تازهسازی MCP استفاده میکند. خواندن داده با ابزارهایی مثل 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 با چهار رقم آخر 4242 |
حساب درست از آب درمیآید: $24.00 - $2.00 + $1.82 + $4.00 = $27.82. این کنترل مفید است، اما حساب مقصد یا دستهبندی را مشخص نمیکند. عامل هنوز باید دفتر کل را ببیند.
۱. پیش از تفسیر تصویر، مقصد را تأیید کنید
از عامل بخواهید این موارد را پیدا کند و نشان دهد:
- اطلاعات حساب کاربری واردشده
- نام و شناسهٔ دقیق فضای کاری
- حساب مقصد در دفتر کل و ارز آن
- تاریخ رسید و منطقهٔ زمانی مربوط به آن
- ارز رسید
در این مثال فرض میکنیم کاربر فضای کاری Personal با شناسهٔ workspace-personal-example، حساب a-visa_4242-usd، ارز USD و زمان محلی نیویورک را برای رسید تأیید کرده است. اینها مقادیر فرضیاند، نه نامهای پیشفرض فضای کاری، حساب یا دستهبندی در محصول. چهار رقم آخر کارت فقط یک نشانه است و اجازه نمیدهد عامل بیسؤال حسابی را انتخاب کند. اگر دو کارت ذخیرهشده به 4242 ختم میشوند، عامل باید بایستد و بپرسد پرداخت با کدام کارت انجام شده است.
۲. ساختار فعلی دادهها را بررسی کنید
عامل باید این درخواست را بفرستد:
GET https://api.expense-budget-tracker.com/v1/schema
پاسخ schema مرجع اصلی رابطهها، ستونها، محدودیتها و قواعد فعلی نوشتن داده است. مثالهای مقاله ممکن است با گذشت زمان قدیمی شوند؛ عامل باید پیش از ساخت SQL از /v1/schema پیروی کند. در ساختار فعلی دفتر کل، هر INSERT باید workspace_id تأییدشده را صریحاً داشته باشد. ذخیرهکردن فضای کاری روی کلید API فقط زمینهٔ درخواست را تعیین میکند و نیاز به این ستون در ردیف جدید را از بین نمیبرد.
۳. اطلاعات قطعی، نشانهها و ابهامها را جدا کنید
یک گزارش استخراج خوب میتواند چنین شکلی داشته باشد:
| فیلد | مقدار استخراجشده | میزان اطمینان یا مسئله |
|---|---|---|
| فروشنده | North Street Cafe | خوانا |
| زمان تراکنش | 2026-08-31 12:17 به وقت محلی |
خوانا؛ کاربر منطقهٔ زمانی نیویورک را تأیید کرده است |
| ارز | USD | علامت $ و مکان تأییدشده؛ کاربر ارز حساب را هم تأیید کرده است |
| جمع پیش از کسورات | 24.00 |
خوانا |
| تخفیف | -2.00 |
خوانا |
| مالیات | 1.82 |
خوانا |
| انعام | 4.00 |
خوانا |
| مبلغ پرداختشده | 27.82 |
خوانا و مطابق محاسبه |
| روش پرداخت | Visa با چهار رقم آخر 4242 |
نشانهای که با حساب تأییدشدهٔ کاربر تطبیق داده شده است |
متن نامطمئن را قطعی جلوه ندهید. اگر رقم آخر مبلغ نهایی ممکن است 2 یا 7 باشد، خروجی درست این است: «مبلغ نهایی خوانا نیست؛ عکس دیگری یا تأیید دستی لازم است.» انتخاب یک عدد محتمل، راهحل قابلقبولی نیست.
۴. یک تراکنش ثبت شود یا چند ردیف با دستهبندیهای مختلف؟
تمام اقلام این رسید هزینهٔ رستوراناند. پس اگر دستهبندی دقیق 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
۵. ثبتهای همپوشان را بررسی کنید؛ نامزد بدهید، نه حکم قطعی
پیش از آمادهکردن دستور درج، عامل باید حساب تأییدشده را در بازهای نزدیک به تاریخ رسید جستوجو کند. برای رسید نمونه، بررسی محدود موارد تکراری میتواند این باشد:
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 دلیل محکمی برای بررسی بیشتر است، نه اجازهای برای حذف یا بازنویسی داده.
ردیفی در همان حوالی زمانی، با همان مبلغ و نام فروشندهای شبیه هم فقط یک نامزد تکراری است. ممکن است دو پرداخت واقعی در یک کافه مبلغ یکسانی داشته باشند. از طرف دیگر، اعلان در انتظار کارت هم ممکن است بعداً با نام فروشنده یا زمان متفاوتی قطعی شود.
اگر ثبت احتمالاً منطبقی از قبل وجود دارد، پیشنمایش باید آن را کنار اطلاعات استخراجشده از رسید نشان دهد و تا وقتی کاربر تکلیف تعارض را روشن نکرده است، هیچ دستور درجی پیشنهاد نکند.
۶. تراکنش و دستور دقیق ثبت را نشان دهید
فرض کنید جستوجوی موارد تکراری هیچ نامزدی برنگردانده و 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'
)
این هنوز فقط یک پیشنمایش است. عامل باید نتیجهٔ مورد انتظار را هم بگوید—افزودهشدن یک ردیف جدید به دفتر کل در فضای کاری تأییدشده—و منتظر تأییدی صریح مثل «اجرای همین دستور دقیق را تأیید میکنم» بماند. تغییر هر مقدار، از فضای کاری و حساب گرفته تا مبلغ، دستهبندی یا یادداشت، پیشنمایش قبلی را باطل میکند و به پیشنمایش تازهای نیاز دارد.
۷. فقط دستور تأییدشده را اجرا کنید و بعد آن را دوباره بخوانید
پس از تأیید، 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 بدون این مقایسه، راستیآزمایی کامل محسوب نمیشود.
۸. پس از قطعیشدن برداشت کارت، آن را تطبیق دهید
رسید نشان میدهد پای صندوق چه اتفاقی افتاده است؛ تراکنش قطعی کارت نشان میدهد چه مبلغی واقعاً به حساب رسیده. وقتی این تراکنش بعداً در خروجی کارت ظاهر شد، همان حساب، مبلغ، بازهٔ تاریخ، نشانههای فروشنده و هر شناسهٔ پایدار منبع را جستوجو کنید. اگر شواهد به همان ردیفی اشاره میکنند که از روی رسید ثبت شده، ردیف صورتحساب را هنگام ورود کنار بگذارید تا تراکنش دوباره ثبت نشود.
اگر مبلغ قطعی با رسید فرق دارد، یک تراکنش جبرانی نسازید. بررسی کنید آیا مبلغ رسید اشتباه خوانده شده، انعام تغییر کرده، مبلغ مسدودی کارت به مقدار دیگری قطعی شده یا کارت هزینهای ارزی را تبدیل کرده است. یک اصلاح مشخص و قابلمشاهده آماده کنید و برای اجرای آن جداگانه تأیید بگیرید.
برای دستههای بزرگتر، راهنمای ورود صورتحساب بانکی بازههای همپوشان و مدیریت انتقالها را توضیح میدهد. راهنمای تطبیق بودجه هم نشان میدهد چطور فعالیت قطعی حساب را با ماندهای قابلاعتماد مقایسه کنید.
کدام رسیدها سختتر خوانده میشوند؟
عکس رسید ورودی تمیز و قابلپیشبینیای نیست. یک اسکنر رسید مبتنی بر Claude یا Codex باید این موارد را آشکار کند، نه اینکه با حدسزدن روی آنها سرپوش بگذارد.
| مورد دشوار | روش امن رسیدگی |
|---|---|
| عکس تار، تاریک، تاخورده یا ناقص | فیلدهای ناخوانا را مشخص کنید، عکس تازه یا مقدار دستی بخواهید و تا وقتی مبلغ نهایی، تاریخ یا ارز نامطمئن است چیزی ثبت نکنید. |
| جمع پیش از کسورات در برابر مبلغ نهایی | اجزای خوانا را دوباره جمع بزنید و مبلغ نهاییِ واقعاً پرداختشده را به کار ببرید. بررسی کنید مالیات داخل مبلغ است یا جداگانه اضافه شده و آیا هزینهٔ خدمات از قبل در مبلغ نهایی آمده است. |
| انعام | انعام پیشنهادی چاپشده، انعام دستنویس، مبلغ مجوز اولیهٔ کارت و مبلغ نهایی را با هم یکی نگیرید. بعداً مبلغ را با تراکنش قطعی کارت مقایسه کنید. |
| تخفیف و کوپن | مبلغ نهایی پرداختشده را حفظ کنید. اگر رسید بین چند دسته تقسیم میشود، نشان دهید تخفیف چطور تخصیص یافته است؛ آن را بیسروصدا به یک دسته نسبت ندهید. |
| مرجوعی و بازپرداخت وجه | رسید مرجوعی را مدرکی برای بازپرداخت وجهِ در انتظار یا تکمیلشده بدانید، نه درآمد عادی. فقط وقتی وضعیت و مبلغ روشن است، بازپرداخت را بهصورت یک ثبت ساختیافتهٔ جداگانه در حساب دریافتکننده وارد کنید و پس از قطعیشدن آن را تطبیق دهید. |
| رسید چنددستهای | برای ردیفهای مرتبط یک event_id بگذارید؛ مبلغ علامتدار هر دسته، قاعدهٔ تخصیص، تصمیم مربوط به گردکردن و مجموع را نشان دهید. مجموع ردیفها باید با مبلغ نهایی پرداختشده برابر باشد. |
| پرداخت نقدی یا کارتی | حسابی را انتخاب کنید که پرداخت واقعاً از آن انجام شده است. لوگوی فروشنده یا کیف پولی که در عکس دیده میشود روش پرداخت را ثابت نمیکند؛ اگر سطر نوع پرداخت روی رسید نیست، سؤال کنید. |
| ارز خارجی | ارز رسید را صریح نگه دارید. اگر ارز حساب کارت متفاوت است، نرخ تبدیل یا مبلغ تسویه را حدس نزنید؛ منتظر تراکنش قطعی بمانید یا مبلغ دقیق و تأییدشده بگیرید. |
| نامزدهای تکراری | تاریخ، مبلغ علامتدار، حساب، ارز، فروشنده و هر شناسهٔ پایدار منبع را مقایسه کنید. نامزدها را برای تصمیمگیری نشان دهید؛ چیزی را بیسروصدا رد یا درج نکنید. |
همین احتیاط دربارهٔ برچسبهای مالیاتی هم لازم است. رسید میتواند برای نگهداری سوابق مفید باشد، اما مدل نباید هر خریدی را هزینهٔ قابلکسر کسبوکار اعلام کند یا فقط از روی نام فروشنده نتیجهگیری حقوقی یا مالیاتی داشته باشد. اسناد لازم برای امور مالیاتی یا اثبات بازپرداخت هزینه را در سامانهٔ اسناد خودتان نگه دارید و برای پرسشهای وابسته به شرایط شخصیتان از متخصص کمک بگیرید.
پرامپتی که میتوانید دوباره برای Claude یا Codex استفاده کنید
بعد از اتصال عامل، متن زیر را جایگذاری و مقدارهای داخل کروشه را عوض کنید. تا وقتی به این گردشکار عادت نکردهاید، بهتر است هر بار با یک رسید پیش بروید.
از تصویر رسید در [مسیر دقیق فایل یا پیوست] و Expense Budget Tracker استفاده کن.
برای API مستقیم، از https://api.expense-budget-tracker.com/v1/ شروع کن و مسیر
معرفیشده در پاسخ را ادامه بده. از ApiKey ذخیرهشده بیرون از حافظهٔ گفتوگو استفاده
کن. اگر این اتصال از MCP استفاده میکند، ابزارهای workspace/schema/query در MCP را
به کار ببر و همان مرز تأیید زیر را حفظ کن.
هنوز چیزی ننویس. در API مستقیم، اطلاعات حساب من را از /me نشان بده. فضاهای کاری
موجود را فهرست کن و از من بخواه نام و شناسهٔ دقیق فضای کاری را تأیید کنم. /v1/schema
را بررسی کن (یا get_schema را فراخوانی کن). حسابهای موجود را بخوان و حساب دقیق و
ارز آن را با من تأیید کن. فقط از روی چهار رقم آخر کارت، حساب را انتخاب نکن.
تصویر را بخوان و فروشنده، تاریخ و زمان رسید، ارز، جمع پیش از کسورات، مالیات، انعام،
هزینهٔ خدمات، تخفیفها، مرجوعیها، مبلغ نهایی و نشانههای پرداخت را استخراج کن. هر
مورد تار، ناقص، مبهم یا ناسازگار از نظر محاسباتی را مشخص کن. هیچ مقدار گمشدهای را
حدس نزن. بگو ثبت یک ردیف در دفتر کل مناسبتر است یا تقسیم تراکنش بین چند دسته، و
پیش از پیشنهاد نام، دستهبندیهای موجود مرا جستوجو کن. برای تراکنش چنددستهای، به
همهٔ ردیفهای مرتبط یک event_id بده و ثابت کن مجموع مبلغهای علامتدار آنها با مبلغ
نهایی برابر است.
با پرسوجوهای فقطخواندنی، ثبتهای همپوشان دفتر کل را در حساب و بازهٔ تاریخ
تأییدشده بررسی کن. نامزدهای تکراری را همراه با شواهدشان نشان بده؛ فقط بهدلیل برابر
بودن تاریخ و مبلغ فرض نکن که تراکنش قطعاً همان خرید قبلی یا قطعاً خریدی جدید است.
بعد یک پیشنمایش فقطخواندنی نشان بده که شامل فضای کاری تأییدشده، حساب دقیق، مبلغ
علامتدار، ارز دقیق، زمان، نوع، دستهبندی موجود، طرف معامله، یادداشت، همهٔ مبلغهای
تفکیکشده در صورت نیاز و نامزدهای تکراری باشد. دستور دقیق SQL را نمایش بده،
workspace_id تأییدشده را در هر INSERT قرار بده و تعداد ردیفهایی را که انتظار داری
تغییر کنند بگو. تراکنش جبرانی، تبدیل ارزی حدسی یا ردیف اضافه نساز.
متوقف شو و منتظر تأیید صریح و جداگانهٔ من برای اجرای همان دستور دقیق بمان. پس از
تأیید، فقط دستور تأییدشده را از طریق /v1/sql/execute (یا sql_execute) بفرست. ردیف را
با /v1/sql/query (یا sql_query) دوباره بخوان و همهٔ فیلدهای ذخیرهشده را با پیشنمایش
تأییدشده مقایسه کن. هر مغایرتی را بدون ایجاد تغییر بیشتر در دادهها گزارش کن. بعداً
کمکم کن این ثبت رسید را بدون ساخت مورد تکراری با تراکنش قطعی بانک یا کارت تطبیق دهم.
این پرامپت عمداً سختگیرانه است. «اسکن رسید با هوش مصنوعی» در ظاهر فقط استخراج اطلاعات است، اما خطاهای پرهزینه معمولاً بعد از استخراج رخ میدهند: انتخاب حساب یا ارز اشتباه، ساختن دستهبندی تازه، درج تکراری یا اجرای دستوری که بازبینی نشده است.
مرزهای داده، به زبان ساده
نبود اتصال بانکی به این معنا نیست که هیچ دادهای از رایانهٔ شما خارج نمیشود. هر بخش از این گردشکار مرز جداگانهای دارد.
| مرز | چه دادهای درگیر است؟ |
|---|---|
| دستگاه یا کلاینت شما | رسید ابتدا یک عکس یا فایل است. کلاینت فقط به فایلی دسترسی میگیرد که شما در اختیارش گذاشتهاید. |
| Claude، Codex و ارائهدهندهٔ مدل انتخابی | محتوای رسید و دستورهای شما طبق شرایط و تنظیمات آن ارائهدهنده و کلاینت پردازش میشود. شرایط مربوط به تنظیمات خودتان را بررسی کنید؛ Expense Budget Tracker نمیتواند از طرف Anthropic یا OpenAI تضمین اضافهای برای حریم خصوصی بدهد. |
| Agent API مستقیم یا اتصالدهندهٔ MCP | عامل، اطلاعات لازم را از فضای کاری و ساختار داده میخواند، دفتر کل را پرسوجو میکند و دستورهای ساختیافته و تأییدشدهٔ مورد نیاز را میفرستد. هیچکدام از این دو اتصال برای کار با ردیاب به تصویر رسید نیاز ندارند. |
| فضای ذخیرهسازی Expense Budget Tracker | در این گردشکار، ردیاب دادههای مالی ساختیافته و تأییدشده مثل مبلغ، ارز، حساب، دستهبندی، طرف معامله و یادداشت را نگه میدارد. تصویر رسید ذخیره نمیشود. |
| بایگانی رسیدهای شما | اگر تصویر اصلی را برای مرجوعی، ضمانت، بازپرداخت هزینه یا نگهداری سوابق لازم دارید، آن را در محل جداگانهای به انتخاب خودتان حفظ میکنید. |
این روش برای کسی که اپ بودجهبندی بدون اتصال بانکی میخواهد میتواند مناسب باشد: گردشکار رسید به جریان دائمی داده از بانک نیاز ندارد و هر تغییر پیشنهادی در دفتر کل پیش از اجرا دیده میشود. بااینحال هنوز باید ارائهدهندهٔ هوش مصنوعی را انتخاب کنید، به فایل دسترسی بدهید و خواندنها و نوشتنهای مالی منتخب را از طریق اتصال ردیاب بفرستید.
آیا این نوع اسکن رسید برای شما مناسب است؟
اگر از «اپ بودجهبندی با اسکن رسید» انتظار صندوق ورودی داخلی برای دوربین گوشی و نگهداری پیوستها را دارید، محصولی را انتخاب کنید که برای همین کار ساخته شده باشد. این گردشکار زمانی مناسب است که میخواهید رسید را با هوش مصنوعی بخوانید، اما هر دستور ثبت در دفتر کل جدا از تصویر اصلی و کاملاً قابلمشاهده بماند.
این گردشکار مناسب شماست اگر میخواهید:
- رسید را بدون اتصال حساب بانکی ثبت کنید
- تفسیر تصویر و جستوجوی دفتر کل را به Claude یا Codex بسپارید
- حسابها و دستهبندیهای موجود مبنای ثبت باشند
- پیش از هر تغییر، دستور دقیق آن را در پیشنمایش ببینید
- بهجای تصمیمهای پنهانی، نامزدهای تکراری را برای بررسی دریافت کنید
- یک تراکنش ساختیافته و راستیآزماییشده داشته باشید که بعداً بتوانید آن را تطبیق دهید
Expense Budget Tracker قرار نیست جای یک بایگانی قابلجستوجوی رسید را بگیرد.
با یک رسید خوانا، یک حساب تأییدشده و دستهبندیای آشنا شروع کنید. محاسبه را بررسی کنید، یک دستور دقیق را تأیید کنید، نتیجه را دوباره بخوانید و بعد از قطعیشدن برداشت آن را تطبیق دهید. همین چرخهٔ کوتاه ردپایی قابلفهم برای حسابرسی باقی میگذارد.