בדיקת חוקיות חשבון תופסת שגיאת הקלדה בלבד, ולכל בנק נוסחה משלו שמס"ב מפרסמת. איפה תשלום באמת נדחה, מה בודק שירות אדיב, ואיך בונים שלב אימות שמקטין דחיות.
עיקרי הדברים
- ספרת ביקורת בודקת מבנה, לא בעלות. מספר חוקי לחלוטין יכול להוביל כסף לאדם אחר.
- הנוסחה תלוית בנק. מס"ב מפרסמת את טבלאות חוקיות החשבון כחלק ממפרטי בניית הקבצים, ולא כאלגוריתם אחיד.
- מי שמעתיק נוסחה מפורום או מקוד ישן מקבל בנק אחד נכון וכמה בנקים שנופלים בשקט.
- שירות אדיב של מס"ב מנתב בקשה לבנק ומחזיר האם החשבון קיים, פעיל, ותואם למזהה הלקוח - ת"ז או ח"פ.
- רוב הדחיות שמגיעות ימים אחרי השליחה אינן שגיאת מבנה אלא חשבון סגור, מוגבל או לא תואם מוטב.
בדיקת חוקיות חשבון היא חישוב אריתמטי על הצירוף בנק-סניף-חשבון, והיא תופסת שגיאת הקלדה בלבד. היא איננה מוכיחה שהחשבון קיים, שהוא פעיל או שהוא שייך לספק. מס"ב מפרסמת נוסחאות חוקיות נפרדות לכל בנק, ולכן אין נוסחה אחת שמתאימה לכל מספרי החשבון בישראל.
מה בדיקת ספרת הביקורת באמת מוכיחה?
בדיקת חוקיות מקבלת שלושה שדות - קוד בנק, קוד סניף ומספר חשבון - ומריצה עליהם חישוב שהבנק הגדיר למרחב המספרים שלו. אם התוצאה לא מתיישבת, אחד משלושת השדות הוקלד לא נכון. זה כל ההיקף. הבדיקה עובדת מול הצורה שהבנק בחר למספריו, ולא מול רשומת החשבון שמאחוריהם.
שלוש שאלות שונות לגמרי מתמזגות אצל רוב הצוותים לשאלה אחת:
- האם המספר בנוי נכון? זו בדיקת החוקיות. היא רצה מקומית, בלי קריאת רשת ובלי עלות.
- האם החשבון קיים ופעיל? רק הבנק יודע, ורק דרך שירות ייעודי.
- האם החשבון שייך למי שאנחנו חושבים? זו התאמה בין מזהה לקוח לבעל החשבון, ואי אפשר להסיק אותה מהספרות.
למה אין נוסחה אחת לכל הבנקים בישראל?
מפני שכל בנק בנה את מרחב מספרי החשבון שלו בנפרד, הרבה לפני שהייתה תקינה מרכזית. אורך מספר החשבון, אילו רכיבים נכנסים לחישוב, והאם קוד הסניף משתתף בו - כל אלה נקבעים ברמת הבנק. מס"ב מרכזת את הכללים האלה ומפרסמת אותם בחומרי בניית הקבצים, לצד טבלאות העברית ושלבי חישוב ה-Hash.
המסקנה המעשית: מימוש נכון הוא טבלת חיפוש לפי קוד בנק, לא פונקציה אחת. אם הקוד שלכם מאמת את כל הבנקים באותה דרך, סביר מאוד שהוא מיישם נוסחה של בנק אחד על כולם.
שלוש שכבות של דחייה, ומתי מגלים כל אחת
| השכבה | מה נבדק | מי מחזיר את השגיאה | מתי מגלים |
|---|---|---|---|
| מבנה | חוקיות בנק-סניף-חשבון | הקוד שלכם או מודול בניית הקובץ | מיד, לפני שליחה |
| קובץ | שדות חובה, אורכים, סכומי בקרה | מס"ב בקליטת הקובץ | תוך שעות |
| חשבון | קיים, פעיל, לא מוגבל | הבנק המקבל | ימים, בקובץ ההחזרות |
| התאמה | מזהה הלקוח מול בעל החשבון | הבנק, דרך אדיב | לפני התשלום, אם ביקשתם |
השורה שעולה כסף היא השלישית. תשלום שנדחה שבוע אחרי השליחה כמעט אף פעם אינו כשל אריתמטי. זהו חשבון שנסגר, הוגבל, או הוחלף אצל הספק בלי שמישהו עדכן את כרטיס הספק.
מה בודק שירות אדיב שהמספר עצמו לא יכול
אדיב הוא שירות אימות דיגיטלי בנקאי של מס"ב. מגישים קובץ עם פרטי החשבונות ומזהה הלקוח, מס"ב מנתבת כל רשומה לבנק הרלוונטי, והבנק משיב האם החשבון קיים, האם הוא פעיל, והאם המזהה תואם לבעל החשבון. התשובות חוזרות כקובץ תגובה מרוכז, בעיבוד אצווה.
זה הבדל בתהליך העבודה ולא רק בטכנולוגיה. בדיקת חוקיות היא סינכרונית ומיידית, ואימות מול הבנק הוא מחזור אצווה שצריך לתכנן סביבו זמנים. מי שמנסה לאמת ספק חדש בזמן אמת בתוך טופס אינטרנטי יגלה שהמודל פשוט לא מתאים.
איך בונים שלב אימות שמקטין דחיות
- הפרידו בין קליטת פרטי הבנק לבין התשלום. פרטים חדשים נכנסים למצב "ממתין לאימות" ולא ישר למחזור התשלומים הקרוב.
- הריצו את בדיקת החוקיות לפי קוד בנק בזמן ההקלדה, והפנו את ההודעה לשדה שנפל.
- שלחו כל ספק חדש, וכל שינוי בפרטי בנק, לאימות מול הבנק לפני התשלום הראשון.
- שמרו לכל רשומה מתי אומתה, מול מה, ומה חזר. בלי חותמת הזמן הזו אין דרך לדעת אם התשלום נשען על מידע ישן.
- קראו את קובץ ההחזרות אוטומטית והקפיאו את הספק שנדחה, במקום לשלוח את אותה רשומה שוב בחודש הבא.
מה משתבש בפועל
- אפסים מובילים שאבדו בגיליון. מספר חשבון שעבר דרך אקסל מאבד את האפס שבתחילתו, והחישוב נופל או, גרוע מכך, מצליח על מספר אחר.
- נוסחה של בנק אחד על כל הבנקים. זה נראה עובד כי רוב הספקים מתנהלים באותם שני בנקים.
- סניף שהתמזג. בנקים ממזגים סניפים, וקוד הסניף הישן מפסיק להיות תקף גם כשמספר החשבון לא השתנה.
- שינוי פרטי בנק שהגיע במייל. זהו וקטור ההונאה המרכזי בתשלומי ספקים, ושום בדיקה אריתמטית לא נוגעת בו.
- אימות חד-פעמי. ספק שאומת ב-2022 אינו ספק מאומת ב-2026.
- דחייה שנבלעת. קובץ ההחזרות מגיע, איש אינו קורא אותו, ואותה רשומה נדחית שוב מדי חודש.
מה קורה כשספק מחליף בנק באמצע מחזור תשלומים
זהו התרחיש שמייצר את הדחיות היקרות ביותר, מפני שכל שלוש השכבות עוברות בהצלחה והכסף פשוט חוזר. הספק פותח חשבון חדש, שולח את הפרטים, מישהו מעדכן את הכרטיס, והקובץ של החודש כבר נבנה ונשלח עם הפרטים הישנים.
הטיפול בו אינו טכני בעיקרו אלא סדר פעולות:
- קבעו נקודת הקפאה: אחרי בניית הקובץ ולפני שליחתו, שינוי פרטי בנק אינו נכנס למחזור הנוכחי אלא לזה שאחריו.
- סמנו כל ספק ששינה פרטים ב-30 הימים האחרונים, והוציאו אותו לרשימת בדיקה ידנית לפני השליחה.
- אשרו את השינוי בערוץ שני, בשיחה יזומה למספר שכבר קיים בכרטיס הספק, ולא למספר שהופיע במייל.
- שמרו את הפרטים הקודמים ולא תדרסו אותם. כשההחזרה תגיע, תצטרכו לדעת לאיזה חשבון בדיוק נשלח התשלום.
- הריצו אימות מול הבנק על החשבון החדש לפני התשלום הראשון אליו, גם אם הספק ותיק.
שלושה פריטים מסירים את רוב העבודה החוזרת עוד לפני ששינוי אחד נכנס למסלול התשלומים:
- המפרט העדכני של מס"ב לסוג הקובץ שאתם בונים, כולל טבלאות חוקיות החשבון לכל בנק.
- מקור אמת אחד לפרטי הבנק של הספק, עם היסטוריית שינויים ומאשר לכל שינוי.
- תהליך קבוע שקורא את קובץ ההחזרות ומזרים דחיות בחזרה לכרטיס הספק.
זה תיאור טכני של מנגנון בדיקה, ולא ייעוץ פיננסי או משפטי. הנוסחאות והדרישות המחייבות נלקחות מהמפרט הרשמי של מס"ב ומהבנק.
קשור: שגיאות בקובץ תשלומים למס"ב, קובץ החזרות ועדכון חוב לקוח, מאישור חשבונית ספק ועד קובץ מס"ב.
מקורות
שאלות נפוצות
האם ספרת ביקורת תקינה מבטיחה שהכסף יגיע לספק הנכון?
לא. הבדיקה מאשרת שהצירוף בנק-סניף-חשבון בנוי לפי כללי אותו בנק, ולא יותר מזה. מספר חשבון של אדם אחר יכול להיות חוקי לחלוטין. התאמה בין החשבון לבעליו נבדקת רק מול הבנק, למשל דרך שירות אדיב של מס"ב.
איפה משיגים את הנוסחה לכל בנק?
מס"ב מפרסמת את כללי חוקיות החשבון יחד עם מפרטי בניית הקבצים, באזור המפרטים באתר שלה. זהו המקור שצריך לעבוד מולו. נוסחאות שמסתובבות בפורומים ובספריות ישנות מכסות לרוב בנק אחד או שניים ומחזירות תשובה שגויה על השאר.
למה תשלום נדחה שבוע אחרי ששלחנו את הקובץ?
מפני שדחייה כזו מגיעה כמעט תמיד מהבנק המקבל ולא ממס"ב: חשבון שנסגר, חשבון מוגבל, או חשבון שאינו מתאים למוטב. שכבת המבנה עברה בהצלחה. הדחייה מגיעה בקובץ ההחזרות, ודרוש תהליך שקורא אותו ומקפיא את הספק.
כל כמה זמן צריך לאמת מחדש פרטי בנק של ספק?
אין תקופה טכנית מחייבת, אבל האירועים שמחייבים אימות מחדש ברורים: כל שינוי בפרטי הבנק, וכל דחייה שחוזרת בקובץ ההחזרות. תאריך האימות האחרון צריך להיות שדה בכרטיס הספק, כדי שאפשר יהיה לסנן לפיו לפני מחזור תשלומים.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.