SUNAT e-invoicing 2026: what changes and how to avoid the fine

One-minute summary

If your SMB in Peru invoices more than 75 UIT a year (~S/ 401,250) and you still print remission guides on paper or keep the Registro de Compras in Excel, you have less than twelve months before that stops being viable. SUNAT is rolling out a three-stage regulatory wave that closes the paper regime for mid-sized companies — and the fine per document runs from 1 UIT to 5 UIT, with temporary closure of the establishment if you repeat.

• Three waves in 2026: SIRE — January 1 · strict CPE validation — February 1 · end of physical remission guide — June 30.
• Real fines: from S/ 2,675 (50% UIT) up to S/ 4,200 (1 UIT) per document, plus temporary closure of 10 to 60 days on repeat offenses.
• SIRE is mandatory for Principales Contribuyentes (PRICOs) and for Régimen General and MYPE Tributario taxpayers with annual revenue above 75 UIT (~S/ 401,250).
• CPE validation: rejected XML is bounced back instantly by the OSE or PSE. The conditional mode is gone.
• Migrating is not the same as buying an OSE. You need an ERP that emits clean UBL 2.1, supports GRE 2.0 and can export to SIRE.
• Odoo + l10n_pe covers the base, but the SIRE export and the OSE/PSE connector get configured case by case.

Where this transition came from and why now

SUNAT launched electronic invoicing in 2010 and has been narrowing the paper margin step by step ever since. By 2024, more than 99% of facturas and boletas were already issued electronically through an OSE or PSE. In parallel, the regulator installed PLE — Programa de Libros Electrónicos — a TXT format for purchase and sales books. It worked, but it was coarse: TXT with no real-time validation, formal errors that surfaced months later, and CPE mismatches that only showed up during an audit.

SIRE is the next step beyond PLE. SUNAT prebuilds the proposal for the Registro de Compras and the Registro de Ventas e Ingresos using the CPE that were actually issued and received. The taxpayer only edits, confirms and submits. That closes the gap between real document flow and the formal record. For a deeper read on SIRE specifically, see SIRE SUNAT January 2026 — SMB guide.

GRE 2.0 is the third leg. Until 2026, the physical paper guide and the electronic GRE version 1.0 coexisted. From July 1, 2026, only GRE 2.0 stands as the legal document to support the movement of goods.

The three dates that matter in 2026

Why this moment and not another

Three reasons. The first is the tax gap: SUNAT estimates IGV evasion at around 30% of potential collection. The electronic chain factura → SIRE → monthly return closes those holes. The second is scale: more than 4 billion CPE were issued in 2025 — without real-time validation, that is a swamp for after-the-fact audits. The third is the physical guides, the main channel for factura-without-guide and guide-without-factura schemes. GRE-only closes the logistics leg in traceability.

The regulator will not back down. The extensions — including the latest stretch of the physical guide to June 30, 2026 — are the last ones.

Technical requirements: what to do by each date

By January 1 — get SIRE-ready

1. Activate SIRE through Clave SOL. Mi RUC → SIRE → Afiliación. Activation is irreversible: once done, PLE is no longer available for the same periods.
2. Configure the export in SIRE format. It is a JSON payload, not TXT like PLE. The structure is set by Annex II of R.S. 040-2022/SUNAT and later updates.
3. Match CPE against SIRE. Every CPE received from suppliers lands automatically in the Registro de Compras proposal. The taxpayer confirms or adjusts — for example, excludes hospitality CPE that does not grant IGV credit.
4. Keep the PLE archive. PLE files already filed stay available for 5 years, but download usability drops once you migrate. The prudent move is to pull local copies before January 1.

By February 1 — strict CPE validation

The new rules are applied by the OSE/PSE and SUNAT at the moment of issuance. Five blocks:

• UBL 2.1 XML structure. Any deviation — namespace, element order, mandatory fields — returns a rejection with error codes 2335, 2336, 2358 and similar.
• Recipient RUC in real time. Query against the SUNAT padron at issuance. If the RUC is invalid or its status is baja, the CPE is rejected.
• IGV arithmetic. The IGV amount matches base imponible × 18% exactly (or 0% / 10% for the regimes that apply). Rounding follows Annex VIII rules.
• Series and numbering. Uniqueness and continuity check. A missed number triggers rejection on the whole series that follows.
• CDR within 7 days. The Constancia de Recepción from SUNAT must arrive within 7 calendar days. If it does not, the CPE counts as not submitted — even if the IGV is already declared.

