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

מספר הקצאה הוא מספר בן 9 ספרות שמוקצה על ידי רשות המסים לחשבונית מס שעוברת את הסף הרלוונטי במודל חשבוניות ישראל (המוכר בעברית כ"חשבוניות חכמות"), ומופיע בגוף החשבונית לצד מספר העוסק של המוכר. עד 31 במאי 2026 הסף עומד על 10,000 ש"ח לפני מע"מ; מ-1 ביוני 2026 הסף הסופי יורד ל-5,000 ש"ח לפני מע"מ. מאותו רגע כמעט כל חשבונית ספק B2B שמגיעה למשרד היא חשבונית חייבת ומחויבת לשאת מספר הקצאה תקין, אחרת אין דרך לקזז אותה.

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

המאמר נכתב למנהלת חשבונות פנימית ב-SMB ישראלי שמטפלת בעשרות חשבוניות ספק בחודש, למשרד הנהלת חשבונות או רואי חשבון שמריץ AP במקביל לכמה לקוחות, ולעוסק המורשה שמנהל את ספריו בעצמו, ובפרט כזה שמחזור עסקאותיו חוצה את סף 500,000 ש"ח השנתי שמכניס מ-2026 לחובת דוח תקופתי מפורט (PCN874). הפלט המבוקש זהה לשלוש הקבוצות: קובץ אקסל מובנה הכולל את שדות החשבונית, את מספר ההקצאה, ושדה תקינות שמסמן מראש איזו שורה זמינה לקיזוז ואיזו חוסמת אותו, כך שאותו קובץ נקלט נקייה בחשבשבת, פריוריטי, ריווחית או וויזקאונט ומהווה גם בסיס ישיר להפקת הדוח התקופתי המפורט.

טבלת הסף לחשבוניות חכמות — מה חל היום ומה משתנה ב-1 ביוני 2026

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

• 2024: 25,000 ש"ח לפני מע"מ.
• 2025: 20,000 ש"ח לפני מע"מ.
• 1 בינואר 2026 עד 31 במאי 2026: 10,000 ש"ח לפני מע"מ.
• מ-1 ביוני 2026 והלאה: 5,000 ש"ח לפני מע"מ — הסף הסופי.

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

מקור הסף החדש הוא האצת הסף ל-5,000 ש"ח ביוני 2026, כפי שדווח ב-TheMarker: ועדת הכספים אישרה את האצת רפורמת חשבוניות ישראל, והחל מ-1 ביוני 2026 כל חשבונית מס מעל 5,000 ש"ח תחייב קבלת מספר הקצאה מרשות המסים — הסף הסופי, מוקדם ביותר משנה וחצי מהתכנית המקורית שדיברה על 2028. עובדה זו חשובה ספציפית למשרדים שתכננו את לוח הזמנים לפי המתווה המקורי וטרם עדכנו את הנהלים הפנימיים.

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

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

מה באמת מפסידים על חשבונית ספק בלי מספר הקצאה — מס תשומות והכרה בהוצאה

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

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

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

הדוגמה המספרית הופכת את ההפרש בין שני הרבדים למוחשי. נניח חשבונית ספק על 10,000 ש"ח לפני מע"מ, סך הכל לתשלום 11,800 ש"ח (מע"מ של 18%, כפי שחל בישראל מינואר 2025):

• מס תשומות אבוד: 1,800 ש"ח.
• הוצאה שנפסלת: 10,000 ש"ח. תוספת המס הצפויה על אובדן ההכרה בהוצאה נעה בין כ-2,300 ש"ח לחברה בשיעור מס חברות של 23%, לכ-5,000 ש"ח ליחיד בשיעור מס שולי גבוה של עד 50%.
• סך ההפסד הישיר על חשבונית בודדת אחת: בין כ-4,100 ש"ח לכ-6,800 ש"ח, לפי סיווג ושיעור המס של מקבל החשבונית.

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

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

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

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

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

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

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

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

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

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

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

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

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

דרך 1: הזנה ידנית לגיליון אקסל

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

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

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

דרך 2: סנכרון אוטומטי בתוך פלטפורמת הנפקה

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

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

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

דרך 3: חילוץ אצווה ישירות מ-PDF, תמונה או דואר נכנס

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

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

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

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

בפועל — שילוב, לא בחירה

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

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

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

העמודות שמרכיבות את קלט חשבונית ספק עם מספר הקצאה לחשבשבת ולמערכות הקליטה האחרות

