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

שלב ראשון: הנפקת החשבונית

ה-flow שאני מכיר הוא שליחה של "הזדמנות" ממערכת ניהול הלקוחות (CRM, Salesforce במקרה שלנו) אל תוכנת הנהלת החשבונות שתנפיק חשבונית בהסתמך על ההזדמנות (פריוריטי, במקרה שלנו). כשאני אומר שליחה אני מתכוון לכך שלאחר טעינת המידע ישנו "משטח עבודה" בתוכנת הנהלת החשבונות בו כרגע ממתינות חשבוניות בטיוטה לסגירתן ושליחה ללקוח. המידע שצריך להישלח הוא לכל הפחות המידע הבא:

1. פירוט המוצרים – מובן מאליו. מה שכן, תחשבו האם אתם רוצים להעביר רק את המחיר הסופי, כלומר לאחר הנחה, או את הכל (לפני הנחה, הנחה ואחרי הנחה). התשובה לשאלה זו גלומה בהחלטה הרבה יותר אסטרטגית, שהיא היכן אתם מנהלים את המחירים שלכם. ייתכן מאוד שתחליטו לנהל אותם אך ורק ב-CRM ולשלוח לגבייה רק את המחירים הסופיים. אחרת, צריך לדאוג לסנכרון של הכל ולא בטוח שיבוא לכם על זה. אצלנו למשל, בגלל שמודול ניהול ה-Pricelists של Salesforce כל כך טוב, אנחנו מעדיפים להתעסק רק איתו ולשלוח לשאר המערכות את המחירים הסופיים.
2. תאריך החשבונית – ייתכנו מקרים שנרצה להוציא ב-1 לחודש חשבונית עבור חודש קודם, ולכן רצוי שהשדה הזה יועבר כפרמטר, ולא ייקבע אוטומטית לפי מועד שליחת ההזדמנות.
3. יישות להוצאת חשבונית, במידה ואתם עובדים עם כמה יישויות שונות (יש חברות שמעדיפות להפריד את הלקוחות והספקים לפי טריטוריות, למשל ישראל וכל השאר).
4. מספר הלקוח שעליו תצא החשבונית
5. תנאי תשלום – חשוב מאוד שתהיה מדיניות תנאי תשלום מסודרת, ועדיף שהיא תהיה רזה ככל האפשר. למשל, או שוטף 60 או 4/8/12 תשלומים. בכל אופן, הסיבה שאנחנו לא שולחים ישירות להוצאת חשבונית היא כדי למנוע מצב שבו איש מכירות להוט ישלח חשבונית עם תנאי תשלום מפליגים. העובדה שהחשבונית נמצאת כטיוטה ומישהו צריך "לגמור" אותה ידנית היא למעשה מנגנון פיקוח.
6. הערות כלליות שיופיעו על החשבונית – תמיד טוב

יאללה, נקסט.

שלב שני: הנפקת קבלה והתאמת הקבלה מול החשבונית המתאימה

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

