Nota de Débito e-CF Tipo 35 República Dominicana

Cuando un proveedor necesita ajustar al alza el valor de una factura electrónica ya emitida —por intereses de mora, un cargo adicional de flete o una diferencia de tipo de cambio— la nota de débito electrónica es el comprobante fiscal que respalda ese ajuste en el marco normativo de la DGII. Sin embargo, muchos equipos de desarrollo en República Dominicana confunden el e-CF Tipo 35 con la nota de crédito, referencian incorrectamente el comprobante original o usan una secuencia NCF del tipo incorrecto, lo que resulta en documentos rechazados que no completan el ciclo contable del emisor ni del receptor.

Esta guía explica la estructura técnica del e-CF Tipo 35, los casos de uso habilitados por la normativa DGII, los campos obligatorios del XML y los errores más frecuentes en su implementación. Al finalizar, el equipo técnico contará con la información necesaria para emitir notas de débito sin rechazos y con el respaldo normativo correcto.

Qué es la nota de débito electrónica en el marco del e-CF dominicano

Definición técnica y fundamento normativo del Tipo 35

La nota de débito electrónica es el comprobante fiscal electrónico (e-CF) que documenta un aumento en el valor de una transacción comercial previamente facturada. En el catálogo de tipos de comprobantes definido por la DGII mediante la Norma General 01-2018 y sus actualizaciones, el Tipo 35 es el código asignado para este documento. Su función normativa es ajustar al alza el monto de una factura ya emitida —ya sea por intereses de mora, ajuste de precio acordado, costos adicionales de transporte u otros conceptos autorizados— sin necesidad de anular el documento original. La nota de débito no cancela la factura: la complementa sumando el diferencial económico acordado. Por ese motivo, el campo de referencia al e-CF original es obligatorio en el XML del Tipo 35 y su correcta implementación es determinante para que el documento sea aceptado por la DGII.

Diferencia técnica entre el Tipo 35 (débito) y el Tipo 34 (crédito)

El e-CF Tipo 34 (nota de crédito) documenta una reducción en el valor de una transacción: descuentos, devoluciones parciales o totales, ajustes a la baja. El e-CF Tipo 35 (nota de débito) documenta un aumento: cargos adicionales, intereses, ajustes al alza. Esta diferencia tiene consecuencias técnicas directas: el signo del monto de ajuste, el impacto sobre el ITBIS acreditable del receptor y el tratamiento contable en ambos extremos de la transacción son opuestos. En la implementación XML, la diferencia más relevante es el campo TipoeCF: debe contener '35' para débito y '34' para crédito. Las series NCF habilitadas para cada tipo son distintas, por lo que un error de tipo no se corrige reemplazando el campo —requiere emitir un comprobante nuevo con el tipo correcto y la serie NCF correspondiente.

Cuándo se debe emitir un e-CF Tipo 35 según la normativa DGII

Casos de uso habilitados por la norma

La DGII habilita la nota de débito electrónica para los siguientes escenarios: ajuste de precio acordado entre las partes después de la emisión de la factura original, intereses de mora por pago tardío cuando estén previstos contractualmente, gastos adicionales de flete o manejo no incluidos en la factura original, y diferencias de tipo de cambio cuando la transacción fue pactada en moneda extranjera. En todos los casos, la nota de débito debe emitirse con referencia directa al e-CF original: el sistema debe incluir el número del comprobante de referencia (NCFModificado) y la fecha de emisión del documento ajustado (FechaNCFModificado). La DGII rechaza automáticamente los documentos Tipo 35 que carezcan de este vínculo o que lo incluyan con datos incorrectos.

Casos que no corresponden a una nota de débito

Los equipos de desarrollo frecuentemente intentan usar el Tipo 35 para escenarios que no corresponden a su función normativa. El error más común es emitir una nota de débito para corregir datos del receptor o del emisor en la factura original: este tipo de corrección requiere anular el comprobante original y emitir uno nuevo con los datos correctos. Otro error frecuente es usar el Tipo 35 para registrar un cargo completamente nuevo no relacionado con ninguna transacción anterior: en este caso corresponde emitir una nueva factura electrónica Tipo 31 o Tipo 32. Finalmente, algunos ISVs intentan usar la nota de débito para revertir una nota de crédito emitida por error; la DGII no reconoce esta operación como válida. La solución correcta es solicitar la anulación de la nota de crédito incorrecta y emitir la correcta.

