FECO - Guía Implementación Cambio Normativo 2019 v1.3

Factura Electrónica
Colombia
Guía Implementación
Cambio Normativo 2019
(Modelo Validación Previa)
V1.3
Ganas el tiempo que no quieres perder, cuando compartes

información entre socios comerciales, apoyando tu tesorería,
contabilidad, logística, facturación y optimizas tus procesos order
to cash y order to pay.
Información Confidencial
Información // No//
Confidencial reproducir sin autorización
No reproducir especial
sin autorización de Carvajal
especial Tecnología
de Carvajal y Servicios
Tecnología y Servicios
Contenido
1. Objetivo ..................................................................................................................................... 3
2. Introducción .............................................................................................................................. 3
3. Contextualización ..................................................................................................................... 4
4. Estándar ..................................................................................................................................... 9
5. Validaciones ............................................................................................................................ 19
6. Catalogo Validaciones CTS .................................................................................................... 22
7. Configuración .......................................................................................................................... 35
8. Canales ..................................................................................................................................... 36
9. Pantillas PDF............................................................................................................................ 39
10. CENF...................................................................................................................................... 40
11. Consideraciones Adicionales ............................................................................................. 43
12. Información General y Tips............................................................................................... 46
Control Cambios
Versión Fecha Descripción
Modificación
1.1 24/09/2019 Adición de CAP12 con tips e información importante DIAN
Adicion en el CAP11 de “Actualización Anexo Técnico SEP
1.2 02/10/2019
2019” con información preliminar de cambios.
Adición en el CAP12 con información adicional sobre
1.3 24/10/2019 especificación de campos para productos gratis de
acuerdo a información de la DIAN.
Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

1. Objetivo
El propósito general de esta guía es ofrecer información sobre el marco de trabajo con
modelo de validación previa dispuesto por la DIAN. La guía cuenta con documentos
relacionados que permiten apoyar y guiar el proceso de implementación tanto para
migración (UBL 2.0) como para nuevos proyectos (UBL 2.1)
2. Introducción
La guía de implementación cuenta con un Repositorio central donde se disponen de
diferentes documentos y herramientas que apoyan cada fase del proceso de
implementación, las cuales se describen a continuación.
Repositorio Documental Central:
Repositorio
Estructura
1. Contextualización
a. FECO - Conozca cómo Afrontar el Modelo con Validación Previa V3.pdf
b. Anexos Técnicos.pdf
c. Resolución 000030 de 29-04-2019.pdf
d. FECO Validación Previa 2019 Contextualización_Cronograma.xlsx
e. Presentaciones FRONT
f. Presentaciones BACK
g. Cronograma dinámico para calendarizar Cliente nuevo y migración
2. Estandar 2.1
a. FECO Estandar Plano V4-0 UBL2.1 Borrador.xlsx
b. CLIENTE_FECO Estandar Plano V4-0 UBL2.1 Borrador.xlsx
c. FECO Calculo CUFE QR.xlsx
d. DIAN Result / XML Application Response DIAN Result / Eventos
e. Insumos Muestras UBL2.1 (FV, ND, NC, DianResult)
3. Validaciones 2.1
a. FECO validaciones UBL2.1 Borrador.xlsx
4. Configuración
a. SIGO
b. CheckList
5. Canales
a. AS2 Connection Information Carvajal AWS
b. Cert_AS2_cen.biz.2018
c. FECO SFTP CERBERUS SOLICITUD
d. FECO SFTP Ficha tecnica cerberus
e. INTRODUCCION TECNICA WSx
f. INTRODUCCION TECNICA AS2x

g. INTRODUCCION TECNICA SFTPx
h. Manual_Tecnico_Web_Service_Factura_Colombia_07-VCDI151096-EB
6. Plantillas PDF
a. FECO - Catalogo Estándar Formatos PDF v3.2.pdf
b. LI
7. CENF
a. Manuales y Guías rápidas.
b. Manuales CENF (Inglés/Español)
8. Formatos
a. Actas
b. Correos Estándar
c. Formatos de Implementación
3. Contextualización
Documentos Kit Herramientas DIAN
Contextualización
Consideraciones para el Modelo de Emisión con Validación Previa. En verde se

identifican los puntos que hacen parte de los cambios en el modelo de validación.

Consideraciones para el Modelo de Recepción con Validación Previa. En verde se
identifican los puntos que hacen parte de los cambios en el modelo de validación.
Consideraciones importantes RESOLUCIÓN 000030 DE ABRIL 29 2019

Articulo 616 – 2 del estatuto tributario. No requerirá la expedición de factura electrónica
en las operaciones realizadas por banco, corporaciones financieras, corporaciones de
ahorro y vivienda y las compañías de financiamiento comercial. Tampoco en las ventas de
régimen simplificado. Articulo 771 – 2 del ET, el documento que se entregue como
evidencia de la transacción deberá cumplir con los requisitos mínimos que el gobierno
nacional establezca.
Articulo2. Requisitos Factura Electrónica de Venta: La factura electrónica de venta

deberá expedirse con el lleno de los siguientes requisitos:
1. Estar denominada expresamente como factura de venta.
2. Apellidos y nombre o razón y NIT del vendedor o de quien presta el servicio.
3. Apellidos y nombre o razón social y NIT del adquirente de los bienes o servicios.
Cuando el adquiriente personal natural no se encuentre inscrito en el RUT, se deberá
incluir el tipo y numero de documento de identidad.
4. Llevar un número que corresponda a un sistema de numeración consecutiva de
facturas de venta, incluyendo el número de autorización, rango autorizado y
vigencia autorizada por la DIAN, en las condiciones que se señalan en las
disposiciones que regulan la materia.
5. Fecha y hora de generación.
6. Fecha de su expedición la cual corresponde a la validación.
7. Cantidad y descripción específica de los bienes vendidos o servicios prestados,
utilizando códigos que permitan la identificación y relación de los mismos.
8. Valor total de la operación.

9. Forma de pago, indicando si es de contado o a crédito, caso en el cual deberá
señalarse el plazo.
10. Medio de pago, indicando si se trata de efectivo, tarjeta crédito, tarjeta débito o
transferencia electrónica u otro, cuando aplique.
11. Indicar la calidad de retenedor del impuesto sobre las ventas - IVA.
12. La discriminación del impuesto sobre las ventas – IVA y la tarifa correspondiente.
13. La discriminación del impuesto nacional al consumo y la tarifa correspondiente.
14. Incluir firma digital o electrónica del facturador electrónico de acuerdo con las
normas vigentes y con la política de firma que establezca la DIAN, al momento de
la generación como elemento para garantizar la autenticidad, integridad y no
repudio de la factura electrónica de venta.
15. Incluir código único de facturación electrónica – CUFE según lo establezca la DIAN.
16. El código QR, cuando se trate de la representación gráfica digital o impresa.
CAPÍTULO V, Artículo 8, Parágrafo 3

Para efectos de las representaciones gráficas en formato digital, los facturadores
electrónicos deberán utilizar formatos que sean de fácil y amplio acceso por el
adquiriente, garantizando que la factura se pueda leer, copiar, descargar e imprimir de
forma gratuita sin tener que acudir a otras fuentes para proveerse de las aplicaciones
necesarias para ello.
Las representaciones gráficas en formato digital o impresión deberán contener como
mínimo los requisitos del articulo 2° de esta resolución, salvo el relacionado en el numeral
14.
Glosario y Abreviaturas
CIAT ........................Centro Interamericano de Administraciones Tributarias
CUFE........................Código Único de Factura Electrónica
DE ..........................Documento Electrónico
DIAN ........................Dirección de Impuestos y Aduanas Nacionales
FE............................Factura Electrónica, Facturación Electrónica
IVA...........................Impuesto al Valor Agregado
NIT...........................Número de Identificación Tributaria
PA ...........................Proveedor, Proveedores Autorizado(s)
SIE............................Sistema de Información Electrónico
UBL ..........................Universal Business Language
XAdES .......................XML Advanced Electronic Signature
XAdES-EPES ................Forma básica a la que se la ha añadido información sobre la
política de firma
XML .........................eXtensible Markup Language
XPath.......................XML Path Language
XSD ..........................XML Schema Definition
XSL...........................eXtensible Stylesheet Language
XSLT.........................XML Stylesheet Language for Transformations

Validaciones de los Documentos Electrónicos
La validación de la factura electrónica de venta se realizará atendiendo los siguientes

eventos.
a) Validación Previa de la factura electrónica de venta: Una vez generado u

transmitida la factura electrónica de venta, nota débito, nota crédito, y demás
documentos electrónicos, por parte del facturador electrónico o el proveedor
tecnológico según el caso, la DIAN procederá a validar el cumplimiento de la
información transmitida y relacionada con los requisitos establecidos.
b) Una vez la DIAN confirme que los documentos cumplen con los requisitos y criterios
establecidos, la DIAN registrara en sus bases de datos el documento electrónico
validado y generará, firmará, almacenará y remitirá un mensaje de validación al
facturador electrónico o a su proveedor tecnológico para su expedición y entrega
al adquiriente.
c) En el caso que los documentos electrónicos no cumplan con los requisitos y
condiciones exigidas al momento de la validación, la DIAN procederá a registrar el
documento electrónico firmado y recibido en la base de datos de inconsistencias
sin consumir la combinación prefijo y número consecutivo.
d) La DIAN generará, firmará, almacenará y remitirá un mensaje de no validación al
facturador electrónico o al proveedor tecnológico, en el que se indican las causas
de la validación fallida.
e) Validación de la factura electrónica de venta expedida en el periodo de
inconvenientes tecnológicos de la Unidad Administrativa Especial Dirección de
Impuestos y Aduanas Nacionales – DIAN: Cuando no pueda llevarse a cabo la
validación previa de la factura electrónica por razones tecnológicas atribuibles a
la DIAN, el obligado a facturar está facultado para expedir y entregar al adquiriente
la factura electrónica de venta sin validación previa. La factura electrónica se
entenderá expedida con la entrega al adquiriente y deberá ser transmitida a la
DIAN, para su validación dentro de las 48 horas siguientes una vez restablecido el
servicio de la DIAN.
Inconvenientes de Tipo Tecnológico Relacionados con la Factura Electrónica
Medidas en caso de inconvenientes tecnológicos. El facturador electrónico, los

proveedores tecnológicos y los demás sujetos que hacen parte del catálogo de
participantes, deberán prever con suficiente anticipación el adecuado funcionamiento de
los medios requeridos para expedir las facturas electrónicas de venta, notas débito, notas
crédito y demás documentos electrónicos que se derivan de la factura electrónica de
venta.
1. Inconvenientes tecnológicos presentados por parte del facturador electrónico y/o el

proveedor tecnológico.
El facturador electrónico y/o proveedor tecnológico según el caso, deberán atender

las siguientes medidas.
a) Por el tiempo en que dure el inconveniente, expedir factura de venta de

talonario o de papel, utilizando la numeración de “Contingencia
Facturación Electrónica”. La factura de venta se podrá generar a través de
sistemas informáticos electrónicos.

b) Transcribir la información que contenga cada una de las facturas de venta
en el periodo del inconveniente y transmitirlas a la DIAN, a mas tardar
dentro del mes siguiente contado a partir de la fecha en que se supera el
inconveniente.
2. Inconvenientes tecnológicos presentados por parte del adquiriente que recibe la

factura electrónica de venta en formato electrónico de generación.
a) El adquiriente deberá informar al facturador electrónico, quien pondrá a

