CA और टैक्स प्रैक्टिस: क्लाइंट को भेजने वाले मेल और चेकलिस्ट Claude Code से बनाने का तरीका

महीने की पहली तारीख़ की सुबह, मेरा एक CA दोस्त हर बार वही लंबी साँस लेता है।

“फिर से यही मेल, बिल्कुल शून्य से लिखना है क्या?”

उसके 30 क्लाइंट हैं। हर एक को बताना होता है कि इस महीने का ट्रायल बैलेंस तैयार है, कहाँ-कहाँ देखना है, और कौन-से दस्तावेज़ अभी भेजने बाक़ी हैं। मज़े की बात यह कि हर कंपनी के मेल का 80% हिस्सा एक जैसा होता है—बस फ़र्म का नाम, आँकड़े और “इस क्लाइंट की एक ख़ास बात” बदलनी पड़ती है। फिर भी वह हर बार खाली स्क्रीन से शुरू करता है। और एक दिन जल्दबाज़ी में भेजे मेल में किसी और क्लाइंट का नाम छूट गया—“आपकी कंपनी का GST” लिखकर ग़लत क्लाइंट को भेज दिया। नतीजा: माफ़ी का एक फ़ोन।

यह “80% एक जैसा, पर 20% में ज़रा भी ग़लती नहीं चलेगी” वाला काम ही टैक्स फ़र्म की चुपचाप ऊर्जा खा जाने वाली जगह है। आज इसी को नए सिरे से बाँधते हैं—जहाँ Claude Code ड्राफ़्ट बनाए और आख़िरी फ़ैसला इंसान करे।

मुख्य बातें

• टैक्स फ़र्म के क्लाइंट मेल और रिव्यू चेकलिस्ट का “ढाँचा” तय रहता है, इसलिए Claude Code से टेम्पलेट बना लेने पर हर महीने का दोबारा-टाइप ख़त्म हो जाता है
• AI को सौंपना है सिर्फ़ “मेल का मसौदा और छूट-चूक की जाँच” तक। टैक्स की रक़म सही है या नहीं, कौन-सा नियम लागू होगा, और अंतिम “Send” बटन—ये हमेशा इंसान तय करे
• क्लाइंट के बैलेंस-शीट डेटा और निजी जानकारी को, नाम और आँकड़े छिपाकर ही AI को देना सुरक्षित है। फ़र्म का एक नियम-पत्र पहले से तय कर लें
• काम में तुरंत इस्तेमाल लायक प्रॉम्प्ट टेम्पलेट, रिव्यू चेकलिस्ट, और छूट-चूक को मशीनी तरीक़े से पकड़ने वाली जाँच स्क्रिप्ट यहाँ दी गई है
• 20 क्लाइंट पर हिसाब लगाएँ तो प्रति क्लाइंट 15 मिनट की बचत—यानी महीने के 5 घंटे। सहायक स्टाफ़ का ओवरटाइम महीने भर के पैमाने पर घट सकता है

पहले, टैक्स फ़र्म के इस काम को टुकड़ों में बाँटें

जिनके लिए यह लिख रहा हूँ, वे हैं 10 से 50 क्लाइंट सँभालने वाली छोटी-मँझोली टैक्स/अकाउंट फ़र्म। 1 से 3 सीनियर CA, और बहीखाता व विज़िट-ऑडिट चलाने वाले कुछ सहायक स्टाफ़। अकाउंटिंग सॉफ़्टवेयर Tally, Zoho Books या QuickBooks जैसा कुछ। ऐसी फ़र्में ही सबसे ज़्यादा हैं।

हर महीने का क्लाइंट-संवाद आमतौर पर इसी क्रम में चलता है।