Estructura técnica del XML para el e-CF Tipo 35

Campos obligatorios del encabezado del documento

El XML de un e-CF Tipo 35 comparte la estructura base del esquema e-CF definido por la DGII, con los siguientes campos de encabezado que son obligatorios y específicos para este tipo de documento: TipoeCF debe contener el valor '35'; Encf debe contener el número de secuencia de la serie NCF habilitada por la DGII específicamente para notas de débito del contribuyente emisor (las series para Tipo 35 son distintas a las de Tipo 31, 32 o 34); FechaVencimientoSecuencia corresponde a la fecha de vencimiento de la secuencia NCF activa; y el bloque InformacionReferencia debe contener el NCFModificado con el número exacto del e-CF original ajustado, la FechaNCFModificado con la fecha de emisión de ese comprobante original en formato YYYY-MM-DD, y el CodigoModificacion con el código de razón del ajuste definido por la DGII. Omitir o formatear incorrectamente el bloque InformacionReferencia es la causa de rechazo más frecuente en la implementación del Tipo 35.

El bloque InformacionReferencia: implementación correcta

El bloque InformacionReferencia dentro del XML del e-CF Tipo 35 debe incluir tres datos del comprobante original: el número de comprobante (NCFModificado en formato exacto del NCF asignado por la DGII), la fecha de emisión del original (FechaNCFModificado en formato YYYY-MM-DD) y el código de razón de la modificación (CodigoModificacion). La DGII define los siguientes códigos de modificación válidos para notas de débito: '1' para cargos adicionales acordados contractualmente, '2' para intereses de mora, '3' para diferencias de tipo de cambio y '4' para otros ajustes al alza. El sistema debe validar que el e-CF referenciado existe en el registro del emisor, que no ha sido previamente anulado y que pertenece a un período fiscal activo. Referenciar un comprobante anulado o de un período fiscal ya cerrado genera rechazo automático.

Flujo técnico de emisión y validación ante la DGII

Firma digital y envío a través del PSFE

El flujo de emisión del e-CF Tipo 35 sigue el mismo ciclo que cualquier otro comprobante electrónico en República Dominicana: el ISV genera el XML según el esquema oficial de la DGII, lo firma con el certificado digital del emisor mediante SHA-256 con RSA, y lo envía al PSFE (Proveedor de Servicios de Facturación Electrónica) habilitado por la DGII. El PSFE valida el XML contra el esquema, aplica sus propias validaciones de negocio y lo transmite a la DGII para la validación final. El ISV recibe del PSFE una respuesta de recepción inmediata y debe consultar posteriormente el estado de validación, que puede ser 'aceptado', 'rechazado' o 'en proceso'. La cadena de responsabilidad técnica incluye tres actores: el ISV que genera y firma, el PSFE que transmite, y el servicio web de la DGII que valida. Un error en cualquiera de los tres genera un estado de rechazo con código distinto.

Respuesta de aceptación y consulta de estado

Una vez que el PSFE transmite el e-CF Tipo 35 a la DGII, el ISV consulta el estado mediante el endpoint de consulta del PSFE. En condiciones normales, el estado final está disponible entre 10 y 120 segundos. Una respuesta de aceptación incluye el estado 'Aceptado' junto con el número de aprobación de la DGII, que debe conservarse en el registro del ISV como evidencia de cumplimiento fiscal. Una respuesta de rechazo incluye el código de error y la descripción del motivo: los códigos más frecuentes en el Tipo 35 son los relacionados con el bloque InformacionReferencia (referencia inválida o comprobante original anulado) y los relacionados con la secuencia NCF (serie incorrecta para el tipo de documento o secuencia agotada). Estos dos grupos de errores representan más del 70% de los rechazos observados en la implementación del Tipo 35.

Errores frecuentes en la implementación del e-CF Tipo 35 y cómo resolverlos

Errores en el bloque de referencia al comprobante original

