El XML de la factura de tu proveedor llega firmado: qué demuestra esa firma y qué solo demuestra la consulta a SUNAT

Supón que un proveedor nuevo te manda por correo el XML y el PDF de una factura de S/ 23,600. Compras quiere programar el pago esta semana y le pide a alguien de contabilidad que confirme que el comprobante es real. Esa persona abre el XML, ve el bloque ds:Signature, y da el asunto por cerrado: «está firmado, entonces está bien». Ahí es donde el proceso se equivoca. Debajo de esa frase hay dos preguntas distintas, y el XML solo contesta una.

Esta página mira el problema desde el lado del que recibe la factura, no del que la emite: qué demuestra comprobar la firma del XML que te mandaron, qué no demuestra esa misma comprobación, y por qué la pregunta que de verdad decide tu crédito fiscal la responde otro servicio de SUNAT, no el archivo. El certificado y la firma vistos desde el emisor están en la guía del certificado digital para facturación electrónica.

Qué hay dentro de la firma

El comprobante que te llega trae dos bloques de firma, no uno. Dentro de ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/ds:Signature va la firma XMLDSig propiamente dicha: el resumen criptográfico del documento, el algoritmo con el que se calculó, y el certificado X.509 de quien firmó, en ds:KeyInfo/ds:X509Data/ds:X509Certificate. Aparte, colgado directamente de la raíz del documento, va cac:Signature, que no firma nada: son datos descriptivos, el RUC y el nombre de quien dice haber firmado, más una referencia al bloque anterior.

Dónde va cada elemento y los veintiséis códigos con los que SUNAT valida su formato ya los detallamos en dónde va la firma dentro del XML de un comprobante, así que no hace falta repetirlos aquí. Sí importa quedarse con una idea de ese artículo: ninguno de esos veintiséis códigos comprueba la firma. Solo comprueban que los campos tengan la forma correcta, como base64.

Qué demuestra comprobar esa firma

Comprobar la firma es otra cosa, y la haces tú, no SUNAT. Un verificador XMLDSig —xmlsec1, una librería dentro de tu ERP, el validador del Estado— recalcula el resumen del documento y lo compara con ds:SignatureValue usando la clave pública del certificado. Si coinciden, quedan probadas dos cosas: que el documento es exactamente el que se firmó, sin un byte cambiado después, y que quien tenía la clave privada de ese certificado firmó ese contenido.

Hay un tercer dato que no da el verificador: lo lees tú, comparando dos campos a mano. El certificado trae el RUC del firmante en el subject, que se abre con openssl x509 -noout -subject y se detalla campo por campo en abre tu certificado digital y léelo. Ese mismo RUC tiene que aparecer en cac:Signature/cac:SignatoryParty/cac:PartyIdentification/cbc:ID y coincidir con el RUC del emisor que declara el comprobante. Si no coincide, tienes un documento con firma matemáticamente correcta, firmado por alguien que no es quien dice ser el emisor. SUNAT hace en la recepción dos comprobaciones parecidas: que cac:Signature lleve el RUC del emisor (código 2078, hoja Firma) y que el certificado sea el que el emisor, o su PSE, le comunicó (código 2325, hoja General). La segunda la hace contra un registro que tú no ves; por eso la comparación del RUC del certificado te toca a ti.

Lo que esa misma comprobación no demuestra

Verificar la firma no te dice que SUNAT aceptó ese comprobante. El manual del programador del SEE - Del contribuyente, en su numeral 3.1, dice que el certificado «debe encontrarse vigente y no revocado, ya que el receptor de SUNAT valida estos dos requisitos». Cuidado con la palabra: ese «receptor» es el sistema de SUNAT que recibió el envío del emisor, no tú. Esa comprobación se hizo una sola vez, al enviarse el comprobante, con la información que había ese día. Verificar el mismo XML meses después no la repite: solo confirma que el archivo no cambió desde que se firmó.

Tampoco te dice que el certificado siga vigente hoy. Las fechas notBefore y notAfter están en el propio archivo y esas sí las lees sin salir de tu máquina. Lo que no puedes saber solo con el XML es si ese certificado fue revocado antes de su caducidad; eso exige consultar la lista de revocación o el respondedor OCSP de la entidad que lo emitió, y medimos qué tan disponible está eso en el mercado peruano en comprobar que un certificado digital no está revocado.

