איך ייבוא עובד בקסטור

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

מה זה עושה

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

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

זיהוי הקובץ בהעלאה

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

לאומי (גם בנק וגם אשראי)
ישראכרט
מקס
כאל
דיסקונט
יהב

הרשימה הזו לא סופית — קסטור ממשיך להוסיף פורמטים נוספים של בנקים וחברות אשראי בישראל.

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

קובץ שלא מזוהה

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

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

זיהוי כפילויות

כל שורה בקובץ שמיובא נבדקת מול הנתונים שכבר שמורים בחשבון של משק הבית. ההתאמה מבוססת על:

תאריך
סכום
שם העסק
מספר אסמכתא — כשהקובץ כולל אותו

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

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

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

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

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

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

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

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

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

תיקון תאריכי תשלומים

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

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

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

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

שורת סיכום מהבנק מול דוח כרטיס מפורט

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

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

סכום — בטווח של עד ₪1 או 0.5% מהסכום (הגבוה מביניהם)
זמן — בטווח של עד 45 יום, כשמדובר בסכום כרטיס ששמור כבר מקודם במערכת

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

לדוגמהנניח שדוח הבנק כולל שורה אחת על סך ₪3,450 שמתארת את כל החיוב החודשי של כרטיס אשראי מסוים, וקובץ האשראי של אותו כרטיס — שיובא באותו זמן או קודם לכן — כולל עשרות שורות מפורטות שמסתכמות גם הן לסביבות ₪3,450. ההפרש בין הסכומים קטן מ-₪1 ומ-0.5% מהסכום, כך שהתנאי מתקיים, וקסטור מוריד את שורת הסיכום מהבנק. אם דוח הכרטיס המפורט עוד לא הגיע באותו רגע, שורת הסיכום נשארת כהוצאה רגילה — ואם דוח מפורט מגיע מאוחר יותר ומתאים לה, קסטור מזהה את ההתאמה, אבל הסרת השורה הישנה עדיין דורשת אישור, לא קורית מעצמה.

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

שני מנגנונים נפרדים, לא אחד

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

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

מדריך #1 מתוך סדרת "איך קסטור עובד"עודכן לאחרונה: 5.8.2026