1. अकाउंटिंग सॉफ़्टवेयर में महीने का ट्रायल बैलेंस और मूवमेंट रिपोर्ट फ़ाइनल करना
2. असामान्य आँकड़े या पिछले महीने से बड़ा घट-बढ़ स्टाफ़ का छाँटना
3. क्लाइंट को मेल करना—“ट्रायल बैलेंस तैयार है”, “यहाँ देख लीजिए”
4. क्लाइंट से रसीद की कमी या लेजर-हेड के सवाल वापस आना
5. जिनका साल-अंत (year-end) पास है, उन्हें अलग से उस महीने की रिव्यू चेकलिस्ट भेजना

इनमें से 3 और 5, यानी “समझाने वाला मेल लिखना” और “रिव्यू लिस्ट बनाना”, लगभग पूरी तरह हाथ से होते हैं। ढाँचा हर बार वही रहता है, पर उसे लफ़्ज़ों में ढालने की मेहनत हर बार लगती है। यहीं Claude Code की बारी आती है।

आम पीछे-हटाव, और शुरुआत से पहले-बाद का फ़र्क़

पीछे-हटाव (rework) की असली शक्ल ठोस तरीक़े से रखता हूँ। पढ़ते ही पहचान जाएँगे।

आम पीछे-हटाव	वजह	नतीजा
किसी और क्लाइंट का नाम/आँकड़ा छूटा रह गया और मेल चला गया	पिछला मेल कॉपी-पेस्ट किया, बदलना भूल गए	माफ़ी और भरोसे में कमी
”यहाँ देख लीजिए” वाली बात हर बार अलग ढंग से	हर स्टाफ़ का लिखने का तरीक़ा अलग	क्लाइंट उलझता है, सवाल बढ़ते हैं
साल-अंत जाँच का कोई बिंदु छूट जाना	लिस्ट याददाश्त के भरोसे	रिटर्न ठीक पहले दस्तावेज़ की कमी पकड़ में आना
भाषा इतनी तकनीकी कि क्लाइंट को समझ न आए	टैक्स की शब्दावली जस की तस	”तो आख़िर करना क्या है?” फिर से सवाल

शुरुआत से पहले स्टाफ़ खाली मेल स्क्रीन के सामने बैठकर “अरे, पिछले महीने कैसे लिखा था…” से शुरू करता था। शुरुआत के बाद, उस महीने के आँकड़े और ख़ास बातें बुलेट में देने भर से, फ़र्म के स्टैंडर्ड टोन वाला ड्राफ़्ट कुछ सेकंड में आ जाता है। स्टाफ़ का काम “शून्य से लिखना” से बदलकर “आए हुए ड्राफ़्ट को CA की नज़र से सुधारना” हो जाता है।

बिल्कुल खाली दिमाग़ से लफ़्ज़ निचोड़ने के बजाय, एक तैयार मसौदा सुधारना तेज़ भी है और कम थकाता भी है। यह वही बात है जो बहीखाते और रिटर्न तैयार करने में लागू होती है—शून्य से बनाने की तुलना में जाँच-सुधार हल्का होता है। अगर आपने Claude Code अभी छुआ नहीं है, तो पहले Claude Code पहली बार छूने वालों के लिए शुरुआती गाइड पर एक नज़र डालें—फिर आगे के प्रॉम्प्ट सीधे चलाए जा सकेंगे।

Use case 1: महीने के ट्रायल बैलेंस का सूचना-मेल टेम्पलेट बनाना

हर महीने का “ट्रायल बैलेंस तैयार है” वाला मेल। इसे सिर्फ़ आँकड़े और ख़ास बातें देकर ड्राफ़्ट करवाएँ।

पहले, फ़र्म का स्टैंडर्ड टोन एक बार लिख लें। इसे प्रॉम्प्ट की शुरुआत में रख दें तो कोई भी करे, गुणवत्ता एक जैसी रहेगी।

आप एक टैक्स फ़र्म के सहायक स्टाफ़ हैं। क्लाइंट को भेजने वाले मासिक ट्रायल बैलेंस सूचना-मेल का ड्राफ़्ट बनाइए।

