Proveedores Tecnológicos DIAN: Qué Son y Cómo Elegir el Mejor para tu Negocio
Un Proveedor Tecnológico (PT) es la empresa habilitada por la DIAN que actúa como intermediario entre tu sistema y la entidad tributaria para la transmisión de documentos electrónicos.
La decisión del proveedor tecnológico para facturación electrónica condiciona durante años la operación contable de una empresa colombiana — desde la latencia de notificaciones hasta los costos por documento, desde el SLA de soporte hasta la facilidad de migrar más adelante. Cambiar de PT después de adoptarlo no es imposible pero tiene fricciones: rangos de numeración, eventos pendientes, ajustes en sistemas conectados. Por eso vale la pena tomar la decisión inicial con un marco analítico que considere las dimensiones técnicas, comerciales, operativas y legales.
Esta guía explica qué es exactamente un Proveedor Tecnológico (PT) en el marco normativo colombiano, qué responsabilidades asume frente a la DIAN, qué criterios objetivos conviene aplicar para evaluar candidatos, y qué señales de alarma indican que un PT puede no servir para el escenario específico de la empresa.
Qué es un Proveedor Tecnológico DIAN
Definición normativa
El Proveedor Tecnológico (PT) es la persona jurídica habilitada por la DIAN para prestar servicios de generación, transmisión, validación y entrega de los documentos electrónicos del sistema de facturación con validación previa. La figura está desarrollada en la Resolución DIAN 0042 de 2020 y sus modificatorias, y se distingue del facturador electrónico (la empresa que emite las facturas) en que el PT presta el servicio técnico a uno o varios facturadores.
Responsabilidades del PT frente a la DIAN
El PT habilitado responde ante la DIAN por la correcta operación técnica del servicio: cumplimiento del Anexo Técnico vigente, disponibilidad del endpoint hacia la entidad, integridad de los documentos transmitidos, conservación de la información por los plazos legales. Esa responsabilidad es solidaria en algunos aspectos con la del facturador, pero el PT mantiene compromisos propios que pueden derivar en sanciones específicas si incumple los términos de su habilitación.
Criterios técnicos de evaluación
Estilo de API y calidad de documentación
Un PT moderno expone API REST sobre JSON con autenticación por bearer token, documentación OpenAPI navegable, SDKs oficiales por lenguaje, y ejemplos embebidos. PTs clásicos pueden operar con SOAP, archivos planos o EDI — válidos legalmente pero con curva de aprendizaje significativamente mayor. Para el equipo de ingeniería, esa diferencia se traduce en semanas o meses de tiempo de integración.
Sandbox real conectado a DIAN vs sandbox mock
Un sandbox real envía las pruebas al ambiente de habilitación DIAN y devuelve respuestas reales del validador oficial. Un sandbox mock simula la respuesta sin pasar por la DIAN. Para validar realmente la integración antes de producción, el sandbox real es la única opción confiable. Conviene preguntar explícitamente al PT cuál de los dos ofrece, porque algunas plataformas usan mock para su quickstart y eso genera falsos positivos.
Webhooks, idempotencia y reintentos
Para arquitecturas event-driven, contar con webhooks firmados con HMAC, idempotencia por ID de evento y reintento automático con backoff es lo que diferencia un PT operativamente fiable de uno frágil. Sin esos elementos, el equipo del cliente debe construirlos por su cuenta, lo cual añade código y riesgo. Preguntar por la política específica de retry del PT (ventana, intervalos, cómo se reentrega manualmente) es parte del checklist técnico.
Criterios comerciales y operativos
Modelo de precios
Los modelos más habituales son tarifa por documento con escalones por volumen, tarifa plana mensual con tope de documentos incluidos, o esquema mixto. La transparencia del precio importa tanto como el precio mismo: PTs que publican tarifas indicativas facilitan la decisión inicial, mientras los que operan con cotización personalizada requieren contacto comercial antes de conocer el costo. Para volúmenes pequeños la transparencia ayuda; para volúmenes grandes la cotización personalizada suele dar mejores condiciones.
SLA, soporte y status page
El SLA contractual de uptime típico de PTs maduros está entre el 99.5% y 99.9%. Más importante que el número es el mecanismo de medición y la compensación por incumplimiento. El soporte técnico debe ser accesible en horarios laborales como mínimo; 24/7 es deseable para volúmenes altos. Una status page pública con histórico de incidencias es señal de madurez operativa.
Cobertura geográfica multi-país
Si la empresa proyecta operar en más de un país LATAM, un PT con cobertura multi-país unificada evita mantener integraciones separadas. PTs como Alanube cubren Colombia, RD, Costa Rica y Panamá desde una sola API; otros PTs requieren integración separada por país. La decisión debe considerar el horizonte de expansión del negocio, no solo la operación actual.
Criterios legales y de cumplimiento
Habilitación vigente ante la DIAN
La verificación más básica: que el PT figure como habilitado en el listado oficial DIAN al momento de la decisión. La habilitación puede perderse — raramente, pero ocurre — por incumplimiento del PT. Un PT no habilitado o con habilitación suspendida no puede transmitir documentos válidos, lo cual pondría en riesgo toda la facturación del cliente. La verificación es pública y se consulta en el portal de la DIAN o en la documentación misma del PT.
Certificaciones de seguridad
Para empresas reguladas por sectores específicos (financiero, salud, público) o con clientes enterprise que exigen due diligence, las certificaciones de seguridad del PT (ISO 27001, SOC 2 Type II) son requisito de contrato. Para empresas no reguladas, son señal de madurez operativa pero no estrictamente obligatorias. Conviene confirmar la vigencia y el alcance de la certificación — algunas certificaciones cubren solo partes específicas del producto.
Tratamiento de datos personales
Las facturas contienen datos personales del adquiriente (nombre, identificación, dirección). El PT como encargado del tratamiento debe cumplir la Ley 1581 de 2012 y demás normativa de habeas data. El contrato debe documentar el rol del PT como encargado y las medidas de seguridad aplicadas. Para empresas con flujos de datos transfronterizos, conviene verificar también los compromisos del PT en transferencia internacional de datos.
Señales de alarma frecuentes
Documentación pública desactualizada
Cuando la documentación pública del PT muestra versiones antiguas del Anexo Técnico, ejemplos con campos obsoletos o referencias a resoluciones derogadas, es indicio de que el PT puede no estar actualizado al ritmo de la DIAN. En un área regulatoria como facturación electrónica, ese desfase se traduce en rechazos en producción y trabajo no previsto de remediación.
Ausencia de status page o de histórico de incidentes
PTs operativamente maduros publican incidentes en una status page con detalle (qué pasó, cuánto duró, qué se hizo para resolverlo). La ausencia total de información pública sobre incidentes no significa que el servicio sea perfecto: significa que la transparencia operativa es limitada y diagnosticar incidentes propios puede ser más difícil.
Contratos sin cláusulas de migración y portabilidad
Contratos que dificultan exportar los datos históricos de facturas emitidas o que penalizan económicamente la migración a otro PT son una señal de alarma. Aunque la historia legal de las facturas está en el repositorio público DIAN, los metadatos operativos (configuraciones, conexiones, customizaciones) suelen quedar en el PT. Garantizar contractualmente la portabilidad de esa información protege a la empresa frente a aumentos de precio o degradación de servicio.
Preguntas frecuentes
¿Cuál es la diferencia entre Proveedor Tecnológico (PT) y software de facturación propio? Un PT es una empresa habilitada por la DIAN que presta el servicio técnico de facturación electrónica a otros. Software propio significa que la empresa misma desarrolla y opera todo el stack técnico, incluyendo la integración directa con los endpoints SOAP de la DIAN. Para que el software propio sea válido, debe estar registrado en MUISCA con su clave técnica y cumplir el Anexo Técnico. Software propio es viable pero implica mantener equipo técnico especializado en facturación DIAN, lo cual rara vez es eficiente fuera de empresas con volúmenes muy altos o requisitos personalizados extremos.
¿Cómo puedo verificar que un PT está efectivamente habilitado por la DIAN? La DIAN mantiene un listado público de proveedores tecnológicos habilitados, consultable desde su portal oficial. La consulta requiere el NIT del PT o su nombre comercial. El listado muestra el estado de la habilitación (vigente, suspendida, cancelada) y la fecha del acto administrativo. Antes de firmar contrato, conviene verificar la habilitación en el listado oficial y solicitar al PT copia del acto administrativo que la otorga. PTs legítimos exponen esa información proactivamente en su sitio web.
¿Qué diferencia hay entre PT habilitado y PSFE de otros países LATAM? PT (Proveedor Tecnológico) es la figura jurídica colombiana definida por la DIAN. En otros países LATAM existen figuras análogas con nombres distintos: PSFE (Proveedor de Servicios de Facturación Electrónica) en República Dominicana, PAC (Proveedor Autorizado de Certificación) en Panamá y México, y operadores con denominaciones específicas en cada jurisdicción. Funcionalmente son equivalentes — todos median entre el emisor y la autoridad fiscal del país — pero las habilitaciones son separadas: un PT habilitado en Colombia no automatically opera en otros países, salvo que ese mismo proveedor haya tramitado habilitación en cada jurisdicción.
¿Es posible cambiar de PT sin notificación previa a la DIAN? La DIAN debe ser notificada del cambio de PT mediante actualización del registro del software emisor en MUISCA. El nuevo PT debe ser informado, los rangos de numeración autorizados se redefinen para el nuevo proveedor, y la entidad ajusta sus registros internos. El cambio en sí no requiere autorización previa de la DIAN (no es un proceso aprobativo) pero sí una comunicación formal. Operativamente, el cambio debe coordinarse para evitar superposición de rangos o documentos en tránsito que queden huérfanos entre el PT saliente y el entrante.
Artículos Relacionados
Errores de API en nómina electrónica DIAN: diagnóstico y solución para integradores
Catálogo de errores de API en nómina electrónica DIAN: errores de esquema, reglas de negocio, firma digital y OASF, con diagnóstico y solución para cada uno.
Firma digital XAdES-BES en nómina electrónica Colombia: certificados, renovación y errores frecuentes
Guía técnica de la firma digital XAdES-BES en nómina electrónica Colombia: entidades certificadoras, proceso de obtención, renovación y errores de firma más frecuentes.
Devengos y deducciones en la NIDD: guía técnica de campos XML para integradores de nómina electrónica Colombia
Guía técnica de los campos XML de devengos y deducciones en la NIDD (nómina electrónica DIAN): obligatorios, opcionales, reglas de validación y errores frecuentes.