SII electronic invoicing 2026 in Chile: May 1 deadline, fines and Odoo

One-minute summary

Fewer than seven days remain before May 1, 2026. If your Chilean company issues the electronic dispatch guide and you do not extend the mandatory fields (full origin and destination, carrier and driver IDs, vehicle plate, nature of the movement), every outbound document becomes grounds for a fine under Art. 97 N° 10 of the Tax Code — from 2 UTM to 40 UTA.

It is not the first 2026 deadline and not the last. On January 1, 2026 the SII already dropped the requirement to print the electronic seal on the DTE representation and switched on fiscal reporting for marketplace platforms. In March, retailers without a printing device became obligated to deliver the electronic boleta to the customer through a digital channel (email, SMS, WhatsApp Business API, or QR code). May closes the dispatch guide cycle. On the SII roadmap for 2027-2028: VAT on cross-border digital services, mandatory XML for Libros, and a DTE 110 cross-check against customs (DGA).

Most Chilean SMBs run on ERP that physically cannot keep up: Defontana 2019, Bsale without the latest modules, custom VB6 setups with a PDF generator from a third-party PSC. If you sit among the 750,000+ VAT taxpayers and your stack does not move with the SII, you have two choices: patch the system and pay a consultant for each new wave, or migrate to a platform with a maintained l10n_cl localization that the community refreshes 2-4 weeks after each SII release.

This article is the territory map: what changes, what does not, how fines convert to real money, and how to configure Odoo — or any other system — so compliance becomes automatic rather than a quarterly panic project. The official SII documentation remains the source of truth, but day-to-day operation needs a layer of judgment on top.

• Three 2026 waves: January 1 (marketplace fiscal reporting + end of printed seal), March (electronic boleta through digital channel to the customer), May 1 (dispatch guide with extended data).
• Art. 97 N° 10 fines: minimum 2 UTM, maximum 40 UTA (~USD 33,000 at May 2026 FX), plus business closure of up to 20 days and risk of CAF revocation.
• Compliance tech stack: digital certificate (.pfx from an accredited PSC), CAF folios per DTE type, XSD validation, mTLS to SII endpoints, and a controlled Accepted / Accepted with reservations / Rejected workflow.
• Odoo: l10n_cl (Community or Enterprise) + l10n_cl_edi from OCA cover the 12 standard DTE types (33, 34, 39, 41, 43, 46, 52, 56, 61, 110, 111, 112).
• Out of scope for standard: marketplace reconciliation, POS contingency, electronic assignment for factoring, and DTE 110 integration with customs DUS. Each one needs custom work.

The three SII waves in 2026

Chile launched electronic invoicing earlier than any other LATAM country — the pilot ran in 2003 (Resolución Exenta N° 45/2003) and mandatory use for large taxpayers landed in 2014 (Law 20.727). By 2017, every DTE type was mandatory for VAT taxpayers: Electronic Invoice 33, Non-VAT Invoice 34, Credit Note 61, Debit Note 56, Dispatch Guide 52, Export Invoice 110. Electronic boleta 39 closed the last gap in 2020-2021 (Law 21.210, Tax Modernization), mandatory from March 1, 2021 for large taxpayers and from January 1, 2022 for SMBs.

What changes in 2026 is not the introduction of new documents. It is the closing of operational gaps in the existing system.

#1. January 1, 2026 — Marketplaces and the end of the seal

The requirement to print the electronic seal on the DTE representation is gone. In parallel, fiscal reporting kicked in for marketplace platforms (Mercado Libre, Cornershop, PedidosYa, Amazon, Falabella Marketplace): they must report third-party sales channeled through their platform to the SII. It is part of Law 21.713 «Cumplimiento Tributario» from October 2024, aimed at closing the VAT gap in digital commerce.

#2. March 2026 — Digital boleta to the customer

Retailers without a printing device (small retail, in-home services, mobile commerce, fairs, ferias) must now deliver the electronic boleta to the customer through a digital channel: email, SMS, WhatsApp Business API, or a QR code that leads to the document representation. The detail lives in Resolución Exenta SII N° 53, which regulates new in-person commerce obligations. The measure closes the B2C digitization cycle: the SII receives the boleta when it is issued, the customer receives it at the moment of purchase, and the paper receipt becomes optional.

