Peru SIRE Guide: RVIE, RCE, and IGV Workflow

Peru's SIRE is SUNAT's Sistema Integrado de Registros Electronicos, a system that uses electronic invoices and purchase documents to generate two statutory books: the RVIE sales register and the RCE purchase register. Once those registers are generated, SIRE also feeds SUNAT's proposal for the sales and purchase boxes in the monthly IGV return. For many readers looking for a Peru SIRE guide, that is the core point to understand first: SIRE is not just a label for electronic bookkeeping. It is a workflow that starts with source documents and ends with proposed tax-reporting fields.

The coverage timeline matters because older pages and vendor explainers often mix earlier milestones with the current position. In practical terms, August 2024 matters for taxpayers that were already required to keep these registers, non-PRICO taxpayers were brought into SIRE from January 2025, and PRICO taxpayers were phased in during January 2026 or June 2026 depending on their 2024 net income thresholds. If you are trying to work out who must use SIRE in Peru, you need to read those dates as part of one rollout rather than as separate announcements.

That context also explains the main compliance problem SIRE is designed to solve. Instead of asking businesses to rebuild sales and purchase books manually from scratch every month, SUNAT starts from the electronic evidence already flowing through the tax ecosystem and turns it into proposed registers that taxpayers can review, adjust, and submit. That matters for finance teams because the real work shifts from rekeying data toward validating whether the proposed records reflect the business's actual transactions.

This is why Peru SIRE requirements are best understood as an operating model, not just a legal acronym. If your team issues electronic invoices, receives purchase documents, or manages IGV reporting across Peru entities, the real question is how those records move through the SIRE workflow and where review still sits with you. The rest of this guide focuses on that chain from source data to RVIE, RCE, and IGV reporting.

RVIE and RCE Are Different Registers Inside the Same System

The easiest way to understand RVIE vs RCE in Peru is to treat them as two different statutory outputs built from different transaction streams. RVIE, short for Registro de Ventas e Ingresos Electronico, is the electronic register for sales and income. RCE, or Registro de Compras Electronico, is the electronic register for purchases. They live inside the same SIRE environment, but they do not perform the same job.

RVIE is concerned with the sales side of the ledger: the documents and values that support taxable sales, income reporting, and the sales side of IGV determination. RCE covers the purchase side: supplier documents, acquisition records, and the information that supports the purchase side of tax treatment. Looking at SIRE this way helps because many English summaries mention both acronyms without explaining why the distinction matters in operational terms.

The distinction matters because the source records, review questions, and downstream tax consequences are different. A sales register typically depends on whether outbound documents were issued correctly and recognized in the right period. A purchase register depends on whether inbound supplier documents are complete, valid, and attributed correctly. Both are part of Peru's electronic record-keeping model, but they reflect different evidence chains.

That is also why SIRE should not be confused with a generic scanning tool or a broad e-invoicing concept. If you want a wider frame for how government e-invoicing systems differ from ordinary PDF invoicing, SIRE sits further downstream: it uses structured electronic evidence to populate official registers rather than merely transmitting a commercial invoice. In practice, Peru's electronic sales register and electronic purchase register are the working records that connect day-to-day document activity to later tax reporting.

Once you see RVIE and RCE as paired but separate records, the rest of the workflow becomes easier to follow. SIRE gathers the relevant electronic evidence, proposes the registers, and then leaves the taxpayer with the task of checking whether those proposed records match commercial reality before they are finalized.

Who Must Use SIRE and How the 2024 to 2026 Rollout Works

The rollout is easier to interpret when you stop looking for a single launch date. SIRE came in through phases tied to taxpayer category and prior obligation status, which is why searchers often find several different dates and assume the guidance conflicts.

Here is the practical timeline to keep in mind:

• August 2024: Relevant for taxpayers in regimes such as RER and MYPE Tributario that were already required to keep the relevant electronic registers.
• January 2025: Non-PRICO taxpayers were brought into the SIRE obligation framework.
• January 2026 and June 2026: PRICO taxpayers were phased in depending on 2024 net income thresholds.

That structure matters because Peru SIRE requirements are not determined only by whether your company issues electronic invoices. They depend on how SUNAT classifies the taxpayer and when that taxpayer falls into the rollout schedule. A finance team reading older summaries can easily miss this and assume that SIRE is either universal from one date or still only an early-stage pilot. Neither reading is useful in 2026.

The safer approach is to treat the latest SUNAT CPE guidance as the freshness anchor when different pages use different wording. Some public-facing SUNAT pages and third-party explainers still echo earlier milestone language, while the current official reference material reflects the January 2026 and June 2026 PRICO split. That is the timeline to rely on when you are mapping obligation status internally.