# फ़र्म का टोन
- शिष्ट और औपचारिक हिंदी। तकनीकी शब्द आए तो साथ में सरल अर्थ जोड़ें
- एक वाक्य छोटा रखें। जो देखना है उसे नंबर वाली सूची में लिखें
- रक़म दिए गए आँकड़े जस के तस लें, अनुमान से मत भरें

# इस महीने की जानकारी
- क्लाइंट का नाम: __ (यहाँ नाम)
- महीना: __ साल __ माह
- पिछले महीने से बड़ा घट-बढ़ वाला हेड: __ (उदा: एंटरटेनमेंट खर्च +18,000 रु.)
- क्या देखना है: __ (उदा: 12/5 की 10,000 रु. नक़द निकासी किस काम की)
- कमी वाले दस्तावेज़: __ (उदा: अप्रैल का क्रेडिट कार्ड स्टेटमेंट)

# आउटपुट
सब्जेक्ट और बॉडी। अंत में "किसी भी शंका के लिए बेझिझक संपर्क करें" से समाप्त करें।
अगर कोई आँकड़ा या बात आपने अनुमान से भरी, तो बॉडी के अंत में 【जाँचें】 के नीचे बुलेट में साफ़ बताएँ।

आख़िरी बात—“अनुमान से भरी चीज़ों को 【जाँचें】 के नीचे साफ़ बताना”—यही असली चाबी है। AI खाली जगह भरना चाहता है, इसलिए उससे ख़ुद बता दिलवाएँ कि कहाँ-कहाँ अपने मन से जोड़ा, तो इंसान की जाँच एकदम हल्की हो जाती है।

प्रॉम्प्ट लिखने का तरीक़ा ही एक स्तर ऊपर उठाना हो, तो Claude Code का प्रॉम्प्ट डिज़ाइन गहराई से समझने वाला लेख में “भूमिका, बंदिश, आउटपुट का रूप” तय करने की सोच काम आती है।

Use case 2: साल-अंत की रिव्यू चेकलिस्ट बनवाना

साल-अंत (year-end) पास आते ही, हर क्लाइंट के लिए “यह सब है क्या?” जाँचना होता है। इन बिंदुओं को हर बार स्टाफ़ की याददाश्त से जोड़ें, तो कहीं न कहीं ज़रूर छूटता है।

इसलिए, फ़र्म के स्टैंडर्ड जाँच-बिंदु एक टेक्स्ट फ़ाइल में रख दें, और क्लाइंट के उद्योग के हिसाब से छाँटवा लें।

नीचे दिए मास्टर बिंदुओं में से, इस क्लाइंट पर लागू होने वाले ही चुनकर, साल-अंत रिव्यू चेकलिस्ट बनाइए।

# क्लाइंट की पृष्ठभूमि
- उद्योग: __ (उदा: रेस्तराँ, 1 आउटलेट)
- कंपनी/व्यक्तिगत: __
- GST स्थिति: __ (उदा: रेगुलर / कम्पोज़िशन / छूट-प्राप्त)

# मास्टर बिंदु
- बिक्री का छूटा हुआ रिकॉर्ड (कट-ऑफ़ के बाद की बिक्री, बिना बिल वाली)
- स्टॉक/इन्वेंट्री की मात्रा और मूल्यांकन
- स्थायी संपत्ति का ख़रीद/बट्टे-खाते/डेप्रिसिएशन
- लोन का रीपेमेंट शेड्यूल और ब्याज
- निदेशक वेतन/बोनस का असल भुगतान
- स्टॉक रखने वाले उद्योग में बरबादी/scrap का रिकॉर्ड
- नक़द-कारोबार में नक़द बैलेंस और बही का मिलान
- GST स्थिति के हिसाब से अलग-अलग संकलन

# आउटपुट
चेकबॉक्स रूप में (- [ ])। हर बिंदु के साथ "क्यों जाँचना है" एक पंक्ति में।
लागू न होने वाले बिंदु छोड़ दें। जिन पर फ़ैसले में हिचक हो, उन्हें अंत में 【CA जाँचें】 के नीचे रखें।

