Facturación electrónica en el Perú: guía para desarrolladores

Si te toca construir o integrar un módulo de facturación electrónica en el Perú, lo primero que notas es la cantidad de siglas: CPE, SEE, OSE, PSE, UBL, CDR. Entender cómo encajan te ahorra semanas de prueba y error.

Esta guía ordena ese sistema desde el punto de vista de quien lo programa. No reemplaza la documentación de SUNAT; es el mapa para leerla con sentido. Verás qué es un comprobante electrónico, por qué caminos se emite, qué contiene el XML y dónde entran el RUC, el DNI, el ubigeo y el tipo de cambio. Donde hay plazos o reglas que cambian por resolución, te lo indicamos para que lo confirmes en la fuente oficial.

---

Qué es un comprobante de pago electrónico

Un comprobante de pago electrónico (CPE) es el documento que acredita una venta o un servicio, emitido en formato digital y con validez tributaria. En la práctica es un XML firmado digitalmente, generado por un sistema autorizado y validado por SUNAT o por un operador autorizado.

Los más comunes son la factura, la boleta de venta y las notas de crédito y débito electrónicas; también existen la guía de remisión, el recibo por honorarios y los comprobantes de retención y percepción.

El PDF que recibe el cliente no es el comprobante. Es una "representación impresa" del XML, con ciertos datos obligatorios (entre ellos un código QR y el resumen de la firma). El documento con valor legal es el XML aceptado, así que conserva el XML y la constancia, no solo el PDF.

Quien emite CPE es un "emisor electrónico"; hoy la gran mayoría de contribuyentes está obligada a serlo.

Las formas de emitir: SOL, tu sistema, OSE y PSE

SUNAT agrupa las modalidades de emisión bajo el nombre Sistema de Emisión Electrónica (SEE). Un desarrollador se cruza con cuatro:

• SEE-SOL. Emisión manual desde el portal de SUNAT con la Clave SOL. Sin integración.
• SEE desde los sistemas del contribuyente. Tu software genera el XML, lo firma y lo envía a SUNAT por sus servicios web. Más control y más responsabilidad.
• SEE-OSE. Igual, pero el XML va a un Operador de Servicios Electrónicos (OSE), empresa autorizada por SUNAT que valida el comprobante, emite la constancia e informa a SUNAT.
• Facturador SUNAT. Aplicación gratuita que toma archivos planos de tu sistema y se encarga del XML, la firma y el envío.

Aparte está el Proveedor de Servicios Electrónicos (PSE): un tercero que genera, firma y envía en nombre del emisor. Tú le mandas los datos por su API; la responsabilidad tributaria sigue siendo del emisor.

Para un ERP, un e-commerce o un punto de venta, la decisión práctica es integrar directo (con SUNAT o un OSE) o delegar en un PSE; en las preguntas frecuentes comparamos ambas. En cualquier caso, los datos del comprobante los produce tu sistema, y ahí se ganan o se pierden la mayoría de rechazos.

Anatomía del XML: UBL, firma digital y CDR

SUNAT adoptó el estándar UBL (Universal Business Language), en su versión 2.1, para estructurar los comprobantes. UBL define elementos para emisor, cliente, líneas, impuestos y totales; SUNAT fija cuáles son obligatorios y qué valores aceptan mediante catálogos numerados.

El flujo técnico para una factura emitida desde tu sistema es, a grandes rasgos:

1. Construir el XML según UBL 2.1 y las reglas de SUNAT.
2. Firmarlo con un certificado digital a nombre del emisor, registrado en SUNAT y emitido por una entidad acreditada.
3. Empaquetarlo en un archivo comprimido con el nombre normado (RUC, tipo de comprobante, serie y número).
4. Enviarlo al servicio web de SUNAT o del OSE (históricamente SOAP; los más recientes, como el de guías de remisión, usan API REST).
5. Recibir la CDR, la Constancia de Recepción, otro XML con el resultado.

