Vendor Verification API: पहले भुगतान से पहले की जाँच

मुख्य बातें

• जाँच वहाँ लगाइए जहाँ vendor आता है या बदलता है: onboarding फ़ॉर्म और बैंक विवरण बदलने का अनुरोध। जोखिम का ज़्यादातर हिस्सा इन्हीं दो घटनाओं में होता है।
• ठोस शुरुआती क्रम यह है: PAN, फिर GSTIN (कंपनी के लिए CIN), फिर बैंक खाता, और सूक्ष्म या लघु दर्जे का दावा करने वाले सप्लायर के लिए Udyam। कोई भी सशुल्क call करने से पहले देखिए कि GSTIN के भीतर वाला PAN फ़ॉर्म के PAN से मिलता है या नहीं।
• onboarding नहीं, payment रोकिए। vendor को "जाँच बाक़ी" स्थिति में बनने दीजिए और payment प्रणाली से कहिए कि जिसकी जाँच अधूरी है उसे भुगतान न दे।
• बैंक विवरण का बदलाव नया vendor जुड़ने जैसी घटना है। ईमेल कितनी भी सामान्य लगे, खाते की दोबारा जाँच और दूसरे मंज़ूरीकर्ता की शर्त रखिए।
• valid: false और found: false पूरे और billable जवाब हैं। इन्हें लूप में मत चलाइए। सिर्फ़ 429 और 502 पर सीमा के साथ दोबारा कोशिश कीजिए।
• दोबारा जाँच जोखिम के स्तर के अनुसार बँटा कार्यक्रम है, पूरे साल एक-सा काम नहीं: ख़र्च वहाँ कीजिए जहाँ रकम और जोखिम सबसे ज़्यादा हैं।
• प्रति vendor तीन जाँच वाले मूल प्रवाह पर प्रकाशित दरों से चंद रुपये लगते हैं। नीचे तीन onboarding मात्राओं और एक बार के backfill का हिसाब rate card से दिखाया है।

vendor की ग़लतियाँ और धोखाधड़ी असल में कहाँ से आती हैं

endpoints चुनने से पहले उन विफलताओं की सूची बनाइए जिन्हें आपका नियंत्रण रोकना चाहता है। व्यवहार में वे पाँच तरह की निकलती हैं।

उधार की पहचान। vendor किसी और कारोबार का असली GSTIN या PAN बता देता है। साथ लगे दस्तावेज़ ठीक-ठाक दिखते हैं, क्योंकि वे नक़ल किए गए हैं।

खोखली या निष्क्रिय संस्थाएँ। पंजीकरण है पर कारोबार नहीं चलता, या पंजीकरण रद्द या निलंबित हो चुका है और किसी ने ध्यान नहीं दिया।

खाते की अदला-बदली। vendor असली है, खाता नहीं। ईमेल से भेजा गया बैंक विवरण बदलने का अनुरोध अगला भुगतान किसी ठग के खाते में पहुँचा देता है।

सीधी-सादी टाइपिंग की ग़लतियाँ। खाता संख्या का एक अंक उलट जाए तो पैसा किसी अजनबी के पास पहुँच जाता है। यह धोखाधड़ी से कहीं ज़्यादा होता है और वसूली उतनी ही महँगी पड़ती है।

ग़लत वर्गीकरण। कोई सप्लायर भुगतान-अवधि के कारण सूक्ष्म या लघु दर्जे का दावा करता है, या जिस पंजीकरण को आपने मान रखा था वह उसके पास है ही नहीं, और आपकी payables प्रक्रिया उसे ग़लत तरीक़े से सँभालती है।

इनमें से हर एक के सामने एक स्वचालित जाँच रखी जा सकती है, इसीलिए vendor बनते समय चार fields की जाँच जल्दी ही अपना ख़र्च निकाल देती है। कौन-सी जाँच किसके सामने, यह अगली तालिका में है।

vendor master को क्या जाँचना चाहिए

सूची की हर चीज़ हर vendor के लिए नहीं चाहिए। GST की सीमा से नीचे भुगतान पाने वाले किसी एक-बार के freelancer के लिए शायद PAN और बैंक काफ़ी हों। नियमित माल-सप्लायर के लिए GSTIN चाहिए। कंपनी के लिए CIN। आगे दिए स्तर तय करेंगे कि किसके लिए क्या।

सशुल्क call से पहले की मुफ़्त जाँचें

GSTIN कोई अपारदर्शी संख्या नहीं है। उसके पंद्रह अक्षरों की शुरुआत दो अंकों के राज्य-कोड से होती है, फिर करदाता का दस अक्षर का PAN, फिर उस राज्य में उसी PAN के पंजीकरणों की इकाई-संख्या, एक तयशुदा अक्षर और अंत में एक जाँच-अक्षर। इस बनावट से आपको तीन मुफ़्त जाँचें मिलती हैं।

