Errores comunes que rechaza la DGII al facturar (y cómo evitarlos)

Una guía Rektora para directores y administradores que ya están emitiendo e-CF o están a punto de comenzar.

Pasar el set de pruebas de la DGII, instalar el certificado digital y activar la producción es un logro. Pero el trabajo no termina ahí. Una vez que tu colegio empieza a emitir Comprobantes Fiscales Electrónicos (e-CF) en producción, la DGII valida cada documento en el momento en que lo recibes. Si algo está mal, el comprobante queda en estado Rechazado y el padre no tiene un documento fiscal válido. Eso genera reclamaciones, confusión y, en el peor caso, quejas ante la DGII.

La buena noticia es que los rechazos no son aleatorios. La DGII valida siempre las mismas reglas, y los errores que aparecen una y otra vez en los colegios que están arrancando son conocidos y prevenibles. Esta guía los lista todos, explica por qué ocurren y, lo más importante, cómo evitar que lleguen a enviarse.

Los errores más comunes de rechazo

La tabla siguiente recoge las causas de rechazo más frecuentes, por qué se producen y qué hacer para prevenirlas antes de que el documento salga de tu sistema.

Error	Por qué ocurre	Cómo evitarlo
XML mal formado	El archivo no respeta el esquema XSD oficial de la DGII: etiquetas fuera de orden, campos obligatorios ausentes, caracteres especiales sin escapar, o una versión del esquema desactualizada.	Usa un software que genere el XML automáticamente contra el esquema vigente. Nunca construyas el XML a mano ni lo copies de otro documento para adaptarlo.
Certificado digital vencido	El certificado digital tributario tiene fecha de vencimiento. Si caduca y el sistema sigue firmando con él, la firma es inválida y la DGII rechaza el comprobante.	Configura alertas con al menos 30 días de anticipación al vencimiento. Gestiona la renovación antes de que expire; el proceso de emisión tarda 3-5 días hábiles. Más detalles en nuestra guía: Certificado digital tributario para colegios.
e-NCF no autorizado	Se usó un número de e-NCF que no está dentro del rango aprobado por la DGII para ese tipo de comprobante y ese RNC. Puede ocurrir cuando se cambia de sistema sin migrar correctamente los rangos autorizados.	El sistema debe consultar y respetar los rangos autorizados vigentes antes de asignar cada e-NCF. Verifica los rangos activos en la Oficina Virtual (OFV) de la DGII y asegúrate de que tu software los tenga cargados.
e-NCF reutilizado	Se emitió dos documentos con el mismo número de e-NCF. Ocurre principalmente en migraciones de sistema o cuando hay registros duplicados en la base de datos.	El contador de secuencias debe ser único, persistente y sin posibilidad de duplicarse. Un buen sistema lo gestiona con un candado a nivel de base de datos y nunca reutiliza un número, aunque el comprobante anterior haya fallado.
Fecha incorrecta	La fecha de emisión del e-CF está fuera del rango aceptable (por ejemplo, fecha en el futuro o con un desfase mayor al permitido respecto al momento de transmisión). También puede ocurrir si el servidor tiene el reloj mal configurado.	Verifica que el servidor o dispositivo donde corre tu software tenga el reloj sincronizado con NTP. La fecha de emisión debe coincidir con el momento real de la transacción.
Errores en el ITBIS o en el total	Los montos de ITBIS declarados por línea no cuadran con los porcentajes aplicados, o la suma de las líneas no coincide con el total del comprobante. Ocurre con frecuencia cuando se mezclan ítems exentos (colegiatura) con ítems gravados (uniformes al 18%) y el cálculo se hace manualmente.	El sistema debe calcular el ITBIS automáticamente por cada línea según el tipo de bien o servicio, y verificar que los totales cuadren antes de generar el XML. Para entender qué va exento y qué no, consulta nuestra guía: Colegiatura e ITBIS: qué está exento en un colegio.
XML firmado editado después de la firma	Alguien intentó corregir un dato (un monto, un nombre, un e-NCF) en el archivo XML después de que ya estaba firmado digitalmente. La firma criptográfica ya no coincide con el contenido y el documento es inválido.	Un comprobante firmado nunca se edita. Si hay un error, se emite un comprobante nuevo (si aún no se transmitió) o se anula con una Nota de Crédito e-CF tipo 34. Ver más en: Nota de crédito e-CF tipo 34: becas, descuentos y correcciones.

El principio que nunca cambia: lo firmado no se toca

Este punto merece su propio espacio porque genera más confusión que cualquier otro.

Una firma digital no es una rúbrica decorativa. Es una huella matemática del contenido exacto del documento en el momento de firmarse. Si cambias un solo carácter después de la firma, la huella ya no coincide con el documento, y la DGII lo detecta de inmediato.

Cuando el personal administrativo descubre un error en una factura ya enviada, la reacción natural es querer "arreglarla". Eso no es posible. El proceso correcto depende del momento:

• Si el error se detecta antes de transmitir a la DGII: descarta el documento, corrige los datos en el sistema y genera un e-CF nuevo con un número de secuencia nuevo.
• Si el e-CF ya fue transmitido y aceptado: emite una Nota de Crédito (e-CF tipo 34) que anula o ajusta el comprobante original, y luego emite uno nuevo si es necesario.

Nunca se edita el XML. Nunca se reenvía el mismo XML con un dato cambiado a mano. Nunca.

Por qué la mayoría de estos errores son prevenibles antes del envío

Aquí está la realidad práctica: la DGII no es el primer filtro que debe atrapar estos errores. Tu sistema de facturación debe serlo.

Un software de facturación bien construido ejecuta validaciones antes de generar el XML final:

• Verifica que el esquema del XML esté completo y correcto.
• Confirma que el certificado digital está vigente antes de firmar.
• Comprueba que el e-NCF corresponde a un rango autorizado y no ha sido usado antes.
• Valida que la fecha de emisión sea coherente con el reloj del sistema.
• Calcula el ITBIS por línea y verifica que los totales cuadren al centavo.
• Bloquea cualquier intento de modificar un documento después de la firma.

Si tu sistema hace todo eso, los rechazos de la DGII dejan de ser un problema recurrente y se convierten en excepciones raras. Si no lo hace, el personal administrativo se convierte en el único filtro, y eso no escala.

Para entender el proceso completo desde cero, consulta nuestra guía pilar: Facturación electrónica e-CF para colegios: todo lo que necesitas saber. Y si quieres ver en detalle cómo funciona la certificación con la DGII antes de producción, revisa: El set de pruebas de certificación de la DGII explicado paso a paso.

Cómo Rektora te ayuda

Rektora genera cada e-CF automáticamente durante el flujo de cobro, aplica el ITBIS correcto por línea (colegiatura exenta, tienda o comedor al 18%), firma con el certificado digital del colegio y transmite a la DGII antes de que el comprobante llegue al padre. Las validaciones de formato, secuencia y totales corren en el sistema, no en el escritorio del administrador.

Si el sistema detecta que el certificado está próximo a vencer, emite una alerta. Si un comprobante necesita corregirse, el flujo de Nota de Crédito está disponible en el mismo módulo. El resultado práctico: los rechazos de la DGII son raros, y cuando ocurren, el equipo de Rektora los resuelve contigo.

Si quieres ver cómo funciona en la práctica para un colegio como el tuyo, solicita una demo.

Solicitar una demo por WhatsApp