उद्योग में “रेस्तराँ” डालें तो नक़द बैलेंस और बरबादी वाले बिंदु रहेंगे, “IT सेवा/कॉन्ट्रैक्ट डेवलपमेंट” डालें तो स्टॉक वाला बिंदु हट जाएगा—यानी उसी क्लाइंट को जितना चाहिए उतना ही निकलता है।

आउटपुट कुछ ऐसा दिखेगा।

## XYZ स्टोर्स — साल-अंत रिव्यू चेकलिस्ट (मार्च क्लोज़िंग)

- [ ] कट-ऑफ़ के बाद की बिक्री अगले साल में तो नहीं खिसकी (टाइमिंग का फ़र्क़ सीधे टैक्स पर असर डालता है)
- [ ] 31/3 की स्टॉक मात्रा और दर (इन्वेंट्री मूल्य मुनाफ़े को तय करता है)
- [ ] कैश-काउंटर नक़द और बही बैलेंस का मिलान (नक़द-कारोबार में फ़र्क़ आसानी से आता है)
- [ ] बरबाद हुए कच्चे माल का छूटा रिकॉर्ड (लागत में दर्ज है या नहीं)

【CA जाँचें】
- कम्पोज़िशन स्कीम की बिज़नेस-कैटेगरी इस साल भी ठीक है या नहीं

Use case 3: क्लाइंट के सवाल का जवाबी ड्राफ़्ट

“यह लेजर-हेड क्या है?” “क्या यह खर्च क्लेम कर सकते हैं?” क्लाइंट के ऐसे सवालों का जवाब किस दिशा में जाएगा, यह तय रहता है—पर हर बार ध्यान से लफ़्ज़ों में ढालना झंझट का काम है।

यहाँ अहम बात यह है: टैक्स का फ़ैसला AI से मत करवाएँ। फ़ैसला CA एक पंक्ति में दे, और AI सिर्फ़ “उसे क्लाइंट की समझ की भाषा में बदलने” का काम करे।

क्लाइंट के सवाल का जवाब, CA के नीति-नोट के आधार पर, आसान भाषा में बनाइए।
टैक्स की व्याख्या या "हो सकता है/नहीं" का फ़ैसला नीति-नोट के मुताबिक़ ही रखें; आप अपना फ़ैसला न जोड़ें, न बदलें।

# क्लाइंट का सवाल
"मीटिंग में हुआ कैफ़े का बिल खर्च में आ सकता है?"

# CA का नीति-नोट (सिर्फ़ इसी का पालन करें)
- काम की मीटिंग हो तो "बिज़नेस मीटिंग खर्च" के रूप में चलेगा
- पर किससे और किस मक़सद से, यह रिकॉर्ड रखें। निजी हो तो नहीं चलेगा

# आउटपुट
नर्म और शिष्ट हिंदी में। तकनीकी शब्द (जैसे बिज़नेस मीटिंग खर्च) छोटे में समझाएँ।
नीति-नोट में जो नहीं है, वैसा अपवाद मत लिखें।

इससे “बिज़नेस मीटिंग खर्च के रूप में दर्ज हो सकता है। बस किससे और किस मक़सद से मिले, यह रिकॉर्ड रखिए” जैसा जवाब, टोन बनाए रखते हुए, निकल आता है।

AI को सौंपने का दायरा, और जो इंसान ज़रूर तय करे

टैक्स फ़र्म में यही सबसे अहम है। रेखा साफ़ खींचते हैं।

