Peru guia de remision electronica requirements start with one operational rule: when goods move in Peru, the trip needs electronic transport support documents that identify who is responsible for the shipment and what role each party plays. In plain English, the guia de remision electronica, or GRE, is the electronic record that supports the transport of goods. The three documents that matter most are GRE-Remitente, GRE-Transportista, and GRE por Eventos. The shipper issues GRE-Remitente, the carrier issues GRE-Transportista in the transport workflow where it applies, and GRE por Eventos is used when a non-imputable disruption forces a transshipment or the journey has to restart. If the recipient later finds a mismatch, SUNAT allows a no conformidad report through the seventh calendar day of the following month.
That sounds straightforward until you try to apply it to a live dispatch. The official SUNAT material is accurate, but it is spread across landing pages, FAQs, and update notices. One page explains the document family, another clarifies event handling, and another answers recipient discrepancy questions. What most English-speaking operators need is the workflow brought back together: which document applies, who issues it, and what changes if the shipment or the recipient's findings do not match the original plan. That is what turns the SUNAT shipment document rules into something a dispatch team can actually use.
It also helps to treat GRE as Peru-specific transport support, not as a generic delivery note. A GRE can become part of your dispatch evidence and later support the teams checking whether an invoice, goods receipt, and shipment trail tell the same story. That is why the issuer logic matters. If the wrong party issues the wrong document, or if a disruption is handled informally instead of through the right GRE path, the problem does not stay in logistics. It can follow the shipment into document review, discrepancy handling, and audit preparation.
One date point needs to be handled carefully. SUNAT announced temporary non-sanction treatment on January 2, 2025, with relief running through June 30, 2025 for certain situations where GRE could not yet be used. That was a time-bound enforcement measure, not a permanent exemption. As of March 12, 2026, it should be read as historical context rather than current relief from the core GRE obligation. The practical sequence for the rest of this guide is the same one most teams use in real life: confirm the shipper document, confirm whether the carrier also needs its own GRE, document any disruption, and then handle any recipient mismatch within the allowed window.
When GRE-Remitente is the document your business must issue
GRE-Remitente is the shipper's document. If your business is dispatching goods and the shipment falls under the remitente's responsibility, this is the GRE that anchors the movement. The practical question is not just "Are goods moving?" but who is responsible for issuing the dispatch support in this specific transport setup. When that answer is the shipper, GRE-Remitente is the controlling document.
For businesses using private transport, the Peru-specific detail matters: the document is issued per recipient, per destination point, and per vehicle. That means a shipment plan that looks like one job internally may still need separate document treatment when different recipients, delivery points, or vehicles are involved. Teams that treat the route as one broad dispatch instead of checking those three variables can end up with paperwork that does not match the real movement on the road.
Before issuing GRE-Remitente, confirm the operating facts that determine whether the document aligns with the shipment:
- who is dispatching the goods
- who the recipient is
- the point of departure
- the destination point
- the vehicle assigned to the movement
- whether a third-party carrier is also entering the workflow
That review is what makes the remitente document useful later. It turns the GRE into a record of the actual dispatch setup rather than a form completed after the fact to satisfy a control step.
Businesses usually generate the document through SUNAT's electronic issuance environment, including workflows such as SEE-SOL where applicable, but the compliance risk is rarely the tool itself. The real risk is issuing GRE-Remitente against the wrong shipment facts or assuming it covers a broader movement than it actually does. Once those basics are correct, you can evaluate whether the transport arrangement also requires a carrier-side GRE.
When GRE-Transportista is also required, and when one can cover several remitente guides
GRE-Transportista deals with the carrier's side of the journey. It does not replace GRE-Remitente. Instead, it documents the part of the workflow where the transportista has its own issuance responsibility. That is why the most useful comparison is not "shipper document versus carrier document" in the abstract. It is which party is taking responsibility for which part of the transport workflow, and what supporting document that responsibility requires.
In practice, the transportista usually issues its GRE after receiving the remitente's GRE, unless the remitente is not obliged to issue one. If you are trying to decide when to use GRE remitente vs GRE transportista, start by identifying the shipper's obligation first and then confirm whether the carrier also has an issuance duty in that transport setup. That sequencing matters because the carrier's document is not meant to float free of the shipment facts already established by the shipper. If a team requests carrier paperwork without first confirming the remitente document position, confusion spreads fast: the carrier may document the route one way while the shipper's records say something else.
SUNAT's FAQ also adds an important efficiency rule. One GRE-Transportista can support multiple GRE-Remitente documents when those related guides share the same destinatario, point of departure, and point of arrival. That is not a blanket permission to roll several deliveries into one carrier record. It works only when the underlying shipment characteristics line up on those shared conditions. If they do not, the safer assumption is that the carrier documentation also needs to stay separate.
This is one reason Peru's regime deserves its own guide instead of being treated like a generic waybill topic. Even compared with other electronic transport-document models, such as Mexico's Carta Porte electronic waybill rules, Peru's issuer logic is highly specific about how remitente and transportista responsibilities connect. For anyone reviewing shipment documentation after the goods move, that relationship is the difference between a clean evidence trail and a file full of partially matching records.
What GRE por Eventos covers when a shipment is disrupted or restarted
GRE por Eventos is the document Peru uses when the original shipment cannot continue as planned because of a non-imputable event and the journey has to be continued in a different way. In operational terms, think of a disruption that forces a transshipment or a restart of the trip after the original GRE has already been issued. The key point is that the shipment already exists in the document trail. GRE por Eventos does not replace that history. It complements it.
That distinction matters because teams sometimes treat disruptions as if they can be solved with an informal note, an email thread, or a revised internal dispatch record. For ordinary communication, that may help everyone understand what happened. For document control, it is not enough. If the route is interrupted and the goods need to move forward under changed conditions, the event has to be reflected in the GRE framework rather than left outside it.
The practical question is when the threshold has been crossed. A minor operational inconvenience does not automatically mean a new event document. But once a non-imputable disruption forces the goods to be moved through a different transport path, handed over through transshipment, or restarted after the original journey breaks, the shipment has moved into GRE por Eventos territory. The event document exists because the original transport support is no longer a complete account of how the goods actually continued.
This is where shipment exception handling and dispatch compliance meet. Operations teams need the shipment to keep moving. Finance and control teams need the record to explain why the movement changed. GRE por Eventos is the bridge between those two needs. It keeps the document trail aligned with the real-world interruption instead of leaving downstream reviewers to guess why the original dispatch record no longer matches the journey that actually happened.
How no conformidad works when the recipient finds a mismatch
No conformidad is the recipient's formal route for saying the shipment received does not match what the GRE says should have arrived. That makes it more than a transport-side correction. It is the point where the person receiving the goods can put a documented mismatch into the record instead of leaving the discrepancy as an internal complaint or a disputed phone call.
The useful way to understand the rule is to separate total and partial mismatch. A total mismatch means the goods received do not correspond to the GRE in a fundamental way. A partial mismatch means part of the shipment or part of the recorded information does not line up, but the issue is narrower. The categories matter because they help the recipient describe the problem in a structured way instead of using vague language such as "the load was wrong." If your team can identify what failed to match, it becomes much easier to investigate the exception and decide what supporting records are needed next.
Timing is just as important as classification. SUNAT states that a recipient can report no conformidad for a GRE through the seventh calendar day of the month following issuance, after which the GRE data is presumed accepted, as explained in SUNAT's GRE FAQ on no conformidad timing. That deadline gives recipients time to review the shipment, but it also means unresolved discrepancies cannot sit indefinitely in an inbox while invoice review continues elsewhere.
For finance and compliance teams, this matters because no conformidad is part of document exception handling. If the shipment record is disputed, invoice support becomes weaker until the mismatch is understood. Was the wrong quantity delivered? Did the route or destination not match the GRE? Did the carrier's records diverge from the shipper's? No conformidad gives the recipient a formal basis for raising that issue while the evidence is still fresh and the reporting window is still open.
Why GRE accuracy matters for invoice support and audit-ready records
The value of accurate GRE records does not end when the truck arrives. In many businesses, the shipment file becomes part of the evidence used to support invoice review, goods-received checks, and later audit questions. If the issuer logic was wrong, the event trail was not updated, or a recipient mismatch was never resolved, the transport problem turns into a finance-control problem.
That is why dispatch evidence needs to be read alongside the rest of the Peru compliance record. A business validating supporting tax and invoice documents may also care how its wider Peru OSE and CDR validation workflow fits into document review, and how related obligations flow into the broader Peru SIRE, RVIE, and RCE workflow. GRE does not do the same job as those records, but it often supports the same downstream question: does the documentary trail match what the business says happened?
From a control perspective, the most useful checklist is short:
- confirm whether the remitente is the correct issuer
- confirm whether the transport arrangement also requires GRE-Transportista
- document any non-imputable disruption through GRE por Eventos when the journey changes
- investigate and resolve no conformidad issues within the reporting window
- keep the shipment record aligned with invoice and receiving evidence
That checklist is what turns Peru's GRE rules into something operational. The point is not to memorize SUNAT terminology for its own sake. The point is to maintain a transport record that still makes sense when a finance reviewer, internal controller, or auditor reconstructs the shipment later. When the GRE trail is accurate, it supports invoice evidence and exception resolution. When it is patchy or inconsistent, every downstream review takes longer.
About the author
David Harding
Founder, Invoice Data Extraction
David Harding is the founder of Invoice Data Extraction and a software developer with experience building finance-related systems. He oversees the product and the site's editorial process, with a focus on practical invoice workflows, document automation, and software-specific processing guidance.
Profile
View author pageEditorial process
This page is reviewed as part of Invoice Data Extraction's editorial process.
If this page discusses tax, legal, or regulatory requirements, treat it as general information only and confirm current requirements with official guidance before acting. The updated date shown above is the latest editorial review date for this page.
Related Articles
Explore adjacent guides and reference articles on this topic.
Peru Factura con Detraccion: Invoice Rules Guide
Peru factura con detraccion rules: when detraccion applies, the S/700 threshold, operation types 1001 to 1004, transport cases, and invoice checks.
Peru OSE Guide: CDR Statuses and Validation
Peru OSE guide to CDR statuses, tax validity, rejected invoices, and the one-hour SUNAT remittance rule.
Peru SIRE Guide: RVIE, RCE, and IGV Workflow
Peru SIRE guide to RVIE, RCE, rollout dates, IGV return proposals, and SUNAT portal, desktop, and API access.
Invoice Data Extraction
Extract data from invoices and financial documents to structured spreadsheets. 50 free pages every month — no credit card required.