disposición del adquiriente, la factura electrónica por un medio diferente
(Correo electrónico).
b) En ningún caso, los eventuales daños en el sistema y/o equipos informáticos

y/o falta de conexión, serán justificación de la extemporaneidad en el envío
de la información.
c) Los facturadores que a la entrada en vigencia de la presente resolución

cuenten con numeración para facturar por talonario o de papel,
“Contingencia Facturación Electrónica” podrán seguir utilizando esta
numeración. No habrá lugar a la información CUFE.
3. Inconvenientes de tipo tecnológicos de la Unidad Administrativa Especial Dirección

de Impuestos y Aduanas Nacionales – DIAN para la recepción y validación de la
factura electrónica de venta.
Cuando por inconvenientes tecnológicos no haya disponibilidad del servicio

informático de validación previa de factura electrónica de la DIAN, el sistema
emitirá un mensaje informando el inconveniente de acuerdo con el “Anexo Técnico
de factura electrónica de venta”.
La DIAN dará a conocer que el servicio ha sido restablecido para que se continúe de
inmediato con el procedimiento transmisión, validación, expedición y entrega de la
factura electrónica de venta, nota débito, nota crédito y demás documentos
electrónicos que se derivan de la factura electrónica de venta, con un tiempo que
se encuentre dentro de las 48 horas siguientes a la publicación del comunicado.
Recomendaciones para uso de Anexos Técnicos

1. Para la versión 2 de factura electrónica (UBL2.1) se han suprimido gran parte de
las personalizaciones del estándar UBL. Así, prefijos como fe, de, dcc desaparecen,
quedando los prefijos propios que maneja el UBL: cac, cbc. El prefijo sts se sigue
utilizando más los propios de la firma electrónica.
2. Se han especificado grupos y elementos de UBL adicionales a los que se trabajan

en la versión 1, con el ánimo de armonizar los conceptos de negocio a las
descripciones de cada grupo según lo define OASIS, responsable del estándar UBL.
En este sentido, algunos de los nuevos grupos son:
3.
a) cac:WhitHoldingTax, para informar las retenciones que a título de IVA, Renta
o ICA practique que el Emisor de la factura (aplica para los emisores actuando
como autoretenedores.

b) cac:PricingReference, para informar el precio comercial del ítem, únicamente
usado cuando se trate de muestras y/o regalos comerciales.
c) cac:AdittionalPropertyItem, para informar características de un ítem en

particular, relevantes en la transacción comercial, pero no en el aspecto
tributario. Por ejemplo, el caso de los vehículos, donde es necesario conocer
información relacionada a la placa, marca, línea, modelo, cilindrada, entre
otras informaciones.
Este grupo contiene dos elementos, uno llamado cbc:Name y otro cbc:Value.
El fin es que el facturador electrónico, cuando lo estime conveniente, informe
a su contraparte la información de interés. A manera de ejemplo:
I. <cbc:Name>Placa</cbc:Name>
II. <cbc:Value>AAA000</cbc:Value>
d) En el grupo cac:TaxTotal, se han agregado dos elementos,

cbc:BaseUnitMeasure y cbc:PerUnitAmount, para informar los tributos cuya
tarifa es nominal en pesos.
Ejemplo de lo anterior, el impuesto al consumo de las bolsas plásticas, que se
hace por unidad o el Impuesto Nacional a los combustibles, que se hace por
galón.
e) Se han perfeccionado las tablas de valores, de tal manera que se facilite la

inclusión de nuevos valores en un futuro próximo.
f) Se ha fortalecido la malla de validaciones para mejorar la consistencia de la

información, así como la estandarización en su reporte.
4. Estándar
Estándar 4.0 UBL2.1
Información General:
• Total Campos disponibles por tipo para UBL 2.1
Tipo Campo Cant

OBLIGATORIO 151
OPCIONAL 398
DEPENDIENTE 62
Total 611

• Convenciones para identificar condiciones de los campos
Campo nuevo mandatorio para UBL2.1

Cambio en definición de campo, longitud del campo,
obligatoriedad
Campo nuevo opcional para UBL2.1
Campos que se encuentran en el anexo técnico con
definiciones pendientes por la DIAN
Consideraciones para el Estandar 4.0 con soporte para UBL2.1:
• El Archivo del Estandar conserva los segmentos, campos, descripciones y

características que se encontraban disponibles en la versión 2.0.
• Se presentan filtros para identificar los tipos de campos, comparar entre la
versión 2.0 y 2.1 e identificar por colores las nuevas características.
Campos Nuevos Obligatorios y Dependientes:

Identificador
Repeticiones No.
de registro/ Req. Tipo Long. Descripción
Registro Campo
Segmento
Código que describe el “ambiente de destino donde
ENC Mandatorio 1 20 N 1 será procesada la validación previa de este
documento electrónico”
ENC Mandatorio 1 21 AN 4 Indicador del tipo de operación
Digito de verificación -DV del NIT del emisor

EMI Mandatorio 1 22 N 1
Rechazo si el DV no corresponde al NIT informado
Código del municipio.

Este código de municipio debe corresponder a valor
EMI Mandatorio 1 23 AN 5
valido
de lista de municipios Tabla 35 - Código Municipio
Nombre registrado en el RUT. Si el emisor persona
jurídica desea también utilizar el nombre comercial
EMI Mandatorio 1 24 AN 450
en el archivo de la factura, debe utilizar el campo
"Nombre Comercial -EMI 7"
Código del municipio
Si este es un grupo con informaciones con respeto a la
DFE Dependiente 1 1 AN 5 dirección del emisor de un documento electrónico,
debe ser un municipio de Colombia.
Obligatorio para emisores y Adquirentes Responsables
Código del Departamento

Si este es un grupo con informaciones con respeto a la
DFE Dependiente 1 2 AN 5
dirección del emisor de un documento electrónico,
debe ser un municipio de Colombia
10

DFE Dependiente 1 3 AN 3 Código dentificador del país
DFE Dependiente 1 4 AN 10 Código postal
GTE Mandatorio 1 1 AN 10 Identificador del tributo
GTE Mandatorio 1 2 AN 30 Nombre del tributo
Nombre registrado en el RUT. Si el adquirente es

persona jurídica desea también utilizar el nombre
ILA Dependiente 1 1 AN 450
comercial en el archivo de la factura, debe utilizar el
campo "Nombre Comercial -ADQ 7"
GTA Mandatorio 1 1 AN 10 Identificador del tributo
GTA Mandatorio 1 2 AN 30 Nombre del tributo
Nombre o Razón Social de la persona o entidad

ITT Dependiente 1 1 AN 450 Razón social o nombre del transportador registrado en
el RUT
ITT Dependiente 1 2 AN 7 Obligaciones del transportardor
ITT Dependiente 1 3 AN 2 Régimen al que pertenece el transportador
ITT Dependiente 1 4 AN 12 Identificador del tranportador.
Tipo de documento de identificación. Tipo de

ITT Dependiente 1 5 AN 2
identificador fiscal de la persona o entidad
Descripción de la naturaleza de la corrección. Tamaño

DCN Dependiente 50 1 AN 5000
mínimo 20 tamaño máximo 5000
ITE Mandatorio 27 N 6 La cantidad real sobre la cual el precio aplica.

9999
11

Unidad de medida de la cantidad del artículo
ITE Mandatorio 9999 28 AN 3
solicitado
Código del producto acuerdo con el estándar descrito

IAE Mandatorio 50 1 AN
en el campo IAE_2.
IAE Mandatorio 50 2 AN 3 Código del estándar.
• Nuevo Segmento LLAVE-VALOR Información Específica del Item

Este segmento permite especificar de forma libre información asociada al ITEM
Ejm. IEI_1 = “TIPO_VEHICULO”, IEI_2 = “CAMION”.
Registro Opcional, se puede repetir hasta cincuenta (50) veces, por cada Registro ITEM (ITE)
Grupo de información para adicionar información específica del ítem que puede ser solicitada por autoridades o entidades
diferentes a la DIAN
Descripción
Identificador No. Valor Versión
Rep. Aplica para. Req Tipo Long.
de registro Campo Value UBL
Factura/Invoice,
Nota Debito Característica que quiere
1 /Debit Note, M AN 50 2.1 informar del ítem, por
Nota Crédito ejemplo (Uso Vehículo)
/Credit Note
IEI 50
Factura/Invoice,
Nota Debito Valor de la característica
2 /Debit Note, M AN 50 2.1 que se quiere informar, por
Nota Crédito ejemplo (Particular)
/Credit Note
12

• Items del Documento
Ampliación de 15 enteros y 6 decimales, Textos técnicos del ítem hasta 5000
caracteres.
Ejm Valor del Articulo, ITE_7 = 1.123.456,123456
Identificador No. Aplica para.

Req. Tipo Long. Descripción
de registro Campo applies to.
Valor total de la línea. Cantidad x Precio
Factura/Invoice, Unidad menos descuentos más recargos
Nota Debito /Debit que apliquen para la línea.
ITE 5 Note, M N 15.6 El Valor Total de la línea es igual al
Nota Crédito /Credit producto de Cantidad x Precio Unidad
Note menos Descuentos más Recargos que
apliquen para la línea.
Factura/Invoice,
Nota Debito /Debit
ITE 7 Note, M N 15.6 Valor del artículo o servicio
Nota Crédito /Credit
Note
Factura/Invoice,
Nota Debito /Debit Descripción.
ITE 11 Note, M AN 300 Descripción del artículo o servicio a que se
Nota Crédito /Credit refiere esta línea de la factura
Note
Factura/Invoice,
Nota Debito /Debit
Datos Técnicos.
ITE 16 Note, O AN 5000
Datos técnicos asociados al artículo
Note
Factura/Invoice,
Nota Debito /Debit
Total del ítem (incluyendo Descuentos y
ITE 19 Note, D N 15.6
cargos). Ver Nota 11
Note
Factura/Invoice,
Nota Debito /Debit
ITE 21 Note, O N 15.6 Valor a pagar del ítem
Note
Factura/Invoice,
Nota Debito /Debit
Valor subtotal del grupo de conceptos del
ITE 23 Note, O N 15.6
ítem
Note
• Campo CUFE (Código Único de Factura Electrónica) /CUDE (Código Único de

Documento Electrónico) para notas y application response
Ampliación hasta 96 caracteres para soportar algoritmo SHA-384
El estándar se definió como 128 en caso de ampliación futura a SHA-512
Este cambio tiene posible impacto sobre la representación grafica
Ejm CUF_1 =
8605f5f47ec7e9156597d57f643ae9ecc1213b5abf05836004215b38eb53e99b309429d
515c6400e441c4fd478c6c180
13

Identificador único del documento

(CUFE/CUDE).
El identificador único del documento debe
Factura/Invoice,
ser calculado según corresponde el tipo de
Nota Debito
documento de acuerdo a lo especificado
CUF 1 /Debit Note, M AN 128
por la DIAN.
Nota Crédito
Para Factura de venta, exportación,
/Credit Note
contigencia: Se le llama CUFE.
Para Nota Débito, Nota Crédito: Se le
llama CUDE
• Impuestos
Ampliación de 15 enteros y 6 decimales
Nueva tabla para tarifa del tributo
IMP 7,8,9,10 campos nuevos opcionales

Factura/Invoice, Identificador del tributo.

