מה השתנה ב-1 בינואר 2026
מערכת תרומות ישראל פעלה עוד קודם, אבל מ-1 בינואר 2026, לפי דף השירות של רשות המסים, כל מוסדות הציבור בעלי אישור לפי סעיף 46 לפקודת מס הכנסה נדרשים לדווח על כל התרומות שקיבלו באמצעות מערכת תרומות ישראל. זה כולל ביטולי תרומות, ואין סכום מינימלי.
הדיווח נעשה באחת משתי דרכים:
- אוטומטית מתוך התוכנה שבה מופקת הקבלה, אם היא מחוברת לשירות ה-API של רשות המסים. הדיווח קורה בזמן הפקת הקבלה, ומספר הדיווח מודפס עליה.
- ידנית באזור האישי באתר רשות המסים, למי שמשתמש בפנקס קבלות או בתוכנה שלא מחוברת. כל קבלה מוקלדת בנפרד.
מה יוצא לתורמים מזה: הקבלות מרוכזות באזור האישי שלהם באתר רשות המסים, והמידע מתעדכן גם במערכות של תיאום מס, דוחות שנתיים ודוחות להחזר מס. כלומר תורם לא צריך לשמור קבלת נייר כדי לממש את הזיכוי. עמותה שהקבלות שלה מדווחות בזמן היא עמותה שהתורמים שלה מקבלים את ההטבה בלי מאמץ, וזה שיקול גיוס לא פחות משיקול רגולטורי.
מה המערכת חייבת לדעת לעשות לפי ההנחיות
רשות המסים פרסמה לבתי תוכנה מפרט API ל"מודל התרומות" (מהדורה 0.4, דצמבר 2025). אם אתם בוחרים מערכת או בונים אחת, אלה הדרישות שהיא צריכה לממש. אם הספק שלכם לא יודע לענות על כל אחת מהן, זה סימן.
מספר דיווח על כל קבלה
כל קבלה בגין תרומה נשלחת לשירות עם מזהה ייחודי (DONATION_ID), ובתמורה מתקבל מספר דיווח. המערכת שומרת אותו ברשומת הקבלה, מדפיסה אותו על הקבלה בנוסף למספר האסמכתא הפנימי, ומדפיסה בצורה בולטת את המילים "פרטי התרומה דווחו לרשות המסים". המפרט קובע שהאחריות לוודא שכל קבלה נקלטה בסוף, גם אחרי שגיאה, היא על בית התוכנה, וגם שצריך להתריע למשתמש כשהטוקן פג או כשיש בעיית הרשאה.
זיהוי התורם
| סוג תורם | מה מדווחים | הערה |
|---|---|---|
| יחיד | מספר ת.ז. ושם כפי שמופיע על הקבלה | התרומה תופיע באזור האישי של התורם |
| חברה | ח.פ. ושם החברה | |
| עמותה או מוסד כספי | מספר ישות ושם | |
| בעילום שם, או עם שם בלי ת.ז. | מספר ישות 999999999 | אנונימית לגמרי: אין זיכוי. עם שם מלא בלי ת.ז.: אפשר לשייך בדיעבד לתורם |
| תושב חוץ | מספר ישות 888888888 | דרכון וקוד מדינה מוגדרים לשימוש עתידי |
מסקנה מעשית לדף התרומה: שדה ת.ז. צריך להיות בולט ומוסבר ("כדי שהזיכוי ממס יופיע אצלכם אוטומטית"), עם בדיקת ספרת ביקורת בצד הלקוח. כל תרומה בלי ת.ז. היא תורם שיצטרך לטפל בזה בעצמו.
אמצעי תשלום ופיצול קבלות
- תרומה בכמה סוגי אמצעי תשלום: קבלה נפרדת לכל סוג.
- תשלום ביותר מכרטיס אשראי אחד: קבלה נפרדת לכל כרטיס.
- הוראת קבע או הוראה לחיוב חשבון: הקבלות מופקות בשנת המס שבה בוצע התשלום.
- צ'קים דחויים: קבלות נפרדות לפי שנת המס של תאריך הפירעון. תאריך המסמך הוא התאריך שבו התקבלו הצ'קים.
- מטבע זר: מדווחים גם את הסכום במטבע הזר ואת קוד המטבע, בנוסף לסכום בשקלים.
- שווה כסף: גם תרומה שאינה כסף מקבלת קבלה, עם סוג אמצעי תשלום ייעודי.
ביטולים
אי אפשר "לתקן" קבלה. כל ביטול הוא מסמך נוסף מסוג ביטול קבלה, שמדווח גם הוא ונושא את מספר הדיווח של הקבלה המקורית. טעות בשם התורם או בת.ז. מטופלת בביטול מלא של הקבלה והפקת קבלה חדשה, ואם התיקון נעשה באיחור, תאריך המסמך של שתיהן נשאר התאריך המקורי כדי שהתרומה תיוחס לשנה הנכונה. המפרט מתיר גם ביטול חלקי במקרה של החזר כספי חלקי, למשל צ'ק אחד מתוך שלושה שהוחזר לתורם.
דיווח רטרואקטיבי
לפי המפרט, אפשר לדווח בדיעבד על תרומות עם תאריך אסמכתא מ-1 בינואר 2025, ועל ביטולים מ-1 בינואר 2024. אי אפשר לדווח תרומה עם תאריך עתידי. בדיווח רטרואקטיבי צריך לוודא שאישור סעיף 46 של העמותה היה בתוקף בתאריכים שעל הקבלות. המפרט כולל גם שירות API לבדיקת תוקף אישור סעיף 46 של עמותה, ששימושי למערכת שמשרתת כמה עמותות.
הרכיבים של מערכת תרומות טובה
הדיווח הוא החלק החובה. מה שקובע כמה כסף העמותה מגייסת הוא כל השאר.
דף תרומה
דף קצר, מהיר במובייל, עם סכומים מוצעים, בחירה בין חד-פעמי לחודשי, ות.ז. כשדה מוסבר. התשלום עצמו עובר בדף התשלום או ב-iframe של ספק הסליקה, כדי שהעמותה לא תחזיק פרטי כרטיסים. חלק מספקי הסליקה הישראליים מציעים דפי תרומה מוכנים, כולל ביט. אם יש לכם אפליקציה, לחנויות יש כללים ספציפיים לגביית תרומות בתוכה, ושווה לבדוק אותם לפני העיצוב. את התמונה הכללית פירטנו במאמר על תשלומים באפליקציה.
תרומות חודשיות: טוקן או מס"ב
תורם חודשי שווה לעמותה הרבה יותר מתורם חד-פעמי, ולכן זה הרכיב שהכי שווה להשקיע בו. שתי אפשרויות:
- הוראת קבע באשראי מבוססת טוקן: נרשמים בדף התרומה בשנייה, אבל כרטיסים פגים ומוחלפים, וצריך מנגנון ניסיון חוזר והתראה לתורם.
- הוראה לחיוב חשבון דרך מס"ב: הקמה איטית יותר עם הרשאה חתומה, אבל לא תלויה בתוקף כרטיס.
בכל חיוב חודשי מופקת קבלה בשנת המס של התשלום ומדווחת לתרומות ישראל. מערכת שמפיקה את הקבלות האלה בלי מגע יד היא ההבדל בין עמותה שמגייסת לבין עמותה שמקלידה. את ההשוואה בין ספקי סליקה מבחינת טוקנים, הוראות קבע ו-webhooks עשינו במדריך לבחירת ממשק API סליקה.
ניהול תורמים (CRM)
- היסטוריית תרומות לכל תורם, כולל חודשיות שנכשלו או בוטלו.
- פילוח לפי קמפיין, מקור הגעה וסכום.
- התראה על הוראת קבע שנכשלה, כדי שמישהו ירים טלפון לפני שהתורם נעלם.
- הפקת קבלה מחדש לתורם ששאל, בלחיצה.
זכרו שמאגר תורמים עם מספרי ת.ז. ופרטי תשלום הוא מאגר מידע אישי שצריך להגן עליו. הרשאות לפי תפקיד ויומן גישה הם לא מותרות. כתבנו על החובות במאמר על חוק הגנת הפרטיות.
חמש טעויות שכדאי לתפוס לפני שהן מגיעות לתורם
- קבלה אחת לתרומה מעורבת. תורם ששילם 500 ש"ח באשראי ו-500 ש"ח בהעברה בנקאית צריך שתי קבלות. מערכת שמאפשרת קבלה אחת עם שני אמצעי תשלום מייצרת דיווח שגוי.
- עריכה במקום ביטול. מישהו בעמותה מתקן שם או ת.ז. ישירות ברשומה, אחרי שהקבלה כבר דווחה. רשות המסים נשארת עם הנתון הישן, והתורם לא רואה את התרומה. הדרך היחידה היא ביטול קבלה וקבלה חדשה.
- ת.ז. כשדה רשות שאף אחד לא ממלא. התוצאה היא קבלות שמדווחות כתרומה בלי מספר זהות, שלא מגיעות לאזור האישי של התורם. אחר כך מגיעות שיחות טלפון בתקופת הדוחות השנתיים.
- "נדווח בסוף החודש". דיווח ידני מצטבר נוטה להתעכב, ובינתיים התורמים לא רואים את התרומות. אם יש יותר מכמה קבלות בשבוע, זה הסימן לעבור לתוכנה מחוברת.
- טוקן שפג בשקט. החיבור לרשות המסים פג, הקבלות ממשיכות לצאת, והדיווחים נתקעים בתור. המפרט מחייב להתריע למשתמש במצב כזה, ושווה לבדוק שהמערכת שלכם באמת עושה את זה.
מערכת מדף או פיתוח: טבלת החלטה
| המצב שלכם | מה מתאים | למה |
|---|---|---|
| עמותה קטנה, תרומות בודדות בחודש | דיווח ידני באזור האישי או מערכת קבלות פשוטה | העלות של כל מערכת גבוהה מהזמן שהיא חוסכת |
| עמותה עם עשרות עד מאות תרומות בחודש | מערכת מדף שמחוברת לתרומות ישראל, עם דף תרומה והוראות קבע | הדיווח, הקבלות והגבייה החוזרת פתורים, ואין מה להמציא |
| ארגון עם כמה עמותות או מוסדות תחת אותה הנהלה | מערכת מדף שתומכת בריבוי ישויות, או שכבת ניהול מותאמת מעליה | כל ישות מדווחת בנפרד עם האישור וההרשאות שלה |
| תרומות הן חלק מפלטפורמה רחבה (אפליקציה לקהילה, מערכת למוסד חינוכי, אירועים וכרטיסים) | פיתוח מותאם, עם ספק קבלות וסליקה קיים מתחת | החוויה היא המוצר, אבל אין סיבה לבנות מחדש דיווח וקבלות |
| אתם בונים מוצר לעמותות כ-SaaS | חיבור ישיר ל-API של רשות המסים | הדיווח הוא חלק מהליבה של המוצר שלכם, והלקוחות מצפים לו |
השאלה הכללית של מדף מול פיתוח מופיעה במאמר על מערכת בהתאמה אישית מול מוצר מדף, וההיגיון שם תקף גם כאן. ההבדל היחיד: בתרומות, הדיווח הוא דרישה ולא פיצ'ר, אז כל מערכת שאתם שוקלים, מדף או מותאמת, נבדקת קודם כול עליו.
אם בונים: מה לקחת בחשבון
השירות עובד ב-OAuth2, וכל עמותה צריכה להירשם לשירותים הדיגיטליים של רשות המסים ולהגדיר מורשה. במערכת שמשרתת כמה עמותות אתם מחזיקים טוקן לכל אחת, ואותם עקרונות של תור, מזהה ייחודי קבוע לכל קבלה ויומן ביקורת שתיארנו במאמר על API חשבוניות ישראל חלים גם כאן. מסמך המפרט עצמו מסומן כמהדורה 0.4 ושירותים בו בסטטוס beta, אז תכננו לעדכונים.
בנינו את Refly, מערכת חשבוניות וקבלות לעסקים קטנים בישראל שנמצאת בפרודקשן, ולכן אנחנו יודעים כמה מהעבודה במסמכים פיננסיים נמצאת במקרי הקצה: ביטולים, שנים חוצות וטעויות הקלדה. זה המקום לחסוך בו בעזרת ספק קיים, אלא אם זה בדיוק המוצר שלכם.
מה עושים עכשיו
- בדקו שהעמותה רשומה לשירותים הדיגיטליים של רשות המסים ושהוגדר מורשה על. בלי זה אי אפשר לדווח, לא ידנית ולא דרך תוכנה.
- שאלו את ספק הקבלות הנוכחי שלכם אם הוא מחובר לתרומות ישראל, ובקשו לראות קבלה עם מספר הדיווח והכיתוב "פרטי התרומה דווחו לרשות המסים".
- אם יש קבלות מ-2026 שלא דווחו, טפלו בהן עכשיו. המפרט מאפשר דיווח בדיעבד על תרומות מ-1 בינואר 2025.
- הוסיפו שדה ת.ז. מוסבר לדף התרומה, ובדקו שההוראות החודשיות מפיקות קבלה ומדווחות בכל חיוב.
זה לא ייעוץ משפטי או חשבונאי. סוגיות כמו אישור סעיף 46, שווה כסף וביטולים בין שנים צריכות להיסגר מול רואה החשבון של העמותה.
אם אתם בונים פלטפורמה שכוללת תרומות, או מוצר לעמותות, זה חלק מהעבודה שלנו בפיתוח SaaS. אפשר לקבל הערכה ראשונית במחשבון העלויות, או לדבר איתנו ישירות.
מקורות
- רשות המסים: דיווח של מוסד ציבורי בעל אישור לפי סעיף 46 על קבלת תרומה (עודכן 01.02.2026)
- רשות המסים: מודל תרומות, תיאור ה-API's, מהדורה 0.4 (12.2025)
- רשות המסים: הנחיות לשירותי API ליצרני תוכנות, מהדורה 1.0 (6.2023)
המאמר נערך על ידי אביתר אדלר, CTO ב-FlowDev.


