מו״פ של צדדים קשורים במסגרת IP Box בקפריסין

זהו את הסדר הפיתוח בפועל

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

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

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

דוגמה לפיתוח בתוך קבוצה

נניח שלמבקש ההטבה יש €300,000 הוצאות מזכות ו־€200,000 מו״פ מצד קשור על נכס אחד, ללא עלות רכישה. ההוצאה הכוללת היא €500,000. התוספת היא הנמוך מבין €90,000, שהם 30% מ־QE, לבין €200,000 של הצד הקשור. לכן nexus הוא €390,000 חלקי €500,000, כלומר 78%.

על הכנסה שנתית נטו מ־IP של €400,000, הרווח המזכה הוא €312,000. ניכוי 80% הוא €249,600, ומשאיר €150,400 חייבים בדוגמה הפשוטה. בשיעור 15%, המס הוא €22,560, שהם 5.64% מההכנסה נטו מ־IP לפני התאמות נוספות.

עלות הצד הקשור לא פסלה אוטומטית את הנכס, אך דוגמת ה־3% עם nexus מלא כבר אינה מתארת את המקרה. התוספת גם אינה מכסה את כל €200,000: יש חשיבות לתקרה הנפרדת של 30% מ־QE.

מחירי העברה ו־nexus הם בדיקות שונות

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

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

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

מה צריך להראות התיק התומך

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

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

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

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

אל תשנו מבנה רק סביב היחס

שינוי מודל הפיתוח עשוי להשפיע על העסקה, שליטה תפעולית, מחירי העברה ומס בכמה מדינות. השוו השלכות אלה להטבת IP Box הצפויה. העברת חשבונית בלי שינוי ההסדר האמיתי עלולה ליצור יותר אי־ודאות.

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