एआई सहयोगसहित मिलान

२०२६ मा एआई साँच्चै कुनमा राम्रो छ

उपकरण केका लागि हो, त्यसमा इमानदार हुनुहोस्। आधुनिक एलएलएम र तिनमाथि बनाइएका नियम-इन्जिन मिलानमा तीन कुरामा राम्रा छन्, र तपाईंले तिनलाई ठीक ती तीन कुराका लागि प्रयोग गर्नुपर्छ।

१. मिति र रकमबाट स्पष्ट मिलान जोड्ने। असार १२ मा तपाईंको लेजरमा रू. ४,५०,००० डेबिट र उही मितिमा NIC Asia स्टेटमेन्टमा रू. ४,५०,००० डेबिट जसको नरेसनमा तपाईंको सप्लायरको नाम छ — मिलान हो। मोडेलले फेला पार्छ। यसले गाह्रोहरू पनि फेला पार्छ — उही रकम, चेक क्लियरिङका लागि एक-दिनको अन्तर, सप्लायरको नामको सट्टा PAN प्रयोग गर्ने नरेसन, FonePay भुक्तानी जहाँ नरेसनमा व्यापारी नाम वास्तविक पाउनेभन्दा एग्रीगेटर हो। यी ढाँचा-पहिचानका समस्या हुन् र मोडेल मानवीय आँखाभन्दा साँच्चै छिटो छ।

२. नमिलेका आइटमका लागि उम्मेदवार व्याख्या उत्पादन गर्ने। यो बढी रोचक क्षमता र बढी कम-प्रयोग गरिएको हो। मोडेलले मिलाउन नसकेको हरेक आइटमका लागि, यसले सम्भावित कारणको छोटो सूची प्रस्ताव गर्न सक्छ: समय फरक (चेक जारी भयो तर पेस भएन), लेजरमा अझै पोस्ट नभएको बैङ्क शुल्क, USD सेटलमेन्टमा FX राउन्डिङ, अङ्क ट्रान्सपोजिसन (रू. ३४,५०० लाई रू. ४३,५०० पोस्ट गरिएको), एक तर्फ डुप्लिकेट पोस्टिङ, वा अर्को तर्फ साँच्चै हराइरहेको इन्ट्री। राम्रो मोडेललाई लेजर र स्टेटमेन्ट सँगै दिँदा, यसले हरेक पङ्क्तिका लागि सम्भावना अनुसार र्याङ्क गर्न सक्छ।

३. नमिलेको आइटम सूचीलाई मेमोमा सङ्क्षेपण गर्ने। एक पटक हरेक नमिलेको आइटम के हो भनेर निर्णय गर्नुभयो भने, मोडेल बिल्कुल राम्रो ड्राफ्टर हो। यसले “तलका सातवटा आइटम अर्को महिनाको पहिलो हप्तामा क्लियर हुने समय फरक हुन्; तलका तीनवटा आइटम पोस्टिङ बाँकी रहेका बैङ्क शुल्क हुन्; तलको एउटा आइटम JV द्वारा सच्याउने ट्रान्सपोजिसन त्रुटि हो” लाई फाइलका लागि सफा मेमोमा बदल्छ। यो वास्तविक काम हो, राम्रोसँग गरिएको।

एआई केका लागि होइन

मिलानमा तीन कामहरू लेखापालका हुन्, र तिनी चल्दैनन्।

के त्रुटि हो र के जानाजान हो भनेर निर्णय गर्ने। तपाईंको स्टेटमेन्टमा रू. १,२०० डेबिट जुन लेजरले देखाउँदैन, छुटेको बैङ्क शुल्क हुन सक्छ — वा तपाईंले विवाद गर्नुपर्ने ठगी डेबिट हुन सक्छ। मोडेलले कुन बढी सम्भावना छ भन्न सक्छ; यसले निर्णय गर्न सक्दैन, किनभने निर्णयले वास्तविक परिणाम बोक्छ। रू. ५०० को राउन्डिङ फरक सच्याउनुपर्ने टाइपो हुन सक्छ — वा अन्यत्र दस्तावेज गरिएका कारणले तीन हप्ताअघि साझेदार-इन-चार्जले गरेको जानाजान समायोजन हुन सक्छ। फर्मको वास्तविक इतिहास भएकोले मात्र थाहा पाउन सक्छ।