Y tampoco te dice si el certificado se dio de baja ante SUNAT, que es un hecho distinto de la revocación y casi nadie lo separa. Las reglas de validación de comprobantes de pago electrónicos, actualizadas al 26 de agosto de 2026, hoja General, tienen el código 2326 para cuando «el certificado del contribuyente (RUC que invoca el servicio) del listado tiene fecha de baja menor a la fecha de emisión del comprobante». Ese listado es el registro propio de SUNAT, con los certificados que cada contribuyente comunicó desde su Clave SOL, independiente de si la entidad de certificación lo revocó. Ni lo uno ni lo otro se lee en el XML que te mandaron.

La consulta de SUNAT: lo que sí decide tu crédito fiscal

Todo lo anterior comprueba el documento. Lo que le importa a tu crédito fiscal es otra pregunta: si SUNAT reconoce que ese comprobante existe y si su emisor estaba habilitado para emitirlo en la fecha en que lo emitió. Eso lo responde un servicio distinto, con manual propio: la consulta integrada de comprobante de pago por servicio web, que autentica con OAuth2 y devuelve, para un comprobante concreto, tres datos: estadoCp del comprobante, y estadoRuc y condDomiRuc de su emisor.

Ya explicamos con detalle cómo se autentica ese servicio, qué significa cada código de esos tres campos y cómo se relaciona con la deducción del gasto para el Impuesto a la Renta en comprobar por API que la factura que te dieron existe. Lo que agrega esta página es el ángulo del IGV, que tiene su propio requisito legal y es distinto del de Renta.

El inciso b) del artículo 19 del Texto Único Ordenado de la Ley del Impuesto General a las Ventas, en el texto que le dio el artículo 2 de la Ley 29214, publicada el 23 de abril de 2008, exige para ejercer el derecho al crédito fiscal que los comprobantes «consignen el nombre y número del RUC del emisor, de forma que no permitan confusión al contrastarlos con la información obtenida a través de los medios de acceso público de la SUNAT y que, de acuerdo con la información obtenida a través de dichos medios, el emisor de los comprobantes de pago o documentos haya estado habilitado para emitirlos en la fecha de su emisión».

estadoRuc y condDomiRuc son justo eso: el estado del emisor y su condición de domicilio, en la fecha en que tú consultas. Si consultas el mismo día que te llega la factura, tu consulta y la emisión casi coinciden, y el dato sirve para lo que pide la ley. Si consultas meses después, en una revisión anual, el estado pudo haber cambiado en cualquier dirección y ya no prueba nada sobre el día de la emisión. Guarda la respuesta con su fecha y hora: es lo único que después sostiene que hiciste la comprobación cuando importaba, no una reconstrucción posterior.

Comprobar la firma en tu propia máquina

Esto se puede probar sin depender de SUNAT ni de un comprobante real. Armamos un certificado autofirmado de prueba —no es de la Infraestructura Oficial de Firma Electrónica, no sirve para firmar nada real— y un XML mínimo con los dos bloques de firma, con comandos ejecutados el 26 de septiembre de 2026.

Primero, el certificado, con el RUC en el campo OU tal como pide el manual del programador:

openssl req -x509 -newkey rsa:2048 -keyout privada-prueba.key -out certificado-prueba.pem \
  -days 365 -nodes -sha256 \
  -subj "/C=PE/O=EMPRESA DE PRUEBA SAC/OU=RUC 20123456789/CN=EMPRESA DE PRUEBA SAC"

Con ese certificado firmamos el XML de prueba, con xmlsec1 y la referencia vacía que exige SUNAT en una firma envolvente:

xmlsec1 --sign --privkey-pem privada-prueba.key,certificado-prueba.pem \
  --id-attr:Id "http://www.w3.org/2000/09/xmldsig#:Signature" \
  --output factura-prueba-firmada.xml factura-prueba-plantilla.xml

La primera verificación, sin decirle a xmlsec1 en qué certificado confiar, falla así:

error=71:certificate verification failed: ...err=18; msg=self-signed certificate
Error: failed to verify file "factura-prueba-firmada.xml"

Eso no es un fallo del documento: un certificado autofirmado no cuelga de ninguna entidad de certificación, y xmlsec1 hace lo correcto al negarse a confiar en una cadena que no existe. Con un comprobante real, esa cadena la resuelve la Infraestructura Oficial de Firma Electrónica hasta la raíz que publica INDECOPI.

Para aislar solo la integridad, le decimos que confíe explícitamente en el certificado que trae el propio XML:

xmlsec1 --verify --id-attr:Id "http://www.w3.org/2000/09/xmldsig#:Signature" \
  --trusted-der firmante-extraido.der factura-prueba-firmada.xml