पहली, ढाँचा: सही आकृति के पंद्रह अक्षर। दूसरी, तीसरे से बारहवें स्थान तक का PAN फ़ॉर्म के PAN के बराबर होना चाहिए। तीसरी, राज्य-कोड vendor के घोषित पते के राज्य से संगत होना चाहिए, इस सावधानी के साथ कि कारोबार कई राज्यों में पंजीकृत हो सकता है और मुख्यालय आपको दिए पंजीकरण से अलग राज्य में हो सकता है। ये जाँचें टाइपो और कई भोंडे जालसाज़ी-प्रयास नेटवर्क के पास पहुँचने से पहले ही पकड़ लेती हैं।

यही बात PAN पर भी लागू होती है: दस अक्षर, पाँच अक्षर, चार अंक, एक अक्षर, और चौथा अक्षर धारक का प्रकार बताता है (जैसे कंपनी या फ़र्म, व्यक्ति से अलग)। "कंपनी" बताने वाले vendor का PAN अगर व्यक्ति दिखाए तो सवाल बनता है। IFSC में ग्यारह अक्षर होते हैं जिनके पाँचवें स्थान पर शून्य रहता है, और इस endpoint के लिए खाता संख्या अंकों की होती है, आम तौर पर नौ से अठारह अंक। ग़लत इनपुट पर endpoint 400 देता है, पर पहले पकड़ना सिर्फ़ तेज़ और मुफ़्त है।

onboarding की कदम-दर-कदम प्रक्रिया

नीचे का क्रम GST पंजीकरण वाले नियमित माल या सेवा सप्लायर के लिए है। सरल vendors के लिए कदम घटा दीजिए।

1. vendor फ़ॉर्म भरता है। कानूनी नाम, व्यापारिक नाम, PAN, GSTIN (या CIN), घोषित राज्य, दावा हो तो Udyam संख्या, और IFSC के साथ बैंक विवरण लीजिए। आपकी privacy सूचना माँगे तो जाँचों की सहमति का पाठ लीजिए। फ़ैसला: अभी कुछ सशुल्क नहीं हुआ, vendor रिकॉर्ड "जाँच बाक़ी" स्थिति में बनता है।
2. normalise करके मुफ़्त जाँचें चलाइए। upper-case और trim कीजिए, ढाँचा देखिए, और जाँचिए कि GSTIN के भीतर का PAN PAN-field के बराबर है। फ़ैसला: फ़ॉर्म सटीक त्रुटि के साथ लौटाइए, या आगे बढ़िए।
3. कानूनी नाम के साथ PAN जाँचिए। POST /v1/verify/pan में pan और name। फ़ैसला: valid: false प्रक्रिया रोकता है, कमज़ोर score समीक्षा में जाता है, और घोषित संस्था-प्रकार से उलटा type भी समीक्षा में।
4. पंजीकरण जाँचिए। POST /v1/verify/gstin में gstin और businessName। response में match score नहीं आता, इसलिए legalName और tradeName को अपने normalise किए फ़ॉर्म-डेटा से ख़ुद मिलाइए। फ़ैसला: tax invoice पर टिके माल व सेवा के सप्लायर के लिए registrationStatus चालू न हो तो रुकिए, समझ न आने वाले नाम समीक्षा में।
5. कंपनी हो तो CIN जाँचिए। POST /v1/verify/cin। फ़ैसला: companyStatus और cinStatus चालू न हों तो रुकिए, और निदेशकों की सूची आपके समीक्षक को पहचानने लायक़ नाम देती है।
6. दावा किया गया MSME हो तो Udyam जाँचिए। POST /v1/verify/udyam। फ़ैसला: found: false या चालू से अलग स्थिति का मतलब है कि दावा दर्ज नहीं हो सकता, किसी दस्तावेज़ से हल होने तक payables के लिए vendor को non-MSME रखिए।
7. जुड़े पंजीकरण मिलाइए। चाहें तो PAN के सारे GSTIN देखने के लिए pan-to-gstin चलाइए। फ़ैसला: जिस पंजीकरण का vendor ने ज़िक्र नहीं किया और जो रद्द है, वह हानिरहित भी हो सकता है और चेतावनी भी, समीक्षा में भेजिए।
8. बैंक खाता जाँचिए। POST /v1/verify/bank-account में accountNumber, ifsc और vendor का कानूनी नाम। फ़ैसला: खाता वैध हो और नाम का score आपकी सीमा पार करे तभी भुगतान के लिए खोलिए।
9. मंज़ूर और सक्रिय कीजिए। vendor के स्तर की सारी ज़रूरी जाँचें पूरी हों तो समीक्षक या कोई नियम vendor को सक्रिय करता है, और अब भुगतान प्रणाली उसे स्वीकार करेगी।
10. सबूत लिखिए। हर जाँच का referenceId, समय, मुख्य response fields और फ़ैसला vendor id से जोड़कर रखिए।

नमूना request और response: GSTIN वाला कदम

इस call में response PAN और बैंक से एक ज़रूरी बात में अलग है: उसमें score नहीं, तथ्य आते हैं, इसलिए तुलना का काम आपके कोड का है।

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/gstin" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"gstin":"07AAAAA1111A1Z1","businessName":"Jane Doe Enterprises"}'