This timeline also often sits alongside other Peru-specific tax workflow questions. For example, teams dealing with Peru detracciones invoice rules that often sit alongside SUNAT-controlled invoice workflows may need to separate those obligations from the SIRE register timeline so they do not blend two different compliance processes into one checklist. SIRE is about the electronic registers and related IGV proposal flow, even though it often appears in the same operational conversations as other SUNAT controls.

---

How SIRE Turns Source Documents Into RVIE, RCE, and Proposed IGV Fields

The most useful way to read SIRE is as a chain of data handling steps. Electronic invoices and purchase documents enter the tax record stream first. SIRE then uses that underlying information to generate proposed RVIE and RCE records. After that, the taxpayer reviews those records, makes any needed adjustments, and only then works with the proposed sales and purchase boxes that flow into the monthly IGV return.

This sequencing explains how SIRE connects to the IGV return. The system is not replacing judgment or filing responsibility. It is organizing the data trail so that the sales side and purchase side of the month can feed a tax return proposal instead of being rebuilt manually in parallel worksheets. As SUNAT's official SIRE overview and rollout guidance explains, SUNAT states that after SIRE generates the RVIE and RCE, the system automatically proposes the sales and purchase boxes for the monthly IGV return. For physical goods movements, teams often also need Peru GRE remitente versus transportista guidance so shipment-control documents do not get mixed up with invoice and register workflows.

For finance teams, the operational point is that SIRE is a proposal-and-adjustment workflow, not a blind auto-filing mechanism. If source data is incomplete, misclassified, duplicated, or recorded in the wrong period, those issues can surface downstream in the proposed registers and then in the IGV proposal. When the uncertainty starts earlier in the issuance chain, a guide to Peru OSE validation and CDR statuses helps teams separate accepted, observed, and rejected documents before those records flow into SIRE. That is why the quality of electronic invoices and purchase records still matters even when the register generation itself is automated.

This is also the clearest way to think about Peru IGV register automation. The automation sits in the structured movement from source documents to proposed statutory records, not in removing taxpayer review. If your team works on invoice data extraction workflows for tax-ready records, SIRE illustrates the same operational point: cleaner, more structured inputs reduce repeated handling later, but the control step still belongs to the business before submission.

If you explain SIRE this way internally, the register acronyms become much less abstract. They are simply the formal containers SUNAT uses to transform transaction evidence into a proposed monthly tax position that your team still has to verify.

Portal, Desktop, and API Access Each Fit a Different Operating Model

SUNAT presents more than one way to access SIRE, and that matters because the right channel depends on how your team works. At a high level, the system is available through portal access, a desktop client, and an API or web API path. Those options do not change the legal function of SIRE, but they do affect how users interact with the register workflow.

The portal is the most straightforward route for teams that need direct, browser-based access to review records, check the status of proposals, and work through the monthly process manually. It suits users who operate inside SUNAT's interface rather than inside a separate internal system.

The desktop application is useful where SUNAT's workflow is supported by local tooling rather than only through the browser. For some teams, especially those that already have fixed operating routines around desktop-based compliance tasks, that can be a more natural fit than relying entirely on the portal.

Peru SIRE API access is the most relevant path for technically minded finance teams and system-connected operating models. The key point is not that every business needs an integration. It is that SIRE can sit inside a more automated environment where data preparation, control checks, or register handling are connected to internal workflows instead of being handled only by manual navigation.

Whichever route a business uses, the underlying logic stays the same. The system still revolves around RVIE and RCE generation, taxpayer review, and the resulting IGV proposal. Access method changes the interaction model, not the responsibility to confirm that the records are accurate before they are submitted.

---

Controls and Common Misunderstandings Before You Submit

The most common misunderstanding is thinking that a generated register no longer needs careful review. SIRE reduces manual reconstruction work, but it does not remove the need to confirm whether the underlying electronic invoices and purchase records are complete, correctly timed, and assigned to the right tax period. A proposed register is still a proposal.

In practice, strong control points usually include four checks. First, confirm obligation status and timing so the team is working from the right rollout window. Second, validate the completeness and quality of the source documents feeding the month. Third, review exceptions or unusual transactions that may not fit the routine pattern. Fourth, assign clear responsibility for approving the proposed RVIE, RCE, and related tax return proposal before submission.

Teams should also be careful with fragmented guidance. English-speaking operators often land on a mix of portal pages, FAQs, and vendor summaries that use different milestone wording. When the dates matter, anchor the interpretation to the latest official reference material and treat older public wording as background only. The same caution applies to downstream record retention and audit support, especially if your broader compliance process also touches invoice retention and digital record-keeping rules across jurisdictions.

If you need a practical starting point, confirm four things in order: whether your taxpayer category is already in scope, whether the source data feeding SIRE is reliable, which access route your team will use, and who signs off on the proposed records before filing. A Peru SIRE guide is only useful if it leaves you with that operational checklist, because the real compliance risk sits in the review process, not in memorizing the acronyms.