A supplier has sent an invoice, the legal name differs slightly from the onboarding form, and the CIN field contains spaces and a hyphen. Finance wants the vendor approved today, while engineering needs a dependable answer from the MCA registry rather than another manual search. A disciplined process to check a company CIN number matters.
The practical pattern is simple: validate the structure first, look up the entity through the Ministry of Corporate Affairs, then compare only the fields your billing or KYC workflow needs. The MCA portal remains useful for investigations, but production systems need a validator-first design that can tolerate HTML changes, rate limits, unavailable records, and human review.
Table of Contents
- Why You Need to Check a Company CIN Number
- Understanding the 21-Character CIN Format
- Running a CIN Lookup on the MCA Portal
- Programmatic CIN Validation With an API
- Comparing Manual and Programmatic Lookup Approaches
- Wiring CIN Checks Into Billing and KYC Flows
- Production Checklist for CIN Verification
Why You Need to Check a Company CIN Number
A Corporate Identification Number, or CIN, is a foundational company identifier in India, not just a lookup code. The Ministry of Corporate Affairs issues it through the Registrar of Companies. The MCA's CIN search service connects a submitted identifier with the company record held in the corporate registry.
That connection matters when a legal name appears on an invoice, onboarding form, supplier record, or payment instruction. Checking the CIN before saving the record can expose a mismatch, prevent duplicate vendors created from spelling variations, and keep the legal name on an invoice aligned with the registry.
What a lookup can confirm
An MCA lookup may return master data including the company's legal name, registration status, date of incorporation, registered office address, authorised capital, and director details. For a billing or KYC integration, store the CIN, returned legal name, status, registered office, and registration details, while retaining the raw response and lookup time for audit purposes. Supplier screening can use the remaining fields when the review requires them.
A CIN is a deterministic matching key, not a complete risk decision. A valid identifier does not prove that the company is operating in practice, meeting every obligation, solvent, currently trading, or controlled by the individuals named in an application. Public MCA data can also be delayed, incomplete for a particular investigation, or unavailable when the portal is rate-limited.
Practical rule: A CIN confirms an entity record. It does not replace beneficial-owner verification, tax registration checks, bank-account ownership confirmation, sanctions screening, or broader risk review.
Run syntax validation before contacting MCA, then compare the returned company name, registered office, status, and registration details with the customer's or vendor's documents. Remove spaces and hyphens for comparison, but preserve the submitted value for audit logs. Punctuation, transliteration, and secondary registration numbers can produce harmless differences, so send material mismatches to manual review instead of automatically rejecting a potentially legitimate business.
Understanding the 21-Character CIN Format
A CIN is a 21-character alphanumeric identifier with a structured pattern. Its segments encode company attributes including listing status, industry classification, state or union territory, incorporation year, company category, and the ROC registration number. That structure lets one identifier carry several compliance signals, but it also creates format gotchas for developers.
A practical parser should remove spaces and hyphens before validation while retaining the original input for audit logs. The canonical value should be stored in uppercase, because users may paste a mixed-case value from a document or spreadsheet.
CIN character positions
| Positions | Value pattern | Meaning |
|---|---|---|
| 1 | L or another valid status character |
Listing status |
| 2 to 6 | Alphabetic segment | Industry or economic activity classification |
| 7 to 8 | Alphabetic segment | State or union territory code |
| 9 to 12 | Numeric segment | Year of incorporation |
| 13 | Usually Z |
Fixed separator or special character |
| 14 to 19 | Numeric segment | Company registration number |
| 20 to 21 | Numeric segment | Final CIN characters used in the identifier structure |
The commonly documented representation can be written as LUUUUUA AA AA1ZZZZZZ600000 without spaces, but don't turn a visual example into an existence test. Historical registrations and exceptions mean that syntax validation can identify malformed input, not prove that the MCA assigned the value to a legal entity.
For an implementation, split the value into named fields rather than relying only on one regular expression. Reject impossible state codes, malformed lengths, unexpected separators, and non-numeric year or registration segments before making a remote request. Compile the expression or parser for the active runtime, and test it with valid examples from more than one company category.
A registry lookup remains mandatory after the local check. This guide to company identification numbers provides useful context for separating identifier format from authoritative company verification.
Running a CIN Lookup on the MCA Portal
A supplier's invoice arrives with a CIN that differs from the onboarding document by one character. For a one-off review, open the MCA portal, enter the CIN or legal company name, complete the displayed verification step, and inspect the matching master record.
Enter a supplied CIN exactly after checking for transcription errors. If it is missing, search by legal name, review the candidate results, and identify the correct CIN from the master record. Name search is less deterministic, so a familiar-looking result is not enough to approve a supplier.
Read the response as a record, not a verdict
First confirm that the CIN and legal name correspond to the invoice or onboarding document. Then review only the fields needed for the decision:
- Status: Check for active, struck-off, amalgamated, or another status that requires escalation.
- Identity: Compare the legal name, company category, class, and registration details.
- Dates and location: Review the incorporation date, registered office, state code, and reporting division.
- Capital fields: Store authorised and paid-up capital when displayed, but do not treat either field as a complete measure of financial health.
- Related records: Use separate MCA services for charges, directors, or filing history. One response may not contain every related record, and public data may not be current.
For billing and KYC, extract the canonical CIN, legal name, status, incorporation date, registered office, state code, and registration details. Supplier screening may also need capital fields and related-record checks. Storing selected fields makes downstream matching and review clearer than copying an entire HTML page into an operational record.
Save an evidence copy with the retrieval date. Public pages can change, access may be rate-limited, and HTML structure can break a scraper. Manual lookup works well for investigations, sampling, and disputed matches, but it is a poor primary dependency for an uninterrupted billing pipeline.
A practical manual path is:
- Search by CIN or company name.
- Open the matching master record.
- Compare identity and address fields.
- Record status and relevant dates.
- Save the result and retrieval timestamp.
- Escalate discrepancies instead of guessing.
The portal can support exceptional customer-facing checks. High-volume workflows should pair local validation with a permitted data provider and a human-review queue.
Programmatic CIN Validation With an API
A production CIN flow should reject obvious errors before it contacts an external service. The local validator can normalize whitespace and hyphens, enforce the 21-character structure, and reject impossible segments. It shouldn't claim that the company exists until the API or MCA-backed provider returns a matching record.
A provider-specific REST request might look like this:
{
"cin": "L12345AB2020Z123456600000"
}
The exact endpoint, authentication scheme, and response contract depend on the provider you select. A useful response shape should contain machine-readable fields rather than a block of HTML:
{
"valid": true,
"cin": "L12345AB2020Z123456600000",
"company_name": "Example Legal Entity Private Limited",
"status": "Active",
"state_code": "AB",
"registration_date": "2020-01-01",
"classification": "12345",
"source": "MCA",
"retrieved_at": "2026-08-27T10:30:00Z"
}
The values above are illustrative field shapes, not a real company record. Your adapter should map the provider's actual response into an internal type, for example:
CINVerification {
canonical_cin
legal_name
status
state_code
incorporation_date
industry_code
source
retrieved_at
verification_state
}
Persist the canonical CIN, legal name, status, state code, incorporation date, classification, source, and retrieval timestamp. Keep raw responses in restricted evidence storage only when your retention and privacy controls allow it. Billing usually needs a smaller projection than a complete MCA master record.
Make failure states explicit
Put credentials in an authentication header, never in the request body or logs. Use an idempotency key derived from the tenant, workflow object, and canonical CIN so retries don't create duplicate verification events. A timeout, provider outage, or registry synchronization delay shouldn't be stored as not_found.
Use separate states such as:
syntax_invalidverifiednot_founddata_unavailableprovider_errormanual_review
That distinction prevents a temporary failure from blocking a legitimate supplier. Cache successful results at the verification layer, not in the browser, and attach an expiry policy that your compliance owner accepts. A shorter policy may suit high-risk onboarding, while a longer one can reduce repeated calls for stable supplier records. Recheck on material changes instead of assuming a cached result remains correct forever.
For broader implementation patterns, this company registration validation guide is a useful reference point. The key engineering decision is to keep the provider behind an adapter, so you can change vendors or introduce an MCA fallback without rewriting invoice and KYC business logic.
Comparing Manual and Programmatic Lookup Approaches
Manual MCA searches and API-driven checks solve different problems. The portal gives an operator direct visibility into a public record, while an API gives software a predictable contract for repeated decisions. Neither method should be treated as universally superior.
| Dimension | MCA Portal (Manual) | Programmatic API |
|---|---|---|
| Cost per check | No separate API call fee, but staff time and operational overhead still matter | Usually depends on provider pricing and usage terms |
| p95 latency | Variable because a person completes the search and the portal may respond inconsistently | Designed for repeatable machine-to-machine requests, subject to provider and registry availability |
| Rate limits | Can include verification steps, access controls, and throttling | Governed by the provider's quota, concurrency, and retry policy |
| Manual operator effort | High for every lookup, especially when names or addresses differ | Low for clear matches, with operators handling exceptions |
| Audit trail quality | Strong when staff save the result and retrieval date, inconsistent when they don't | Consistent when the system stores request, response, source, and timestamp |
| Best fit | Low-volume supplier reviews, one-off investigations, escalated KYC cases | Checkout, signup, billing, reconciliation, and bulk screening |
HTML scraping sits in the least comfortable middle ground. It appears inexpensive at first, but page changes, CAPTCHA or similar verification steps, IP-based throttling, outages, and altered field labels can break a production integration without a versioned contract. A scraper also has to interpret presentation markup, which is a poor substitute for typed status values and documented error codes.
Choose by workflow
Use the portal when a human needs to inspect the broader master record, investigate a mismatch, or sample automated results. It works well for a small supplier review where context matters more than response uniformity.
Use an API when a CIN arrives during checkout, signup, invoice creation, or a bulk supplier import. The machine-readable result supports deterministic branching, retries, caching, and consistent audit events. You may pay per call, but that cost is easier to model than hidden engineering time spent repairing a scraper.
The right production design is usually hybrid. Let software handle syntax and clear matches, then send ambiguous or high-impact cases to an operator with a direct MCA lookup path.
Wiring CIN Checks Into Billing and KYC Flows
Don't put every CIN check at the first keystroke. Run the local format validator as the user leaves the field, then perform the authoritative lookup when the customer submits the legal entity details or before your system finalizes the invoice. This keeps the interface responsive while ensuring that the approval decision uses a server-side result.
For billing, store the fields that explain why the invoice was accepted:
- Canonical CIN: The normalized identifier used for matching.
- Submitted CIN: The original value, if retention is appropriate for your audit needs.
- Legal company name: The registry-returned name used on the customer or supplier record.
- Status: The result at the time of verification.
- Registered office and state code: Useful for reconciliation and identity comparison.
- Incorporation date and classification: Store when your KYC or supplier policy uses them.
- Source and retrieval timestamp: Record whether the result came from an API, MCA review, or another permitted provider.
Don't dump the entire master record into every invoice row. Keep the invoice projection small and link it to a versioned verification record that preserves the evidence and decision history.
Place rechecks around business events
Existing suppliers need revalidation when their identity data changes, not only when a person opens the account. Trigger a check after an address change, a GST update, a payment-terms change, a legal-name edit, or a new bank account request. You can also schedule periodic review according to your risk policy, but the interval should be a controlled configuration rather than a hard-coded assumption.
Route data_unavailable, conflicting names, changed status, and address mismatches to manual review. An exact CIN match with a harmless punctuation difference in the name can proceed under a documented normalization rule, while a different legal entity or unexpected status should pause payment or onboarding.
For teams comparing build and buy options, a KYB verification platform can provide a broader workflow around business verification. For a developer-focused view of tax and identity workflows, see KYC and tax ID verification use cases.
Log the requester, tenant, workflow object, canonical CIN, provider, response state, retrieval timestamp, and final decision. Redact personal data and credentials from application logs. That evidence gives finance and compliance teams a defensible explanation when a supplier disputes a rejected invoice or a customer asks why onboarding paused.
Production Checklist for CIN Verification
Before shipping, turn the following into acceptance criteria for the integration:
- Run a client-side regex check before any network call, while keeping the server as the authority.
- Revalidate the format server-side after normalizing spaces, hyphens, and letter casing.
- Perform an MCA-backed lookup through the official portal for manual cases or a permitted provider for automated flows.
- Compare the returned legal name with the submitted business documents using controlled normalization.
- Check the incorporation date when the onboarding policy requires confirmation of the company record.
- Validate the state code against the parsed CIN segment and the returned registered address.
- Confirm the ROC or reporting division where jurisdictional review matters.
- Review listing status and preserve the returned value in the verification record.
- Verify company status, including escalation for strike-off or amalgamated results.
- Complete a final manual audit for ambiguous results, material mismatches, or high-risk suppliers.
Also cache verified results with a policy-approved expiry, handle provider rate limits with exponential backoff, redact PII in logs, and preserve every lookup with its requester and timestamp. Queue status changes for re-review after onboarding, and keep a controlled fallback to the MCA portal when an API response is ambiguous. If your team is collecting registry data across systems, guidance on web data collection for B2B APIs can help frame the operational and reliability concerns.
A production check should extract only the fields required for billing, KYC, and supplier screening. That keeps the schema maintainable, reduces unnecessary data retention, and leaves the MCA portal available for the cases where software shouldn't make the final call.
TaxID provides a developer-focused REST API for validating supported tax and company identification numbers, returning structured validation status, company name, and address for supported jurisdictions. If you're building billing or onboarding workflows that need reliable identifier checks, visit TaxID to review the API and documentation.