Colombia Electronic Invoicing in SAP: DIAN Prior Validation

Status: Live nationwide prior-validation regime. Verified on: 10 July 2026. Colombia’s electronic sales invoice is a regulated fiscal document, not simply a PDF sent by email.

Electronic sales invoices, credit notes and debit notes must be generated in the DIAN-defined structure and transmitted for validation. DIAN checks the submitted document against its rules and returns a validated or rejected result. The validated document and DIAN evidence are then delivered to the buyer. A production design therefore has to treat DIAN validation as part of the invoice lifecycle, while still controlling accounting, customer delivery and exception handling in SAP.

Who is in scope

The regime applies to persons and entities required to issue invoices under Colombia’s tax rules, including electronic billers enabled in DIAN’s service. It should not be summarised as “every company and every transaction”. A scope assessment must consider the seller’s tax status, the operation, any permitted equivalent document, the buyer, and whether the document is an invoice, adjustment, supporting document or another electronic instrument.

• Core scope: electronic sales invoices issued by obligated electronic billers, plus the related credit and debit notes.
• Separate processes: electronic equivalent documents, payroll support, acquisitions from parties not required to invoice, and RADIAN events have their own legal and technical rules.
• Not a safe shortcut: a commercial PDF or an XML created without DIAN validation is not a substitute for the regulated document.

Format, identifiers and channel

The current DIAN technical documentation adopts version 1.9 of the Electronic Sales Invoice Technical Annex. The regulated payload is XML based on UBL 2.1 with Colombian extensions and validation rules. The invoice carries a CUFE, the unique electronic invoice code calculated from prescribed invoice data. Related notes and other instruments use the applicable unique document identifier, including CUDE where required.

The XML, digital signature, authorised numbering, tax data, parties, totals and references must remain consistent. DIAN responses and business events are represented separately from the invoice payload; the technical annex uses ApplicationResponse messages for relevant responses and events. Do not collapse an invoice, DIAN validation response and later buyer or RADIAN event into one SAP status.

An electronic biller may operate through its own software, an authorised technology provider or DIAN’s free solution. The route selected changes integration ownership, but it does not remove the biller’s responsibility for source data, document numbering, validation outcomes and retention.

Lifecycle, corrections and contingency

1. SAP creates the commercial and accounting source document with the correct customer, tax, numbering and reference data.
2. The integration maps the source to the Annex 1.9 XML, calculates or verifies the required identifiers, applies the required signature and submits the document.
3. DIAN returns a validated or rejected result. A rejection must enter a controlled correction queue; it must not be treated as successful delivery.
4. After validation, the buyer receives the regulated document, its graphical representation where used, and the DIAN validation evidence through the configured delivery process.
5. Subsequent corrections use the legally appropriate credit or debit note and retain references to the original document. Business and RADIAN events remain traceable as separate messages.

Contingency depends on where the technical incident occurs. For an issuer-side incident, the current rules allow the applicable paper or talonario process only in the defined circumstances and require later electronic transcription and transmission. The compiled DIAN rules specify transmission within 48 hours after the incident is overcome for the relevant issuer contingency. DIAN-side and buyer-side incidents have their own procedures. Record the incident, preserve sequence and timestamps, prevent duplicate CUFE generation, and reconcile every fallback document after service restoration.

What this means for SAP

• Maintain Colombian tax identifiers, addresses, responsibilities, authorised ranges and payment data in governed master data.
• Separate SAP billing status from DIAN submission, validation, customer delivery and later-event status.
• Use idempotent submission and retry controls so a timeout does not create duplicate fiscal documents.
• Archive the signed XML, DIAN response, graphical representation, delivery evidence and adjustment chain under a common business reference.
• Test tax rounding, allowances, charges, free-of-charge items, foreign currency, exports, notes and contingency—not only the happy-path invoice.

S4FN delivery classification: S4FN implementation service and, where required, a custom integration. The SAP release, existing localisation, selected DIAN operating mode and provider contract are assessed before a delivery model is proposed. This page does not claim that every Colombia requirement is supplied as standard SAP content.

Primary sources

• DIAN — Electronic invoicing overview
• DIAN — Prior validation
• DIAN — Technical documentation and Annex 1.9
• DIAN — Resolution 227 of 2025, compiled rules

Review note: DIAN rules, annexes and validation assets can change. Confirm current taxpayer scope, resolutions, certificates, test requirements and production endpoints with DIAN, the selected provider and Colombian tax counsel before go-live. This page is implementation guidance, not legal or tax advice.