{
  "referenceId": "SMV-20260927-9K21P4",
  "GSTIN": "07AAAAA1111A1Z1",
  "valid": true,
  "legalName": "Jane Doe Enterprises Private Limited",
  "tradeName": "Jane Doe Enterprises",
  "registrationStatus": "Active",
  "principalPlaceOfBusiness": "123, MG Road, Bengaluru, Karnataka, 560001",
  "message": "GSTIN Exists"
}

नीचे की तुलना Python में एक ठीक-ठाक शुरुआत है। यह कंपनी के प्रत्यय और विराम-चिह्न हटाकर शब्दों के समूह मिलाती है, ताकि शब्दों का क्रम या "Private Limited" का छूट जाना झूठा बेमेल न बनाए। अपने डेटा पर ट्यून कीजिए।

import re

SUFFIXES = {"private", "pvt", "limited", "ltd", "llp", "and", "co", "company", "the"}

def tokens(name: str) -> set[str]:
    words = re.sub(r"[^a-z0-9 ]", " ", name.lower()).split()
    return {w for w in words if w not in SUFFIXES}

def names_agree(form_name: str, legal_name: str, trade_name: str = "") -> str:
    form = tokens(form_name)
    best = 0.0
    for candidate in (legal_name, trade_name):
        cand = tokens(candidate)
        if form and cand:
            best = max(best, len(form & cand) / len(form | cand))
    if best >= 0.8:
        return "agree"
    if best >= 0.5:
        return "review"
    return "disagree"

फ़ैसले की तालिका: valid, मेल नहीं, निष्क्रिय, नहीं मिला

बैंक विवरण बदलने की समस्या

vendor धोखाधड़ी से होने वाला ज़्यादातर नुक़सान नए vendor से नहीं, बदले हुए बैंक विवरण से आता है, क्योंकि मौजूदा vendor के पास पहले से भरोसा और भुगतान का इतिहास होता है। खाता बदलने के हर अनुरोध को नए vendor जैसी घटना मानिए, कुछ अतिरिक्त नियमों के साथ।

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

इनमें कुछ भी महँगा नहीं है। जाँच call हर plan पर bank-account की एक-सी दर लेती है, और ठंडक-अवधि व वापसी-फ़ोन में थोड़े समय के सिवा कुछ नहीं लगता।

दोबारा जाँच: कैलेंडर नहीं, जोखिम के हिसाब से

एक बार जाँचा हुआ vendor हमेशा के लिए जाँचा हुआ नहीं होता। GST पंजीकरण रद्द हो सकता है, कंपनी का नाम रजिस्टर से हट सकता है, खाता बंद हो सकता है। पर हर साल सारे vendors पर सब कुछ दोबारा चलाना फ़िज़ूल है। vendors के स्तर बनाइए।

• स्तर 1: बड़ा ख़र्च या अहम आपूर्ति। पंजीकरण और कंपनी की स्थिति आपके चुने छोटे अंतराल पर दोबारा जाँचिए, और खाते की जाँच हर बदलाव पर कीजिए। ये वे vendors हैं जिनके रुकने से आपका काम रुकता है या जिनके भुगतान बड़े हैं।
• स्तर 2: नियमित सप्लायर। पंजीकरण की स्थिति साल में एक बार या अनुबंध के नवीनीकरण पर, और बैंक खाता सिर्फ़ बदलाव पर।
• स्तर 3: कभी-कभार या छोटे vendors। onboarding पर जाँच। दोबारा तभी जब वे लंबे अंतराल के बाद फिर सक्रिय हों या उनका ख़र्च स्तर की सीमा पार करे।

कैलेंडर के ऊपर घटनाओं के ट्रिगर जोड़िए: लौटा हुआ भुगतान, AP के किसी कर्मचारी को दिखा बेमेल, अधिकृत हस्ताक्षरकर्ता का बदलना, या ख़रीदार की कोई प्रतिकूल टिप्पणी। हर घटना उन जाँचों को फिर खोलती है जो उस पर लागू हों।

पुराने vendors का backfill

ज़्यादातर टीमें हज़ारों vendors पहले से सिस्टम में लेकर शुरू करती हैं। backfill एक batch job है जिस पर तीन बंदिशें हैं: rate limit, लागत और दोबारा शुरू हो सकना।

हर endpoint पर rate limits लागू हैं (दस्तावेज़ में दर्ज error का उदाहरण 60 सेकंड में 60 requests है, अपनी सीमाएँ dashboard और pricing पेज से पढ़िए क्योंकि वे plan पर निर्भर हैं)। batch को छोटे worker pool और रफ़्तार-देरी के साथ चलाइए, 429 पर backoff कीजिए, और 402 wallet error आए तो रुक जाइए। job को दोबारा शुरू होने लायक़ बनाइए: हर नतीजा vendor id और जाँच की कुंजी पर लिखिए, ताकि restart में जो हो चुका वह छूट जाए। batch को स्तर के क्रम में चलाइए ताकि सबसे जोखिम वाले vendors पहले जाँचे जाएँ, और कोई नियम कसने से पहले पहले कुछ सौ नतीजे हाथ से देखिए।

