Peru OSE Guide: CDR Statuses and Validation

Peru OSE guide searches usually come from one practical question: is this invoice valid yet, and what happens next? In Peru's electronic invoicing model, the issuer sends the invoice XML to an Operador de Servicios Electronicos (OSE) for validation. The OSE returns a Constancia de Recepcion (CDR) showing whether the document is Aceptada, Aceptada con observacion, or Rechazada. Aceptada and Aceptada con observacion keep tax validity. Rechazada means the invoice has no tax validity and must be issued again correctly. After validation, the OSE has one hour to remit the XML and CDR information to SUNAT.

That sequence matters because the CDR is not just a technical acknowledgment. It tells your finance, tax, and systems teams whether the document can move forward, whether an observation queue needs review, or whether the invoice has to be corrected before anyone treats it as valid.

This article approaches Peru electronic invoice validation OSE workflows as an operator would see them: what the OSE checks, what the CDR confirms, how SUNAT fits into the chain, and what action follows each status.

What the OSE Does in Peru's Electronic Invoicing Model

If you are asking what is OSE in Peru, the short answer is that it is an authorized validation layer inside the country's electronic invoicing model. An Operador de Servicios Electronicos receives the XML generated by the issuer, validates it under the applicable rules, and returns the response that tells the issuer whether the document has been Aceptada, Aceptada con observacion, or Rechazada.

Operationally, that makes the OSE more than a background intermediary. It is the point where a document first gets a usable status that accounting, tax, AP, and implementation teams can act on. A status returned by the OSE affects whether the document can keep moving through payment, bookkeeping, customer communication, and exception handling.

This matters for real Peru document flows such as the factura electronica and the boleta de venta electronica. Instead of treating Peru e-invoicing as a single handoff to SUNAT, it is more accurate to think of the process as a validation chain in which the issuer, the OSE, and SUNAT each play a distinct role.

From XML Submission to SUNAT Remittance

The SUNAT OSE validation workflow is easier to manage when you separate it into the actual events teams have to monitor:

1. The issuer generates the XML invoice file. This is the electronic document that will be submitted for validation.
2. The issuer sends the XML to the OSE. At this point the document is in the validation queue, but the status outcome has not been confirmed yet.
3. The OSE validates the XML. This is where the file is reviewed against the required rules and the document receives a result.
4. The OSE issues the CDR. The CDR is the status response the issuer and other stakeholders use to understand whether the invoice is Aceptada, Aceptada con observacion, or Rechazada.
5. The OSE remits the XML and CDR information to SUNAT. This remittance must occur within one hour, which is why timing matters for traceability and downstream reconciliation.

Keeping those steps separate helps prevent a common operational mistake: assuming validation, status communication, and SUNAT remittance are one event. They are related, but they are not identical. If your team is diagnosing delays or mismatches, knowing which step has already occurred is often the difference between a routine follow-up and a real exception.

That distinction matters in day-to-day operations. A returned CDR tells you the validation result, but teams may still need to confirm that the remittance step has been completed in the expected timeframe. Treating every timing mismatch as a rejection problem sends people to the wrong fix.

What Each CDR Status Means in Practice

If you are wondering what CDR means in Peru, it refers to the Constancia de Recepcion, the response that records the validation outcome for the submitted electronic document. The value of the CDR is not the acronym itself. The value is that it tells you what the document's status means in operational terms.

According to SUNAT's OSE validation workflow guidance, Aceptada and Aceptada con observacion retain tax validity, while Rechazada means the electronic invoice has no tax validity and the issuer must issue a corrected new document. The same SUNAT guidance says the OSE has one hour to remit the XML and CDR information to SUNAT.

You can read the three outcomes this way:

• Aceptada: The document passed validation and can proceed as a valid electronic invoice.
• Aceptada con observacion: The document remains tax-valid, but the observation still needs review. Operations teams should not ignore this status just because it is not a rejection.
• Rechazada: The document is not tax-valid. Work should shift immediately to correction and reissuance rather than trying to treat the original invoice as usable.

The practical distinction between Aceptada con observacion and Rechazada is the one most teams need to get right. An observed document may still move forward with follow-up. A rejected document cannot be treated as valid and has to be fixed at the source.

---

What to Do After Observation or Rejection

An Aceptada con observacion result and a Rechazada result do not trigger the same response.

For Aceptada, the usual next move is straightforward: retain the CDR with the document record, reconcile the invoice against your submission log, and let downstream processing continue on the basis that the document is valid.

For Aceptada con observacion, the document still retains tax validity, so your next step is usually controlled review rather than full reissuance. Confirm what the observation relates to, log it in the team's exception process, and decide whether any source-data correction, communication, or follow-up is needed to prevent the same issue from recurring.

For Rechazada, the response is more direct. If you need to know how to fix a rejected Peru electronic invoice, work backward from the validation error, correct the source data or the generated XML, then issue the corrected new document through the normal workflow. Do not keep circulating the rejected invoice as if it were valid, because that status means it has no tax validity.

Teams may also encounter terminology such as Comunicacion de Inconsistencia in broader exception handling, so it helps to align your ERP, middleware, and support workflows with the same vocabulary used in Peru's electronic invoicing environment. If the rejected or observed document also affects withholding or special invoice treatment, related rules such as Peru detraccion invoice rules can become part of the downstream review.

Who Can Check Status and What Teams Should Monitor

Status visibility is not limited to the issuer alone. In the OSE workflow, the status can be consulted by the issuer and by other parties identified in SUNAT's model, including buyers, recipients, senders, and transporters. In practice, teams check that status through the consultation services tied to the OSE and SUNAT electronic invoicing workflow, not just in the ERP screen that created the document. Those consultation points are where you confirm where a document stands after submission. When the same transaction also depends on transport compliance, it helps to separate invoice validation from Peru GRE remitente and transportista shipment rules so teams do not treat the freight document as part of the CDR status itself.

Consultation helps answer three questions: was the document Aceptada, was it Aceptada con observacion, or was it Rechazada? It also helps teams confirm whether a document has progressed through the expected validation path and whether a follow-up is needed before the invoice moves into payment, bookkeeping, or customer-facing communication.

The strongest operational setup is to connect status checks to exception queues, reconciliation, and document follow-up rather than relying on ad hoc email checks. If your Peru process also feeds reporting and record-management work, your Peru SIRE filing workflow becomes easier to manage when accepted, observed, and rejected documents are separated before downstream compliance tasks begin.