אוטומציה של דיווח מפורט למע"מ: מה אפשר לאטמט ומה לא

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

קודם כול: מה לא נקבע כאן

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

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

• הפרסום של רשות המסים עצמה - עמוד השירות "הגשת דיווח מפורט למע"מ" וההודעות לעוסקים באתר gov.il.
• רואה החשבון או יועץ המס שלך, שיודע מה חל על העסק הספציפי.

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

למה זה קשה יותר מייצוא

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

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

הצד הקל: מה שהוצאת

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

שתי נקודות שכן שוברות גם כאן:

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

הצד הקשה: מה שקיבלת

כאן נמצא רוב המאמץ, ורוב הפרויקטים מזלזלים בו.

1. החשבוניות מגיעות כתמונות

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

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

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

2. מספר העוסק הוא המפתח - לא השם

זו הנקודה הטכנית החשובה ביותר במאמר.

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

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

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

3. חשבונית שהגיעה אחרי שדיווחת

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

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

ארבעת הכללים ההנדסיים

1. מפתח ייחודי לכל דיווח: תקופה + עוסק. אם התהליך רץ פעמיים, הוא לא מייצר שני דוחות. אותה עקביות שנדרשת בכל תהליך פיננסי.
2. לשמור את הקובץ שהוגש בפועל. לא לייצר אותו מחדש כשמישהו שואל. הראיה למה שהוגש היא הקובץ, לא היכולת לשחזר אותו.
3. לרשום כל כשל, לא רק הצלחות. חשבונית שלא נקלטה בגלל שדה חסר חייבת להופיע ברשימה שמישהו רואה - לא בקובץ יומן.
4. בדיקת התאמה לפני ההגשה. סך המע"מ בקובץ מול סך המע"מ בספרים. אם יש פער - עוצרים. זו בדיקה של שנייה שמונעת דיווח שגוי.

יש API רשמי - וזה מה שהוא מכסה

כן, קיים. רשות המסים מפרסמת מסמך בשם "Tax Authority Open API" בעמוד השירות "קישור לשע"ם", וברשימת השירותים שמוצעים דרך ה-API מופיע במפורש דיווח ותשלום תקופתי למע"מ.

לצידו מופיעים באותה רשימה:

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

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

מי יכול להתחבר, ומה זה אומר עליך

עמוד השירות מגדיר שלושה קהלי יעד, וההבחנה ביניהם היא כל התשובה:

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

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

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

איך החיבור עובד בפועל

המסמך הרשמי מתאר את התהליך במלואו. בקצרה, וכדי שתדע מה מחכה לך:

1. רישום בית התוכנה במערכת הרישום של הרשות, ואישור בדוא"ל.
2. פורטל מפתחים - יוצרים ארגון (Organization). כל ארגון דורש בקשת רישום משלו ומנהל משלו, ומזמינים מפתחים בקישור.
3. יוצרים אפליקציה ומקבלים Client ID ו-Client Secret. הסוד אינו ניתן לשחזור - רק להפקה מחדש, ולכן שומרים אותו בנפרד ובאופן מאובטח.
4. רושמים את האפליקציה לשירות הספציפי. אי אפשר לייצר טוקן לשירות שלא נרשמת אליו.
5. Sandbox קודם, ורק אחר כך Client ID לסביבת ייצור - לאחר אישור.

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

האימות הוא OAuth2 בשני שלבים: קריאת authorize בדפדפן שמחזירה קוד הזדהות בכתובת, ואז בקשת token מהשרת עם ה-Client ID וה-Secret. בתשובה מתקבלים access_token מסוג Bearer, expires_in, ו-refresh_token.

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

מה זה מחייב בתכנון

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

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

מה נשאר אצל אדם

גם כששידור אוטומטי זמין לך, שלושה דברים לא עוברים לקוד:

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

הניסוח המדויק: ההכנה מתאטמטת במלואה; השידור תלוי במסלול הגישה שלך; האחריות על מה שמוגש נשארת אנושית. וההכנה היא ממילא מה שלוקח ימים.

מה שהאוטומציה באמת נותנת

שווה להיות מדויק בציפייה:

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

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

לפני שמתחילים

1. לברר מה חל עליך - מרשות המסים ומרואה החשבון. לא ממאמר.
2. לבדוק מה מערכת החשבוניות שלך כבר עושה. חלק מהמערכות כבר מפיקות את הקובץ, וחלקן גם משדרות אותו - שווה לבדוק לפני שבונים.
3. למפות מאיפה מגיעות חשבוניות ספקים. זה החצי הקשה, וזה קובע את התקציב.
4. לנרמל מספרי עוסק לפני הכול.
5. לתכנן את החריגים - חשבונית מאוחרת, סכום שלא זוהה, ספק חדש.

והשאלה שקודמת לכול: למערכות שצריך לחבר יש ממשק? בלי זה, הפרויקט הוא לא פרויקט דיווח - הוא פרויקט חיבור.