साइड व्यवसायको खर्चलाई लेखा SaaS र mail बाट AI ले स्वचालित रूपमा तुलना गराइरहेको कुरा

नमस्ते, म まさきん हुँ।

व्यक्तिगत रूपमा सानो जारी राखेको साइड व्यवसाय छ। खर्चको लेखा आफैं लेखा SaaS ले गर्न सकिन्छ, तर “यो कार्ड प्रयोग के को खर्च थियो” भनी सम्झने काम सादा तर बोझिलो थियो।

त्यसैले, कार्ड विवरण र mail को receipt लाई AI ले तुलना गराई, खर्चको वर्गीकरणसम्म स्वचालित बनाउने संरचना बनाएँ। यसपटक API को call गर्ने तरिका, वा वास्तवमा फसेको खतरासम्म समावेश गरी देखाउँछु।

सुरुवातको कारण “वर्गीकरण नभएकै अवस्थामा जम्मा हुनु” हो

लेखा SaaS मा कार्ड जडान गरिराख्दा, प्रयोग विवरण स्वचालित रूपमा भित्रिन्छ। तर, “यो के को भुक्तानी थियो” सम्म थाहा हुँदैन। अन्तमा, पछि सम्झनामा भर परी वर्गीकरण गर्नुपर्छ।

सम्झना बिस्तारै हराउँदै जान्छ। त्यसैले, सम्झने काम आफैलाई AIलाई सुम्पने निर्णय गरें।

संरचनाको प्रक्रिया

गरिरहेको काम तलका 4 चरण हो।

1. लेखा SaaS को API बाट, अझै वर्गीकरण नसकिएको कार्ड प्रयोग विवरण लिने
2. उही रकम・नजिकैको मितिको order confirmation mail वा receipt mail खोज्ने
3. दुवैलाई तुलना गरी, सामग्री निश्चित गर्ने
4. निश्चित भएको सामग्रीको आधारमा, खर्चको प्रकार वर्गीकृत गरी, लेखा SaaS मा transaction को रूपमा दर्ता गर्ने

महत्वपूर्ण कुरा, “विवरण मात्र” पनि “mail मात्र” पनि नभई, दुवैलाई तुलना गरेपछि मात्र सामग्री निश्चित हुनु हो।

प्रक्रिया नभएको विवरण लिने

लेखा SaaS को API ले विवरण लिँदा, प्रत्येक विवरणमा प्रक्रिया अवस्था देखाउने flag लागेको हुन्छ। दर्ता नभएको विवरण मात्र लक्ष्य बनाउन, यो flag ले संकुचित गरिन्छ।

GET /api/1/wallet_txns
  query: { company_id, start_date, end_date, limit: 100 }

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

Mail खोजको उपाय

Mail को मुख्य भाग त्यसै गरी AI लाई पढाउँदा, जानकारीको मात्रा धेरै भई token को सीमामा पुगिने हुन सक्छ। त्यसैले, अगाडि नै सर्त संकुचित गरेपछि भित्री कुरा दिने उपाय गरिएको छ।

पहिले, order confirmation mail वा receipt mail को पठाउने address ले अवधि खोज गरिन्छ।

search_threads  query: "from:[email protected] after:2026/09/01 before:2026/09/30"

मिल्ने mail भेटिए पनि, मुख्य भाग पूरै AI लाई दिँदा token सीमामा अड्किन सक्छ। त्यस्तो अवस्थामा, mail को मुख्य भाग save गरिएको file मा keyword खोज गरी, रकम वा सामानको नाम लेखिएको line मात्र निकालिन्छ।