By June 30 — GRE 2.0

The GRE is actually two linked documents:

• GRE Remitente — the party that dispatches the goods. Carries customer data, the load, the route, the reason for movement and the ubigeo of origin and destination.
• GRE Transportista — the party that moves the goods. Carries vehicle data (plate), driver data (license, document) and the route.

GRE 2.0 requires:

• Link with a factura or an explicit no-aplica with justification.
• Real-time issuance before transport starts, not after.
• Mandatory identification of vehicle and driver.
• Correct ubigeo (INEI catalog) for origin and destination.

What Odoo with l10n_pe covers, and what it does not

Odoo with the l10n_pe module plus partner extensions (OCA, Vauxoo, Defontana-PE) covers:

• UBL 2.1 XML generation for factura, boleta, credit note and debit note.
• XAdES-BES signing.
• Sending through OSE/PSE — Nubefact, Sunat-PSE, Efact, FactiliZA.
• CDR reception and link to the journal entry.

What is not out of the box for 2026:

• SIRE export. Standard l10n_pe emits PLE TXT. For SIRE you need a custom module; upstream Odoo 19, released in June 2026, promises partial support per the roadmap.
• GRE 2.0. Odoo 17 supports GRE 1.0. For 2.0 you need patches or partner modules.
• CPE reception. Receiving supplier CPE with XML parsing and matching against purchase orders is a separate project (l10n_pe_edi_purchases or an integration with the OSE inbox).
• Preflight validations. Validating XML locally before sending it to the OSE lowers your rejection rate, but is not in the standard pack.

In practice, almost every Odoo install in Peru runs l10n_pe plus one of three partner stacks. Moving to SIRE and GRE 2.0 means either forward-porting patches into l10n_pe, or waiting on Odoo 19. For a wider look at the ecosystem, see Odoo in Peru — country pillar.

When it applies and when it doesn't

#1. Service SMB in Lima, ~30 boletas/day, S/ 800,000 revenue

Standard setup. Régimen MYPE Tributario with revenue > 75 UIT (S/ 401,250), no PRICO status. SIRE mandatory from January. The volume — ~7,800 boletas plus ~600 facturas a year — is fully covered by standard l10n_pe and any top-5 OSE. The SIRE migration is activating in SOL and configuring the export in one of the standard Odoo formats. One day of consultant time.

#2. Distributor in Arequipa, 80 GRE/day, S/ 3.5M revenue

Non-trivial setup. The main pain is GRE 2.0. Revenue exceeds the MYPE ceiling or falls into Régimen General with > 75 UIT — SIRE mandatory from January. 80 GRE/day means offline issuance (at a remote warehouse without stable internet) and linking with route sheets become technical blockers. You need either an OSRM-route → GRE generation connector, or a mobile app for the driver with an offline buffer. Standard l10n_pe does not solve this. Budget — USD 15,000 to USD 30,000 for custom dev and integration.

#3. Restaurant in Cusco, 4 locations, ~200 boletas/day, S/ 600,000 revenue

Does not apply directly — the approach is different. Revenue below 75 UIT — SIRE voluntary. The February 2026 CPE validation does apply (it hits every issuer). GRE is irrelevant — nothing physically moves. What you do need: Odoo POS integration at each location, one OSE provider for all 4, automatic boleta issuance after every sale. Solved by standard l10n_pe + point_of_sale + any OSE, with no custom dev. Budget — USD 4,000 to USD 8,000.

#4. Construction company with 12 simultaneous projects, S/ 25M revenue

All three requirements bite. Facturas to clients with multiple adelantos and valorizaciones per project, GRE on every material transfer between warehouse and site, supplier CPE reception from dozens of vendors. Standard Odoo + l10n_pe covers the base but does not cover: linking adelantos → final factura (custom management of advance accounts), multi-site GRE generation in offline mode, drawback and detracción recovery (construction-specific). Budget — USD 40,000 to USD 80,000 for the full stack. For cases like this, a 30-minute Odoo audit usually pays for itself before committing the budget.

#5. Freelance designer, S/ 90,000 revenue

Most requirements do not apply. Régimen Especial or RUS, below the SIRE threshold. CPE — yes, mandatory (boletas to clients). GRE — irrelevant. Odoo is overkill: the right tool is an OSE with a web UI like Nubefact. ~USD 25/month, no ERP.

Common mistakes that trigger fines

