विदेशी क्लाइंट्स को इनवॉइस करना: मुद्रा, टैक्स और पते की व्यावहारिक गाइड

जब आप पहली बार किसी विदेशी क्लाइंट को इनवॉइस भेजते हैं, तो समझ आता है कि "इनवॉइस भेजना" एक सरल काम नहीं है। बर्लिन का क्लाइंट यूरो चाहता है, दशमलव की जगह कॉमा, और टैक्स लाइन जो जर्मन शैली में लिखी हो। टोरंटो का क्लाइंट कैनेडियन डॉलर चाहता है और पोस्टल कोड के लिए एक फ़ील्ड जिस पर "Postal code" लिखा हो, "ZIP" नहीं। टोक्यो का क्लाइंट ऐसे दस्तावेज़ को नहीं पढ़ना चाहता जो पूरी तरह आपके देश की धारणाओं पर बना हो।

यह सब मुश्किल नहीं है। बस कुछ छोटी-छोटी बातें हैं जो, लापरवाही से छोड़ दी जाएं, तो आपको अनुभवहीन दिखाती हैं — और जो सोच-समझकर की जाएं, तो लगता है जैसे आप यह काम सैकड़ों बार कर चुके हों। यह लेख वह गाइड है: कैसे हर इनवॉइस सही मुद्रा में जारी करें, टैक्स कैसे दिखाएं ताकि क्लाइंट को संख्याएं सही लगें, PDF क्लाइंट की भाषा में कैसे प्रिंट करें, और 199 देशों में से किसी के लिए भी पता कैसे सही ढंग से लिखें। नीचे बताया गया तरीका InvoiceFlow में काम करता है, लेकिन ये सिद्धांत किसी भी अच्छे इनवॉइसिंग सिस्टम पर लागू होते हैं।

मुद्रा: एक इनवॉइस, एक मुद्रा, कोई अनुमान नहीं

अंतरराष्ट्रीय इनवॉइसिंग का सबसे बुनियादी नियम यह है कि इनवॉइस एक ही मुद्रा में होता है, और वह मुद्रा क्लाइंट की होती है, आपकी नहीं — जब तक कोई खास कारण न हो (कुछ अनुबंध बिलिंग मुद्रा USD या EUR तय करते हैं, चाहे क्लाइंट कहीं भी हो; ऐसे में अनुबंध का पालन करें)। एक जर्मन एजेंसी डॉलर में इनवॉइस पाकर खुद कन्वर्ज़न नहीं करना चाहती। अमेरिकी क्लाइंट पाउंड में कुल राशि देखकर सिर खुजाना नहीं चाहता। एक बार, हर क्लाइंट के लिए मुद्रा तय करें और उसी पर टिके रहें।

InvoiceFlow में हर इनवॉइस अपनी मुद्रा में जारी किया जा सकता है, सही फॉर्मेट के साथ। यह आखिरी बात उतनी मामूली नहीं जितनी लगती है। "सही फॉर्मेट" का मतलब है कि मुद्रा का चिन्ह, उसकी संख्या के सापेक्ष स्थिति, हजार का विभाजक और दशमलव विभाजक — सब उस मुद्रा के नियमानुसार हों। €1.234,56 और $1,234.56 एक ही राशि है, लेकिन दो बिल्कुल अलग तरीकों से लिखी गई — और गलत लिखना एक ऐसी चूक है जो वित्त विभाग का ध्यान खींच लेती है।

आप हर क्लाइंट के लिए डिफ़ॉल्ट मुद्रा उनकी सेटिंग में सेट कर सकते हैं, ताकि उस क्लाइंट का अगला इनवॉइस अपने आप सही मुद्रा में खुले। यह एक सेटिंग अंतरराष्ट्रीय इनवॉइसिंग की सबसे आम गलती खत्म कर देती है: यूरो क्लाइंट को आपकी होम करेंसी में इनवॉइस भेज देना क्योंकि ऐप ने वही डिफ़ॉल्ट रखा था।

ऐप क्या करता है — और क्या नहीं

यह ईमानदारी से समझना ज़रूरी है, क्योंकि इससे आपके काम करने का तरीका बदलता है। InvoiceFlow हर इनवॉइस को उसकी बताई गई मुद्रा में फॉर्मेट और ट्रैक करता है। यह अपने आप लाइव FX कन्वर्ज़न नहीं करता। आप ही राशि और जहां ज़रूरी हो, विनिमय दर तय करते हैं। ऐप भेजते समय चुपके से मिड-मार्केट रेट खींचकर आपके आंकड़े नहीं बदलता।

