SUNAT electronic invoice 2026: what changes and how to configure Odoo to avoid penalties

One-minute brief — what changes and when

In January 2026 SUNAT extended SIRE to mid-sized companies. As of February 1, new CPE validations apply — strict UBL 2.1, real-time RUC checks on the buyer, mandatory detraction fields in the XML. From July 1, 2026 the paper guía de remisión stops being a legal document. This is the fourth and final prórroga tramo. If your Odoo was set up in 2022, it meets none of the three requirements today — and it shows on the first audit.

• SIRE becomes mandatory for third-category income taxpayers with annual revenue above 1 700 UIT starting January 1, 2026. From October 1, 2026 it covers every other CPE issuer. PLE for books 8 and 14 stops being accepted on those dates.
• New CPE validations take effect February 1, 2026: online RUC checks on the receiver, strict UBL 2.1, required fields for detracciones, and tipo de cambio validation against the SBS rate.
• GRE becomes the only legal shipping document on July 1, 2026 — the fourth and final extension, set by Resolución 000040-2025/SUNAT.
• Penalties: from 1 UIT (~S/ 5 350) per rejected CPE up to 25 UIT (~S/ 133 750) and establishment closure up to 30 days.
• Odoo 17 and 18 cover everything through the l10n_pe + l10n_pe_edi + l10n_pe_edi_stock stack plus community modules for SIRE. Any setup older than 2024 needs review — no exceptions.

What changes in SUNAT 2026 — the exact timeline

SUNAT does not ship 2026 as one bundle. There are four independent tracks, each with its own schedule, its own sanctions regime, and its own operating risk. Tying them all into a single migration project is the most expensive planning mistake we see partners in Lima make. For a deeper look at SIRE specifically, see SIRE SUNAT January 2026 — PYME guide.

#1. January 2026 — SIRE goes mandatory for mid-sized companies

The Sistema Integrado de Registros Electrónicos (SIRE) replaces PLE for the two heaviest books: Sales and Income Register (libro 14.1) and Purchases Register (libro 8.1). Since 2023 SIRE has run for PRICO (Principales Contribuyentes) and large filers. From January 1, 2026 it is mandatory for every third-category income taxpayer with annual revenue above 1 700 UIT (~S/ 9 095 000 at the 2025 UIT value). From October 1, 2026 it extends to every other CPE issuer.

The key difference between SIRE and PLE: SUNAT pre-builds the propuesta for both registers using the CPEs that you (or your suppliers) already issued. Your job is to confirm, adjust, or reject. That means your own CPEs feed your RVIE directly. An error in the CPE shows up in the register automatically — and you have to explain it later in the cross-check.

If you keep sending PLE 5.x.x for libro 14 after January 1, 2026, SUNAT does not accept it — formally the books are not filed. Penalty under numeral 2 of article 175 of the Tax Code: 0.6% of net income, minimum 10 UIT, maximum 25 UIT.

#2. February 2026 — new CPE validations

From February 1, 2026 the SUNAT and OSE (Operador de Servicios Electrónicos) validators apply a new rule set to every XML. The changes most likely to break existing integrations:

• Real-time RUC validation on the receiver. If the receiver is not registered or its status is not ACTIVO/HABIDO, the invoice comes back as RECHAZADO. Previously it was a warning on the CDR. Now it is a hard reject.
• Strict UBL 2.1. The cbc:ID field inside cac:InvoiceDocumentReference is mandatory on credit and debit notes. Notes without a reference to the original CPE come back RECHAZADO.
• Detracciones validation. If the product or service code is subject to detracción (transportation, construction, agencies, etc.), the sac:AdditionalProperty field with the service code is mandatory. Without it, RECHAZADO with error code 4143.
• Tipo de cambio. If the currency is not PEN, the cbc:CalculationRate field gets validated against the official SBS rate for the issue date. Tolerance ±0.5%. This is critical for exporters and companies that operate in USD.
• Recibos por honorarios. RHE adds validation of the income type and the 8% withholding rate for fourth-category income.

The technical bottom line: if your l10n_pe_edi is updated to 17.0.1.5+ (Odoo 17) or 18.0+, the validations work out of the box. Older versions do not. A backport is possible but requires custom development.

#3. July 2026 — GRE becomes the only legal shipping document

The Guía de Remisión Electrónica (GRE) has been formally mandatory since 2022, but the paper guía stayed valid through four consecutive prórrogas. The last one — Resolución 000040-2025/SUNAT — sets the final date at July 1, 2026. After that date, the paper guía stops existing as a legal document. If a truck rolls out on July 2 with a paper guía, that is transport without authorized documentation — an infracción.

The GRE comes in two flows: GRE Remitente (from the shipper) and GRE Transportista (from the carrier). If you use third-party logistics, both guías must be issued and linked by the código de enlace. That is a critical requirement for retail chains with high inter-store transfer volume.

#4. The standing rule — boleta electrónica with DNI

