अध्याय २ · खण्ड I · 17 मिनेट
चलानी, रसिद र बैङ्क विवरणका लागि OCR + LLM
२०२६ मा नेपाली लेखा कार्यालयमा सबैभन्दा ठूलो समय-बचत भनेको छिटो पोस्ट गर्नु होइन — कागज मेसिनलाई पढ्न दिएर मानिसले किनारका कुरा मात्र जाँच्नु हो।
महिनाको २५ गते काठमाडौंको कुनै पनि अभ्यासरत लेखा कार्यालयमा छिर्नुहोस् — एउटै दृश्य देख्नुहुन्छ: २०१७ को डेल टावर, एक-एक फुट अग्ला कागजका दुई चाङ, र कोही NIC Asia स्टेटमेन्टबाट चलानी नम्बर एक-एक पङ्क्ति Tally मा टाइप गर्दैछ। यो काम एआईले अन्ततः, सुस्तरी, अनावश्यक बनाइदियो — वा कम्तीमा फरक काममा बदलिदियो। काम अब टाइप गर्ने होइन। काम भनेको सही ठाउँमा, मेसिनले पहिल्यै टाइप गरिसकेको कुरालाई जाँच्ने हो। यो खण्ड त्यो परिवर्तन नेपाली स्रोत कागजातमा वास्तवमै कसरी लागू गर्ने भन्ने बारे हो — जहाँ कागज फोहोर छ, लिपि मिश्रित छ, र “अटो-पोस्ट” अझै डराउनुपर्ने शब्द हो।
छापिएको देवनागरी समाधान भयो। हस्तलिखित भएन।
पहिले बुझ्नुपर्ने कुरा यो हो: २०२६ मा OCR दुई फरक समस्या हुन्, एउटै नाम बोकेर हिँडेका। छापिएको देवनागरी — भाटभटेनीको थर्मल प्रिन्टरबाट निस्केको, बिरगन्जको होलसेलरको लेजर प्रिन्टरबाट आएको, Global IME को बैङ्क स्टेटमेन्ट PDF — समाधान भएको समस्या हो। आधुनिक मल्टिमोडल मोडेल (Claude, GPT-वर्गका मोडेल, Gemini) ले एउटै पृष्ठमा छापिएको देवनागरी, रोमन नेपाली र अंग्रेजी एक प्रतिशतभन्दा निकै कम क्यारेक्टर-त्रुटि दरमा पढ्छन्। Nabil बैङ्क स्टेटमेन्टको स्क्रिनसट Claude मा टाँसेर तालिका माग्नुहोस् — तालिका सही आउँछ।
हस्तलिखित नेपाली बेग्लै खेल हो। किराना पसलको रू. १२,४५०/- लेखिएको नीलो रसिद, ट्रान्सपोर्टरको म्यानुअल चलानी, ट्याक्स इन्भ्वाइसको कुनामा क्यासियरले पेन्सिलले गरेको टिपोट — यिनै ठाउँमा मोडेल भत्किन्छन्, कहिलेकाहीं चुपचाप। हस्तलिखित रकममा कन्फिडेन्स छापिएकोमा जस्तै देखिन्छ; मोडेलले सधैं भन्दैन कि म अनुमान गर्दैछु। कागजात धेरैजसो हस्तलिखित छ र रकम महत्त्वपूर्ण छ भने, OCR मा हाल्नुहुन्न। टाइप गर्नुहोस्। बचेको एक मिनेट पछि किन रू. ९,००,००० कम छ भनेर खोज्न लाग्ने आधा दिनको मूल्यभन्दा सानो छ।
त्यसैले उपकरण रोज्नुअघिको व्यावहारिक विभाजन: छापिएका पृष्ठ मोडेलमा जान्छन्; जुनसुकै महत्त्वपूर्ण रकमका हस्तलिखित पृष्ठ मानिसमा जान्छन्। मिश्रित कागजात — तलमा हस्तलिखित डिस्काउन्ट कोरिएको छापिएको चलानी — मोडेलमा जान्छ, तर हस्तलिखित भाग समीक्षाका लागि फ्ल्याग गर्ने स्पष्ट निर्देशनसहित।
कुन कागजातबाट के निकाल्ने
फरक कागजातका फरक न्यूनतम क्षेत्र छन् जुन तपाईंले निकाल्नैपर्छ। मोडेललाई के चाहिएको हो स्पष्ट भन्नुहोस्; उसैलाई छाड्नुहुन्न।
१. सप्लायर चलानी (VAT वा गैर-VAT)। निकाल्नुहोस्: चलानी नम्बर, चलानी मिति (जहाँ छ, BS र AD दुवै), सप्लायरको नाम, सप्लायरको PAN/VAT नम्बर, परिमाण र दरसहित लाइन-आइटम, उप-योग, VAT रकम (वा स्पष्ट exempt फ्ल्याग), जम्मा, र उल्लिखित TDS। मोडेलले चार्ट-अफ-अकाउन्ट्स वर्ग प्रस्ताव गर्नुपर्छ तर त्यसलाई प्रस्ताव भनेर मात्र चिह्नित गर्नुपर्छ, पोस्टिङका रूपमा होइन। VAT चलानीका लागि नियम सम्झौतायोग्य छैन: ०.१३ अंश शुद्धबाट छुट्याउनैपर्छ, र जहाँ चलानीमा VAT र छुटप्राप्त सामग्री मिसिएको छ त्यहाँ प्रति-लाइन आधारमा। धेरैजसो टोलीका सबैभन्दा खराब पोस्टिङ त्रुटि त्यस्ता मोडेलबाट आउँछन् जसले चुपचाप छुटप्राप्त पङ्क्तिमा १३% लगाइदिन्छन्।
२. ग्राहक रसिद / काउन्टरफ्वाइल। निकाल्नुहोस्: रसिद नम्बर, मिति, ग्राहकको नाम, रकम, भुक्तानी मोड (नगद / बैङ्क ट्रान्सफर / चेक / Khalti / eSewa / FonePay), र भएमा सन्दर्भ नम्बर। सन्दर्भ नम्बर नै यहाँको मूल्य हो — यही क्षेत्र हो जसले अर्को खण्डको मिलान चरणमा यो रसिदलाई बैङ्क क्रेडिटसँग जोड्न दिन्छ।
३. बैङ्क स्टेटमेन्ट PDF (जस्तै, NIC Asia, Nabil, Global IME, Siddhartha)। निकाल्नुहोस्: प्रत्येक कारोबारको मिति, हुबहु नरेसन, डेबिट, क्रेडिट, र रनिङ ब्यालेन्स। मोडेललाई नरेसन “सफा” गर्न नदिनुहोस् — नरेसन फरेन्सिक हो। MBL/NPS/TXN-***/RAJU TRADERS ले पत्ता लगाउन दिन्छ; Payment to Raju Traders ले निशान हराउँछ। नरेसन क्षेत्र क्यारेक्टर-दर-क्यारेक्टर सुरक्षित राख्न स्पष्ट रूपमा भन्नुहोस्।
४. IRD चलान र VAT रिटर्न प्रिन्टआउट। निकाल्नुहोस्: PAN, अवधि (महिना / त्रैमास), कर प्रकार, रकम, मिति, चलान / पेस गरेको सन्दर्भ। यी पोस्ट गर्ने कारोबार होइनन्, मिलान-एङ्कर हुन्; निकालिएको डाटालाई लेजरसँग तुलना गर्ने कुराका रूपमा लिनुहोस्।
५. Khalti / eSewa / FonePay वालेट निर्यात। यी सामान्यतया पहिल्यै CSV का रूपमा आउँछन्, त्यसैले OCR समस्या होइन — समस्या यो हो कि व्यापारी-तर्फ र ग्राहक-तर्फका नरेसन बैङ्क-तर्फका नरेसनसँग मिल्दैनन्, र मोडेल पुल प्रस्ताव गर्नमा राम्रो छ। दुवै तर्फ खुवाएर कुन पङ्क्ति कुनसँग मेल खान्छ भनेर सोध्नुहोस्।
वास्तवमा काम गर्ने स्पट-चेक नियम
तपाईंले हरेक पङ्क्ति जाँच्नुहुन्न। यदि हरेक पङ्क्ति जाँच्नुहुन्छ भने, समय बचाएकै हुनुहुन्न। पूरा समीक्षाको अधिकांश सुरक्षा थोरै लागतमा दिने नियम भनेको टप-र-बटम नियम हो।
मोडेलले निकालेको तालिका तयार भएपछि, यसलाई दुई पटक छाँट्नुहोस्। पहिलो, निरपेक्ष रकमका आधारमा घट्दो क्रममा — र मूल्य अनुसारको माथिल्लो दश प्रतिशत मानिसले जाँच्नुहोस्। यहाँको लेखापालन सिद्धान्त OCR भन्दा पुरानो हो: ठूला रकममा भएका त्रुटि सानामा भएका भन्दा बढी महत्त्वपूर्ण हुन्छन्। दोस्रो, मोडेलको कन्फिडेन्स स्कोरका आधारमा बढ्दो क्रममा — र तल्लो दश प्रतिशत मानिसले जाँच्नुहोस्। यी ती पङ्क्ति हुन् जसमा मोडेल आफै अनिश्चित छ। दुई छनोटको ओभरल्याप सानो हुन्छ तर त्यहीँ लगभग सबै महत्त्वपूर्ण त्रुटि बस्छन्।
उच्च जम्मा मूल्य वा असामान्य लाइन-ढाँचा भएका कागजातका लागि — रू. १०,००,००० भन्दा माथिको एउटै चलानी, कुनै नयाँ सप्लायरलाई जाने, वा विदेशी मुद्रामा भएको — नमुना होइन, पूरै कागजात समीक्षा गर्नुहोस्। नियम भनेको भुइँ हो, छत होइन।
भोलि नै टाँस्न सकिने एउटा प्रम्प्ट ढाँचा
प्रम्प्टको आकार तपाईंले प्रयोग गर्ने मोडेलभन्दा बढी महत्त्वपूर्ण छ। Claude, ChatGPT, र Gemini सबैमा काम गर्ने प्रम्प्ट यस्तो देखिन्छ — कागजात प्रकार अनुसार फिल्ड सूची मिलाउनुहोस्:
तपाईं नेपाली सप्लायर चलानी पढ्दै हुनुहुन्छ (तस्बिर संलग्न)। निम्न क्षेत्र निकाल्नुहोस् र Markdown तालिकाका रूपमा फर्काउनुहोस्: invoice_number, invoice_date_BS, invoice_date_AD, supplier_name, supplier_PAN, line_description, quantity, rate, line_amount, VAT_applicable (yes/no/exempt), VAT_amount, line_total, proposed_account, confidence (high/medium/low)। प्रति लाइन-आइटम एक पङ्क्ति। कुनै पनि देवनागरी पाठ लेखिएको हुबहु राख्नुहोस्। तालिकापछि, विश्वासका साथ पढ्न नसकेका कुनै पनि क्षेत्र र देखिएको कुनै पनि हस्तलिखित क्षेत्र सूचीबद्ध गर्नुहोस्। नदेखेका मान अनुमान नगर्नुहोस्।
यो प्रम्प्टले जानाजान गरेका तीन कुरा याद गर्नुहोस्। यसले लिपिको नाम लिन्छ (नेपाली), जसले गर्दा मोडेलले चुपचाप ट्रान्सलिटरेट गर्दैन। यसले VAT लाई जम्माबाट छुट्याउँछ, जसले मोडेललाई निर्णयलाई स्पष्ट बनाउन बाध्य पार्छ, लुकाउन होइन। र यसले अनुमान निषेध गर्छ — अन्तिम वाक्य सबै प्रम्प्टको सबैभन्दा महत्त्वपूर्ण हो, किनभने तपाईंले बच्न खोजेको असफलता मोड भनेको साँच्चै नदेखेको PAN विश्वासका साथ भरिदिने मोडेल हो।
“कहिल्यै अटो-पोस्ट नगर्ने” नियम
यो नियम काम गर्ने एआई वर्कफ्लो र चुपचाप विपत्ति बीचको भेद हो। कन्फिडेन्स जति नै उच्च भए पनि, मोडेलको आउटपुट ड्राफ्ट पोस्टिङ हो, पोस्टिङ होइन। एक मानिसले — चार्ट अफ अकाउन्ट्स र फर्मको सन्दर्भ टाउकोमा राखेर — पोस्ट बटन थिच्छ।
मोडेल राम्रा हुँदै जाँदा पनि यो नियम बाँचिरहन्छ, कारण दुई हुन्। पहिलो कानुनी हो: SME का लागि NFRS र IRD अडिट अपेक्षा अन्तर्गत, फर्म — यसको सफ्टवेयर होइन — आफ्नो बहीमा भएका इन्ट्रीका लागि जिम्मेवार हुन्छ। गलत वर्गीकृत खर्च भेट्टाएको कर अधिकृतलाई “एआईले भन्यो” बचाउ होइन। दोस्रो व्यावहारिक हो: एलएलएमका असफलता मोड ठीक ती हुन् जुन मानिसले पछि पत्ता लगाउन गाह्रो हुन्छ। एक हजार पङ्क्तिमा गलत खाता तर सम्भाव्य नाम छान्ने मोडेलले लेजरमा फ्ल्याग उत्पादन गर्दैन; यसले सुस्त, चुपचाप व्यवस्थापन लेखाको विकृति उत्पादन गर्छ जुन कसैले निर्णयका लागि प्रयोग गर्न खोज्दासम्म कसैले याद गर्दैन।
त्यसैले अनुशासन “महिनाको अन्त्यमा समीक्षा” होइन। यो ब्याच आइपुग्नेबित्तिकै, कुनै पनि पङ्क्ति Tally वा Xero वा Sage वा तपाईं जुन बही राख्नुहुन्छ त्यसमा जानुअघि समीक्षा हो। एलएलएम आउटपुटलाई स्मार्ट तर नयाँ जुनियरको कामलाई जसरी व्यवहार गर्नुहुन्छ त्यसरी नै व्यवहार गर्नुहोस् — उपयोगी, छिटो, र सामान्य लेजर नजिक जानुअघि वरिष्ठ आँखा अनिवार्य।
आफ्नो बुझाइ जाँच्नुहोस्
छोटो जाँच
—महिनाको प्रशोधनका लागि देवनागरी र अंग्रेजीमा ८० वटा छापिएका सप्लायर चलानीको चाङ छ। कुन वर्कफ्लो सबैभन्दा सुरक्षित र समय-दक्ष छ?
छोटो जाँच
—एउटा सप्लायर चलानी धेरैजसो देवनागरीमा टाइप गरिएको छ, तर डिस्काउन्ट लाइन र अन्तिम जम्मा सप्लायरले हातले लेखेका छन्। जम्मा महत्त्वपूर्ण छ। स्वचालन र म्यानुअल कामको सही विभाजन के हो?
अब के?
कागजबाट डाटा निकाल्नु बही-केपिङ परिवर्तनको पहिलो आधा मात्र हो। दोस्रो आधा भनेको हरेक पङ्क्ति कुन वर्ग मा पर्छ भन्ने हो — र त्यहाँ तपाईंको फर्मको चार्ट अफ अकाउन्ट्स अघि नभएको सामान्य मोडेलले चुपचाप पुनः-टाइपिङभन्दा खराब कुरा गर्छ। अर्को खण्डमा तपाईंको फर्मले वास्तवमा प्रयोग गर्ने चार्ट अफ अकाउन्ट्स अनुसार कारोबार वर्गीकरण गर्ने कुरा छ।