SUNAT 2027: Peru's final phase of tax digitalization

Timeline 2024–2026: how we got here

Physical waybills die on June 30, 2026. SIRE becomes mandatory for nearly every taxpayer on January 1, 2027. The shift that matters: penalties are no longer issued by an inspector — they fire from an algorithm that cross-checks records and does not forgive. If your Odoo isn't ready by fall 2026, the migration turns into a crisis project priced at emergency rates.

2026 was the warm-up year. SUNAT 2027 is the year the cross-checking system catches everything: a mismatch between GRE and invoice, a RUC in «no habido» status when the receiver opens the document, IGV off by a cent, ISC not applied on an alcohol sale. Each error is no longer a warning — it is a fine of 25% to 50% of the UIT (roughly S/ 1,340–2,680 at 2026 prices). For retail running more than 1,000 comprobantes a month, the math becomes fatal.

To understand what changes in 2027, look at the trajectory. SUNAT has been building electronic compliance since 2014, but the 2024–2026 stretch is an unprecedented sprint.

2024: SIRE for PRICOS and GRE expansion

The Resolución de Superintendencia that introduced SIRE applied it to PRICOS (Principales Contribuyentes Nacionales) starting January 2024. By year-end, SIRE covered roughly 14,000 large taxpayers — under 0.5% of the country's formal SMBs.

In parallel, electronic GRE expanded. More categories of goods movement shifted to the electronic format. By the end of 2024, the system processed about 250,000 GRE per month.

2025: SIRE for MEPECOS in staged rollout

In 2025 SUNAT began folding MEPECOS (Medianos y Pequeños Contribuyentes) into SIRE in waves — by RUC registration date and revenue. By year-end, around 80,000 taxpayers were in the system. Electronic GRE became the standard for carriers; the paper waybill was reduced to an exception.

2026: the critical year, three waves at once