# Save भइसकेको mail file बाट, रकम र मिति नजिकैको मात्र संकुचित गर्ने उदाहरण
grep -l "3,980円" ./mail_archive/*.eml | xargs grep -l "2026-09"

रकम र मिति भन्ने 2 सङ्केतले संकुचित गर्दा, उम्मेदवार केही जति घट्छ। त्यहाँसम्म संकुचित गरेपछि, पहिलोपल्ट मिल्ने भाग मात्र AI लाई दिई तुलना गराइन्छ। Subject वा सुरुको snippet मात्रैले पुग्ने mail पनि धेरै भएकोले, आवश्यक दायरा मात्र लिनु trick हो।

खर्चमा वर्गीकृत गर्ने खर्चमा, संचार खर्च जस्तो निश्चित खर्च पनि मिसिन्छ। काममा पनि प्रयोग हुने smartphone शुल्क, बाँडफाँडमा अलमल हुने प्रतिनिधि हो। त्यसो सोच्दा, plan पुनरावलोकन गर्नु पनि एउटा उपाय होला।

वर्गीकरणको नियम

सामग्री निश्चित भएपछि, तलका 3 प्रकारमा वर्गीकृत गरिन्छ।

वर्गीकरणमा अलमल हुने कुरा, जबर्जस्ती खर्च तिर नझुकाउने गरिएको छ। निर्णयमा आत्मविश्वास नभएको खर्च, एकपटक व्यक्तिगत खर्चको रूपमा व्यवहार गरी, पछि पुनरावलोकन गर्ने लक्ष्यको रूपमा flag लगाइन्छ।

खर्चको रूपमा दर्ता गर्ने

वर्गीकरण तय भएपछि, लेखा SaaS को API ले transaction को रूपमा दर्ता गरिन्छ।

POST /api/1/deals
  body: {
    company_id,
    issue_date: "2026-09-15",
    type: "expense",
    details: [{
      account_item_id: <खर्च विषयको ID>,
      amount: <रकम>,
      description: "◯◯ सामान (व्यवसाय बाँडफाँडको note)"
    }],
    payments: [{
      amount: <रकम>, date: "2026-09-15",
      from_walletable_type: "credit_card", from_walletable_id: <कार्डको ID>
    }]
  }

यहाँ एउटा ध्यान दिनुपर्ने बिन्दु छ। यो दर्ता प्रक्रिया, लेखा SaaS भित्र “transaction नयाँ बनाउने” operation हो, मौलिक प्रक्रिया नभएको विवरणसँग स्वचालित रूपमा जोडिने मेलमिलाप हुने होइन। Transaction दर्ता गर्ने मात्रैले, विवरणको status प्रक्रिया नभएकै रहन्छ।

त्यसैले, दर्ता सकिएपछि अनिवार्य रूपमा लेखा SaaS को screen मा, विवरण र यसपटक बनाइएको transaction लाई हातैले जोड्ने operation गरिन्छ। यहाँ छुटाइदिँदा, उही खर्च दोहोरो दर्ता हुने भएकोले ध्यान दिइन्छ।

“गल्तीले अर्को category मा परेको खर्च” पनि नियमित रूपमा पहिचान गर्ने

स्वचालित बनाए पनि, वर्गीकरणको गल्ती शून्य हुँदैन। त्यसैले, महिनामा एकपल्ट, साइड व्यवसायसँग सम्बन्धित जस्तो तर सामान्य category कै अवस्थामा छाडिएको रेकर्ड छ कि, AI लाई पहिचान गराइन्छ।

ठोस रूपमा, नाफा-नोक्सान विवरणको report API ले लिई, साइड व्यवसाय विशेष विषय नभई सामान्य विषयमा दर्ता भएको खर्च निश्चित गरिन्छ। त्यसपछि, प्रत्येक विषयको विवरण transaction सूची API ले लिई, विवरण स्तम्भको keyword वा रकमको प्रवृत्तिबाट “वास्तवमा साइड व्यवसाय category मा झुकाउनुपर्ने होला” भन्ने लाग्ने रेकर्ड निकालेर सूची बनाइन्छ।

मिल्ने transaction भेटिएमा, PUT ले विषय बदलिन्छ।

PUT /api/1/deals/{transaction ID}
  body: { company_id, issue_date, type: "expense",
    details: [{ id: <अवस्थित विवरण ID>, account_item_id: <सही विषय ID>, amount, description }] }

यहाँ पनि ध्यान दिनुपर्ने बिन्दु छ। details भित्र अवस्थित विवरण ID समावेश नगरी पठाउँदा, अपडेट नभई नयाँ थपको रूपमा व्यवहार गरिन्छ। अवस्थित ID अनिवार्य रूपमा जारी राख्नु, सही रूपमा सार्नको लागि सर्त हो।

निकालिएको कुरा आफैले सामग्री जाँच गरी, आवश्यक मात्र बदलिन्छ।

अन्तिम निर्णय विशेषज्ञलाई सुम्पने

यो दोहोर्याई जोड दिन चाहेको बिन्दु हो। यो संरचना सधैं “वर्गीकरणको पूर्व तयारी” लाई कुशल बनाउने कुरा हो। अन्तिम खर्च वर्गको निर्णय, वा बाँडफाँडको उचितताको बारेमा, tax advisor जस्ता विशेषज्ञको निर्णय पछ्याइन्छ।

AI द्वारा वर्गीकरण सधैं प्राथमिक प्रस्ताव हो। विशेष गरी व्यवसाय बाँडफाँड जोडिएको भाग, आफ्नै निर्णयले मात्र नबढी, विशेषज्ञलाई जाँच गराउने पूर्वाधारमा सञ्चालन गरिन्छ।

गरेर महसुस भएको कुरा

सबैभन्दा सहयोग भएको, “यो के को भुक्तानी थियो” भनी सम्झने काम हराएको हो। Mail भन्ने रेकर्ड बाँकी रहेसम्म, सामग्रीको निश्चितता AI लाई सुम्पिन सकिन्छ।

अर्कोतिर, वर्गीकरणको अन्तिम जाँच अनिवार्य रूपमा आफ्नो आँखाले गरिन्छ। विशेष गरी व्यक्तिगत खर्च र खर्चको सीमा रेखा, यान्त्रिक निर्णय मात्रैले खतरा हुन्छ जस्तो लाग्ने भाग भएकोले।

यस्ता व्यक्तिलाई उपयुक्त छ

• साइड व्यवसाय वा व्यक्तिगत व्यवसायमा कार्ड भुक्तानीको खर्च धेरै भई, वर्गीकरण पछि सारिने बानी हुने व्यक्ति
• Mail मा order confirmation वा receipt बाँकी रहने खरिद धेरै हुने व्यक्ति
• लेखा SaaS को API जडान वा AI प्रयोगमा, केही हदसम्म अभ्यस्त व्यक्ति

सारांश

कार्ड विवरण र mail तुलना गर्ने भन्ने सोच आफैं, विशेष कुरा होइन। तर, त्यो हरेकपल्ट आफैले गर्ने कि संरचनालाई सुम्पने भन्नेले, लाग्ने श्रम धेरै फरक पर्छ।

API दर्ता मात्रैले विवरणसँग मेलमिलाप हुँदैन भन्ने खतरा पनि समेटी राख्दा, वास्तवमा हात चलाउँदा अलमलिन गाह्रो हुन्छ जस्तो लाग्छ। अन्तिम निर्णय विशेषज्ञलाई सुम्पने पूर्वाधार नबिगारी, पूर्व तयारीको भाग मात्र राम्रोसँग संरचना बनाउन सकियो जस्तो लाग्छ।

यो मिलाउने काम गर्दै, संचार खर्च पनि पुनरावलोकनको लक्ष्य बन्यो। काममा पनि प्रयोग हुने smartphone शुल्क, बाँडफाँडको निर्णय सबैभन्दा अलमल हुने खर्च थियो। भए पहिले, plan आफैं मिलाउनु पनि राम्रो होला।

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

यस लेखमा मेसिन अनुवाद समावेश छ। आधिकारिक सर्तका लागि राकुतेन मोबाइलको आधिकारिक साइटको बहुभाषी पृष्ठ हेर्नुहोस्।

राकुतेन मोबाइलको सञ्चार क्षेत्र वा सिग्नल अवस्थाको बारेमा चिन्ता भएमा, आधिकारिक सिग्नल सुधार·अनुसन्धान अनुरोध फारम मार्फत सोध्न सकिन्छ।