यह एक सुविधा है, कमी नहीं — और यह दर्शाता है कि अंतरराष्ट्रीय बिलिंग वास्तव में कैसे काम करती है। अगर आपने म्यूनिख के क्लाइंट को किसी प्रोजेक्ट के लिए €2,000 कोट किया है, तो आप €2,000 का इनवॉइस बनाते हैं — बस। कोई कन्वर्ज़न नहीं करना; वही उनकी मुद्रा में कीमत है। आपके घर पर बुककीपिंग — जहां आप यह दर्ज करते हैं कि जब पैसा आया तब €2,000 आपकी स्थानीय मुद्रा में कितने बने — वह एक अलग काम है जो भुगतान के बाद होता है, उस दर पर जो आपके बैंक ने वास्तव में दी। इन दोनों को मिलाना — एक मुद्रा में इनवॉइस करना लेकिन दूसरी में सोचना — फ्रीलांसरों को उलझन में डाल देता है।

तो काम का तरीका सरल है:

• आप क्लाइंट की मुद्रा में कीमत तय करते हैं। या तो आपने सीधे उसी में कोट किया, या कोट करते समय एक बार कन्वर्ट करके रेट लॉक कर लिया।
• आप ठीक वही राशि इनवॉइस करते हैं। ऐप उसे उस मुद्रा के लिए सही फॉर्मेट में दिखाता है।
• आप भुगतान होने तक उस मुद्रा में बैलेंस ट्रैक करते हैं, अगर आंशिक भुगतान आएं तो उन्हें दर्ज करते हुए।
• पैसा आने के बाद आप अपनी होम करेंसी में reconcile करते हैं, अपने बैंक स्टेटमेंट की असली दर से — अनुमान से नहीं।

अगर आप क्लाइंट को एक सौजन्य कन्वर्ज़न दिखाना चाहते हैं ("आज की दर पर लगभग $2,150"), तो उसे इनवॉइस के नोट्स में टेक्स्ट के रूप में लिखें और साफ बताएं कि यह अनुमानित है। बिल की राशि क्लाइंट की मुद्रा में ही रहेगी।

टैक्स: inclusive, exclusive, कई दरें, और net-of-tax

अंतरराष्ट्रीय इनवॉइस में सबसे अधिक गड़बड़ी टैक्स में होती है, क्योंकि देश मूल बातों पर भी सहमत नहीं हैं — न दर पर, न नाम पर, और सबसे ज़रूरी बात — यह कि कीमतें सामान्यतः टैक्स सहित दिखाई जाती हैं या बिना टैक्स के।

Inclusive बनाम Exclusive — क्लाइंट की उम्मीद के अनुसार चुनें

InvoiceFlow दोनों tax-inclusive और tax-exclusive प्राइसिंग को सपोर्ट करता है, और यह चुनाव सिर्फ दिखावे का नहीं है — इससे बदलता है कि क्लाइंट कौन-सी संख्या को "कीमत" मानकर पढ़ेगा।

• Tax-exclusive: लाइन आइटम में टैक्स-पूर्व कीमत दिखती है, टैक्स अलग लाइन के रूप में जुड़ता है, और कुल उनका योग होता है। यह दुनिया के अधिकांश हिस्सों में B2B काम का मानक है — कंपनियां net आंकड़ों में सोचती हैं क्योंकि वे टैक्स वापस ले लेती हैं।
• Tax-inclusive: दिखाई गई कीमत में टैक्स पहले से शामिल होता है, और इनवॉइस बताता है कि उस कीमत में से कितना टैक्स था। यह उन देशों में आम है जहां नियम या परंपरा है कि ग्राहक वही चुकाता है जो कीमत पर लिखा है।

इसे बाज़ार के अनुसार सही तरीके से करें। एक B2B जर्मन क्लाइंट जो tax-exclusive इनवॉइस पढ़ रहा है जिसमें VAT लाइन स्पष्ट है — वह ठीक वही देख रहा है जो उसे चाहिए। वही क्लाइंट tax-inclusive इनवॉइस पाए तो उसे अपनी बुककीपिंग के लिए net राशि खुद निकालनी होगी — बिना किसी वजह के आपके द्वारा पैदा की गई परेशानी।

एक इनवॉइस पर कई टैक्स दरें

असली इनवॉइस हमेशा एक दर पर नहीं होते। आप किसी क्लाइंट को कंसल्टिंग (एक दर) और किसी फिजिकल प्रोडक्ट (अलग दर) के लिए बिल कर सकते हैं, या ऐसा काम जो reduced rate और standard rate दोनों में आता हो। InvoiceFlow एक ही इनवॉइस पर कई टैक्स दरें संभालता है — हर लाइन पर सही दर लगाता है और टैक्स को दर के अनुसार सारांशित करता है। क्लाइंट को एक साफ breakdown दिखती है, न कि कोई ऐसा मिश्रित आंकड़ा जिसे वह verify न कर सके।

