Peru Factura con Detraccion: Invoice Rules Guide

If you need a fast answer, a Peru factura con detraccion applies when the invoice total is more than S/700.00, every good or service on that invoice is subject to the SPOT system, and the document carries the correct detraccion operation type. If even one line is outside the detraccion regime, the invoice should stay in the normal flow rather than being issued as a mixed detraccion document.

That is the operational starting point behind most Peru detracciones invoice requirements. The question is not "does this customer or supplier ever handle detraccion?" It is "does this specific invoice meet the full set of conditions?" According to SUNAT's factura con detraccion guidance, a factura con detraccion issued through its portal must include detraccion information, only applies when all goods or services on the invoice are subject to detraccion, and requires the invoice total to be greater than S/700.00.

For finance teams, that turns the rule into a simple first-pass test:

1. Is the total above S/700.00?
2. Are all invoiced items within the SPOT regime?
3. Does the invoice carry the correct detraccion operation type, from the applicable 1001 to 1004 set?
4. Has the required detraccion information been captured in the electronic invoice record?

If the answer to any of those questions is no, stop and recheck the classification before the invoice is issued, paid, or booked. That workflow framing matters because many short explainers jump straight to the code list without helping you decide when detraccion applies on a Peru invoice in the first place. The real compliance risk is often a bad classification decision made at the top of the process, then copied into the invoice, XML, AP review, and accounting entry downstream.

Apply the S/700 Threshold Before You Check Anything Else

The S/700 threshold is the first gate, not the only gate. In practice, teams should test the total invoice amount before they spend time reviewing codes or XML details. If the amount does not exceed S/700.00, the invoice does not belong in the Peru SPOT invoice flow described on SUNAT's detraccion page.

Once the amount clears that threshold, the next question is whether the invoice is entirely made up of goods or services subject to detraccion. This is where many errors start. A Peru electronic invoice detraccion is not meant for a partly subject invoice. If a supplier bills one line that falls inside SPOT and another line that does not, the safe reading of the rule is that the invoice should not be issued as factura con detraccion just because one component qualifies.

That subject-only rule is more important than it looks because it affects tax support and bookkeeping. A buyer may be expecting an invoice that can sustain IGV-related treatment and downstream review, but the document format still has to match the operation actually billed. When the structure is wrong, AP teams end up checking the same issue twice: once during payment review and again during ledger cleanup.

Use a practical threshold test like this:

• Confirm the invoice total is more than S/700.00.
• Check whether every billed line falls under the detraccion regime.
• If the invoice is mixed, do not force the entire document into the detraccion format.
• Escalate the case before issuance or payment approval if the commercial transaction may need separate billing.

For example, imagine a service provider issues one invoice for a subject transport service plus a non-subject administrative charge. The amount may be above S/700.00, but the mixed composition still breaks the factura con detraccion rule. The compliance decision has to happen before the invoice moves into approval or posting, not after the payment file is already prepared.

---

What Information Must Appear on the Invoice and XML

Once a transaction qualifies, the next job is data completeness. A factura con detraccion is not only a visual label on a PDF. The invoice record has to carry the detraccion information that SUNAT expects, and that means the electronic record matters just as much as the rendered document your AP team reads on screen.

At a practical level, reviewers should confirm these field groups are present and consistent:

• The detraccion information required for the qualifying operation
• The correct operation type for the transaction
• Supplier and buyer identifiers, including the relevant RUC values
• The invoice data submitted in the electronic record, including the XML fields used to represent the transaction

This is where workflow discipline matters. If the PDF view says one thing but the electronic invoice XML fields say another, the problem does not stay isolated to issuance. It flows into reporting, audits, and system-to-system reconciliation. Teams that need a clearer view of how validation outcomes affect tax validity can use this Peru OSE and CDR status guide before deciding whether the invoice should move forward. That is also why Peru SIRE register workflows work better when teams validate the structured invoice record early rather than treating the XML as a back-office detail.

A short review list helps:

1. Confirm the invoice was classified correctly as subject to detraccion.
2. Confirm the operation type on the record matches the transaction.
3. Confirm the RUC details and invoice identifiers are complete.
4. Confirm the detraccion information shown to users matches the structured electronic data.