This is not a 2026 event, but it is worth restating: for the buyer to deduct the expense, the boleta must include the DNI or RUC of the receiver when the amount is at least S/ 700. Without that field, the expense is not deductible. SUNAT has enforced this since 2024, but in 2026 it adds automatic verification through the SIRE cross-check. Forgetting it used to be survivable; now it is not.

Technical requirements for Odoo under SUNAT 2026

Odoo's base Peru localization is the l10n_pe module. It covers the chart of accounts (PCGE), tax rates (IGV 18%, percepción, retención), and partner classifications (RUC, DNI, CE). It is not enough on its own. CPE needs a full stack, and SIRE needs a separate addon. For a broader view of the ecosystem, see Odoo in Peru — country pillar.

Minimum module stack for Odoo 17 and 18

l10n_pe_edi in Enterprise ships with Digiflow by default, but the connector is standardized — any OSE that supports the UBL 2.1 endpoint plugs in (Nubefact, The Factory HKA, Efact, Bizlinks, Paperless). Each OSE expects its own credential set and contract — that is the operational piece.

The l10n_pe_sire piece does not yet ship in Odoo Enterprise. It is a gap that community forks fill (OCA, Adhoc, NavMatic) or that custom development covers. If your Odoo partner does not mention SIRE in the first conversation, that is a red flag.

Electronic invoice issuance flow in Odoo

1. Create the account.move — type out_invoice from Sales or Accounting.
2. Field validation — Odoo checks the document type (l10n_latam_document_type_id), the series (FXXX, BXXX), the number, the partner RUC (validated by cron every 24 hours), the IGV, and the issue date.
3. Generate UBL 2.1 XML — the module builds the XML to SUNAT 1.0+ spec. From February 2026 onward it includes the new required fields.
4. X.509 signature — the XML is signed with the company certificate or the OSE certificate (depends on the contracted scheme).
5. Send to OSE/SUNAT — the XML is posted to the OSE SOAP endpoint (REST in newer integrations).
6. CDR — SUNAT returns the Constancia de Recepción. Status 0 is ACEPTADO. Codes 2000–3999 are issuer errors (fixable). Codes 4000+ are validation errors: RECHAZADO with no resubmission path.
7. Archive — the XML and CDR are stored in Odoo for at least 5 years (the tax prescription window).

Configuring SIRE in Odoo

Odoo Enterprise does not ship a SIRE module. The base workflow for a community extension:

1. Extract data from account.move.line by period (monthly).
2. Map to the RVIE 14.1 and RCE 8.1 format (fixed-width fields, TXT with | separator).
3. Validate against the SIRE schema (operation types, detraction codes, retentions).
4. Reconcile against the SUNAT propuesta (pull the propuesta from the SIRE API, compare, surface differences).
5. Confirm / adjust / reject — the action runs in the SUNAT portal or via the SIRE API.

The SIRE API is the critical improvement many partners ignore. Since 2024 SUNAT offers an official REST API with OAuth 2.0. If your Odoo connects to it directly, monthly RVIE+RCE close stops being a three-day accountant task and becomes an overnight cron job.

Certificates, OSE, and failure points

SUNAT does not accept a CPE without an X.509 v3 signature from an approved Certificate Authority: Andina, RIESCOM, Innova IT, Camerfirma. The certificate expires every 1–2 years and must be renewed before the expiry date. A CPE signed with an expired certificate counts as not issued — with every consequence that follows.

For PYMEs we recommend issuance via OSE: it offloads the SUNAT uptime risk, the certificate sits on the OSE side, and the contract includes an SLA. The cost runs S/ 0.05–0.30 per CPE depending on volume. Direct issuance via SUNAT SOL only makes sense for large filers with their own IT team.

5 common Odoo configuration mistakes under SUNAT — and what they cost

What follows are real cases from Odoo implementation audits we ran in Lima between 2024 and 2025. All five mistakes showed up in roughly three of every four PYMEs that came in for rescue. For the full diagnostic framework, see Odoo audit — 47-point framework.

#1. Document series hard-coded into journals without proper config

Often an accountant hard-codes series F001, F002, B001 into each sale.journal. If the same series appears in another journal or duplicates, SUNAT rejects the CPE with error code 2017 (duplicate numbering). Penalty under numeral 4 of article 174 of the Tax Code: 50% UIT (~S/ 2 675) per incident, plus the series gets locked until a formal renumbering.

The right way: one series, one journal, configured through account.journal.l10n_latam_use_documents = True. The module's unique constraint locks the series out of other journals.

#2. IGV calculated at the product level instead of the line level

By default Odoo attaches the tax to the product. When an invoice mixes products with IGV 18% and IGV 0% (exoneradas, export) and the fiscal_position inherits incorrectly, the total IGV is no longer 18% × base. The CPE passes SUNAT validation (the XML is formally valid), but the SIRE cross-check flags the discrepancy. Penalty for under-declaration plus moratorio interest at 1.2% monthly, compounding.

