چطور صورت‌حساب بانکی را وارد یک ردیاب هزینه کنیم

صورت‌حساب نهایی بانک یا کارت ممکن است آمادهٔ ورود به نظر برسد، اما هنوز چند دام در آن پنهان باشد. شاید بعضی تراکنش‌ها از قبل در دفتر کل شما باشند، چون آن‌ها را از روی رسید ثبت کرده‌اید. پرداخت صورت‌حساب کارت هم ممکن است هزینه‌ای تازه به نظر برسد، درحالی‌که خریدها چند هفته پیش ثبت شده‌اند.

راه امن برای وارد کردن صورت‌حساب بانکی در ردیاب هزینه این است که منبع اصلی بانک را حفظ کنید، از یک ایجنت هوش مصنوعی بخواهید پیش‌نویسی قابل‌بازبینی آماده کند، فقط ردیف‌هایی را تأیید کنید که می‌فهمید و بعد همهٔ حساب‌های تحت‌تأثیر را تطبیق دهید.

Expense Budget Tracker ابزار داخلی و یک‌کلیکی برای بارگذاری CSV یا PDF ندارد و ارتباط دائمی با بانک شما هم برقرار نمی‌کند. در این گردش‌کار، یک ایجنت هوش مصنوعی یا اسکریپت بیرونی صورت‌حساب را می‌خواند و با ردیاب تعامل می‌کند. ایجنت فایل را پردازش می‌کند؛ شما بررسی و کنترل می‌کنید که دقیقاً چه چیزی در دفتر کل ثبت شود.

با منبعی شروع کنید که همیشه بتوانید به آن رجوع کنید

صورت‌حساب اصلی را بدون تغییر نگه دارید. روی یک کپی کار کنید و مسیر دقیق فایل یا پیوست، حساب، ارز و تاریخ شروع و پایان دورهٔ بسته‌شده را به ایجنت بدهید.

تا جای ممکن، هر فایل باید مربوط به یک حساب و یک دورهٔ صورت‌حساب باشد. اگر خروجی بانک دو کارت را با هم ترکیب کرده، تراکنش‌های در انتظار و قطعی‌شده را در هم آمیخته یا چند دوره را روی هم انداخته است، پیش از استانداردسازی تراکنش‌ها بازبینی را به بخش‌های مشخص تقسیم کنید. وگرنه پیدا کردن علت اختلاف مانده در ادامه بسیار سخت می‌شود.

برای وارد کردن یک دورهٔ بسته‌شده، فقط از تراکنش‌های قطعی‌شده استفاده کنید. مبلغ، شرح یا تاریخ تراکنش‌های در انتظار ممکن است تغییر کند. آن‌ها را به‌جای اینکه سابقهٔ قطعی بدانید، در فهرستی جداگانه برای پیگیری بگذارید.

قالب فایل روی ریسک استخراج اثر می‌گذارد. در ورود صورت‌حساب بانکی CSV کار با فیلدهای ساخت‌یافته شروع می‌شود؛ در ورود صورت‌حساب بانکی PDF ممکن است نقطهٔ شروع متن استخراج‌شده یا خود تصویر باشد.

• یک CSV ساخت‌یافته معمولاً تمیزترین نقطهٔ شروع است، اما ایجنت همچنان باید کاراکتر جداکننده، قالب تاریخ، ممیز اعشار، ارز و این موضوع را تأیید کند که مبالغ در دو ستون جداگانهٔ بدهکار و بستانکار آمده‌اند یا در یک فیلد علامت‌دار.
• یک 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

این مسیر به‌جای ApiKey از OAuth مرورگر استفاده می‌کند. برای استفاده از list_workspaces، get_schema و sql_query محدودهٔ دسترسی expenses:read را درخواست کنید. محدودهٔ اختیاری 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 مستقیم، در هر درخواست به POST /v1/sql/execute یک دستور تأییدشدهٔ INSERT، UPDATE یا DELETE بفرستید. برای 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 ماندهٔ ابتدا و پایان دوره را نداشته باشد. در این حالت، از مانده‌ای جداگانه که بانک برای یک زمان دقیق ارائه کرده است یا از آخرین نقطهٔ تطبیق قابل‌اعتماد استفاده کنید. بدون هیچ‌کدام، می‌توانید پوشش ردیف‌ها و مجموع‌ها را بررسی کنید، اما نمی‌توانید مدعی تطبیق کامل صورت‌حساب بانکی شوید.

شرط توقف ساده است: اگر در هر حساب اختلاف مانده‌ای بدون توضیح، ردیف منبعی حل‌نشده، مبلغ یا ارزی نامطمئن، یا مورد تکراری یا انتقالی مبهم وجود دارد، توقف کنید. تراکنش ترازکننده اضافه نکنید. پیش‌نویس را نگه دارید و همان مغایرت مشخص را با گردش‌کار تطبیق بودجه بررسی کنید.

بدانید داده‌های صورت‌حساب کجا می‌روند

این یک ردیاب هزینه بدون اتصال به بانک است، اما قرار نیست تضمین کند که صورت‌حساب روی دستگاه خودتان باقی می‌ماند.

کلاینت هوش مصنوعی یا ارائه‌دهندهٔ مدلی که انتخاب می‌کنید ممکن است CSV یا PDF و متن مالی داخل آن را پردازش کند. شرایط آن ارائه‌دهنده برای مدیریت داده‌ها را بررسی کنید و فقط به فایل‌های لازم برای این کار دسترسی بدهید. در گردش‌کار توضیح‌داده‌شده، ایجنت درخواست‌های SQL و عملیات نوشتن ساخت‌یافته‌ای را که تأیید کرده‌اید به ردیاب می‌فرستد و در پاسخ ردیف‌های ساخت‌یافتهٔ انتخاب‌شده را دریافت می‌کند. فایل اصلی صورت‌حساب در ردیاب بارگذاری نمی‌شود.

اگر Expense Budget Tracker را روی سرور خودتان میزبانی کنید، به این معنا نیست که ایجنت هوش مصنوعی، ابزار OCR یا ارائه‌دهندهٔ مدل هم خودمیزبان شده‌اند. آن‌ها سیستم‌هایی جدا با مرزهای دادهٔ جداگانه‌اند. اگر پرهیز از دسترسی دائمی به بانک اولویت شماست، ببینید یک اپ بودجه‌بندی چطور می‌تواند بدون اتصال به بانک کار کند و هر بخش از گردش‌کار را بر همین اساس انتخاب کنید.

پرامپتی که می‌توانید دوباره استفاده کنید

صورت‌حساب نهایی بانک یا کارت را که در [file path or attachment] قرار دارد به Expense
Budget Tracker وارد کن. این صورت‌حساب مربوط به فضای کاری [name] و حساب [name] است و
[dates] را پوشش می‌دهد.

هنوز چیزی ننویس. فایل اصلی را بدون تغییر نگه دار. مشخص کن که فایل CSV ساخت‌یافته،
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 اجرا کن. همان ردیف‌های دقیق را دوباره واکشی و با
پیش‌نمایش تأییدشده مقایسه کن. هر حساب تحت‌تأثیر را با ماندهٔ پایان دورهٔ صورت‌حساب
خودش یا یک نقطهٔ کنترل دقیق و قابل‌اعتماد برای مانده تطبیق بده. اگر چیزی بدون توضیح
ماند، بدون افزودن ردیف ترازکننده توقف کن.

نتیجه ملموس است: سند اصلی، تصمیمی برای هر ردیف منبع، تغییری تأییدشده در دفتر کل و مانده‌هایی که می‌توانید توضیحشان دهید.