• January 2026: SIRE became mandatory for all PRICOS and an expanded list of MEPECOS. The old PLE started losing its status for those categories.
• February 2026: new CPE validation rules. The system rejects comprobantes with inconsistent totals (amounts and IGV that don't tie), with a receptor RUC in «no habido» at issuance, or with missing mandatory B2B fields.
• June 30, 2026: the cut-off date for legally issuing a physical guía de remisión in most scenarios. After that, only electronic GRE.

By the end of 2026, roughly 95% of CPE will be electronic; SIRE will cover about 1.5 million taxpayers; and electronic GRE will be the only legal format for the vast majority of operations. The SUNAT 2026 47-point checklist describes the current phase. What's coming is stricter.

Four structural changes in 2027

SUNAT does not publish all 2027 rules in one shot — some resolutions get clarified across Q3–Q4 2026. But the trajectory is clear and the prep work happens now, not in January. Four concrete directions.

#1. SIRE becomes universal

By January 2027, SIRE extends to every taxpayer category, including Régimen Especial and MyPe Tributario. In practice:

• RVIE (Registro de Ventas e Ingresos Electrónico) and RCE (Registro de Compras Electrónico) get pre-filled by SUNAT from your CPE.
• The confirmation window runs through the 8th business day of the following month.
• The old PLE stops making sense for most categories.

The key shift: you no longer «generate» ledgers — SUNAT assembles them for you. That cuts accounting routine, but raises the bar sharply on source-data quality in the ERP. Any CPE error flows into SIRE automatically and forces a manual correction.

#2. GRE-only with no exceptions

By 2027:

• Every goods movement requires electronic GRE at the moment of dispatch.
• Paper waybills are accepted only with confirmed contingency (system outage).
• The lag between GRE issuance and actual movement gets monitored — a long gap triggers review.

For logistics, this means real integration between ERP, TMS, and SUNAT. Excel-based processes are out.

#3. Stricter CPE validations

Based on the 2024–2026 trajectory and SUNAT's published drafts, expect:

• GRE-to-invoice matching: every B2B invoice tied to a physical shipment must have a matching GRE with consistent data. Mismatch on amount, SKU, or quantity — automatic rejection.
• Real-time RUC validation: RUC status is checked not only at issuance but also at receiver acknowledgment. If the RUC slips into «no habido» in that window, the CPE risks rejection.
• ISC by product category: automatic check for Impuesto Selectivo al Consumo on alcohol, tobacco, fuel, and vehicles. ISC missing where required — rejection.

#4. More fines and cross-checking

Expected direction based on the 2024–2026 trend:

• Fine for a missing or incorrect CPE: up to 50% of UIT (around S/ 2,680 per case at 2026 prices). At 1,000 cases a month that's S/ 2.68 M a year — bankruptcy for an SMB.
• Late SIRE filing: 0.3% UIT per day, capped at 12 UIT (≈ S/ 64,300).
• Cross-check with bank data: SUNAT already runs ITF (Impuesto a las Transacciones Financieras) and a bank-data protocol. When declared revenue doesn't match actual bank movements, the audit flag fires.

Configuring Odoo for SUNAT 2027

What you actually need to wire up so 2027 isn't the year of fines. We start with the module baseline and end with the operational checklist. If you're still migrating off a legacy POS, the Odoo in Peru guide covers the full SMB architecture.

The baseline: l10n_pe and its limits

The l10n_pe module (current in Odoo 17–19) gives you the foundation:

• IGV 18% — standard tax positions.
• Boleta and factura electrónica — via l10n_pe_edi.
• CPE sequencing — series and numbering.
• Basic RUC validation when a customer is created.

What l10n_pe community does not cover out of the box:

• Direct SIRE integration — only a basic PLE export ships.
• Electronic GRE automation — the basic flow exists, but conformance to current SUNAT validation rules requires customization.
• Real-time pre-issuance CPE validation — needs integration with SUNAT's validation API through a certified OSE.
• ISC product taxonomy — taxes are there, but automatic application to product categories requires setup.

Seven-step operational checklist

1. Upgrade to Odoo 17+ — versions 14 and 15 no longer receive l10n_pe updates aligned with the new SUNAT requirements.
2. Install the bundle: l10n_pe + l10n_pe_edi + l10n_pe_edi_stock (the latter for GRE).
3. Connect a certified OSE (Operador de Servicios Electrónicos). Mandatory for PRICOS and de-facto required for MEPECOS. The official list lives on sunat.gob.pe.
4. Enable SIRE export — via third-party community modules or custom development.
5. Audit the RUC field across all customers — find and update the invalids and the «no habidos».
6. Audit product taxonomy — especially for ISC-affected categories.
7. Turn on monitoring — Sentry or Healthchecks on CPE submission failures. A week without checking logs and silent rejections pile up.

When the standard module is enough — and when it isn't

The most important section of this analysis. Not every scenario is the same, and implementation cost moves 5–10× across them. The Odoo implementation roadmap for LATAM SMBs is the reference we use for sizing each case.

Standard SMB: single RUC, simple B2B/B2C retail

Works out of the box. l10n_pe plus an OSE connector equals compliance-ready for basic flows.

Why: the main operations — boleta for B2C, factura for B2B, occasional GRE — are covered by the standard modules with the right setup.

What to do: install l10n_pe, connect a single OSE, map taxes, configure series, validate the email template for CPE. 2–4 weeks of implementation and a budget of USD 3,500–8,000.

Multi-RUC: holding or intercompany

Doesn't work out of the box. l10n_pe assumes one RUC per company. Intercompany transactions between distinct RUCs need separate CPE on distinct series with their own OSE accounts.

What to do: either separate Odoo company-instances per RUC (recommended architecture), or custom development for multi-company CPE generation. Cost: USD 8,000–20,000.

Logistics-heavy operations (more than 500 GRE/month)

Works partially. l10n_pe_edi_stock covers basic GRE flows but does not cover:

• Multi-stop deliveries (one dispatch to several destinations).
• Driver and vehicle management for GRE Transportista.
• Real-time tracking to meet the timing requirements.

What to do: a custom GRE extension plus integration with a TMS (Track-POD, Onfleet, or in-house build). Realistic setup: USD 15,000–35,000.

MyPe Tributario and Régimen Especial

Works with simplifications. Factura only (in most categories), simplified ledgers, basic IGV.

What to do: the standard l10n_pe config is enough. But by 2027 these categories also fall into SIRE — you need an upgrade migration plan, not a wait-and-see stance.

Digital services and service exports

Doesn't work out of the box. Digital services to non-residents require specific CPE flows with exempt IGV, plus the new rules for IGV on non-domiciled providers (relevant for digital platforms).

What to do: a custom module for non-domiciled IGV plus the right export flow. Cost: USD 4,000–10,000.

5 common mistakes preparing for SUNAT 2027

Patterns that repeat across the Peruvian SMBs we saw in 2025–2026. Each one costs money. The Odoo audit methodology catches them before they become fines.

#1. «I've been on SIRE since 2025, I'm fine»

Reality: SIRE 2024–2025 was the first phase with relatively soft validations. By 2027 the RVIE/RCE auto-population rules tighten — the system demands clean CPE data. If your customer master in Odoo is half-filled (RUC missing, outdated razón social, incomplete address), SIRE will generate garbage that you'll have to fix by hand.

Cost of the mistake: 0.3% UIT per day for late filing, capped at 12 UIT per error.

#2. Putting off the GRE migration until the last minute

By my estimate, roughly 70% of the SMBs we worked with in Lima during 2025 kept issuing physical waybills «out of habit». After June 30, 2026 that simply doesn't work anymore.

Cost of the mistake: beyond the fine for a non-electronic GRE (S/ 1,605–3,210), goods sit in transit during SUNAT controls, lead time blows up, and customer experience degrades.

#3. A single OSE with no fallback

OSEs go down. Every major Peruvian OSE had downtime in the past 24 months — some for hours, some for a full day. If your only OSE is down, you don't issue CPE — the customer walks out without a receipt and you lose the sale.

Cost of the mistake: lost sales plus a potential 50% UIT fine for unissued CPE if the customer complains.

Fix: SUNAT allows emergency issuance directly through its portal (without an OSE) under confirmed contingency — but that requires prior setup. Adding a secondary OSE as hot standby completes the picture.

#4. Old Odoo version (16 or below)

Odoo 14 and 15 no longer receive active l10n_pe updates. By the start of 2027, their validation logic will not match the new SUNAT requirements.

Cost of the mistake: either mass CPE rejections, or a 30-day emergency upgrade under pressure — a crisis project at USD 25,000–60,000 with data-loss risk. The zero-loss Odoo rescue playbook walks through that scenario in detail.

#5. Self-hosted with no monitoring

Many SMBs run Odoo on a VPS with zero observability. CPE go out, SUNAT errors hit the logs, nobody looks. By the time the problem surfaces (audit, customer complaint, or SUNAT notice), a week or a month has passed — and fines accumulate on the penalty escalation ladder.

What to do: a minimal monitoring stack — Sentry or Healthchecks.io on CPE submission failures, a weekly summary email, a dashboard in Metabase or Superset with rejection rate. 1–2 days of setup and USD 0–500 in the first year.

Case: Lima retail chain, 6 stores, 12,000 CPE/month

Anonymized case from 2025–2026 client work.

Situation: a Lima retail chain with 6 physical stores and an e-commerce channel. Annual revenue around S/ 18 M. The team ran a legacy POS with manual PLE export. ERP migration had been pushed «to next year» on repeat.

In December 2025 the SUNAT notice landed: SIRE inclusion effective January 1, 2026. Six weeks to be ready.

What was done between January and February 2026:

1. l10n_pe audit — RUC in the customer master was filled in only 60% of records (the legacy POS skipped it on boleta mode).
2. Deployed Odoo 17 with l10n_pe + l10n_pe_edi + l10n_pe_edi_stock + an OSE connector.
3. Imported 14 months of historical CPE from the legacy system to reconcile against SUNAT registros.
4. Set up SIRE export via a third-party community module plus manual reconciliation for the first 3 months.
5. Accounting team training — 8 hours across 2 weeks.

Result between March and April 2026:

• 100% of CPE issued through Odoo → OSE → SUNAT.
• First SIRE filing in March 2026 — 7 errors (0.06% rejection rate), all fixed before the deadline.
• Project cost: USD 18,000 over 3 months of implementation.
• Time saved per month vs. legacy: around 80 hours, equivalent to 1 FTE.
• Estimated cost avoidance on fines: USD 12,000–20,000 per year.

Six weeks was the absolute minimum for an SMB of that size, and only because the accounting team already knew the PLE cycle. If you're learning to read an RVIE for the first time in February 2026, the same project turns into six months.

Lesson: six weeks is the absolute minimum, and only with an experienced team. When the SUNAT notice arrives, you react immediately. By 2027 there will be no margin for improvisation.

Conclusion: the window closes in fall 2026

The 2024–2026 stretch was the training phase. SUNAT learned, the compliance industry learned with it. By 2027 there are no more «misunderstandings»: the system is calibrated, fines fire automatically through cross-checking, and escalation runs on Código Tributario timelines.

If your Odoo isn't ready for the new wave of validations, the prep work happens before November 2026. After that, it stops being a planned migration — it becomes a crisis project with premium pricing and exposure to fines during the transition.

Related reading:

• Odoo in Peru — full SMB guide
• SUNAT 2026 SMB Checklist — 47 compliance points
• Odoo + SUNAT 2026 course for Peruvian SMBs
• Odoo audit course — framework for LATAM SMBs
• Odoo implementation — 16-week roadmap
• Odoo rescue — zero-loss migration

Frequently asked questions