के सस्पेन्समा पोस्ट गर्ने भनेर निर्णय गर्ने। “सस्पेन्स” त्यो खाता हो जहाँ कसैले समाधान नगरुन्जेल नसुल्झेका आइटम बस्छन्। आइटम सस्पेन्समा पठाउनु आफैमा निर्णय हो: यसलाई कति समय नसुल्झिएको छाड्न स्वीकार्य छ, छाड्ने जोखिम के हो, कसले फलो अप गर्छ, कहिले। मोडेलसँग यो कुनै सन्दर्भ छैन र यसलाई बहाना गर्न दिनुहुन्न।

कुन तर्फ समायोजन गर्ने भनेर निर्णय गर्ने। जब बैङ्क र लेजर असहमत हुन्छन्, एउटा सही छ र अर्को समायोजन चाहिन्छ। कुन कुन हो भन्ने डाटाबाट मात्र विरलै स्पष्ट हुन्छ। बैङ्क सामान्यतया रकम र मितिबारे सही हुन्छ; लेजर सामान्यतया वर्गीकरण र नियतबारे सही हुन्छ। तर “सामान्यतया” ले त्यो वाक्यमा एलएलएमलाई निर्णय गर्न दिन धेरै काम गर्दैछ। लेखापालले निर्णय गर्छन्, कागजात अगाडि राखेर।

ठोस वर्कफ्लो

२०२६ मा सानो वा मध्यम आकारको नेपाली अभ्यासमा काम गर्ने व्यावहारिक अन्त्य-देखि-अन्त्य आकार यस्तो देखिन्छ।

चरण १ — निर्यात। आफ्नो बैङ्कको पोर्टलबाट बैङ्क स्टेटमेन्ट CSV का रूपमा निकाल्नुहोस् (NIC Asia, Nabil, Global IME, Siddhartha, Standard Chartered सबैले यो प्रदान गर्छन्; अझै PDF मात्र दिने थोरैका लागि, PDF लाई यो अध्यायको पहिलो खण्डको OCR चरणबाट चलाउनुहोस्)। Tally वा तपाईंको लेखा सफ्टवेयरबाट सम्बन्धित लेजर CSV का रूपमा निकाल्नुहोस्। दुवै फाइलले उही मिति दायरा कभर गर्नुपर्छ, उही खुल्ने र बन्द हुने ब्यालेन्ससहित।

चरण २ — संरचित प्रम्प्ट। दुवै CSV लाई Claude, ChatGPT, वा Gemini लाई एउटै प्रम्प्टमा टाँस्नुहोस्, यस्तो देखिने निर्देशनसहित:

तल दुई CSV छन्। पहिलो हाम्रो कम्पनीको [मिति दायरा] का लागि NIC Asia बैङ्क स्टेटमेन्ट हो। दोस्रो उही अवधि र खाताका लागि हाम्रो बहीबाटको सम्बन्धित लेजर हो। दुई तालिका उत्पादन गर्नुहोस्। तालिका A: मिलेका जोडी — हरेक जोडीका लागि, बैङ्क पङ्क्ति, लेजर पङ्क्ति, र मिलान आधार (हुबहु रकम + उही मिति / रकम + एक-दिन अन्तर / रकम + नरेसन मिलान / आदि) देखाउनुहोस्। तालिका B: नमिलेका आइटम — कुनै पनि तर्फबाट नमिलेका सबै पङ्क्ति सूचीबद्ध गर्नुहोस्, कुन तर्फबाट आयो चिह्नित गर्नुहोस्, र हरेक पङ्क्तिका लागि किन नमिलेको हो भन्ने सम्भावित कारणको छोटो र्याङ्क गरिएको सूची दिनुहोस् (समय, शुल्क, ट्रान्सपोजिसन, हराइरहेको इन्ट्री, ठगी, FX, डुप्लिकेट)। मिलान नबनाउनुहोस्। जर्नल इन्ट्री प्रस्ताव नगर्नुहोस्।

