Autorización de un sistema de facturación en los servicios SOAP v3: pruebas, inspecciones y vigencia

Experiencia de un proceso de pruebas en piloto, el mensaje al finalizar las pruebas, la constancia PDF, la vigencia de un año, la modalidad de inspección, la asociación de NIT, los eventos 5, 6 y 7, los errores 976 y 901 y los puntos por confirmar

Experiencia compartida en el grupo; no constituye norma. Este artículo describe el proceso de pruebas y autorización de un sistema de facturación sobre los servicios SOAP de la versión 3 (v3), tal como lo relataron participantes con capturas de los mensajes oficiales. Sirve como referencia de los pasos y de los mensajes que aparecen. Los plazos y condiciones deben confirmarse en la norma vigente y con el SIN.

Secuencia observada

1. Pruebas en piloto. El sistema consume los servicios de facturación v3 del ambiente piloto (ver el artículo sobre servicios web v2 y v3).
2. Finalización de pruebas. Al cerrar las pruebas, el portal muestra un aviso de confirmación (ver la sección siguiente) antes de finalizarlas.
3. Autorización. Si el sistema cumple, el SIN emite un comunicado que indica que se superaron las pruebas de los servicios SOAP Facturación V.3 y que se emite la autorización.

Mensaje al finalizar las pruebas y constancia en PDF

Al hacer clic en Finalizar Pruebas, el portal muestra un aviso con el texto siguiente:

• «Recuerde que dispone de 3 inspecciones y un plazo de 30 días para autorizar su sistema.»
• «El detalle de las inspecciones se enviarán vía correo electrónico y buzón tributario.»
• La pregunta «¿Está seguro de Finalizar las Pruebas?», con los botones Cancelar y Aceptar.

Tras aceptar, el portal genera un PDF titulado «Datos de la autorización de consumo de servicios SOAP Facturación v.3». Ese documento contiene:

• La fecha de autorización y la fecha de vencimiento, con un año de diferencia entre ambas.
• La indicación «VIGENCIA 1 (un) año, computable desde la fecha de emisión».

El aviso habla de 30 días y de 3 inspecciones, mientras que el PDF indica una vigencia de un año. Un participante supone que el texto del aviso es un mensaje heredado del flujo de la v2 y que el PDF refleja el resultado real de la v3. Esta hipótesis no fue confirmada por el SIN.

Qué hacer en la práctica

1. Antes de finalizar, leer el aviso completo y anotar el texto mostrado.
2. Guardar el PDF de constancia que se genera al terminar la prueba.
3. Revisar el buzón tributario y el correo electrónico del contribuyente, donde según el aviso llegará el detalle de las inspecciones.
4. Si el aviso y el PDF no coinciden, no asumir ninguno de los dos plazos como definitivo. Consultar al SIN por el canal oficial y pedir confirmación por escrito antes de planificar la inspección o la renovación.

Cierre de pruebas y estado AUTORIZADO

Un participante describió cómo se llega al cierre de las pruebas en el ambiente piloto de la v3:

• El ambiente muestra un contador de avance de los paquetes de prueba. El botón «Finalizar pruebas» se habilita solo cuando el contador llega al 100 %.
• En el caso relatado, el avance estaba en 80 % porque faltaban los envíos de los eventos 5, 6 y 7. Al completarlos, el contador llegó al 100 % y el proceso avanzó sin intervención manual.
• Otro participante observó que, aunque el botón seguía deshabilitado, el estado del sistema cambió de «EN PRUEBAS» a «AUTORIZADO» y el contador de días restantes quedó en cero. Antes de dar por cerrado el proceso, conviene verificar ambos indicadores.

Para los eventos 5, 6 y 7 véase la sección de validación de paquetes más abajo.

Qué contiene el documento de autorización

El documento compartido es un comunicado titulado Actualización de sistemas informáticos de facturación. Sus campos principales son:

Conviene revisar que las modalidades y los documentos sector coincidan con lo que el sistema va a emitir. Una modalidad o documento sector no listado no queda cubierto por la autorización.

Vigencia de la autorización: v2 y v3

Interpretación de un participante, no confirmada por una norma de la wiki.

• La autorización de la v2 tendría una vigencia de 3 años y un proceso de inspección.
• La autorización de la v3, según el PDF recibido, indicaría una vigencia de 1 año.
• La autorización de la v3 no reemplazaría la de la v2, por lo que podrían coexistir dos fechas de validez: 3 años para la v2 y 1 año para la v3.

