UBL 2.1 en Perú: requisitos técnicos para factura, boleta y nota de crédito

El estándar UBL 2.1 define la estructura base de los comprobantes electrónicos en Perú, pero SUNAT lo extiende con un conjunto de campos propios que no forman parte del estándar genérico. Un equipo que implementa UBL 2.1 sin estudiar el Anexo Técnico de SUNAT produce XMLs que son válidos contra el esquema base pero rechazados por el OSE por campos faltantes o mal ubicados. La diferencia entre un XML aceptado y uno rechazado suele estar en tres líneas del bloque ext:UBLExtensions.

Esta guía cubre la estructura XML requerida por SUNAT para los cuatro tipos de comprobante de uso general: Factura (01), Boleta de Venta (03), Nota de Crédito (07) y Nota de Débito (08), con énfasis en las diferencias entre tipos y los campos que generan más rechazos.

Estructura base del XML UBL 2.1 con extensiones SUNAT

Todo comprobante electrónico en Perú parte de la misma estructura de namespaces. El elemento raíz para Facturas y Boletas es Invoice del namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2. Para Notas de Crédito es CreditNote y para Notas de Débito es DebitNote. Los namespaces obligatorios incluyen: cac (CommonAggregateComponents), cbc (CommonBasicComponents), ext (UBLExtensions), ds (XMLDSig) y xsi. Cualquier namespace no declarado que se use en el XML resulta en error de estructura.

El bloque ext:UBLExtensions y la firma XAdES-BES

El primer hijo del elemento raíz debe ser ext:UBLExtensions, que contiene ext:UBLExtension con ext:ExtensionContent, donde va el elemento ds:Signature de la firma XAdES-BES. Este bloque debe estar presente incluso en el XML pre-firma; el proceso de firma lo popula. Si ext:UBLExtensions está ausente o mal posicionado, el OSE rechaza el documento antes de validar cualquier dato fiscal.

Factura (tipo 01): campos obligatorios y específicos

La Factura Electrónica se emite a clientes con RUC. Los campos obligatorios específicos de la Factura incluyen: cbc:InvoiceTypeCode con valor 01, cbc:DocumentCurrencyCode (PEN para soles, USD para dólares), el bloque cac:AccountingSupplierParty con el RUC del emisor en cbc:CompanyID con el atributo schemeID="6", y el bloque cac:AccountingCustomerParty con el RUC del receptor igualmente con schemeID="6". El schemeID="6" identifica el tipo de documento como RUC; usar schemeID="1" para DNI resulta en rechazo por tipo de documento incorrecto para Factura.

Estructura del bloque de impuestos (TaxTotal)

El bloque cac:TaxTotal requiere: cbc:TaxAmount con el monto total de IGV, y dentro de cac:TaxSubtotal: cbc:TaxableAmount (base imponible), cbc:TaxAmount (IGV de esta categoría), y cac:TaxCategory con cbc:TaxExemptionReasonCode para operaciones exoneradas o inafectas. Para operaciones gravadas el código de categoría es S (gravado), para exoneradas E y para inafectas O. La SUNAT requiere que la suma de todos los TaxSubtotal sea igual al TaxTotal del comprobante.

Boleta de Venta (tipo 03): diferencias con la Factura

La Boleta de Venta usa el mismo esquema Invoice con cbc:InvoiceTypeCode = 03. Las diferencias clave frente a la Factura son: el receptor puede tener DNI (schemeID="1"), Carné de Extranjero (schemeID="4") u otros documentos; si el total es menor a S/ 700 no es obligatorio consignar datos del receptor. En ese caso, el campo cac:AccountingCustomerParty puede omitir cbc:CompanyID o usar el valor -. Las Boletas de Venta con total menor a S/ 700 pueden enviarse al OSE como parte de un Resumen Diario (SummaryDocuments) en lugar de individualmente, reduciendo el número de llamadas al web service.

Resumen Diario de Boletas: cuándo y cómo usarlo

