Cómo clasificar la capa que falló en un e-CF antes de escalar

Tu conector acaba de devolverte un error, el cajero te mira por encima del mostrador y el contador te está escribiendo por WhatsApp. Antes de abrir un ticket o de escribirle a nadie, hay una pregunta que te ahorra tiempo y, sobre todo, que evita que el problema se le asigne a quien no le toca: ¿qué capa falló?

Esta guía es sobre ese momento. No cubre cómo recuperar un comprobante individual sin respuesta, ni cómo aceptar la impresión en el POS. Cubre lo que pasa antes de escalar: cómo separar evidencia por capa para que el soporte llegue a quien corresponde.

Una nota honesta al inicio: lo que sigue es criterio de ingeniería para que prepares mejor un ticket. No es orientación fiscal ni un procedimiento oficial de la DGII. Cualquier decisión sobre contingencia, plazos o comprobantes individuales la tomas con tu contador y tu proveedor.

Por qué se confunde un error local con una indisponibilidad del servicio FE

Cuando un envío de e-CF no produce el resultado esperado, el instinto es saltar a una conclusión: "la DGII está caída". El salto se hace con poca evidencia y, casi siempre, antes de mirar lo que está del lado de acá: tu equipo, tu red, tu conector, tu certificado.

En la operación diaria hay por lo menos cuatro capas que pueden fallar, y se parecen entre sí desde la pantalla del cajero. Un timeout, un error de transporte, un certificado con problemas y una ventana de mantenimiento se ven parecido desde el mostrador. Por eso la confusión es la norma.

La trampa está en mezclar dos cosas distintas: el resultado del comprobante individual y la disponibilidad del servicio como sistema. Son dos conversaciones. Mezclar las dos lleva a conclusiones que después no se defienden.

Qué dice el §4.9 del Informe Técnico e-CF y qué NO dice

El §4.9 del Informe Técnico e-CF v1.0 (DGII, marzo 2026 — publicación informativa sin validez legal) describe el servicio Consulta Estatus Servicios como el que proporciona el estatus y la disponibilidad de los servicios de facturación electrónica y sus ventanas de mantenimiento. Eso es lo que describe. Lo que no describe también importa, y ahí se cuela la mayoría de las confusiones operativas:

• No reporta el resultado de un envío individual. Si tu e-CF volvió sin TrackId, ese servicio no te lo resuelve.
• No es un veredicto universal de "DGII caída" o "DGII funcionando". Es un reporte del estatus y la disponibilidad de los servicios.
• No sustituye la verificación en tu propio entorno, ni reemplaza la pista de evidencia que te da el comportamiento de tu conector.
• El mismo documento describe autenticación por certificado (§4.1) para acceder a ese y otros servicios web del flujo e-CF. Eso no convierte un fallo de autenticación en un evento de indisponibilidad.

En resumen: §4.9 informa sobre el servicio. Tu ticket debe hablar de lo que pasó en tu intento, con tu evidencia. La separación en cuatro capas que usamos en este artículo es criterio práctico de ingeniería, no una clasificación oficial de la DGII.

Las cuatro capas que pueden fallar

Antes de mirar nada, conviene tenerlas todas en la cabeza. No porque siempre fallen todas, sino para no atribuirle a una lo que le pasa a la siguiente.

Capa local. Tu equipo, tu conexión, la energía. Es el primer lugar donde el proveedor investiga cuando el resto parece sano. Preguntas típicas: ¿hubo cambios de red o energía?, ¿cuál fue el último envío exitoso desde ese mismo equipo?

Capa del conector. La pieza que conecta tu POS o tu sistema con el servicio web. Aquí se mira si hubo actualizaciones recientes, versiones atrás de lo requerido o cambios de configuración. Tu proveedor de la solución o integrador es quien investiga.

