SUNAT 2027: fase final de la digitalización tributaria en Perú

Timeline 2024–2026: cómo llegamos aquí

El 30 de junio de 2026 muere la guía física. El 1 de enero de 2027, SIRE pasa a ser obligatorio para casi todos los contribuyentes. La gran diferencia: las multas ya no las pone un inspector — las pone un algoritmo que cruza datos automáticamente y no perdona. Si tu Odoo no está listo en otoño de 2026, la migración se vuelve un proyecto de crisis con pricing de emergencia.

2026 fue el año de calentamiento. SUNAT 2027 es el año en que el sistema de cross-checking lo atrapa todo: discrepancia entre GRE y factura, RUC en estado «no habido» al momento de recepción, IGV que no cuadra por un céntimo, ISC no aplicado en venta de alcohol. Cada error ya no es una advertencia: es una multa del 25% al 50% de la UIT (aproximadamente S/ 1,340–2,680 en precios de 2026). Para retail con más de 1,000 comprobantes al mes, la aritmética se vuelve fatal.

Para entender lo que cambia en 2027, conviene mirar la trayectoria. SUNAT viene construyendo electronic compliance desde 2014, pero el período 2024–2026 es un sprint sin precedentes.

2024: SIRE para PRICOS y expansión GRE

La Resolución de Superintendencia que reguló SIRE introdujo el sistema para PRICOS (Principales Contribuyentes Nacionales) desde enero de 2024. A fines del año, SIRE cubría unos 14,000 contribuyentes grandes — pero eso era menos del 0.5% de las PYME formales del país.

En paralelo, la GRE-electrónica se expandió. Cada vez más categorías de movimiento de mercadería pasaron al formato electrónico. A fines de 2024 ya había unas 250,000 GRE mensuales en el sistema.

2025: SIRE para MEPECOS de forma escalonada

En 2025, SUNAT comenzó a incorporar a los MEPECOS (Medianos y Pequeños Contribuyentes) en SIRE de forma escalonada — por fecha de inscripción en el RUC y por ingresos. A fines del año, unos 80,000 contribuyentes ya estaban en el sistema. La GRE se volvió estándar para transportistas; la guía física quedó como excepción.

2026: el año crítico, tres olas a la vez

• Enero 2026: SIRE obligatorio para todos los PRICOS y para una lista ampliada de MEPECOS. El viejo PLE empieza a perder estatus para esas categorías.
• Febrero 2026: nuevas reglas de validación CPE. El sistema rechaza comprobantes con montos inconsistentes (importes y IGV que no cuadran), con RUC receptor en estado «no habido» al momento de emisión, o con campos obligatorios faltantes en B2B.
• 30 de junio de 2026: fecha en que se acaba la posibilidad de emitir legalmente la guía de remisión física para la mayoría de escenarios. Después, solo GRE-electrónica.

A fines de 2026, aproximadamente el 95% de los CPE serán electrónicos; SIRE cubrirá unos 1.5 millones de contribuyentes; y la GRE-electrónica será el único formato legal para la gran mayoría de operaciones. El checklist SUNAT 2026 con 47 puntos describe la fase actual; lo que viene es más estricto.

Cuatro cambios estructurales en 2027

SUNAT no publica todas las normas de 2027 de golpe — parte de las resoluciones se irá precisando en el Q3–Q4 de 2026. Pero la trayectoria es clara y la preparación se hace ahora, no en enero. Cuatro direcciones concretas.

#1. SIRE pasa a ser universal

Para enero de 2027, SIRE se extiende a todas las categorías de contribuyentes, incluyendo Régimen Especial y MyPe Tributario. En la práctica:

• El RVIE (Registro de Ventas e Ingresos Electrónico) y el RCE (Registro de Compras Electrónico) los prellena SUNAT a partir de tus CPE.
• El plazo de confirmación es hasta el octavo día hábil del mes siguiente.
• El viejo PLE deja de tener sentido para la mayoría de categorías.

El cambio clave: ya no «generas» libros — SUNAT los arma por ti. Eso reduce la rutina contable, pero eleva fuertemente la exigencia sobre la calidad de los datos fuente en el ERP. Cualquier error en un CPE entra automáticamente en SIRE y obliga a corregirlo.