Este punto no está confirmado. Antes de planificar renovaciones, consulte al SIN por escrito cómo se aplicará la vigencia de cada versión.

Desde cuándo corre el año de vigencia

El documento de cierre de pruebas indica una validez de un año, pero las fuentes revisadas no dicen desde qué fecha se cuenta: la de autorización, la de emisión del PDF, la de finalización de pruebas o la de la inspección. Si el SIN prorroga la fase de inspección, la certificación podría vencer antes de lo previsto. Conviene pedir por escrito la fecha de inicio de la vigencia y el efecto de cualquier prórroga.

Inspección presencial o virtual

Opiniones de la comunidad, no constituyen norma. El procedimiento de autorización compartido en el grupo indica que la fase 2 (pruebas de funcionalidad e inspección) puede realizarse física o virtualmente, según criterios del SIN. El procedimiento no define cuándo corresponde cada modalidad.

• Lectura en línea: la v3 se aprobó en línea, sin comité presencial, y «virtual» incluiría las reuniones por videoconferencia.
• Lectura presencial o con comité: «físicamente» implicaría presencia con funcionarios, y un comité podría exigirse al menos para el primer sistema del contribuyente o para cambios sustanciales.

No hay criterio publicado que distinga ambos casos. Antes de planificar la fase 2, consulte al SIN si su inspección será presencial o virtual y qué presencia o documentos se requieren.

Una propuesta del grupo es aplicar la inspección como en la v2 en certificaciones posteriores al primer año, y reservar una recertificación más simple para pruebas funcionales en línea. Es una sugerencia no confirmada.

Ventana normativa

La RND 102600000034 establece que los sistemas propios o de proveedor deben cumplir el Anexo Técnico Ley 1733 para las pruebas en piloto y la autorización, en el periodo del 01/10/2026 al 16/11/2026. En el caso relatado, la autorización es de fecha 29/10/2026, dentro de ese periodo. El relato no indica si el sistema cumplió el Anexo Técnico, por lo que esta condición debe verificarse.

En el grupo se mencionó que el plazo para concluir las pruebas piloto sería el día 16. Esa fecha coincide con el cierre de la ventana, pero la fuente no confirma si la ventana aplica a todos los cambios de la v3.

Validación de paquetes y pruebas de eventos 5, 6 y 7 en el piloto v3

Aparecen problemas recurrentes: el paquete de facturas queda en estado PENDIENTE al validarlo, el evento 5 puede ser rechazado, y no siempre está claro si las pruebas de los eventos 5, 6 y 7 requieren CAFC.

Caso 1: el paquete de facturas queda en estado PENDIENTE

Problema planteado. La recepción del paquete de facturas de la v3 devuelve un código de recepción sin errores, pero al validarlo el estado permanece PENDIENTE.

Qué indica la lista de códigos. En la lista de códigos de respuesta del SIAT, el código 901 corresponde a recepción pendiente. Antes de cambiar datos, conviene confirmar la recepción y reconsultar.

Solución reportada. Un participante notó que la validación era lenta y que, al repetirla sobre el mismo paquete, el estado pasó a VALIDO. Por eso se recomienda reintentar la validación sin reenviar el paquete. Otro participante indicó que pudo usar el otro servicio de validación; no se confirmó si se refería a la v2 u otro método de la v3, por lo que debe verificarse antes de aplicarlo.

Si el estado no cambia tras varios reintentos, conviene revisar los errores individuales de cada factura con una herramienta de pruebas de servicios SOAP, porque la respuesta puede no detallarlos. Después, consulte al soporte técnico con el código de recepción.

Campos de la solicitud de validación. Según el ejemplo compartido: codigoAmbiente, codigoDocumentoSector, codigoEmision, codigoModalidad, codigoPuntoVenta (opcional), codigoSistema, codigoSucursal, cufd, cuis, nit, tipoFacturaDocumento y codigoRecepcion. Sin el codigoRecepcion que devuelve el SIAT no puede consultarse el resultado.

Fórmula. Las fuentes no definen un cálculo. El control es operativo: reconsultar con el codigoRecepcion y no reenviar el paquete mientras el estado siga pendiente.

