ITN-03 v1.3.0: O Que Mudou nos Schemas e o Que Pode Quebrar no Seu Arquivo

Por que essa versão importa

A ITN 003/2025 define o arquivo JSON que cada serventia envia mensalmente ao ONR, alimentando o ONR-CAD. Se você ainda não conhece o processo — quem envia, prazos, o que entra e o que fica de fora —, comece por ITN-03: o que é e como enviar os atos ao ONR.

Este artigo é sobre a versão 1.3.0 dos schemas. E ela importa por um detalhe que costuma passar despercebido: o campo version no arquivo gerado é um const no schema. Não é informativo, não é “melhor esforço” — ele precisa bater exatamente com a versão do schema usado na validação. Um arquivo marcado 1.2.0 validado contra o schema 1.3.0 é reprovado na primeira linha, antes de qualquer campo de imóvel ser olhado.

{
  "version": "1.3.0",        // const — tem que ser exatamente a versão do schema
  "cns": "123456",           // ^(?:\d{6}|\d{5}-\d)$
  "imoveis": [ { /* ... */ } ]
}

A raiz do envelope é additionalProperties: false. Qualquer chave extra ali reprova o arquivo.

Antes de tudo: contra qual schema você está validando?

O ponto que mais custa tempo de implementação não é nenhum campo novo — é garantir que o arquivo e o schema falam da mesma versão. A ITN-03 já teve três releases de schema, e quem acompanha o padrão desde o começo naturalmente acumula as três na pasta de documentação, baixadas em momentos diferentes:

Versão	Situação
1.0.0	Superada — corrigida pela 1.2.0
1.2.0	Superada — corrigida pela 1.3.0
1.3.0	Vigente — a que acompanha o validador oficial

O risco não é o erro barulhento. Se o seu arquivo diz 1.2.0 e você o valida contra o schema 1.2.0 que ficou guardado do ano passado, tudo passa — e ainda assim o arquivo está fora do padrão vigente. A reprovação só aparece lá na frente, no portal. Por isso vale fixar explicitamente qual schema o seu pipeline usa e conferir a cada nova versão da norma. A referência é sempre a que acompanha o validador oficial — o Anexo IV hoje é um build React standalone, que abre direto no navegador, sem servidor.

A versão anterior já tinha passado por uma limpeza parecida. Da 1.0.0 para a 1.2.0 foram corrigidos erros que reprovavam arquivos gerados conforme o próprio manual: a chave situação acentuada (virou situacao), Fuso_zona com maiúscula (virou fuso_zona), o campo fundido ccir_sncr (separado em ccir + cod_sncr), a ausência de condicao_parte e de bairro em dados_imovel, e filhos_brasileiros como boolean (virou inteiro 1/2/3). Vale o registro porque parte disso já foi assunto em ITN-03 na prática: 3 achados de uma implementação de referência — e a 1.3.0 continua nessa linha de acerto do padrão contra o dado real.

O que mudou da 1.2.0 para a 1.3.0

Mudança	Detalhe
+ decisao_jud	boolean no imóvel; true dispensa quase todas as obrigatoriedades
+ nao_CPF	boolean em dados_pessoa; true dispensa cpf_cnpj
coordenadas	maxLength de 3000 → 15000
numero_matricula	string livre → ^\d{1,10}$ (só dígitos)
fracao (urbano)	string "5.55%" → number 0.055555
rip, cat	numérico → string
cif	15 → 25 caracteres
cep	perde a máscara 00.000-000; aceita 00000000 ou 00000-000
condicao_parte	passou de condicional para não obrigatório
− certificacao_incra	removido do schema urbano (é campo rural)
+ data_averbacao	no rural

Abaixo, o que cada bloco significa na prática.

1. decisao_jud: a válvula de escape do cumprimento judicial

É a novidade de maior efeito. decisao_jud é um boolean no nível do imóvel e, quando true, o arquivo fica dispensado de quase toda a obrigatoriedade. Sobram apenas:

