Tipos de e-CF DGII 2026: mapa operativo de comprobantes electrónicos

El comprobante fiscal electrónico contiene datos estructurados, reglas de validación, identificación, secuencia y estados que permiten su intercambio y control. La representación legible ayuda a personas, pero no reemplaza por sí sola el archivo ni las validaciones que exige el ecosistema de factura electrónica.

Para llevar esa idea al mostrador, imagina que un cliente recibe por correo una representación impecable, pero el documento estructurado quedó rechazado. Comercial puede pensar que la venta terminó, cuentas por cobrar puede registrar el saldo y el cliente puede intentar contabilizarlo, mientras el sistema fiscal conserva otro estado. El mapa operativo debe impedir esa divergencia. Cada estado necesita una definición, una acción, un responsable y un tiempo esperado. El equipo no tiene que dominar la arquitectura técnica, pero sí reconocer cuándo una factura está completa y cuándo solo parece completa.

La clasificación también debe ocurrir antes de generar archivos. El sistema puede validar formatos, pero no sabe por sí solo si la contraparte fue registrada correctamente o si la operación requiere un comprobante especial. Esa decisión nace en ventas, contratos y datos maestros, y luego se convierte en reglas configuradas. Por eso el proyecto de e-CF no pertenece únicamente a tecnología. Participan comercial, caja, cuentas por cobrar, contabilidad, impuestos, seguridad y soporte. Reúne esos roles al diseñar pruebas y no solamente cuando aparece el primer rechazo en producción.

Un mapa operativo útil tiene dos niveles. El primero lo entiende cualquier persona: escenario de venta, receptor, tipo de comprobante y documentos necesarios. El segundo sirve al equipo técnico y contable: código vigente, campos obligatorios, secuencia, firma, transmisión, estados, referencias y tratamiento de ajustes. Ambos niveles deben compartir una versión y una fecha. Si el cajero usa una ficha antigua y el integrador configura una nueva, el conflicto terminará en anulaciones. Controlar versiones es una tarea pequeña comparada con reconstruir cientos de documentos después del cierre.

Hablar de tipos de e-CF significa distinguir la naturaleza de la operación: crédito fiscal, consumo, ajustes y casos especiales, entre otros que establezca el catálogo oficial. Esta guía no publica una lista cerrada ni inventa equivalencias. Confirma denominaciones, códigos y usos en dgii.gov.do.

Nompli no emite e-CF, no firma archivos, no solicita secuencias y no transmite documentos a DGII. Puede ayudarte a ordenar checklist, calendario y estimados educativos. Tu facturador, proveedor tecnológico, contador y la autoridad sostienen las funciones oficiales correspondientes.

Antes de escoger un tipo electrónico, identifica quién recibe, cuál transacción se documenta y qué tratamiento necesita sustentar. La tecnología no corrige una clasificación comercial defectuosa. Si el maestro del cliente está incompleto, el XML puede estar perfectamente formado y aun así representar mal la venta.

Mantén una matriz con escenario, tipo probable, identificación requerida, impuestos, documentos relacionados y aprobación. Incluye solo casos reales de tu negocio y una ruta para excepciones. El personal de caja debe reconocer cuándo puede emitir y cuándo necesita detenerse.

Revisa tipos de NCF 2026 para entender la decisión previa a facturar. Después valida en la documentación oficial cómo esa lógica se expresa en e-CF para tu perfil. Equivalencia conceptual no significa que códigos, campos y estados sean idénticos.

Durante la migración es tentador crear una tabla donde cada NCF tradicional tiene un e-CF con nombre parecido y asumir que el trabajo terminó. Una equivalencia útil debe incluir uso, receptor, secuencia, referencias, reglas de aceptación, representación y efecto en reportes.

Pide al proveedor tecnológico y al contador que validen la tabla contra dgii.gov.do. Fecha la versión y conserva la fuente. Si una clase no está habilitada para tu empresa o requiere una prueba adicional, el sistema debe impedir seleccionarla en producción.

No renombres tipos dentro del ERP hasta volverlos irreconocibles. Puedes mostrar una etiqueta comercial, pero conserva el nombre y código oficial en reportes. Cuando soporte, contador y DGII usan la misma nomenclatura, investigar un rechazo toma menos tiempo.

La adopción de factura electrónica puede responder a leyes, calendarios, grupos, autorizaciones y condiciones que cambian según el contribuyente. No uses la fecha de otra empresa como fecha propia. Confirma tu estatus, comunicaciones oficiales y pasos pendientes directamente con DGII y tu asesor.

