הנפקת חשבוניות ללקוחות בחו"ל: מדריך מעשי למטבע, מס וכתובת

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

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

מטבע: חשבונית אחת, מטבע אחד, בלי לנחש

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

ב-InvoiceFlow, ניתן להנפיק כל חשבונית במטבע משלה, עם פורמט נכון. החלק האחרון הזה חשוב יותר משנדמה. "פורמט נכון" פירושו שסמל המטבע, מיקומו ביחס למספר, מפריד האלפים ומפריד העשרוני — כולם תואמים את המוסכמה של אותו מטבע. ‎€1.234,56‎ ו-‎$1,234.56‎ הם אותו סכום הכתוב בשתי דרכים שונות לחלוטין, וטעות בכך היא בדיוק סוג הסימן הקטן שגורם למחלקת כספים להרים גבה.

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

מה האפליקציה עושה — ומה לא

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

זו תכונה, לא חיסרון, והיא משקפת את האופן שבו חיוב חוצה-גבולות באמת עובד. אם תמחרתם פרויקט ללקוח ממינכן ב-‎€2,000‎, אתם מנפיקים חשבונית על ‎€2,000‎ — נקודה. אין המרה לבצע; זה המחיר במטבע שלו. ניהול הספרים שלכם בארץ המוצא, שבו אתם רושמים כמה היו ‎€2,000‎ במטבע המקומי שלכם ביום שבו נפרעו, הוא תרגיל נפרד המתרחש אחרי התשלום, לפי השער שהבנק שלכם באמת נתן. ערבוב בין השניים — הנפקת חשבונית במטבע אחד אך חשיבה בסתר במטבע אחר — שם פרילנסרים מסתבכים.

אז זרימת העבודה נקייה:

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

אם בכל זאת תרצו להציג ללקוח המרת נימוס ("בערך ‎$2,150‎ לפי השער היום"), הוסיפו זאת בהערות החשבונית כשורת טקסט, מסומנת בבירור כאינדיקטיבית. הסכום המחויב נשאר במטבע הלקוח.

מס: כולל, לא כולל, מספר שיעורים, ונטו-לפני-מס

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

כולל לעומת לא כולל — בחרו את מה שהלקוח מצפה לו

InvoiceFlow תומכת בתמחור כולל מס וגם לא כולל מס, והבחירה אינה קוסמטית — היא משנה איזה מספר הלקוח קורא בתור "המחיר".

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

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

מספר שיעורים על חשבונית אחת

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

נטו-לפני-מס וסכום לתשלום

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

הערה מעשית אחת על מס חוצה-גבולות שאף אפליקציה לא יכולה להחליט במקומכם: האם בכלל לגבות מס על מכירה לחו"ל היא שאלה משפטית, לא הגדרה באפליקציה. כללי חיוב-עצמי (reverse-charge), אפס-מס לייצוא, מבחני מקום-האספקה — אלה תלויים בתחום השיפוט שלכם, בזה של הלקוח, ובמה שאתם מוכרים. האפליקציה תציג בנאמנות כל טיפול מס שתורו לה. לדעת את הטיפול הנכון זו עבודתכם (או של רואה החשבון שלכם). החליטו את הכלל ראשון; הגדירו את החשבונית שני.

שפה פר-חשבונית: הדפיסו בשפת הלקוח

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

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

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

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

כתובות: 199 מדינות, והשדות באמת מתאימים

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

שדות הכתובת של InvoiceFlow מותאמים למדינה ב-199 מדינות. שני דברים קורים כשאתם בוחרים את מדינת הלקוח:

• תוויות האזור והמיקוד מסתגלות. מה שהוא "ZIP code" בארה"ב הוא "Postal code" בקנדה, "Postcode" בבריטניה, ו-"PIN code" בהודו. השדה מסומן בדרך שבה אותה מדינה מסמנת אותו, כך שהכתובת נקראת באופן טבעי עבור הנמען ועבור צוות הכספים שלו.
• מדינות מסוימות מסתירות אזור ומיקוד לחלוטין. מספר מדינות אינן משתמשות בשורת מדינה/אזור או במיקוד באופן שבו אחרות משתמשות. כפיית שדה "מדינה" ריק על כתובת מאחת מאותן מדינות פשוט נראית כאילו אינכם מכירים את המדינה. הטופס משמיט את השדות שאינם רלוונטיים.

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

מחברים את הכול: מדריך מעובד

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

1. הגדירו כל לקוח פעם אחת. עבור כל אחד, קבעו את מטבע ברירת המחדל, את שפת החשבונית המועדפת ואת המדינה (שקובעת את תוויות הכתובת). מינכן: EUR, גרמנית, גרמניה. טורונטו: CAD, אנגלית, קנדה. טוקיו: JPY, יפנית, יפן.
2. החליטו על טיפול המס פר לקוח עם רואה החשבון שלכם, ואז הגדירו אותו. חשבונית מינכן היא לא-כוללת-מס עם שורת מע"מ; האחרות לפי הכללים שלכם עבור אותן מכירות.
3. צרו את החשבונית. היא נפתחת במטבע הנכון. אתם מזינים שורות פריטים באותו מטבע — המספרים שבאמת סיכמתם, לא מומרים תוך כדי תנועה.
4. תנו לאפליקציה לבצע את הסכומים. נטו-לפני-מס, מס לפי שיעור, וסכום לתשלום — כולם מתחשבים נכון.
5. הפיקו את ה-PDF. הוא מודפס בשפת הלקוח, מעצב את המטבע נכון, ומציג את הכתובת עם התוויות הנכונות — גם אם שפת הלקוח היא בכתב שאינו לטיני.
6. עקבו והתאימו. אתם עוקבים אחר היתרה במטבע החשבונית; משסולקה, אתם רושמים את הסכום האמיתי במטבע ארץ המוצא מהבנק שלכם בספרים שלכם.

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

הפרטים הקטנים שמצטברים

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

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