Capa de autenticación. El §4.1 describe la validación de identidad mediante certificado digital y la entrega de un token para consumir otros servicios FE. Si aparece un error en esta fase, pide al proveedor que confirme qué ocurrió en ese intento. Ese mensaje, por sí solo, no determina qué pasó con un comprobante ni la disponibilidad de todos los servicios.

Capa del servicio FE. El §4.9 describe información de estatus, disponibilidad y ventanas de mantenimiento. Pide al proveedor que identifique el servicio y el ambiente realmente observados; una pantalla aislada no permite atribuir una causa general.

Worksheet de evidencia mínima por capa

La tabla siguiente no es un checklist de implementación ni una lista para llenar a lo loco. Es una guía de qué datos no sensibles tienen valor diagnóstico y a quién le toca investigar cada uno. No incluyas credenciales, tokens, certificados, contenido del XML firmado, importes, RNC de clientes ni números de TrackId.

Capa sospechosa	Datos a recolectar	Pregunta que abre la investigación	Quién investiga
Local	Marca de tiempo del intento con zona horaria del negocio. Último envío exitoso conocido desde el mismo equipo. Cambios recientes de red, energía o hardware. Mensaje de error tal como aparece, solo como categoría, sin contenido crudo.	¿El problema es de mi equipo o conexión?	Tu equipo interno o soporte TI local.
Conector	Versión del conector y fecha del último despliegue. Cambios recientes de configuración. Referencia del incidente del proveedor, si existe. Confirmación del proveedor sobre el ambiente donde ocurrió.	¿El problema está en mi conector?	Tu proveedor de la solución o integrador.
Autenticación	Marca de tiempo del intento con zona horaria. Categoría del error devuelto. Referencia del incidente del proveedor, si existe. Confirmación del proveedor sobre la fase exacta que falló en su ambiente.	¿El problema es de la fase de autenticación?	Tu proveedor de la solución; si la pista apunta más allá, se coordina por los canales formales que tu contador indique.
Servicio FE	Nombre del servicio y ambiente confirmados por el proveedor. Hora y zona horaria de la consulta autorizada. Estatus observado y ventana de mantenimiento, si se informó. Para una hora anterior, evidencia conservada entonces; si no existe, marcar desconocido.	¿El problema es del servicio FE?	Tu proveedor de la solución, en pruebas de solo lectura y autorizadas.

Tres reglas prácticas para llenar este worksheet sin meter la pata:

• Sanitiza antes de escribir. Categoría de error, no captura cruda de pantalla. Una captura puede contener tu certificado, un TrackId o un RNC de cliente.
• Pide al proveedor las pruebas que él controla. No ejecutes pruebas que produzcan nuevos comprobantes o inyecten fallas por tu cuenta; deja que el proveedor corra las suyas en su ambiente, y que sean solo de lectura y autorizadas.
• Registra lo que no sabes. "No pude confirmar" es una línea válida. Mejor eso que inventar una causa para que el ticket se vea completo.

Caso ficticio: dos operaciones independientes en la misma jornada

Ejemplo ilustrativo. Esto no ocurrió. Los nombres, los horarios y los errores son ficticios.

Una ferretería abre a las 8:00 a.m. A las 8:42 a.m., el cajero de la caja 1 envía un e-CF firmado desde el POS. El conector devuelve un error de timeout, sin TrackId. El encargado sabe que esa mañana hubo una ventana corta de mantenimiento eléctrico en el local, registrada en la bitácora interna.

En una venta independiente, distinta de la anterior, a las 9:10 a.m., la cajera de la caja 2 envía un e-CF de Crédito Fiscal con XML completo, firmado desde otro equipo, con el mismo proveedor. Esta vez el conector responde con TrackId y el sistema marca la operación como enviada.

¿Qué demuestra esto? Menos de lo que parece a primera vista. Que una operación posterior haya devuelto un TrackId no descarta que el servicio FE estuviera afectado a las 8:42, ni que el conector tuviera un fallo intermitente. Lo que sí muestra es que el conector respondió a las 9:10 en el mismo local. La causa del fallo de las 8:42 queda sin confirmar con esta sola evidencia.

