חילוץ חשבוניות מס/קבלה מספקים לאקסל — מדריך 2026

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

המשמעות של זה לקליטה היא מעשית מאוד. חילוץ חשבוניות מס/קבלה מספקים לאקסל דורש ארבעה שדות שאינם נדרשים בחשבונית מס סטנדרטית: מספר חשבונית, מספר קבלה, אמצעי תשלום (מזומן, אשראי, העברה בנקאית או שיק), ושיעור מע"מ — לרבות שיעור 0 לעסקאות באזור סחר חופשי אילת. כאשר ערך המסמך חוצה את סף ההקצאה הקרוב, 5,000 ש"ח מ-1.6.2026, נדרש שדה חמישי: מספר הקצאה תקף שהונפק מראש על-ידי רשות המסים, ובלעדיו מס תשומות לא ניתן לקיזוז.

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

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

שני מספרי זיהוי במסמך אחד — מספר חשבונית ומספר קבלה בעמודות נפרדות

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

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

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

הספקים לא תמיד מקלים. ספקים שונים מסמנים את שני המספרים במקומות שונים על המסמך: לפעמים שניהם בכותרת בשתי שורות סמוכות; לפעמים מספר החשבונית בכותרת ומספר הקבלה בתחתית ליד פירוט אמצעי התשלום; לפעמים נמצא רק אצל ספקים מסוימים מבנה מאוחד של "חשבונית/קבלה מס' X" עם זהות מספרית בין שני המזהים — ואז דווקא צריך לוודא שלא נתפסה אסמכתא יחידה תחת שני שמות עמודה. בחילוץ אוטומטי ובחילוץ ידני כאחד, הבדיקה הראשונה אחרי שכל העמודות התמלאו היא שבכל שורה Invoice_Number ו-Receipt_Number אינם זהים אלא אם הספק הזה באמת מנפיק מסמכים בזיהוי מאוחד.

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

אמצעי תשלום כעמודת ניתוב — איך מזומן, אשראי, העברה ושיק משנים את פקודת היומן

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

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

אשראי. שורת התקבול נכנסת לכרטיס סולק כרטיסי האשראי — חוב פתוח של חברת האשראי כלפי העסק, לא ישירות לבנק. הסליקה מתבצעת אחת לחודש, בניכוי עמלות. כשמגיע דף הסליקה החודשי, ההתאמה היא בין סכום החשבוניות מס/קבלה ששולמו בכרטיס אצל ספקים שונים באותו חודש לבין ההפקדה בפועל מהסולק, בניכוי עמלות סליקה. אקסל שמסמן Payment_Method = אשראי בשורות הרלוונטיות הופך את ההתאמה הזו לחישוב פילטר בסיסי; אקסל שלא מפריד אותן הופך אותה לעבודה ידנית של סינון לאחור.

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

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

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

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

פירוט מע"מ ועמודת השיעור — כולל מע"מ 0 לחשבוניות מאזור סחר חופשי אילת

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

ההיגיון של VAT_Rate בקליטה הוא בינארי לפעולת הקיזוז: שיעור 17 מאפשר קיזוז מלא של סכום המע"מ כמס תשומות; שיעור 0 משבית את הקיזוז לגמרי, כי אין מע"מ לקזז. מקרה מע"מ 0 הוא מקור מסוים לבלבול, משום שהמסמך עצמו נראה זהה לכל חשבונית מס/קבלה אחרת — כותרת, פירוט, חתימה, אסמכתאות.

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

הפתרון בסכמה הוא להפריד את שיעור המע"מ לעמודה מספרית מפורשת. VAT_Rate שמכיל את הערך 17 או 0 (לא טקסט "סטנדרטי" או "אילת") מאפשר חישוב חוזר של VAT_Amount מ-Net לצורך בקרה (Net × VAT_Rate / 100), ומאפשר גם לכל שורה שבה VAT_Rate = 0 ליפול אוטומטית לקבוצת קליטה נפרדת בחשבשבת או בפריוריטי תחת קוד עסקה של פטור ממע"מ.

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

מספר הקצאה כעמודה — מתי הסף נכנס לתוקף ואיך הוא נדגל באקסל

