Rechazo 204 de la NF-e: NF-e duplicada, qué significa y cómo resolverlo
El rechazo 204 indica que la SEFAZ ya tiene una NF-e con el mismo modelo, estado, emisor, serie y número. Por qué ocurre y cómo resolverlo sin emitir de nuevo.

El rechazo 204 de la NF-e tiene el texto oficial Rejeição: Duplicidade de NF-e [nRec:999999999999999] ("NF-e duplicada"). Según el Anexo I del Manual de Orientación al Contribuyente (MOC), se devuelve cuando la SEFAZ ya tiene registrada una NF-e con el mismo modelo, estado (UF), CNPJ o CPF del emisor, serie y número, y esa factura no está cancelada ni denegada. En otras palabras: esa numeración ya la usó una factura que sigue vigente.
La corrección empieza por consultar la clave de acceso antes de cualquier reenvío. Si la factura figura como autorizada, ella es el documento fiscal de la operación: lo que corresponde es recuperar el XML autorizado e imprimir el DANFE a partir de él, no emitir otra. La guía de procedimientos de la SEFAZ-PE describe exactamente eso para el rechazo 204: consultar la situación de la factura en la SEFAZ y, si hace falta, descargar el XML mediante la consulta completa del Portal Nacional de la NF-e, con el certificado digital de la empresa.
Por qué ocurre el rechazo 204
La regla existe por la clave natural. El MOC 7.0 define que la identificación única de una NF-e a efectos tributarios es el conjunto de UF, CNPJ o CPF del emisor, serie, número, modelo y ambiente de autorización, y que el sistema de autorización rechaza nuevas solicitudes cuando encuentra una duplicidad de esa clave. Cambiar otros datos de la factura no sirve: si modelo, UF, emisor, serie y número coinciden con una factura autorizada, la SEFAZ la rechaza.
El caso más común es el reenvío. La SEFAZ-PE lo resume: el contribuyente transmitió la factura, fue autorizada con la misma clave de acceso y está intentando transmitirla de nuevo. El documento Consumo Indevido do Ambiente de Autorização (uso indebido del ambiente de autorización), publicado en el Portal de la NF-e, relata los dos orígenes típicos: empresas sin un control efectivo de la numeración, que envían facturas nuevas con un número ya autorizado, y aplicaciones que, por un error de programación, quedan en bucle reenviando el mismo lote y reciben siempre el error de factura duplicada.
Por eso el 204 suele aparecer después de una falla de comunicación: la factura fue autorizada, pero la respuesta no llegó al sistema emisor, que vuelve a intentarlo. El mismo documento indica que, si se pierde el número de recibo del lote, la empresa debe consultar individualmente la clave de acceso de cada NF-e del lote y decidir, según el resultado, si la factura fue autorizada o no. La consulta de la situación actual de la NF-e en la base de la SEFAZ es un servicio síncrono que recibe la clave de acceso.
Detalles del Anexo I y rechazos vecinos
El Anexo I agrega dos observaciones útiles. En la respuesta asíncrona, la SEFAZ puede devolver el número de recibo del lote (nRec) junto con el mensaje. Y, a criterio de la UF, cuando el DigestValue de la factura enviada es igual al de la NF-e ya autorizada, la SEFAZ puede devolver el propio protocolo de autorización en lugar de solo rechazar.
No hay que confundir el 204 con dos rechazos vecinos de la misma regla. El 539 (Duplicidade de NF-e com diferença na Chave de Acesso, duplicidad con otra clave de acceso) aparece cuando la factura ya está registrada con la misma numeración pero con otra clave de acceso, por ejemplo con otro código numérico. El 218 (NF-e já está cancelada na base de dados da SEFAZ, ya cancelada) aparece cuando la factura con esa numeración ya fue cancelada.
Cómo evitar el rechazo 204
Para no volver a caer en el 204, el Portal de la NF-e recomienda que la aplicación controle la numeración, para no generar una NF-e con un número ya usado; las claves de acceso que componen cada lote; si el lote ya fue enviado al ambiente de autorización; y el tratamiento de errores de transmisión y de timeout en la respuesta. Si la venta realmente necesita una factura nueva, lleva un número nuevo; si la factura autorizada no debería existir, el camino es la cancelación, no una segunda emisión.
En stackin, la consulta por clave de acceso es la ruta GET /api/v1/invoices/{access_key}, y el historial de envíos de cada factura (/api/v1/invoices/{invoice_id}/submissions) muestra el código y el mensaje que la SEFAZ devolvió en cada intento. La emisión acepta el encabezado Idempotency-Key: repetir la solicitud con la misma clave y el mismo cuerpo devuelve la primera respuesta en lugar de emitir un segundo documento, lo que cubre justamente el reenvío tras un timeout.