The right way: the account.tax carries the correct repartition_line, and the fiscal_position maps taxes for different taxpayer types (exporters, non-domiciled, exempt). Minimum test: create three invoice variants (three buyer types) and inspect the XML manually before going to production.

#3. GRE not linked to the invoice

Many setups run GRE as a separate flow from the sale.order and never link it to the final account.move. It works technically, but in the cross-check SUNAT cannot see the invoice → GRE → delivery chain. A fiscalization alert appears: "invoice without confirmed delivery." That is not a direct fine, but it is a trigger for inspection.

The right way: the GRE is generated from stock.picking after validation, and the account.move references l10n_pe_edi_dispatch_id on that GRE. Then SIRE sees the issue → dispatch → delivery chain.

#4. Boleta electrónica without DNI when the amount is at least S/ 700

Odoo POS issues the boleta anonymously (no DNI) even when the amount is S/ 1 200. If that customer later asks for the document for deduction, they have nothing: a boleta without DNI is not deductible. Your company carries double exposure: a complaint from the customer for failing to issue the correct CPE, and a penalty if SUNAT picks up the pattern during a fiscalization.

The right way: in pos.config enable the mandatory DNI flag when the amount exceeds S/ 700. The custom flag is named pos_l10n_pe_dni_threshold. The cashier is required to ask for the DNI — the UX flow blocks the sale without it.

#5. PLE keeps getting submitted after SIRE migration

The most expensive mistake. The company migrates to SIRE for libro 14 in January 2026, but the Odoo cron keeps generating PLE 14.1 TXT and uploading it. SUNAT logs a double submission: automatic inconsistency, explanation request, and if you miss the 5-day window, penalty for non-compliance plus a deep review. Three clients in the portfolio paid for it in 2024 before we took them over.

The right way: when activating SIRE, disable PLE 14 (libro 14) and PLE 8 (libro 8) generation in account.report.l10n_pe.ple. Keep only the books that stay outside SIRE: 1 (cash), 3 (inventory), 5–7 (fixed assets), 9–13 (payroll, retentions). Configured through the report_id mask.

Case: Lima textile PYME migrated to Odoo 17 + SIRE

A Lima textile PYME, 180 employees, around S/ 22 million in annual revenue, exporting to the United States and Colombia. Before we got involved: SAP Business One v9.2 plus 3 parallel spreadsheets plus a controller who ran manual adjustments every month to reconcile. The problem: they could not plug into SIRE (SAP B1 does not export the data in the required format without a USD 18 000 add-on), and the prior partner had abandoned the Odoo project half-done in 2023.

What we did in 4 months:

• Forensic audit of SAP B1 — 2 weeks. We documented 84 inconsistencies in libro 8 (Purchases) and 41 in libro 14 (Sales). Cumulative penalty exposure: roughly S/ 280 000 plus interest.
• Migration to Odoo 17 Enterprise in 3 waves by business unit (production → warehouse → commercial), no big bang.
• SIRE connection via a custom l10n_pe_sire extension (we forked the OCA branch and adapted it to the client's multi-company architecture). RVIE and RCE go out automatically on the 8th of each month via cron and the SIRE API.
• GRE Remitente and Transportista — we configured the chain from warehouse exit in Villa El Salvador to international delivery in the United States (including enlace with the export DUA).
• BI on top of Odoo — margin by collection in real time, layered on Odoo through ClickHouse + Superset. The CFO sees the margin on her phone before the monthly close.

Results measured 6 months after go-live (measured by the client's CFO, not us):

• Monthly accounting close: 14 days → 3 days.
• SIRE inconsistencies: 0 from month five onward.
• Penalties accumulated after go-live: 0.
• License savings: S/ 280 000 per year (Odoo Enterprise + hosting + unlimited support < SAP B1 alone).
• Accounting FTE: 1.5 people reassigned to financial analysis, off the operational reconciliation work.

The methodological point: we did not start with migration. First — 2 weeks of audit (S/ 9 500 flat, credited against the project). That alone kept the client from carrying SAP errors into Odoo. Half of Odoo implementations in Peru fail because the error transfer happens in the first month, and the next 6 months go into "fixing" old problems inside the new system.

Checklist — what to review in Odoo before July 1, 2026

If your Odoo is already issuing CPE, run through these 7 items now. They cover 80% of the risk surface against the new SUNAT 2026 requirements.

1. l10n_pe_edi version — 17.0.1.5+ or 18.0+.
2. X.509 certificate — valid through at least October 2026.
3. Receiver RUC — validation cron enabled (partner.l10n_pe_check_ruc).
4. Detracciones — service codes set in account.tax.l10n_pe_edi_unspsc_code.
5. Tipo de cambio — sync with SBS via cron, at least daily.
6. SIRE — migration plan from PLE 8/14 approved, PLE cutoff date set.
7. GRE — the stock.picking → GRE → account.move chain tested end to end.

Frequently asked questions