चरण ३ — नमिलेको सूचीको ट्रायाज। तालिका B लाई Excel मा लैजानुहोस् — वा अझ राम्रो, तपाईंको फर्मले मिलानका लागि प्रयोग गर्ने वर्किङ पेपर टेम्प्लेटमा। हरेक नमिलेको पङ्क्तिका लागि, यो के हो, यसलाई कुन प्रमाणले समर्थन गर्छ, के (यदि छ भने) पोस्ट हुन्छ, र के (यदि छ भने) सस्पेन्स वा फलो-अपमा जान्छ निर्णय गर्नुहोस्। मोडेलका उम्मेदवार व्याख्या यहाँ निष्कर्षका रूपमा होइन, सुरूवात बिन्दुका रूपमा उपयोगी छन्।

चरण ४ — च्याटमा होइन, लेखा सफ्टवेयरमा पोस्ट गर्ने। कुनै पनि वास्तविक जर्नल इन्ट्री — बुक गर्नुपर्ने छुटेको बैङ्क शुल्क, सच्याउनुपर्ने ट्रान्सपोजिसन, पुँजीकृत गर्नुपर्ने शुल्क — मानिसले Tally वा तपाईंको लेखा सफ्टवेयरमा पोस्ट गर्छ, वर्किङ पेपरलाई समर्थन कागजातका रूपमा राखेर। च्याट ट्रान्सक्रिप्ट तपाईंको अडिट ट्रेल होइन; वर्किङ पेपर हो।

“एआईले ९५% मिलायो, ठीकै देखिन्छ” किन खतरा हो

यो खण्डले चेतावनी दिइरहेको त्रुटिको विशिष्ट आकारमा अलिकति रुकेर हेर्नु लायक छ, किनभने यो यति प्रलोभक छ।

एक जुनियरले मिलान चलाउँछ। मोडेलले पन्चानब्बे प्रतिशत मिलेको सफा तालिका A र पाँचवटा नमिलेका आइटमसहित तालिका B फर्काउँछ। योगफल लगभग मिल्छ। जुनियर, थकित र समय-सीमामा, तालिका A हेर्छ, योगफल मिलेको पुष्टि गर्छ, तालिका B लाई “सानो कुरा” मान्छ र बही मिलाउन सस्पेन्समा सानो ब्यालेन्सिङ JV पोस्ट गर्छ। मिलान “सकियो।” वास्तविक मिलानजस्तो देखिन्छ। वर्किङ पेपर त प्रभावशाली पनि देखिन्छ।

तर गरिएको कामको मूल्य — सजिलो पन्चानब्बे प्रतिशत मिलाउनु — सधैं अनिवार्य रूपमा शून्य थियो। ती पङ्क्ति कहिल्यै समस्या हुने थिएनन्; तिनी मिल्ने थिए। नगरिएको काम — पाँचवटा नमिलेका आइटम प्रत्येकलाई साँच्चै बुझ्ने, यसले के सङ्केत गर्छ निर्णय गर्ने, उचित अनुसार पोस्ट वा वृद्धि गर्ने — मिलानको सम्पूर्ण बिन्दु थियो। जुनियरले एक धेरै महँगो मोडेलको सहायताले, मिलानको रूप कार्यान्वयन गरेको छ तर यसको सार छोडेर।

यो काल्पनिक होइन। २०२६ मा मैले देखेका फर्ममा यो एआई-सहायतायुक्त मिलानको प्रमुख असफलता मोड हो। प्रतिकार संरचनात्मक हो, प्रेरणात्मक होइन: तालिका B को हरेक पङ्क्तिमा दस्तावेज गरिएको निर्णय नभएसम्म मिलान बन्द हुँदैन। मिलेको तालिका सूचनात्मक हो; नमिलेको तालिका नै काम हो।