El error más frecuente en la implementación del Tipo 35 es un NCFModificado que no corresponde a un comprobante aceptado en el registro del emisor ante la DGII. Esto ocurre cuando el sistema intenta emitir la nota de débito antes de confirmar que el comprobante original fue aceptado, o cuando el número de referencia se construye con datos del sistema interno en lugar del NCF oficial asignado por la DGII. La solución es implementar una validación previa que consulte el estado del e-CF original antes de generar el Tipo 35: si el original está en estado 'en proceso' o 'rechazado', la nota de débito no debe generarse hasta que el original esté confirmado como 'aceptado'. Para ISVs que necesitan emitir múltiples ajustes sobre el mismo comprobante, la API de facturación electrónica para República Dominicana de Alanube expone un endpoint de validación de referencia que permite verificar el estado del e-CF original antes de transmitir el Tipo 35.

Errores de monto y concepto de ajuste

El segundo grupo de errores frecuentes está relacionado con el monto del ajuste y el concepto declarado en el cuerpo del XML. El monto de la nota de débito debe corresponder exactamente a la diferencia que se está ajustando, con el ITBIS calculado sobre ese diferencial según las mismas tasas aplicadas en la factura original. Un error común es calcular el ITBIS sobre el monto total del documento original en lugar de calcularlo solo sobre el monto del ajuste. Otro error frecuente es omitir el campo de descripción del concepto de ajuste o llenarlo con texto genérico sin especificar la causa autorizada por la DGII. La DGII valida la coherencia entre el CodigoModificacion declarado en InformacionReferencia y la descripción del concepto en el cuerpo del documento: incongruencias entre ambos campos generan rechazo con código de error de validación de negocio.

¿Cuál es el código de tipo de comprobante correcto para una nota de débito electrónica en República Dominicana? El código es '35', definido por la DGII en el catálogo de tipos de e-CF. La serie NCF habilitada para el Tipo 35 es distinta a la utilizada para facturas de crédito fiscal (Tipo 31), tiquetes de consumo (Tipo 32) y notas de crédito (Tipo 34). El contribuyente debe solicitar a la DGII la habilitación de la secuencia NCF para el Tipo 35 antes de emitir el primer comprobante de este tipo. Intentar emitir una nota de débito usando una secuencia NCF de otro tipo resulta en rechazo automático por parte de la DGII, independientemente de la validez del resto del documento.

¿Cómo puedo verificar que el e-CF original está aceptado antes de emitir la nota de débito Tipo 35? Consulte el estado del comprobante original a través de la API de su PSFE habilitado por la DGII, usando el NCF del comprobante como identificador de consulta. El PSFE devuelve el estado actual: aceptado, rechazado o en proceso. Si el original está aceptado, puede proceder con la generación del Tipo 35. Si está en cualquier otro estado, la nota de débito no debe generarse hasta que el original complete el ciclo de validación. Esta verificación debe implementarse como paso obligatorio en el flujo de generación de notas de débito, no como validación opcional posterior a la generación del XML.

¿Qué diferencia hay entre el e-CF Tipo 34 y el Tipo 35 en términos de impacto sobre el ITBIS? El Tipo 34 reduce el valor de la transacción y, en consecuencia, reduce el ITBIS que el receptor puede acreditar. El Tipo 35 aumenta el valor de la transacción y aumenta el ITBIS que el receptor debe pagar. Para el emisor, el Tipo 34 reduce el ITBIS cobrado y el Tipo 35 lo incrementa. Una confusión entre ambos tipos tiene consecuencias contables directas para emisor y receptor, no solo para uno de ellos. La corrección requiere anular el comprobante incorrecto y emitir el tipo correcto; no existe mecanismo de enmienda directa en el marco normativo actual de la DGII.

¿Es posible emitir una nota de débito sobre una factura ya anulada o sobre un comprobante de un período fiscal cerrado? No. La DGII rechaza automáticamente cualquier e-CF Tipo 35 cuyo NCFModificado referencie un comprobante en estado 'anulado' o cuya fecha de emisión pertenezca a un período fiscal ya declarado y cerrado. Si la factura original fue anulada, el flujo correcto es emitir una nueva factura con el monto total correcto desde el inicio. Si el período fiscal está cerrado, el ajuste debe tramitarse a través del proceso de rectificación de declaraciones, no mediante comprobante electrónico. Verificar el estado y el período del comprobante original antes de generar el Tipo 35 evita este rechazo.

Nota de Débito Electrónica en República Dominicana: e-CF Tipo 35 Paso a Paso