चरण	Claude Code को सौंपें	इंसान (CA) तय करे
मेल का मसौदा	○ ड्राफ़्ट बनाना	अंतिम शब्दावली की मंज़ूरी
छूट-चूक छाँटना	○ बिंदुओं की सूची बनाना	बिंदु ज़रूरी है या नहीं—अंतिम फ़ैसला
टैक्स/दर की गणना	× न करवाएँ	◎ इंसान ख़ुद गणना और दोबारा जाँच करे
नियम लागू होने का फ़ैसला	× न करवाएँ	◎ छूट/शर्तें इंसान तय करे
क्लाइंट को भेजना	× न करवाएँ	◎ Send बटन हमेशा इंसान दबाए

याद रखने का तरीक़ा आसान है। “लिखना और तरतीब देना” AI का, “सही है या नहीं तय करना और भेजना” इंसान का। टैक्स की रक़म या लागू-योग्यता AI से पूछकर आँख मूँदकर मान लेना उतना ही ख़तरनाक है जितना कैलकुलेटर पर भरोसा किए बिना अंदाज़े से जोड़ना। AI ने जो आँकड़ा या शर्त दी, उसे हमेशा मूल दस्तावेज़ से मिलाएँ।

ग़ैर-तकनीकी स्टाफ़ के साथ यह रेखा साझा करने की बुनियाद के लिए, ग़ैर-इंजीनियर के लिए Claude Code सुरक्षित शुरुआत वाला लेख फ़र्म में एक बार घुमा दें—अजीब इस्तेमाल से होने वाले हादसे घटते हैं।

सुरक्षा और निजी जानकारी की सावधानी

क्लाइंट का बैलेंस-शीट डेटा पक्की निजी और गोपनीय जानकारी है। यहाँ समझौता मत कीजिए।

• नाम और ठोस रक़म छिपाकर दें: प्रॉम्प्ट में देते समय “A कंपनी”, “बिक्री ◯◯ रु.” जैसे गुमनाम करें। आए हुए ड्राफ़्ट में सही नाम और आँकड़े बाद में इंसान भरे
• फ़र्म का AI-इस्तेमाल नियम एक पन्ने में तय करें: किस टूल में क्या डाल सकते हैं, क्या नहीं (PAN/आधार, बैंक खाता नंबर, कच्ची बैलेंस-शीट PDF आदि)—यह लिखित रूप में हो
• भेजने से पहले आँखों से जाँच ज़रूरी: AI के बनाए मेल को हमेशा ज़िम्मेदार CA पढ़कर ही भेजे। ऑटो-सेंड न हो
• अकाउंटिंग सॉफ़्टवेयर से सीधे न जोड़ें: फ़िलहाल कॉपी-पेस्ट तक सीमित रहें, असल डेटा में ऑटो-राइटिंग से बचें

फ़र्म के नियम टीम के साथ साझा करने का ठोस तरीक़ा CLAUDE.md बेस्ट प्रैक्टिस वाले लेख में मिलेगा। प्रोजेक्ट के नियम एक फ़ाइल में लिख दें, तो कोई भी इस्तेमाल करे, एक ही पूर्वधारणा पर चलेगा। इस्तेमाल से पहले निजी डेटा के बरताव को लेकर भारत के डिजिटल पर्सनल डेटा प्रोटेक्शन एक्ट की सरकारी जानकारी एक बार देख लेना भी ठीक रहेगा।

कॉपी-पेस्ट लायक: छूट-चूक पकड़ने वाली स्क्रिप्ट

ड्राफ़्ट मेल में “बदलना भूल गया” वाला कुछ बचा तो नहीं, यह मशीनी तरीक़े से पकड़ने वाली छोटी स्क्रिप्ट है। पिछले क्लाइंट का नाम रह जाना, रक़म का प्लेसहोल्डर (__) न भरना—ऐसे हादसे भेजने से पहले रोक देती है। Node.js हो तो चलेगी।

check-draft.mjs नाम से सेव करें और node check-draft.mjs draft.txt से चलाएँ।

import { readFile } from "node:fs/promises";

const file = process.argv[2];
if (!file) {
  console.error("इस्तेमाल: node check-draft.mjs draft.txt");
  process.exit(1);
}