מ-1.6.2026, סף ההקצאה החדש הוא 5,000 ש"ח לפני מע"מ. כל חשבונית מס/קבלה שערכה נטו חוצה את הסף הזה חייבת לכלול מספר הקצאה תקף שהונפק על-ידי רשות המסים מראש דרך מסלול שירות החשבוניות. אם המספר חסר, אם הוא לא תקף, או אם הוא לא מתאים לחשבונית הספציפית — מס תשומות לא ניתן לקיזוז, גם אם כל יתר השדות במסמך תקינים.

מספר ההקצאה הוא מזהה ייחודי של 9 ספרות שמופיע על פני המסמך במקום מוגדר ברגולציה. הוא לא מחליף את מספר החשבונית ולא מחליף את מספר הקבלה — הוא שדה שלישי שמתווסף לשתי האסמכתאות הקיימות. בסכמת האקסל הוא מקבל שתי עמודות ייעודיות: Allocation_Number (המספר עצמו, כשהוא קיים על המסמך), ו-Allocation_Required (דגל בינארי שמסמן אם החשבונית הזו אמורה לשאת מספר הקצאה לפי הסף התקף בתאריך החשבונית).

ההיגיון של עמודת Allocation_Required נגזר מהשוואה בין Net לבין הסף התקף בתאריך החשבונית — לא בתאריך הקליטה לאקסל. הסף יורד בשלבים: ינואר 2025 פתח בסף של 25,000 ש"ח, ינואר 2026 הוריד אותו ל-10,000 ש"ח, ויוני 2026 מוריד אותו ל-5,000 ש"ח (היעד הסופי). חשבונית מס/קבלה ישנה מ-2025 בסכום של 8,000 ש"ח לא הייתה חייבת מספר הקצאה כשהוצאה (היא מתחת לסף שהיה תקף אז); אותו סכום מסמך שהוצא ביוני 2026 כן חייב מספר הקצאה. בקליטה במסה של תיקייה שבה מסמכים מתפרסים על פני חודשים שונים, צריך לפתור את הלוגיקה הזו לכל שורה בנפרד.

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

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

חשבשבת, פריוריטי, ריווחית ו-וויזקאונט כבר הוסיפו שדה אסמכתת הקצאה לטופס קליטת חשבונית הספק במהלך 2025. העבודה של האקסל היא להעביר את הערך משדה Allocation_Number במאמר לשדה אסמכתת ההקצאה במערכת — וכשמדובר בשורה שבה Allocation_Required = TRUE אבל Allocation_Number ריק, האקסל לא מעביר אותה למערכת בכלל אלא לקבוצת המתנה.

קוד הלקוח 999999998 — איך מסמנים בקליטה שלא ניתן לקזז מס תשומות

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

ההשלכה לקיזוז מס תשומות חדה: כשמספר העוסק של הקונה הוא 999999998, החשבונית מס/קבלה אינה מאפשרת קיזוז מס תשומות אצל הקונה. גם אם הקונה הוא בפועל עוסק מורשה בעל מספר עוסק חוקי, גם אם המע"מ מפורט במסמך בשורה נפרדת ושיעור 17%, וגם אם הספק תקין לחלוטין מצדו — תנאי הזכאות לקיזוז הוא שהמסמך עצמו יזהה את הקונה במספר העוסק הנכון. מסמך שמסומן ב-999999998 לא עומד בתנאי הזה.

הסיכון התפעולי מצטבר במהירות. רוב המסמכים הקטנים שעוסק מורשה אוסף לאורך החודש מגיעים בדיוק מהסיטואציה הזו: דלק שמילא בלי להציג את כרטיס העוסק בתחנה; ארוחה במסעדה ששילם בכרטיס פרטי או במזומן; חניון בשדה התעופה; חניית מטעמים בעיר. בכולם הקופאי לא ביקש או לא קיבל את התעודה, ולכן ההדפסה יצאה עם 999999998 כברירת מחדל. החילוץ האוטומטי קורא את המסמך, מזהה שיעור מע"מ 17%, ממלא את עמודת VAT_Amount בערך הנכון — ובלי דגל נוסף בסכמה, מנהל/ת החשבונות מקזז/ת בדוח התקופתי על סמך נתוני האקסל לבד. הקיזוז הזה ייפסל בביקורת.

