SUNAT factura electrónica 2026: qué cambia y cómo configurar Odoo para no pagar multas

Resumen en un minuto — qué cambia y cuándo

En enero de 2026 SUNAT extendió SIRE a la mediana empresa. Desde el 1 de febrero rigen nuevas validaciones de CPE — UBL 2.1 estricto, RUC del receptor verificado en tiempo real, detracciones obligatorias en el XML. Desde el 1 de julio de 2026 la guía de remisión física deja de ser documento legal. Es el cuarto y último tramo de la prórroga. Si tu Odoo se configuró en 2022, hoy no cumple ninguno de los tres requisitos — y se nota en la primera fiscalización.

• SIRE pasa a ser obligatorio para contribuyentes generadores de rentas de tercera categoría con ingresos anuales mayores a 1 700 UIT desde el 1 de enero de 2026. Desde el 1 de octubre de 2026 alcanza al resto de emisores de CPE. PLE para los libros 8 y 14 deja de ser aceptado en esas fechas.
• Nuevas validaciones de CPE entran en vigor el 1 de febrero de 2026: verificación del RUC del receptor en línea, UBL 2.1 estricto, campos obligatorios para detracciones y validación del tipo de cambio contra la SBS.
• GRE pasa a ser el único documento legal el 1 de julio de 2026 — es la cuarta y última prórroga, fijada por la Resolución 000040-2025/SUNAT.
• Multas: desde 1 UIT (~S/ 5 350) por un solo CPE incorrecto hasta 25 UIT (~S/ 133 750) y cierre del establecimiento por hasta 30 días.
• Odoo 17 y 18 cubren todo mediante el stack l10n_pe + l10n_pe_edi + l10n_pe_edi_stock más módulos community para SIRE. Toda configuración anterior a 2024 requiere revisión — sin excepciones.

Qué cambia en SUNAT 2026 — cronograma exacto

SUNAT no entrega 2026 en un solo paquete. Son cuatro tracks independientes, cada uno con su propio cronograma, su propio régimen sancionatorio y su propio operating risk. Atarlos en un único proyecto de migración es el error de planificación más caro que vemos hacer a los partners en Lima. Si quieres profundizar en SIRE específicamente, ver SIRE SUNAT enero 2026 — guía PYME.

#1. Enero 2026 — SIRE obligatorio para la mediana empresa

El Sistema Integrado de Registros Electrónicos (SIRE) reemplaza al PLE para los dos libros más cargados: Registro de Ventas e Ingresos (libro 14.1) y Registro de Compras (libro 8.1). Desde 2023 SIRE funcionaba para PRICO (Principales Contribuyentes) y grandes. Desde el 1 de enero de 2026 es obligatorio para todos los contribuyentes generadores de rentas de tercera categoría con ingresos anuales mayores a 1 700 UIT (~S/ 9 095 000 según UIT 2025). Desde el 1 de octubre de 2026 alcanza al resto de emisores de CPE.

La diferencia clave entre SIRE y PLE: SUNAT preconstruye la propuesta de ambos registros con los datos de los CPE que tú (o tus proveedores) ya emitieron. Tu trabajo es confirmar, ajustar o rechazar. Eso significa que tus propios CPE alimentan directamente tu RVIE. Si hay error en el CPE, el error entra al registro automáticamente y después toca explicarlo en el cruce.

Si después del 1 de enero de 2026 sigues enviando PLE 5.x.x del libro 14, SUNAT no lo recibe — formalmente los libros no están presentados. Multa según numeral 2 del artículo 175 del Código Tributario: 0,6% de los ingresos netos, mínimo 10 UIT, máximo 25 UIT.

#2. Febrero 2026 — nuevas validaciones de CPE

Desde el 1 de febrero de 2026 los validadores de SUNAT y los OSE (Operadores de Servicios Electrónicos) aplican un nuevo set de reglas a cada XML. Los cambios que más rompen integraciones existentes:

• Validación del RUC del receptor en tiempo real. Si el receptor no está registrado o su estado no es ACTIVO/HABIDO, la factura sale como RECHAZADO. Antes era apenas una advertencia en el CDR. Ahora es rechazo.
• UBL 2.1 estricto. Los campos cbc:ID dentro de cac:InvoiceDocumentReference son obligatorios para notas de crédito y débito. Notas sin referencia al CPE original quedan RECHAZADO.
• Validación de detracciones. Si el código del producto o servicio está sujeto a detracción (transporte, construcción, agencias, etc.), el campo sac:AdditionalProperty con código de servicio es obligatorio. Sin él, RECHAZADO con código 4143.
• Tipo de cambio. Si la moneda no es PEN, el campo cbc:CalculationRate se valida contra el tipo de cambio oficial de la SBS para la fecha de emisión. Tolerancia ±0,5%. Crítico para exportadores y empresas con operaciones en USD.
• Recibos por honorarios. Para RHE se añadió validación del tipo de renta y retención del 8% en cuarta categoría.

