API de Facturación Electrónica Integración Fiscal Directa DIAN
Genera, valida y transmite facturas electrónicas directamente con la DIAN sin intermediarios. SIIVRO automatiza XML UBL 2.1, firma digital XAdES-EPES, numeración y cálculo de impuestos (IVA, retefuente, reteICA) a partir del RUT, la resolución y la configuración fiscal del tenant.
Qué significa facturar electrónicamente en Colombia
La DIAN exige que toda factura de venta sea emitida en formato UBL 2.1, firmada digitalmente con un certificado XAdES-EPES de entidad certificadora autorizada, y validada por el WebService oficial antes de ser entregada al receptor. No es opcional y no admite simplificaciones.
Para un desarrollador esto implica: construir XML estructurado, aplicar firma criptográfica, calcular impuestos según actividad económica, consumir SOAP/XML de la DIAN, manejar reintentos y procesar el ApplicationResponse. Son semanas de trabajo especializado.
Sin SIIVRO
Construir XML UBL 2.1 manualmente
Gestionar certificado XAdES-EPES
Calcular IVA / ReteFuente / ReteICA
Consumir SOAP de la DIAN
Manejar reintentos y timeouts
Procesar ApplicationResponse
Mantener según cambios DIAN
Con SIIVRO
Envías JSON con datos de negocio
SIIVRO gestiona el certificado
Motor fiscal automático por tenant
REST sobre HTTPS, no SOAP
Reintentos y colas internas
CUFE + PDF + XML en el response
Actualizaciones DIAN sin código
El principio de SIIVRO: el cliente envía datos de negocio. SIIVRO resuelve la complejidad fiscal. El desarrollador nunca toca XML, firma ni SOAP.
Sección 02
Flujo completo end-to-end
Desde el registro de la empresa hasta la descarga del PDF firmado.
01
Registro de empresa (tenant)Setup
Alta de la empresa en SIIVRO. Cada empresa es un tenant independiente con su configuración fiscal.
02
Carga de RUT y resolución DIANSetup
Se sube el RUT de la empresa y la resolución de facturación electrónica vigente (número, rango, vigencia).
03
Configuración fiscal automáticaAutomático
SIIVRO extrae del RUT: actividad económica, régimen tributario, ciudad, tarifas de ICA y retenciones aplicables.
04
Creación de factura vía APITu código
Tu backend llama POST /V2/invoices con los datos del cliente, ítems y tipo de documento. Sin XML, sin impuestos manuales.
05
Procesamiento interno SIIVROAutomático
SIIVRO construye el XML UBL 2.1, calcula impuestos, aplica la firma XAdES-EPES y prepara la transmisión.
06
Transmisión y validación DIANDIAN
SIIVRO envía el XML al WebService de la DIAN y espera el ApplicationResponse de aceptación o rechazo.
07
Respuesta con CUFE y documentosResponse
Tu backend recibe status, cufe, pdf_path, xml_path y qr_code. La factura tiene validez legal inmediata.
08
Corrección con nota crédito (si aplica)Corrección
Si hay error en la factura aceptada, se emite un tipo 91 referenciando la factura original. No hay eliminaciones.
09
Consulta y descargaConsulta
Consulta el estado de cualquier factura con GET /V2/invoices/{id}. Descarga PDF y XML firmado cuando lo necesites.
Sección 03
Arquitectura multi-tenant
Cada empresa registrada en SIIVRO opera como un tenant independiente. El aislamiento fiscal entre empresas es total: resolución propia, numeración propia, configuración fiscal propia y certificados propios.
Por tenant
—Resolución DIAN propia
—Rango de numeración propio
—Certificado digital
—Tarifas de impuestos
Para SaaS
—Una integración, N clientes
—Cada cliente factura de forma aislada
—Sin contaminación de datos
—API Key única por tenant
Para ERP
—Una empresa por instancia
—Múltiples resoluciones vigentes
—Facturación interna contable
—Control por centro de costo
Sección 04
Tipos de documento soportados
La DIAN define el tipo de documento en el campo document_type. Cada tipo tiene reglas fiscales y estructurales distintas.
01Factura electrónica de venta
Ventas normales B2B y B2CObligatorio para obligados a facturar electrónicamenteDocumento principal ante la DIAN
02Factura de venta de papel
Contingencia cuando el sistema electrónico no está disponibleFacturación fuera del sistema electrónico temporal
NO reemplaza la factura electrónica. Debe ser reportada posteriormente a la DIAN. Tiene implicaciones fiscales si no se regulariza.
91Nota crédito
Corrección de una factura previamente emitidaAnulación parcial o total de una ventaDevolución de mercancía o descuentos posteriores
Es el único mecanismo válido para corregir una factura aceptada.
92Nota débito
Ajustes adicionales sobre una factura existenteCobros adicionales no incluidos en la factura original
95Documento soporte
Compras a proveedores no obligados a facturar electrónicamenteRegistro de costos y deducciones ante la DIAN
96Nota de ajuste
Corrección de documentos soporte (tipo 95)Reversiones de registros de compra
Sección 05
Cálculo automático de impuestos
SIIVRO calcula los impuestos automáticamente a partir de la configuración del tenant (RUT, actividad económica, ciudad). El desarrollador no necesita implementar ninguna lógica fiscal manual. Solo envía el precio base y la tasa de IVA del ítem.
IVAImpuesto al Valor Agregado
→Tarifa general: 19%
→Bienes exentos: 0%
→Servicios excluidos: N/A
→Determinado por item/servicio
Fuente: Configurado por ítem en el request
ReteFuenteRetención en la Fuente
→Depende actividad económica
→Depende tipo de cliente (persona/empresa)
→Aplica solo si supera base mínima
→SIIVRO calcula y aplica automático
Fuente: Extraído del RUT y tipo de cliente
ReteICARetención de ICA
→Varía por ciudad del comprador
→Varía por actividad económica
→Solo aplica a personas jurídicas
→SIIVRO calcula por tarifa municipal
Fuente: Extraído del RUT y ciudad del cliente
Resultado: tú envías price: 100000 y tax_rate: "19.00". SIIVRO calcula IVA, aplica retenciones según el perfil del cliente y entrega los totales correctos a la DIAN.
Sección 06
Campos del request qué es obligatorio y qué resuelve SIIVRO
Campo
Tipo
Estado
Descripción
document_type
string
Obligatorio
Tipo de documento DIAN: 01, 91, 92, 95, 96. Define la estructura fiscal del documento.
external_id
string
Recomendado
Identificador único interno de tu sistema. Garantiza idempotencia: si se repite, SIIVRO retorna el resultado original sin crear duplicado.
resolution_number
string
Automático
SIIVRO inyecta la resolución activa del tenant. No la envías en el request.
customer.identification
string
Obligatorio
NIT o cédula del cliente. La DIAN valida su existencia en el RUT.
customer.name
string
Obligatorio
Razón social o nombre completo del cliente.
customer.dv
string
Recomendado
Dígito de verificación del NIT. Si no se envía, SIIVRO lo calcula.
customer.email
string
Opcional
Si se incluye, SIIVRO envía el PDF automáticamente al correo del cliente.
items[].description
string
Obligatorio
Descripción del bien o servicio. Aparece en el PDF y en el XML.
items[].quantity
number
Obligatorio
Cantidad. Puede ser decimal para servicios fraccionados.
items[].price
number
Obligatorio
Precio unitario antes de impuestos. Debe ser mayor a 0.
items[].tax_rate
string
Obligatorio
Tasa de IVA aplicable: 19.00, 5.00 o 0.00 según el bien/servicio.
notes
string
Opcional
Observaciones libres. Aparecen en el pie del PDF generado.
billing_reference
object
Condicional
Obligatorio solo para tipos 91 y 92. Referencia la factura original a corregir.
Sección 07
Ejemplo real completo
Request con cliente, múltiples ítems e impuestos. Response con CUFE y documentos generados.
El CUFE (Código Único de Factura Electrónica) es el identificador legal que emite la DIAN al aceptar una factura. Su presencia confirma que el documento tiene plena validez fiscal.
Contingencia cuando el sistema electrónico no está disponible
La normativa DIAN define tres niveles de contingencia cuando no es posible emitir facturas electrónicas. SIIVRO soporta los tres niveles del Anexo Técnico.
Nivel 1Inmediato
Facturación offline
Emisión de facturas en papel (tipo 02). Se reportan masivamente a la DIAN una vez restablecido el sistema.
Nivel 2Mediano plazo
Sistema alterno
Uso de un sistema de facturación alterno habilitado por la DIAN. Numeración diferenciada.
Nivel 3Regularización
Reporte posterior
Reporte masivo a la DIAN con todas las facturas emitidas durante el período de contingencia.
→ La contingencia se profundiza en la sección dedicada: /docs/contingency
Sección 14
Flujo real en producción
El error más común al integrarse con SIIVRO es asumir que facturar es siempre un flujo síncrono: POST → respuesta → listo. Eso no siempre ocurre. Tu integración debe manejar ambos escenarios desde el primer día.
Caso A — Respuesta síncrona
→SIIVRO responde DIAN_ACCEPTED
→Tienes CUFE en el response
→Puedes mostrar el PDF de inmediato
→Flujo termina aquí
Caso B — Respuesta asincrónica
→SIIVRO responde PROCESSING
→No tienes CUFE aún
→NO reenvíes la factura — espera
→El resultado llega por webhook
Idempotencia — crítico en producción
Una factura no puede crearse dos veces. En producción es frecuente que el frontend reintente, el backend haga retry por timeout, o el usuario haga doble click. El resultado sin control es doble facturación fiscal.
La solución: envía siempre un external_id único por operación. Si SIIVRO recibe el mismo external_id dos veces, retorna el resultado original sin crear un nuevo documento.
Cuándo reintentar y cuándo no
Reintentar si:
→Timeout de red
→Error de conexión (5xx)
→Status PROCESSING resuelto por webhook
NO reintentar si:
→Error 4xx (datos incorrectos)
→DIAN_REJECTED (error fiscal)
→Factura ya existe con mismo external_id
Sección 15
Webhooks eventos de estado en tiempo real
Cuando la DIAN no responde de forma síncrona, SIIVRO te notifica por webhook en el momento en que se resuelve el estado. Los webhooks son el mecanismo que separa una integración robusta de una frágil. No son opcionales en ambientes productivos reales.
Actualizar estado en DB — habilitar descarga PDF — notificar usuario
DIAN_REJECTED
Marcar factura como rechazada — mostrar error — solicitar corrección
Los webhooks pueden repetirse. Tu endpoint debe ser idempotente: si recibes el mismo invoice_id dos veces, no ejecutes la lógica de negocio dos veces. Valida siempre contra el estado actual en tu base de datos.
Valida la firma del webhook. Cada evento incluye un header X-SIIVRO-Signature con firma HMAC-SHA256. Verifica que el payload proviene de SIIVRO antes de ejecutar cualquier lógica. Consulta la guía en /docs/webhooks/security.
Sección 16
Manejo de estados tabla de decisión operativa
Conocer los estados no es suficiente. Lo que importa en producción es saber qué hacer con cada uno.
Estado
Qué significa
Qué debe hacer tu sistema
Qué NO hacer
PROCESSING
DIAN no respondió aún
Esperar webhook invoice.updated
NO reenviar la factura
DIAN_ACCEPTED
Factura válida con CUFE
Mostrar PDF / guardar CUFE
NO modificar ni reenviar
DIAN_REJECTED
Error fiscal en la factura
Corregir datos y reenviar
NO reenviar sin corregir
PENDING_SIGN
En cola interna de firma
No hacer nada — estado transitorio
NO asumir error
Esta tabla no es información — es comportamiento. La diferencia entre una integración que escala y una que genera incidencias en producción es haber implementado estas reglas desde el inicio.
Sección 17
Versionado de API
Todas las rutas de la API incluyen la versión como prefijo. Esto garantiza que tu integración no se rompa ante cambios internos o actualizaciones del motor fiscal.
Versión actual
/V2.1/invoices
Versión estable en producción. Se recomienda siempre integrar con la versión más reciente para acceder a las últimas capacidades fiscales.
Versiones futuras
/V3/invoices
Cuando se introduzcan cambios con ruptura de compatibilidad, SIIVRO publica una nueva versión. La anterior sigue funcionando hasta su retiro formal.
Garantías de retrocompatibilidad
SIIVRO no rompe versiones existentes sin aviso formal.
Cambios que afecten la estructura del request o el response implican una nueva versión mayor.
Campos nuevos opcionales pueden agregarse a versiones existentes sin considerarse una ruptura.
Los endpoints de consulta GET mantienen su estructura mientras la versión esté activa.
Política de notificación de cambios
SIIVRO notifica con mínimo 30 días de anticipación cualquier cambio relevante en la API. Los cambios mayores pasan por un programa beta con usuarios seleccionados antes del lanzamiento general.
Sección 18
Límites de tasa rate limiting
Los límites de tasa protegen la estabilidad de la plataforma y garantizan disponibilidad uniforme para todos los tenants.
Creación de facturas
60 req / min
Por tenant
Consultas GET
300 req / min
Por tenant
Registro de webhooks
10 req / min
Por tenant
Descarga de documentos
120 req / min
Por tenant
Headers de respuesta relevantes
X-RateLimit-LimitLímite total de requests para el período actual.
X-RateLimit-RemainingRequests disponibles en el período actual.
X-RateLimit-ResetTimestamp UNIX cuando el contador se reinicia.
Retry-AfterSegundos a esperar antes de reintentar (solo en 429).
Si superas el límite, la API retorna HTTP 429 Too Many Requests. Implementa backoff exponencial en tus clientes. Los límites por plan se detallan en /docs/rate-limits.
Sección 19
Seguridad — diseñado para ambientes productivos reales
La seguridad de SIIVRO va más allá de HTTPS y API Keys. Cada capa está diseñada para ambientes donde la información fiscal tiene valor legal y no admite compromisos.
API Keys — privadas y rotables
→Solo se usan desde backend. Nunca en frontend.
→Se pueden regenerar en cualquier momento desde el panel.
→La rotación no interrumpe facturas en curso.
→Cada key queda registrada en el log de acceso.
Firma de webhooks
→Cada evento incluye firma HMAC-SHA256.
→Verifica el header X-SIIVRO-Signature antes de procesar.
→Rechaza eventos sin firma válida.
→El secreto de firma es configurable por tenant.
Scopes y permisos
→Las keys pueden limitarse a operaciones específicas.
→Ejemplo: key solo lectura para reportes.
→Ejemplo: key solo escritura para creación de facturas.
→Configuración por tenant en el panel SIIVRO.
IP Whitelisting (opcional)
→Restringe el acceso a rangos de IP autorizados.
→Ideal para entornos corporativos con IP fija.
→Configurable por tenant desde el panel.
→Recomendado para integraciones ERP críticas.
Sección 20
Qué NO hacer en producción
Experiencia condensada de integraciones reales. Los errores aquí listados son los que generan incidencias fiscales, doble facturación o rechazos masivos de la DIAN.
No facturar sin validar el NIT del cliente
La DIAN valida el NIT del receptor contra el RUT. Un NIT inválido resulta en rechazo inmediato (FAD01). Valida el NIT antes de presentarlo al usuario como opción.
No reenviar requests sin control de idempotencia
Reintentar sin external_id puede crear múltiples facturas por la misma operación. Siempre envía un external_id único por transacción y controla si ya fue procesada.
No confiar en los datos que vienen del frontend
El frontend puede ser manipulado. Valida cantidades, precios y datos del cliente en tu backend antes de enviarlos a SIIVRO. Un price: 0 o un NIT vacío genera error inmediato.
No intentar borrar facturas aceptadas
Una factura aceptada por la DIAN es un documento fiscal con validez legal. No existe endpoint de eliminación. El único mecanismo es una nota crédito (tipo 91).
No ignorar el estado PROCESSING
PROCESSING no es un error. Es un estado válido que indica que la DIAN no respondió de forma síncrona. Escucha el webhook y actualiza tu sistema cuando llegue el resultado.
No hardcodear la resolución DIAN en el código
Las resoluciones tienen fechas de vencimiento y rangos de numeración. Cuando se agotan o vencen, el sistema falla. SIIVRO gestiona la resolución activa automáticamente.
No exponer la API Key en el frontend o repositorios
La API Key de SIIVRO tiene acceso a toda la facturación del tenant. Nunca la incluyas en código cliente, variables de entorno públicas o repositorios de código.
Sección 21
Por qué esta arquitectura escala mejor
No se trata solo de que SIIVRO sea una API REST en lugar de SOAP. Se trata de cómo está construido cada componente para reducir puntos de fallo, latencia y carga operativa.
Menos latencia
SIIVRO se comunica directamente con el WebService de la DIAN sin capas de intermediación. Menos saltos, menos tiempo de espera, menos puntos de fallo.
Menos dependencias en tu stack
Sin librerías de firma criptográfica, sin parsers XML, sin clientes SOAP, sin gestión de certificados. Tu codebase es más pequeño y más mantenible.
Menos puntos de fallo
La complejidad fiscal vive en SIIVRO. Tu backend solo hace HTTP POST. Si la DIAN cambia su esquema, SIIVRO se actualiza sin que toques código.
Más escalabilidad multi-tenant
La arquitectura multi-tenant nativa permite agregar N empresas sin duplicar infraestructura. Un solo punto de integración gestiona múltiples clientes.
El resultado práctico: menos código, menos infraestructura y menos operación fiscal manual. Esto no es solo una API de facturación — es la capa fiscal completa de tu producto, lista para producción desde el primer request.
De request a CUFE. Qué hace el sistema en cada momento y qué debe hacer tu código.
T0Request enviado
T1PROCESSING
T2Webhook recibido
T3Estado final
Sistema
SIIVRO recibe el JSON, lo valida y lo encola para firma XAdES-EPES.
Tu código
Guarda el external_id en tu base de datos con estado PENDING.
Sistema
SIIVRO firma el XML, lo transmite al WebService DIAN y espera el ApplicationResponse.
Tu código
No reenvíes. No modifiques. Espera el webhook.
Sistema
SIIVRO notifica el resultado via POST a tu endpoint con firma HMAC-SHA256.
Tu código
Valida la firma. Actualiza el estado en tu DB. No ejecutes lógica duplicada.
Sistema
La factura queda en DIAN_ACCEPTED (con CUFE) o DIAN_REJECTED (con dian_errors).
Tu código
ACCEPTED — habilita descarga del PDF. REJECTED — muestra error y permite corrección.
La regla de oro: en T1 (PROCESSING) tu sistema no debe hacer nada excepto esperar. Un reenvío en ese estado crea doble factura. El webhook en T2 es la única señal válida para actuar.
Sección 24
Error DIAN real caso completo con corrección
No un error abstracto. El escenario real más frecuente en producción: NIT de cliente inválido. Qué salió mal, qué respondió el sistema y cómo se corrige paso a paso.
PARTE 1Qué salió mal
El sistema envía una factura tipo 01 con el NIT del cliente obtenido directamente del formulario web, sin validar el dígito de verificación. El campo customer.identification tiene un dígito transpuesto: se envía "901944218" en lugar de "901944128". La DIAN consulta el RUT y no encuentra ese NIT registrado.
PARTE 2Respuesta del sistema
Response — 422 DIAN_REJECTED
{
"id": "inv_7h3nB2q1",
"status": "DIAN_REJECTED",
"cufe": null,
"dian_errors": [
{
"code": "FAD01",
"message": "NIT del receptor no encontrado en el RUT de la DIAN.",
"field": "customer.identification",
"value_sent": "901944218"
}
],
"created_at": "2025-04-24T16:10:44-05:00"
}
Nota importante: esto no es un error técnico de la API. Es un error fiscal. La factura no existe ante la DIAN. El NIT enviado no está en el RUT.
PARTE 3Corrección paso a paso
01
Leer dian_errors[0].field
El campo culpable es customer.identification. El valor enviado fue 901944218.
02
Validar el NIT correcto
Consulta al usuario o valida con la DIAN. El NIT real de la empresa es 901944128 con DV 3.
03
Generar un nuevo external_id
No reutilices el external_id de la factura rechazada. Genera uno nuevo: ORD-2025-00847-R1.
04
Reenviar el request con el NIT corregido
Envía el mismo request con customer.identification: '901944128', dv: '3' y el nuevo external_id.
05
Verificar DIAN_ACCEPTED y guardar CUFE
El response exitoso incluye cufe, pdf_path y xml_path. La factura corregida tiene validez legal.
Conclusión: FAD01 nunca es un bug de SIIVRO. Siempre es un dato de negocio incorrecto. Valida el NIT del cliente antes de enviarlo no después del rechazo.
Sección 25
Testing sandbox mindset antes de producción
El entorno sandbox es idéntico al productivo en comportamiento. Si algo falla aquí, fallará en producción. No es un entorno de juguete.
Modo sandbox
→No afecta la DIAN real bajo ninguna circunstancia
Factura con NIT inválido — status: DIAN_REJECTED, código FAD01
Factura con resolución agotada — status: DIAN_REJECTED, código FAD14
Mismo external_id dos veces — segunda request retorna resultado original
Factura tipo 91 sin billing_reference — error 422 inmediato
Webhook configurado — recibes evento invoice.updated al cambiar estado
Rate limiting — 60 facturas/min; la 61 retorna HTTP 429
API Key expuesta en frontend — nunca, aunque sea sandbox
La regla del sandbox: si no probaste el caso en sandbox, no existe en tu integración. Un escenario no probado es un incidente fiscal esperando ocurrir.
Sección 26
Observabilidad logs, trazabilidad y auditoría
Una integración enterprise no solo emite facturas. Puede responder en cualquier momento: "¿qué pasó con esta factura?" con precisión y evidencia completa.
Un cliente dice: "me cobraron pero no llegó la factura". Con SIIVRO puedes responder en segundos: qué estado tiene la factura, si el webhook se entregó, cuándo ocurrió cada transición, y dónde está el PDF firmado. Eso no es soporte — es trazabilidad fiscal completa.
→ Guía de observabilidad avanzada y retención de logs en /docs/observability
Sección 27 Playground · Demo Interactivo
Playground Simula la API sin backend real
Simula el comportamiento real del endpoint POST /V2/invoices sin backend real, sin DIAN, sin certificados. El motor de simulación aplica las mismas reglas que producción: validaciones, estados, idempotencia, webhooks y rate limiting. Cuando estés listo, solo reemplazas el simulador por la API real sin cambiar tu código.
Autorización simulada activa. En producción este endpoint requiereAuthorization: Bearer <API_KEY> desde backend. Nunca expongas tu API Key en el frontend.
MODO SANDBOX0 requests enviadosLímite: 5 / 30s (demo)LISTO
POST /V2/invoices
document_type: "01"
Envía el mismo external_id dos veces → verás idempotencia en acción
customer
Ítem 1
Ítem 2
Totales estimados (pre-simulación)
Subtotal$ 350.000
IVA$ 66.500
ReteFuente-$ 8.750
ReteICA-$ 1.925
Total$ 405.825
Escenarios de prueba rápida
Response Panel
LISTO
Completa el formulario y haz clic en Emitir factura para ver la respuesta simulada de la API.
Prueba diferentes NITs para ver ACCEPTED, REJECTED o PROCESSING.
El response incluye CUFE, PDF y totales fiscales calculados automáticamente. Este es el flujo del 95% de tus facturas en producción.
NIT de prueba: 901944128
BREJECTED — NIT inválido (FAD01)
La DIAN rechaza porque el NIT no existe en el RUT. Ver dian_errors[0].field para saber exactamente qué corregir.
NIT de prueba: 000000000
CPROCESSING → webhook
La DIAN no responde de forma síncrona. El sistema retorna PROCESSING. Después llega el webhook con el estado final. NO reenvíes.
NIT de prueba: 900100200
DIdempotencia
Envía el mismo external_id dos veces. El sistema retorna el resultado original sin crear una nueva factura. Esto evita doble facturación.
NIT de prueba: 901944128
ERate limit (429)
Envía más de 5 requests en 30 segundos. El sistema responde con 429 y Retry-After. Implementa backoff exponencial en producción.
NIT de prueba: 901944128
FPrice: 0 → error 400
Pon price: 0 en cualquier ítem. El validador rechaza antes de llegar a la DIAN. Siempre valida en tu backend antes de enviar.
NIT de prueba: 901944128
El Playground no es un juguete. Es una simulación fiel del comportamiento real de la API. Si tu integración pasa todos los escenarios aquí, está lista para producción. Solo cambia la URL del simulador por https://api.siivro.com/v1/invoices y agrega tu API Key desde backend. Sin cambiar una línea más.