סורק קבלות מבוסס AI למעקב הוצאות: תהליך עבודה עם Claude ו-Codex

על קבלה מבית קפה מופיע $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/, פועל לפי תגובת הגילוי, משלים את ההצטרפות באמצעות קוד בדוא"ל ושומר את ה-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
תאריך ושעה	31 באוגוסט 2026, 12:17 בצהריים
סכום ביניים של האוכל	$24.00
הנחה	-$2.00
מס	$1.82
טיפ	$4.00
סכום סופי	$27.82
רמז לאמצעי התשלום	Visa שמסתיים ב-4242

החשבון מסתדר: $24.00 - $2.00 + $1.82 + $4.00 = $27.82. הבדיקה הזאת מועילה, אבל היא אינה מוכיחה מהו חשבון היעד או מהי הקטגוריה. הסוכן עדיין זקוק לספר החשבונות.

1. אשרו את היעד לפני שמפרשים את התמונה

בקשו מהסוכן לזהות ולהציג:

• את פרטי החשבון המחובר
• את השם והמזהה המדויקים של סביבת העבודה
• את חשבון היעד בספר החשבונות ואת המטבע שלו
• את תאריך הקבלה ואת אזור הזמן
• את מטבע הקבלה

בדוגמה הזאת נניח שהמשתמש מאשר את סביבת העבודה Personal עם המזהה 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 לפי השעה המקומית	ברור; המשתמש אישר את אזור הזמן של ניו יורק
מטבע	USD	הסימן $ בתוספת המיקום שאושר; המשתמש אישר את מטבע החשבון
סכום ביניים	24.00	ברור
הנחה	-2.00	ברור
מס	1.82	ברור
טיפ	4.00	ברור
סך הכול שולם	27.82	ברור והחישוב מסתדר
אמצעי תשלום	Visa שמסתיים ב-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. בדקו רשומות חופפות והציגו מועמדות לכפילות, לא הכרעות

לפני ניסוח פקודת הוספה, הריצו שאילתה על החשבון שאושר סביב תאריך הקבלה. עבור הקבלה לדוגמה, בדיקה מצומצמת של כפילויות יכולה להיראות כך:

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 היא ראיה חזקה שכדאי לבדוק, לא הרשאה למחוק או לדרוס דבר.

גם רשומה סמוכה עם אותו סכום ובית עסק דומה היא רק מועמדת לכפילות. שתי רכישות אמיתיות בבית קפה יכולות להיות באותו סכום, וחיוב שמופיע כעת בהמתנה עשוי להיקלט בהמשך בשם אחר של בית העסק או עם חותמת זמן אחרת.

אם כבר קיימת רשומה שסביר שהיא תואמת, התצוגה המקדימה צריכה להציג אותה לצד הנתונים שחולצו מהקבלה ולא להציע הוספה עד שהמשתמש יכריע אם מדובר באותה עסקה.

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'
)

זאת עדיין רק תצוגה מקדימה. הסוכן צריך לציין את ההשפעה הצפויה — שורה חדשה אחת בספר החשבונות בסביבת העבודה שאושרה — ולהמתין לאישור מפורש כמו "אני מאשר את פעולת הכתיבה המדויקת הזאת". תיקון של ערך כלשהו, לרבות סביבת העבודה, החשבון, הסכום, הקטגוריה או ההערה, מבטל את התצוגה המקדימה הקודמת ודורש תצוגה חדשה.

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. בצעו התאמה כשהחיוב בכרטיס נקלט בחשבון

הקבלה מתעדת את מה שקרה בקופה. החיוב שנקלט בחשבון הכרטיס מאשר מה חויב בפועל. כשהחיוב מופיע בהמשך בייצוא של כרטיס האשראי, הריצו שאילתה לפי אותו חשבון, סכום, חלון תאריכים, רמזים על בית העסק וכל מזהה מקור יציב. אם הראיות מצביעות על השורה שנרשמה מהקבלה, החריגו את שורת דף החשבון מהייבוא במקום ליצור רשומה שנייה בספר החשבונות.

אם הסכום שנקלט שונה, אל תיצרו עסקת איזון. בדקו אם סכום הקבלה נקרא באופן שגוי, אם הטיפ השתנה, אם חיוב הרשאה זמני הפך לחיוב סופי או אם הכרטיס המיר עסקה במטבע זר. הכינו תיקון גלוי אחד ובקשו אישור נפרד.

לייבוא בכמות גדולה יותר, המדריך לייבוא דפי חשבון בנק מסביר על תקופות חופפות ועל טיפול בהעברות. המדריך להתאמת התקציב מסביר איך להשוות את הפעילות שנקלטה בחשבון ליתרה שידוע שהיא נכונה.

איפה קריאת קבלות נעשית קשה

תמונות של קבלות הן קלט מבולגן. סורק קבלות מבוסס AI שפועל בזהירות עם Claude או עם Codex צריך להציף את המקרים האלה, לא להחליק מעליהם.