Nota Debito La Dian rechaza si el contenido de este campo
1 /Debit Note, M AN 2 no corresponde a un contenido de la columna
Nota Crédito “código” de la tabla 11b (aceptase elemento
/Credit Note sin contenido)
Base Imponible sobre la que se calcula el
valor del tributo.
Factura/Invoice,
En el caso de que el tributo es un porcentaje
Nota Debito
del valor tributable: informar la base
2 /Debit Note, M N 15.6
imponible en valor monetario
Nota Crédito
En el caso de que el tributo es un valor fijo
/Credit Note
por unidad tributada: informar el número de
unidades tributadas
Factura/Invoice,
Nota Debito
Moneda de la base Imponible sobre la que se
3 /Debit Note, M A 3
calcula el valor del tributo
IMP Nota Crédito
/Credit Note
Valor del tributo: producto del porcentaje

aplicado sobre la base imponible
La Dian rechaza: Para tributos cuya tarifa se

enuncia en porcentajes
Factura/Invoice, si "IMP_4 - Valor del tributo" es diferente a
Nota Debito "IMP_2 - Base Imponible sobre la que se
4 /Debit Note, M N 15.6 calcula el valor del tributo" multiplicado por
Nota Crédito "IMP_6 - Tarifa del tributo"
/Credit Note La DIAN rechaza: Para tributos cuya tarifa se
enuncia en valores nominales (ejempo bolsas
plásticas)
si ""IMP_4 - Valor del tributo" es diferente a
"IMP_9 - Valor del tributo por unidad"
multiplicado por ITE_3
14

Factura/Invoice,
Nota Debito
5 /Debit Note, M A 3 Moneda del valor del tributo
Nota Crédito
/Credit Note
Tarifa del tributo
En el caso de que el tributo es un porcentaje
del valor tributable: informar la tarifa
Factura/Invoice, (porcentaje) a ser aplicada a la base
Nota Debito imponible
6 /Debit Note, O N 2.2 - El valor debe corresponder a los presentados
Nota Crédito en tablas 2.1- ver tabla 32, para los tributos
/Credit Note que figuren en dicha tabla.
Rechazo: Si reporta una tarifa diferente para
uno de los tributos enunciados en tablas 2.1-
ver tabla 32
Unidad de medida base para el tributo
Usado en el caso de que el tributo es un valor
Factura/Invoice, fijo por unidad tributada: informar el valor
Nota Debito del tributo por unidad tributada. Por ejemplo
7 /Debit Note, O N 2.2 el impuesto de consumo a las bolsas o los
Nota Crédito impuestos a los combustibles
/Credit Note La DIAN rechaza si "IMP_9 - Valor del tributo
por unidad" es informado y "IMP_7 - Unidad de
medida base para el tributo" no es informado
Factura/Invoice,
Nota Debito Identificación de la unidad de medida.
8 /Debit Note, D AN 5 Obligatorio si se envía "IMP_7 - Unidad de
Nota Crédito medida base para el tributo"
/Credit Note
Factura/Invoice, Valor del tributo por unidad. Es el valor
Nota Debito nominal del tributo por unidad.
9 /Debit Note, O N 15.2 La DIAN rechaza si el campo "IMP_7 - Unidad
Nota Crédito de medida base para el tributo" NO es
/Credit Note infomado.
Factura/Invoice,
Nota Debito Moneda del valor del tributo por unidad.
10 /Debit Note, D A 3 Obligatorio si se envia el valor de tributo por
Nota Crédito unidad.
/Credit Note
15

