Latin America continues to show why they lead the world in electronic invoicing. Below I cover the basics of the Chile eInvoice process. Chile was one of the first movers in electronic invoicing and they have one of the more complex environments. The model isuniquebut does take into account some similar processes from other Latin America countries.
The Chilean electronic invoicing model combines elements of the batch-oriented folio scheme used in the legacy Mexican CFD model along with the real-time communication as found in Brazil and Argentina. The process begins in two steps – first a delivery document (the “Gia Despacho” or “bill of lading”) is generated and registered with the government as the initial transport event, and then the other fiscal documents (like invoice or credit/debit notes) are generated and registered with reference to that event as follow-on activities occur later in the process.
Currently, there are 12 types of electronic fiscal documents, referred to collectively as “Documentos Tributarios Electrónicos” or DTE. Each document type has its own series of government issued folio numbers, which are consumed by the company in sequence as each DTE is produced. The fiscal data required for each document is packaged in a DTE specific XML format, and then signed and registered with the government in real time via web services exposed by the Chilean tax authority.
Additionally, at the end of each month, a set of up to four compliance reports are uploaded to the government web site, either manually or through automated web service. These reports summarize the DTE transactions produced during the month and specifically account for each folio used or destroyed. Folios can be skipped or voided through automated web service and any paper DTE’s issued in contingency must appear on these reports as well.
Customers registered for outbound DTE must be able to receive inbound DTE also. This involves providing a XML response back via email to the email address registered by the supplier on the SII website. There are currently no requirements for inbound fiscal compliance validation, though the XML structure fully supports it.
