Cyprus IP Box: הסכם פיתוח תוכנה ורשימת בדיקה מעשית

ההסכם צריך לתאר את יחסי הפיתוח בפועל

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

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

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

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

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

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

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

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

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

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

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

קשרו כל תשלום לעבודה ולנכס

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

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

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

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

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

תעדו שליטה תפעולית, סיכונים ואחריות

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

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

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

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

רשימת בדיקה של סעיפים וראיות לפרויקט אמיתי

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

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

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

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

דוגמה: קוד חדש, כלים קיימים ושיפור מאוחר

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

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

נניח שהחשבונית הראשונה היא €90,000: סכום של €60,000 לפיתוח מקורי של הרכיב, €20,000 לרכישת קוד או זכויות קיימות ו-€10,000 ליישום אצל לקוח. זו הדגמה של הפרדת חיובים, לא סיווג מס אוטומטי. מה נחשב מחקר כשיר תלוי בעבודה ובעובדות המשפטיות; רכישה ויישום נבדקים בנפרד.

אם Studio A היא למעשה חברה קשורה בקבוצה ולא ספק עצמאי, אותם €60,000 אינם הופכים למחקר עצמי כשיר של CyprusCo רק מפני שהעבודה הוזמנה או שהמחיר הוא מחיר שוק. הקשר בין החברות משפיע על הנקסוס; תמחור העברה בוחן את התמורה. שינוי הכותרת ל״החזר שכר״ אינו משנה את העובדות.

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

שמרו על ההסכם והרישומים מעודכנים

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

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

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