La ferretería no escala este caso como "DGII caída", porque la evidencia no soporta esa conclusión. La pregunta que se lleva al proveedor es: correlacione servicio, hora y ambiente de las 8:42 con su bitácora y revise la fase registrada y señale qué puede confirmar y qué queda desconocido. La pregunta que se lleva al contador es qué hacer con el comprobante individual. La decisión fiscal sobre ese comprobante la toman el proveedor y el contador, con la evidencia preservada.

Qué no se puede inferir de una respuesta ausente

Tres errores de inferencia que aparecen una y otra vez en tickets de este tipo:

• "No recibí TrackId, entonces la DGII no recibió mi e-CF." No se puede concluir eso. La ausencia de TrackId local significa que el identificador no quedó disponible del lado de acá; no es prueba de que la red no haya devuelto respuesta. Si la respuesta existió y no se almacenó en tu sistema, la causa puede estar en la persistencia local tanto como en el servicio.
• "Otra caja sí respondió, entonces la DGII está bien y fue mi equipo." Incompleto. La respuesta de otra operación es un dato de otro intento, no una prueba del estado anterior ni de todos los servicios.
• "Si fue un error de autenticación, entonces la DGII está caída." No. Un mensaje etiquetado como error de autenticación requiere revisión del proveedor; no prueba una caída general ni resuelve el resultado del documento.

Cómo puede ayudar Antreva

En Antreva Tech evaluamos integraciones técnicas entre CRM, POS y el flujo de facturación electrónica, según el alcance que acordemos contigo. Revisamos cómo está conectado tu conector, cómo se gestiona el certificado y qué tan observable es tu intento cuando algo no responde. Esta evaluación es de ingeniería: no emite veredictos fiscales, no promete disponibilidad del servicio FE y se circunscribe al alcance acordado.

Si necesitas una traza técnica ordenada de cada intento de e-CF, en Antreva Tech podemos definir contigo un flujo de trabajo concreto: registro de hora y zona horaria del intento, categoría del error, capa sospechosa, ambiente del proveedor y responsable del seguimiento, todo conectado al sistema que ya usas. El alcance se centra en cómo se preserva la evidencia y cómo se enruta el ticket hacia quien corresponde; las decisiones fiscales sobre el comprobante requieren revisión con tu proveedor y tu contador; este trabajo técnico no determina la aceptación ante la DGII.

Si quieres revisar tu flujo técnico de e-CF bajo este criterio, conversemos. Puedes partir de la página de la solución de facturación electrónica, CRM y POS y, si te sirve de contexto general antes, mira nuestra guía de continuidad digital para mipymes en República Dominicana.

Preguntas frecuentes

¿Cómo sé si fue la DGII o mi sistema cuando falla un e-CF?

No lo sabes a primera vista. Necesitas evidencia por capa: hora del intento con zona horaria, mensaje de error categorizado, última operación exitosa desde el mismo equipo, estado del conector y del certificado en su ambiente. Con eso separas hipótesis, no produces un veredicto.

¿Qué significa exactamente que el servicio FE esté "disponible" según el Informe Técnico?

Según el §4.9, el estatus y la disponibilidad de los servicios de facturación electrónica y sus ventanas de mantenimiento son reportados por el servicio Consulta Estatus Servicios. "Disponible" se refiere a ese reporte observado, no a que tu comprobante individual haya sido recibido ni aceptado. Son dos conversaciones distintas.

¿Qué envío al soporte sin exponer datos?

Envía por el canal autorizado que ya tengas con tu proveedor o integrador: evidencia sanitizada — hora con zona horaria, categoría del error, capa sospechosa, referencia del incidente, cambios recientes. Para procedimientos formales con la DGII relativos a temas fiscales, sigue el canal que tu contador y tu proveedor te indiquen; no asumas canales directos que no estén documentados.

Conversemos para revisar tu flujo técnico de e-CF.