התהליך שקורה לפני שנבנה קובץ התשלומים: קליטת החשבונית, התאמה להזמנת רכש ולתעודת משלוח, מדרג הרשאות אישור, והצעת תשלום שהיא מה שההרצה באמת צורכת.
עיקרי הדברים
- שלוש פעולות שונות: מי מכניס את החשבונית, מי מאשר שהסחורה או השירות התקבלו, ומי מאשר להוציא כסף. הפרדה ביניהן היא המנגנון, לא הנוהל.
- ההתאמה המשולשת - חשבונית מול הזמנת רכש מול תעודת משלוח - מייצרת ארבעה סוגי חריגים, וכל אחד הולך לבעלים אחר.
- קובץ מס"ב אינו צורך חשבוניות. הוא צורך הצעת תשלום מאושרת: רשימת שורות שכבר עברו התאמה, אישור ובדיקת פרטי בנק.
- שינוי פרטי בנק של ספק הוא תהליך נפרד לחלוטין מהחשבונית, עם אישור נפרד ועם המתנה מכוונת לפני התשלום הראשון.
- מה שנשבר בפועל אינו הפורמט אלא הזהות: אותה חשבונית שנקלטת פעמיים בשתי דרכים, במייל ובסריקה.
קובץ התשלומים הוא הפלט האחרון בשרשרת, ולא התהליך. לפניו יש שלושה שלבים נפרדים שחייבים להיות בידיים שונות: קליטת החשבונית, התאמתה להזמנת רכש ולתעודת משלוח, ואישור התשלום עצמו. כשאותו אדם מבצע את שלושתם, אין נקודת בקרה - יש רק תיעוד.
שלוש הפעולות שחייבות להיות בידיים שונות
הפרדת תפקידים בתשלומי ספקים היא בדיוק שלוש שאלות שמישהו אחר עונה עליהן:
| הפעולה | מה נבדק | מי מבצע בעסק קטן | מה קורה כשזה מתמזג |
|---|---|---|---|
| קליטה | האם המסמך תקין וזוהה מול ספק קיים | מנהלת משרד | חשבונית כפולה נכנסת ומשולמת פעמיים |
| התאמה | האם הוזמן, האם התקבל, האם המחיר תואם | מי שהזמין | תשלום על סחורה שלא הגיעה |
| אישור תשלום | האם לשלם עכשיו, מאיזה חשבון, לאיזה ספק | מנהל / בעלים | אין בקרה על יעד הכסף |
| הפקת הקובץ | האם הרשימה תואמת את המאושר | הנהלת חשבונות | שורה שנוספה אחרי האישור |
בעסק של שלושה אנשים אי אפשר לפצל לארבעה תפקידים, ולכן הכלל המעשי הוא צר יותר: מי שמזין את פרטי הספק אינו מי שמאשר את התשלום. זו ההפרדה היחידה שאסור לוותר עליה, כי היא היחידה שמונעת שינוי יעד כסף בלי עדים.
מה בעצם בודקים בהתאמה המשולשת?
ההתאמה המשולשת בודקת שלושה מספרים שאמורים להיות זהים ולעיתים קרובות אינם. הנה מקרה: הזמנת רכש PO-2026-0342 ל-500 יחידות במחיר 12.40 ש"ח ליחידה, סך 6,200 ש"ח.
- תעודת משלוח DN-88214: התקבלו 480 יחידות. 20 חסרות.
- חשבונית ספק 2026/4471: 500 יחידות, 6,200 ש"ח.
- הפער: 248 ש"ח ששולמו על סחורה שלא הגיעה, אם החשבונית משולמת כמות שהיא.
ארבעה סוגי חריגים נובעים מהשוואה כזאת, ולכל אחד בעלים שונה:
- חריגת כמות - סופק פחות מהמוזמן. בעלים: מי שקלט את הסחורה במחסן.
- חריגת מחיר - מחיר החשבונית שונה מהמחיר בהזמנה. בעלים: הרכש.
- חשבונית ללא הזמנה - אין הזמנת רכש בכלל. בעלים: מנהל התחום שהזמין בפועל.
- הזמנה ללא חשבונית - התקבלה סחורה ואין חשבונית. בעלים: הנהלת חשבונות, וזו התחייבות פתוחה שצריכה להופיע בדוחות.
חשוב שהסף לחריגה יהיה מוגדר במספרים ולא בתחושה: למשל, פער מחיר עד 1% או עד 50 ש"ח עובר אוטומטית, ומעל זה נעצר. סף כתוב הופך את רוב החשבוניות לזרימה שקטה ומשאיר לאדם רק את מה שבאמת חורג.
מכונת המצבים של חשבונית ספק
received- נקלטה, יש מסמך וספק מזוהה. מעבר ל-matchingאו ל-rejected.matching- בתהליך התאמה מול הזמנה ותעודה. מעבר ל-matchedאו ל-exception.exception- נמצא פער. מעבר ל-matchedאחרי החלטה מתועדת, או ל-rejected.matched- הותאמה. מעבר ל-approved.approved- אושרה לתשלום, עם מאשר ותאריך. מעבר ל-scheduled.scheduled- נכנסה להצעת תשלום עם תאריך ערך. מעבר ל-paid.paid- שולמה. מצב סופי.
הכלל היחיד שמחזיק את כל זה: אי אפשר להגיע ל-scheduled בלי לעבור ב-approved, ואישור ניתן לחשבונית מסוימת בסכום מסוים. אישור גורף ל"כל מה שנשלח לספק הזה" מבטל את המנגנון.
מה קובץ התשלומים באמת צורך
הרצת התשלומים אינה קוראת חשבוניות. היא קוראת הצעת תשלום - אובייקט נפרד שנוצר בזמן ההרצה ומצלם את מה שאושר. השדות שלה:
| שדה | דוגמה |
|---|---|
run_id | PR-2026-09-02 |
value_date | 2026-09-25 |
line_count / total | 37 / 412,880 |
שורה: supplier_id | SUP-0219 |
שורה: invoice_ids | ["2026/4471","2026/4488"] |
שורה: amount | 11,340 |
שורה: bank_ref | 12-345-0000067890 |
שורה: approved_by / approved_at | yossi / 2026-09-22T11:04+03:00 |
שורה: flags | new_bank_details |
לפני הפקת הקובץ מפיקים את ההצעה לאישור, ומסתכלים על שלושה דברים בלבד: שורות עם flags, שורות שסכומן חורג מהממוצע ההיסטורי של אותו ספק, וספקים שלא שולם להם מעולם. אחרי האישור, כל שינוי בהצעה מבטל את האישור ודורש אישור מחדש - אחרת אפשר להוסיף שורה אחרי שהמנהל הסתכל.
מכאן והלאה מתחיל עולם אחר: מבנה הקובץ, כללי הפורמט וסיבות הדחייה של אצווה שלמה מפורטים בשגיאות בקובץ תשלומי ספקים במס"ב. המאמר הזה נעצר בדיוק בנקודה שבה ההצעה מאושרת.
למה שינוי פרטי בנק חייב מסלול נפרד?
שינוי פרטי בנק חייב מסלול נפרד מפני שהוא הפעולה היחידה בתהליך שמפנה את הכסף למקום אחר בלי לשנות שום סכום. חשבונית מזויפת נראית חשודה; שינוי מספר חשבון נראה כמו עדכון פרטים.
- הבקשה לשינוי אינה מתקבלת מהמסמך. חשבונית שמופיע בה חשבון חדש אינה בקשת שינוי.
- האימות נעשה בערוץ יוצא ולא נכנס: מתקשרים למספר שמופיע בכרטיס הספק מלפני הבקשה.
- השינוי נרשם כאירוע עם משתמש, זמן, ערך קודם וערך חדש.
- התשלום הראשון אחרי שינוי מסומן ב-
flagsודורש אישור נוסף. - הודעה על השינוי נשלחת לאיש הקשר הקודם אצל הספק, שהוא מי שיזעק אם לא הוא ביקש.
בדיקות הספק האחרות - אישורים ותקפותם - מתוארות באימות ספקים אוטומטי, והצד של קליטת מסמכים סרוקים בעיבוד חשבוניות ספק בעברית.
מה נשבר בפועל בשלב הקליטה
- קליטה כפולה - אותה חשבונית מגיעה במייל וגם נסרקת. מפתח הייחודיות חייב להיות צירוף של מזהה הספק ומספר החשבונית שלו, לא מספר פנימי רץ.
- מספר חשבונית לא מספרי - ספקים משתמשים ב-
2026/4471או ב-A-118. שדה מספרי יאבד את התו המפריד. - חשבונית ריכוז - מסמך אחד מול שש הזמנות. אם הקישור הוא שדה יחיד, חמש הזמנות יישארו פתוחות לנצח.
- זיכוי ספק - מגיע כמסמך נפרד וצריך להיקשר לחשבונית המקורית לפני שהוא מקוזז בהרצה.
- מטבע - חשבונית במטבע חוץ שנשמרת בשקלים לפי שער היום מייצרת פער קבוע מול התשלום בפועל.
מקורות
שאלות נפוצות
האם צריך הזמנת רכש לכל חשבונית?
לא בהכרח, אבל צריך להחליט מראש לאילו קטגוריות כן. הדפוס הנפוץ הוא לדרוש הזמנה מעל סכום מסוים ולקטגוריות מלאי, ולאפשר אישור מנהל בלבד לחשבוניות שוטפות כמו חשמל או תקשורת. מה שלא עובד הוא לדרוש הזמנה בנוהל ולא לאכוף אותה במערכת.
מה עושים כשהחשבונית מגיעה לפני הסחורה?
היא נקלטת ונשארת ב-`matching` עד שנרשמת קבלה. זה תקין ואף רצוי, כי החשבונית כבר בתוך המערכת ולא בתיבת מייל. מה שאסור הוא לאשר אותה לתשלום בזמן הזה, כי האישור מעיד על קבלה שטרם קרתה.
מי צריך לאשר סכום חריג?
זה נקבע במדרג הרשאות כתוב שמבוסס על סכום ועל קטגוריה, ולא על מי פנוי באותו רגע. הנקודה החשובה יותר היא שהמערכת אוכפת את המדרג, ולא מסתמכת על כך שמישהו יזכור לשלוח למנהל. אישור שניתן במייל ולא נרשם על החשבונית אינו קיים בביקורת.
כמה זמן לוקח להטמיע תהליך כזה?
החלק הטכני קצר יחסית; מה שלוקח זמן הוא הסכמה על מדרג ההרשאות ועל ספי החריגה, וזו החלטה של ההנהלה ולא של המערכת. בפועל, עסקים מתחילים במעקב בלי חסימה, מודדים חודש-חודשיים כמה חריגים נוצרים, ורק אז מפעילים אכיפה.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.