El archivo que prueba que tu factura fue aceptada también va firmado: qué lleva dentro el CDR y cómo se comprueba
Un contador pide el respaldo de una factura de hace dos años y le llegan tres cosas: el PDF de la representación impresa, el XML firmado y un archivo llamado R-20xxxxxxxxx-01-F001-1284.xml. Los dos primeros se miran siempre. El tercero, casi nunca, y es el único que dice que SUNAT recibió el comprobante y lo aceptó.
Ese tercer archivo es la constancia de recepción, el CDR. Y va firmado digitalmente, igual que la factura. La diferencia es que a la factura la firmas tú y a la constancia la firma quien la emite: SUNAT, o el OSE que tengas contratado.
Este artículo explica qué hay dentro de ese archivo, qué comprueba SUNAT de la firma cuando la constancia la genera un OSE, y cómo verificar esa firma sin depender de nadie. El punto de partida del tema, con el certificado que hace falta para todo lo demás, está en la guía del certificado digital para facturación electrónica.
El CDR no es un acuse de recibo, es un requisito del siguiente documento
Conviene empezar por para qué sirve, porque cambia la importancia de todo lo demás.
El artículo 26.1 de la Resolución de Superintendencia 117-2017/SUNAT, que regula el SEE - OSE, dice que la nota de crédito electrónica se emite únicamente respecto de «la factura electrónica o el DAE que cuente con la CDR – comprobantes y notas». El artículo 27.1 repite lo mismo para la nota de débito. Y el artículo 28.1 lo traslada al otro sistema de emisión: una nota electrónica solo puede modificar una factura emitida en el SEE - Del contribuyente «si aquella tiene una constancia de recepción con estado de aceptada».
O sea que sin CDR no hay corrección posible. No es un comprobante de que el envío llegó: es la condición para poder emitir el documento que anula o corrige.
Todas las constancias van firmadas por SUNAT
El manual del programador del SEE - Del contribuyente, en su versión 2.1 de mayo de 2021, dedica el numeral 2.6 a la constancia de recepción. Clasifica cuatro tipos según el documento enviado —factura y notas, resumen diario, comunicación de baja y resumen de reversiones— y aclara que para el sistema todos son iguales: misma estructura y misma información.
Después describe sus características. El formato es XML basado en el documento ApplicationResponse de UBL versión 2.0. El nombre es el del archivo enviado con el prefijo R-: si mandaste 20199872761-01-FR92-9882.xml, la constancia se llama R-20199872761-01-FR92-9882.xml. Y la última característica es una sola línea:
Firma digital: Todas las constancias se encontrarán firmadas digitalmente por SUNAT.
El anexo 1 del mismo manual detalla la estructura. La firma va donde va la de tu comprobante, dentro de ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent, con los mismos elementos de XMLDSig: ds:SignedInfo, ds:SignatureValue y ds:KeyInfo/ds:X509Data/ds:X509Certificate, este último con cardinalidad 1 en la constancia. Es la misma mecánica que ya describimos para el comprobante en dónde va la firma dentro del XML, vista desde el otro lado.
El bloque cac:Signature también está, y el apartado B.9 del manual dice qué va en él: la parte firmante «para el caso de la constancia de recepción corresponde a los datos de SUNAT», con su RUC en PartyIdentification/cbc:ID y su nombre en PartyName/cbc:Name.
El CDR tiene dos relojes, y no marcan lo mismo
Dentro del ApplicationResponse hay cuatro campos de tiempo, y el manual los separa con cuidado:
| Campo | Qué fecha es |
|---|---|
cbc:IssueDate / cbc:IssueTime | recepción del documento que enviaste |
cbc:ResponseDate / cbc:ResponseTime | generación de la constancia |
La primera pareja es la que cuenta para los plazos de envío, porque es el momento en que SUNAT tuvo tu comprobante. La segunda es cuándo terminó de procesarlo. Entre una y otra pueden pasar minutos y en el caso del resumen diario bastante más, porque el procesamiento es asíncrono y el CDR se recoge después con el ticket.
Hay un tercer dato que conviene guardar: cbc:ID, que el manual define como el número único asignado por SUNAT para identificar el proceso de recepción. Es el identificador con el que se reclama cualquier cosa sobre ese envío.
Si el problema que tienes es el contrario —el certificado con el que firmas vence esta semana y tienes comprobantes sin enviar—, la comparación de fechas que hace SUNAT está en este otro artículo.
Cuando el CDR lo firma tu OSE, quien revisa esa firma es SUNAT
Si emites a través de un OSE, la constancia no la genera SUNAT sino el operador. La RS 117-2017 lo define así en su numeral 1.9: el CDR es el documento «emitido y remitido electrónicamente por el OSE al emisor electrónico», cuando comprueba que lo enviado cumple las condiciones.
Ese CDR del OSE llega después a SUNAT, y ahí sí se revisa. Las reglas de validación de comprobantes de pago electrónicos actualizadas al 26 de agosto de 2026 tienen dos hojas dedicadas a eso, CDR-OSE-Comprobante y CDR-OSE-Resumen. Estos son los códigos que hablan de quién firmó:
| Código | Condición | Tipo |
|---|---|---|
| 2822 | falta el número de documento de identificación del OSE | ERROR |
| 2823 | ese número no es numérico de 11 dígitos | ERROR |
| 2824 | el certificado con el que se firma el CDR no corresponde al RUC del OSE | OBSERV |
| 2825 | el RUC no corresponde a un OSE registrado en el padrón | ERROR |
| 2874 | el OSE no está vinculado al emisor en la fecha de recepción | OBSERV |
Lee otra vez el 2824. Que la constancia esté firmada con un certificado que no es el del OSE que dice haberla emitido es una observación, no un error. El documento pasa igual. En cambio, que el RUC no esté en el padrón de OSE sí es error.
El 2874 trae además el plazo que casi nadie tiene a mano: la relación entre OSE y emisor «se considera vigente hasta el 7mo día calendario del mes siguiente de solicitado la baja». Cambiar de operador un día 3 no rompe nada ese mismo mes.
Y hay una asimetría de versiones que llama la atención al comparar los dos documentos. La constancia que emite SUNAT es UBL 2.0 con CustomizationID 1.0, según el apartado B.2 del manual. La que emite un OSE tiene que ser UBL 2.1, según la fila 1 de la hoja CDR-OSE-Comprobante, con los códigos 2110 y 2111 si no lo es. Dos documentos con el mismo nombre y la misma función, en dos versiones distintas del estándar.
Cómo compruebas tú esa firma
La constancia llega dentro de un ZIP. Al descomprimirlo tienes el XML, y a partir de ahí es el mismo procedimiento que con cualquier documento XMLDSig.
Primero, sacar el certificado del firmante y leerlo:
xmllint --xpath "//*[local-name()='X509Certificate']/text()" R-20199872761-01-FR92-9882.xml \
| tr -d '\n ' | base64 -d > firmante.der
openssl x509 -inform DER -in firmante.der -noout -subject -issuer -dates
El subject te dice quién firmó y el issuer, qué entidad de certificación lo emitió. Si el CDR es de SUNAT, el titular tiene que ser SUNAT; si es de un OSE, el RUC del certificado tiene que ser el mismo que el del bloque cac:ReceiverParty, que es justo lo que comprueba el código 2824.
Segundo, verificar que la firma cuadra con el contenido:
xmlsec1 --verify --trusted-der firmante.der R-20199872761-01-FR92-9882.xml
Si esa verificación pasa, el archivo no se tocó después de firmarse. Si falla, el XML se modificó, aunque sea por algo tan inocente como haberlo abierto y guardado con un editor que reindenta.
Lo que ese comando no comprueba es la cadena de confianza hacia arriba ni el estado de revocación del certificado. Para eso hacen falta los certificados intermedios y la raíz, y la comprobación de revocación que explicamos en cómo se comprueba que un certificado no está revocado. Los campos que hay que mirar dentro del certificado, uno por uno, están en abre tu certificado digital y léelo.
Qué hacer con esto
Guarda el CDR con el mismo cuidado que el XML. Sin él no puedes emitir una nota que corrija la factura, por el artículo 26.1 de la RS 117-2017. Cuánto tiempo y en qué formato hay que conservarlo es la pregunta que tratamos en conservar un documento firmado.
No lo conviertas. Un CDR impreso en PDF o pegado en un correo deja de ser verificable: la firma vive en el XML.
Si trabajas con un OSE, comprueba una vez al año el certificado con el que firma sus constancias. Es una comprobación de treinta segundos con los dos comandos de arriba y detecta el escenario del código 2824, que SUNAT solo observa y no te va a rechazar.
Si recibes un CDR ajeno como prueba de algo, verifícalo. Es un XML firmado: o valida o no valida.
Lo que este artículo no afirma
Que SUNAT firme sus constancias con un certificado concreto. El manual dice que van firmadas y el anexo dice dónde va la firma. No hemos contrastado esta descripción contra un CDR de producción para este artículo, así que no afirmamos qué entidad de certificación emite ese certificado ni con qué algoritmo firma.
Que xmlsec1 verifique cualquier CDR sin ajustes. Las firmas envolventes con referencia vacía suelen verificarse tal cual, pero hay implementaciones que necesitan que se les indique el atributo identificador del nodo firmado.
Qué pasa si la firma del CDR no valida. No localizamos ninguna norma que diga cómo se reclama eso, ni si SUNAT admite la impugnación de una constancia por ese motivo. Lo que sí se puede hacer es recuperar la constancia otra vez desde el servicio web y comparar.
Que el CDR de un OSE con el código 2824 sea inválido. Las reglas lo clasifican como observación y el comprobante sigue aceptado. Que eso sea suficiente para el emisor es otra discusión.
Fuentes de esta página
- Manual del programador del SEE - Del contribuyente, versión 2.1 de 12 de mayo de 2021: numeral 2.6, anexo 1 apartados A.2, B.2 y B.9.
- Reglas de validación de comprobantes de pago electrónicos, actualizadas al 26 de agosto de 2026: hojas
CDR-OSE-ComprobanteyCDR-OSE-Resumen. - Resolución de Superintendencia 117-2017/SUNAT, que aprueba el SEE - OSE: numeral 1.9 y artículos 16, 26, 27 y 28.
Las tres se descargaron el 21 de septiembre de 2026.
En mifirmadigital.pe emitimos los certificados con los que se firman los comprobantes que generan estas constancias. Si tienes un CDR que no valida y no sabes si el problema es el archivo o la herramienta, escríbenos con el XML y la salida del comando.
Última revisión: 21 de septiembre de 2026.