הפתרון בסכמה הוא להוסיף שתי עמודות שעובדות יחד: Buyer_Tax_ID קולט/ת את הערך שמופיע על המסמך בשדה מספר העוסק של הקונה (כולל הערך 999999998 כשהוא שם); ועמודת Input_VAT_Eligible נגזרת אוטומטית — היא מקבלת ערך TRUE כש-Buyer_Tax_ID שווה למספר העוסק של עסק הקונה הנכון, ו-FALSE בכל מקרה אחר (כולל 999999998, וכולל שדה ריק או מספר עוסק שגוי). דוח התקופתי נבנה רק מהשורות שבהן Input_VAT_Eligible = TRUE, וסכום המע"מ בשורות ה-FALSE נשמר באקסל לתיעוד אבל לא משתתף בקיזוז.

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

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

שלושה מסלולים לקליטת התיקייה — הקלדה ידנית, סריקה מאפליקציית הספק, וכלי חילוץ מסמכים

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

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

מסלול 2: סריקה מתוך אפליקציית הספק או מתוך פלטפורמת ההנפקה. Greeninvoice, iCount, EasyCount ועוד פלטפורמות הנפקה ישראליות מציעות אפליקציה לקבלת חשבונית מהספק ישירות לסביבה של הקונה — אם הקונה משתמש באותה פלטפורמה. כשהספק והקונה שניהם, למשל, ב-Greeninvoice, שיתוף הנתונים מאפשר משיכה אוטומטית של מסמכי הספק לכרטסת הקונה בלי הקלדה. בפועל הכיסוי מצומצם מאוד: רוב התשלומים-במקום במשק הישראלי מגיעים מספקים על פלטפורמות שונות, מקופות רושמות שלא משתפות נתונים החוצה, או מנייר תרמי שאינו דיגיטלי כלל. למסעדה שמקבלת חשבוניות מס/קבלה ממספקי מזון שונים, למוסך שמקבל מספקי חלקים שונים, ולמשרד הנהלת חשבונות שמטפל במאה לקוחות בענפים שונים — המסלול הזה מכסה אולי חלק מהספקים, בדרך כלל מעטים. לא נותן פתרון לתמהיל הספקים האמיתי.

מסלול 3: כלי חילוץ מסמכים שקורא PDF, תמונה או צילום טלפון. כלי שעובד על הקלט עצמו — מסמך מצולם, מסמך סרוק, או מסמך PDF — ומייצר שורה באקסל לכל מסמך, מתאים למשרדי הנהלת חשבונות עם עשרות עד מאות חשבוניות מס/קבלה לחודש; למסעדות, רשתות קמעונאיות ומוסכים שאוספים כמה מסמכים ביום; ולעוסקים מורשים בעלי נפח אמיתי. הוא הופך תיקייה של מסמכים מעורבים — חשבוניות ממאות ספקים שונים, חלקם PDF דיגיטליים מהפלטפורמה של הספק, חלקם צילומי טלפון של נייר תרמי, חלקם סריקות באיכות בינונית — לקובץ אקסל אחיד עם כל העמודות שתוארו בסעיפים הקודמים: שתי האסמכתאות, אמצעי תשלום, שיעור מע"מ עם דגלי אילת ויצוא, מספר הקצאה ודגל Allocation_Required, ודגל Input_VAT_Eligible שמסמן את שורות 999999998. זה המסלול שבו כלי חילוץ נתונים מחשבוניות ספקים לאקסל שלנו מתאים באופן ספציפי לתמהיל הישראלי.

בפועל, מי שמשתמש/ת בכלי כזה מעלה תיקייה של עד 6,000 מסמכים בעבודה אחת — PDF, JPG, או צילומי טלפון של נייר תרמי — וכותב/ת בעברית פרומפט שמתאר את הסכמה שתוארה כאן. הפלט הוא קובץ XLSX עם שורה לכל מסמך וכל העמודות מלאות. הכלי קורא עברית מימין לשמאל בלי קונפיגורציה נוספת, וצילום טלפון של חשבונית מס/קבלה על נייר תרמי נקרא באותה איכות שבה הוא קורא PDF מקורי — שזה הקלט הדומיננטי בתיקייה אמיתית של תשלומים-במקום.

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

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

סכמת האקסל המלאה — ומיפוי הקליטה לחשבשבת, פריוריטי, ריווחית ו-וויזקאונט

הסכמה המלאה של האקסל, בסדר העמודות המומלץ, נראית כך:

