מה השתנה ב-2026, במספרים
מודל חשבוניות ישראל התחיל לעבוד בפועל ב-5 במאי 2024, עם סף של 25,000 ש"ח. בשנת 2025 הוחלט להאיץ את המתווה: מ-1 בינואר 2026 הסף ירד ל-10,000 ש"ח, ומ-1 ביוני 2026 ל-5,000 ש"ח. את לוח הזמנים המעודכן הזה מפרט דוח מבקר המדינה שפורסם ביוני 2026.
שימו לב לפרט שמבלבל מפתחים: מפרט ה-API של רשות המסים (מהדורה 2.0, יולי 2024) עדיין מציג את המתווה המקורי, שבו 5,000 ש"ח הגיע רק ב-2028. הקוד שלכם צריך לעבוד לפי המתווה המואץ, ובפועל כדאי שהסף יהיה ערך קונפיגורציה ולא קבוע בקוד.
| תקופה | סף לפני מע"מ |
|---|---|
| מ-5 במאי 2024 | 25,000 ש"ח |
| 2025 | 20,000 ש"ח |
| מ-1 בינואר 2026 | 10,000 ש"ח |
| מ-1 ביוני 2026 | 5,000 ש"ח |
לפי המפרט, חובת העברת המידע חלה כשמתקיימים ארבעה תנאים מצטברים: הסכום לפני מע"מ מעל הסף, בחשבונית יש רכיב מע"מ שאינו אפס, הלקוח הוא עוסק מורשה, והלקוח דרש מספר הקצאה. בפועל לקוח עסקי תמיד ידרוש, כי בלי המספר הוא לא יכול לנכות מס תשומות. מותר לבקש מספר הקצאה לכל חשבונית בכל סכום, כולל זיכויים, וזו ברירת מחדל סבירה למוצר B2B.
השירותים שרשות המסים חושפת
המפרט הרשמי מגדיר כמה שירותים, וכולם עובדים ב-OAuth2 בהרשאת משתמש (User Restricted), עם סביבת Sandbox וסביבת Production נפרדות:
- Approval: בקשת מספר הקצאה לחשבונית בודדת, מצד הספק. זה השירות שתשתמשו בו ברוב המקרים.
- MultiApproval: אותו דבר למקבץ חשבוניות בבקשה אחת. שימושי למערכות שמפיקות חיובים חודשיים בבת אחת.
- Invoice-Information: שירות מצד הלקוח, שמחזיר את פרטי החשבונית לפי מספר הקצאה, או את מספר ההקצאה לפי פרטי החשבונית. מעניין אם אתם בונים מערכת שקולטת חשבוניות ספקים.
- Invoice-decision: עדכון רשות המסים בהחלטה של המשתמש לגבי חשבונית שעוכבה (ביטול, המשך בלי הקצאה, או בקשה לשימוע).
שדות החובה בבקשת Approval כוללים בין היתר: invoice_id (מזהה ייחודי עד 50 תווים), סוג המסמך, מספר העוסק של המנפיק, מספר האסמכתא, מספר העוסק של הלקוח, תאריך המסמך, תאריך ההפקה האוטומטי, מספר רישום התוכנה (ואם אין כזה, ח.פ. או ת.ז. של מפיק המסמך), הסכומים לפני ואחרי מע"מ, ותעודת זהות או שם המשתמש שמבצע בפועל את ההקצאה.
סוגי המסמכים שמקבלים מספר הקצאה לפי טבלת המפרט: חשבונית מס (305), חשבונית מס ריכוז (310), חשבונית מס קבלה (320), חשבון עסקה או פרופורמה בהקצאה מוקדמת (332), חשבונית מס סוכן (345) ופקודת יומן (348). חשבונית מס זיכוי (330) לא מקבלת מספר הקצאה לפי הטבלה.
הארכיטקטורה שאנחנו ממליצים עליה
הטעות הנפוצה היא לקרוא ל-API של רשות המסים באמצע בקשת ה-HTTP של המשתמש ולהציג שגיאה אם משהו נכשל. זה עובד ב-Sandbox ונשבר ביום עמוס. הנה המבנה שמחזיק בפרודקשן:
- יצירת החשבונית במצב טיוטה, עם invoice_id שנוצר פעם אחת ולא משתנה לעולם. המפרט מחייב שהחשבונית כבר תישא מספר אסמכתא בזמן הבקשה.
- שליחה לתור (Queue) של בקשות הקצאה, ולא קריאה סינכרונית. העובד (Worker) שולח, שומר את התשובה ומעדכן סטטוס.
- שמירת מספר ההקצאה ברשומת החשבונית ורק אז נעילה, יצירת PDF ושליחה ללקוח. המפרט מחייב להדפיס את 9 הספרות הימניות בבירור תחת הכותרת "מספר הקצאה", בנוסף למספר האסמכתא הפנימי.
- הכללת 9 הספרות בשדה הייעודי בדיווח המפורט (PCN874), אם העוסק מחויב בו.
אידמפוטנטיות: invoice_id הוא המפתח
המפרט קובע שבקשה חוזרת לגבי אותה חשבונית נעשית עם אותו invoice_id, למשל אחרי שימוע שבו החשבונית הותרה. זה בדיוק המפתח האידמפוטנטי שאתם צריכים: אם העובד קרס אחרי ששלח ולפני ששמר תשובה, הוא שולח שוב עם אותו מזהה ולא יוצר בקשה כפולה מבחינת המערכת שלכם. לעולם אל תייצרו invoice_id חדש בניסיון חוזר.
להבחין בין שלושה סוגי כישלון
זה הלב של כל האינטגרציה, ורוב המימושים החלשים מתייחסים לכל כישלון באותו אופן:
| מה חזר | מה זה אומר | מה המערכת עושה |
|---|---|---|
| HTTP 200 עם approved: true | הוקצה מספר | שומרים, נועלים, שולחים ללקוח |
| HTTP 200 עם שגיאה 460 | הנתונים תקינים אבל החשבונית לא אושרה (עיכוב מהותי) | לא מנסים שוב. מציגים למשתמש את ארבע החלופות |
| שגיאות 461 או 462 | חשבונית שעוכבה כבר קיימת, בלי החלטה או עם החלטה | 461: להציג שוב את החלופות. 462: אין צורך בפעולה |
| HTTP 400 (למשל 434 תאריך ישן מדי, 435 תאריך רחוק מחודש קדימה, 431 מספר עוסק שגוי) | נתונים לא תקינים | לא מנסים שוב אוטומטית. מסמנים לתיקון ומתריעים |
| HTTP 401 או 403 | טוקן פג או חסרה הרשאה | עוצרים את התור לעסק הזה ומבקשים מהמשתמש לחדש הרשאה |
| HTTP 500, timeout, תקלת רשת | תקלה זמנית | ניסיון חוזר עם השהיה הולכת וגדלה, אותו invoice_id |
מה עושים כשרשות המסים לא עונה
חשבונית שממתינה למספר הקצאה היא לא חשבונית שאפשר לשלוח ללקוח עסקי מעל הסף. לכן ה-UI צריך להציג מצב "ממתין להקצאה" ברור, והמערכת צריכה לשלוח התראה אם חשבונית תקועה יותר מזמן סביר. בהנחיות ליצרני תוכנה מ-2023 תיארה רשות המסים כוונה לשירות של "מספרי חירום" לכשל ממושך במערכותיה, שמותנה בתיעוד ניסיונות כושלים. לא מצאנו מסמך הפעלה מעודכן שלו, אז אל תבנו עליו כפתרון. מה שכן כדאי לעשות כבר עכשיו: לתעד כל ניסיון כושל עם חותמת זמן וקוד שגיאה.
עיכוב חשבונית: ארבע החלופות שהמערכת חייבת להציע
עד סוף 2024 כל בקשה תקינה קיבלה מספר. מינואר 2025 רשות המסים יכולה לסרב כשיש חשש לחשבונית שהוצאה שלא כדין. כשזה קורה, המפרט מחייב את התוכנה להציג למשתמש ארבע חלופות ולעדכן את הרשות בבחירה:
- ביטול החשבונית (Cancel), בתהליך הביטול הרגיל.
- המשך בלי מספר הקצאה (Continue). החשבונית תכלול בצורה בולטת את המשפט "אין לנכות מס תשומות בגין חשבונית זו".
- היפוך חיוב, בהסכמת הלקוח: בקשה מיוחדת לשירות ה-Approval עם חשבונית בשיעור אפס, אותו invoice_id והערך 3 בשדה action.
- בקשה לשימוע (FurtherObjection), עם קישור לפורטל השירות. אם החשבונית הותרה, שולחים בקשת הקצאה חוזרת עם אותו invoice_id.
זה מסך שרוב המפתחים שוכחים לתכנן, ובדיוק בו לקוח לחוץ צריך הכי הרבה בהירות. תכננו אותו מראש, עם טקסט שמסביר בעברית פשוטה מה כל חלופה אומרת לגבי הלקוח שלו.
טוקנים, הרשאות ואבטחה
כל עסק שמבקש מספרי הקצאה, ישירות או דרך תוכנה, צריך לבצע רישום חד-פעמי למערכת ההרשאה לפעולות דיגיטליות של רשות המסים. במערכת SaaS זה אומר שכל לקוח שלכם עובר תהליך חיבור משלו, ואתם מחזיקים טוקן לכל עסק.
- הצפנה במנוחה של טוקנים, בנפרד משאר נתוני הלקוח, עם מפתח שמנוהל מחוץ למסד הנתונים.
- בידוד בין לקוחות: באג שגורם לבקשת הקצאה לצאת עם הטוקן של עסק אחר הוא תקלה חמורה. אם אתם בונים מערכת מרובת לקוחות, קראו על ארכיטקטורת SaaS מרובת לקוחות לפני שאתם כותבים את השכבה הזו.
- תיעוד המשתמש בפועל: המפרט מחייב להעביר ת.ז. או שם של המשתמש שמבצע את ההקצאה בפועל, גם אם הטוקן רשום על משתמש "כללי" בארגון. זה אומר שצריך לשמור מי לחץ על הכפתור.
- התראה על טוקן שפג: אל תיתנו לתור להיתקע בשקט. מסך בולט "החיבור לרשות המסים פג, חברו מחדש" חוסך שיחות טלפון.
זה לא תרגיל תיאורטי. דוח מבקר המדינה מיוני 2026 מתאר מקרים של גניבת זהויות של עוסקים, הפקת חשבוניות על שמם וקבלת מספרי הקצאה לחשבוניות פיקטיביות. מערכת שמחזיקה הרשאות הקצאה של עשרות עסקים היא מטרה, ותתייחסו אליה כך.
יומן ביקורת
שמרו לכל חשבונית: כל בקשה שנשלחה (בלי הטוקן), כל תשובה מלאה, קוד השגיאה, מי ביצע, מתי, ואיזו החלטה התקבלה בעיכוב. יומן כזה הוא append-only ולא נמחק. כשלקוח ישאל למה החשבונית שלו יצאה בלי מספר, או כשרואה החשבון ישאל מה קרה ב-14 במרץ, זו התשובה.
לבנות בעצמכם או להשתמש בספק חשבוניות
המפרט עצמו מאשר שבתי תוכנה רשאים להשתמש בשירותי תיווך של ספקים אחרים כדי לפנות לשירותי ה-API של רשות המסים. ספקי חשבוניות ישראליים כמו Morning (חשבונית ירוקה) ו-iCount מציעים API להפקת מסמכים, וכך אתם מקבלים חשבונית מוכנה בלי לנהל את הקשר עם רשות המסים בעצמכם. את פרטי הטיפול בהקצאה ובעיכוב בדקו בתיעוד של כל ספק לפני שאתם מתחייבים.
| שיקול | חיבור ישיר לרשות המסים | API של ספק חשבוניות |
|---|---|---|
| מתי זה מתאים | הפקת חשבוניות היא הליבה של המוצר (תוכנת הנהלת חשבונות, ERP, מערכת חיוב) | חשבוניות הן תוצר לוואי של המוצר (SaaS, אפליקציה, מערכת הזמנות) |
| זמן פיתוח | שבועות: OAuth, תור, עיכובים, ביטולים, PDF, דיווח מפורט | ימים: קריאה ליצירת מסמך וטיפול בתשובה |
| אחריות על תקינות המסמך | עליכם, כולל מספור, נעילה וביטולים | על הספק, במסגרת התנאים שלו |
| שליטה בעיצוב ובחוויה | מלאה | מוגבלת לתבניות ולאפשרויות של הספק |
| עלות שוטפת | תחזוקה ושינויי מפרט | מנוי או עמלה לספק |
| תלות | ברשות המסים בלבד | בספק ובזמינות שלו, וברשות המסים דרכו |
כלל האצבע שלנו: אם אתם לא יכולים להצביע על לקוח שישלם לכם יותר בגלל שבניתם את זה בעצמכם, אל תבנו את זה בעצמכם. בנינו את Refly, מערכת חשבוניות וקבלות לעסקים קטנים בישראל שנמצאת בפרודקשן, ולכן אנחנו מכירים את המחיר של לבנות את השכבה הזו מאפס. עבור רוב מוצרי ה-SaaS, השעות האלה שוות יותר בפיצ'רים שהלקוחות שלכם באמת קונים. השיקולים הכלליים מופיעים במאמר על מערכת בהתאמה אישית מול מוצר מדף.
איפה זה פוגש סליקה, מנויים ותרומות
הקצאת מספר היא החוליה האחרונה בשרשרת חיוב. במוצר שגובה כרטיס אשראי, הסדר הנכון הוא חיוב מוצלח, יצירת חשבונית מס קבלה, בקשת הקצאה, ורק אז שליחה ללקוח. אם החיוב נעשה בהוראת קבע חודשית, כל חיוב חודשי הוא חשבונית נפרדת, ובמנוי B2B מעל הסף כל אחת צריכה מספר. על בחירת ספק הסליקה וחיבור ה-webhooks שלו כתבנו במדריך לבחירת ממשק API סליקה.
עמותות עובדות במודל מקביל אבל שונה: מ-1 בינואר 2026 קבלות על תרומות מדווחות למערכת תרומות ישראל, והמערכת מקצה להן מספר דיווח. פירטנו את זה במאמר על מערכת לניהול תרומות. ואם המוצר נמכר דרך אפליקציה, שווה לקרוא גם על תשלומים באפליקציה, עמלות החנויות ומע"מ.
זה לא ייעוץ משפטי או חשבונאי. הסיווג של מסמכים, הטיפול בעוסק המדווח על בסיס מזומן ושאלות של דיווח מפורט צריכים להיסגר מול רואה החשבון של העסק.
מה עושים עכשיו
- אם יש לכם מערכת שמפיקה חשבוניות מס לעסקים ועדיין אין בה הקצאה: מאז 1 ביוני 2026 הלקוחות העסקיים שלכם לא יכולים לנכות מס תשומות על חשבוניות שלכם מעל 5,000 ש"ח לפני מע"מ. זה הדבר הראשון בתור.
- אם אתם רק מתחילים: החליטו קודם אם חשבוניות הן הליבה של המוצר. אם לא, חברו API של ספק חשבוניות ותתקדמו.
- אם אתם בונים חיבור ישיר: תור, invoice_id קבוע, טיפול מלא ב-460, מסך חלופות, יומן ביקורת והצפנת טוקנים. בלי כל השישה זה לא מוכן לפרודקשן.
אנחנו בונים מוצרי SaaS עם חיוב, חשבוניות ודיווח מובנים. MVP ממוקד מתחיל מ-4,000 ₪, ומוצר מלא מ-60,000 ₪. אפשר לקבל הערכה ראשונית במחשבון העלויות, או לדבר איתנו על האינטגרציה הספציפית שלכם.
מקורות
- רשות המסים: מודל חשבוניות ישראל, תיאור ה-API's, מהדורה 2.0 (7.2024)
- רשות המסים: הנחיות לשירותי API ליצרני תוכנות, מהדורה 1.0 (6.2023)
- רשות המסים: היערכות למודל חשבוניות ישראל, מכתב לציבור המייצגים (11.9.2023)
- מבקר המדינה: היבטים בתפעול מערכת חשבוניות ישראל ברשות המיסים (יוני 2026)
המאמר נערך על ידי אביתר אדלר, CTO ב-FlowDev.