Construye un calendario con hitos: evaluación, selección de proveedor, certificado, pruebas, habilitación, capacitación, salida y estabilización. Añade vencimientos de certificados y renovaciones. El calendario tributario puede recordar tareas internas, pero no certifica obligatoriedad.

Si todavía puedes emitir bajo un esquema anterior durante una transición, define exactamente qué canal usa cada fecha, sucursal y operación. Evita superposición sin control. Dos sistemas activos para la misma venta elevan el riesgo de duplicados, huecos de secuencia y cierres inconsistentes.

Pruebas y producción deben estar claramente separadas. Usuarios, certificados, endpoints, series y datos de ejemplo no pueden confundirse. Un documento exitoso en pruebas no es una venta real, y un e-CF enviado por error a producción no se borra como un archivo local.

Controla quién solicita o administra secuencias, quién configura el sistema y quién puede emitir. Registra rangos o autorizaciones según el modelo vigente, consumo, documentos pendientes y alertas. La empresa debe anticipar agotamientos o bloqueos antes de la hora pico.

Nunca completes un hueco copiando manualmente el número anterior. Investiga si hubo rechazo, intento sin transmisión, contingencia o duplicidad. Conserva logs y consulta el procedimiento oficial. La secuencia cuenta una historia que debe coincidir entre facturador, contabilidad y DGII.

Emitido no siempre significa recibido, aceptado y contabilizado. Define los estados reales que devuelve tu solución y cuáles exige la normativa. Un tablero útil separa enviado, aceptado, rechazado, pendiente, anulado y en contingencia, usando la terminología oficial que corresponda.

Cada mañana revisa rechazos del día anterior y asigna responsable. No esperes al cierre mensual. Un error de RNC o impuesto repetido en cien ventas empezó como un rechazo que nadie atendió. Corrige el dato maestro y reprocesa según el procedimiento, no solo el caso visible.

Conserva XML, representación, acuses, referencia y bitácora de eventos durante el plazo aplicable. Confirma conservación y formato en dgii.gov.do. Una captura del portal puede apoyar una investigación, pero no debería ser la única evidencia de la transacción.

El e-CF de crédito fiscal y el de consumo responden a receptores y finalidades diferentes, como sus equivalentes conceptuales. Configura el alta del cliente para reunir los datos antes de vender. No permitas cambiar el tipo solo porque el cliente llamó después del cierre.

Para notas, compras particulares, regímenes especiales, gobierno, exportaciones u otros escenarios contemplados oficialmente, crea fichas separadas. No adivines códigos. Documenta requisitos, referencias y aprobaciones. Si tu negocio nunca usa un tipo, mantenlo fuera del menú cotidiano para reducir errores.

Al añadir una nueva línea de negocio, prueba todos los comprobantes que pueda generar, incluidos ajustes. Una empresa puede emitir bien ventas normales y fallar justo en la primera devolución. La cobertura de pruebas debe seguir el ciclo comercial completo, no solo el camino feliz.

Una empresa recibe un pedido de un cliente con datos validados. El ERP elige el tipo aprobado, calcula impuestos según parametrización revisada, asigna secuencia y genera el e-CF. La plataforma firma, transmite y registra la respuesta conforme al flujo vigente.

El documento aceptado se entrega por el canal acordado y se registra en cuentas por cobrar. Cuando llega el pago, tesorería enlaza banco, factura y cualquier retención. Si hay devolución, el ajuste referencia la operación original y conserva su propio estado y acuse.

Al cierre, ventas, documentos electrónicos, cuentas por cobrar, banco e IT-1 cuentan la misma historia o incluyen un puente de diferencias. Este ejemplo es operativo, no una especificación técnica. Tu implementación debe seguir los formatos e instructivos oficiales de DGII.

En un sistema electrónico, eliminar la fila local no deshace lo que fue transmitido. Identifica el estado del e-CF y usa el documento o evento de corrección que corresponda. Confirma plazos, referencias y efectos con la documentación vigente y tu contador.

La solicitud interna debe incluir motivo, aprobación, documento original, impacto monetario y acción propuesta. Después verifica que cliente, DGII, ERP y contabilidad reflejen el resultado compatible. Si una vista mantiene el original activo, el cierre seguirá mostrando una diferencia.

Mide anulaciones por causa: identificación tardía, tipo incorrecto, duplicado, precio, impuesto, fallo de integración o devolución real. Separar error de proceso y evento comercial evita conclusiones equivocadas. Una tasa alta de correcciones técnicas pide arreglar configuración, no entrenar al cajero otra vez.