const BASE = "https://api-b2b.stampmitra.in";
const headers = {
  Authorization: `Bearer ${process.env.STAMPMITRA_API_KEY}`,
  "Content-Type": "application/json",
};
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function call(path, body, attempt = 0) {
  const res = await fetch(`${BASE}${path}`, { method: "POST", headers, body: JSON.stringify(body) });
  if (res.status === 402) throw new Error("WALLET_EMPTY");
  if ((res.status === 429 || res.status === 502) && attempt < 4) {
    await sleep(1000 * 2 ** attempt + Math.random() * 500);
    return call(path, body, attempt + 1);
  }
  return { status: res.status, body: await res.json() };
}

export async function backfill(vendors, saveResult, alreadyDone) {
  for (const v of vendors) {
    if (alreadyDone(v.id, "gstin")) continue;
    const out = await call("/v1/verify/gstin", { gstin: v.gstin, businessName: v.legalName });
    await saveResult(v.id, "gstin", out);
    await sleep(1100); // दस्तावेज़ में दर्ज प्रति-मिनट खिड़की के भीतर रहने के लिए
  }
}

vendor portal ऐसा बनाइए कि जाँच सस्ती और शालीन हो

कई टीमें vendors को portal से ख़ुद पंजीकरण करने देती हैं। ठीक से बना portal किसी सशुल्क call से पहले ही ज़्यादातर डेटा साफ़ कर देता है।

vendor के टाइप करते समय ही ढाँचे और "GSTIN में PAN" वाले नियम की जाँच कीजिए, और सामान्य विफलता की जगह सीधा संदेश दिखाइए ("इस GSTIN के भीतर का PAN आपके दिए PAN से मेल नहीं खाता")। vendor से कहिए कि कानूनी नाम वैसा ही दे जैसा पंजीकरण पर है, और बताइए कि बैंक विवरण उसी नाम के खाते के होने चाहिए। हर keystroke पर या बार-बार दबाए जा सकने वाले "जाँचें" बटन पर सशुल्क endpoint मत बुलाइए: submit पर एक बार बुलाइए, और नतीजा submission के साथ रखिए ताकि refresh पर दोबारा call न हो। vendor को कोई field सुधारना पड़े तो सिर्फ़ वही जाँचें दोबारा चलाइए जो उस field पर टिकी हैं। सुधारी खाता संख्या को नई बैंक जाँच चाहिए, सुधरे फ़ोन नंबर को कुछ नहीं।

registry के response से संपादन-योग्य फ़ॉर्म fields इस तरह कभी न भरिए कि vendor आपकी जाँची हुई चीज़ बदल दे। जाँचे हुए मान घोषित मानों से अलग कॉलमों में रखिए, ताकि समीक्षक को दोनों हमेशा दिखें और घोषित मान चुपचाप जाँचा हुआ मान न बन जाए।

दुरुपयोग की रोकथाम आपके gateway का काम है। सशुल्क calls चलाने वाला खुला पंजीकरण-फ़ॉर्म किसी script से चलवाकर आपका wallet ख़ाली करवाया जा सकता है, इसलिए जाँच से पहले सत्यापित ईमेल या मोबाइल माँगिए, हर vendor और हर IP पर प्रयास सीमित कीजिए, और असामान्य मात्रा पर अलर्ट रखिए।

प्रोप्राइटर, साझेदारी और कंपनी: क्या बदलता है

एक ही फ़ॉर्म बहुत अलग-अलग कानूनी इकाइयों के काम आता है, और सही जाँचें अलग होती हैं।

एकल प्रोप्राइटर नाम से व्यापार करने वाला एक व्यक्ति है। PAN व्यक्ति का होता है, GSTIN (हो तो) में कानूनी नाम की जगह प्रोप्राइटर का नाम और व्यापारिक नाम की जगह दुकान का नाम आता है, और बैंक खाता अक्सर निजी होता है। PAN का type व्यक्ति बताएगा और बैंक का नाम दुकान का नहीं, व्यक्ति का होगा। ऐसे vendors के लिए बैंक-नाम की तुलना प्रोप्राइटर के नाम से होनी चाहिए, और व्यापारिक नाम बस एक लेबल है।

साझेदारी फ़र्म या LLP का अपना PAN होता है, जिसका चौथा अक्षर व्यक्ति के PAN से अलग होता है। खाता फ़र्म के नाम में होना चाहिए। इस प्लेटफ़ॉर्म पर LLP के लिए CIN जैसा कोई endpoint नहीं है, इसलिए LLP का सबूत PAN, GSTIN और बैंक खाते से आता है, साथ में वे दस्तावेज़ जो आपकी नीति माँगे, जैसे पंजीकरण प्रमाणपत्र।

कंपनी का CIN होता है, और CIN call उसकी स्थिति और निदेशक लौटाती है। निदेशकों की सूची आपके समीक्षकों को vendor के पीछे के लोगों को पहचानने में और यह देखने में काम आती है कि फ़ॉर्म पर दस्तख़त करने वाला व्यक्ति कंपनी से जुड़ा है। यह साबित नहीं करती कि उस व्यक्ति को कंपनी की ओर से बाँधने का अधिकार है, वह दस्तावेज़ का सवाल है।