#1. "I have an OSE, so I'm ready"

The OSE or PSE only handles issuance, signing and sending the CPE to SUNAT. They do not own the correctness of the data (recipient RUC, IGV bases), the SIRE export, GRE 2.0 or supplier CPE reception. An SMB that thinks Nubefact or Defontana equals full compliance will hit an 8-12% rejection rate under the February rules: dirty master data carried over from the Excel era smashes into a hardened validator.

#2. Excel-based Registro de Compras with manual copy-paste from CPE

Before SIRE, that method worked. After January 1, 2026, for taxpayers above 75 UIT, it ceases to exist. SIRE generates the registry proposal automatically from the CPE actually received. If you edit your Excel and upload it to SIRE, the divergence with the automatic registry triggers a notification, then a fine for inconsistency between comprobantes and registros.

#3. Boleta vs factura — picking the wrong document by recipient

The new validation instantly rejects a factura issued to an individual without a RUC (boleta is correct) and a boleta issued to a legal entity with a RUC for an amount > S/ 700 (factura is correct). Until 2026 this was forgiven; after the tightening it equals a rejection plus a fine for incorrect documentation. The fine under Art. 174.2 of the Código Tributario is 0.6% of IB (ingreso bruto del periodo), with a minimum of 10% UIT (~S/ 535).

#4. GRE "later" — once the truck is already moving

Classic practice: the driver leaves, two hours later the office files the GRE and posts it. From July 1, 2026, that is a Código Tributario violation — remitir bienes sin guía de remisión. Fine: 50% UIT (~S/ 2,675) per case, plus the risk of incautación del bien at the next SUNAT checkpoint.

#5. Ignoring "conditional" CPE from the past

If in 2024 or 2025 you issued CPE and the CDR did not arrive within 7 days, that CPE is formally not submitted — even if you already declared the IGV. In 2026, when the SIRE proposal gets crossed against the CPE history, SUNAT will see the gap. Every dangling CPE must be retransmitted (if still possible) or formally voided and reissued with new numbering.

Anonymous case: distributor in Lima

Situation (Q4 2025). Electronics distributor in Lima, Régimen MYPE Tributario, S/ 2.1M in revenue (~400 UIT). Stack: QuickBooks for accounting, Nubefact for CPE issuance, Excel for Registro de Compras and Ventas, physical guides on every delivery. Team: 1 accountant, 2 sales reps, 1 warehouse lead, 2 drivers. 60-80 facturas, 200 boletas and 30 GRE per day.

Trigger. In October 2025 a SUNAT notification arrived — audit of the Registro de Compras for July 2025. Gap against the automatic CPE base: S/ 18,400 of IGV not supported (loss of the right to crédito fiscal). On top of that: 4 GRE on large deliveries from the previous month were missing — they only found out from a customer call.

What we did (November 2025 - January 2026). Migration QuickBooks → Odoo 17 Community + l10n_pe + Nubefact connector. Custom module for SIRE export (OCA fork with local adjustments). Move to Nubefact full plan with GRE 2.0 and Odoo integration. POS tablet for drivers: offline buffer for 50 GRE, sync on return to the warehouse. Training: 3 days for the accountant (SIRE workflow) plus 1 day for the drivers.

"In November we thought the problem was the accountant. By January we understood the problem was that no system was talking to any other system. Migrating Odoo wasn't a software swap — it was the first time in five years we had a single operating system for the business."

Result (February 2026). CPE rejection dropped from 9.3% (Q3 2025) to 1.1% (January 2026). Every GRE is issued before the truck leaves (before, 70% were post-facto). SIRE-readiness in the first month: the automatic proposal matched the final declaration at 99.2%. Investment: USD 9,200 over 8 weeks. Avoided risk: estimated Q1 2026 fines under the status quo ran S/ 18,000 to S/ 30,000.

This is the typical scale for an SMB with 300-600 UIT in revenue in Lima: 6-12 weeks of migration, USD 6,000 to USD 15,000 investment, 18-24 months of payback through recovered crédito fiscal and avoided fines. When the Odoo project is already running but failing, the pattern is covered in rescuing failing Odoo projects.

Checklist and next step

Pull the SUNAT 2026 checklist for your Odoo — 24 points on SIRE, CPE validations and GRE 2.0, with concrete l10n_pe modules and settings. PDF, 14 pages, no email spam. Or book a 30-minute audit call — we go through the current stack and call out what is critical before each of the three dates.

FAQ