Schema DTE SII: Chile's Electronic Invoice XML Structure Explained

If you are integrating with Chile's Servicio de Impuestos Internos (SII) for electronic invoicing, you need to understand the DTE XML schema. DTE stands for Documento Tributario Electrónico, and the schema defines every field, constraint, and nesting rule your XML must follow to pass SII validation. This guide walks through the structure, the common document types, and the exact patterns that trip up most integrations.

What Is a DTE and Why Does the Schema Matter

A DTE is any tax document issued electronically and authorized by Chile's SII. Every invoice, credit note, debit note, and dispatch guide your business sends must conform to the official XML schema published by SII. If your XML does not validate against this schema, SII rejects the document outright; there is no partial acceptance.

The schema file (typically DTE_v10.xsd or its current revision) defines:

• Allowed document types and their numeric codes
• Required and optional fields per document type
• Field lengths, data types, and enumeration values
• The nesting structure (Documento > Encabezado > IdDoc, Emisor, Receptor, Totales, etc.)
• Digital signature placement and format

DTE Document Types

SII defines over a dozen document types, each identified by a numeric code in the TipoDTE field. Here are the ones you will encounter most often:

| Code | Document Type | Spanish Name | Common Use | |---|---|---|---| | 33 | Electronic Invoice | Factura Electrónica | Standard B2B sales | | 34 | Exempt Electronic Invoice | Factura No Afecta o Exenta | Tax-exempt sales | | 39 | Electronic Purchase Receipt | Boleta Electrónica | B2C retail sales | | 41 | Exempt Electronic Receipt | Boleta No Afecta o Exenta | Tax-exempt retail | | 43 | Liquidación Factura | Liquidación Factura Electrónica | Commission sales | | 46 | Electronic Purchase Invoice | Factura de Compra Electrónica | Buyer-issued invoice | | 52 | Electronic Dispatch Guide | Guía de Despacho Electrónica | Goods transport | | 56 | Electronic Debit Note | Nota de Débito Electrónica | Price increase, interest | | 61 | Electronic Credit Note | Nota de Crédito Electrónica | Returns, discounts | | 110 | Export Electronic Invoice | Factura de Exportación Electrónica | International sales |

Each type has slightly different required fields. For example, type 33 requires IVA (VAT) calculation in Totales, while type 34 explicitly omits it. Type 52 (dispatch guide) requires transport-related fields like Transporte that other types ignore.

XML Structure: The Anatomy of a DTE

Every DTE document follows the same high-level nesting. Understanding this tree is the key to building a correct XML generator.

Encabezado (Header)

The <Encabezado> block contains four required child elements:

IdDoc holds the document identity: TipoDTE (document type code), Folio (sequential number from your CAF range), FchEmis (issue date in YYYY-MM-DD format), and optionally FmaPago (payment method) and FchVenc (due date).

Emisor contains the issuer's data: RUTEmisor, RznSoc (legal name), GiroEmis (business activity), Acteco (SII activity code), DirOrigen, CmnaOrigen, and CdgSIISucur if the issuer has branch offices.

Receptor mirrors the buyer's info: RUTRecep, RznSocRecep, GiroRecep, DirRecep, CmnaRecep.

Totales contains the calculated amounts: MntNeto (net amount), TasaIVA (VAT rate, typically 19), IVA (VAT amount), MntTotal (total). For exempt documents, you use MntExe instead of MntNeto and omit IVA entirely.

Detalle (Line Items)

Each <Detalle> element represents one line item. Required fields:

<Detalle>
  <NroLinDet>1</NroLinDet>
  <NmbItem>Servicio de consultoría técnica</NmbItem>
  <QtyItem>10</QtyItem>
  <PrcItem>50000</PrcItem>
  <MontoItem>500000</MontoItem>
</Detalle>

Optional but common fields include DscItem (item description), UnmdItem (unit of measure), CdgItem (item code with TpoCodigo and VlrCodigo children), and DescuentoPct / DescuentoMonto for line-level discounts.

The CAF: Your Folio Authorization

Before you can issue any DTE, you need a CAF (Código de Autorización de Folios) from SII. The CAF is an XML file that grants you a range of folio numbers for a specific document type. For example, a CAF might authorize folios 1 through 100 for type 33 invoices.

The CAF contains:

• The authorized folio range (RNG > D and RNG > H for start and end)
• Your company's RUT
• The document type
• An RSA public key that SII uses to validate your signatures
• The corresponding private key (keep this secret)
• SII's own signature over the authorization

When you build the <TED> (Timbre Electrónico Digital) section of a DTE, you sign a digest of core document fields using the private key from your CAF. SII verifies this stamp using the public key it holds. If the folio is outside your authorized range, or the signature does not match, the document is rejected.

CAF Lifecycle

| Stage | What Happens | Action Required | |---|---|---| | Request | You request folios via SII's portal or API | Choose document type and quantity | | Active | Folios are valid for issuance | Use folios sequentially | | Running low | Fewer than 20% of folios remain | Request a new CAF range | | Expired | SII revokes unused folios after ~6 months | Request fresh folios | | Exhausted | All folios in the range have been used | Must have a new CAF ready |

XML Digital Signature

Every DTE requires an XML Digital Signature (XMLDSig) that covers the entire <Documento> element. The signing process follows these steps:

1. Canonicalize the <Documento> XML using C14N (Canonical XML 1.0)
2. Hash the canonicalized output with SHA-1 (SII still requires SHA-1 for DTE signatures as of 2026)
3. Sign the hash with your RSA private key (from a valid SII digital certificate, not the CAF key)
4. Embed the signature as a <Signature> element inside <DTE>, after <Documento>

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
    <Reference URI="#F33T1">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <DigestValue>...</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>...</SignatureValue>
  <KeyInfo>
    <KeyValue>
      <RSAKeyValue>
        <Modulus>...</Modulus>
        <Exponent>AQAB</Exponent>
      </RSAKeyValue>
    </KeyValue>
    <X509Data>
      <X509Certificate>...</X509Certificate>
    </X509Data>
  </KeyInfo>
</Signature>

The Reference URI follows the pattern #F{TipoDTE}T{Folio}, so invoice folio 1 becomes #F33T1. This URI must match the ID attribute on your <Documento> element.

Sending DTEs to SII: The EnvioDTE Wrapper

Individual DTEs do not go to SII alone. You wrap one or more DTEs in an <EnvioDTE> envelope:

<EnvioDTE xmlns="http://www.sii.cl/SiiDte" version="1.0">
  <SetDTE ID="SetDoc">
    <Caratula version="1.0">
      <RutEmisor>76123456-7</RutEmisor>
      <RutEnvia>12345678-9</RutEnvia>
      <RutReceptor>60803000-K</RutReceptor>
      <FchResol>2024-01-15</FchResol>
      <NroResol>0</NroResol>
      <TmstFirmaEnv>2026-04-06T10:30:00</TmstFirmaEnv>
      <SubTotDTE>
        <TpoDTE>33</TpoDTE>
        <NroDTE>1</NroDTE>
      </SubTotDTE>
    </Caratula>
    <DTE version="1.0">
      <!-- your Documento + Signature here -->
    </DTE>
  </SetDTE>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <!-- envelope-level signature -->
  </Signature>
</EnvioDTE>

The <Caratula> summarizes the batch: who is sending, who is receiving, the SII resolution date and number that authorized your electronic invoicing, and a count of DTEs by type. The entire <SetDTE> gets its own XMLDSig signature at the envelope level.

FchResol and NroResol come from the SII resolution that authorized you as an electronic invoicer. For companies in the certification environment, NroResol is 0 and FchResol is the date SII granted your test environment access.

Validation Flow: What Happens After You Send

After upload, SII returns a TrackID immediately. This does not mean acceptance. You must poll SII's status endpoint with that TrackID to get the final result. Processing typically takes 30 seconds to 5 minutes, but can take longer during peak tax filing periods (end of month, annual tax season).

The final response is one of:

• RSC (Recibido Sin Comprobación): received, not yet checked
• RCT (Recibido Con Comprobación): accepted, legally valid
• RFR (Rechazado por Firma): signature invalid
• RCH (Rechazado por Schema): XML schema validation failed
• RPR (Rechazado por regla de negocio): business rule violation

Common Pitfalls

These are the issues that consume most debugging time when implementing SII integration:

Minimal Working Example: Building a Type 33 Invoice

Here is a minimal but complete structure for a standard electronic invoice (type 33):

<?xml version="1.0" encoding="ISO-8859-1"?>
<DTE version="1.0" xmlns="http://www.sii.cl/SiiDte">
  <Documento ID="F33T101">
    <Encabezado>
      <IdDoc>
        <TipoDTE>33</TipoDTE>
        <Folio>101</Folio>
        <FchEmis>2026-04-06</FchEmis>
      </IdDoc>
      <Emisor>
        <RUTEmisor>76123456-7</RUTEmisor>
        <RznSoc>Mi Empresa SpA</RznSoc>
        <GiroEmis>Servicios de tecnología</GiroEmis>
        <Acteco>620200</Acteco>
        <DirOrigen>Av Providencia 1234</DirOrigen>
        <CmnaOrigen>Providencia</CmnaOrigen>
        <CiudadOrigen>Santiago</CiudadOrigen>
      </Emisor>
      <Receptor>
        <RUTRecep>96500000-5</RUTRecep>
        <RznSocRecep>Cliente SA</RznSocRecep>
        <GiroRecep>Comercio al por mayor</GiroRecep>
        <DirRecep>Los Leones 456</DirRecep>
        <CmnaRecep>Providencia</CmnaRecep>
        <CiudadRecep>Santiago</CiudadRecep>
      </Receptor>
      <Totales>
        <MntNeto>500000</MntNeto>
        <TasaIVA>19</TasaIVA>
        <IVA>95000</IVA>
        <MntTotal>595000</MntTotal>
      </Totales>
    </Encabezado>
    <Detalle>
      <NroLinDet>1</NroLinDet>
      <NmbItem>Servicio de desarrollo de software</NmbItem>
      <QtyItem>1</QtyItem>
      <PrcItem>500000</PrcItem>
      <MontoItem>500000</MontoItem>
    </Detalle>
    <TED version="1.0">
      <!-- Timbre Electronico Digital -->
      <!-- Generated and signed with CAF private key -->
    </TED>
  </Documento>
  <!-- XMLDSig Signature goes here -->
</DTE>

The IVA calculation: 500000 * 0.19 = 95000. Total: 500000 + 95000 = 595000. All integers, no rounding ambiguity.

Integration Checklist

Before going live with SII electronic invoicing, verify each of these:

Wrapping Up

Chile's DTE schema is strict but predictable. Once you understand the nesting (DTE > Documento > Encabezado + Detalle + TED + Signature), the CAF folio lifecycle, and the two-layer signing requirement (CAF key for the stamp, certificate key for the document), the pieces fit together. The debugging pain almost always comes from encoding mismatches, arithmetic rounding, or using the wrong private key for the wrong signature. Get those three right and your integration will clear SII validation on the first try.

Fazm is an open source macOS AI agent. Open source on GitHub.