Net-of-tax और देय राशि

इन सबके पीछे ऐप net-of-tax आंकड़े और देय राशि सही तरीके से compute करता है, ताकि कुल योग मेल खाए — चाहे आपने inclusive, exclusive और multi-rate का कोई भी संयोजन इस्तेमाल किया हो। अगर आंशिक भुगतान आए, तो देय राशि बैलेंस के अनुसार अपडेट हो जाती है। आप रात 11 बजे यह अंकगणित हाथ से नहीं कर रहे — जब अक्सर इनवॉइस में गलतियां होती हैं।

अंतरराष्ट्रीय टैक्स के बारे में एक व्यावहारिक बात जो कोई ऐप नहीं तय कर सकता: विदेशी बिक्री पर टैक्स लगाना है या नहीं — यह कानूनी प्रश्न है, ऐप की सेटिंग नहीं। Reverse-charge नियम, निर्यात के लिए zero-rating, place-of-supply परीक्षण — ये आपके अधिकारक्षेत्र, क्लाइंट के अधिकारक्षेत्र और आप क्या बेच रहे हैं, इन सब पर निर्भर करते हैं। ऐप आपके बताए किसी भी टैक्स ट्रीटमेंट को ईमानदारी से दिखाएगा। सही ट्रीटमेंट जानना आपका काम है (या आपके अकाउंटेंट का)। पहले नियम तय करें; फिर इनवॉइस configure करें।

Per-invoice locale: PDF क्लाइंट की भाषा में प्रिंट करें

यह वह बात है जो लोगों को चुपचाप प्रभावित करती है। आपका ऐप अंग्रेज़ी में चल सकता है जबकि क्लाइंट को मिलने वाला इनवॉइस जर्मन, फ्रेंच या जापानी में प्रिंट होता है।

InvoiceFlow per-invoice locale को सपोर्ट करता है: आप किसी खास इनवॉइस के लिए भाषा सेट करते हैं, और जनरेट हुई PDF — "Invoice," "Due date," "Subtotal," "Tax," "Total" जैसे लेबल, तारीख का फॉर्मेट, इत्यादि — उस भाषा में रेंडर होती है, चाहे आपका ऐप किसी भी भाषा में सेट हो। आप अपने सहज इंटरफेस में काम करते हैं; क्लाइंट को ऐसा दस्तावेज़ मिलता है जो लगता है उनके लिए ही बना हो।

यह ऐप की PDF रेंडरिंग के साथ मिलकर काम करता है, जो non-Latin लिपियों को सही तरीके से handle करती है — सिरिलिक, अरबी, CJK — bundled NotoSans फॉन्ट्स और user-selectable फॉन्ट्स के साथ। टोक्यो या रियाध के क्लाइंट के लिए बना दस्तावेज़ लिपि की जगह खाली बक्सों की पंक्ति नहीं बनेगी। अगर आपने कभी टूटे हुए अक्षरों वाली PDF मिली हो, तो आप जानते हैं कि यह कितनी जल्दी विश्वास खो देती है; इसे सही करना एक छोटी-सी बात है जो दक्षता का संकेत देती है।

व्यावहारिक कदम: हर विदेशी क्लाइंट के लिए उनका पसंदीदा invoice locale एक बार सेट करें। उसके बाद उनके इनवॉइस अपने आप उनकी भाषा में निकलेंगे, जबकि आप अपना इंटरफेस कभी नहीं छोड़ते।

पते: 199 देश, और फ़ील्ड वास्तव में फिट होती हैं

अंतरराष्ट्रीय इनवॉइसिंग की एक सच्चाई यह है कि पते देशों के बीच अत्यंत असंगत होते हैं, और एक कठोर पता फॉर्म हर विदेशी पते को थोड़ा गलत दिखाता है।

InvoiceFlow के पता फ़ील्ड 199 देशों में country-aware हैं। जब आप क्लाइंट का देश चुनते हैं तो दो चीजें होती हैं:

• Region और postal के लेबल बदल जाते हैं। अमेरिका में जो "ZIP code" है, वह कनाडा में "Postal code" है, UK में "Postcode" है, और भारत में "PIN code" है। फ़ील्ड उसी तरह लेबल होती है जैसे उस देश में होती है, ताकि पता प्राप्तकर्ता और उनकी अकाउंट्स टीम को स्वाभाविक लगे।
• कुछ देशों में region और postal पूरी तरह छिप जाते हैं। कई देशों में state/region लाइन या postal code उस तरह नहीं होती जैसे अन्य देशों में होती है। ऐसे देश के पते पर खाली "State" फ़ील्ड जबरदस्ती लगाना दर्शाता है कि आप वह देश नहीं जानते। फॉर्म उन फ़ील्ड्स को हटा देता है जो लागू नहीं होतीं।