La CDR trae un código de respuesta: cero significa aceptado. Otros valores indican rechazo (el comprobante no existe para SUNAT; hay que corregir y volver a emitir) u observación (aceptado, con advertencias). A grandes rasgos, los rechazos van en el rango 2000 a 3999 y las observaciones desde 4000; confirma cada código en el catálogo de errores vigente.

Las boletas tradicionalmente se informan en un resumen diario y las facturas se anulan con una comunicación de baja; revisa la guía de SUNAT para tu modalidad.

Datos obligatorios del cliente y de la operación

Es el corazón del trabajo de integración. Cuatro bloques:

Identificación del comprobante

• Tipo de comprobante (catálogo 01): 01 factura, 03 boleta de venta, 07 nota de crédito, 08 nota de débito.
• Serie y número. Las facturas usan series que empiezan con F (F001) y las boletas con B (B001), seguidas de un correlativo que no se repite ni retrocede.
• Fecha de emisión, moneda (catálogo 02, con códigos ISO como PEN y USD) y tipo de operación (catálogo 51, por ejemplo 0101 para una venta interna).

Emisor

RUC, razón social y dirección con ubigeo, departamento, provincia y distrito, tal como figuran en SUNAT.

Cliente

• Tipo de documento (catálogo 06): 6 RUC, 1 DNI, 4 carnet de extranjería, 7 pasaporte, y otros valores para casos como no domiciliados sin RUC.
• Número de documento y razón social o nombre, tal como figuran en la fuente oficial.
• Dirección, opcional según el tipo de comprobante; si la incluyes, que sea la correcta.

Una factura exige un cliente con RUC. Una boleta va a un consumidor final y, cuando el importe llega a S/ 700, debe consignar el DNI y el nombre del comprador. En factura o boleta: cuándo emitir cada una está la regla completa.

Líneas y totales

Por cada ítem: descripción, cantidad, unidad de medida (catálogo 03: NIU unidades, ZZ servicios), valor unitario, precio con impuestos y afectación al IGV (catálogo 07: 10 gravado, 20 exonerado, 30 inafecto, 40 exportación). A nivel de documento: totales por afectación, IGV, importe total y la leyenda con el monto en letras. El IGV es 18 % (16 % de IGV más 2 % de IPM); el redondeo lo tratamos en cómo calcular el IGV en tu sistema.

Dónde entran RUC, DNI, ubigeo y tipo de cambio

Cada dato tiene un lugar preciso en el flujo y una validación que se puede automatizar.

RUC del cliente. Entra cuando el vendedor elige "factura". Antes de emitir, comprueba que el RUC tiene formato válido, existe, está ACTIVO y HABIDO, y trae la razón social exacta. Facturar a un RUC de baja o copiar la razón social a mano son dos de los errores más frecuentes. Con la API de consulta RUC de endpoint.pe esa comprobación es una llamada:

curl https://api.endpoint.pe/v1/ruc/20131312955 \
  -H "Authorization: Bearer TU_TOKEN"

{
  "success": true,
  "message": "Consulta exitosa",
  "data": {
    "ruc": "20131312955",
    "razon_social": "SUPERINTENDENCIA NACIONAL DE ADUANAS Y DE ADMINISTRACION TRIBUTARIA - SUNAT",
    "estado": "ACTIVO",
    "condicion": "HABIDO",
    "direccion": "AV. GARCILASO DE LA VEGA NRO. 1472 LIMA - LIMA - LIMA",
    "ubigeo": "150101"
  },
  "meta": {
    "fuente": "SUNAT",
    "consultado_en": "2026-10-12T07:40:12Z",
    "creditos_cobrados": 1,
    "creditos_disponibles": 14621
  }
}

Si el RUC no existe, la API responde 404 (esa consulta no se cobra) y tu sistema debe impedir la emisión.

DNI del comprador. Entra en las boletas, sobre todo desde S/ 700. Con la API de DNI se completan nombres y apellidos a partir del número, sin errores de tipeo.