Ejemplo ilustrativo (intervalos no fijados por norma). Se envía el paquete a las 10:00 y la respuesta es 901. Se reconsulta a las 10:15 y a las 10:30 con el mismo codigoRecepcion. Si a las 11:00 sigue PENDIENTE, se registra el caso con el número de envío y se consulta al soporte técnico.

Caso 2: evento significativo 5 rechazado con código 976

Problema planteado. Al registrar el evento significativo 5, el sistema respondió 976 – EL CÓDIGO DEL EVENTO ES INCORRECTO.

Solución reportada. Un participante recomendó reenviar los eventos desde el 1 hasta el 4, tras lo cual el contador llegaría al 100 %. Otro reportó que el problema se resolvió tras una gestión por ticket, sin confirmar qué acción del SIN lo corrigió. El reenvío no está confirmado como solución oficial: consulte al soporte técnico del SIN antes de aplicarlo.

Fórmula de avance (ilustrativa, no oficial). Avance = eventos aceptados / eventos requeridos × 100.

Ejemplo numérico ilustrativo. Con 4 eventos aceptados de 5 requeridos, el avance es 4 / 5 × 100 = 80 %. Cuando el evento 5 también sea aceptado, el avance sería 5 / 5 × 100 = 100 %.

Caso práctico: error 976 en los eventos 5, 6 y 7 con avance parcial de la lista de pruebas

Problema planteado. La lista de pruebas en el piloto tenía 32 registros, paginados de 5 en 5. En la captura compartida el avance general era de 78 %, y las pruebas de la modalidad Electrónica en Línea de los sectores educativo y ventas estaban aprobadas hasta la página 4. Al llegar a las páginas 5 a 7, que corresponden a los eventos 5, 6 y 7, el registro respondió 976 - EL CODIGO DEL EVENTO ES INCORRECTO. Según la guía del SIAT, estos eventos habilitan facturas manuales de contingencia con CAFC. Otro participante reportó el mismo error con documento sector 11. Un tercer caso de la misma modalidad y sectores no presentó el error, lo que sugiere que el problema depende de la configuración de cada caso.

Parámetros del ejemplo compartido (evento 5, virus informático o falla de software).

Solución. No hay solución oficial compartida. Antes de escalar, conviene verificar:

• Que codigoEvento contenga el número del tipo de evento (5, 6 o 7). La descripción del ejemplo lo presenta como código de recepción, lo que puede confundir ambos valores. Confirme en la documentación del método registroEventoSignificativo.
• Que cantidadFacturas, codigoDocumentoSector y codigoEmision coincidan con lo declarado.
• Si el error persiste, reúna las capturas del listado, el mensaje exacto y los parámetros enviados, y consulte al soporte técnico del SIN.

Fórmula del avance de la lista (captura del participante). Avance = registros aprobados / registros totales × 100. No es la misma medida que el avance de eventos.

Ejemplo numérico. Con 32 registros, las páginas 1 a 4 suman 20 registros: 20 / 32 × 100 = 62,5 %. La captura mostró 78 %, equivalente a unos 25 registros aprobados (25 / 32 × 100 = 78,1 %). Esto indica que hay aprobaciones fuera de las páginas 1 a 4. Verifique en el listado qué registros figuran como aprobados.

Caso práctico: contador de pruebas al 80 % y cierre de pruebas

Problema planteado. El botón «Finalizar pruebas» del ambiente piloto v3 estaba deshabilitado. El contador marcaba 80 % porque faltaban los envíos de los eventos 5, 6 y 7.

Solución reportada. Completar los envíos pendientes de los eventos 5, 6 y 7. Según el participante, el contador llegó al 100 % y el botón se habilitó. Otro participante observó que el estado del sistema pasó a «AUTORIZADO» aunque el botón seguía deshabilitado; esta conducta no está confirmada como regla.

Fórmula. No definida en las fuentes. El contador es un indicador visual del avance, sin fórmula oficial publicada.

Ejemplo ilustrativo. Si el contador marca 80 % y faltan los eventos 5, 6 y 7, el cierre no se habilita. Al completar esos envíos, el contador debe llegar al 100 %. Luego se verifica que el botón esté habilitado, que el estado figure como «AUTORIZADO» y que el contador de días restantes esté en cero.

Caso práctico: plazo de inspección frente al aviso de 30 días