जब मोडेल आफैसँग असहमत हुन्छ

एक उपयोगी अन्तिम बानी। उही मिलानलाई थोरै फरक प्रम्प्टसहित दुई पटक चलाउनुहोस् — एक पटक मोडेललाई मिलान प्रस्ताव गर्नमा उदार हुन भन्दै (नरेसन-समानता मिलान स्वीकार्य, तीन दिनसम्मको मिति-अन्तर स्वीकार्य), अर्को पटक कडा हुन भन्दै (हुबहु-रकम-र-मिति मिलान मात्र, बाँकी सबै नमिलेका)। दुई नमिलेका सूची तुलना गर्नुहोस्।

दुवै रनमा नमिलेका आइटम लगभग पक्कै वास्तविक अपवाद हुन् र पूर्ण ध्यान पाउन योग्य छन्। उदार रनमा मिलेका र कडा रनमा नमिलेका आइटम सिमानाका केस हुन् — मोडेलको निर्णय पुष्टि गर्न तिनलाई छिटो मानवीय हेराइ चाहिन्छ। दुवै रनमा मिलेका आइटम धेरै सम्भावना सुरक्षित छन्। यो दोहोरो-रन ढाँचाले तपाईंलाई केही अतिरिक्त रुपैयाँको टोकन लाग्छ र एउटै विश्वासमा भएको तर गलत रनको झूटो आत्मविश्वासबाट बचाउँछ। यो वर्कफ्लोमा निःशुल्क सुरक्षा-जाँचको सबैभन्दा नजिकको कुरा हो।

आफ्नो बुझाइ जाँच्नुहोस्

छोटो जाँच

—

तपाईंको जुनियरले एलएलएमसँग बैङ्क मिलान चलाउँछ। यसले ९५% आइटम मिलेको र ५% नमिलेको रिपोर्ट गर्छ। जुनियरले बही मिलाउन सस्पेन्समा सानो ब्यालेन्सिङ इन्ट्री पोस्ट गरेर मिलान बन्द गर्न चाहन्छ। यो किन गलत चाल हो?

1. Aयो सही चाल हो; आधुनिक मोडेलले पर्याप्त सटीक मिलाउँछन् कि नमिलेका आइटम सुरक्षित रूपमा सस्पेन्समा बन्द गर्न सकिन्छ।
2. Bमिलेको ९५% सूचनात्मक हो — ती आइटम सधैं मिल्ने थिए। नमिलेको ५% मा हरेक मिलानको वास्तविक मूल्य बस्छ: यसमा त्रुटि, ठगी, समय फरक, र छुटेका इन्ट्री छन् जुन सतहमा ल्याउन मिलान अस्तित्वमा छ। अनुसन्धान बिना तिनलाई सस्पेन्समा बन्द गर्दा अभ्यासको उद्देश्य परास्त हुन्छ।
3. Cबैङ्कले सस्पेन्स इन्ट्री अस्वीकार गर्न सक्छ।
4. Dलेखा सफ्टवेयरले सस्पेन्स पोस्टिङ अनुमति दिँदैन।

उत्तर जाँच्नुहोस्→

अब के?

तपाईंले अब लेखाको डाटा-इन तर्फको लूप बन्द गर्नुभयो: स्रोत कागजात कब्जा गरियो, कारोबार तपाईंको फर्मको वास्तविक चार्ट अनुसार वर्गीकृत भयो, र बही बाहिरी संसारसँग सहमत छ। अर्को अध्याय डाटा-इन बाट डाटा-आउट तर्फ सर्छ: यी सबै सफा डाटाबाट निस्कने रिपोर्ट — व्यवस्थापन लेखा, भेरियन्स विश्लेषण, बोर्ड नरेटिभ, र ग्राहकले आफ्ना सङ्ख्याबाट वास्तवमा सोध्ने प्रश्न — बनाउने, व्याख्या गर्ने, र प्रयोग गर्ने तरिकालाई एआईले कसरी बदल्छ।