#2. Régimen GRE-only sin excepciones

Para 2027:

• Todo movimiento de mercadería exige GRE-electrónica al momento de la salida.
• La guía física solo se acepta con contingencia confirmada (sistema fuera de servicio).
• El tiempo entre emisión de GRE y movimiento real se controla — un gap muy largo gatilla revisión.

Para la logística, esto significa integración real entre ERP, TMS y SUNAT. Los procesos basados en Excel quedan fuera del juego.

#3. Validaciones CPE reforzadas

Sobre la base de la trayectoria 2024–2026 y de los drafts ya publicados por SUNAT, lo que se espera:

• Cruce GRE ↔ factura: cada factura B2B ligada a un movimiento físico debe tener una GRE correspondiente con datos consistentes. Diferencias de monto, ítem o cantidad — rechazo automático.
• Validación de RUC en tiempo real: el estado del RUC se valida no solo al emitir, sino también al recibir. Si en esa ventana el RUC pasa a «no habido», el CPE puede ser rechazado.
• ISC por categorías de producto: verificación automática del Impuesto Selectivo al Consumo para alcohol, tabaco, combustible y vehículos. Si el ISC no se aplica donde corresponde, rechazo.

#4. Más multas y cross-checking

Dirección esperable según la tendencia 2024–2026:

• Multa por CPE no emitido o incorrecto: hasta el 50% de la UIT (cerca de S/ 2,680 por caso en precios de 2026). Con volumen de 1,000 casos al mes, son S/ 2.68 M al año — quiebra para una PYME.
• Presentación tardía de SIRE: 0.3% de la UIT por día, con tope en 12 UIT (≈ S/ 64,300).
• Cruce con datos bancarios: SUNAT ya cuenta con el ITF (Impuesto a las Transacciones Financieras) y un protocolo con bancos. Cuando el ingreso declarado no cuadra con los movimientos bancarios reales, salta el flag de auditoría.

Cómo configurar Odoo para SUNAT 2027

Qué hay que dejar listo en tu Odoo para que 2027 no sea el año de las multas. Empezamos por la base del módulo y terminamos con el operational checklist. Si recién estás migrando desde un POS legacy, el guía Odoo en Perú describe la arquitectura completa para PYME.

La base: l10n_pe y sus límites

El módulo l10n_pe (vigente en Odoo 17–19) entrega la base:

• IGV 18% — tax positions estándar.
• Boleta y factura electrónica — vía l10n_pe_edi.
• Sequencing de CPE — series y numeración.
• Validación básica de RUC al crear cliente.

Lo que l10n_pe community no cubre out-of-the-box:

• Integración SIRE directa — solo trae un export PLE básico.
• Automatización GRE-electrónica — el flujo básico existe, pero el conformance a las reglas actuales de validación SUNAT exige customización.
• Validación CPE en tiempo real pre-emisión — requiere integración con la API de validación SUNAT a través de un OSE certificado.
• ISC por taxonomía de producto — los impuestos están, pero la aplicación automática a categorías de producto requiere setup.

Operational checklist en siete pasos

1. Upgrade a Odoo 17+ — las versiones 14 y 15 ya no reciben actualizaciones de l10n_pe alineadas con las nuevas exigencias SUNAT.
2. Instalar el combo l10n_pe + l10n_pe_edi + l10n_pe_edi_stock (este último para GRE).
3. Conectar un OSE certificado (Operador de Servicios Electrónicos). Para PRICOS es obligatorio; para MEPECOS, en la práctica también. La lista oficial está en sunat.gob.pe.
4. Habilitar export SIRE — vía módulos community externos o desarrollo custom.
5. Auditar el campo RUC en todos los clientes — encontrar y actualizar los inválidos y los «no habidos».
6. Auditar la taxonomía de productos — especialmente para categorías afectadas por ISC.
7. Activar monitoring — Sentry o Healthchecks sobre fallas de envío de CPE. Una semana sin mirar logs y se acumulan rechazos invisibles.

Cuándo el módulo estándar alcanza — y cuándo no