#3. May 1, 2026 — Dispatch guide with extended data

Extended fields on the electronic dispatch guide, set by Resolución SII N° 207/2026. New mandatory fields:

• origen in full — complete address, not just comuna.
• destino in full.
• carrier identification — RUT, name, phone.
• driver identification — RUT, name, license number.
• vehicle plate.
• nature of the movement — sale, internal transfer, return, export, import, or other.

The change targets the traceability gaps where, by SII estimates, a meaningful chunk of VAT was leaking. The extended data enables cross-checks against Carabineros (plate enforcement) and Transportes (freight regulation).

#4. What comes after May

Three more items are on the SII table: VAT on cross-border digital services (Netflix, Spotify, Steam — already partially covered through withholding under Law 21.210), migration of Libros Compras y Ventas to mandatory XML instead of the current CSV, and integration of DTE 110/111/112 with DGA so that export operations cross-check against the customs declarations (DUS) automatically.

If your SMB runs on a modern ERP with maintained l10n_cl, these are module updates plus reconfiguration. If you run legacy stack, it is migration. There is no acceptable third lane.

The 4 layers of DTE compliance

For any DTE to be accepted by the SII you have to pass four layers. Fail one and the document gets rejected and you enter the fine zone. This is the minimum base on which any Odoo implementation in Chile — or any other platform on the local market — is later built.

#1. Identity: digital certificate

No certificate, no right to issue DTE. The SII accepts certificates from accredited PSCs (Prestadores de Servicios de Certificación): E-Sign (formerly Acepta.com Certs), E-Certchile (Santiago Chamber of Commerce), Certinet, Toc.cl, IDOK, Acepta, Camerfirma Chile, and BIRC.

The certificate is issued to the Legal Representative with an active mandate; the format is PKCS#12 (.pfx) with a mandatory password. Validity is 1-3 years. Cost runs USD 40-150 a year.

One certificate equals one issuer RUT. A holding with three RUTs needs three separate certificates.

#2. Folios: CAF

The CAF (Código de Autorización de Folios) is an XML file digitally signed by the SII and delivered in batches. Each folio is used once. When the batch runs out, issuance stops with folio no autorizado.

The flow: log in at sii.cl, Servicios online → Factura electrónica → Solicitar folios → choose document type → set quantity → download the .xml. The CAF is loaded into the system as a cryptographic resource — Odoo, Bsale, Defontana, and Toteat all support it. The classic trap is the numeric sequence: if your CAF covers folios 1001-2000 but Odoo already burned through 1500 without syncing, the next batch (2001-3000) collides because folio 1500 is already in the SII.

#3. DTE structure: XML and XSD validation

The DTE is an XML described in the SII XSD schemas (current version: XSD 1.0). Core blocks:

• Encabezado — issuer RUT, receiver RUT, document type, folio, date, total.
• Detalle — line items with name, quantity, price, line-level VAT.
• DscRcgGlobal (optional) — document-level discounts and surcharges.
• Referencia — for credit and debit notes, link to the original DTE.
• TmstFirma — signing timestamp.
• Signature — XML Digital Signature, RSA-SHA1 or SHA256.

The XML is sent to the SII via dedicated endpoints:

• Certification: https://maullin.sii.cl/cgi_dte/UPL/DTEUpload
• Production: https://palena.sii.cl/cgi_dte/UPL/DTEUpload

The SII returns a TrackID. Between 1 and 15 minutes later the status lands: Accepted, Accepted with reservations, or Rejected. Only Accepted entitles the receiver to VAT credit.

#4. Delivery to the receiver

Once Accepted, the SII does not deliver the DTE to the buyer. That is on the issuer. The standard B2B channel is still email with the XML attached and a PDF representation. For B2C boletas, digital channels (email, SMS, WhatsApp, QR) became mandatory on March 1, 2026.

#5. Setup in Odoo: l10n_cl + l10n_cl_edi

In Odoo Community or Enterprise, the l10n_cl module installs as a fiscal localization (shipped by default since version 14+). Add from the OCA l10n-chile repo:

• l10n_cl_edi — core EDI logic and SII delivery.
• l10n_cl_edi_boleta — electronic boleta 39.
• l10n_cl_edi_exports — export DTEs (110, 111, 112).
• l10n_cl_edi_stock — dispatch guide 52.