OK
SignedInfo References (ok/all): 1/1

Y para confirmar que de verdad detecta un cambio, editamos el monto del documento firmado, de 118.00 a 999.00, sin volver a firmarlo:

error=12:invalid data:data and digest do not match
FAIL

El documento sin tocar verifica limpio, y en cuanto cambia un byte del contenido la verificación falla. Lo que este ejercicio no prueba —porque es justo lo que le falta a un certificado autofirmado— es una cadena de confianza hacia una entidad acreditada ni un estado de revocación. Para eso hace falta un certificado real y su propia infraestructura detrás.

En qué orden mirar esto, si el que decide eres tú

Con dos o tres comprobantes de compra al mes, verificar la firma de cada uno no compensa el tiempo; la consulta sí, porque es la que sostiene el requisito legal. Con más volumen, un proveedor nuevo o un monto alto, este es el orden que defendemos.

Primero, la consulta integrada, antes que la firma. Dice si SUNAT reconoce el comprobante y si el emisor podía emitirlo, que es el requisito que sostiene el crédito fiscal según el artículo 19 citado arriba. Verificar una firma impecable de un comprobante que SUNAT no reconoce es tiempo gastado en el dato equivocado.

Segundo, si el comprobante existe y el emisor está habilitado, ahí sí vale la pena verificar la firma: confirma que el archivo que vas a archivar es el mismo que se firmó, y no uno alterado en el camino, como un adjunto reenviado varias veces o un XML reabierto y reindentado por un editor de texto.

Tercero, comparar el RUC del certificado contra el RUC del emisor importa sobre todo si vas a usar el documento como prueba frente a un tercero —una fiscalización, un litigio con el proveedor—, porque para el crédito fiscal ese dato ya lo cubrió la consulta integrada, desde otro ángulo.

Invertir el orden y empezar por la firma es el error de la escena del principio, y viene de tratar el comprobante electrónico como un papel con un sello: se mira el objeto, no el registro. El objeto puede estar impecable y el comprobante no servirte de nada si SUNAT no lo tiene por aceptado.

Lo que no afirmamos

Que la consulta integrada revise la firma o el certificado. No lo hace. Devuelve el estado del comprobante y del RUC del emisor; nada sobre el documento firmado que tienes en tus manos.

Que el ejercicio con el certificado de prueba equivalga a validar un comprobante real. Falta la cadena hacia una entidad acreditada, la revocación y el cumplimiento del esquema XSD completo de UBL. Solo aislamos la parte de integridad y la comparación de RUC del firmante, que es la parte que le corresponde de verdad al receptor.

Que el inciso b) del artículo 19 de la Ley del IGV mencione la consulta integrada por su nombre. No lo hace: exige contrastar contra información obtenida por «medios de acceso público de la SUNAT». La consulta integrada es, hasta donde comprobamos, el servicio que junta esa información sobre el emisor en la misma respuesta que confirma el comprobante. No verificamos si existe además un medio distinto, gratuito y sin credenciales de aplicación, que cumpla el mismo papel para este caso.

Fuentes de esta página

• Manual del programador del SEE - Del contribuyente, versión 2.1 de 12 de mayo de 2021: numeral 3.1.
• Reglas de validación de comprobantes de pago electrónicos, actualizadas al 26 de agosto de 2026: hoja Firma, código 2078; hoja General, códigos 2325 y 2326.
• Manual de consulta integrada de comprobante de pago por servicio web, versión 2.0: endpoint validarcomprobante y anexo de códigos estadoCp, estadoRuc, condDomiRuc.
• Texto Único Ordenado de la Ley del Impuesto General a las Ventas e Impuesto Selectivo al Consumo, artículo 19 inciso b), en el texto dado por el artículo 2 de la Ley 29214, publicada el 23 de abril de 2008.

Las cuatro se descargaron el 26 de septiembre de 2026. Los comandos de la sección de comprobación se ejecutaron ese mismo día con OpenSSL 3.5.8 y xmlsec1 1.2.41, sobre un certificado y un XML de prueba creados para este artículo.

En mifirmadigital.pe emitimos los certificados con los que se firman los comprobantes que después tiene que revisar tu contraparte. Si estás armando el criterio de tu área de compras para decidir qué facturas se pagan directo y cuáles se revisan antes, escríbenos con el volumen de comprobantes que recibes al mes.

Última revisión: 26 de septiembre de 2026.