איך לייבא דפי חשבון בנק למנהל הוצאות

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

הדרך הבטוחה לייבא דפי חשבון בנק למנהל הוצאות היא לשמור את מסמך המקור כפי שהתקבל מהבנק, לתת לסוכן 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/

פעלו לפי תגובת הגילוי, השלימו את תהליך האימות באמצעות קוד בדוא"ל ושמרו את מפתח ה-ApiKey לטווח ארוך שהוחזר מחוץ לזיכרון הצ'אט. בקשות מאומתות משתמשות ב-Authorization: ApiKey <key>. המדריך להגדרת סוכן מכסה את כל רצף ההגדרה הראשוני.

לפני בניית SQL כלשהו, על הסוכן:

1. לאמת את החשבון שאליו התחברתם ואת סביבת העבודה המדויקת.
2. לבחור את סביבת העבודה הרצויה או לשלוח את המזהה שלה עם הבקשה.
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 או ספק המודל. אלה מערכות נפרדות, ולכל אחת גבולות נתונים משלה. אם העדיפות היא להימנע מגישה קבועה לבנק, קראו כיצד אפליקציית תקציב יכולה לעבוד בלי קישור לבנק ובחרו כל חלק בתהליך בהתאם.

פרומפט שאפשר להשתמש בו שוב

ייבא אל Expense Budget Tracker את דף החשבון של הבנק או כרטיס האשראי לתקופה
שנסגרה, שנמצא ב-[file path or attachment]. הפעולה מיועדת לסביבת העבודה [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. שלוף שוב את השורות המדויקות והשווה אותן לתצוגה
המקדימה שאושרה. בצע התאמה חשבונאית לכל חשבון שהושפע מול יתרת הסגירה בדף
החשבון שלו או מול נקודת בדיקת יתרה מהימנה ומדויקת. עצור בלי להוסיף שורת איזון
אם משהו נותר לא מוסבר.

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