קובץ מס"ב לבנק 2026 — המדריך המלא (עם דוגמאות)

עודכן לאחרונה: 6 ביולי 2026

אם ניסיתם פעם להעלות "קובץ מס״ב" לפורטל של בנק ישראלי וקיבלתם דחייה בלי הסבר ברור, אתם לא לבד. הפורמט מוגדר בעברית של מסמכי טכניים ישנים, מבוסס על שדות ברוחב-בייטים מדויק, ומשתמש בקידוד עברית שכבר לא נפוץ במחשבים מודרניים. במדריך הזה נפתח את הקובץ מבפנים: איזה בייט יושב באיזה מיקום, למה הבנקים דורשים CP-862 ולא UTF-8, למה חתימת SHA-512 חייבת להתבצע בסדר של salt-first, ואיך Fullness Invoice מייצרת את הקובץ אוטומטית בלי שתצטרכו לפתוח עורך בייטים.

מה זה קובץ מס"ב ומתי צריך אותו

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

יש שני סוגי קבצים מרכזיים:

• חיובים (Debits / Collections) — הקובץ שאתם, כמוסד גובה, שולחים כדי למשוך כסף מלקוחות. קוד תנועה ברירת-מחדל: 504. דורש שהלקוח חתם מראש על הרשאת חיוב בבנק שלו.
• זיכויים / תשלומים (Credits / Payments) — הקובץ שדרכו מעבירים כספים החוצה. השימוש הנפוץ ביותר: תשלום משכורות ל-20 עובדים בבת אחת ב-1 לחודש. קוד תנועה ברירת-מחדל: 006.

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

מתי עסק שוקל לעבור למס"ב? התשובה הפרקטית: כשמספר החיובים החודשיים עובר את סף ה-30-50. עד שם, לחיצה על "העברה בנקאית" ידנית עדיין ריאלית. מעבר לזה, הזמן שלוקח לפתוח 200 הוראות תשלום שקול לחצי יום עבודה בחודש — ומס"ב חוסך אותו לגמרי. גם עמלת הבנק על קובץ מס"ב היא קבועה (בין ₪30 ל-₪120 לקובץ בבנקים הגדולים, לפי הסכם), בעוד שחיוב יחיד הוא ~₪1 עד ₪4 להוראה.

מבנה K/1/5 של 128 בייט — הסבר שדה-אחר-שדה

הקובץ הוא טקסט פשוט (ASCII + עברית בקידוד CP-862) עם רשומות ברוחב 128 בייט בדיוק כל אחת, מסופרות ב-CRLF (\r\n). Fullness Invoice מוודאת ברמת runtime שכל רשומה בדיוק 128 בייט — אם חסר בייט אחד, המערכת זורקת RuntimeException לפני שהקובץ בכלל נשמר.

יש ארבעה סוגי רשומות:

• K — Kotertext, כותרת הקובץ. מופיעה פעם אחת בתחילת הקובץ. מכילה מספר מוסד, שם המוסד, תאריך יצירה, ותאריך ערך.
• 1 — רשומת פירוט. אחת לכל חיוב או זיכוי. זו הרשומה שמכילה את פרטי הבנק/סניף/חשבון של הלקוח והסכום.
• 5 — רשומת סיכום. אחת בסוף. סוכמת את סך כל הסכומים ומספר הרשומות.
• מסיים — רשומת "9-ים בלבד" (128 תווי 9) שמסמנת סוף קובץ פיזי.

רשומת כותרת (K)

הנה מפת השדות המדויקת, במיקומים מבוססי-1 (offset מתחיל ב-1):

