איפה נולד תשלום כפול?
תשלום כפול לקבלן משנה כמעט אף פעם לא מתחיל בכוונה רעה. הוא מתחיל בשלושה ערוצים שלא מדברים: הודעת וואטסאפ («שלם לו על הקומה»), שורת אקסל ישנה, וזיכרון של מנהל («נדמה לי שעדיין לא שילמנו»). בסוף אותה כמות יוצאת פעמיים.
צ׳קליסט לפני שחרור עוזר — ראו בדיקות לפני שחרור תשלום. כאן נבנה תהליך עבודה שמונע את הכפל מלכתחילה.
כלל ברזל: אין שחרור בלי עוגן לסעיף ולכמות שנותרה לתשלום.
למה אקסל + וואטסאפ נכשלים?
- כל קבלן משנה בגיליון נפרד — אין תמונה אחת של «שולם עד כה».
- צילומים בלי קישור לסעיף — אי אפשר לדעת מה כבר כוסה.
- חלקיות מצטברת שלא נשמרת — סבב 2 «מתחיל מאפס».
- שינויים (Change Order) שנכנסים לצ׳אט ולא לחוזה.
זרימה מומלצת: בקשה → ראיה → אימות → אישור
- בקשת תשלום מעוגנת: קבלן המשנה מציין סעיף BOQ/חוזה וכמות מבוקשת — לא סכום באוויר.
- ראיית ביצוע מהשטח: צילום / סיור עם חותמת זמן. מסלול מעשי: Site Walk ו־אישור חשבון קבלן עם AI.
- אימות מול BOQ: כמה אושר עד כה? כמה נותר? האם חורגים מהחוזה?
- אישור או דחייה: מנהל/משרד מחליטים. חריגה עולה לאימות — לא עוברת בשקט.
- רישום חלקיות: מה ששולם נשמר מול הסעיף — כדי שסבב הבא לא ישלם שוב.
תפקיד יומן העבודה
יומן יומי מחבר «מה קרה באתר» ליום התשלום. בלי יומן, קל יותר לטעון ששילמתם על יום שלא בוצע — או לשכוח מה שכן בוצע. מדריך: יומן עבודה יומי באתר.
מדדי בקרה שבועיים למנהל פרויקט
- כמה בקשות תשלום ממתינות בלי ראיית ביצוע?
- כמה סעיפים קרובים ל־100% כמות חוזית?
- האם יש קבלן משנה עם שני ערוצי תשלום פתוחים (אקסל + מערכת)?
- האם Change Orders מאושרים לפני תשלום על תוספת?
תשלום כפול הוא כשל תהליך — לא «חוסר מזל». תהליך אחד + עוגן לסעיף פותרים את רוב המקרים.
שורה תחתונה
מונעים תשלום כפול כשכל שחרור עובר באותה צינורת: סעיף → כמות שנותרה → ראיה → אישור. לקבלנים ראשיים: מסלול קבלן ראשי · התחילו ניסיון חינם.
