Chile Factura de Compra Electronica: 2026 Guide

Chile factura de compra electronica is a buyer-issued Documento Tributario Electronico (DTE) used when the purchaser must issue the tax document in place of the seller, commonly in cambio de sujeto workflows. That changes the finance team's job immediately. Instead of receiving a normal supplier invoice and checking it after the fact, the buyer becomes responsible for issuing, validating, and retaining the purchase document itself.

For AP and accounting teams, the practical questions start at the source: is the buyer authorized to issue it, is the seller's RUT correct, do any withholding details need to appear, and has the document gone through the Servicio de Impuestos Internos (SII) process correctly? Those checks matter because the document is not just proof that a purchase happened. It is also the formal tax document that supports how the transaction is recorded and reviewed.

This is why factura de compra electronica Chile should not be treated as just another name for self-billing. A standard supplier invoice is created by the seller and then reviewed by the buyer. A Chilean Factura de Compra Electronica is created on the buyer side in defined scenarios, which moves the control burden to the purchaser and ties the workflow to Chile's DTE framework. If your team handles cross-border AP, that distinction is the difference between a routine invoice check and a document issuance obligation.

The most useful way to understand the document is as a buyer-side compliance workflow. You need to know when the buyer must issue it, who is allowed to do that through SII, what field-level data must appear, how issuance works in practice, and what should be validated before anything is posted to the ledger or retained in the purchase file.

When the Buyer Must Issue It, and Who Is Allowed to Do So

The buyer issues this document when the transaction falls into a regime where the purchaser, not the seller, must create the tax document. In Chile, that often comes up in cambio de sujeto situations, where the usual invoicing or withholding responsibility shifts away from the seller. The important operational point is that not every purchase qualifies. Teams should first confirm whether the transaction actually belongs to a buyer-issued regime before treating it as a Factura de Compra Electronica.

That is where authorization matters. A company cannot assume that a purchase invoice can be buyer-issued just because a supplier is informal, because the supplier did not provide an invoice promptly, or because self-billing would be convenient. The Chile purchase invoice withholding workflow depends on whether the relevant legal scenario applies and whether the buyer is recognized to operate within it. In practice, the entity often needs to be acting as an authorized retaining agent when withholding obligations are part of the transaction.

Withholding is a useful signal, but it is not the whole test. Teams still need to confirm that the transaction fits the correct Chilean regime and that the issuing entity is the party allowed to create the document through SII.

This is also why finance teams should separate two questions that are often blurred together:

1. Does the transaction fall within a regime that requires or allows buyer-side issuance?
2. Is our entity authorized to issue and retain the document through SII for that scenario?

If either answer is unclear, the safest move is to pause the issuance decision and confirm the Chile-specific rules first. A buyer-issued document created without the right basis creates more risk, not less. The core issue is not whether your AP team can generate a PDF or enter a record in the portal. It is whether the buyer is the correct tax-document issuer for that purchase under the applicable cambio de sujeto and VAT withholding framework.

Required Fields, Codes, and Withholding Data

Once the document is required, the next question is what must actually appear on it. This is where many summaries become too abstract. For AP and accounting work, the real issue is whether the document contains the data needed for tax treatment, review, and downstream posting.

At a minimum, teams should expect to validate:

• the identity of the seller or service provider
• the seller's RUT
• buyer identification
• the authorized folio information
• the electronic signature elements used in the DTE process
• item or service detail that supports the transaction
• any references that connect the document to related records

The withholding fields become even more important when the issuer is an authorized retaining agent. In SII's current guide to issuing a factura de compra electronica, the buyer-side workflow requires the issuer to select the product or activity that supports the VAT change-of-subject treatment, auto-load key counterparty data from the seller's RUT, and review calculated net amount, VAT, withheld VAT, and total values before validation. Those are not decorative fields. They are the data that tells reviewers how the transaction was classified and how the withholding logic was applied.

It also helps to read these requirements as control points rather than as a static form. Folio authorization and the digital signature tell you the document belongs inside Chile's DTE system. The seller identity and line-level detail tell you whether the commercial event is traceable. The retention code and withholding values tell you whether the tax treatment is internally consistent. If any of those elements are incomplete, the document may still look finished on screen while remaining risky to accept or post.

Where the transaction relies on supporting references, such as a related dispatch guide or linked commercial document, teams should review those references with the same care as the core fields. In a buyer-issued invoice SII workflow, missing context often creates the reconciliation problem later, not during issuance.

---

How the SII Issuance Workflow Works in Practice

If you are asking how to issue factura de compra electronica Chile in real life, the useful answer is a workflow, not a list of portal buttons. The SII screens matter, but the quality of the result depends on what your team confirms before and after the document is created.

The process usually follows this order:

1. Confirm the legal scenario first. Verify that the transaction belongs in a buyer-issued regime and that the issuer has the right authorization for that case.
2. Prepare the document data before opening the issuance flow. That includes seller details, the seller's RUT, line descriptions, prices or quantities, any required withholding treatment, and any reference information the document should carry.
3. Generate and review the draft carefully. Check the folio, totals, retention fields, and references before the document is finalized.
4. Apply the digital signature and submit the DTE. Because this is a DTE, the issuance event is tied to formal electronic generation and transmission rather than to a standalone spreadsheet or PDF.
5. Retain the output and delivery evidence. Teams should keep the issued record, confirm submission status, and preserve the supplier copy or related evidence needed for later review.

That sequence explains why a narrow click-by-click tutorial is not enough. The transaction can fail operationally even when the portal steps were followed if the buyer used the wrong scenario, entered the wrong retention treatment, or missed a required reference. In practice, the best control is to treat the issuance screen as the final execution point, not as the place where the business logic is figured out for the first time.

After issuance, finance teams should confirm that the document status, retained support, and downstream recording all line up. If the document feeds a purchase register or another tax control record, the issuance step and the accounting step need to agree on the same identifiers and withholding outcome. That is the operational difference between "issued" and "ready to rely on."

AP Validation Checklist Before You Book the Document

For most teams, the real risk is not understanding the definition. It is posting a buyer-issued document that is incomplete, misclassified, or poorly supported. A practical checklist reduces that risk.

Before you accept or book the document, confirm the following:

• Issuer basis: The transaction really belongs in a buyer-issued regime, and the issuing entity is authorized for that scenario.
• Seller identity: The seller name and RUT match the commercial counterparty and supporting records.
• Field completeness: Mandatory identifiers, folio data, line details, references, and signature-related information are present.
• Withholding logic: The retention code, rate, VAT withheld, and VAT not withheld are internally consistent with the transaction.
• Submission evidence: The DTE has gone through the expected issuance and submission steps, with evidence your team can retain.
• Recordkeeping: The supplier copy, related references, and posting trail are stored so the transaction can be reviewed later.

The most common errors sit in the details. A missing retention code, a seller RUT copied from the wrong source, or a reference field that does not line up with the underlying purchase can all create trouble once the document reaches reconciliation or audit review. That is why Chile buyer-issued DTE guide content is most valuable when it turns the rule set into review actions rather than repeating a definition.

If your team handles multiple Latin American document regimes, it can help to compare this control logic with a Latin American buyer-issued support document for non-invoicing suppliers. The documents are not interchangeable, but the comparison helps clarify why buyer-side issuance requires stronger validation than ordinary supplier invoice intake.

A strong review file should let another person reconstruct the decision later without guessing. That usually means keeping the commercial support, the issued DTE record, the submission result, the supplier copy, and enough explanation to show why the withholding treatment and issuer basis were accepted.

A useful AP habit is to separate issuance success from posting readiness. A document may exist and still fail your internal standard if the withholding treatment is unclear, the support trail is incomplete, or the purchase register outcome cannot be reconciled cleanly later. For supplier-issued DTEs, Chile's acuse de recibo and reclamo workflow adds a separate receipt-and-acceptance control layer that teams should not confuse with buyer-side issuance.

---

How It Differs From Other Buyer-Issued Invoice Models

The cleanest way to avoid mistakes is to stop calling every buyer-created document "self-billing" and move back to the specific Chilean framework. An ordinary supplier invoice starts with the seller as issuer, and the buyer's job is to review, code, and post it. A Factura de Compra Electronica changes that sequence. The buyer becomes the issuer inside the DTE system, and that means the buyer also carries more responsibility for authorization, field accuracy, withholding treatment, and submission evidence.

Cross-jurisdiction comparisons can still help, as long as they are used carefully. You may already know another buyer-issued invoice model through Australia's RCTI rules or how self-billing agreements work under UK VAT rules. Those models are useful reference points because they also shift part of the invoicing burden to the buyer. Kenya's buyer-initiated invoicing rules for small-trader procurement provide another useful contrast because the buyer-side document is tied to a turnover threshold and eCitizen consent rather than Chile's cambio de sujeto framework, while Albania's farmer self-invoice requirements show a buyer-issued agricultural model built around compensation and payment-limit controls. But they do not replace Chile's own rules on cambio de sujeto, DTE issuance, retaining-agent status, and withholding data.

That is the practical takeaway. When factura de compra electronica Chile appears in a workflow, treat it as a Chile-specific buyer-issued tax document, not as a generic shortcut for missing supplier invoices. First confirm the legal scenario and the authorized issuer. Then validate the field-level content, withholding treatment, and SII submission trail before the document is booked or retained. Teams that follow that order are much less likely to confuse a formally issued document with a fully reliable one.