En lo técnico: si tu l10n_pe_edi está actualizado a 17.0.1.5+ (Odoo 17) o 18.0+, las validaciones funcionan out of the box. Versiones anteriores no. El backport es posible pero requiere custom development.

#3. Julio 2026 — la GRE pasa a ser única legal

La Guía de Remisión Electrónica (GRE) es formalmente obligatoria desde 2022, pero la guía física siguió siendo aceptada gracias a cuatro prórrogas consecutivas. La última — Resolución 000040-2025/SUNAT — fija la fecha definitiva en el 1 de julio de 2026. Después de esa fecha la guía física deja de existir como documento legal. Si una unidad sale a carretera el 2 de julio con guía de papel, es infracción por transporte sin documento autorizado.

La GRE se genera en dos flujos: GRE Remitente (del despachador) y GRE Transportista (del transportista). Si usas logística tercerizada, ambas guías deben emitirse y enlazarse mediante el código de enlace. Es un requerimiento crítico para cadenas retail con alto volumen de traslados entre tiendas.

#4. Fondo permanente — boleta electrónica con DNI

No es un "evento 2026", pero conviene recordarlo: para deducibilidad la boleta debe contener DNI o RUC del receptor cuando el monto sea mayor o igual a S/ 700. Sin ese dato, el gasto no es deducible. SUNAT lo viene aplicando desde 2024, pero en 2026 se agrega verificación automática mediante cruce contra SIRE. Antes se podía "olvidar"; ahora no.

Requisitos técnicos para Odoo bajo SUNAT 2026

La localización base de Odoo para Perú es el módulo l10n_pe. Cubre el plan de cuentas (PCGE), las tasas tributarias (IGV 18%, percepción, retención) y las clasificaciones de partner (RUC, DNI, CE). No alcanza. Para CPE hace falta un stack completo, y para SIRE un addon separado. Para una mirada al ecosistema más amplio, ver Odoo en Perú — pillar de país.

Conjunto mínimo de módulos para Odoo 17 y 18

l10n_pe_edi en Enterprise opera por defecto con Digiflow, pero el conector está estandarizado: se conecta cualquier OSE que soporte UBL 2.1 endpoint (Nubefact, The Factory HKA, Efact, Bizlinks, Paperless). Cada OSE pide su propio set de credenciales y contrato — esa es la parte operativa.

La pieza l10n_pe_sire todavía no entra en Odoo Enterprise. Es un gap que se cierra con forks community (OCA, Adhoc, NavMatic) o con desarrollo a medida. Si tu partner Odoo no menciona SIRE en la primera conversación, es red flag.

Flujo de emisión de factura electrónica en Odoo

1. Creación de account.move — tipo out_invoice desde Sales o Accounting.
2. Validación de campos — Odoo verifica tipo de documento (l10n_latam_document_type_id), serie (FXXX, BXXX), número, RUC del partner (con cron de validación cada 24 horas), IGV y fecha de emisión.
3. Generación de XML UBL 2.1 — el módulo construye el XML según la especificación SUNAT 1.0+. Desde febrero de 2026 incorpora los nuevos campos obligatorios.
4. Firma X.509 — el XML se firma con el certificado de la empresa o del OSE (depende del esquema contratado).
5. Envío al OSE/SUNAT — el XML sale por el endpoint SOAP del OSE (o REST en las generaciones nuevas).
6. CDR — SUNAT devuelve la Constancia de Recepción. Estado 0 es ACEPTADO. Códigos 2000 a 3999 son errores del emisor (corregibles). Códigos 4000+ son errores de validación: RECHAZADO sin posibilidad de reenvío.
7. Archivado — XML y CDR se guardan en Odoo por mínimo 5 años (plazo de prescripción tributaria).

Configuración de SIRE en Odoo

En Odoo Enterprise no hay módulo SIRE listo. El workflow base para una extensión community:

1. Extracción de datos de account.move.line por período (mensual).
2. Mapeo al formato RVIE 14.1 y RCE 8.1 (ancho fijo de campos, TXT con separador |).
3. Validación contra el esquema SIRE (tipos de operación, códigos de detracción, retenciones).
4. Conciliación contra la propuesta SUNAT (descargar la propuesta desde el API SIRE, comparar, encontrar diferencias).
5. Confirmar / ajustar / rechazar — la acción se ejecuta en el portal SUNAT o vía API SIRE.

El API SIRE es la mejora crítica que muchos partners ignoran. Desde 2024 SUNAT ofrece un REST API oficial con OAuth 2.0. Si tu Odoo se conecta directo, el cierre mensual RVIE+RCE deja de ser tres días de contadora para volverse un cron-job nocturno.

Certificados, OSE y puntos de fallo

SUNAT no acepta CPE sin firma del certificado X.509 v3 emitido por una Autoridad de Certificación habilitada: Andina, RIESCOM, Innova IT, Camerfirma. El certificado expira entre 1 y 2 años, y debe renovarse antes de la fecha de vencimiento. Si un CPE se firma con certificado vencido, no se considera emitido — con todas las consecuencias.

Para PYME recomendamos emisión vía OSE: saca de la empresa la responsabilidad por el uptime de SUNAT, el certificado vive del lado del OSE y el contrato incluye SLA. Costo entre S/ 0,05 y S/ 0,30 por CPE según volumen. La emisión directa por SUNAT SOL queda solo para grandes contribuyentes con equipo de IT propio.

5 errores típicos de configuración Odoo bajo SUNAT — y cuánto cuestan

Lo que sigue son casos reales de auditorías de implementaciones Odoo en Lima entre 2024 y 2025. Los 5 errores aparecieron en promedio en 3 de cada 4 PYME que llegaron a rescate. Si quieres el marco completo de diagnóstico, ver auditoría Odoo — framework de 47 puntos.

#1. Series de documentos configuradas a mano sin journal

Con frecuencia el contador hardcodea las series F001, F002, B001 en cada sale.journal. Si la misma serie aparece en otro journal o se duplica, SUNAT rechaza el CPE con código 2017 (numeración duplicada). Multa según numeral 4 del artículo 174 del CT: 50% UIT (~S/ 2 675) por cada incidente, más bloqueo de la serie hasta renumeración formal.

Como se hace bien: una serie, un journal, configuración mediante account.journal.l10n_latam_use_documents = True. La serie queda bloqueada para otros journals por unique constraint del módulo.

#2. IGV calculado a nivel producto, no a nivel línea

Por defecto Odoo enlaza el impuesto al producto. Si en una factura se mezclan productos con IGV 18% e IGV 0% (exoneradas o exportación) y la fiscal_position hereda mal, el total de IGV deja de ser 18% × base. El CPE pasa la validación SUNAT (el XML es formalmente válido), pero en el cruce con SIRE aparece la discrepancia. Multa por subdeclaración más intereses moratorios (1,2% mensual, capitalizables).

Como se hace bien: el account.tax debe llevar el repartition_line correcto, y la fiscal_position mapea impuestos para contribuyentes distintos (exportadores, no domiciliados, exonerados). Test mínimo: crear 3 facturas variantes (3 tipos de cliente) y revisar el XML manualmente antes de soltar a producción.

#3. GRE sin enlace con la factura

Muchos arman GRE como flujo separado del sale.order sin enlazarla con el account.move final. Técnicamente funciona, pero en el cruce SUNAT no ve la cadena factura → GRE → entrega. Aparece alerta de fiscalización: "factura sin entrega confirmada". No es multa directa, pero es trigger de inspección.

Como se hace bien: la GRE se genera desde stock.picking después de la validación, y el account.move referencia l10n_pe_edi_dispatch_id a esa GRE. Así SIRE ve la cadena emisión → despacho → entrega.

#4. Boleta electrónica sin DNI cuando el monto es mayor o igual a S/ 700

El POS de Odoo emite la boleta anónima (sin DNI) incluso cuando el monto es S/ 1 200. Si ese cliente después pide el documento para deducción, no tiene nada: boleta sin DNI no es deducible. Para tu empresa hay riesgo doble: queja del cliente por no entregarle el CPE correcto y multa si SUNAT detecta el patrón en una fiscalización.

Como se hace bien: en pos.config activar el flag de DNI obligatorio cuando el monto sea mayor a S/ 700. Custom flag llamado pos_l10n_pe_dni_threshold. El cajero está obligado a pedir el DNI — el flujo UX bloquea la venta sin él.