ट्रस्ट, सोसाइटी और सरकारी निकाय अपने नियमों से चलते हैं और अक्सर उनका GSTIN नहीं होता। उन्हें कंपनियों के लिए बने प्रवाह में ठूँसने की जगह हाथ के रास्ते से भेजिए।

ऑडिटर और आंतरिक नियंत्रण टीम आम तौर पर क्या पूछती हैं

आपके vendor नियंत्रणों की समीक्षा हो तो सवाल अक्सर वही होते हैं। आपको कैसे पता कि vendor मौजूद है? जाँच और उसका transaction id दिखाइए। बदला हुआ खाता धोखाधड़ी में इस्तेमाल होने से कैसे रोकते हैं? बैंक-बदलाव का नियम, दूसरा मंज़ूरीकर्ता और ठंडक-अवधि दिखाइए। विफल जाँच को कौन override कर सकता है? भूमिका, कारण का field और log दिखाइए। पिछले साल vendor चालू था, यह कैसे जानते हैं? दोबारा-जाँच का कार्यक्रम और उसके खोले अपवाद दिखाइए। नियंत्रण बनने से पहले जाँचे गए vendors का क्या? backfill की योजना और उसकी प्रगति दिखाइए।

साफ़ सबूत-रिकॉर्ड इन सबका जवाब मिनटों में दे देता है। उसे ऐसी रिपोर्ट की तरह बनाइए जो export हो सके, ऐसी चीज़ की तरह नहीं जिसे दबाव में कोई इंजीनियर जोड़-जोड़कर तैयार करे।

नतीजे को ERP या भुगतान-चक्र से जोड़ना

सबसे साफ़ जोड़ने की जगह payment block है, डेटा-प्रविष्टि पर पहरा नहीं। procurement को vendors खुलकर बनाने दीजिए, हर एक को तब तक "असत्यापित" चिह्नित रखिए जब तक ज़रूरी जाँचें पास न हों, और भुगतान का प्रस्ताव बनाने वाला तर्क ऐसे हर vendor को बाहर रखे जो सत्यापित नहीं है या जिसकी कोई समीक्षा खुली है। इस तरह धीमी जाँच कभी purchase order नहीं रोकती और विफल जाँच किसी हड़बड़ी वाले भुगतान-चक्र से बचकर नहीं निकल सकती।

सत्यापन की स्थिति अपनी तालिका में रखिए: vendor id, जाँच का प्रकार, नतीजा, referenceId, फ़ैसले का समय, किसने तय किया, और लागू नियम का संस्करण। आपका ERP जो भी हो, वह अपने समर्थित integration से वही स्थिति पढ़ेगा। StampMitra verification के नतीजों के लिए webhook नहीं भेजता, calls synchronous हैं, इसलिए आपकी onboarding सेवा उन्हें करती है और नतीजे ख़ुद लिखती है।

लेखा-विभाग की मेज़ से पाँच स्थितियाँ

ये काल्पनिक हैं और दिखाती हैं कि response और नियम कैसे साथ चलते हैं।

असली GSTIN और किसी और का PAN

फ़ॉर्म में ऐसा GSTIN है जिसके भीतर का PAN PAN-field से अलग है। कोई सशुल्क call होने से पहले ही मुफ़्त जाँच विफल हो जाती है। फ़ॉर्म सटीक संदेश के साथ लौट जाता है। लागत: शून्य।

व्यापारिक नाम वाला vendor

पंजीकरण पर कानूनी नाम किसी लंबी कंपनी का है, और फ़ॉर्म में ब्रांड का नाम। नामों की तुलना "review" लौटाती है क्योंकि शब्दों का मेल मध्यम है। समीक्षक को फ़ॉर्म के नाम के बग़ल में legalName और tradeName दिखते हैं, वह ब्रांड पहचान लेता है और टिप्पणी के साथ मंज़ूर कर देता है। दूसरी सशुल्क call की ज़रूरत नहीं पड़ी।

रद्द हुआ पंजीकरण

एक पुराने सप्लायर का GSTIN स्तर 1 की दोबारा जाँच में अब चालू से अलग स्थिति लौटाता है। सिस्टम अपवाद खोलता है, खुले purchase orders पर निशान लगाता है, और procurement सप्लायर से संपर्क करता है। ख़रीद जारी रखनी है या नहीं, और कर-दस्तावेज़ कैसे सँभालने हैं, यह procurement और कर सलाहकार का काम है, कोड का नहीं।

जल्दी वाला बैंक बदलाव

अगले भुगतान-चक्र से पहले खाता बदलने की ईमेल आती है। AP अनुरोध दर्ज करता है, नए खाते की बैंक जाँच एक वैध खाता लौटाती है जिसका nameAtBank किसी और व्यक्ति का है। बदलाव रोक दिया जाता है, वापसी-फ़ोन फ़ाइल में दर्ज नंबर पर जाता है, और vendor पुष्टि करता है कि उसने ऐसा कोई अनुरोध नहीं भेजा। घटना धोखाधड़ी-लॉग में जाती है।