Setup steps:

1. Settings → Companies → SII configuration: upload the .pfx, enter the password, pick the SII environment (Certification for testing, Production for live), and choose the taxpayer type.
2. Load CAF: each document type needs its own; via Accounting → Configuration → CAF.
3. Align numbering: Odoo journal sequences must match CAF ranges precisely — no overlap, no gaps.
4. Test in Certification environment: issue at least 3 DTEs of each type and wait for Accepted.
5. Switch to Production: change environment and load the production CAF.
6. Async status cron: every 10 minutes, check pending DTEs and refresh status from the SII.
7. WhatsApp and email integration for B2C boleta: Twilio, MessageBird, 360Dialog, or the native mail module with auto-attached PDF.

Odoo l10n_cl: where it works and where it does not

Standard l10n_cl covers the basic SMB scenarios. Not everything.

Works: 1st-category SMB with local B2B

If the company sells goods or services to another Chilean RUT, issues Electronic Invoice 33 (Afecta) or 34 (No Afecta), plus occasional Credit Note 61, Debit Note 56, and Dispatch Guide 52 — standard l10n_cl + l10n_cl_edi is enough. Setup: 1 day. Certification testing: 2-3 days. Production go-live: 1 day.

Works with configuration: retail with boleta 39

Electronic boleta 39 runs on its own CAF and its own flow. If you run a POS (Odoo POS, Toteat, Bsale), the POS journal has to be bound to the boleta sequence and issuance has to be real-time, not batch. After March 1, 2026, digital delivery is mandatory. In Odoo, that is solved with the pos_send_receipt_* modules or with 200-300 lines of custom code.

Needs customization: marketplace and B2B2C

If you sell through Mercado Libre, Cornershop, PedidosYa, Amazon, or Falabella Marketplace, each platform has its own DTE issuance mechanism on behalf of the seller. From January 2026, those marketplaces must also submit fiscal reporting on your activity. If you issue DTEs directly from Odoo, you need reconciliation between the marketplace's outbound DTEs and the SII reporting — otherwise you get duplications and SII corrections. Not covered by standard — needs a custom connector.

Needs customization: export DTEs (110, 111, 112)

Export Invoice 110 plus Credit Note 111 and Debit Note 112 are supported by l10n_cl_edi_exports. But proper customs integration (DUS — Documento Único de Salida) is required. If you export ag, mining, or wine, you must integrate with the ADUANA system because DTE 110 references the DUS. Not covered by standard.

Does not work: real-time fallback during SII downtime

The SII has periodic downtime (maintenance, overload). Standard l10n_cl_edi marks the DTE as Pending and retries via cron. But if your retail POS runs thousands of boletas a day, downtime over 30 minutes means lost sales (if issuance is online) or batch issuance with delay — and that is a legal risk because Art. 56 of the Tax Code Regulation requires issuance at the moment of the operation and regulates contingency separately. The fix is contingency mode: offline issuance with local numbering, synced to the SII once it comes back. Not a standard Odoo feature — needs a custom module.

Does not work: electronic assignment for factoring

Chile runs a separate SII module for electronic assignment (cesión electrónica) — the transfer of DTE collection rights for factoring with Tanner, Banco BCI, Banco Estado, Forum, or Incofin. It operates through RPEL (Registro Público Electrónico de Transferencia de Créditos), a different SII API. Standard l10n_cl_edi does not support it — custom development required.

Five common l10n_cl mistakes

Over the last 18 months we audited roughly 40 SMB l10n_cl installations in Chile and other LATAM countries. Five mistakes repeat more than the rest. The 30-minute audit catches them quickly — they also work as a self-applied checklist.

#1. Certificate issued to the outside accountant, not to the Legal Representative

Chilean accountants sometimes issue DTEs in their clients' names using their own certificate. The SII does not technically reject this, but it breaches Law 19.628 on personal data protection and is a potential ground for a fine under Art. 97 N° 16 (incorrect issuer identification). When you switch accountants, the problem detonates — the new accountant has no certificate for your company.

Fix: the company gets its own certificate in the Legal Representative's name. USD 40-150 a year, 2-day process through any accredited PSC.

#2. Folio overlap in the Odoo journal