• Supplier_Name (שם ספק). השם המלא של הספק כפי שמופיע על החשבונית, לא הקיצור הפנימי שלכם.
• Supplier_Tax_ID (מספר עוסק ספק). מספר 9 ספרות; ההצלבה הראשונה שמערכת הנהלת החשבונות מבצעת מול כרטיס הספק.
• Invoice_Number (מספר חשבונית). מספר הריצה של החשבונית אצל הספק.
• Invoice_Date (תאריך החשבונית). תאריך ההנפקה, לא תאריך הקבלה.
• Net_Amount (סכום לפני מע"מ). הוא גם השדה שעליו נמדדת חציית הסף (5,000 או 10,000 לפי התקופה).
• VAT_Rate (% מע"מ). ברירת המחדל 18% מינואר 2025, אבל יש לבדוק חשבוניות חריגות (שיעור אפס לעוסקים פטורים, יצוא, אזורי סחר חופשי).
• VAT_Amount (סכום מע"מ). הסכום עצמו ולא חישוב מחדש; אי-התאמה בין Net כפול VAT_Rate ל-VAT_Amount היא דגל אדום לבדיקה ידנית.
• Total_Amount (סכום לתשלום). Net ועוד VAT, כפי שמופיע על החשבונית.
• Allocation_Number (מספר הקצאה). 9 ספרות. ריק כשהחשבונית מתחת לסף.
• Allocation_Status. הערכים המומלצים: "תקין", "חסר", "מתחת לסף", "999999998", "שגוי". "חסר" משמעו שאין כלל מספר הקצאה בחשבונית מעל הסף; "שגוי" משמעו שיש מספר אבל הוא מעוות (אורך לא נכון, מכיל אותיות או מקפים, או לא תואם את פורמט ה-9 ספרות). שמרו את התוויות בעברית כי הן מופיעות בדוחות פנימיים שמנהל החשבונות צופה בהם יומיומית.
• Withholding_Tax (ניכוי מס במקור). סכום הניכוי במקור אם חל, או 0 כאשר אין תעודת פטור.
• Payment_Status (סטטוס תשלום). "פתוח", "שולם", "מתוזמן".
• Source_File (קובץ מקור). שם הקובץ ומספר העמוד שממנו חולצה החשבונית. קריטי לביקורת רטרואקטיבית.

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

מיפוי לחשבשבת

חשבשבת קולטת חשבוניות ספק דרך מודול הקליטה המובנה. עמודות החובה במיפוי הסטנדרטי הן מספר ספק (Supplier_Tax_ID), מספר חשבונית (Invoice_Number), תאריך (Invoice_Date), סכום לפני מע"מ (Net_Amount), מע"מ (VAT_Amount) וסך הכל (Total_Amount). Allocation_Number נשמר על השורה כשדה אסמכתא וניתן לסנן לפיו. בגרסאות עדכניות חשבשבת מציגה את מספר ההקצאה כשדה ייעודי בכרטיסיית החשבונית; בגרסאות ישנות יותר השדה ממופה לשדה האסמכתא הכללי.

מיפוי לפריוריטי

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

מיפוי לריווחית ולוויזקאונט

ריווחית קולטת חשבוניות ספק לרשימת "חשבוניות פתוחות לתשלום", עם השדות הסטנדרטיים של הסכמה. וויזקאונט, שהיא חלק ממשפחת H-ERP, קולטת דרך כלי הקליטה של חשבשבת ולכן עוקבת אחר אותו מיפוי. בשתיהן, שמירה קפדנית של Source_File עם שם הקובץ ומספר העמוד היא מה שמאפשר ביקורת רטרואקטיבית של רשות המסים אחרי שהחשבונית המקורית כבר נמחקה משולחן העבודה.

עמודת Withholding_Tax

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

טיפ פורמט אחד שחוסך שעות

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

הכנה אוטומטית של דוח תקופתי מפורט (PCN874) מאותן שורות

הדוח התקופתי המפורט (PCN874) הוא הדיווח החודשי או הדו-חודשי שמחייב פירוט פר-חשבונית של רכישות והניכוי בגינן, במקום סיכום ברוטו של תשומות שהדוח התקופתי הרגיל מסתפק בו. החובה חלה על עוסק מורשה שמחזור עסקאותיו עובר את הסף שקבעה רשות המסים. מ-1 בינואר 2026 הסף יורד ל-500,000 ש"ח מחזור שנתי לעוסק מורשה, וזה מכניס לחובה הזו אוכלוסייה רחבה של עוסקים שלא נדרשו אליה קודם.

המפתח להבנת המבנה התפעולי הוא להבין שאותו קובץ אקסל שבניתם לקליטה במערכת הנהלת החשבונות (סעיף 6) הוא, ברובו, גם הקלט להפקה אוטומטית של PCN874. אין שתי עבודות נפרדות; יש קובץ אחד עם שני שימושים.

מבנה הקובץ של PCN874

הקובץ הוא טקסטואלי. רשות המסים מקבלת אותו ברוחב קבוע (fixed-width, פורמט שורות בעלות מספר תווים מוגדר לכל שדה) או כ-CSV עם שדות מוגדרים מראש. השדות המרכזיים שעל כל שורת חשבונית למלא הם:

• סוג רשומה (קוד שמציין אם זו רכישה רגילה, יבוא, רכישה מעוסק פטור וכדומה).
• מספר עוסק ספק.
• מספר חשבונית.
• תאריך החשבונית.
• סכום העסקה לפני מע"מ.
• סכום המע"מ.
• קוד סיווג עסקה (S/T/I/M לפי סוג הטרנזקציה ולפי הטיפול המיסויי הנדרש).
• מספר הקצאה, חובה ברשומות שהחשבונית בהן מעל הסף.

המיפוי הישיר מסכמת האקסל ל-PCN874

מהסכמה שבסעיף הקודם:

• Supplier_Tax_ID → שדה מספר עוסק ספק.
• Invoice_Number → שדה מספר אסמכתא.
• Invoice_Date → שדה תאריך החשבונית.
• Net_Amount → שדה סכום עסקה.
• VAT_Amount → שדה מס תשומות.
• Allocation_Number → שדה מספר הקצאה.

השדות שמתווספים ב-PCN874 ולא קיימים בקובץ הקליטה הסטנדרטי הם קוד סיווג עסקה (S/T/I/M, נקבע לפי סוג הרכישה — שירות, סחורה, יבוא, מעורב) וקוד סוג רשומה. את שני אלה אפשר לחשב מהשדות הקיימים: סוג הרשומה נגזר משילוב של פרופיל הספק (עוסק רגיל/פטור) ופרופיל החשבונית, וקוד הסיווג נגזר מקטגוריית ההוצאה בכרטיס הספק או מסיווג אוטומטי על בסיס תוכן החשבונית. בכל מקרה, הם נוספים על שורת הקובץ הסטנדרטי ולא דורשים עבודה חוזרת על השדות המקוריים.

שתי הטעויות הנפוצות שמובילות לדחיית הדוח

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

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

הריצו סימולציה לפני ההגשה

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

בדיקת תקינות לפני שמדווחים — צ'קליסט לכל חשבונית ספק

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

1. האם החשבונית מעל הסף החל בתאריך החשבונית? עד 31 במאי 2026 הסף הוא 10,000 ש"ח לפני מע"מ; מ-1 ביוני 2026 הוא 5,000 ש"ח לפני מע"מ. אם החשבונית מתחת לסף החל ביום ההנפקה, סמנו Allocation_Status = "מתחת לסף" — זה מצב תקין, אין דרישה למספר הקצאה.
2. אם מעל הסף: האם מופיע מספר הקצאה בעל 9 ספרות בגוף החשבונית? ספרות בלבד, ללא אותיות וללא מקפים. שדה ריק או מספר באורך שונה הוא דגל אדום שמחייב פנייה לספק לפני הקיזוז.
3. האם מספר העוסק בשדה הלקוח הוא מספר העוסק שלכם — ולא 999999998? כל ערך שאינו מספר העוסק המדויק של ישות הדיווח שלכם פוסל את החשבונית לקיזוז, גם כשמספר ההקצאה עצמו תקין.
4. האם מספר העוסק של הספק תואם את הרישום בכרטיס הספק שלכם? אי-התאמה כאן יכולה לאתת על שינוי ישות אצל הספק שלא עודכן, או, נדיר יותר, על חשבונית מזויפת.
5. האם תאריך החשבונית נופל בתקופת הדיווח הנוכחית? חשבונית שתאריכה בתקופה שכבר דווחה דורשת את הטיפול הנפרד של תיקון דוח, לא קליטה רגילה.
6. האם הסכומים על החשבונית מסתכמים נכון? Net ועוד VAT חייב להיות שווה ל-Total. סטייה כאן כמעט תמיד מצביעה על שגיאת חילוץ של ספרה בודדת, לא על טעות אצל המוכר — וצריכה לחזור לבדיקה ידנית של הקובץ המקורי.
7. האם החשבונית היא חשבונית מס, ולא חשבונית עסקה? חשבונית עסקה אינה מקנה זכות קיזוז גם אם הונפק עליה מספר הקצאה תקין. הבדיקה הזו פשוטה ויזואלית — שם המסמך מודפס בראש החשבונית ומבדיל בין הסוגים.

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

שורה שעוברת את כל שבע הבדיקות נכנסת ישירות לקובץ הקליטה למערכת הנהלת החשבונות ולקובץ ה-PCN874 ללא טיפול נוסף.