GST के बिना प्रोप्राइटर

एक छोटे सप्लायर के पास PAN और बैंक खाता है पर GSTIN नहीं। सीमा से नीचे के सप्लायर की नीति को सिर्फ़ PAN और बैंक चाहिए। दोनों पास होते हैं, vendor स्तर 3 में सक्रिय होता है, और टिप्पणी दर्ज होती है कि कोई पंजीकरण ज़रूरी नहीं था।

finance टीम के लिए अपनाने लायक़ समीक्षा-नियम

ये सुझाव हैं जिन्हें आपकी नीति बदलकर अपनाए।

• अपने-आप सक्रिय करें जब vendor के स्तर की हर ज़रूरी जाँच वैध हो, GSTIN-में-PAN वाली जाँच पास हो, नाम मेल खाएँ और बैंक का score आपकी ऊँची सीमा से ऊपर हो।
• समीक्षा में भेजें जब नाम की तुलना बीच के दायरे में पड़े, कोई type घोषित संस्था से उलटा हो, या कोई जुड़ा पंजीकरण चालू न हो।
• पक्की रोक अवैध PAN, tax-invoice सप्लायर के लिए निष्क्रिय पंजीकरण, या ऐसे खाते पर जो वैध नहीं।
• दूसरा मंज़ूरीकर्ता हर बैंक-बदलाव और हर पक्की रोक के override के लिए।
• भुगतान पर रोक जाँच पूरी होने तक। डिफ़ॉल्ट रूप से कोई अपवाद नहीं, और जो अपवाद हो वह नामित और दर्ज हो।
• ख़र्च पर आधारित वृद्धि: जिन नए vendors का अनुमानित वार्षिक ख़र्च आपकी तय रकम से ऊपर है, और जिनका बैंक खाता पिछले कुछ दिनों में बदला है, उनके लिए procurement प्रमुख की मंज़ूरी माँगिए।
• कर्तव्यों का बँटवारा: जो व्यक्ति vendor बनाता है वह उसे मंज़ूर नहीं करता और उसके पहले भुगतान को भी मंज़ूर नहीं करता।

क्या रखें और कितने समय तक

वह सबूत रखिए जो फ़ैसला समझाए: हर call का referenceId, समय, key का environment, ढके हुए पहचान-नंबर, फ़ैसले में काम आए response fields, फ़ैसला, नियम का संस्करण, और override मंज़ूर करने वाला। पूरे PAN या खाता संख्या application logs में न लिखिए। vendor master (संचालन) और सबूत-भंडार (audit) को अलग रखिए।

vendor रिकॉर्ड की अवधि कई जगहों से तय होती है: कर और लेखा-रिकॉर्ड की ज़रूरतें, कंपनी कानून, अनुबंध पर कार्रवाई की समय-सीमा के विचार, और रिकॉर्ड में मौजूद निजी डेटा पर डेटा-सुरक्षा के दायित्व (एकल प्रोप्राइटर और निदेशक व्यक्ति हैं)। अवधियाँ हम नहीं बता सकते। सवाल अपने सलाहकार और कर सलाहकार के पास ले जाइए, जवाब को retention schedule में लिखिए, और फिर उसी के अनुसार मिटाना या archive करना स्वचालित कीजिए। StampMitra का अपना तरीक़ा उसके retention और deletion schedule में है।

लागत: तीन onboarding मात्राएँ और एक backfill

pay-as-you-go rate card पर PAN, GSTIN, CIN और Udyam की हर call ₹5 की है (standard वर्ग), और bank-account जाँच ₹4 की। Growth और Scale plans standard दर घटाते हैं और महीने की फ़ीस जोड़ते हैं, और bank दर सब पर एक-सी रहती है। सभी राशियाँ 18 प्रतिशत GST से पहले की हैं।

मूल vendor प्रवाह है PAN, GSTIN और बैंक खाता। MSME दर्जे का दावा करने वाला सप्लायर एक Udyam call और जोड़ता है।

मासिक मॉडल के लिए मान लीजिए हर चार में से एक नया vendor MSME दर्जे का दावा करता है। महीने में 100 नए vendors पर यह 100 PAN, 100 GSTIN, 25 Udyam (कुल 225 standard calls) और 100 बैंक जाँचें हैं।

महीने में 1,000 नए vendors पर: 2,250 standard calls और 1,000 बैंक जाँचें।

महीने में 5,000 नए vendors पर, जैसा कोई marketplace या बड़ा ख़रीदार देख सकता है: 11,250 standard calls और 5,000 बैंक जाँचें।

20,000 मौजूदा vendors का PAN, GSTIN और बैंक जाँचों वाला एक बार का backfill 40,000 standard calls और 20,000 बैंक जाँचें हैं। इसे किसी plan पर एक ही महीने में चलाएँ तो वह महीना ऐसा दिखता है:

दो व्यावहारिक नतीजे। छोटे ख़रीदार के लिए plan फ़ीस कम दरों के फ़ायदे से भारी पड़ती है, इसलिए जब तक महीने का उपयोग अंतर साफ़ न दिखाए, pay as you go पर रहिए। बड़े backfill के लिए जिस महीने job चले उसमें कम दर वाले स्तर पर चले जाना सार्थक हो सकता है, और इतने बड़े ख़र्च पर contact पेज से enterprise व्यवस्था की बात करना भी तर्कसंगत है। तालिकाएँ मानती हैं कि GST plan फ़ीस पर भी लगता है, इसे invoice से पक्का कीजिए। उपयोग सफल response के बाद दर्ज होता है, इसलिए error पर ख़त्म हुई calls का शुल्क नहीं कटता, जबकि valid: false का जवाब कटता है। अपने रिटर्न का अंदाज़ा लगाने के लिए इस लागत की तुलना एक ग़लत जगह गए भुगतान और हाथ से जाँच में लगे कर्मचारी-समय से कीजिए। हम उद्योग का कोई आँकड़ा नहीं देते।

रोलआउट: sandbox, pilot, production

Sandbox। पूरा प्रवाह sandbox पर बनाइए, जहाँ response नमूना डेटा है और wallet नहीं कटता। sandbox PAN SNDBX0000A पर वैध और SNDBX9999F पर अवैध नतीजा देता है, और GSTIN की जोड़ी 09SNDBX0000A1Z5 व 09SNDBX9999F1Z5 है, जिनमें दूसरा रद्द पंजीकरण लौटाता है। बाक़ी इनपुट पर स्थिर पर मनमाना नतीजा आता है, इसलिए उन पर assertion मत लिखिए। भरोसा करने से पहले dashboard में ताज़ा test values देख लीजिए। फ़ैसले-तालिका के हर खाने, मुफ़्त जाँचों और batch के दोबारा शुरू होने के तर्क का test कीजिए।

Pilot। production access माँगिए, जो आपके संगठन की KYC मंज़ूरी और product-वार production आवेदन पर निर्भर है, और किसी एक business unit में नए vendors के लिए onboarding प्रवाह चलाइए जबकि AP साथ-साथ हाथ से जाँचता रहे। कुछ हफ़्ते नतीजे मिलाइए और हर असहमति लिख लीजिए।

Production। pilot वाली इकाई पर payment block चालू कीजिए, फिर इकाई-दर-इकाई बढ़ाइए। backfill स्तर के क्रम में चलाइए। wallet का balance ख़त्म होने से बहुत पहले अलर्ट रखिए। keys, scopes और IP allowlist के लिए sandbox बनाम production keys गाइड देखिए।

किन मापदंडों पर नज़र रखें

• बिना इंसानी समीक्षा के सक्रिय हुए vendors का हिस्सा, स्तर के हिसाब से।
• समीक्षा queue का आकार और सबसे पुराने मामले की उम्र।
• कारण के हिसाब से पक्की रोकें: अवैध PAN, निष्क्रिय पंजीकरण, अवैध खाता, नामों की असहमति।
• बैंक-बदलाव के अनुरोध, कितने रोके गए, और कितने बाद में असली निकले।
• खुले अपवाद वाले vendors जिन्हें फिर भी भुगतान मिला। बनावट से यह शून्य होना चाहिए, न हो तो payment block में रिसाव है।
• हर स्तर पर दोबारा-जाँच का कवरेज, आपके कार्यक्रम के मुक़ाबले।
• प्रति vendor calls। उम्मीद से ज़्यादा हों तो duplicate submissions या retry loops हैं।

जो ग़लतियाँ vendor जाँच को कमज़ोर करती हैं

• एक बार जाँचकर हमेशा के लिए भरोसा। स्थितियाँ बदलती हैं।
• vendor को जाँचना, खाते को नहीं। ज़्यादातर धोखा खाते में है।
• नामों का अक्षरशः मिलान। प्रत्यय और व्यापारिक नाम इसे बेकार कर देते हैं।
• GST पंजीकरण को असली कारोबार का सबूत मानना। वह दिखाता है कि एक स्थिति में पंजीकरण है, यह नहीं कि माल मौजूद है।
• जल्दबाज़ी को प्रक्रिया लाँघने देना। "अर्जेंट" अनुरोध ही सबसे आम हमला है।
• कर्तव्यों का बँटवारा न होना। एक ही व्यक्ति बनाए, मंज़ूर करे और भुगतान करे तो नियंत्रण बेकार है।
• पूरे पहचान-नंबर logs में लिखना। उन्हें application logs से दूर रखिए।
• PAN के प्रकार को अनदेखा करना। व्यक्ति का PAN बताने वाली कंपनी पर एक सवाल बनता है।

संबंधित API और गाइड

