cAut na NF-e: autorização do pagamento, não protocolo fiscal

cAut, em /nfeProc/NFe/infNFe/pag/detPag/card/cAut, identifica o número de autorização da transação com cartões, PIX, boletos e outros pagamentos eletrônicos no contexto documentado. Ele pertence ao pagamento. Não é o protocolo que a SEFAZ retorna ao autorizar a nota.

Qual retorno fornece cAut

Use o dado de autorização documentado pelo prestador ou sistema de integração para a transação daquele detPag. Preserve a associação com o valor, meio e instituição correspondentes. Uma confirmação genérica de que o pedido foi pago não fornece necessariamente esse identificador.

O código de autorização, um NSU, um identificador de pedido ou uma referência interna de gateway podem ter significados diferentes. Só mapeie o campo do prestador para cAut quando seu contrato documentar essa equivalência. Não escolha qualquer número do comprovante por semelhança nem use a chave de acesso da nota. idTermPag identifica o terminal, que pode realizar muitas transações; não substitui a autorização individual.

Tamanho atual e exigência contextual

A NT 2023.004 ampliou o campo, descrito com 1 a 128 caracteres; a estrutura conferida confirma esse limite. O tamanho antigo de 1 a 20, encontrado em documentação anterior, não é a referência atual para esse campo. Ele é texto: zeros iniciais e caracteres do identificador precisam ser preservados, com escapamento XML se necessário.

cAut aparece zero ou uma vez em card. Para pagamento por cartão integrado tpIntegra=1, YA05-10 documenta a exigência de CNPJ da instituição e código de autorização, aplicação opcional a critério da UF e exceção histórica para emissão anterior a 01/04/2016. A ausência pode resultar 392 nas condições da regra. A tabela atual também observa que as UF podem exigir o código de transação no PIX dinâmico 17; a existência do campo opcional não elimina essas exigências contextuais.

Exemplo com identificador textual

Fragmento parcial e sintético de card, sem os demais grupos da nota e sem aptidão para transmissão:

<card xmlns="http://www.portalfiscal.inf.br/nfe">
  <tpIntegra>1</tpIntegra>
  <CNPJ>12345678000195</CNPJ>
  <cAut>AUT-2026-000123</cAut>
  <idTermPag>TERMINAL-01</idTermPag>
</card>

AUT-2026-000123 é uma autorização ilustrativa; TERMINAL-01 identifica um equipamento ilustrativo. Nenhum deles atesta pagamento real ou autorização fiscal. Num cenário em que o prestador devolve um código com zeros iniciais, converter para inteiro poderia corromper a identificação. Truncar arbitrariamente para 20 caracteres também poderia perder informação de uma autorização válida no contrato atual.

Como investigar ausência ou código trocado

Na 392, confira a integração declarada e se instituição/autorização estão presentes no mesmo detalhe. Confronte o retorno bruto autorizado do prestador com o dado armazenado e o XML gerado; procure perda de mapeamento, limpeza de string ou associação com outra transação. Se não houve retorno de autorização, não invente o código nem declare integração diferente só para passar.

Quando o texto excede o limite ou contém caracteres sem escapamento, investigue se foi enviado um objeto inteiro, URL ou mensagem em vez do identificador. Corrija a origem e serialização do rascunho e valide novamente. Não gere novo pagamento para obter outro código e não altere um XML assinado.

Se o pagamento ocorreu depois da emissão, a NT 2024.002 trata o ECONF em contrato próprio, que também possui cAut; isso não é inclusão retroativa do campo na nota assinada. A aplicabilidade de evento e eventual obrigação estadual precisam ser confirmadas com o documento e a operação, sem confundir a autorização eletrônica com confirmação fiscal. Veja tpIntegra e idTermPag e a identificação do terminal.

Fontes oficiais

• NT 2023.004 — Informações de Pagamentos e Outros, 1.20; p. 3–6, 11–12, 14–15.
• MOC 7.0 — Anexo I, 7.0; Grupo Y/YA, p. 61–62 e 125–126.
• Tabela de meios de pagamento, Publicada SVRS 04/03/2026; Plan1!A2:E26.
• NT 2024.002 — Evento de Conciliação Financeira ECONF, 1.00; seções 1–3.