When configuring l10n_cl_edi, people forget that each journal's ir.sequence in Odoo must be strictly tied to the CAF range. If the CAF covers folios 1001-2000 and the Odoo sequence is on 1500, the next CAF (2001-3000) collides — folio 1500 is already on file at the SII.

Fix: in Settings → Sequences, set next number for each Invoice 33 journal to current CAF folio + 1.

#3. Receiver RUT without validation in Odoo

Standard l10n_cl checks RUT format (XX.XXX.XXX-Y) with check digit. It does not validate: (a) that the RUT is active at the SII, (b) that the receiver RUT is a VAT taxpayer (for Invoice 33) or a final consumer (for Boleta 39). Issuing Invoice 33 against a non-VAT RUT yields Accepted with reservations — the receiver loses VAT credit, and a customer complaint follows.

Fix: integrate the SII taxpayer consultation API (free) into res.partner. Fires on partner save.

#4. Credit notes without the right reference

DTE 61 (Credit Note) must carry the Referencia to the original DTE. If it is missing or does not match, the SII rejects with referencia inválida. In l10n_cl_edi, the link is wired automatically by the Reversal Wizard, but if you create the credit note manually (Add Credit Note button), the reference is not populated.

Fix: always use the Reversal Wizard. If a manual note already exists, add the reference through Other Info before issuing.

#5. Sending to the customer before the SII Accepted

A DTE has three states: Accepted, Accepted with reservations, Rejected. Only Accepted grants clean VAT credit. Many SMBs trigger the customer dispatch immediately after issuance, before reading the SII response; Rejected arrives, and they lose both the customer and the credit.

Fix: configure customer dispatch (email or WhatsApp) to trigger only on Accepted. On Rejected, the workflow returns the DTE to Draft with a logged reason.

«The SII takes about 90 seconds on average to come back with the state. Those 90 seconds are the difference between selling well and selling badly.»

Anonymous case: textile distributor migrates Defontana 2019 → Odoo 17

Situation. Textile and footwear distributor based in Santiago, around 200 SKUs and 600 transactions per month. Used Defontana 2019, issued Invoice 33, Credit Note 61, and Dispatch Guide 52. Late 2025 they hit three concrete problems.

1. Defontana did not update XSD for the Q3 2025 SII changes — every 2-3 weeks a handful of DTEs fell into Rejected.
2. The dispatch guide was issued with the basic fields (origen = only comuna), which after May 1, 2026 would be direct grounds for a fine under Resolution 207.
3. Monthly Libros SII reconciliation ate 3 working days — export from Defontana to Excel, cross-check by hand.

What we did. A 2-month project (February-March 2026):

• Migration to Odoo 17 Community with l10n_cl + OCA l10n_cl_edi.
• Early implementation of the extended dispatch-guide fields: full origin and destination, carrier RUT + driver RUT + plate, nature of the movement.
• Custom contingency module for POS (8 sales points across Santiago and Valparaíso).
• Libros Compras and Libros Ventas automation — Odoo report exports SII-ready XML, with a cron on the 5th of each month.
• WhatsApp Business API integration via 360Dialog for B2C boleta delivery.
• RUT validation via SII consultation on partner save.

Result 60 days after go-live:

• Rejected DTEs: from 4-6 per month to 0.
• Libros reconciliation time: from 3 days to 45 minutes.
• Compliance: 100% ready for May 1 and March 1.
• TCO reduction: around USD 14,000 per year (Defontana licensing + external PSC + manual reconciliation labor).

The project cost USD 22,000 across migration, customization, and training. Payback in 19 months, before counting fines avoided and VAT credit no longer lost by customers. This kind of legacy installation rescue has become the most frequent case over the last year for SMBs on pre-2020 stack.

Your next step

Ready to check your installation? Download the «SII 2026 in 7 steps» checklist — PDF with concrete dates, SII forms, Odoo verification (l10n_cl + CAF + certificate + delivery), and an estimate of potential Art. 97 fines for your operations volume. No email gate.

Or book a 30-minute audit — in one call we assess whether your Odoo, Defontana, Bsale, Toteat, or Manager will hit the May deadline. I am Sergei Filatov, Forbes 30 Under 30 LATAM. I do Odoo implementations with a data-driven mindset for SMBs in 10 LATAM countries.

FAQ