Nota de Débito Electrónica en República Dominicana: e-CF Tipo 35 Paso a Paso
Guía técnica para implementar la nota de débito electrónica (e-CF Tipo 35) en República Dominicana: estructura XML, campos obligatorios, flujo DGII y errores frecuentes.
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
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.
Artículos Relacionados
Los 10 tipos de comprobantes fiscales electrónicos (e-CF) en República Dominicana: cuándo usar cada uno
Referencia práctica de los 10 tipos de comprobantes fiscales electrónicos en República Dominicana: código, caso de uso, flujo de emisión (síncrono o asíncrono) e implicaciones técnicas para developers e integradores.
Cuánto tiempo toma integrar la API de facturación electrónica de la DGII: benchmark por método
Desglose honesto del tiempo de integración de la API de facturación electrónica de la DGII por etapa: lectura de documentación, construcción de payloads, manejo de estados y diagnóstico de rechazos. Comparativa REST vs MCP con estimaciones transparentes.
Errores de rechazo de la DGII en e-CF: cómo diagnosticarlos y corregirlos desde un agente de IA
Los rechazos de la DGII en e-CF tienen causas precisas y acciones correctivas definidas. Esta guía explica el ciclo de vida del documento, los códigos de error más frecuentes y cómo un agente de IA puede diagnosticar y corregir rechazos de forma autónoma.