The alphanumeric CNPJ is no longer a future change. On July 31, 2026, the Federal Revenue reported the generation of the first CNPJ in this format. But this does not mean a conversion of existing registrations: CNPJs already issued remain valid and do not need to be replaced. The new standard reaches new registrations and is being introduced gradually — therefore, a new CNPJ can still only consist of numbers.
For HR, payroll and teams responsible for registrations, this coexistence between formats is the central point. The system needs to continue accepting the numerical CNPJ it already knows and, at the same time, stop rejecting a valid application just because it contains letters.
What changed in the CNPJ and what didn't
The identifier continues with 14 positions and maintains the same visual mask structure. In the new format, the first 12 positions, which cover the root and order of establishment, can contain letters and numbers; the last two characters remain numeric check digits. The Revenue also maintained the calculation in module 11, but validation now considers the conversion of alphanumeric characters according to the technical rule defined for the new standard.
This creates two different risks. The first is obvious: fields configured to accept only numbers can block registration even before any validation. The second is less visible: a screen may start accepting letters, but the digit validator, integration or database layer continue to treat CNPJ as an exclusively numeric value.
The Revenue expressly advises that the systems are prepared to receive the new format. In the July 31 communication, the agency cited the need to review registrations, integrations between systems and validation rules that only accept numeric characters.
A company with an old CNPJ can also find letters in a new branch
It is not safe to conclude that a company is outside the impact just because its headquarters has an old numerical CNPJ. The Revenue clarifies that the alphanumeric format also covers new registrations of branches of already established companies. The head office and existing branches remain with their current numbers, but a branch created can now receive letters in the part corresponding to the order of establishment.
This is a particularly relevant scenario for HR and payroll. A company may continue operating with the same historical roots and, when registering a new establishment, discover that some admission, capacity, accounting integration or obligation submission routine rejects the new identifier.
The first alphanumeric CNPJ issued by the IRS on July 31 was destined for a branch. The case confirms that the situation is not just a laboratory example: lettered inscriptions already exist in production.
eSocial already has artifacts for alphanumeric CNPJ in production
In eSocial, adaptation should also not be treated as preparation for a future date. The technical documentation lists version S-1.3 XSD schemas specific to alphanumeric CNPJ as in production as of July 1, 2026. The portal also provides an “eSocial Communication Package v.1.6 - Alfa”.
There is another technical detail that deserves attention from sheet suppliers. In eSocial layouts, the employer's registration field is defined as a character field and can take on lengths of 8, 11 or 14 positions, depending on the type of registration and the context. For legal entities, there are situations in which the root of eight positions is informed and others in which the full CNPJ is used.
Therefore, reviewing only the “complete CNPJ” visual field is not enough. Internal routines that extract the root, group establishments, identify employers or form files also need to stop assuming that these positions will necessarily be numerical.
What HR, payroll and records need to test now
The test must go through the entire process, and not just check whether a screen accepts typing. The priority fronts are:
- Registration entry and editing: check if CNPJ fields allow letters in the expected positions and do not apply “numbers only” filters before validation.
- Storage: locate database columns, variables, import routines or integrations that convert the CNPJ to a numeric type. An alphanumeric identifier must be preserved as a sequence of characters, including any leading zeros.
- Normalization and mask: when removing periods, slashes and hyphens for processing, the system cannot eliminate the letters. If the application already works with formatted and unformatted CNPJ, both paths must be retested.
- Check digit: allowing letters is not enough. Own validators or old libraries need to implement the valid rule for the alphanumeric CNPJ and, simultaneously, continue to correctly validate existing numeric CNPJs.
- Branches and establishments: especially test the combination of an existing company with numeric CNPJ and a new branch with alphanumeric characters. Searches, groupings by root and links between headquarters and establishments cannot depend on conversion to number.
- eSocial: check the version of the XSD schemas and components used by the sheet system, in addition to the generation, validation, transmission and treatment of event returns that carry CNPJ or its root. eSocial already maintains the specific XSD for the new standard in production.
- External integrations: repeat the test on APIs, import and export files, accounting systems, benefits, time, health and occupational safety, ERPs and other applications that receive or return the identifier. An application adapted in isolation will not solve an integration that continues to reject letters.
A good acceptance criterion is simple: the same chain must be able to process an old numeric CNPJ, a valid alphanumeric CNPJ and a deliberately invalid identifier — rejecting the third for the correct reason, not the simple presence of a letter.
Don't wait for a real CNPJ to appear in your registration to discover the error
The IRS itself provides a simulator to generate fictitious alphanumeric registrations for head offices and branches. The service also allows you to validate the formation and the check digit and informs that it can generate up to a thousand registrations per user, without consulting or using real data from the Revenue database.
This makes it possible to set up a mass of tests before a new establishment, supplier or other legal entity with CNPJ letters reaches a production routine.
The priority, therefore, is not to change existing CNPJs or re-register. It is to eliminate from applications the premise that “CNPJ is always a number”. Federal Revenue and eSocial already operate with the new reality; For HR and payroll, the work now is to locate where this premise is still hidden in fields, validators, databases and integrations.