#5. PLE sigue enviándose después de migrar a SIRE

El error más caro. La empresa migra a SIRE para el libro 14 en enero de 2026, pero el cron de Odoo sigue generando PLE 14.1 TXT y subiéndolo. SUNAT registra doble sumisión: inconsistencia automática, requerimiento de explicación, y si no contestas en 5 días, multa por incumplimiento más revisión profunda. Tres clientes de la cartera lo pagaron en 2024 antes de que nosotros los tomáramos.

Como se hace bien: al activar SIRE, deshabilitar la generación de PLE 14 (libro 14) y PLE 8 (libro 8) en account.report.l10n_pe.ple. Dejar activos solo los libros que no migran a SIRE: 1 (caja), 3 (inventario), 5–7 (activo fijo), 9–13 (planillas, retenciones). Se configura por máscara de report_id.

Caso: PYME textil en Lima migrada a Odoo 17 + SIRE

Textilera limeña, 180 trabajadores, facturación aproximada S/ 22 millones anuales, exporta a Estados Unidos y Colombia. Antes de nosotros: SAP Business One v9.2 más 3 hojas de cálculo en paralelo más una contadora que cada mes hacía ajustes manuales para cuadrar. El problema: SIRE no podían conectarlo (SAP B1 no exporta los datos al formato exigido sin un add-on de USD 18 000), y el partner anterior había abandonado el proyecto Odoo en 2023 a la mitad.

Lo que hicimos en 4 meses:

• Auditoría forense de SAP B1 — 2 semanas. Documentamos 84 inconsistencias en el libro 8 (Compras) y 41 en el libro 14 (Ventas). Riesgo acumulado de multas: aproximadamente S/ 280 000 más intereses.
• Migración a Odoo 17 Enterprise en 3 olas por unidad de negocio (producción → almacén → comercial), no big-bang.
• Conexión SIRE mediante extensión propia l10n_pe_sire (forkeamos la rama OCA y la ajustamos a la arquitectura multi-empresa del cliente). El RVIE y el RCE salen automáticos el 8 de cada mes vía cron más API SIRE.
• GRE Remitente y Transportista — configuramos la cadena desde la salida del almacén en Villa El Salvador hasta la entrega internacional al cliente en Estados Unidos (incluye enlace con la DUA de exportación).
• BI sobre Odoo — margen por colección en tiempo real, montado encima de Odoo con ClickHouse + Superset. El CFO ve el margen en el teléfono antes del cierre mensual.

Resultados medidos a los 6 meses de go-live (los midió la CFO del cliente, no nosotros):

• Cierre mensual contable: 14 días → 3 días.
• Inconsistencias SIRE: 0 desde el quinto mes.
• Multas acumuladas tras go-live: 0.
• Ahorro de licencias: S/ 280 000 al año (Odoo Enterprise + hosting + soporte ilimitado < SAP B1 sola).
• FTE de contabilidad: 1,5 personas reasignadas a análisis financiero, fuera del cuadre operativo.

Lo metodológico importante: no arrancamos por la migración. Primero — 2 semanas de auditoría (S/ 9 500 fijos, descontados luego del proyecto). Eso le evitó al cliente arrastrar los errores de SAP hacia Odoo. La mitad de las implementaciones Odoo en Perú fracasan justamente porque el arrastre ocurre en el primer mes, y después se invierten otros 6 meses tratando de "corregir" en el sistema nuevo problemas que vienen del viejo.

Checklist — qué revisar en Odoo antes del 1 de julio 2026

Si ya tienes Odoo emitiendo CPE, revisa estos 7 puntos ahora. Cubren el 80% de los riesgos contra los nuevos requerimientos SUNAT 2026.

1. Versión de l10n_pe_edi — 17.0.1.5+ o 18.0+.
2. Certificado X.509 — vigente al menos hasta octubre de 2026.
3. RUC del receptor — cron de validación activado (partner.l10n_pe_check_ruc).
4. Detracciones — códigos de servicio configurados en account.tax.l10n_pe_edi_unspsc_code.
5. Tipo de cambio — sincronización con SBS vía cron, frecuencia mínima diaria.
6. SIRE — plan de migración desde PLE 8/14 aprobado, fecha de corte de PLE definida.
7. GRE — flujo stock.picking → GRE → enlace con account.move probado end-to-end.

Preguntas frecuentes