Brazilian State Tax ID Validator

How does the validation work?

State Tax ID length differs from one state to another, and each one relies on its own check-digit algorithm. The check here covers length and check digits for SP (12 digits), RJ (8), MG (13), RS (10), PR (10) and BA (9).

Everything runs inside your own browser and never leaves it.

Inscrição Estadual (IE): 27 algorithms for 27 jurisdictions

The Inscrição Estadual (IE) is the state-level tax registration of any legal entity (or natural person under produtor rural regime) that operates ICMS-bearing activities. Unlike the federal CNPJ — single algorithm, single authority — the IE is a federalized identifier: each of the 26 states plus the Federal District (27 jurisdictions total) operates its own SEFAZ, its own length, its own weights and its own check-digit algorithm. There is no single universal IE validator: any tool that claims otherwise is either incomplete or just running a length check.

For developers integrating Brazilian fiscal systems — NF-e, eSocial, SPED Fiscal, ICMS substitution tributária, EFD-Contribuições — IE validation is a per-state branch table. Mature libraries like inscricao-estadual (npm), validation-br (Python) and brazilian-utils (TypeScript) ship one validator function per state and dispatch by UF code.

Examples of state-specific algorithms

A small tour of the variety:

• SP: 12 digits with 2 check digits. DV1 uses weights 1,3,4,5,6,7,8,10 over the first 8 digits, modulo 11; DV2 uses weights 3,2,10,9,8,7,6,5,4,3,2 over the first 11 digits.
• RJ: 8 digits with a single check digit. DV uses weights 2,7,6,5,4,3,2 over the first 7 digits, modulo 11; if the remainder is 0 or 1, DV is 0.
• MG: 13 digits with 2 check digits, the famous "rule of zero insertion" — a 0 is injected at position 4 before computing DV1.
• DF: 13 digits in the format 07.XXX.XXX/XXX-XX, prefixed by 07, with 2 check digits computed by modulo 11 with weights starting at 4.
• RS: 10 digits, with the first three indicating the city (município) — useful for cross-checking against the IBGE municipal table.
• PR, BA, GO, CE: each has its own quirks — BA, for example, uses modulo 10 in some ranges and modulo 11 in others.

Use cases: NF-e, SPED, eSocial, ICMS-ST

IE validation is mandatory in several Brazilian fiscal obligations:

• NF-e emission: the issuer and the recipient IEs are required fields in the emit and dest tags. SEFAZ validates the format at the gateway and returns rejection codes (cStat=246 IE inválida) if the algorithm fails.
• SPED Fiscal (Sistema Público de Escrituração Digital): the IE field is mandatory in registers C100, D100 and others — invalid IE blocks the monthly file delivery to SEFAZ.
• eSocial: for legal entities, the IE is reported when applicable to ICMS contributors.
• ICMS substituição tributária: cross-state operations require the IE of the recipient state for correct ST-tax allocation.

Sintegra, IE Isento and the limits of offline validation

Sintegra is the public consultation portal of state tax data — historically the canonical way to confirm IE existence and status. Its availability is uneven: some states maintain active portals, others have migrated to their own SEFAZ portals, and a few have decommissioned the service. BrasilAPI also exposes a unified IE lookup endpoint that proxies the underlying state portals when available.

A peculiarity of the Brazilian system is the IE Isento: companies that are exempt from state registration (MEI in some activities, accounting offices, certain liberal professions) declare the literal string "ISENTO" in the IE field of NF-e and other documents. Validators must accept this string as a valid pseudo-IE for non-ICMS contributors. Conversely, a properly-formed IE may still be revogada (revoked): format and DV pass the math but the SEFAZ has cancelled the registration. Only a Sintegra/SEFAZ consultation confirms current validity.

Multi-establishment and multi-state companies

A company with branches across multiple states must register one IE per state of operation. The CNPJ stays the same (with a different branch suffix 0002, 0003, etc.), but each establishment carries its own state registration. ERPs must store IEs in a separate table keyed by (cnpj_branch, uf); storing a single IE per CNPJ is a recurring data model bug. Some banks request IE during business onboarding (PJ accounts), forcing the same multi-state mapping.

Practical pitfalls

• Treating "ISENTO" as a validation error — it is the official literal for non-contributors and must be accepted.
• Reusing a numeric CNPJ validator on the IE field "because it looks similar" — every state is different.
• Validating format only and assuming the IE is active — formal validation does not prove SEFAZ registration is current.
• Hardcoding masks per state in the UI: prefer a single text input and validate by UF after submission.
• Using a JSON Schema with a single regex; switch to a discriminator-by-UF or a custom validation hook.

FAQ

Is there a single algorithm valid for all states?

No. There are 27 different algorithms — one per state plus the Federal District. Length, weights and modulo rules differ. A validator must dispatch by UF.

Can I check whether the IE is currently active on SEFAZ?

Yes, through Sintegra or directly via the state SEFAZ portal, when available. Coverage is uneven across the federation; BrasilAPI offers a unified proxy that consolidates the working endpoints.

Is "ISENTO" a valid IE value?

Yes — for legal entities exempt from state registration (most MEIs, accounting firms, certain liberal professions). The NF-e XML accepts the literal ISENTO in the IE field instead of digits.

Does a valid format guarantee the IE is registered with SEFAZ?

No. Format and check-digit math only prove the number is well-formed. The IE may have been revoked, suspended or never issued. Confirming registration requires a Sintegra/SEFAZ query.

Does a single company have a single IE?

Not necessarily. A company operating in multiple states must register one IE per state. The CNPJ keeps the same root, but the branch suffix and the IE differ per establishment.