• Totales
Ampliación de 15 enteros y 6 decimales
Aplicación de técnica de redondeo sobre los campos TOT 1,3,5,7,9,11,13
Identific
No. Aplica para.
ador de Req. Tipo Long. Descripción
Campo applies to.
registro
Total Importe bruto antes de impuestos.
Valor bruto antes de tributos: Total valor bruto, suma
de los valores brutos de las líneas de la factura.
El valor bruto antes de tributos tiene que ser la suma
de los valores de las líneas de la factura que contienen
Factura/Invoice,
valor comercial
Nota Debito
Rechazo si TOT_1 no es la suma de los elementos
ITE_5
Nota Crédito
Rechazo:
/Credit Note
si
round(/sig:DebitNote/cac:RequestedMonetaryTotal/cb
c:LineExtensionAmount) es distinto de
round(sum(/sig:DebitNote/cac:DebitNoteLine/cbc:Lin
eExtensionAmount))
Factura/Invoice,
Nota Debito
2 /Debit Note, M A 3 Moneda total Importe bruto antes de impuestos.
Nota Crédito
/Credit Note
Total Valor Base Imponible : Base imponible para el
cálculo de los tributos
El Valor Base Imponible tiene que ser la suma de los
Factura/Invoice, valores de las bases imponibles de todas líneas de
Nota Debito detalle.
Nota Crédito Rechazo:
/Credit Note Si
TOT round(//cbc:TaxExclusiveAmount) es distinto de
round(sum(//cac:DebitNoteLine/cac:TaxTotal[1]/cac:
TaxSubtotal/cbc:TaxableAmount))
Factura/Invoice,
Nota Debito
4 /Debit Note, M A 3 Moneda del total Base Imponible
Nota Crédito
/Credit Note
Valor a Pagar de Factura: Valor total de ítems
(incluyendo cargos y descuentos a nivel de
ítems)+valors tributos + valor cargos – valor
descuentos – valor anticipos
El Valor a Pagar de Factura es igual a la Suma de Valor
Bruto más tributos - Valor del Descuento Total + Valor
del Cargo Total - Valor del Anticipo Total
Factura/Invoice,
Rechazo:
Nota Debito
Si
let $TaxInclusiveAmount :=
Nota Crédito
if(boolean(//cbc:TaxInclusiveAmount)) then
/Credit Note
//cbc:TaxInclusiveAmount else 0.00,
$SumTotalAllowance :=
if(boolean(//cbc:AllowanceTotalAmount)) then
//cbc:AllowanceTotalAmount else 0.00,
$SumTotalCharge := if
(boolean(//cbc:ChargeTotalAmount)) then
//cbc:ChargeTotalAmount else 0.00, $PrepaidAmount
:=
16

if (boolean(//cac:PrepaidPayment/cbc:PaidAmount))
then sum(//cac:PrepaidPayment/cbc:PaidAmount)
else
0.00, $PayableAmount := $TaxInclusiveAmount -
$SumTotalAllowance + $SumTotalCharge -
$PrepaidAmount return
round(number($PayableAmount)) es distinto de
round(//cac:LegalMonetaryTotal/cbc:PayableAmount)
Factura/Invoice,
Nota Debito
6 /Debit Note, M A 3 Moneda del total de la factura
Nota Crédito
/Credit Note
Total de Valor Bruto más tributos
El Valor Bruto más tributos tiene que ser igual a Valor
Bruto de la factura que contienen el valor comercial
más la Suma de los Tributos de todas las líneas de
Factura/Invoice,
detalle.
Nota Debito
Rechazo:
si
Nota Crédito
round(//cac:RequestedMonetaryTotal/cbc:LineExtensi
/Credit Note
onAmount +
sum(//cac:TaxTotal[not(ancestor::cac:DebitNoteLine)
]/cbc:TaxAmount)) es distinto de
round(//cbc:TaxInclusiveAmount)
Factura/Invoice,
Nota Debito
Moneda Total de Valor bruto con tributos
8 /Debit Note, D A 3
Obligatorio si se envia el valor en el campo anterior.
Nota Crédito
/Credit Note
Descuento Total: Suma de todos los descuentos
aplicados al total de la factura
El Valor del Descuento Total es igual a la Suma de
Factura/Invoice, todos los descuentos globales aplicados al total de la
Nota Debito factura.
9 /Debit Note, O N 15.6 Rechazo:
Nota Crédito Si
/Credit Note round(/sig:Invoice/cac:LegalMonetaryTotal/cbc:Allow
anceTotalAmount) es distinto de
round(sum(/sig:Invoice/cac:AllowanceCharge[cbc:Char
geIndicator = "false"]/cbc:Amount))
Factura/Invoice,
Nota Debito
Moneda del total de descuentos.
Nota Crédito
/Credit Note
Cargo Total: Suma de todos los cargos aplicados al
total de la factura
El Valor del Cargo Total es igual a la Suma de todos los
Factura/Invoice,
cargos globales aplicados al total de la factura.
Nota Debito
Rechazo:
11 /Debit Note, O N 15.6
Si
Nota Crédito
round(/sig:Invoice/cac:LegalMonetaryTotal/cbc:Charg
/Credit Note
eTotalAmount) es distinto de
round(sum(/sig:Invoice/cac:AllowanceCharge[cbc:Char
geIndicator = "true"]/cbc:Amount))
Factura/Invoice,
Nota Debito
Moneda del total de cargos.
Nota Crédito
/Credit Note
17

Anticipo Total: Suma de todos los pagos anticipados
El Valor del Anticipo Total es igual a la Suma de todos
los anticipos o prepagos globales aplicados al total de
la factura.
Factura/Invoice,
Rechazo:
Nota Debito
Si
13 /Debit Note, O N 15.6
(/sig:Invoice/cac:LegalMonetaryTotal/cbc:PrepaidAmo
Nota Crédito
unt) then
/Credit Note
round(/sig:Invoice/cac:LegalMonetaryTotal/cbc:Prepai
dAmount) =
round(sum(/sig:Invoice/cac:PrepaidPayment/cbc:Paid
Amount)) else true()
Factura/Invoice,
Nota Debito
Moneda del total de Anticipos.
Nota Crédito
/Credit Note
• Notas
Ampliación de tamaño hasta 5000 caracteres
Identificador Aplica para.

No. Campo Req. Tipo Long. Descripción
de registro applies to.
Factura/Invoice,
Nota Debito
Información adicional: Texto libre, relativo al
NOT 1 /Debit Note, M AN 5000
documento. Importante Ver Notas 7, 8
Nota Crédito
/Credit Note
18

5. Validaciones
Documentos Validaciones
La aplicación de las reglas de validación puede terminar en uno (1) de los siguientes tres
(3) resultados:
• Rechazo, si la aplicación de la regla apunta a una discrepancia grave, que indica
que las informaciones del archivo no pueden ser utilizadas de manera confiable
o de manera legal;
• Notificación, si la aplicación de la regla apunta a una discrepancia menos
importante, pero que asimismo merece que se advierta al emisor de un posible
problema con las informaciones del archivo;
• Aprobación, si la aplicación de la regla no apunta a ningún tipo de problema.
Las reglas de validación serán aplicadas en los siguientes momentos:
• Por la DIAN al recibir en línea, de un Proveedor Tecnológico (PT) un documento
electrónico para validación.
• Por la DIAN al recibir en contingencia, de un Proveedor Tecnológico (PT) un
documento electrónico para validación.
Convenciones Utilizadas en las Tablas de Reglas de Validación
Columna Descripción
Tipo Categoría de la regla de validación
# Identificador de la regla de validación
Campo Nombre del campo en las tablas de formato
Regla Descripción de la regla de validación
Cod Código de mensaje correspondiente a la regla de validación
Efecto de la regla de validación:
• R: Rechazo, el procesamiento correspondiente ha encontrado problemas que
Y impiden el procesamiento de la solicitud.
• N: Notificación. el procesamiento correspondiente ha encontrado indicios de
potenciales problemas, los cuales no impiden el procesamiento de la solicitud
Mensaje Mensaje regresado como resultado de un rechazo el de una notificación
V Versión de las reglas de validación
19

Resumen validaciones por conjunto
Tipo Cantidad de
Documento Tipo TOTAL
Validación Validaciones
Invoice Documento R 172
344
Invoice Documento N 172
ApplicationResponse Documento R 25
34
ApplicationResponse Documento N 9
CreditNote Documento R 139
305
CreditNote Documento N 166
CreditNoteLine Documento R 37
68
CreditNoteLine Documento N 31
DebitNote Documento R 144
306
DebitNote Documento N 162
DebitNoteLine Documento R 36
68
DebitNoteLine Documento N 32
InvoiceLine Documento R 47
80
InvoiceLine Documento N 33
Signature Documento R 56 56
Certificado Digital de Firma (Firma
Conexión R 7
XML) 13
Certificado digital de transmisión Conexión R 6
Firma Conexión R 3
7
Schema XML Conexión R 4
Web Service Conexión R 1
3
Web Service Conexión N 2
1284
Técnica de redondeo para aplicar a Totales de Factura e Impuesto (TOT, IMP)
La suma de elementos que son el resultado de otras operaciones aritméticas, como

aplicación de porcentajes, por ejemplo, puede llevar a diferencias entre los totales
calculados y los correctos. Para evitar la propagación de errores, para redondeos se
recomienda que sea utilizado el siguiente procedimiento:
Dígito siguiente al dígito menos significativo es Redondeo

Entre 0 y 4 Mantener el dígito menos
significativo
Entre 6 y 9 Incrementar el dígito menos
significativo
5, y el segundo dígito siguiente al dígito menos Mantener el dígito menos
significativo es cero o par significativo
5, y el segundo dígito siguiente al dígito menos Incrementar el dígito menos
significativo es impar significativo
20

Esta definición se hace para que se reduzca el riesgo de problemas de sumas de los
valores redondeados, para valores originales con décimas conteniendo el número “5”.
En caso de que, con la adopción de este procedimiento, haya diferencia entre los totales
calculados y la suma de los parciales, para el valor total de un documento se deberá
utilizar el elemento /Invoice/LegalMonetaryTotal/cbc:PayableRoundingAmount para
informar la diferencia.
Ejemplos para redondear cuando el digito menos significativo es la segunda casilla

decimal:
Valor a Redondear Valor Redondeado
1.723 1.72
1.726 1.73
1.7252 1.72
1.7253 1.73
1.7258 1.72
Ejemplo validaciones
Tipo de Valor Valores

XSD Tag UBL 2.1
comprobante esperado Error
2.1,
Versión base de UBL debe ser
Factura /Invoice/cbc:UBLVersionID UBL 2.1 UBL2.1,
“UBL 2.1”
UBL 2.0
DIAN,
Versión del Formato debe ser
Factura /Invoice/cbc:ProfileID DIAN 2.1 DIAN 2.0,
"DIAN 2.1"
2.0
Número de factura solo puede ZZZ-103,
Factura /Invoice/cbc:ID ZZZ103
contener dígitos y letras ZZZ_103
Esquema de identificación de
algoritmo utilizado para el cáculo CUFE,
Factura /Invoice/cbc:UUID/@schemeName SHA384
del CUFE debe ser uno de los SHA512
permitidos
Ambiente de autorización al que
se destina este documento, debe
Factura /Invoice/cbc:ProfileExecutionID 1, 2 3
contener el código correcto para
indicar si es producción o pruebas
21

6. Catalogo Validaciones CTS
Código
Tipo de
Error Log Tipo
Escenario compro Mensaje de error Aplica para Colombia - Tag XML
Estructur Validación
bante
ado
El archivo tiene “El comprobante: <Nombre del

Precondici una extensión archivo>, no fue procesado. El archivo
ERROR-
ón del diferente a: .txt, Todos tiene una extensión inválida. La Si aplica - No aplica tag XML
VA4
sistema .xml, .zip, .idoc, extensión del archivo debe ser: .txt,
.pdf, .csv .xml, .idoc o .zip.”
“El comprobante con anexos: <nombre

Se detectan
del archivo> no fue procesado. Existen
Precondici archivos anexos
ERROR- archivos anexos a enviar con el
ón del con una extensión Todos Si aplica - No aplica tag XML
VA6 comprobante que tienen extensión
sistema diferente a la
inválida. El comprobante se cargó sin
permitida
los anexos."
En un
comprobante con
anexos (.Zip).
El nombre del
comprobante con
anexos (.zip
"padre") es
diferente al “El comprobante con anexos: <nombre
nombre del del archivo>, no fue procesado. El
Precondici
ERROR- comprobante. nombre del archivo .zip del
ón del Todos Nombre del archivo
VA10 comprobante con anexos debe ser
sistema
Esta validación igual al nombre del comprobante (.txt o
aplica solo si a .xml) que va contenido en el .zip.”
nivel de empresa
el parámetro
"Requiere
Renombramiento
de Archivos:"
está configurado
en "No"
Cuando se intenta
Precondici "El comprobante: <nombre del
ERROR- cargar un archivo
ón del Todos archivo>, no fue procesado. El archivo Si aplica - No aplica tag XML
VA15 con contenido
sistema se encuentra vacío."
vacío, tamaño=0.
Validación del
tamaño máximo
de un archivo.
Según:
XML-> 2MB "El comprobante: <Nombre del
Precondici PDF-> 2MB archivo>, no fue procesado. El tamaño
ERROR-
ón del TXT-> 1KB Todos del archivo <Formato archivo> no es Si aplica - No aplica tag XML
VA18
sistema válido, el tamaño máximo permitido es
<Peso máximo <Peso máximo permitido>.”
permitido>xForma
to: peso
configurable por
desarrollo.
22

En un
comprobante con
anexos (.Zip).
El nombre del
comprobante con
anexos (.zip
"padre") es
diferente al
nombre de los “El comprobante: <nombre del
Precondici archivos archivo>, no fue procesado. El nombre
ERROR-
ón del contenidos. Todos del archivo .ZIP del comprobante debe Nombre del archivo
VA23
sistema ser igual al nombre de los archivos
Esta validación contenidos.”
aplica solo si a
nivel de empresa
el parámetro
"Requiere
Renombramiento
de Archivos:"
está configurado
en "No"
“El comprobante: <nombre del archivo>

En un no fue procesado. El .ZIP enviado
comprobante .ZIP contiene más de un archivo con la
Precondici
ERROR- cargado, se envía misma extensión.
ón del Todos Si aplica - No aplica tag XML
VA24 más de un archivo Recuerde el .ZIP debe contener un solo
sistema
.txt, .xml, .txt, archivo de cada una de las siguientes
.idoc, o .zip. extensiones: .txt, .xml, .pdf, .idoc, .zip
según lo acordado con el receptor.”
El archivo no
puede ser
Precondici Error en el proceso de
ERROR- transformado “<Errror devuelto por el mapa de
ón del Todos transformación, corresponde a
VA0 porque ocurrió un transformación>”.
sistema errores del mapa.
error al realizar la
transformación.
Se envía
documento en el
campo ENC_4
con versión UBL
diferente a la
configurada para
la empresa.
Ejemplo: "El comprobante: <nombre del

Precondici 1. Empresa archivo>, no fue procesado. El archivo Versión UBL del documento
ERROR-
ón del configurada con Todos que se está enviando a procesar no /raíz del
VA68
sistema UBL 2.1 y se corresponde a la versión UBL esquema/cbc:UBLVersionID
envía documento configurada para la empresa."
con campo
ENC_4="2.0"
2. Empresa
configurada con
UBL 2.0 y se
envía documento
con campo
ENC_4="2.1"
23

Fecha de emisión:
Fecha de registro El comprobante: <Nombre del archivo>
del evento a fue procesado con notificación.
efectos fiscales IssueDate del evento no puede ser
Considerando Applica anterior al IssueDate / IssueTime del
[ERROR- /ApplicationResponse/cbc:I
Normativa zona horaria de tionRes documento referenciado. Campo
AAD09] ssueDate
Colombia: ponse Estándar CarvajalTyS: "<Identificador
Rechazo: no de registro + No. Campo>". Campo
puede ser anterior XML UBL: /ApplicationResponse/cbc:I
al documento ssueDate
referenciado
Solamente puede El comprobante: <Nombre del archivo>

haber una fue procesado con notificación. Más de
ocurrencia de un un grupo UBLExtension conteniendo el
grupo grupo sts:DianExtensions Campo …//ext:UBLExtensions/ext:UBLExte
[ERROR-
Normativa UBLExtension Invoice Estándar CarvajalTyS: "<Identificador nsion/ext:ExtensionContent/sts:Dian
FAB03]
conteniendo el de registro + No. Campo>". Campo Extensions
grupo XML UBL:
sts:DianExtension /Invoice/ext:UBLExtensions/ext:UBLExt
s ension
El comprobante: <Nombre del archivo>

Fecha de inicio de no fue procesado. Fecha de emisión
la información de anterior al la fecha de inicio de la
autorización para resolución para la autorización de la
la numeración numeración StartDate > IssueDate …//ext:UBLExtensions/ext:UBLExte
[ERROR- debe ser anterior Campo Estándar CarvajalTyS: nsion/ext:ExtensionContent/sts:Dian
Normativa Invoice
FAB07a] o igual a la fecha "<Identificador de registro + No. Extensions/sts:InvoiceControl/sts:A
de la emisión de Campo>". Campo XML UBL: uthorizationPeriod/cbc:StartDate
la factura …//ext:UBLExtensions/ext:UBLExtensio
(solamente para n/ext:ExtensionContent/sts:DianExtensi
facturas) ons/sts:InvoiceControl/sts:Authorization
Period/cbc:StartDate

Fecha final de la no fue procesado. Fecha de emisión
resolución de posterior al la fecha final de la
autorización para resolución para la autorización de la
la numeración numeración EndDate < IssueDate …/ext:UBLExtensions/ext:UBLExten
[ERROR- debe ser posterior Campo Estándar CarvajalTyS: sion/ext:ExtensionContent/sts:Dian
Normativa Invoice
FAB08a] o igual a la fecha "<Identificador de registro + No. Extensions/sts:InvoiceControl/sts:A
de la emisión de Campo>". Campo XML UBL: uthorizationPeriod/cbc:EndDate
la …/ext:UBLExtensions/ext:UBLExtensio
factura(solamente n/ext:ExtensionContent/sts:DianExtensi
para facturas) ons/sts:InvoiceControl/sts:Authorization
Period/cbc:EndDate
24

no fue procesado. UBLVersionID : no
Versión base de
[ERROR- contiene el literal “UBL 2.1” Campo
Normativa UBL debe ser Invoice /Invoice/cbc:UBLVersionID
FAD01] Estándar CarvajalTyS: "<Identificador
“UBL 2.1”
de registro + No. Campo>". Campo
XML UBL: /Invoice/cbc:UBLVersionID

no fue procesado. ProfileID : no
Versión del
[ERROR- contiene el literal “DIAN 2.1” Campo
Normativa Formato debe ser Invoice /Invoice/cbc:ProfileID
FAD03] Estándar CarvajalTyS: "<Identificador
“DIAN 2.1”
XML UBL: /Invoice/cbc:ProfileID
Ambiente de El comprobante: <Nombre del archivo>

autorización al no fue procesado. ProfileExecutionID
que se destina no indica un valor válido para ambiente
este documento, de destino del documento (1=
[ERROR-
Normativa debe contener el Invoice Producción ; 2= Prueba) Campo /Invoice/cbc:ProfileExecutionID
FAD04]
código correcto Estándar CarvajalTyS: "<Identificador
para indicar si es de registro + No. Campo>". Campo
producción o XML UBL:
pruebas /Invoice/cbc:ProfileExecutionID

no fue procesado. No se permiten
Número de
caracteres adicionales como espacios
[ERROR- factura solo puede
Normativa Invoice o guiones Campo Estándar /Invoice/cbc:ID
FAD05a] contener dígitos y
CarvajalTyS: "<Identificador de registro
letras
+ No. Campo>". Campo XML UBL:
/Invoice/cbc:ID
Valida rango
inferior de
numeración
otorgado
/Invoice/cbc:ID >
no fue procesado. Número de factura
=
es inferior al número inicial del rango
[ERROR- /Invoice/ext:UBLE
Normativa Invoice de numeración autorizado Campo /Invoice/cbc:ID
FAD05b] xtensions/ext:UBL
Estándar CarvajalTyS: "<Identificador
Extension/ext:Ext
ensionContent/sts
XML UBL: /Invoice/cbc:ID
:DianExtensions/s
ts:InvoiceControl/s
ts:AuthorizedInvoi
ces/sts:From

Número de
no fue procesado. Número de factura
factura debe estar
no esta contenido en el rango de
[ERROR- contenido en el
Normativa Invoice numeración autorizado Campo /Invoice/cbc:ID
FAD05d] rango de
Estándar CarvajalTyS: "<Identificador
numeración
autorizado.
XML UBL: /Invoice/cbc:ID
25

Identificador del fue procesado con notificación. No fue
algoritmo utilizado utilizado o informado uno de los
[ERROR- para el cáculo del algoritmos permitidos para el cálculo
Normativa Invoice /Invoice/cbc:UUID/@schem eName
FAD08] CUFE. Debe del CUFE. Campo Estándar
contener el literal CarvajalTyS: "<Identificador de registro
“CUFE-SHA384” + No. Campo>". Campo XML UBL:
/Invoice/cbc:UUID/@schem eName
Valida fecha de
emisión no sea El comprobante: <Nombre del archivo>
posterior a 10 fue procesado con notificación. La
días de la fecha fecha de emisión no puede ser
[ERROR- actual posterior a 10 días calendario de la
Normativa Invoice /Invoice/cbc:IssueDate
FAD09d] /Invoice/cbc:Issue fecha actual Campo Estándar
Date de debe ser CarvajalTyS: "<Identificador de registro
>= fecha + No. Campo>". Campo XML UBL:
calendario + 10 /Invoice/cbc:IssueDate
días

fue procesado con notificación. Código
La factura debe de tipo de factura inválido Campo
[ERROR-
Normativa ser de uno de los Invoice Estándar CarvajalTyS: "<Identificador /Invoice/cbc:InvoiceTypeCo de
FAD12a]
tipos permitidos. de registro + No. Campo>". Campo
XML UBL: /Invoice/cbc:InvoiceTypeCo
de
Divisa aplicable a
toda la factura
fue procesado con notificación. Código
debe estar
[ERROR- de divisa inválido Campo Estándar /Invoice/cbc:DocumentCurr
Normativa definida en el Invoice
FAD15a] CarvajalTyS: "<Identificador de registro encyCode
estándar
internacional ISO
/Invoice/cbc:DocumentCurr encyCode
4217

El número fue procesado con notificación.
declarado de LineCountNumeric : diferente del
líneas de la número de ocurrencias del grupo
[ERROR-
Normativa factura debe Invoice /Invoice/cac:InvoiceLine Campo /Invoice/cbc:LineCountNum eric
FAD16]
corresponder al Estándar CarvajalTyS: "<Identificador
número de grupos de registro + No. Campo>". Campo
InvoiceLine XML UBL: /Invoice/cbc:LineCountNum
eric

fue procesado con notificación.
Algoritmo utilizado para el cáculo del
Identificador del CUFE con corresponde a lo esperado …//cac:AdditionalDocument
[ERROR-
Normativa esquema de Invoice Campo Estándar CarvajalTyS: Reference/cbc:UUID/@sche
FAI04]
identificación "<Identificador de registro + No. meName
Campo>". Campo XML UBL:
…//cac:AdditionalDocument
Reference/cbc:UUID/@sche meName
26

Régimen al que
Régimen informado por emisor no
pertenece el
valido según lista Campo Estándar …//cac:AccountingSupplierP
[ERROR- emisor debe estar
Normativa Invoice CarvajalTyS: "<Identificador de registro arty/cac:Party/cac:PartyTax
FAJ27] dentro de lista Ver
+ No. Campo>". Campo XML UBL: Scheme/cbc:TaxLevelCode
lista de valores
…//cac:AccountingSupplierP
posibles en 6.2.4
arty/cac:Party/cac:PartyTax
Scheme/cbc:TaxLevelCode

Prefijo de la fue procesado con notificación. El
facturación usada prefijo debe existir y corresponder al
para el punto de código de la sucursal de este punto de
…//cac:AccountingSupplierParty/ca
[ERROR- venta. Valida que facturación Campo Estándar
Normativa Invoice c:Party/cac:PartyLegalEntity/cac:Co
FAJ50] Prefix sea igual a CarvajalTyS: "<Identificador de registro
rporateRegis trationScheme/cbc:ID
código de + No. Campo>". Campo XML UBL:
sucursal Se debe …//cac:AccountingSupplierParty/cac:Pa
validar que exista rty/cac:PartyLegalEntity/cac:Corporate
Regis trationScheme/cbc:ID
El método de
pago debe estar
relacionado en la El comprobante: <Nombre del archivo>
tabla del 6.3.4.1. fue procesado con notificación. Método
[ERROR- Rechazo si el de pago inválido Campo Estándar
Normativa Invoice /Invoice/cac:PaymentMean s/cbc:ID
FAN02] valor de este CarvajalTyS: "<Identificador de registro
elemento no + No. Campo>". Campo XML UBL:
corresponde a un /Invoice/cac:PaymentMean s/cbc:ID
valor de la
columna “Código”
El medio de pago
debe estar El comprobante: <Nombre del archivo>
relacionado con la fue procesado con notificación. Medio
tabla 6.3.4.2 de pago inválido Campo Estándar
[ERROR- /Invoice/cac:PaymentMean
Normativa Obligatorio si la Invoice CarvajalTyS: "<Identificador de registro
FAN03a] s/cbc:PaymentMeansCode
/Invoice/cac:Paym + No. Campo>". Campo XML UBL:
entMeans/cbc:ID /Invoice/cac:PaymentMean
corresponde a s/cbc:PaymentMeansCode
Contado

El medio de pago fue procesado con notificación. Medio
debe ser de pago no informado Campo
[ERROR- /Invoice/cac:PaymentMean
Normativa informado para Invoice Estándar CarvajalTyS: "<Identificador
FAN03b] s/cbc:PaymentMeansCode
facturas de de registro + No. Campo>". Campo
contado XML UBL: /Invoice/cac:PaymentMean
s/cbc:PaymentMeansCode
27

Fecha de
vencimiento de la
factura o fecha de El comprobante: <Nombre del archivo>
compromiso de fue procesado con notificación. Venta a
pago Obligatorio crédito sin información de fecha en la
[ERROR- si es venta a cual ese comprometio el pago Campo /Invoice/cac:PaymentMean
Normativa Invoice
FAN04] crédito Rechazo: Estándar CarvajalTyS: "<Identificador s/cbc:PaymentDueDate
Si de registro + No. Campo>". Campo
PaymentMeans/ID XML UBL: /Invoice/cac:PaymentMean
=2y s/cbc:PaymentDueDate
PaymentDueDate
no es informado
Indica que el
elemento es un
Cargo o un
ChargeIndicator contiene información
descuento
[ERROR- diferente de “true” o “false” Campo …//cac:AllowanceCharge/
Normativa Rechazo: Si este Invoice
FAQ03] Estándar CarvajalTyS: "<Identificador cbc:ChargeIndicator
elemento contiene
una información
XML UBL: …//cac:AllowanceCharge/
diferente de “true”
cbc:ChargeIndicator
o “false”
Valor total del

cargo o descuento
Valor numérico
del Cargo el
Descuento Si es
descuento, no
puede ser
superior al valor
Descuento superior al valor base
[ERROR- base Rechazo: Si …//cac:AllowanceCharge/
Normativa Invoice Campo Estándar CarvajalTyS:
FAQ07] …//AllowanceCha cbc:Amount
"<Identificador de registro + No.
rge/cbc:Ch
argeIndicator es
…//cac:AllowanceCharge/ cbc:Amount
true y
…//AllowanceCha
rge/cbc:A mount >
…//AllowanceCha
rge/cbc:Ba
seAmount
Solamente puede El comprobante: <Nombre del archivo>

existir un grupo de fue procesado con notificación. Existe
campos para más de un grupo con información de
[ERROR- información de totales para un mismo tributo en la
Normativa Invoice /Invoice/cac:TaxTotal
FAS01a] totales factura Campo Estándar CarvajalTyS:
relacionadas con "<Identificador de registro + No.
un tributo en Campo>". Campo XML UBL:
particular /Invoice/cac:TaxTotal
Valida que existe

solo un grupo con
fue procesado con notificación. Existe
información de
un grupo /Invoice/TaxTotal para uno de
totales para un
los impuestos s IVA (01), INC (04), ICA
mismo tributo en
(03) sin que exista un grupo
[ERROR- la factura y que
Normativa Invoice /Invoice/cac:InvoiceLine con /Invoice/cac:TaxTotal
FAS01b] los impuestos IVA
información correspondientes al mismo
(01), INC (04),
impuesto. Campo Estándar
ICA (03) deben
existir también en
almenos una línea
/Invoice/cac:TaxTotal
de la factura
28

fue procesado con notificación. Debe
Grupo de ser informado un grupo de estos para
[ERROR- informaciónes que cada tarifa. Campo Estándar ../cac:WithholdingTaxTotal/
Normativa Invoice
FAT04] definen los CarvajalTyS: "<Identificador de registro cac:TaxSubtotal
valores del tributo + No. Campo>". Campo XML UBL:
../cac:WithholdingTaxTotal/
cac:TaxSubtotal
Anticipo Total:
Suma de todos
los pagos
anticipados El
Valor del Anticipo
Total es igual a la
Suma de todos
los anticipos o
prepagos globales
fue procesado con notificación. Valor
aplicados al total
del Anticipo Total es distinto a la Suma
de la factura.
de todos los anticipos o prepagos
Rechazo: Si
[ERROR- globales aplicados al total de la factura. …//cac:LegalMonetaryTotal/cbc:Pre
Normativa (/sig:Invoice/cac:L Invoice
FAU12] Campo Estándar CarvajalTyS: paidAmount
egalMone
"<Identificador de registro + No.
taryTotal/cbc:Prep
aidAmou nt) then
…//cac:LegalMonetaryTotal/cbc:Prepai
round(/sig:Invoice/
dAmount
cac:LegalMonetar
yTotal/cbc:Prepai
d Amount) =
round(sum(/sig:In
voice/cac:
PrepaidPayment/c
bc:PaidAmount))
else true()
Valida Valor total

de la línea. El
Valor Total de la
línea es igual al
producto de
Cantidad x Precio
Unidad menos
Descuentos más
Recargos que
apliquen para la
fue procesado con notificación. Valor
línea.
total de la línea, libre de tributos,
Rechazo:Si
diferente del producto de la cantidad
/Invoice/cac:Invoic
por el precio unitario, considerados los
[ERROR- eLine/cbc Invoice /Invoice/cac:InvoiceLine/cb
Normativa cargos y los descuentos aplicados en
FAV06] :LineExtensionAm Line c:LineExtensionAmount
esta línea Campo Estándar
ount es distinto de
(/Invoice/Price/cbc
:PriceAmount *
/Invoice/cac:InvoiceLine/cb
/Invoice/Price/cbc:
c:LineExtensionAmount
Price/BaseQuantit
y) –
(/Invoice/cac:Invoi
ceLine/cac:Allowa
nceCharge/cbc:A
mount,
correspondientes
a aquellos grupos
en donde
29

/Invoice/cac:Invoic
eLine/cac:Allowan
ceCharge/cbc:Ch
argeIndicator es
“false” o ) +
(/Invoice/cac:Invoi
ceLine/cac:Allowa
nceCharge/cbc:A
mount,
correspondien tes
a aquellos grupos
en donde
AllowanceCharge/
cbc:ChargeIndicat
or es “true”) Nota:
Si se informa el
grupo
InvoiceLine/cac:Pr
icingRefer ence
entonces el valor
de
LineExtensionAm
out es cero (0.00),
ya que se trata de
muestra o regalo
comercial
Solamente puede
existir un grupo de Impuestos retenidos:
campos para /Invoice/cac:WithholdingTaxTotal/ca
información de c:TaxSubtotal/cbc:TaxAmount
[ERROR- no fue procesado. Existe más de un
Normativa totales Invoice
AA31Aa] grupo con información de totales para
relacionadas con /Invoice/cac:WithholdingTaxTotal/ca
un mismo tributo en la factura.
un tributo en c:TaxSubtotal/cac:TaxCategory/cac:
particular (Total TaxScheme/cbc:ID
Retenidos)
Los impuestos Impuestos retenidos linea:

“ReteIVA” o /Invoice/cac:InvoiceLine/cac:Withhol
no fue procesado. Existe un grupo
“ReteFuente” dingTaxTotal/cac:TaxSubtotal/cac:T
/Invoice/TaxTotal para uno de los
deben existir axCategory/cac:TaxScheme/cbc:ID
[ERROR- impuestos “ReteIVA” o “ReteFuente”
Normativa también en por lo Invoice =05, 06
AA31Ab] sin que exista un grupo
menos una línea
/Invoice/cac:InvoiceLine con
de la factura /Invoice/cac:InvoiceLine/cac:Withhol
información correspondientes al mismo
(Determinados dingTaxTotal/cac:TaxSubtotal/cbc:T
impuesto..
retenidos) axAmount
Solamente puede
existir un grupo de
Impuestos línea:
campos para
El comprobante: <Nombre del archivo> /Invoice/cac:InvoiceLine/cac:TaxTot
informaciones
no fue procesado. Existe más de un al/cac:TaxSubtotal/cbc:TaxAmount
[ERROR- relacionadas con
Normativa Invoice grupo con información de totales para
AB08 ] un determinado
un mismo tributo en una línea de la /Invoice/cac:InvoiceLine/cac:TaxTot
tributo en cada
factura. al/cac:TaxSubtotal/cac:TaxCategory
una de las líneas
/cac:TaxScheme/cbc:ID
de la factura
(Impuestos línea)
30

Registro de Evento: ApplicationResponse
Un evento, por contener la firma electrónica de la persona o entidad que lo registra, es

también un Documento Electrónico, que deja constancia verificable sobre lo que esta
persona o entidad declara sobre el documento electrónico a que se refiere.
Tabla de Eventos
Identificador Descripción Responsable por el Registro

001 Uso Autorizado por PA PA
002 Uso Autorizado por la DIAN DIAN
Documento Electrónico Validado por PA, y que Debería
003 DIAN
Haber Sido Rechazado
004 Uso NO Autorizado por la DIAN DIAN
Documento Referenciado no Existe en la Base de Datos de
011 DIAN
la DIAN
030 Acuse de Recibo Receptor de una Factura Electrónica
031 Rechazo de Documento Receptor de una Factura Electrónica
032 Recepción de los Bienes Receptor de una Factura Electrónica
033 Aceptación de Documento Receptor de una Factura Electrónica
Emisor de una Factura Electrónica o
040 Factura Ofrecida para Negociación como Título Valor adquirente de los derechos de crédito de
una Factura Electrónica
Emisor de una Factura Electrónica o
041 Factura Negociada como Título Valor adquirente de los derechos de crédito de
una Factura Electrónica
Relacionamientos Mutuos Entre los Eventos
Impedido por
01 0 2 03 04 011 030 031 032 033 040 041
3.5.4.1. Uso Autorizado por PA
01
3.5.4.2. Uso Autorizado por la DIAN
02
3.5.4.3. Documento Electrónico Validado por PA, y que Debería
Haber Sido Rechazado 03 X X X X X X
3.5.4.4. Uso No Autorizado por la DIAN
04 X X X X X X
3.5.4.5-Documento Referenciado no Existe en la Base de Datos de
la DIAN 011
3.5.4.6. Acuse de recibo
030
3.5.4.7.Rechazo de Documento
031 X X X
3.5.4.8. Recepción de los Bienes
032
3.5.4.9. Aceptación de Documento
033 X
3.5.4.10. Factura Ofrecida para Negociación como Título Valor
040 X
3.5.4.11.Factura Negociada como Título Valor
Impide 041 X
31

Detalles de Cada Evento
Uso Autorizado por PA
Documento electrónico fue validado exitosamente por un Proveedor Autorizado para la
validación de facturas en tiempo real (PA).
Resultado de la aplicación de reglas de validación por el PA, en un documento que no
fue rechazado: pueden existir notificaciones.
Este evento debe ser enviado por el PA al emisor del DE validado, y deberá también ser
enviado por el emisor para el adquirente, en el mismo contenedor del DE.
Responsable por el Registro: PA

Efecto: documento tendrá validez de acuerdo con lo que dispone la Ley 1819, de 29 de
diciembre de 2016, después de que haya sido transmitido para la DIAN por el PA.
Cardinalidad: solamente puede ser registrado uno de estos eventos para un determinado
documento electrónico.
Documento Electrónico Validado por PA, y que Debería Haber Sido Rechazado
Documento electrónico validado exitosamente por un PA, transmitido por este PA para la
DIAN, pero que no cumple satisfactoriamente con todas las validaciones, y que, por lo
tanto, no debiera haber sido validado exitosamente por el PA.
Responsable por el Registro: DIAN

Efectos: Impide el registro de los eventos “Aceptación de Documento” y “Factura
Ofrecida para Negociación como Título Valor”, sin posibilidad de resolución de esta
situación
• PA deberá comunicar el emisor del problema, y el emisor deberá regularizar el
documento.
• PA deberá corregir su aplicación para que no se repita el problema.
Cardinalidad: solamente puede ser registrado uno de estos eventos para un determinado
Uso NO Autorizado por la DIAN
Documento electrónico fue rechazado por la DIAN.

Resultado de la aplicación de reglas de validación por la DIAN, en un documento que fue
rechazado: pueden existir notificaciones.
Este evento debe ser enviado por la DIAN al emisor del DE validado, en el mismo
contenedor del DE.

Efecto: documento NO tiene validez de acuerdo con lo que dispone la Ley 1819, de 29
de diciembre de 2016.
Cardinalidad: Puede ser registrado mas de un evento para un determinado documento
electrónico.
Documento Referenciado no Existe en la Base de Datos de la DIAN

Cardinalidad: Solamente puede ser registrado una vez para un determinado evento.
32

Acuse de recibo
Responsable por el Registro: Receptor

Adquirente declara que ha recibido el documento.
Efecto: Declaración del adquirente de que ha tomado conocimiento de que fue emitido
el documento a su nombre como receptor.
• Perfecciona la expedición del documento.
Restricciones:
• No puede ser registrado para un documento rechazado.
• Solamente puede ser registrado en un documento para el cual existe un evento
“Documento Recibido en la DIAN”.
Cardinalidad: Solamente puede ser registrado uno de estos eventos para un determinado
Rechazo de Documento

Adquirente declara que no acepta el documento.
Efecto: Declaración del adquirente que no reconoce la operación registrada en el
documento, teniendo como resultado un conflicto de declaraciones: del emisor, por las
informaciones registradas en el documento, y del adquirente, que no reconoce su
veracidad.
Impide el registro de los eventos “Aceptación de Documento” y “Factura Ofrecida
para Negociación como Título Valor”, sin posibilidad de resolución de esta situación
Restricciones:
• No puede ser registrado para una factura para la cual existe un evento “Factura
Ofrecida para Negociación como Título Valor”.
Aceptación de Documento

Adquirente informa al emisor que no existen divergencias entre las informaciones
registradas en el documento, con las eventuales correcciones registradas hasta la fecha,
y la operación efectivamente realizada.
Efectos:
A partir del registro del evento:
• No se puede registrar evento de anulación de este documento.
Si el documento es una factura:

• No se pueden emitir notas crédito o notas débito referenciando esta factura.
• Se permite el registro de “Factura Ofrecida para Negociación como Título Valor”.
Observación: Si el documento referenciado es una factura, el registro se extiende a
todas las Notas Crédito y Notas Débito que la referencien.
Restricciones:
• No puede ser registrado para un documento para el cual existe un evento “Documento
Electrónico Validado por PA, y que Debería Haber Sido Rechazado”.
33

Factura Ofrecida para Negociación como Título Valor
Responsable por el Registro: Emisor de una Factura Electrónica o adquirente de los

derechos de crédito de una Factura Electrónica. Emisor de una factura, o adquirente de
los
derechos de título valor de una factura, ofrece estos derechos para negociación.
Restricciones: Solamente puede ser registrado para un documento para el cual existe un
evento “Aceptación de Documento”.
34

7. Configuración
Documentos
Configuración
Si la empresa del receptor tiene activo el parámetro "Habilitar Envío Eventos DIAN 2.1",
significa (Habilitar envio eventos DIAN recepción UBL2.1)
Aplica para receptores CTS
• El Sistema debe completar el XML Application Response Eventos Dian UBL 2-1 del
evento.
• Generar el XML con los datos que correspondan al documento seleccionado, le
coloque el CUFE del documento referenciado, genere el archivo Application
Response con el CUDE, lo firme, lo envíe a la DIAN y recibir la respuesta de la DIAN.
• Actualizar el estado comercial a aceptado/rechazado cuando la DIAN responda
"00=Procesado correctamente", marque la actualización del estado comercial como
tipo "Legal", registre en la auditoria de estados comerciales el nombre del usuario
que ejecutó la acción en el sitio web, realice la entrega del XML Application
Response Eventos Dian UBL 2-1 al emisor si así lo tiene configurado y realice la
entrega del XML Application Response Eventos Dian UBL 2-1 al receptor si así lo
35

tiene configurado (se debe nombrar el documento de acuerdo a lo definido si el
evento fue enviado a la DIAN o es informativo).
• Si la empresa del receptor tiene activo el parámetro "Habilitar 2.1" y evento de
aceptación/rechazo que se generó desde el sitio web es rechazado por la DIAN,
quede registrado y almacenado para que pueda ser consultado por el receptor en
el visor de rechazos Dian del Receptor.
Si la empresa del receptor NO tiene activo el parámetro "Habilitar 2.1":
• el Sistema valide el XML Application Response Eventos Dian UBL 2-1 del evento,
NO lo firme, actualice el estado comercial a aceptado/rechazado, marque la
actualización del estado comercial como tipo "Informativo", registre en la auditoria
de estados comerciales el nombre del usuario que ejecutó la acción en el sitio web,
realice la entrega del XML Application Response Eventos Dian UBL 2-1 al emisor si
así lo tiene configurado y realice la entrega del XML Application Response Eventos
Dian UBL 2-1 al receptor si así lo tiene configurado (se debe nombrar el documento
de acuerdo a lo definido si el evento fue enviado a la DIAN o es informativo
8. Canales
Documentos Canales
Inconvenientes tecnológicos generados por parte de la Unidad Administrativa

Especial Dirección de Impuestos y Aduanas Nacionales – DIAN para la validación
previa de la factura electrónica.
Los facturadores electrónicos y proveedores tecnológicos que utilicen los servicios de

Validación Previa de la Factura Electrónica que la DIAN disponga, podrán establecer
automáticamente el procedimiento de contingencia previsto en la Ley si se cumplen
las siguientes condiciones:
1. Detección del error “500 – Internal Server Error” o “503 – Service Unavailable”.
Únicamente este error.
2. Transmitir nuevamente a la DIAN la factura electrónica de venta para validación
previa transcurridos 20 segundos después de la detección del error “500 – Internal
Server Error” o “503 – Service Unavailable”. Si persiste el error, se deben realizar
dos (2) intentos más, cada uno en intervalo de 20 segundos. Al finalizar la cuarta
transmisión en la que se ha detectado el error, es decir un minuto después de la
transmisión inicial y si persiste la condición de error, el facturador electrónico o
el proveedor tecnológico podrá transmitir directamente al adquirente, la factura
electrónica sin validación previa.
3. Mantener o archivar las evidencias del error “500 – Internal Server Error” o “503 –
Service Unavailable” en sus registros digitales.
36

4. Generar nuevamente la factura electrónica de venta cambiando el contenido
referenciado en la etiqueta InvoiceTypeCode con el valor 04 según la tabla 6.1.3
del anexo técnico manteniendo el mismo prefijo y numero de factura, volver a
firmar la factura electrónica, incluir la factura electrónica sin Application
Response (validación de la DIAN) en un AttachedDocument y entregar al
adquirente.
5. Monitorear la conexión y el sitio web de la DIAN, con el fin de identificar el
restablecimiento del servicio por parte de la DIAN. Transmitir normalmente las
Facturas Electrónicas para Validación Previa, e iniciar la transmisión de las facturas
electrónicas entregadas al adquirente sin validación previa al web service de
contingencia dispuesto por la DIAN.
Nueva Estructura nombramiento Dian Result Documentos.
A continuación, se describe el nombre con el cual se entregan los archivos DianResult

cuando para entregar la respuesta DIAN de validación de un documento por medio
automático.
Estructura de nombramiento:
DIANResult_<código respuesta dian>_nombre archivo original.xml
<código respuesta dian>:

Se asigna el código 00 si el evento fue validado satisfactoriamente por la DIAN. Se
asigna el código 01 si el evento no fue validado satisfactoriamente por la DIAN y la
DIAN retornó código de error.
Ejemplo:
Documento validado satisfactoriamente por la DIAN:
DIANResult_00_factura1.xml
Documento con error al ser validado por la DIAN:

DIANResult_01_factura1.xml
Error en la conexión DIAN:

DIANResult_ER_factura1.xml
Eventos del receptor.
1) Evento Acuse Recibo

DIANResult_AcuRec_<código respuesta dian>_nombre archivo original.xml
<código respuesta dian>: Se asigna el código 00 si el evento fue validado

satisfactoriamente por la DIAN. Se asigna el código 01 si el evento no fue validado
satisfactoriamente por la DIAN y la DIAN retornó código de error.
37

Ejemplo:
Evento validado satisfactoriamente por la DIAN:

DIANResult_AcuRec_00_factura1.xml
Evento con error al ser validado por la DIAN:

DIANResult_AcuRec_01_factura1.xml
2) Evento Aceptación Documento

DIANResult_AceDoc_<código respuesta dian>_nombre archivo original.xml

Ejemplo:

DIANResult_AceDoc_00_factura1.xml

DIANResult_AceDoc_01_factura1.xml
3) Evento Rechazo Documento

DIANResult_RecDoc_<código respuesta dian>_nombre archivo original.xml

Ejemplo:

DIANResult_RecDoc_00_factura1.xml

DIANResult_RecDoc_01_factura1.xml
38

9. Pantillas PDF
Documentos Plantillas
PDF
Impactos en Representación Gráfica
• Las plantillas PDF deben considerar la posición y tamaño del CUFE y CUDE (Notas
Debito y Crédito) debido a que se ha aumentado de 32 Caracteres a 96 caracteres.
• Las plantillas deben soportar el DV para emisor y adquirente.
• Los documentos Nota Debito y Nota Credito deben estar identificado con un Código
Único de Documento Electrónico CUDE.
• Soporte para nuevas tablas (Tipos de documentos de identidad, Incoterms, Códigos
Medios de pago, impuestos, tarifas, estándar productos, entre otros)
39

10. CENF
Documentos CENF
Modificación Visor Emitidos y Recibidos
40

Nuevo Visor de Rechazos Emisión y Recepción (Eventos)
41

Carga de certificado para firmar documentos enviados a la DIAN
Estructura SFTP FECO
La estructura de carpetas de entrada para el servicio de factura electrónica es:
N° IDENTIFICACIÓN DEL EMISOR

Cuenta
IN
OUT
En la carpeta de entradas “IN” se deben generar y ubicar las salidas por tipo de documento
así:
• Solicitudes_Notas: Carpeta para emitir las solicitudes de notas crédito/débito.

• Paquetes: Carpeta para enviar paquetes de comprobantes (.zip).
• Representacion_Grafica: Carpeta para cargar la representación gráfica.
• Socios_Comerciales: Carpeta para cargar para procesamiento el archivo de socios

comerciales.
• Eventos: Carpeta para cargar los XML Application Response de UBL 2.1 para
informar los eventos a la DIAN.
42

Notas:
1. N°IDENTIFICACIÓN DE LA EMPRESA->Para Colombia la identificación es el NIT.
2. Para procesar comprobantes cargados por el “Intermediario Emisor Externo”, el N°
IDENTIFICACIÓN DE LA EMPRESA->Es el Nit del “Intermediario Emisor Externo”
En la carpeta de salidas “OUT” se deben generar y ubicar las salidas por tipo de documento
así:
• Error: Archivo .log y comprobantes/archivos procesados con error. Dentro de la

carpeta de error se debe crear la subcarpeta:
• Socios_Comerciales: Archivos .xslx y .log de socios comerciales procesados con
error.
• Comprobantes: Se entregan XML legal, PDF, Acuse DIAN,
• Dian_Result: Se entrega el XML Dian Result.
• Anexos: Archivo .zip de anexos del comprobante
• Referencias: Para el receptor se entrega el Txt de referencias según las
configuraciones del receptor.
• Aceptación_y_rechazo: Archivo de aceptación y rechazo.
• Acuse_Recibo: Archivo de recibo.
• Informe_pago: Informes de pago generados para el emisor de facturas.
• Comprobantes_físicos: Archivo Excel y PDF de comprobantes físicos recibidos.
• Solicitudes_Notas: Se entregan las solicitudes de notas crédito/débito.
• Response_File: Se entrega el Xml de datos básicos del comprobante.
• Paquetes: Carpeta para recibir el archivo de respuesta del resultado de
procesamiento del paquets de comprobantes (.zip).
• Eventos: Carpeta en la cual se entrega los XML Application Response de UBL 2.1 de
los eventos aprobado por la DIAN.
11. Consideraciones Adicionales

Recepción
Si se tiene un receptor por canal automático, se debe retirar la validación de "Acuse
de Recibo Automático”.
43

Actualización Anexo Técnico SEP 2019
Puntos más relevantes que hemos identificado a la fecha del nuevo anexo técnico que
esta publicado como borrador.
1. Nueva tabla para tipos de documentos, donde se indica que el tipo 93 y 94 son
utilizados para referencias facturas del modelo SIN validación previa (Decreto 2242):
Para la generación de estas notas crédito y débito que afecten facturas electrónicas
diferentes a la versión de validación previa, se manejara los tipos de documentos 93, 94
las cuales no validaran que el numero de la factura y el CUFE referenciados sobre el bloque
BillingReference, esto no excluye que sean informado el bloque BillingReference y los
elementos ID, UUID, IssueDate en la generación del xml.
13.1.7.5. Notas Contables de Naturaluza Crédito/Débito 13.1.7.6. Se incluyen los tipos de
documentos 95 Y 96 con los conceptos de notas contables de naturaleza crédito y débito,
las cuales no afectan bases gravables ni impuestos causados con facturas electrónicas.
Estas notas contables son para eventuales descuentos tipo rebate utilizados en el comercio
por cumplimiento de metas periódicas en ventas, según lo manifestado por el mercado.
No obstante lo anterior, es de recordar que los descuentos que suceden en el momento
de la facturación pueden y deben ser reportados en los grupos de información destinados
para tal fin, según el anexo técnico.
2. Código postal:
Existen varias alternativas según el anexo técnico:
a. Al ser opcional el campo, se podría probar un documento sin código postal. En caso de
no informar los valores de la tabla, se indica que genera notificación y NO un rechazo.
b. La DIAN también menciona que si no se sabe el código postal, se puede enviar el
código del municipio.
c. Existe la opción de un comodín, mientras la DIAN lo vuelve exigible:
44

3. 13.1.7.3. Consumidor final Se genera la modificación para los elementos (XPath):
/Invoice/CreditNote/DebitNote/
cac:AccountingCustomerParty/cac:Party/cac:PartyIdentification
/Invoice/CreditNote/DebitNote/ cac:AccountingCustomerParty/cac:Party/cac:Person
Estas incorporaciones quedarán disponibles para su uso el día 23 de octubre del 2019,
fecha en la cual podrán generar las pruebas en el ambiente de Habilitación. Se
informará en esta fecha “23/10/2019” los elementos que generen rechazo y/o
notificaciones los cuales serán desplegados en producción el 23 de enero del 2020 para
la fiscalización y control por parte de la DIAN.
4. 13.1.6.1.5. Valores comodines:

Se disponen de los siguientes campos comodines:
Nota: Los comodines de los elementos TaxScheme/ID y TaxScheme/Name solo aplican

para los bloque de Emisor, Adquirente y Transportista hasta que sean requeridos como
información obligatoria por la DIAN.
45

12. Información General y Tips
• Se debe informar el Nit y el dígito de verificación. Esto porque las transacciones
se van a permitir entre nits activos en la plataforma. El dígito de verificación
porque se puede dar el caso de que los nits activos son muy parecidos y por eso
uno como emisor se equivoque y le este factrurando a la empresa XZ que tiene un
Nit muy parecido a la empresa ZY, porque solo hay la diferencia de un digito en el
nit y resulta que ambas empresas están activas en el rut y la única manera de
asegurar el nit correcto es por el dígito de verificación para saber que el NIt es el
correcto y se pueda proteger la información.
• Si el adquiriente no es responsable (no tiene NIT) la información de dirección no

es obligatoria.
• Información de pagos: Debe ser informado porque habilita la entrada al factoring

electrónico, se debe informar si la transacción es de contado o crédito, si es de
contado debe informar la forma de pago (efectivo, trajeta, etc) si es a crédito es
una de las condiciones para poderse pasar al título valor y no debe de informar la
forma de pago porque no se conoce, lo que se debe informar es cuando vence la
factura y pasa a ser obligatorio el campo "Fecha de pago (Fecha en la cual es
pagamento es debido)" - MEP_3.
• Los descuentos que afectan la base gravable se deben informar a nivel de ítem.
Estos descuentos no van codificados.
• Los descuentos que no afectan las bases gravables van a nivel de factura,
(descuentos de temporada, descuento de volumen) un cambio importante es que
van codificados a nivel de factura porque hay casos en donde regalo algo en un
ítem y este regalar algo me causa el impuesto de un iva y generalmente lo que
hace el emisor es que lo asume, entonces desde las tipificaciones de los descuentos
hay uno que dice descuento por impuesto asumido. Cuando se da este caso en que
regalo un ítem se debe causar el impuesto del ítem y el emisor puede asumir el
impuesto haciendo un descuento por impuesto asumidos y cuando se netea da los
valores de la factura y queda todo registrado como debe.
• Los impuestos se deben informar a nivel de ítem cuando aplique y aplica cuando
se genere un tributo a nivel de ítem. Se debe informar un grupo de taxtotal por
cada impuesto, esto es importante porque no se pueden mezclar impuestos. Se
debe tener un taxtotal para IVA, Otro para ICA, etc; y si yo tengo ventas con
diferentes tarifas lo que hago es que en los subtotales se hace un subtotal por cada
tarifa, de tal manera que en el Taxtotal solo tengo IVA y adentro (subtotal) tengo
todas las tarifas de IVA y ahí me da mi suma.
• Impuestos retenidos, se envían en el WithholdingTaxTotal del xml. Para diferenciar

las retenciones de lo que no se retiene (otros tipos de cobros) y se debe utlizar
cuando el emisor es autoretenedor. El manejo debe ser igual que de los impuestos;
46

es decir, se debe informar un grupo de WithholdingTaxTotal por cada impuesto
retenido, esto es importante porque no se pueden mezclar impuestos retenidos.
Se debe tener un WithholdingTaxTotal para ReteIVA, otro para ReteFuente, otro
para ReteICA. Si yo tengo ventas con diferentes tarifas lo que hago es que en los
subtotales se hace un subtotal por cada tarifa, de tal manera que en el
WithholdingTaxTotal solo tengo RETEIVA y adentro (subtotal) tengo todas las
tarifas de RETEIVA y ahí me da mi suma.
• Para algunos impuestos como IVA, Impuesto Nacional al Consumo, retefuente,

reteiva se colocaron las listas de valores. Es importante se revisen esas listas de
valores porque si se reporta una tarifa diferente a las que se tienen en la tabla de
la DIAN esa factura se va a rechazar hasta que la Dian no ajuste la lista de valores.
• Elementos adicionales para tributos nominales. El caso más genérico es el de las

bolsas plásticas es un impuesto al consumo que está expresado en pesos; los
combustibles tienen todos sus impuestos por galón y así hay varias cosas en el
estatuto que aplican por unidad y van a aprecio nominal; entonces se ha creado
ahí unos grupos de información donde me dice cuál es la medida base del tributo
y el valor. Esa unidad de medida base por la unidad por el valor, es como se debe
hacer el cálculo y es simplemente para diferenciar los temas de tarifa porcentual
a valores nominales para no tener problemas.
• Los cálculos están formulados en el anexo, básicamente lo que se tiene es que el

valor bruto más toda su materia de impuestos, menos los anticipos, menos los
descuentos más los cargos, y eso me da el valor a pagar y se tiene unas reglas de
margen porque se sabe que los cálculos no van a cuadrar de una en diferencia cero,
entonces la idea es usar el tema de cuadre dentro del margen establecido.
• Obligatorio, todos los ítems que causen un impuesto debe reportarse en el ítem los
impuestos.
• Los bienes y servicios excluidos no llevan taxtotal. Los bienes exentos llevan
taxtotal con una tarifa cero.
• Se debe incluir la información del mandante si aplica y se debe enviar a nivel del
item la información del mandante.
• Se incluye campos comodín en formato llave- valor(INFORMACIÓN ESPECÍFICA DEL
ÍTEM - IEI). Es para información comercial complementaria que no necesariamente
cabe en la sección del ítem y que es necesaria darle una estructura. Entonces esta
estructura lo soporta. Por ejemplo, en los vehículos se debe reportar todo lo que
dice la tarjeta de propiedad: placa, chasis del motor, etc. lo que permite estos
campos es que se pone en la llave Placa y en el valor se pone XSC987. Se puede
enviar tantos datos de detalle como sean necesarios.
47

Para artículos gratis
Regalos, se debe informar el precio de referencia cac:prinicingreference donde va
el precio unitario del ítem que se está regalando, que es el que sirve para sacar la
base gravable del impuesto.
o Se debe detallar la cantidad (ITE_3)

o En el precio se coloca valor Unitario (ITE_7) cero,
o ITE_5 debe ser cero.
o Se debe diligenciar el registro "PRECIOS ADICIONALES - IPA" especificando en
el IPA_1 el tipo de precio "01" - "Valor comercial" y colocar el valor comercial
del ítem que se está dando como obsequio.
o Para los impuestos, la base imponible no debe ser cero “IIM_4”. Para calcular
los impuestos se debe tomar como base imponible “IIM_4”: Cantidad (ITE_3) x
Precio Referencial Unidad (valor comercial del ítem "IPA_2) menos Descuentos
más Recargos que apliquen para la línea.
o El total de la línea va a ser el total que es cero, más el impuesto.
o Si es solo un ítem, el valor de la factura “TOT_5” sería solo el valor del
impuesto.
• Código en Ítem. Se debe informar un código de producto, para lo cual el emisor

tiene 4 opciones (solo debe informar 1 opción no las 4):
o Lista de compra eficiente, que es la tabla de orden para bienes o servicios

o Gtn, que es e código de barras
o Partida arancelaria, este es opcional par todos los emisores excepto cuando la
factura sea de exportación que se vuelve obligatorio informar el código
arancelario que se está vendiendo en la exportación
o código propio. Seguramente muchas facturas llegaran con código propio pero
se busca estándarizar los códigos y a futuro eliminar esta 4ta opción y se utilice
algo estándar.
• Ambiente. Producción y pruebas. Estando en ambiente de producción puedo probar

si una factura va a pasar o no en el ambiente de producción, es una versatilidad
adicional de está versión 2. De tal manera que no se generen rechazos innecesarios
al momento de hacer su operación sino que permita hacer los ajustes necesarios
antes de tiempo. Todos los datos deben ser reales, no se deben inventar el número
de factura o va a generar rechazo. No se debe usar para envíos masivos, para
probar de vez en cuando.
Ejemplos xls en la caja de herramientas:

• Caso genérico: Es el que más aplica a todos los sectores, se tiene como se deben
reportar los ítems que están gravados, ejemplo de ítem excluído, ítems como
muestra comercial o regalo, descuentos a nivel de ítem que afectan la base
gravable, los cargos gravados los cuales se deben reportar como ítems, un impuesto
48

de las bolsas plásticas, descuentos a nivel de factura, cargos a nivel de factura y
todos los totales.
• Estos son ejemplos de como reportar la información según los casos, pero si los
casos de ejemplos se deben mezclar la empresa emisor es responsable que se
reporte bien. Son ejemplos de como se debe reportar la información según el caso
de negocio.
• El ítem excluido no tiene impuestos, ni a nivel de ítem ni a nivel de factura.
• Para los exentos se debe informar el taxtotal con valor de tributo en 0.00. Debe ir
a nivel de item y a nivel de factura.
Caso contratos AIU
• A nivel de ítem se deben informar los conceptos que sumados den el valor completo
del contrato.
• El concepto AIU o Utilidad reporta el grupo de impuestos, con base normatividad
vigente.
• Debe informar 2 ítems, el ítem 1 es lo que está sin impuestos la parte excluida y
el concepto de utilidad dependiendo el tipo de contrato y el ítem 2 con su
respectiva base gravable y con las normas que aplican al estatuto tributo que es
el 10% del valor más el consumo de las 2 cosas y eso me debe dar el total.
49

Entendemos la tecnología y la transformamos en una
solución para usted
50

FECO - Guía Implementación Cambio Normativo 2019 v1.3

Cargado por

Copyright:

Formatos disponibles

FECO - Guía Implementación Cambio Normativo 2019 v1.3

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

FECO - Guía Implementación Cambio Normativo 2019 v1.3

Cargado por

Copyright:

Formatos disponibles

Factura Electrónica

Ganas el tiempo que no quieres perder, cuando compartes

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

Consideraciones para el Modelo de Emisión con Validación Previa. En verde se

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

Consideraciones importantes RESOLUCIÓN 000030 DE ABRIL 29 2019

Articulo2. Requisitos Factura Electrónica de Venta: La factura electrónica de venta

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

CAPÍTULO V, Artículo 8, Parágrafo 3

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

La validación de la factura electrónica de venta se realizará atendiendo los siguientes

a) Validación Previa de la factura electrónica de venta: Una vez generado u

Inconvenientes de Tipo Tecnológico Relacionados con la Factura Electrónica

Medidas en caso de inconvenientes tecnológicos. El facturador electrónico, los

1. Inconvenientes tecnológicos presentados por parte del facturador electrónico y/o el

El facturador electrónico y/o proveedor tecnológico según el caso, deberán atender

a) Por el tiempo en que dure el inconveniente, expedir factura de venta de

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

2. Inconvenientes tecnológicos presentados por parte del adquiriente que recibe la

a) El adquiriente deberá informar al facturador electrónico, quien pondrá a

b) En ningún caso, los eventuales daños en el sistema y/o equipos informáticos

c) Los facturadores que a la entrada en vigencia de la presente resolución

3. Inconvenientes de tipo tecnológicos de la Unidad Administrativa Especial Dirección

Cuando por inconvenientes tecnológicos no haya disponibilidad del servicio

Recomendaciones para uso de Anexos Técnicos

2. Se han especificado grupos y elementos de UBL adicionales a los que se trabajan

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

c) cac:AdittionalPropertyItem, para informar características de un ítem en

d) En el grupo cac:TaxTotal, se han agregado dos elementos,

e) Se han perfeccionado las tablas de valores, de tal manera que se facilite la

f) Se ha fortalecido la malla de validaciones para mejorar la consistencia de la

