שלוש הדרכים לקבל את שיעור ניכוי המס במקור של ספק - שאילתה ידנית, מערכת 1000 ומערכת מבזק - ואיך מחברים אותן לשער בדיקה אוטומטי בתוך תהליך התשלום שלכם.
עיקרי הדברים
- הבדיקה נעשית לפי מועד התשלום, ולא לפי מועד קבלת החשבונית.
- שאילתה בודדת מתבצעת באתר רשות המסים לפי מספר תיק או מזהה של המשלם.
- מערכת 1000 מיועדת לגופים עם היקף ספקים בינוני ומחזירה נתונים לכל הספקים בקובץ אחד.
- לפי חומרי הספקים, התשובה כוללת את שיעור הניכוי לכל ספק ואת מצב אישור ניהול הספרים.
- אין ממשק API ציבורי מתועד לבדיקה בזמן אמת, ולכן האוטומציה נבנית סביב קליטת קובץ.
הנתון שצריך לפני תשלום הוא שיעור הניכוי התקף של הספק במועד התשלום, לצד מצב אישור ניהול הספרים שלו. רשות המסים מספקת אותו בשלוש דרכים - שאילתה מקוונת בודדת, קליטת קובץ במערכת 1000, ומערכת מבזק לגופים גדולים. ההבדל ביניהן הוא נפח, לא תוכן.
מה בדיוק בודקים לפני שמשלמים
לא "האם לספק יש אישור" כשאלה בינארית, אלא שלושה נתונים נפרדים:
- שיעור הניכוי התקף לספק - אחוז או פטור.
- טווח התוקף של האישור, כי אישור שהיה תקף כשהחשבונית אושרה יכול לפוג לפני שהתשלום יוצא.
- מצב אישור ניהול ספרים, שהוא נתון נפרד ומגיע יחד עם הראשון.
שלושת הנתונים מגיעים יחד מאותו מקור, ולכן אין טעם לשמור רק את הראשון. מערכת שמחזיקה אחוז בלי תאריכים לא יודעת לענות על השאלה החשובה באמת, שהיא לא "כמה" אלא "האם זה עדיין תקף להיום".
זה גם מסביר למה בדיקה חד-פעמית בפתיחת כרטיס ספק לא מספיקה. הנתון הוא נתון עם תאריכי תוקף, ולכן הוא צריך לשבת בכרטיס עם התאריכים שלו, לא כדגל של כן או לא.
שלוש הדרכים לקבל את הנתון
| הדרך | למי היא מתאימה | איך הנתון מגיע |
|---|---|---|
| שאילתה מקוונת | בדיקה נקודתית של ספק בודד | מסך באתר רשות המסים, אפשר להפיק אישור להדפסה |
| מערכת 1000 | גופים עם היקף ספקים בינוני | שולחים קובץ ספקים ומקבלים קובץ תשובה |
| מערכת מבזק | גופים גדולים מעל הסף של מערכת 1000 | קליטת קובץ בתיאום מול הרשות |
לפי תיעוד של ספקי תוכנה, בקליטת קובץ במערכת 1000 חוזרים שני קבצים: קובץ של רשומות תקינות עם אחוז הניכוי ואישור ניהול הספרים לכל ספק, וקובץ של רשומות שגויות עם תיאור השגיאה. אותם מקורות מציינים כי מאוגוסט 2019 המערכת מיועדת לגופים עם עד 3,000 ספקים. את הסף המדויק ואת כללי ההצטרפות יש לאמת מול דף השירות של רשות המסים, כי הם השתנו.
האם יש API לבדיקת אישור ניכוי מס במקור?
לא כממשק ציבורי מתועד שכל מפתח יכול לצרוך. מה שקיים הוא שאילתה במסך ומנגנוני קליטת קובץ. המשמעות המעשית לתכנון: אל תתכננו קריאה סינכרונית ברגע הלחיצה על "שלם". תכננו מחזור עדכון - קובץ שנשלח ונקלט בקצב קבוע - ובדיקה מקומית מול הנתונים שנקלטו בזמן התשלום.
בפועל זה גם עדיף. שער שתלוי בשירות חיצוני זמין נופל יחד איתו, בעוד בדיקה מול נתון מקומי עם תאריך תוקף ממשיכה לעבוד ויודעת לומר "הנתון ישן משבעה ימים" במקום להיכשל בשקט.
מה שומרים בכרטיס הספק
- שיעור הניכוי כפי שהתקבל, כמספר ולא כטקסט חופשי.
- תאריך תחילת התוקף ותאריך סיום התוקף.
- מצב אישור ניהול הספרים.
- מועד העדכון האחרון ומקורו - קובץ מערכת 1000, שאילתה ידנית, או מסמך שהספק שלח.
- מזהה הספק שנשלח בקובץ, כדי שאפשר יהיה להתאים את רשומת התשובה חזרה.
השדה האחרון הוא זה שמונע את התקלה הנפוצה ביותר בקליטה חוזרת: קובץ תשובה שלא ניתן לשייך בוודאות לספק, כי המזהה ששלחתם והמזהה שחזר אינם אותו שדה.
איך זה נכנס לתהליך התשלום
- חשבונית מאושרת ונכנסת למועמדות לתשלום.
- לפני בניית מנת התשלום, המערכת בודקת לכל ספק אם הנתון קיים ובתוקף לתאריך התשלום המתוכנן.
- ספק עם נתון בתוקף עובר. ספק בלי נתון או עם נתון שפג מסומן לטיפול.
- מנת התשלום נבנית עם השיעור שהיה בתוקף באותו רגע, והשיעור נשמר על התנועה.
- אחרי הביצוע, השיעור והמקור נשארים על התשלום כתיעוד.
הצעד הרביעי הוא מה שהופך את זה לניתן לביקורת: לא "מה השיעור של הספק היום" אלא "מה היה השיעור כשהתשלום יצא". בהמשך השרשרת, מנת התשלום עצמה עוברת לקובץ מס"ב, ותהליך האישור המלא מתואר במאישור חשבונית ספק ועד קובץ מס"ב.
מה קורה כשהאישור פג בין האישור לתשלום?
זה בדיוק המקרה שבגללו הבדיקה יושבת לפני התשלום ולא בקליטת החשבונית. חשבונית שאושרה בתחילת החודש יכולה לצאת לתשלום שבועות אחר כך, ובינתיים חלף תאריך התוקף.
מערכת שמחזיקה תאריכי תוקף יכולה לזהות את זה מראש: היא יודעת אילו אישורים פגים בתוך שלושים יום ואילו ספקים מתוכננים לתשלום בחלון הזה. זו רשימה שאפשר להפיק לפני שהיא הופכת לבעיה, בדומה לבדיקות ספק אחרות שמתוארות באימות ספקים אוטומטי בישראל.
מה עולה כשמחברים את זה למערכת קיימת
ההתנגשות הראשונה היא כמעט תמיד מזהה. הקובץ שנשלח בנוי סביב מספר התיק או המזהה של הספק כפי שהרשות מכירה אותו, בעוד שמערכת הרכש מזהה ספק לפי מפתח פנימי משלה. אם אין שדה שמחבר ביניהם, קובץ התשובה מגיע ואי אפשר לקלוט אותו.
שלוש ההחלטות שצריך לקבל לפני הפיתוח, ורצוי בכתב:
- איזה שדה במערכת מחזיק את המזהה שנשלח, ומי אחראי על נכונותו.
- מה עושים עם רשומה שחזרה בקובץ השגויות - האם היא חוסמת את הספק לתשלום או רק מסומנת.
- מי מקבל את רשימת האישורים שעומדים לפוג, ובאיזה קצב.
בלי השלישית, המנגנון עובד ואף אחד לא פועל לפיו. זו אותה נקודה שמתוארת ברשימת בדיקות לפני אינטגרציה: לא מי כותב את הקוד, אלא מי מקבל את ההתראה.
הקשר לדיווח השנתי
מה שנוכה בפועל מתשלומים לספקים לאורך השנה הוא הבסיס לדיווח השנתי על ניכויים. אם השיעור נשמר על כל תנועת תשלום יחד עם מקור הנתון, ההפקה היא שאילתה. אם השיעור הוחל ידנית ולא נשמר, מדובר בשחזור מסמכים בסוף השנה. איך בונים את זה מהנתונים של התשלומים מתואר בהפקת טופס 856 מנתוני התשלומים.
זהו תיאור טכני של מקורות נתונים ותהליך, ואינו ייעוץ מס. חובות הניכוי, השיעורים והמועדים החלים על תשלום מסוים נקבעים מול רואה החשבון ומול המקור הרשמי.
מקורות
שאלות נפוצות
כל כמה זמן צריך לרענן את הנתון?
אין תשובה טכנית אחת, כי זה תלוי בתדירות התשלומים ובהיקף הספקים. הכלל המעשי הוא שהנתון צריך להיות תקף לתאריך התשלום המתוכנן, ולכן מחזור העדכון נגזר ממחזור התשלומים שלכם ולא להפך.
מה עושים עם ספק שאין לו נתון בכלל?
מסמנים אותו לטיפול ולא מעבירים אותו אוטומטית. מה לעשות בפועל כשאין אישור בתוקף היא שאלה עם משמעות מיסויית, ולכן הכלל צריך להיקבע מול רואה החשבון ולהיות מוטמע כהחלטה מוגדרת במערכת, לא כשיקול דעת של מי שמריץ את התשלום.
אפשר לקחת את הנתון מהמסמך שהספק שלח?
אפשר לשמור אותו כמקור, אבל צריך לסמן אותו ככזה. מסמך שספק שלח בדוא"ל אינו זהה לנתון שהתקבל מהשאילתה או מקובץ התשובה, והבחנה בין המקורות בכרטיס הספק היא מה שמאפשר לדעת אחר כך על מה הסתמכתם.
למה לשמור את השיעור על התשלום ולא רק בכרטיס?
כי כרטיס הספק מתעדכן ומאבד את ההיסטוריה. השיעור על התנועה הוא מה שהיה בתוקף באותו רגע, וזה הנתון שנדרש בבדיקה מאוחרת ובדיווח השנתי. כרטיס מציג מצב נוכחי; תנועה מתעדת עובדה.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.