• tipo_imovel e o contexto (contexto_urbano / contexto_rural);
• motivo_envio;
• tipo_matricula_transcricao;
• numero_matricula (ou numero_transcricao).

Isso resolve um problema real. Quando o registro decorre de cumprimento de decisão judicial, o cartório frequentemente não tem — e não pode inventar — dados que a norma exigiria: CPF da parte, valor da transação, cadastros fiscais do imóvel. Antes, esse ato ou travava o arquivo ou obrigava a preencher campos com informação que a serventia não possui.

Vale notar que ela generaliza uma regra que já existia: o ato = 2 (abertura de matrícula de ofício ou por decisão judicial) já dispensava tudo além de numero_matricula, tipo_imovel e contexto. O decisao_jud estende esse alívio a qualquer tipo de ato.

O ponto de atenção para quem implementa: essa flag precisa vir do dado, não de um chute. Nos sistemas que descrevem o ato apenas em texto livre, a menção ao processo judicial existe na denominação ou no resumo do ato, mas não há um campo booleano correspondente. É uma extração nova a fazer.

2. nao_CPF: distinguir “não tem” de “não foi preenchido”

Em dados_pessoa, o novo nao_CPF (boolean) sinaliza que a parte não possui CPF/CNPJ e, com isso, dispensa o campo cpf_cnpj.

A mudança parece pequena, mas fecha uma ambiguidade que decide aprovação e reprovação: até então, um cpf_cnpj vazio significava as duas coisas ao mesmo tempo — “essa pessoa não tem documento” e “esse dado não foi preenchido no cadastro”. O ONR não tinha como diferenciar, e o implementador não tinha como declarar a primeira situação sem parecer estar na segunda.

3. numero_matricula: agora só dígitos

Essa é a mudança com maior chance de quebrar um arquivo que funcionava. O campo deixou de ser string livre e passou a exigir o padrão ^\d{1,10}$.

Na prática, deixam de passar:

• números com prefixo ou sufixo de livro (M-1234, 1234-A);
• separadores de milhar (12.345);
• espaços, traços ou qualquer letra.

Isso é especialmente relevante porque o restante da 1.3.0 caminhou na direção oposta — afrouxando máscaras. O numero_matricula é a exceção: enquanto cep e cpf_cnpj passaram a aceitar com e sem pontuação, ele ficou mais restrito. Se o cadastro guarda o número da matrícula como texto com decoração, é preciso normalizar antes de exportar.

4. Máscaras: o padrão finalmente aceita o dado como ele existe

Do lado bom, a 1.3.0 reconheceu que o mesmo dado circula em formatos diferentes:

• cep — aceita 00000000 ou 00000-000. A máscara 00.000-000, que a versão anterior impunha, saiu.
• cpf_cnpj — aceita 11 ou 14 dígitos, com ou sem pontuação, e contempla o CNPJ alfanumérico.

O CNPJ alfanumérico merece destaque: quem tratava o campo como numérico ou aplicava validação estritamente de dígitos precisa revisar. Não é uma mudança cosmética de formatação; é uma mudança na natureza do identificador.

5. Trocas de tipo: fracao, rip e cat

Três campos mudaram de tipo, e todos exigem ajuste no gerador:

• fracao (urbano) deixou de ser a string "5.55%" e virou número: 0.055555. Repare que não é só o tipo — é a escala. Enviar 5.55 como número, em vez de 0.055555, passa na validação de schema e comunica um valor cem vezes maior. É o tipo de erro que nenhum validador pega.
• rip (Registro Imobiliário Patrimonial) e cat (Certidão de Autorização de Transferência), ambos do bloco União, passaram de numérico para string, com padrões ^\d{1,13}$ e ^\d{1,15}$. É o acerto conceitual correto: identificador é rótulo, não quantidade — preserva zeros à esquerda e não passa por ponto flutuante. Foi exatamente o ponto que levantamos sobre o ccir_sncr nos achados da implementação de referência.

6. Ajustes menores, mas que reprovam arquivo