Problema planteado. El aviso al finalizar indica un plazo de 30 días y 3 inspecciones, mientras que el PDF de autorización indica una vigencia de 1 año. No se sabe cuál de los dos datos rige la v3.

Solución reportada. No hay confirmación oficial. Un participante atribuye el aviso a un texto heredado de la v2. Hasta que el SIN lo aclare por escrito, ambos datos se tratan como pendientes.

Fórmula (solo si se confirma el plazo de 30 días). Fecha límite de inspección = fecha de finalización de pruebas + 30 días.

Ejemplo ilustrativo. Si las pruebas se finalizaran el 01/11/2026 y el plazo de 30 días aplicara, la fecha límite sería el 01/12/2026. Para la vigencia del PDF, si la autorización es del 29/10/2026 y el vencimiento de un año, la fecha de vencimiento sería el 29/10/2027. Ambos cálculos son ilustrativos y deben verificarse con la norma vigente.

Plantilla de envío de eventos de prueba

El grupo compartió una plantilla con tres tipos de evento (falla de software o virus, cambio de infraestructura o falla de hardware, y corte de suministro de energía eléctrica). Cada uno se envía en dos variantes:

En todas las variantes: codigoAmbiente 2 (piloto), codigoEmision 2, codigoSucursal 0, codigoRecepcion «no aplica» y tipoFacturaDocumento 1. En la plantilla, codigoEvento se describe como el código de recepción del evento ya registrado, por lo que el evento debe registrarse antes de enviar el paquete. Esa descripción no está confirmada.

Pasos recomendados

1. Verificar el valor que exige codigoEvento en la documentación oficial, registrar el evento significativo y guardar su código de recepción.
2. Enviar el paquete con ese código en codigoEvento y codigoRecepcion «no aplica».
3. Consultar el resultado con la validación del paquete, usando el codigoRecepcion devuelto.
4. Si el estado sigue en PENDIENTE, reintentar la validación sin reenviar el paquete. Si persiste, registrar el caso con el número de envío y consultar al soporte técnico.
5. Si el piloto exige eventos 5, 6 o 7 con CAFC, solicitarlo por el canal oficial y no suponer que el CAFC va en el XML del evento.

Nota: los pasos 2 y 4, el uso del otro servicio de validación, la plantilla, la fórmula de avance y el comportamiento del contador y del estado AUTORIZADO se basan en la práctica reportada en el grupo, no en una norma. Confirme con el SIN antes de aplicarlos en producción.

Novedades de la experiencia en pruebas v3

Experiencia compartida en el grupo; no constituye norma.

Asociación de nuevos NIT durante las pruebas v3

Un participante reportó que, mientras se está en pruebas de la v3, no es posible asociar nuevos NIT. Otro confirmó que el problema continúa. Algunos participantes lo consideran un error, sin confirmación de corrección. No quedó confirmado si la asociación se habilita al concluir las pruebas. Si necesita asociar un NIT en este periodo, consulte primero el estado con el SIN.

Inspección posterior a las pruebas

Al terminar las pruebas, la inspección no fue solicitada todavía. Un participante vio en el mensaje de finalización un plazo de 30 días, pero el sistema se habilitó de inmediato. Se sospecha que ese texto fue copiado de la v2 sin ajustarse, por lo que no conviene dar por cierto el plazo de 30 días. Como indica el propio mensaje, revise el correo con frecuencia, porque el SIN puede comunicar la inspección por esa vía.

Caso práctico: eventos 5, 6 y 7 que no aparecen en la v3 de pruebas

Problema planteado. En la v3 de pruebas, los eventos 5, 6 y 7 (uso de facturas manuales de contingencia, que requieren CAFC según la guía del SIAT) no aparecían en el ambiente. Al intentar registrar uno, el SIAT respondió con el error 976 (el código del evento es incorrecto).

Solución reportada. No hay una regla única. Según los participantes, en un caso se resolvió sin acción del usuario; en otros, al cerrar operaciones; y en otros fue necesario enviar un ticket al SIN. Ninguna de estas salidas está confirmada como procedimiento oficial.

Fórmula. No aplica. El control es operativo.

Ejemplo ilustrativo. Al registrar el evento 5 se recibe el error 976. Se revisa que el código de evento sea 5 y que la configuración del sistema coincida con la modalidad y el ambiente de prueba. Si el error persiste, se anotan la fecha, la hora y el mensaje exacto, y se abre un ticket ante el SIN con esos datos.