La sección más importante del análisis. No todos los escenarios son iguales y el costo de implementación cambia 5–10× entre uno y otro. La metodología de implementación Odoo para PYME LATAM es la referencia que usamos para dimensionar cada caso.

PYME estándar: un RUC, retail B2B/B2C simple

Funciona out-of-the-box. l10n_pe + un connector OSE = compliance-ready para los flujos básicos.

Por qué: las operaciones principales — boleta para B2C, factura para B2B, GRE ocasional — están cubiertas por los módulos estándar con un setup correcto.

Qué hacer: instalar l10n_pe, conectar un OSE, mapear impuestos, configurar series, validar el email-template para CPE. Implementación de 2–4 semanas y presupuesto de USD 3,500–8,000.

Multi-RUC: holding o intercompany

No funciona en la caja. l10n_pe asume un RUC por company. Las transacciones intercompany entre distintos RUC exigen CPE separados con series distintas y cuentas OSE propias.

Qué hacer: o bien company-instances separadas en Odoo por cada RUC (arquitectura recomendada), o bien desarrollo custom para generación multi-company de CPE. Costo: USD 8,000–20,000.

Operaciones logistic-heavy (más de 500 GRE/mes)

Funciona parcialmente. l10n_pe_edi_stock cubre flujos básicos de GRE, pero no cubre:

• Multi-stop deliveries (una salida con varios destinos).
• Gestión de chofer y vehículo para GRE Transportista.
• Tracking en tiempo real para cumplir los timing-requirements.

Qué hacer: extensión custom de GRE más integración con TMS (Track-POD, Onfleet o desarrollo propio). Setup realista: USD 15,000–35,000.

MyPe Tributario y Régimen Especial

Funciona con simplificaciones. Solo factura (en la mayoría de categorías), libros simplificados, IGV básico.

Qué hacer: el config estándar de l10n_pe alcanza. Pero hacia 2027 estas categorías también entran a SIRE — necesitan un upgrade migration plan, no quedarse esperando.

Servicios digitales y export de servicios

No funciona en la caja. Los servicios digitales a no residentes exigen flujos CPE específicos con IGV exonerado, más las nuevas reglas para IGV de no domiciliados (relevante para plataformas digitales).

Qué hacer: módulo custom para IGV no domiciliados más el export-flow correcto. Costo: USD 4,000–10,000.

5 errores típicos al prepararse para SUNAT 2027

Patrones que se repiten en las PYME peruanas que vimos en 2025–2026. Cada uno cuesta dinero. La metodología de auditoría Odoo los detecta antes de que se vuelvan multas.

#1. «Ya estoy en SIRE desde 2025, todo bien»

Realidad: SIRE 2024–2025 fue la primera fase, con validaciones relativamente suaves. Hacia 2027 las reglas de auto-population del RVIE y el RCE se endurecen — el sistema exige limpieza en los datos CPE. Si tu customer master en Odoo está lleno a medias (RUC faltante, razón social desactualizada, dirección incompleta), SIRE va a generar basura que después hay que corregir a mano.

Costo del error: 0.3% UIT por día por presentación tardía, máximo 12 UIT por error.

#2. Postergar la migración GRE hasta el último momento

Por mi estimación, aproximadamente el 70% de las PYME con las que trabajé en Lima en 2025 seguían usando guías físicas «por costumbre». Después del 30 de junio de 2026 eso ya no funciona.

Costo del error: además de la multa por GRE no electrónica (S/ 1,605–3,210), demoras del producto en ruta durante controles SUNAT, pérdida de lead time, deterioro de customer experience.

#3. Un solo OSE sin plan de respaldo

Los OSE se caen. Cualquiera de los grandes operadores de Perú tuvo downtime en los últimos 24 meses — algunos por horas, otros por un día entero. Si tu único OSE no responde, tú no emites CPE — el cliente se va sin comprobante y tú pierdes la venta.

Costo del error: ventas perdidas más una multa potencial del 50% de la UIT por CPE no emitido si el cliente reclama.

Solución: SUNAT permite emisión de emergencia directamente desde su portal (sin OSE) con contingencia confirmada — pero eso exige configuración previa. Sumar un segundo OSE como hot-standby completa el cuadro.

#4. Versión vieja de Odoo (16 o inferior)