• cif passou de 15 para 25 caracteres — o Cadastro Imobiliário Fiscal das prefeituras varia muito de formato, e o limite anterior era apertado.
• condicao_parte (alienante/adquirente) deixou de ser condicional e passou a não obrigatório.
• certificacao_incra foi removido do schema urbano. Se o seu gerador ainda o envia em imóvel urbano, o arquivo é reprovado: dados_pessoa[] e dados_imovel[] usam additionalProperties: false, e qualquer campo fora da lista reprova o arquivo inteiro. Campo a mais é tão fatal quanto campo a menos.
• data_averbacao foi acrescentado no rural.

Duas divergências entre manual e schema

Ao confrontar os manuais 1.3.0 com os schemas 1.3.0, dois pontos não batem — e nos dois casos quem manda é o schema, porque é ele que roda na validação:

• georreferenciamento — o manual urbano marca como não obrigatório e o rural como obrigatório. Os dois schemas exigem. Trate como obrigatório sempre. E, se ele for true, o schema passa a exigir também o numero_poligono.
• ccir — o padrão é ^\d{11}$, ou seja, 11 dígitos, não 13. É um campo distinto do cod_sncr (12 a 13 dígitos, com ou sem máscara), que foi separado dele lá na 1.2.0 e ainda é confundido com frequência.

O que revisar no seu gerador

Um roteiro curto de conferência para quem já tinha arquivo válido na 1.2.0:

1. version — atualizar para "1.3.0" e garantir que a validação usa o schema da mesma versão.
2. numero_matricula — normalizar para dígitos puros; remover prefixos, pontos e traços.
3. fracao no urbano — converter de percentual em texto para número decimal, dividindo por 100.
4. rip e cat — serializar como string, preservando zeros à esquerda.
5. certificacao_incra — remover do payload urbano.
6. cpf_cnpj — aceitar CNPJ alfanumérico na entrada e na validação interna.
7. georreferenciamento — enviar sempre; se true, incluir numero_poligono.
8. decisao_jud e nao_CPF — passar a preencher; são os dois campos que transformam pendência em envio válido.

Os dois últimos itens são os que mais mudam o resultado. Eles não são apenas campos novos: são as duas portas que permitem enviar, de forma correta e declarada, atos que antes ficavam de fora por falta de dado que a serventia legitimamente não tem.

Como o RI-Online trata isso

O impacto de uma virada de versão de schema não deveria chegar ao balcão. No RI-Online, a exportação ao ONR já valida cada imóvel contra o schema oficial antes de gerar o arquivo e exporta apenas os imóveis válidos, listando à parte as matrículas pendentes e o motivo de cada uma. Como o portal do ONR reprova o lote inteiro por causa de um único imóvel inválido, essa validação prévia é o que evita o retrabalho de reenviar tudo.

Na prática, para o cartório, uma mudança como a da 1.3.0 significa: os campos que passaram a ser exigidos ou reformatados aparecem na lista de pendências com a matrícula e o campo exatos, e o arquivo continua saindo pronto para upload — urbano e rural em arquivos separados, como a norma exige.

O passo a passo do envio está na central de ajuda:

1. Envio de atos ao ONR: visão geral
2. Gerar e baixar o arquivo do ONR
3. Resolver pendências de cadastro (CIB, CCIR, CAR)
4. Enviar o arquivo no portal do Mapa

Em resumo

A 1.3.0 é uma versão de maturidade do padrão: ela reconhece que o dado real nem sempre existe (decisao_jud, nao_CPF), que o mesmo dado circula com e sem máscara (cep, cpf_cnpj), e que identificador é string, não número (rip, cat). São correções na direção certa.

O custo de adoção está concentrado em três pontos: o numero_matricula que ficou mais restrito, a fracao que mudou de tipo e de escala, e o certificacao_incra que precisa sumir do payload urbano. Some-se a isso a atenção com a versão do schema que você usa para validar — com três convivendo no mesmo pacote e PDFs desalinhados dos .json, essa é a checagem que economiza mais tempo.

Dúvidas, correções ou sugestões de tema são bem-vindas em suporte@mupisystems.com.br.