מיקום   רוחב   שדה                    דוגמה
1       1      קוד רשומה              K
2       2      סמל קבוע               01
4       3      מזהה קובץ              KOT
7       3      קוד יעד (מס"ב)         000
10      2      מטבע (00 = שקל)        00
12      6      תאריך יצירה (YYMMDD)   260706
18      1      גרסה                   1
19      3      סידורי הפעלה           001
22      6      תאריך ערך (YYMMDD)     260710
28      8      מספר מוסד (מוסד גובה)  00012345
36      4      בנק/סניף מוסד          10800
40      30     שם מוסד (עברית, RTL)   ...ץ"נלופ תרבח...
70-127  58     Filler (רווחים)
128     1      סיום שורה              רווח

שני פרטים חשובים שצריך להכיר:

1. תאריך = YYMMDD, לא YYYYMMDD. 6 ספרות בלבד. Fullness Invoice מקבלת קלט בפורמט Y-m-d או YYYYMMDD ומסלקת את המקפים ואת אלפי-השנה אוטומטית — אבל אם אתם בונים קובץ ידנית ב-Excel, זכרו: 6 ספרות, לא 8.

2. שם המוסד ב-K מיושר לימין (encodeRight). ברוב שדות הטקסט השם מיושר לשמאל ("padded on the right"). בכותרת דווקא מיושר לימין, כדי לתמוך בקריאה עברית מסורתית של מדפסות בנק ישנות.

רשומת פירוט (1)

זו הרשומה שיש בקובץ הכי הרבה. כל שורה = חיוב או זיכוי אחד.

מיקום   רוחב   שדה                           דוגמה
1       1      קוד רשומה                     1
2       8      מספר מוסד גובה                00012345
10      2      Filler                        (רווחים)
12      1      קוד סוג עסקה                  (0/1)
13      4      Filler                        (רווחים)
17      2      בנק היעד                      10
19      3      סניף היעד                     800
22      1      סוג חשבון                     (0)
23      3      Filler                        (רווחים)
26      9      מספר חשבון                    000123456
35      9      מספר זיהוי לקוח               (ת.ז./ח.פ.)
44      1      Filler                        (רווח)
45      1      דגל דמוי-הרשאה                (0)
46      16     שם הלקוח (עברית, LTR)         עלמה כהן
62      13     סכום באגורות                  0000000485000
75      1      Filler                        (רווח)
76      20     אסמכתא (טקסט חופשי)           INV-2026-07-4821
96      9      אסמכתא נוספת                  (רווחים)
105     3      קוד תנועה (חיוב=504)          504
108-127 20     Filler                        (רווחים)
128     1      סיום שורה                     רווח

שימו לב במיוחד לשלושה מיקומים:

• סכום @62/13 באגורות. חשבונית של ₪4,850.00 מיוצגת כ-0000000485000 (485,000 אגורות, 13 ספרות עם ריפוד אפסים משמאל). Fullness Invoice זורקת חריגה במקרה של Overflow — היא לא חותכת ספרות בשקט, כי חיתוך שקט היה שובר את סכום הבקרה מול רשומת ה-5.
• קוד תנועה @105/3. עבור חיובים (משיכת כסף מלקוח) — 504 ברירת מחדל. עבור זיכויים (העברת משכורות) — 006. הקודים ניתנים לתצורה תחת config('fullness_invoice.masav.movement_types.*'). חלק מהמוסדות מקבלים מהבנק שלהם קוד תנועה ייעודי (למשל 911 לגבייה עסקית — יש לבדוק מול הבנק לפני שליחה ראשונה).
• שם לקוח @46/16 בעברית. 16 בייטים בדיוק, בקידוד CP-862, אחרי היפוך כל-מחרוזת. על הקידוד וההיפוך נדבר בסעיף הבא.

רשומת סיכום (5)

רשומת ה-5 אוגרת את סך הסכומים ומספר רשומות הפירוט. שימו לב לפרט טכני שסבל מבאג היסטורי בכל ספריות המס"ב הישראליות: מיקום השדות ברשומת ה-5 שונה בין קובץ חיובים לקובץ תשלומים.

• בקובץ חיובים (504): filler @22/15 → סך-הכל @37/15 → filler @52/7 → מספר רשומות @59/7.
• בקובץ תשלומים (006): סך-הכל @22/15 → filler @37/15 → מספר רשומות @52/7 → filler @59/7.

קוד המפיק ב-Fullness Invoice מכיל שתי שיטות sum() נפרדות — אחת ב-MasavChargeExporter ואחת ב-MasavPaymentExporter — בכוונה מלאה. אם ראיתם מדריך ישן שמתייחס לזה כאל "אותו מיקום", הוא לא נכון, ותקבלו דחייה מהבנק ברמת האימות.

קידוד CP-862 לעברית וחישוב SHA-512

שתי אבני נגף אמיתיות שהפילו יישומי מס"ב רבים ב-2024-2025.

למה CP-862 ולא UTF-8?

קידוד CP-862 הוא קידוד עברית של IBM PC-DOS משנות ה-80. הוא ממפה כל אות עברית לבייט אחד: א (U+05D0) → 0x80, ב → 0x81, ..., ת (U+05EA) → 0x9A. תווי ASCII (a-z, 0-9, רווח) עוברים בלי שינוי; כל תו יוניקוד אחר מוחלף ב-?.

למה זה עדיין השתמר ב-2026? כי חלק ממערכות הליבה של הבנקים הישראליים הן מיינפריים COBOL שקוראים את הקבצים בקידוד קבוע — והחלפת הקידוד לUTF-8 הייתה שוברת עשרות אלפי לקוחות עסקיים באוטומציה. Fullness Invoice מטפלת בזה דרך MasavHebrewEncoder, שגם עושה היפוך של המחרוזת ברמת הבייטים אחרי הקידוד, כדי שסדר ההדפסה על מדפסת בנק ישן ייראה נכון מימין לשמאל.

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

חתימת SHA-512 בסדר salt-first

לצד הקובץ עצמו, מס"ב דורש חתימת SHA-512 שאתם מציגים באתר הבנק בעת ההעלאה. הבנק מחשב מחדש את החתימה על הקובץ שהעליתם ומשווה — אי-התאמה אפילו בבייט אחד = דחייה מיידית. החתימה עצמה אינה חלק מהקובץ; היא מוצגת ליד ההעלאה.

כאן טמונה המלכודת הכי מסוכנת: סדר הרכיבים ב-hash.

הנוסחה הנכונה, שאומתה מול הדוגמה הרשמית של מס"ב:

hash('sha512', salt . data)

salt = mosad(8 digits) + record_count(7 digits)   // 15 בתים
data = per detail record: substr(1,8) + substr(17,2)
     + substr(19,3) + substr(26,9) + substr(61,13)
     + substr(105,3)

שימו לב: salt קודם, נתונים אחריו. לפחות שתי ספריות מס"ב פתוחות שנבדקו הפכו את הסדר וייצרו חתימות שנדחו על ידי כל הבנקים. אימוץ הסדר של salt לפני data אומת מול הדוגמה הרשמית של מס"ב במסמכי ה-PDF שלה, וגם עבר סקירת קוד יריבותית בפיתוח Fullness Invoice — 27 תיקונים היו נדרשים כדי להגיע לגרסה עובדת.

ה-salt הוא 15 בייטים: 8 ספרות של מספר המוסד + 7 ספרות של מספר הרשומות בקובץ, שניהם עם ריפוד אפסים משמאל. ה-data הוא קונקטנציה של 6 שדות מכל רשומת פירוט: מספר מוסד, בנק, סניף, חשבון, סכום, וקוד תנועה.

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

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

הבעיה: לכל בנק אלגוריתם משלו. אין תקן ISO. הנה הכללים שאומתו מול הדוגמאות של הבנקים ב-MasavAccountValidator:

בנק לאומי (10) ו-פועלים לישראל (34)

שיטת ה"משלים ל-100". גוף החשבון (6 ספרות) מוכפל בווקטור משקלים 7, 6, 5, 4, 3, 2. מספר הסניף (3 ספרות) מוכפל ב-10, 9, 8. סוכמים את הכל, מוסיפים אחד מארבעה קבועים ({330, 340, 180, 128}, ולפעמים +110 אם ספרות 5-6 של החשבון הן 20/23/00), מחשבים 100 - (sum + const) mod 100, ומשווים לשתי ספרות אחרונות של החשבון. חשבון תקין אם לפחות אחד מהקבועים מייצר התאמה.

דוגמה: בנק לאומי (10), סניף 800, חשבון 12345678 — הוולידטור מריץ 4 בדיקות במקביל וקובע תוקף בברירת המחדל הראשונה שמתאימה.

בנק הפועלים (12)

חשבון של 6 ספרות מוכפל ב-1, 2, 3, 4, 5, 6 מימין לשמאל. סניף של 3 ספרות מוכפל ב-7, 8, 9. סוכמים ומחלקים ב-11. השארית חייבת להיות 0, 2, 4, או 6 — אחרת דחייה.

בנק דיסקונט (11) ומרכנתיל (17)

חשבון של 9 ספרות מוכפל ב-1..9 מימין לשמאל. ללא סניף — סניף לא נכנס לחישוב. סוכמים ומחלקים ב-11. השארית חייבת להיות 0, 2, או 4.

מזרחי-טפחות (20)

אותה שיטה כמו הפועלים, אבל אם מספר הסניף הוא בין 401 ל-799, מפחיתים 400 לפני החישוב (סימון לסניפי "מזרחי" לעומת "טפחות" שהתאחדו ב-2004 ונשארה מטענת ספרתית). השארית מתקבלת אם היא 0, 2, או 4.

בנק יהב (04)

אלגוריתם דומה. השארית מתקבלת רק אם היא 0 או 2 (יהב הוא הכי מחמיר).

כל שאר הבנקים

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

קבצי החזרה R/1/6 — קריאה ופעולה על דחיות

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

הפורמט: רשומות של 220 בייט (לא 128!), במבנה של שלושה סוגי רשומות:

• R — כותרת. תאריך עיבוד, מספר מוסד, קוד חבילה יומית.
• 1 — רשומה של דחייה בודדת. מכילה קוד סיבה, טקסט סיבה, אסמכתא, סכום, ותאריך.
• 6 — סיכום. כמה נדחו וסך סכום שנדחה.

מיפוי השדות ברשומת ה-1 של קובץ החזרה:

מיקום   רוחב   שדה                דוגמה
1       1      קוד רשומה          1
18      3      קוד סיבה           006
21      10     טקסט סיבה          NSF
31      20     אסמכתא             INV-2026-07-4821
85      15     סכום באגורות       000000000485000
143     6      תאריך עיבוד        260710
149     2      מס' חבילה יומית    01

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

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

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

ומה עושים עם חיוב שהתקבל אבל אין לו חשבונית פתוחה תואמת (למשל, לקוח שילם על חשבונית עתידית)? Fullness Invoice פותחת רשומה בחשבון "מקדמות לקוחות" (System role: CustomerAdvances, קוד מאזני 2150), ומקזזת אותה אוטומטית מול החשבונית הבאה שתופק ללקוח. אין צורך בהתערבות ידנית.

טעויות נפוצות שהבנק דוחה

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

1. ספרת ביקורת שגויה בחשבון היעד. ~40% מהדחיות ההיסטוריות. מקור: הקלדה ידנית של מספר חשבון של לקוח. פתרון: הוולידטור המקדים ב-Fullness Invoice תופס את זה לפני שהקובץ בכלל נבנה, ומסמן את ההרשאה כ"לא-פעילה" במסך הרשאות החיוב.
2. קוד תנועה לא רשום למוסד. ~25%. חלק מהמוסדות מקבלים מהבנק שלהם קוד תנועה מותאם אישית (למשל 911 במקום ה-504 ברירת המחדל), ואם משתמשים בקוד לא רשום — כל הקובץ נדחה, לא רק שורה אחת. תמיד בדקו מול הבנק בהפעלה ראשונה.
3. סכום מעל התקרה המורשית של הלקוח. ~15%. הלקוח חתם על הרשאת חיוב עם תקרה חודשית של ₪1,500, ואתם מנסים לחייב ₪1,750 בגלל חוב מהחודש הקודם. הבנק דוחה בשקט. פתרון: שדה "תקרה חודשית" בהרשאה + התראה אוטומטית לפני יצירת הקובץ אם סכום החיוב עוקף את התקרה.
4. אסמכתא כפולה (duplicate asmachta). ~10%. אותו מספר אסמכתא נשלח פעמיים באותו יום. המסלקה מכבדת רק את הראשון. פתרון: יצירה של אסמכתאות ייחודיות באוטומציה (למשל {מספר-חשבונית}-{תאריך}) ולא הקלדה ידנית.
5. שדה עברי בקידוד לא נכון (UTF-8 במקום CP-862). ~5%. אם ניסיתם ליצור קובץ ב-Excel או בסקריפט Python בלי לקבוע את הקידוד המפורש, קיבלתם UTF-8 (2 בייטים לאות עברית). המסלקה תראה את זה כג'יבריש ותדחה את כל הקובץ.

איך Fullness Invoice מפיק את הקובץ אוטומטית

המודול הפיננסי של Fullness Invoice מטפל בכל שרשרת מס"ב מקצה לקצה בלי שתצטרכו לפתוח עורך בייטים. הרעיון: כל הלוגיקה הכבדה (בדיקת ספרת ביקורת, קידוד CP-862, מבנה 128 בייט, חתימת SHA-512) עוברת בעצמה, ואתם רק בוחרים "אילו לקוחות" ו"על איזה סכום" והלחצן אחרון הוא "הפק קובץ".

בפועל, כשעסק מתפעל תשלום משכורות ל-30 עובדים ב-1 לחודש:

• קלט: טבלת עובדים עם שם, ח.פ., בנק, סניף, חשבון, וסכום משכורת. Fullness מטענה את זה ממודול השכר אוטומטית.
• ולידציה: על כל שורה, ה-MasavAccountValidator רץ ומחזיר True/False. שורה שנופלת מסומנת ב-UI, ומחכה לתיקון ידני. שאר השורות ממשיכות.
• הפקה: MasavPaymentExporter בונה את הקובץ ב-MasavWriter, שתופר מסביב ל-FixedWidthWriter ומחזק בבדיקת runtime שכל רשומה בדיוק 128 בייט.
• קוד CP-862: MasavHebrewEncoder ממיר את שמות העובדים ומצמצם ל-16 בייט בדיוק (חיתוך אוטומטי אם השם ארוך יותר).
• SHA-512: MasavHashService מייצר את החתימה עם ה-salt-first. החתימה מוצגת ב-UI לצד לחצן ההורדה.
• העלאה: אתם מורידים את הקובץ, נכנסים לאתר הבנק, מעלים, מדביקים את החתימה.
• קובץ החזרה: תוך 2-3 ימי עסקים אתם מעלים חזרה את קובץ ההחזרה למערכת. Fullness מבצעת settlement אוטומטי מול החשבוניות הפתוחות ומעדכנת את הסטטוס של כל חיוב.

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

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