Por qué un XML válido puede ser rechazado
El esquema XSD que publica la DGII solo comprueba la estructura del documento: qué elementos existen, en qué orden y con qué tipo de dato. El validador de la DGII aplica además reglas de negocio que el esquema no expresa: campos que solo son obligatorios en ciertos tipos de comprobante, valores permitidos según el tipo, saldos de notas de crédito o fechas de la secuencia autorizada.
Por eso un XML que pasa la validación del XSD en tu computadora puede volver Rechazado. Y como un rechazo suele consumir el e-NCF, cada error cuesta un número de secuencia que después hay que reportar en el 608.
Tabla de códigos de rechazo
Todos estos casos los hemos visto en rechazos reales de la DGII, en producción o en certificación:
| Código | Qué pasa | Cómo evitarlo |
|---|---|---|
| 1100 | «El campo FechaLimitePago del área IdDoc no es válido» | Con TipoPago 2 (crédito), incluir FechaLimitePago en formato dd-MM-yyyy. |
| 615 | La nota de crédito supera el saldo modificable del comprobante | Calcular el saldo: total − notas de crédito previas + notas de débito previas. |
| 645 | Anulación o corrección de texto con monto distinto de cero | Códigos de modificación 1 y 2 van con MontoTotal 0.00; para corregir montos, código 3. |
| 176 | Falta IndicadorMontoGravado | Obligatorio cuando hay MontoGravadoTotal en los tipos 31, 32, 33, 34, 41 y 45. |
| 145 | FechaVencimientoSecuencia inválida | Debe ser el vencimiento del rango autorizado, no una fecha cualquiera. El tipo 32 no lleva el campo. |
| 3 | «The element 'IdDoc' has incomplete content» | TipoPago es obligatorio en todos los tipos excepto el 43, que debe omitirlo. |
| 244 | Indicador de facturación no permitido para el tipo | E43 solo admite 4 (exento); E46 solo 3 (tasa cero) o 0 (no facturable). |
| 1950 | Tasa cero mal totalizada | Va en el tercer tramo: MontoGravadoI3, ITBIS3 = 0 y TotalITBIS3 = 0.00. Nunca en MontoExento. |
| 1381 | E44 sin RNC del comprador | La DGII lo exige aunque el XSD lo marque opcional. |
| 294 | E47 con indicador de bien | IndicadorBienoServicio debe ser 2 (servicio). |
| 181 | E34 sin tipo de ingresos | La nota de crédito exige TipoIngresos. |
| — | Montos con formato inválido | Exactamente dos decimales: 7080.00, no 7080 ni 0. |
1100: facturas a crédito rechazadas
Es el rechazo más fácil de repetir en masa: si el sistema no envía FechaLimitePago, todas las facturas a crédito salen rechazadas, mientras las de contado se aceptan y el problema pasa desapercibido. La regla aplica igual al comprobante de compras (E41) a crédito. A contado el campo no se envía.
Comprueba que la fecha viaje en formato dd-MM-yyyy (por ejemplo 30-09-2026) y que se valide antes de pedir el número de secuencia.
615 y 645: notas de crédito y débito
Error 615: la nota excede el saldo
Una nota de crédito (E34) no puede superar el saldo modificable del e-CF que referencia. Ese saldo no es el total original: hay que restarle las notas de crédito ya emitidas y sumarle las de débito. Si necesitas devolver más que ese saldo, la nota tiene que repartirse entre otros comprobantes.
Error 645: anular con monto
El código de modificación dice qué hace la nota:
- 1 — Anulación y 2 — Corrección de texto:
MontoTotaldebe ser 0.00. - 3 — Corrección de montos: el que se usa para devolver o ajustar importes.
Recuerda además que la nota solo se puede emitir sobre un comprobante ya aceptado y del mismo ambiente (pruebas o producción). Más contexto sobre los tipos 33 y 34 en la guía de tipos de e-CF.
Reglas por tipo de e-CF
| Tipo | Regla que el XSD no expresa |
|---|---|
| E31, E32, E33, E34, E41, E45 | IndicadorMontoGravado obligatorio si hay monto gravado (0 = precios sin ITBIS, 1 = con ITBIS). |
| E32 | No lleva FechaVencimientoSecuencia. Si es menor de RD$250,000 se envía como resumen (RFCE), sin la tabla de formas de pago. |
| E34 | Exige TipoIngresos. |
| E43 | Sin TipoPago y solo líneas exentas (indicador 4). |
| E44 | Exige RNC del comprador. |
| E46 | Solo tasa cero (3) o no facturable (0); la tasa cero va en el tercer tramo de ITBIS. |
| E47 | Siempre servicio (IndicadorBienoServicio = 2). |
Errores de formato
- Decimales: los montos se validan con un patrón de exactamente dos decimales. Un sistema que convierte números a texto sin formatear produce
7080o0y el documento no pasa. - Fechas: los campos de fecha del e-CF usan
dd-MM-yyyy. - Firma: un XML modificado después de firmado invalida la firma. Nunca se re-firma un documento ya enviado: la nueva firma cambia el código de seguridad y deja de coincidir con lo que registró la DGII.
Aceptado Condicional no es un rechazo
Tampoco es un error que un e-CF de consumo menor de RD$250,000 vuelva sin trackId: el resumen RFCE se acepta de forma síncrona y la DGII no asigna trackId en ese caso.
Qué hacer después de un rechazo
- Lee el mensaje tal cual lo devolvió la DGII: indica el campo y el área del documento.
- Comprueba si la secuencia quedó utilizada. La respuesta lo indica; normalmente sí.
- No reutilices el e-NCF. Corrige el dato y emite el comprobante con un número nuevo.
- Reporta el número consumido en el formato 608 del período.
- Corrige la causa en el sistema, no solo en ese documento: la mayoría de los rechazos se repiten en todos los comprobantes del mismo tipo.
Rechazos durante la certificación
En el proceso para ser emisor electrónico, un solo rechazo en la etapa de simulación de e-CF reinicia esa etapa desde cero: lo aceptado antes deja de contar. Antes de enviar el primer documento, conviene validar el conjunto completo contra todas las reglas de esta página y usar secuencias nuevas en cada intento.
Emite e-CF sin quemar secuencias
EmiteF valida las reglas de negocio de la DGII antes de enviar y firma directo a la DGII, sin intermediarios. Prueba gratis con 30 facturas.
Crear cuenta gratisNota: los códigos y mensajes corresponden a respuestas reales del validador de la DGII en los ambientes de certificación y producción. La DGII puede cambiar sus reglas de validación; ante la duda, revisa la documentación técnica vigente en dgii.gov.do. Contenido informativo, no sustituye asesoría fiscal.