#	עמודה	תיאור
1	Supplier_Name	שם הספק כפי שמופיע על המסמך
2	Supplier_Tax_ID	מספר עוסק/ח.פ. של הספק
3	Buyer_Tax_ID	מספר עוסק של הקונה כפי שמופיע על המסמך (כולל 999999998 כשרלוונטי)
4	Invoice_Number	מספר החשבונית
5	Receipt_Number	מספר הקבלה
6	Date	תאריך החשבונית/קבלה
7	Net	סכום נטו לפני מע"מ
8	VAT_Rate	שיעור מע"מ באחוזים (17 או 0)
9	VAT_Amount	סכום המע"מ
10	Total	סך הכל כולל מע"מ
11	Payment_Method	מזומן / אשראי / העברה / שיק
12	Allocation_Number	מספר הקצאה (9 ספרות) כשהוא מופיע על המסמך
13	Allocation_Required	TRUE/FALSE — נגזר מ-Net אל מול הסף התקף בתאריך החשבונית
14	Input_VAT_Eligible	TRUE/FALSE — נגזר מ-Buyer_Tax_ID ומ-VAT_Rate
15	Source_File	קובץ המקור עם מספר עמוד, לצורך אימות לאחור

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

חשבשבת. מסך "קליטת חשבוניות ספקים" מקבל את העמודות הבאות: Supplier_Tax_ID לזיהוי כרטיס הספק, Invoice_Number בשדה אסמכתא 1, Date כתאריך החשבונית, Net כסכום ההוצאה, VAT_Amount כסכום המע"מ, Total כסך הכל, ו-Allocation_Number בשדה אסמכתת ההקצאה. שורת התקבול נקלטת בנפרד דרך "קליטת תקבולים" — Receipt_Number בשדה אסמכתא, Date כתאריך התקבול, Total כסכום, וכרטיס המאזן היעדי נבחר לפי Payment_Method (חשבון קופה למזומן, חשבון סולק לאשראי, חשבון בנק להעברה, חשבון שיקים לגבייה לשיק עם רישום מועד הפירעון בנפרד).

פריוריטי. מסך חשבוניות לקבל מספקים (טבלת AP) מקבל את הקליטה דרך טופס ייעודי. Invoice_Number ממופה לשדה אסמכתא החשבונית של AP, Allocation_Number ממופה לשדה ההקצאה הייעודי שנוסף בעדכון הרגולציה ב-2025, ו-Payment_Method מנותב באמצעות יצירת תנועת תקבול אוטומטית בעת הקליטה: בחירת הערך "שולם במזומן/אשראי/העברה/שיק" יוצרת את שורת התקבול בכרטיס המאזן הנכון בלי הזנה ידנית של פקודת יומן נפרדת.

ריווחית. קליטת תנועות הנהלת חשבונות תומכת בייבוא חשבונית מס/קבלה כתנועה אחת עם פיצול לשני סעיפים — שורת ההוצאה והמע"מ אל מול כרטיס הספק, ושורת התקבול אל מול כרטיס הקופה/הבנק. הפורמט הוא קובץ CSV עם עמודות תאריך, אסמכתא, אסמכתא 2, כרטיס חובה, כרטיס זכות, סכום ופירוט. עמודות האקסל מותאמות אליו: Invoice_Number → אסמכתא, Receipt_Number → אסמכתא 2, ניתוב כרטיס החובה/זכות נקבע לפי Payment_Method.

וויזקאונט. ייבוא תנועות מקובץ אקסל או CSV עם אותה לוגיקה של אסמכתא 1 / אסמכתא 2 / שדה הקצאה כמו בריווחית; הנקודה התפעולית הייחודית היא שהשמות המדויקים של עמודות הייבוא משתנים בין גרסאות התקנה, ולכן יש לאמת את שורת הכותרת מול תבנית הייבוא של גרסת הלקוח לפני ההרצה הראשונה.

גם כשהמערכת תומכת בייבוא אוטומטי, מומלץ לבצע הרצת ניסיון על קבוצה קטנה של 10–20 שורות לפני קליטה במסה. הרצה כזו בודקת שלוש נקודות חיבור שנשברות בשקט: שמיפוי VAT_Rate = 0 באמת מפיל את השורה לקוד עסקה של פטור (אילת, ייצוא, או חקלאות) ולא לקוד עסקה רגיל עם 17/117; ש-Allocation_Required = TRUE עם Allocation_Number חסר נדחה לקבוצת המתנה במקום להיקלט בלי הקצאה; ושערכי Input_VAT_Eligible = FALSE לא מצטרפים לסך מס התשומות בדוח התקופתי.

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