Odoo 14 y 15 ya no reciben actualizaciones activas de l10n_pe. Para inicio de 2027, la lógica de validación en esas versiones no va a cumplir los nuevos requirements de SUNAT.

Costo del error: o rechazos masivos de CPE, o un upgrade de emergencia en 30 días bajo presión — un proyecto-crisis de USD 25,000–60,000 con riesgo de pérdida de datos. El playbook de rescate Odoo sin pérdida de datos describe ese escenario en detalle.

#5. Self-hosted sin monitoring

Muchas PYME ponen Odoo en un VPS sin observability. Los CPE se envían, los errores SUNAT entran en logs, nadie mira. Para cuando se detecta el problema (auditoría, reclamo de cliente, o aviso SUNAT) ya pasó una semana o un mes — y las multas se acumulan según la escalera de penalidades.

Qué hacer: stack mínimo de monitoring — Sentry o Healthchecks.io sobre las fallas de envío CPE, summary semanal por email, dashboard en Metabase o Superset con rejection rate. Setup de 1–2 días y USD 0–500 el primer año.

Caso: retail en Lima, 6 tiendas, 12,000 CPE/mes

Caso anonimizado de trabajo en 2025–2026.

Situación: red retail en Lima con 6 tiendas físicas y un canal e-commerce. Ingresos anuales cerca de S/ 18 M. Usaban un POS legacy con export manual a PLE. La migración a un ERP se venía postergando «hasta el próximo año».

En diciembre de 2025 llegó la notificación SUNAT: incluidos en SIRE desde el 1 de enero de 2026. Seis semanas para estar listos.

Qué se hizo entre enero y febrero de 2026:

1. Audit de l10n_pe — el RUC en el customer master estaba completo solo en el 60% de los casos (el POS legacy lo omitía en modo boleta).
2. Despliegue de Odoo 17 con l10n_pe + l10n_pe_edi + l10n_pe_edi_stock + connector al OSE.
3. Import de 14 meses de CPE históricos del sistema legacy para cuadrar contra los registros SUNAT.
4. Setup de export SIRE vía un módulo community externo + reconciliación manual durante los primeros 3 meses.
5. Capacitación para contabilidad — 8 horas a lo largo de 2 semanas.

Resultado entre marzo y abril de 2026:

• 100% de CPE emitidos vía Odoo → OSE → SUNAT.
• Primera presentación SIRE en marzo de 2026 — 7 errores (rejection rate del 0.06%), todos corregidos antes del deadline.
• Costo del proyecto: USD 18,000 en 3 meses de implementación.
• Tiempo ahorrado por mes vs. legacy: cerca de 80 horas, equivalente a 1 FTE.
• Cost avoidance estimado en multas: USD 12,000–20,000 al año.

Seis semanas fue el mínimo absoluto para una PYME de ese tamaño, y solo porque la contabilidad ya manejaba el ciclo PLE. Si recién aprendes a leer un RVIE en febrero de 2026, ese mismo proyecto se vuelve de seis meses.

Lección: 6 semanas son el mínimo absoluto y solo con un equipo experimentado. Si llega la notificación SUNAT, la reacción es inmediata. En 2027 ya no va a haber margen para improvisar.

Conclusión: la ventana cierra en otoño de 2026

El período 2024–2026 fue la fase de entrenamiento. SUNAT aprendió y la industria de compliance aprendió con él. En 2027 ya no habrá «malentendidos»: el sistema está calibrado, las multas se aplican automáticamente vía cross-checking y el escalamiento corre por los plazos del Código Tributario.

Si tu Odoo no está listo para la nueva ola de validaciones, la preparación se hace antes de noviembre de 2026. Después, ya no es una migración planificada — es un proyecto-crisis con premium pricing y riesgo de multas durante la transición.

Material relacionado:

• Odoo en Perú — guía completa para PYME
• Checklist SUNAT 2026 para PYME — 47 puntos
• Curso Odoo + SUNAT 2026 para PYME peruanas
• Curso de auditoría Odoo — framework para PYME LATAM
• Implementación Odoo — roadmap de 16 semanas
• Rescate Odoo — migración sin pérdida de datos

Preguntas frecuentes