מה עושים כשהלקוח לא שילם את כל סכום החשבונית? ראשית, אולי זה בסדר, אולי קיימת פריסה. למשל, נאמר שב-1.1.2015 הנפקנו חשבונית על סך 1,200 ש"ח (כולל מע"מ) שאמורה להיות משולמת ב-4 תשלומים. מערכת הנהלת החשבונות אמורה לדעת לפרוס בצורה אוטומטית את 4 התשלומים על פני השנה הקרובה כך שבמקום 1,200 ש"ח יהיה תחת החשבון 4 תנועות לא מתואמות על סך 300 ש"ח כל אחת, עם תאריך ערך משתנה (למשל, 31/1/2015, 28/2/2015… 30/4/2015). ואז כשהלקוח (שמו ב' בשביל הדוגמה בסעיף הבא) משלם 300 ש"ח אנו נדע להתאים בין קבלה על סך 300 ש"ח לתנועה לא מתואמת שקיימת לנו בספרים על סך 300 ש"ח. ללקוח יישארו עוד 3 תנועות לא מתואמות על סך 300 ש"ח כל אחת שזמנן יגיע בעתיד.

הבעיה היא כשהלקוח לא משלם את כל החשבונית, למשל 50%. נאמר שהנפקנו ב-15.1.2015 חשבונית על סך 300 ש"ח (כולל מע"מ), לתשלום בתשלום אחד, בתנאי תשלום של שוטף 30, והלקוח (שמו ג' בשביל הדוגמה בסעיף הבא) שילם לנו ב-15.3.2015 100 ש"ח על דעת עצמו. נשאלת השאלה מה לעשות. האם לא לבצע התאמה ואז יוותרו לנו שתי פעולות פתוחות (אחת על 300 ש"ח בצד החובה ו-100 ש"ח בצד הזכות), או שמא להשאיר פעולה אחת פתוחה על סך 200 ש"ח (יתרת החוב). בעיקרון, כדי שלא לאבד את היסטוריית התשלומים של הלקוח (יש התסברות גבוהה שהוא יבקש אותה), עדיף לא להשאיר יתרה פתוחה שמורכבת מיתרה על חשבונית שלא שולמה במלואה. זה אמנם מקטין את כמות התנועות הפתוחות, אבל לא מאוד ידידותי למעקב שוטף.

שלב שלישי: הנפקת דוח גיול

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

טבלה 1: בסיס לחישוב דוח גיול, במספרי הדוגמא מהסעיף השני

שם לקוח	מספר חשבון במערכת	תאריך חשבונית	תאריך תשלום	מספר חשבונית	אסמכתא ממערכת ה-CRM	סכום (ש"ח)	ימי פיגור
ב	100002	1.1.2015	28.2.2015	IN20150002	006D000000fgUBb	300	30
ב	100002	1.1.2015	31.3.2015	IN20150002	006D000000fgUBb	300	0
ב	100002	1.1.2015	30.4.2015	IN20150002	006D000000fgUBb	300	0
ג	100003	15.2.2015	28.2.2015	IN20150003	0012000000N2SIl	300	30
ג	100003	15.3.2015	15.3.2015	RC20150005		(100)	15
סה"כ יתרת לקוחות						1,100

לפני שנמשיך לדוח הגיול עצמו, כמה הערות:

• לקוח א' לא מופיע בטבלה מאחר ואין לנו תנועות פתוחות תחתיו. הייתה לו חשבונית שהוא שילם במלואה ונכון ל-31.3.2015 היא כבר אמורה להיות מותאמת. התשלום הראשון של לקוח ב' גם הוא איננו מופיע מאותה סיבה.
• הוספתי את שדה קוד הלקוח כי נחמד שיש אותו לאחזור מהיר במערכת הנהלת החשבונות
• תאריך החשבונית הוא תאריך הרישום של הפעולה מבחינתת רישום ההכנסות ותאריך התשלום הוא התאריך שבו התנועה אמורה להיסגר. לכן, במקרה של חשבוניות, החשבונית נרשמת ביום מסוים והתשלומים "נפרסים" על פני האופק. לעומת זאת, עבור קבלה, תאריך ה"חשבונית" ותאריך ה"תשלום" זהים כי מה שחשוב היא שהיינו רוצים שהקבלה תיסגר כבר ביום הנפקתה. זה אמור לקרות כאשר היא תואמת תנועה פתוחה, כמו במקרה של לקוח א' שאיננו מופיע בטבלה מאחר והחשבונית
• שהופנקה לו נסגרה לו מול קבלה.
• כדי להפוך את הדוגמה ליותר מציאותית הוספתי גם שדה מקשר בין החשבונית שהונפקה במערכת הנהלת החשבונות ל-ID של ההזדמנות התואמת ב-CRM. זה לא חובה, אבל כאשר עובדים בכמה מערכות זה יכול להיות נחמד לקשר בין החשבונית למקור שלה. למשל, לא תמיד לאנשי המכירות תהיה גישה למערכת הנהלת החשבונות, אז נוכל לשלוח להם בקלות את קוד ההזדמנות וכך הם יידעו את פירוט החשבונית וכו'.
• ימי הפיגור מחושבים כמקסימום שבין (מועד הנפקת הדו"ח פחות תאריך התשלום) לבין 0.

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

טבלה 2: דוח גיול, במספרי הדוגמה מהסעיף השני

שם לקוח	סך הכל חוב בפיגור (ש"ח)
ב	300
ג	200
סה"כ	500

בבגדול, מה שעשיתי זה לקחתי את טבלה 1, ועבור כל לקוח סיכמתי את טור הסכום, עבור שורות עם ימי פיגור גבוהים מ-0. אפשר גם לעשות את זה באקסל, בעזרת טבלת פיבוט וסינון לפי תאריך התשלום בעזרת פיצ'ר שנקרא PivotTable Timeline. פשוט, נכון?

דוח גיול הוא הכלי מספר 1 בידיו של מנהל הכספים כדי להעריך:

• עד כמה אמיתיות העסקאות שנסגרו? אם החשבוניות לא משולמות אולי יש סיבה לכך
• עד כמה טובה מערכת הגבייה של החברה
• כמה מזומן עתיד להיכנס לקופת החברה. למשל, עבור החברה הנידונה, אנו רואים כי עד לסוף חודש אפריל אמורים להיכנס לקופה 1,100 ש"ח (900 ש"ח מלקוח א' ו-200 ש"ח מלקוח ב'). זה נדבך די חשוב לחיזוי תזרים המזומנים, בו נגעתי בפוסט קודם.

עכשיו, נהוג להציג דוח גיול עם קיבוץ החובות בפיגור לפי 0-30 ימים, 30-60 ימים ו-90+, אבל כשיש בלאגן בגיול, כלומר חשבוניות שלא נסגרו במלואן מול כספים שנכנסו, החלוקה הזו לא תהיה נכונה. למשל, אם הייתי מקבץ את דוח הגיול בדוגמה בקפיצות של 10 ימים, עבור לקוח ג' הייתי רואה שיש לו פיגור של -100 ש"ח בקבוצה של 10-20 ימים ופיגור של 300 ש"ח בקבוצה של 20-30. סתם מבלבל.

הערה קטנה למשתמשי פריוריטי: עד כמה שידוע לי, אם חשבונית לא נסגרת במלואה, אי אפשר להקצות קבלה מסוימת דווקא אליה. כלומר, נגיד ויש לנו שתי חשבוניות פתוחות על סכום של 300 ש"ח כל אחת ולקוח העביר לנו 100 ש"ח בעד החשבונית הראשונה. בהנחה שנשאיר את כל התנועות האלה כלא מתואמות, מה שנקבל בדוח הגיול של לקוח ספציפי הוא שיש לו שלוש תנועות פתוחות, שתיים על 300 ש"ח (בחובה) ואחת על 100 ש"ח (בזכות). אין לנו דרך לדעת שהדרך הנכונה יותר להציג זאת היא שיש לנו תנועה אחת פתוחה על 200 ש"ח (בחובה) ותנועה אחת פתוחה על 300 ש"ח (בחובה). זה קצת מבאס, כי היינו רוצים לשלוח ללקוח דוח גיול מסכם עם כל היתרות הפתוחות, כשאנחנו יודעים להציג את היסטוריית התשלומים בגין כל חשבונית שנשארה פתוחה בצורה מסודרת. Oh well…

שלב רביעי: אכיפת מדיניות גבייה

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

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

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