Define qué ocurre cuando falla internet, el facturador, el certificado o un servicio externo. El plan debe indicar quién declara la contingencia, qué mecanismo autorizado se usa, cómo se informa al cliente y cómo se regularizan documentos cuando vuelve el servicio.

Lleva una bitácora con inicio, fin, operaciones afectadas, identificadores temporales, responsable y estado de regularización. Prueba el plan antes de necesitarlo. Una carpeta llamada pendientes no evita duplicar ventas cuando dos personas intentan recuperar el mismo lote.

Confirma límites y procedimientos de contingencia en dgii.gov.do. No inventes números ni emitas fuera de la solución porque el cliente tiene prisa. Nompli puede recordar revisiones, pero no activa contingencia ni transmite el lote recuperado.

Diario: revisar rechazos, documentos pendientes, agotamiento de secuencias y salud del certificado. Semanal: muestrear tipos, impuestos, receptores, notas y entrega. Mensual: congelar el período, exportar el universo, resolver estados abiertos y conciliar con contabilidad.

Asigna responsables y suplentes. Ventas conoce la operación; tecnología conoce la integración; contabilidad conoce el cierre; el proveedor conoce su plataforma. Ninguno puede operar solo. Una reunión breve de excepciones funciona mejor que descubrir cien pendientes la noche anterior al IT-1.

Recorre el checklist fiscal mensual como recordatorio y adapta tareas a tu procedimiento aprobado. El checklist no valida XML, no declara y no reemplaza los controles del facturador ni la revisión del contador.

Agrupa e-CF por tipo, estado, fecha, base, ITBIS y ajustes. Compara con ventas contables. Luego incorpora notas, anulaciones y diferencias temporales. El total limpio sirve como fuente de revisión para IT-1, no como sustituto automático de la declaración.

Cruza compras y ventas con los auxiliares correspondientes, y verifica retenciones cuando apliquen. La guía de conciliación e-CF e IT-1 profundiza ese puente. Para retenciones de servicios, consulta retención 10%.

Si Oficina Virtual rechaza o los totales no cuadran, captura el mensaje y corrige la fuente. Revisa errores del IT-1. No cambies ventas aceptadas para forzar una casilla sin entender el impacto.

Confundir PDF con e-CF, memorizar equivalencias no verificadas, mezclar prueba y producción, permitir tipos sin habilitación, ignorar estados, borrar rechazos, usar certificados vencidos y mantener dos maestros de clientes son fallas que aparecen antes del cierre.

Otros errores son anular sin referencia, regularizar contingencia dos veces, emitir ajustes como ventas nuevas o dejar que soporte técnico decida el tratamiento fiscal. Tecnología implementa reglas; contador y fuente oficial ayudan a definirlas. Los roles deben quedar escritos.

Corrige con análisis de causa: dato, parametrización, capacitación, integración o criterio. Después prueba el caso, actualiza la matriz y monitorea recurrencia. Resolver un XML sin reparar el origen solo garantiza que el mismo rechazo volverá con otro cliente.

Prepara matriz de equivalencias, tipos habilitados, secuencias, certificado, flujo de estados, política de corrección, contingencia, reporte de rechazos y conciliación del último mes. Adjunta muestras anonimizadas y enlaces a las fuentes oficiales usadas para configurar.

Al contador pregunta por clasificación, impuestos, reportes y efecto de ajustes. Al proveedor pregunta por validaciones, logs, respaldo, seguridad, exportación y recuperación. Junta las respuestas en un solo procedimiento. Evita que cada parte asuma que la otra controla el hueco.

Prueba escenarios antes de producción: crédito fiscal, consumo, nota, anulación, receptor inválido, secuencia próxima a agotarse, certificado vencido y caída de servicio. Guarda resultados y responsables. Un demo de una venta correcta no demuestra que el cierre mensual esté listo.

Confirma: tipos habilitados, equivalencias validadas, clientes completos, ambientes separados, secuencias controladas, certificado vigente, estados monitoreados, notas referenciadas, contingencia probada, respaldos disponibles y conciliación con ventas, ITBIS, IT-1 y retenciones.

Usa el calendario tributario, el checklist fiscal mensual y el apartado de impuestos para organización interna. Nompli no emite factura electrónica, no declara, no transmite ni reemplaza al contador.

Este artículo es educativo y no constituye una especificación técnica ni un catálogo oficial cerrado. Tipos, obligatoriedad, secuencias, estados, plazos y procedimientos pueden cambiar. Confirma la versión vigente en dgii.gov.do antes de configurar, emitir, anular, corregir o declarar.