Notas de conciliación y notas de crédito ICE

Un participante respondió que sí probó las notas de conciliación y las notas de crédito ICE en el sistema v3. Conviene incluirlas en la lista de pruebas antes de solicitar la autorización.

Puntos pendientes de confirmar en esta sección

• Si la asociación de NIT se habilita al concluir las pruebas v3.
• El plazo real para la inspección y la cantidad de inspecciones.
• La causa por la que los eventos 5, 6 y 7 no aparecían en el ambiente de pruebas v3.
• Si el estado «AUTORIZADO» puede aparecer con el botón de finalización deshabilitado.

Recertificación v2 y actualización a v3

Experiencia compartida en el grupo; no constituye norma. Un participante relató que, en un sistema con certificación próxima a vencer, la plataforma no habilitó la recertificación de la v2, sino únicamente la actualización a la v3.

• En la Oficina Virtual, dentro del listado de certificaciones de los sistemas anteriores, aparece un botón verde con el signo +. Desde ahí se inicia la autorización de la v3, siguiendo el Anexo Técnico y sus variaciones.
• Al solicitar un sistema nuevo, el documento de la plataforma mostró las rutas de ambas versiones (v2 y v3). La recomendación del grupo es no asumir que ambas puedan certificarse.
• Quien tenga una certificación v2 próxima a vencer debe consultar el trámite de actualización a v3 antes del vencimiento.

Puntos a confirmar con el SIN: qué versión queda habilitada para las pruebas en cada caso; si la recertificación de la v2 sigue disponible para sistemas que vencen antes de la migración; y cómo se registra la actualización a v3 en el documento de autorización.

Puntos por confirmar

• Vigencia. El documento indica una vigencia de 1 (un) año, computable desde la fecha de emisión. No se identificó una resolución normativa que confirme expresamente ese plazo para la autorización de servicios SOAP v3, ni desde qué fecha se cuenta. La vigencia de 3 años de la v2 tampoco está confirmada. Anote el vencimiento que figura en el documento para renovar a tiempo.
• Plazo y número de inspecciones. El aviso de 30 días y 3 inspecciones no coincide con el PDF. Ver la sección de mensaje al finalizar las pruebas.
• Modalidad de la inspección. No está definido si la fase 2 será presencial o virtual, ni en qué casos se requeriría un comité. Ver la sección de inspección presencial o virtual.
• Prórroga de la fase de inspección. Si el SIN prorroga la fase 2, no está confirmado si el año de vigencia se extiende o se mantiene desde la fecha original.
• Verificación de la autorización. Según el participante, la autorización se verifica del lado del SIN y no requiere un trámite adicional. Es un relato no confirmado. Compruebe el estado en el portal del SIN.
• Cambios de versión. Conviene consultar con el SIN si una nueva versión requiere una nueva autorización, incluido el caso de la actualización de v2 a v3.
• Agregar sectores a una certificación emitida. Según los participantes, no existe a la fecha la opción de agregar sectores a una certificación ya emitida. El procedimiento practicado fue solicitar una nueva certificación o consultar al SIN.
• Cierre de operaciones. Un participante resolvió su proceso al cerrar operaciones; otro indicó que en su caso la sincronización fue automática. Verifique el estado de sus eventos en el ambiente piloto antes de asumir que el cierre es necesario.

Buenas prácticas

1. Guarde copia del documento de autorización, del PDF de constancia y del texto del aviso de finalización de pruebas.
2. Revise que el tipo de sistema, las modalidades y los documentos sector del documento sean los correctos.
3. Anote la fecha de vencimiento de la autorización y el plazo de las inspecciones, y programe la revisión antes de que venza.
4. Guarde el codigoRecepcion de cada envío y el número de envío para poder reintentar la validación y reportar casos pendientes.
5. Antes de finalizar las pruebas, confirme que el contador esté en 100 % y que el estado del sistema figure como «AUTORIZADO».
6. Si tiene una certificación v2 próxima a vencer, consulte la actualización a v3 con suficiente antelación.
7. Incluya en las pruebas las notas de conciliación y las notas de crédito ICE.
8. Esté atento al buzón tributario y al correo electrónico, donde llegará el detalle de las inspecciones.
9. Pida por escrito al SIN la modalidad de la inspección y la fecha de inicio de la vigencia antes de planificar la fase 2.

Documentos y capturas del caso