El SummaryDocuments es un XML que agrupa múltiples Boletas emitidas en un día y las envía como un solo documento al OSE usando el método sendSummary. El OSE responde con un ticket y el PSE hace polling con getStatus para obtener el CDR consolidado. Es la opción óptima para negocios con alto volumen de ventas a consumidor final (retail, e-commerce B2C). El resumen debe enviarse a más tardar al día siguiente de la fecha de emisión de las boletas incluidas.

Nota de Crédito (tipo 07): referencia y tipos de ajuste

La Nota de Crédito usa el elemento raíz CreditNote con cbc:CreditNoteTypeCode = 07. El campo obligatorio que diferencia las Notas de Crédito es cac:BillingReference, que debe contener el número de serie y correlativo del comprobante que se está ajustando (cbc:ID con el número de la Factura o Boleta original) y el tipo de comprobante referenciado (cbc:DocumentTypeCode). Si el BillingReference referencia un comprobante que no existe o que ya tiene una nota aplicada que lo anula completamente, el OSE rechaza la Nota. El campo cbc:DiscrepancyResponse indica el motivo del ajuste con un código de respuesta (01 = anulación, 02 = anulación por error en el RUC del receptor, etc.).

Nota de Débito (tipo 08): usos y estructura

La Nota de Débito usa el elemento raíz DebitNote con cbc:DebitNoteTypeCode = 08. Tiene la misma lógica de BillingReference que la Nota de Crédito. Se usa para incrementar el valor de una transacción previa: penalidades, intereses por mora, o ajustes al alza en el precio acordado. Es menos frecuente que la Nota de Crédito pero sigue exactamente el mismo patrón de referencia al comprobante original.

Preguntas frecuentes

¿Cuál es el schemeID correcto para cada tipo de documento de identidad en Perú?

Los valores de schemeID definidos por SUNAT son: 0 para documento sin especificar, 1 para DNI, 4 para Carné de Extranjeria, 6 para RUC (obligatorio en Facturas), 7 para Pasaporte, y A para Cédula Diplomatica. Usar un schemeID incorrecto para el tipo de documento del receptor resulta en rechazo con código de error relacionado al tipo de documento del comprador.

¿Cómo puedo validar el XML localmente antes de enviarlo al OSE?

SUNAT publica los esquemas XSD en su portal. Descargar el XSD correspondiente al tipo de comprobante (Invoice.xsd para Facturas y Boletas, CreditNote.xsd para Notas de Crédito, DebitNote.xsd para Notas de Débito) y validar el XML generado antes de firmarlo. La validación local no reemplaza la validación del OSE, pero detecta el 80% de los rechazos estructurales antes de hacer una llamada al web service.

¿Qué diferencia hay entre emitir una Nota de Crédito sobre una Factura y sobre una Boleta?

La estructura del XML es idéntica: la diferencia está en el campo DocumentTypeCode del BillingReference, que debe indicar 01 si la nota es sobre una Factura o 03 si es sobre una Boleta. No se puede emitir una Nota de Crédito que referencie una Factura si el emisor es un consumidor final sin RUC: el comprobante original determina el tipo de receptor permitido en la nota.

¿Es posible emitir comprobantes en moneda extranjera (USD) en Perú?

Sí. El campo cbc:DocumentCurrencyCode acepta códigos ISO 4217: PEN para soles, USD para dólares. Sin embargo, SUNAT requiere que el IGV se calcule y declare en soles, independientemente de la moneda del comprobante. Cuando el comprobante está en dólares, el bloque TaxTotal debe incluir el tipo de cambio (cbc:CalculationRate y cbc:MathematicOperatorCode) para que SUNAT pueda calcular el IGV equivalente en soles al tipo de cambio del día de emisión.

Para el modelo completo de validación en Perú, ver la guía de facturación electrónica para ISVs. Para el flujo de integración paso a paso, ver el checklist técnico de integración con SUNAT.