---
title: "2026.9 - Responsável técnico próprio na NF-e e na NFC-e (infRespTec)"
description: "Quem desenvolve o próprio sistema emissor já pode declarar a própria empresa no grupo infRespTec da NF-e e da NFC-e, com credenciais CSRT por UF. Resolve a rejeição 974."
source_url: https://nfe.io/docs/release-notes/2026-9-responsavel-tecnico-infresptec
last_updated: 2026-09-04
---

# Responsável técnico próprio na NF-e e na NFC-e

> **Para quem é este comunicado:** clientes que **desenvolvem o próprio sistema emissor** de NF-e ou NFC-e e já são credenciados como fornecedores de sistema na SEFAZ da UF onde emitem.
>
> **O que muda no seu lado:** nada, se você não se encaixa acima — o comportamento padrão continua idêntico. Se você se encaixa, passa a existir um cadastro que antes não existia, e que resolve a rejeição 974 sem precisar apontar a NFE.io como sua fornecedora de sistema.

## O problema que isso resolve

O grupo `infRespTec` da NF-e (modelo 55) e da NFC-e (modelo 65) declara quem responde tecnicamente pelo sistema emissor. Até agora a plataforma sempre declarava os dados da **NFE.io**.

A SEFAZ não escolhe quem é o responsável técnico: ela compara o CNPJ declarado com o fornecedor de sistema reconhecido no cadastro **daquele emitente**. Quando não bate, a nota é recusada:

> **Rejeição 974 — Informado grupo de Responsável Técnico com CNPJ divergente do cadastro na SEFAZ** (NT 2018.005)

Consequência: um cliente que desenvolve o próprio emissor e já está credenciado como fornecedor na UF **não conseguia** emitir por nós naquele estabelecimento. A única saída era apontar a NFE.io como fornecedora no cadastro da SEFAZ — um arranjo que nem sempre é o que o cliente quer.

## O que passou a existir

O responsável técnico agora é resolvido **nota a nota**, em três camadas:

| Camada | Onde cadastrar | Cobre CSRT? |
|---|---|---|
| 1 — **Empresa** | `PUT /v3/companies/{company_id}/technicalresponsible` | Sim |
| 2 — **Subscription** | `PUT /v3/Subscriptions({subscriptionId})/TechnicalResponsible` | Não |
| 3 — **Padrão NFE.io** | nada a cadastrar | Sim, mantido pela plataforma |

A camada 2 atende quem opera **várias empresas sob a mesma subscription**: cadastre uma vez e vale para todas as empresas sem responsável técnico próprio.

### Credenciais CSRT por UF

Onde a UF exige, o grupo leva também `idCSRT` e `hashCSRT`. Aceitar o responsável técnico do cliente implica custodiar o **CSRT** dele:

- Cadastro por UF em `PUT /v3/companies/{company_id}/csrt`, **até 5 por UF**, `idCSRT` de 1 a 5 (NPF 063/2012, itens 2.6 a 2.8).
- O código **nunca** é devolvido em resposta, nem gravado em cache distribuído, em log ou nos eventos da nota. No XML vai apenas o `hashCSRT`, derivado do código e da chave de acesso.
- O CSRT é **exclusivo da empresa** — não existe na subscription, porque a Receita Estadual o emite por empresa e UF.

### Quais UFs exigem o quê

| Exigência | UFs | Modelos |
|---|---|---|
| Validar o **CNPJ** do `infRespTec` | AM, MS, PE, PR, SC e TO (desde 2019) | NF-e e NFC-e |
| Exigir **`idCSRT` e `hashCSRT`** | **Paraná** | **NF-e (modelo 55)** |

## O que NÃO muda

- **Nenhum campo novo na emissão.** A resolução é automática, a partir do cadastro — o payload de emissão de NF-e e NFC-e é o mesmo.
- **Empresa sem cadastro emite XML idêntico** ao de antes desta mudança, campo por campo.
- **Cadastrar na NFE.io não credencia ninguém na SEFAZ.** O credenciamento como fornecedor de sistema continua sendo ato administrativo, feito no portal da UF.

## Detalhes que valem atenção

**Cache de 1 hora.** O resultado resolvido é guardado por uma hora, por empresa e UF. Depois de cadastrar ou remover, a mudança pode levar até esse tempo para aparecer nas notas — inclusive quando o resultado é "usar o padrão da plataforma".

**Coerência entre CNPJ e CSRT.** Numa UF que exige CSRT, se a camada tem responsável técnico mas não tem credencial para aquela UF, a resolução **desce um degrau** em vez de misturar as origens — declarar o CNPJ de uma camada com o hash de outra é rejeição 974 garantida.

**Falha de cadastro não derruba a emissão.** Indisponibilidade ou timeout na leitura fazem a resolução descer a cadeia; a nota sai.

**Reserialização preserva o hash.** Baixar o XML de uma nota já autorizada devolve o `hashCSRT` original, mesmo que a credencial tenha sido rotacionada depois.

## Como começar

1. Credencie-se como fornecedor de sistema na SEFAZ da UF (no Paraná, no UPD da Receita Estadual) e obtenha os códigos CSRT, se a UF exigir.
2. Cadastre o responsável técnico na empresa — ou na subscription, se o mesmo responsável vale para várias empresas.
3. Cadastre as credenciais CSRT na empresa, para cada UF que exigir.
4. Emita e confira o grupo `infRespTec` no XML autorizado.

O passo a passo completo, com os contratos, as regras de validação e os códigos de erro, está em **[Responsável técnico (infRespTec)](/documentacao/gerenciamento-empresas/responsavel-tecnico/)**.

## Referências

- [Responsável técnico (infRespTec)](/documentacao/gerenciamento-empresas/responsavel-tecnico/) — guia completo
- [Habilitar o fornecedor e emissor de NF-e no Paraná](/como-habilitar-o-fornecedor-e-emissor-de-nota-fiscal-nfe-mercadoria/) — o caminho alternativo
- NT 2018.005 — regra de validação 974 e obrigatoriedade de `idCSRT`/`hashCSRT`
- NPF 063/2012 (Receita Estadual do Paraná), itens 2.1 a 2.8 — fornecedor de sistema, credenciamento no UPD e emissão de até 5 códigos CSRT