ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Peru — SUNAT, Comprobante de Pago Electrónico

Peru rolled out its universal Comprobante de Pago Electrónico (CPE) mandate via SUNAT in 2018. The format is UBL-PE 2.1, a Peruvian profile of UBL 2.1 enriched with official SUNAT catalogues, with mandatory XML signature and server-side validation hash (CDR).

Regulatory timeline

  • 13 August 2010 — RS 188-2010/SUNAT. First CPE framework on a voluntary basis through SEE-SOL.
  • 13 November 2014 — RS 300-2014/SUNAT. Framework for Operadores de Servicios Electrónicos (OSE) for private PSEs.
  • 1 July 2015 — Principal taxpayer mandate. Mandatory for Principales Contribuyentes Nacionales (PRICOS).
  • 26 November 2015 — RS 339-2015/SUNAT. Creates the OSE registry and technical obligations.
  • 1 January 2018 — Universal go-live. CPE obligation extended to all businesses with annual turnover > 150 UIT (≈ PEN 600,000).
  • 10 May 2019 — RS 097-2019/SUNAT. Consolidated SUNAT code catalogues (Cat01–Cat51), reference source for document types, payment means, units, currencies, etc.
  • 2022 — Progressive threshold lowering. Threshold drops to 75 UIT, then 23 UIT (≈ PEN 121,000) in 2024 for micro-enterprises.
  • 2025-2026 — Mandatory electronic Boleta de venta B2C. Progressive extension to Boletas (B2C final consumers) with real-time reporting for retail.

Technical schema

The format is UBL-PE 2.1, the Peruvian profile of OASIS UBL 2.1 with SUNAT extensions (UBL Extensions for XMLDSig signature). Specifics:

  • ISO-8859-1 encoding — the XML must declare Latin-1 encoding, not UTF-8 (otherwise rejection code 2335).
  • CustomizationID 2.0 — current Peruvian profile version.
  • ProfileID per scenario (Catalogo 51): 0101 (domestic sale), 0200 (export), 0301 (services-related internal), etc.
  • SUNAT catalogue schemas: Catalogo 01 (document type), Catalogo 06 (identity type — 6 for RUC, 1 for DNI), Catalogo 07 (IGV codes — 1000 standard 18 %, 9995 exemption), etc.
  • ds:Signature: mandatory XMLDSig block in UBLExtensions/UBLExtension/ExtensionContent, with an X.509 certificate issued by a recognised CA.

Minimal example of an electronic factura 01:

xmlfactura-pe-ublPE21.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
         xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <cbc:UBLVersionID>2.1</cbc:UBLVersionID>
  <cbc:CustomizationID>2.0</cbc:CustomizationID>
  <cbc:ProfileID schemeAgencyName="PE:SUNAT"
                 schemeURI="urn:pe:gob:sunat:cpe:see:gem:catalogos:catalogo51">0101</cbc:ProfileID>
  <cbc:ID>F001-00000142</cbc:ID>
  <cbc:IssueDate>2026-05-16</cbc:IssueDate>
  <cbc:IssueTime>10:30:00</cbc:IssueTime>
  <cbc:InvoiceTypeCode listAgencyName="PE:SUNAT"
                       listName="Tipo de Documento"
                       listURI="urn:pe:gob:sunat:cpe:see:gem:catalogos:catalogo01">01</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>PEN</cbc:DocumentCurrencyCode>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyIdentification>
        <cbc:ID schemeID="6">20100070970</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>EDIVERSE DEMO PERU S.A.C.</cbc:RegistrationName>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PartyIdentification>
        <cbc:ID schemeID="6">20505425042</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>CLIENTE DEMO S.A.C.</cbc:RegistrationName>
      </cac:PartyLegalEntity>
    </cac:Party>
  </cac:AccountingCustomerParty>
</Invoice>

Submission flow

The seller signs the UBL-PE then sends it compressed (.zip) via:

  • SEE-SOL: SUNAT direct portal (web or API), free for low volume.
  • SEE-OSE: private Operador de Servicios Electrónicos certified by SUNAT. The OSE validates, transmits to SUNAT and returns the CDR.
  • SEE-Empresa: direct integration (very large enterprises) with SUNAT servers.
textsunat-cpe-flow.txt
┌─────────────┐    ┌──────────────────┐    ┌─────────────┐
│ PE supplier │───>│ SEE-SOL portal   │───>│ PE customer │
│ (UBL-PE)    │    │ (SUNAT) or OSE   │    │ (download)  │
│ + ds:Sign.  │    │ certified        │    │             │
└─────────────┘    └────────┬─────────┘    └─────────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ CDR (Constancia  │  ← signed XML SUNAT
                  │ de Recepción)    │     accept/reject
                  └──────────────────┘

SUNAT (or the OSE) returns synchronously the CDR (Constancia de Recepción), a signed XML that records: acceptance (code 0), rejection with reason (code > 0), or non-blocking observations. A rejected CDR invalidates the invoice: correct and resubmit, and if already delivered to the buyer, issue a Nota de Crédito.

Validation

  • SUNAT CPE portal: sunat.gob.pe/cpe — programme and official catalogues.
  • Online CPE lookup: e-consulta.sunat.gob.pe — public validity check.
  • OSE registry — official list of certified Operadores de Servicios Electrónicos (Sovos, Nubefact, Efact…).
  • INDECOPI: indecopi.gob.pe — authority accrediting CAs for XML signatures.

Common pitfalls

  1. Mandatory ISO-8859-1 encoding. SUNAT rejects UBL-PE encoded in UTF-8 (code 2335) — one of the few mandates still in Latin-1 in 2026. Characters ñ, á, í, etc., must be correctly encoded, with no BOM.
  2. SUNAT Catálogo and IGV codes. Every line with IGV must reference a code from Catalogue 07 (1000 = gravado standard 18 %, 9995 = exonerado, etc.). A mismatch between cbc:TaxExemptionReasonCode and the operation type fails the signature on the SUNAT side.
  3. CDR with observations vs CDR with rejection. The CDR may contain non-blocking observations (codes 4xxx) — the invoice is valid but SUNAT flags a point to fix. Rejections (codes 2xxx, 3xxx) invalidate the invoice. Many integrations conflate them and patch unnecessary resubmissions.
  4. Boleta de venta vs Factura. Factura (01) is for B2B transactions with buyer RUC; Boleta (03) for Consumidor Final (DNI or anonymous). Issuing a Factura for a final consumer or a Boleta between businesses are common structural errors.
  5. OSE vs SEE-SOL — architectural choice. SEE-SOL is free but limited in volume and latency. Above a few hundred CPEs/day, an OSE is required. An SME passing the threshold must migrate its flow — anticipate the switch at threshold exit.