If your team also works on other Latin American e-invoicing formats, the same discipline appears in Argentina factura electronica requirements and CAE workflow: the visible invoice and the electronic submission have to stay aligned, because later tax and accounting steps depend on the structured record being right the first time.

What Operation Types 1001 to 1004 Actually Tell You

The 1001 to 1004 values are not decorative labels. They tell SUNAT which detraccion scenario the invoice belongs to, so they function as a classification field as much as a code list. If the wrong code is used, a team can pass the threshold test and still end up with a document that is classified incorrectly.

The official code set on the factura con detraccion page is:

Operation type	What it signals operationally
1001	A standard operation subject to detraccion
1002	An operation subject to detraccion involving hydrobiological resources
1003	A detraccion operation for passenger transport services
1004	A detraccion operation for cargo transport services

The key control is not memorizing the list. It is matching the code to the real transaction. If your billing template keeps defaulting to 1001, that may be fine for many routine cases, but it is not safe to reuse automatically when the operation involves passenger transport, cargo transport, or a more specific category such as hydrobiological resources.

For AP teams, the review question is straightforward: does this code describe the operation I am looking at, or did someone copy it from a prior invoice? For issuers, the same logic applies before the document is sent. The code belongs in the same control set as threshold testing and field completeness, because all three parts work together.

If you compare that with other regional withholding formats, Mexico retenciones CFDI invoice rules show a similar lesson: tax-sensitive invoice fields are not clerical extras, they are classification data that need to match the transaction being reported.

How Transport and Logistics Invoices Fit the Detraccion Rules

Transport cases deserve their own review because they are a recurring source of search demand and a common place for sloppy assumptions. A transport invoice does not bypass the normal detraccion tests. You still need to confirm that the invoice is above S/700.00 and that all billed items on that document fall within the relevant detraccion treatment. What changes is the classification detail, especially when the operation type points to passenger or cargo transport.

That means a Peru transport detraccion invoice should be checked in this order:

1. Confirm the invoice exceeds the threshold.
2. Confirm the invoice is fully made up of subject transport services, not a mixed bundle with unrelated non-subject charges.
3. Confirm the operation type reflects the actual transport category.
4. Confirm the detraccion information is carried through the invoice record.

Consider a freight operator invoicing a cargo movement plus a separate non-subject charge on the same document. Even if the total is above S/700.00, the invoice still fails the subject-only rule if the non-subject element remains on that same record. The team then has to decide whether the transaction needs separate billing or a different document flow.

This is why transport should be treated as a classification issue, not just a tax footnote. The underlying SPOT logic is the same, but transport scenarios add more chances to pick the wrong code or overlook mixed billing. Readers who deal with similar withholding-style invoice checks in other jurisdictions may also find useful parallels in Turkey VAT withholding invoice field requirements, where the document fields and transaction category have to stay aligned.

---

A Finance Team Checklist for Issuing, Paying, or Booking the Invoice

For day-to-day work, the safest approach is to turn the rule set into a short control checklist. Whether you issue invoices, review supplier documents, or book entries into accounting records, the same sequence helps prevent avoidable errors:

1. Threshold check: Is the total more than S/700.00?
2. Subject-only check: Are all goods or services on the invoice subject to detraccion?
3. Operation-type check: Does the code match the actual transaction, including any passenger or cargo transport scenario?
4. Field-completeness check: Does the invoice carry the required detraccion information in the electronic record, not only in the visual document?
5. Identity check: Are the RUC and invoice identifiers complete and internally consistent?
6. Workflow check: Has the document been reviewed before payment approval, ledger posting, and any SIRE-dependent downstream process?

That checklist works for both sides of the workflow. Issuers can use it before sending the invoice. AP and bookkeeping teams can use it before paying or recording it. The benefit is not only compliance accuracy. It also reduces rework, because classification mistakes made at issuance tend to create corrections in review, posting, and audit support later.

If your team is building repeatable controls around this kind of regional invoice logic, it can help to standardize the capture of threshold, code, and special-field data inside broader invoice data extraction workflows for compliance-heavy invoices. The practical aim is consistency, not automation for its own sake: every special invoice field should be visible, reviewable, and preserved in the record your finance team relies on.