const text = await readFile(file, "utf8");

// इस मेल का सही क्लाइंट नाम (जिसे भेजना है) यहाँ डालें
const correctClient = process.env.CLIENT_NAME || "XYZ स्टोर्स";

// पुराने मेल में आम तौर पर रह जाने वाले अन्य क्लाइंट नाम। फ़र्म की हक़ीक़त के हिसाब से जोड़ें
const otherClients = ["Sample Pvt Ltd", "Test Industries", "ABC Clinic"];

const issues = [];

// 1) भरना भूला हुआ प्लेसहोल्डर
if (text.includes("__")) issues.push("प्लेसहोल्डर __ बचा हुआ है");

// 2) 【जाँचें】 टैग बचा तो नहीं (मिटाना भूलने की जाँच)
if (text.includes("【जाँचें】")) issues.push("【जाँचें】 बचा हुआ है। सामग्री देख लें");

// 3) किसी और क्लाइंट का नाम घुस तो नहीं गया
for (const name of otherClients) {
  if (text.includes(name)) issues.push(`अन्य क्लाइंट का नाम "${name}" मौजूद है`);
}

// 4) जिसे भेजना है उसका नाम एक बार भी नहीं आया
if (!text.includes(correctClient)) {
  issues.push(`प्राप्तकर्ता "${correctClient}" बॉडी में कहीं नहीं दिखा`);
}

if (issues.length === 0) {
  console.log("जाँच ठीक: भेजने से पहले अंतिम आँखों-वाली जाँच पर बढ़ें");
} else {
  console.log("सुधार ज़रूरी:");
  for (const i of issues) console.log(" - " + i);
  process.exit(1);
}

यह पूरी तरह सटीक पकड़ नहीं है। पर “पिछली कंपनी का नाम रह गया और मेल चला गया” वाला सबसे डरावना हादसा, इतने भर से लगभग रुक जाता है। otherClients में अपने क्लाइंट के नाम भर लेना ही असली तरकीब है। Claude Code से तो बस “मेरे 10 क्लाइंट के नाम ऐरे में डाल दो” कहने भर से यह स्क्रिप्ट बदलकर मिल जाती है।

आसान ROI का अंदाज़ा

मोटा-मोटी हिसाब लगाते हैं। 20 क्लाइंट, हर महीने सूचना-मेल और रिव्यू लिस्ट बनती है, और हर क्लाइंट पर हाथ से 20 मिनट लगते थे—मान लें।

• शुरुआत से पहले: 20 क्लाइंट × 20 मिनट = महीने के 400 मिनट (लगभग 6.7 घंटे)
• शुरुआत के बाद: ड्राफ़्ट + आँखों-वाली जाँच मिलाकर प्रति क्लाइंट 5 मिनट = 20 × 5 = 100 मिनट (लगभग 1.7 घंटे)
• फ़र्क़: महीने के क़रीब 5 घंटे की बचत

सहायक स्टाफ़ का घंटा 300 रु. मानें तो महीने के क़रीब 1,500 रु. की मेहनत। साल-अंत में यह असर और बढ़ता है। रक़म से बड़ी बात शायद यह है कि “नाम ग़लत होने पर माफ़ी का फ़ोन” ही ख़त्म हो जाता है।

आँकड़ों के पीछे भागे बिना छोटा सा आज़माना हो, तो Claude Code की दक्षता बढ़ाने वाले छोटे नुस्ख़े में से सिर्फ़ एक अपनाकर शुरू करें—जारी रखना आसान रहेगा।

अक्सर पूछे जाने वाले सवाल

Q. टैक्स की गणना तक Claude Code को सौंप दूँ? नहीं। AI मेल का मसौदा बनाने में माहिर है, पर टैक्स की रक़म या लागू-योग्यता सही है या नहीं—इसकी गारंटी नहीं देता। गणना और फ़ैसला हमेशा CA करे, AI को सिर्फ़ “तय बात को क्लाइंट की भाषा में बदलने” तक रखें।