• Total Campos disponibles por tipo para UBL 2.1

Tipo Campo Cant

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

Campo nuevo mandatorio para UBL2.1

Consideraciones para el Estandar 4.0 con soporte para UBL2.1:

• El Archivo del Estandar conserva los segmentos, campos, descripciones y

Campos Nuevos Obligatorios y Dependientes:

ENC Mandatorio 1 21 AN 4 Indicador del tipo de operación

Digito de verificación -DV del NIT del emisor

Código del municipio.

Código del Departamento

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios

DFE Dependiente 1 4 AN 10 Código postal

GTE Mandatorio 1 1 AN 10 Identificador del tributo

GTE Mandatorio 1 2 AN 30 Nombre del tributo

Nombre registrado en el RUT. Si el adquirente es

GTA Mandatorio 1 1 AN 10 Identificador del tributo

GTA Mandatorio 1 2 AN 30 Nombre del tributo

Nombre o Razón Social de la persona o entidad

ITT Dependiente 1 2 AN 7 Obligaciones del transportardor

ITT Dependiente 1 3 AN 2 Régimen al que pertenece el transportador

ITT Dependiente 1 4 AN 12 Identificador del tranportador.

Tipo de documento de identificación. Tipo de

Descripción de la naturaleza de la corrección. Tamaño

ITE Mandatorio 27 N 6 La cantidad real sobre la cual el precio aplica.

Información Confidencial // No reproducir sin autorización especial de Carvajal Tecnología y Servicios