Ubigeo. Entra en la dirección del emisor, en la del cliente cuando la incluyes y en las guías de remisión (puntos de partida y llegada). Son 6 dígitos (2 de departamento, 2 de provincia, 2 de distrito); la API de ubigeo devuelve los nombres a partir del código.

Tipo de cambio. Entra cuando la operación es en moneda extranjera: el comprobante va en dólares, pero el IGV se expresa en soles con el tipo de cambio de la fecha de emisión. A grandes rasgos, se usa el tipo de cambio venta que publica SUNAT (el promedio ponderado que calcula la SBS); el detalle está en tipo de cambio SUNAT: cuál usar. La API de tipo de cambio devuelve el vigente cada día, para guardarlo junto al comprobante.

Arquitectura de un módulo de facturación

Un módulo de facturación bien diseñado es una tubería con etapas separadas.

1. Captura. El pedido: cliente, ítems, moneda, condición de pago.
2. Validación previa. Antes de asignar número: formato y existencia del RUC o DNI, estado y condición, razón social exacta, ubigeo válido, tipo de cambio del día, totales cuadrados.
3. Numeración. Serie y correlativo asignados de forma atómica, para que dos emisiones concurrentes nunca compartan número.
4. Generación del XML. Del modelo interno al UBL con los catálogos correctos.
5. Firma. Con el certificado del emisor, cuya clave privada vive en un almacén seguro del servidor, nunca en el repositorio.
6. Envío. A SUNAT, OSE o PSE, por una cola con reintentos que respete el plazo máximo.
7. CDR. Se guarda la constancia y se actualiza el estado (aceptado, observado, rechazado).
8. Entrega. Representación impresa al cliente, con el XML y la CDR adjuntos.

Separar la validación previa del resto es la decisión que más paga. Una factura emitida a un RUC inexistente o de baja no se arregla con un reintento: hay que anular y volver a emitir. Detectarlo antes de numerar cuesta una consulta; después, una nota de crédito.

Para construir esa etapa, endpoint.pe ofrece 150 consultas gratis al mes sin tarjeta; al crear una cuenta tienes el token y la documentación para la primera llamada.

En resumen

• El comprobante electrónico es el XML firmado y aceptado; el PDF es solo su representación impresa.
• Se emite desde el portal SOL, desde tu sistema hacia SUNAT o un OSE, con el facturador de SUNAT o vía un PSE.
• El XML sigue UBL 2.1, se firma con certificado digital y SUNAT u OSE responden con una CDR: aceptado, observado o rechazado.
• Una factura exige RUC del cliente; una boleta identifica al comprador con DNI cuando llega a S/ 700.
• Los catálogos de SUNAT definen los códigos de comprobante, documento de identidad, moneda, unidad y afectación al IGV.
• Valida RUC, DNI, ubigeo y tipo de cambio antes de numerar el comprobante: es la etapa que evita anulaciones.

Preguntas frecuentes

¿Integro directo con SUNAT o uso un PSE?

Depende de tu volumen y de tu equipo. Integrar directo (o con un OSE) da control total sin costo por comprobante, pero asumes certificados, firma, colas y cambios normativos. Un PSE lo reduce a una llamada HTTP con un costo por documento. En ambos casos, la validación de los datos del cliente la haces tú.

¿El PDF que envío al cliente tiene valor legal?

No por sí mismo. El comprobante es el XML aceptado por SUNAT o por el OSE; el PDF es su representación impresa. Guarda siempre el XML y la CDR junto al PDF.

¿Qué pasa si SUNAT rechaza un comprobante?

Un comprobante rechazado no existe para SUNAT: corrige el error y emítelo de nuevo según las reglas vigentes. Si fue aceptado con observaciones, es válido, pero revisa qué observó para no repetirlo.

¿Dónde consulto los catálogos y las reglas de validación?

En la documentación oficial de SUNAT para emisores electrónicos: guía de elaboración de comprobantes, catálogos y listado de errores. Se actualiza por resolución; revisa la versión vigente antes de cada cambio importante en tu sistema.