नतीजा: PDF पर पता ब्लॉक ऐसा दिखता है जैसे किसी स्थानीय व्यक्ति ने लिखा हो — सही फ़ील्ड नाम, सही फ़ील्ड मौजूद, कुछ भी थोपा हुआ नहीं। जब यह सही होता है तो दिखता नहीं; जब गलत होता है तो सबको नज़र आता है — इसीलिए इसे सही करना ज़रूरी है।

सब कुछ एक साथ: एक व्यावहारिक उदाहरण

मान लीजिए आप एक फ्रीलांस डिज़ाइनर हैं जिनके तीन विदेशी क्लाइंट हैं: म्यूनिख की एक एजेंसी (यूरो में भुगतान, B2B, tax-exclusive और स्पष्ट VAT लाइन की उम्मीद, जर्मन में इनवॉइस चाहिए), टोरंटो का एक स्टार्टअप (कैनेडियन डॉलर, अंग्रेज़ी, postal code), और टोक्यो का एक स्टूडियो (जापानी येन, जापानी भाषा में इनवॉइस)। यहां एक-बार का सेटअप और बार-बार का काम का तरीका है।

1. हर क्लाइंट को एक बार सेट करें। हर एक के लिए डिफ़ॉल्ट मुद्रा, पसंदीदा invoice locale, और देश सेट करें (जो पता लेबल तय करता है)। म्यूनिख: EUR, जर्मन, Germany। टोरंटो: CAD, English, Canada। टोक्यो: JPY, Japanese, Japan।
2. अपने अकाउंटेंट के साथ हर क्लाइंट के लिए टैक्स ट्रीटमेंट तय करें, फिर configure करें। म्यूनिख का इनवॉइस tax-exclusive है VAT लाइन के साथ; बाकियों के लिए उन बिक्रियों के आपके नियमों के अनुसार।
3. इनवॉइस बनाएं। यह सही मुद्रा में खुलता है। आप उस मुद्रा में line items दर्ज करते हैं — वे आंकड़े जो आपने वास्तव में तय किए थे, fly पर converted नहीं।
4. ऐप को totals करने दें। Net-of-tax, दर के अनुसार टैक्स, और देय राशि — सब सही compute होते हैं।
5. PDF जनरेट करें। यह क्लाइंट की भाषा में प्रिंट होती है, मुद्रा को सही फॉर्मेट में दिखाती है, और पते को सही लेबल के साथ render करती है — भले ही क्लाइंट की भाषा non-Latin लिपि में हो।
6. ट्रैक करें और reconcile करें। आप इनवॉइस की मुद्रा में बैलेंस फॉलो करते हैं; भुगतान हो जाने पर, बैंक से मिली असली होम-करेंसी राशि अपनी बुककीपिंग में दर्ज करते हैं।

तीन क्लाइंट, तीन मुद्राएं, तीन भाषाएं — और आपकी तरफ से हर बार वही चंद तरीके, क्योंकि per-client सेटिंग्स आपके लिए सब अंतर संभाल लेती हैं।

वे छोटी बातें जो मिलकर बड़ा फर्क डालती हैं

अंतरराष्ट्रीय इनवॉइसिंग सटीकता को उस तरह पुरस्कृत करती है जैसे घरेलू इनवॉइसिंग नहीं करती। घर पर, थोड़ा-सा गलत पता लेबल या अपरिचित टैक्स प्रस्तुति किसी का ध्यान नहीं खींचती क्योंकि सब एक ही धारणाएं साझा करते हैं। सीमाओं के पार, हर बेमेल एक छोटा संकेत है कि आप improvise कर रहे हैं। जिस फ्रीलांसर के यूरो इनवॉइस यूरो में आते हैं, जर्मन में, VAT लाइन उसी तरह जैसे जर्मन इनवॉइस में होती है, और पता ब्लॉक जो सही दिखता है — उसे एक professional vendor माना जाता है। जिसके इनवॉइस को AP टीम process करने से पहले translate, convert और reformat करना पड़े, वह "वह विदेशी सप्लायर जो थोड़ा झंझट वाला है" बन जाता है।

यह सेटअप आपको हर क्लाइंट के लिए सिर्फ एक बार करना है। उसके बाद, स्थानीय दिखने और बाहरी दिखने का अंतर आपके हर भेजे इनवॉइस में built-in हो जाता है — और इसकी कीमत है सिर्फ वे दस मिनट जो पहली बार क्लाइंट की मुद्रा, भाषा और देश सही से भरने में लगते हैं।