Q. क्लाइंट की बैलेंस-शीट जस की तस पेस्ट कर दूँ तो ठीक है? बचें। नाम, रक़म, PAN/आधार आदि छिपाकर, गुमनाम करके ही देना उसूल है। आए ड्राफ़्ट में सही नाम बाद में इंसान भरे—यही सुरक्षित तरीक़ा है।

Q. जिन्हें कंप्यूटर ठीक से नहीं आता, वे स्टाफ़ भी इस्तेमाल कर सकते हैं? हाँ। करना बस हिंदी में कहना और जाँचना है। शुरू में सीनियर एक टेम्पलेट प्रॉम्प्ट तैयार करे, और स्टाफ़ उसमें आँकड़े भरने से शुरू करे—तो कहीं नहीं अटकेंगे।

Q. अकाउंटिंग सॉफ़्टवेयर से ऑटो-कनेक्ट हो सकता है? तकनीकी रूप से मुमकिन है, पर शुरू में सलाह नहीं दूँगा। असल डेटा में ऑटो-राइटिंग का हादसा बड़ा होता है, इसलिए फ़िलहाल कॉपी-पेस्ट से “ड्राफ़्ट बनाने” तक सीमित रहना सुरक्षित है।

Q. आए हुए लेख की गुणवत्ता कैसे पक्की करूँ? फ़र्म का स्टैंडर्ड टोन प्रॉम्प्ट की शुरुआत में फ़िक्स करें, ऊपर वाली जाँच स्क्रिप्ट से मशीनी हादसे रोकें, और अंत में CA आँखों से देखे। इस तीन-परत बंदोबस्त से व्यक्ति-दर-व्यक्ति गुणवत्ता का फ़र्क़ घटता है।

असल में आज़माने पर

मैंने सचमुच, 5 काल्पनिक क्लाइंट के मासिक सूचना-मेल, ऊपर वाले टेम्पलेट प्रॉम्प्ट और जाँच स्क्रिप्ट से बनाकर देखे।

जाँचना दो बातें थीं। एक—“फ़र्म का टोन शुरुआत में फ़िक्स कर दें, तो क्या सचमुच क्लाइंट-दर-क्लाइंट मेल का फ़र्क़ मिट जाता है?” नतीजा: पाँचों मेल एक ही शिष्टता और एक ही ढंग की समाप्ति वाले निकले। नंबर वाली सूची की बारीकी तक एक जैसी रही।

दूसरा—“क्या स्क्रिप्ट अन्य क्लाइंट का नाम पकड़ लेती है?” जान-बूझकर एक मेल में पिछली कंपनी का नाम छोड़कर जाँच चलाई, तो अन्य क्लाइंट का नाम "Test Industries" मौजूद है कहकर ठीक रुक गई। प्लेसहोल्डर __ का बचना भी पकड़ में आया।

उलटा, एक सीमा भी पता चली। GST स्थिति पूछने पर AI पूरे आत्मविश्वास से जँचता-सा जवाब देता है, पर कम्पोज़िशन स्कीम की एक बिज़नेस-कैटेगरी ग़लत बता गया। आख़िर फ़ैसला इंसान का। ड्राफ़्ट और छूट-चूक की जाँच AI, सही-ग़लत और भेजना CA। यह रेखा बनाए रखें, तो हर महीने की थकान काफ़ी हल्की हो जाती है—यही आज़माने का असल अनुभव है।

फ़र्म के स्तर पर इसे ढंग से काम में जोड़ना हो, तो ट्रेनिंग/सलाह में आपकी फ़र्म के वर्कफ़्लो के हिसाब से डिज़ाइन साथ बैठकर तय किया जा सकता है। पहले ख़ुद हाथ चलाकर अभ्यस्त होना हो, तो शिक्षण-सामग्री/मुफ़्त PDF से छूकर देखिए।