यहाँ इस्तेमाल हुए endpoints verification API reference में दर्ज हैं: GSTIN, PAN, bank account, CIN, Udyam और PAN to GSTIN। और गहराई के लिए GSTIN verification गाइड, business verification गाइड और errors गाइड पढ़िए। जो प्लेटफ़ॉर्म सप्लायर की जगह sellers जोड़ते हैं, उनके लिए marketplace seller verification पेज ज़्यादा सीधा है, और जो टीमें बार-बार भुगतान करती हैं वे payout से पहले bank account verification पढ़ें। उद्योग-वार सारे पेज solutions पेज पर हैं, और मौजूदा दरें pricing पर।

API reference एक नज़र में

{
  "referenceId": "SMV-20260927-8F42K7",
  "pan": "ABCDE1234F",
  "type": "Individual",
  "valid": true,
  "registeredName": "RAHUL KUMAR",
  "fatherName": "SURESH KUMAR",
  "panStatus": "VALID",
  "panStatusCode": "E",
  "panStatusDescription": "Existing and valid PAN",
  "nameMatchResult": "MATCH",
  "nameMatchScore": "100",
  "aadhaarSeedingStatus": "y",
  "aadhaarSeedingStatusDescription": "Aadhaar linked",
  "lastUpdatedAt": "2023-04-01",
  "message": "PAN is Valid"
}

{
  "referenceId": "SMV-20260927-9K21P4",
  "verificationId": "VRF-4M8Q2T7XB9KD",
  "gstin": "29AAICP2912R1ZR",
  "GSTIN": "29AAICP2912R1ZR",
  "valid": true,
  "legalNameOfBusiness": "UJJIVAN SMALL FINANCE BANK LIMITED",
  "tradeNameOfBusiness": "UJJIVAN SMALL FINANCE BANK",
  "centerJurisdiction": "I-A RANGE",
  "stateJurisdiction": "GUWAHATI - A - 1",
  "dateOfRegistration": "2017-09-30",
  "constitutionOfBusiness": "Public Limited Company",
  "taxpayerType": "Regular",
  "gstinStatus": "Active",
  "lastUpdateDate": "2022-03-01",
  "natureOfBusinessActivities": [
    "Retail Business",
    "Supplier of Services",
    "Recipient of Goods or Services",
    "Office / Sale Office",
    "Others"
  ],
  "principalPlaceAddress": "First Floor 3512-DISPUR Prithivi Mansion opp. KFC building G.S. Road, Lachit Nagar Assam 781007",
  "principalPlaceSplitAddress": {
    "buildingName": "Prithivi Mansion",
    "street": "G.S. Road",
    "location": "Lachit Nagar",
    "buildingNumber": "3512-DISPUR",
    "district": "Guwahati",
    "state": "Assam",
    "city": "Dispur",
    "flatNumber": "First Floor",
    "latitude": "26.1445",
    "longitude": "91.7362",
    "pincode": "781007"
  },
  "additionalAddresses": [
    {
      "address": "Mirza Santipur NH-37 Dist-Kamrup Rural PS-Palashbari, PO  Mirza Kamrup Assam 781125",
      "splitAddress": {
        "buildingName": "",
        "street": "NH-37",
        "location": "Santipur, Mirza",
        "buildingNumber": "",
        "district": "Kamrup Rural",
        "state": "Assam",
        "city": "Palashbari",
        "flatNumber": "",
        "latitude": "26.0926",
        "longitude": "91.5069",
        "pincode": "781125"
      }
    },
    {
      "address": "N.A.C.C.I. Foundation 3559-Tezpur CHAMBER BHAWAN Binjraj Road, P. o. and P.S. - Tezpur, Dist. Binjraj Road, P. o. and P.S. - Tezpur, Dist. Sonitpur Assam 784154",
      "splitAddress": {
        "buildingName": "CHAMBER BHAWAN",
        "street": "Binjraj Road",
        "location": "Tezpur",
        "buildingNumber": "3559-Tezpur",
        "district": "Sonitpur",
        "state": "Assam",
        "city": "Tezpur",
        "flatNumber": "",
        "latitude": "26.6338",
        "longitude": "92.8006",
        "pincode": "784154"
      }
    }
  ],
  "message": "GSTIN Exists",
  "legalName": "UJJIVAN SMALL FINANCE BANK LIMITED",
  "tradeName": "UJJIVAN SMALL FINANCE BANK",
  "registrationStatus": "Active",
  "principalPlaceOfBusiness": "First Floor 3512-DISPUR Prithivi Mansion opp. KFC building G.S. Road, Lachit Nagar Assam 781007"
}

{
  "referenceId": "SMV-20260927-3B71A0",
  "valid": true,
  "nameAtBank": "RAVI KUMAR",
  "bankName": "ICICI Bank",
  "utr": "017952100012345",
  "city": "Mumbai",
  "branch": "Andheri West",
  "micr": "400229002",
  "nameMatchScore": "100",
  "nameMatchResult": "GOOD_MATCH",
  "accountStatus": "ACCOUNT_IS_VALID",
  "accountStatusCode": "1",
  "ifscDetails": {
    "bank": "ICICI Bank",
    "ifsc": "ICIC0001234",
    "micr": "400229002",
    "address": "Andheri West, Mumbai",
    "city": "Mumbai",
    "state": "Maharashtra",
    "branch": "Andheri West"
  }
}

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