מקרה קשה	טיפול בטוח
תמונה מטושטשת, חשוכה, מקופלת או חתוכה	סמנו שדות שאינם קריאים, בקשו תמונה חדשה או ערך ידני, ואל תכתבו כל עוד הסכום הכולל, התאריך או המטבע אינם ודאיים.
סכום ביניים לעומת סכום כולל	חשבו מחדש את הרכיבים הגלויים והשתמשו בסכום הסופי ששולם בפועל. בדקו אם המס כלול או נוסף, ואם דמי שירות כבר נכללים בסכום הכולל.
טיפים	הבחינו בין טיפים מוצעים שהודפסו, טיפים שנכתבו ביד, סכומי הרשאה בכרטיס והסכום הסופי. השוו בהמשך לסכום שנקלט בחשבון הכרטיס.
הנחות וקופונים	שמרו את הסכום הסופי ששולם. בפיצול לקטגוריות, הציגו כיצד חולקה ההנחה במקום לשייך אותה בלי לומר דבר.
החזרות והחזרים כספיים	התייחסו לקבלת החזרה כראיה לזיכוי שבהמתנה או לזיכוי שהושלם, ולא כהכנסה רגילה. רשמו זיכוי כרשומה מובנית משלו בחשבון המקבל רק כשהסטטוס והסכום ברורים, ואז התאימו אותו כשהוא נקלט בחשבון.
קבלה שמפוצלת לקטגוריות	השתמשו באותו event_id לכל השורות הקשורות; הציגו את הסכום והסימן של כל קטגוריה, את כלל החלוקה, את החלטת העיגול ואת הסכום הכולל. השורות חייבות להסתכם בסכום הסופי ששולם.
מזומן לעומת כרטיס	השתמשו בחשבון שממנו בוצע התשלום בפועל. לוגו של בית העסק או ארנק בתמונה אינם הוכחה לאמצעי התשלום; שאלו אם שורת אמצעי התשלום חסרה.
מטבע זר	השאירו את מטבע הקבלה מפורש. אם חשבון הכרטיס משתמש במטבע אחר, אל תמציאו שער חליפין או סכום סליקה; המתינו לחיוב שייקלט בחשבון או קבלו סכום מדויק שאושר.
מועמדות לכפילות	השוו את התאריך, הסכום והסימן שלו, החשבון, המטבע, בית העסק וכל מזהה מקור יציב. הציגו את הרשומות להחלטה במקום לדלג עליהן או להוסיף אותן בלי לומר דבר.

אותה זהירות חלה גם על סיווגי מס. קבלה יכולה לסייע בתיעוד, אבל המודל לא צריך להכריז שכל רכישה היא הוצאה עסקית מוכרת לצורכי מס או לקבל החלטות משפטיות או החלטות מס לפי שם בית העסק. שמרו במערכת המסמכים שלכם כל מסמך שנדרש כהוכחה לצורכי מס או החזר הוצאות, ופנו לייעוץ מוסמך בשאלות שתלויות בנסיבות שלכם.

הנחיה לשימוש חוזר עם Claude או Codex

הדביקו את ההנחיה הזאת לאחר חיבור הסוכן, ואז החליפו את הערכים שבסוגריים המרובעים. כשעוד לומדים את התהליך, עדיף לעבוד איתה על קבלה אחת בכל פעם.

השתמש בתמונת הקבלה שנמצאת ב-[נתיב קובץ מדויק או קובץ מצורף] וב-Expense Budget Tracker.
עבור ה-API הישיר, התחל מ-https://api.expense-budget-tracker.com/v1/ ופעל לפי
תגובת הגילוי. השתמש ב-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	הסוכן שולח את הקריאות הדרושות לסביבת העבודה ולסכימה, שאילתות בספר החשבונות ופעולות כתיבה מובְנות שאושרו. לא ה-Agent API ולא מחבר ה-MCP זקוקים לתמונת הקבלה.
האחסון של Expense Budget Tracker	בתהליך הזה, מנהל ההוצאות שומר נתונים פיננסיים מובְנים שאושרו, כגון סכום, מטבע, חשבון, קטגוריה, צד נגדי והערה. הוא אינו שומר את תמונת הקבלה.
ארכיון הקבלות שלכם	אם אתם זקוקים לתמונה המקורית לצורך החזרה, אחריות, החזר הוצאות או תיעוד, אתם שומרים אותה במיקום נפרד לבחירתכם.

התהליך יכול להתאים אם אתם רוצים אפליקציית תקציב ללא חיבור לבנק: תהליך הקבלות אינו דורש סנכרון בנקאי קבוע, וכל שינוי מוצע בספר החשבונות נשאר גלוי. עדיין עליכם לבחור ספק AI, להעניק גישה לקובץ ולשלוח פעולות קריאה וכתיבה פיננסיות נבחרות דרך החיבור למנהל ההוצאות.

האם זה סוג סריקת הקבלות שמתאים לכם?

אם מבחינתכם "אפליקציית תקציב עם סריקת קבלות" היא מסך צילום מובנה בטלפון ששומר את הקבלות כקבצים מצורפים, בחרו במוצר שנועד למשימה הזאת. השתמשו בתהליך הזה אם אתם רוצים לסרוק קבלות עם AI ובו בזמן לשמור כל כתיבה בספר החשבונות גלויה ונפרדת מהתמונה המקורית.

השתמשו בתהליך הזה אם אתם רוצים:

• לתעד קבלות בלי לחבר חשבון בנק
• ש-Claude או Codex יטפלו בפענוח התמונה ובבדיקת ספר החשבונות
• שהחשבונות והקטגוריות הקיימים ינחו את יצירת הרשומה
• תצוגה מקדימה מדויקת לפני כל כתיבה
• מועמדות לכפילות במקום הנחות שקטות
• רשומה מובנית ומאומתת בספר החשבונות, שאפשר להתאים בהמשך

Expense Budget Tracker אינו מנסה להחליף ארכיון קבלות בר-חיפוש.

התחילו בקבלה ברורה אחת, בחשבון אחד שאושר ובקטגוריה מוכרת אחת. בדקו את החישוב, אשרו רשומה מדויקת אחת, שלפו אותה מחדש והתאימו אותה כשהחיוב נקלט בחשבון. התהליך הקצר הזה משאיר נתיב ביקורת שתוכלו להבין גם בהמשך.