Formato 606 DGII desde facturas: guía práctica

El Formato 606 es la informativa mensual donde se reportan a la DGII las compras de bienes y servicios, los costos y gastos para fines de ISR, los adelantos de ITBIS usados como crédito y las retenciones de ITBIS e ISR realizadas a terceros. Para preparar el Formato 606 DGII desde facturas, el trabajo empieza antes del TXT: cada comprobante de proveedor debe quedar clasificado por tipo de NCF, fecha, RNC o cédula, monto, ITBIS, retención y forma de pago.

La propia DGII describe el 606 como el formato usado para remitir costos y gastos para ISR, adelantos de ITBIS usados como créditos y retenciones realizadas a terceros, y señala que requiere prevalidación antes de la fecha límite de la declaración de ITBIS, según su guía de la DGII sobre formatos de envío de datos.

Por eso una guía de Formato 606 DGII paso a paso no debe empezar con "abra la Oficina Virtual". Debe empezar con la factura del proveedor. Una factura B01 de mercancía local, una nota de crédito B04, una compra a proveedor informal y una factura de servicio con retención no se convierten en la misma fila solo porque todas llegaron en el mismo mes. El pre-validador revisa estructura, pero la estructura correcta depende de decisiones contables tomadas factura por factura.

La mecánica final es relativamente corta: organizar una planilla, generar el archivo TXT, correr el pre-validador, corregir errores y enviar por la Oficina Virtual. Lo que consume horas en un cierre real es otra cosa: determinar qué documentos entran, qué ITBIS se adelanta, qué ITBIS se retiene, qué parte se lleva al costo, qué fecha de pago aplica y si una nota modifica un comprobante anterior.

Como disciplina de cierre, muchos equipos dominicanos trabajan el 606 para tenerlo listo antes del día 15 del mes siguiente, no para empezar a revisarlo ese día. Ese margen es lo que permite pedir una factura corregida, validar un RNC nuevo o resolver una nota de crédito sin improvisar en el TXT.

Cuando alguien busca cómo llenar el formato 606 mensual, normalmente no está buscando una definición académica. Tiene una carpeta de PDF, XML, fotos, recibos y facturas impresas, y necesita que el archivo pase sin perder créditos ni dejar una compra importante fuera del soporte fiscal. La forma práctica de trabajar es tratar el 606 como una base de datos mensual de compras: primero se limpia la información de origen, luego se clasifica, después se valida.

Qué facturas de proveedores entran en el 606 y cuáles se desvían

El primer filtro del 606 es documental: no todo papel de proveedor pertenece a la informativa de compras, y no todo pago del mes se resuelve llenando una fila. Antes de tocar ITBIS o retenciones, el contador debe separar los comprobantes que sustentan costos, gastos y créditos fiscales de los casos que tienen otro tratamiento.

En una preparación ordinaria, el 606 recibe comprobantes de compras vinculados al comprador: facturas con crédito fiscal, notas de débito, notas de crédito, comprobantes de compras emitidos por el comprador, gastos menores y comprobantes especiales cuando aplican. En la nomenclatura tradicional y electrónica, eso suele llevar al lector a B01 o E31, B03 o E33, B04 o E34, B11 o E41, B13 o E44, B14 o E45 y B15 o E46, siempre según la naturaleza real de la operación.

El comprobante de consumidor final, B02 o E32, exige cuidado. Si el proveedor entregó consumidor final porque la compra no fue facturada como crédito fiscal al comprador, no conviene tratarla como si fuera una factura deducible ordinaria solo para cuadrar el gasto. Puede existir soporte administrativo del desembolso, pero no es el mismo soporte fiscal que un comprobante con valor de crédito para el comprador.

El proveedor informal es otro desvío común. Si una persona o negocio sin RNC vendió bienes o prestó servicios y corresponde documentar la compra, el problema no se arregla inventando un RNC ni usando datos incompletos en el 606. Se evalúa si procede emitir el comprobante B11 para proveedores sin RNC y, una vez emitido correctamente, ese comprobante entra al flujo de compras.

También hay pagos que parecen compras por la lógica del negocio, pero no son 606 por la lógica tributaria. Un pago a un proveedor extranjero sin NCF, como una suscripción internacional, publicidad en plataforma extranjera o servicio contratado fuera del país, se analiza por el Formato 609. Si se mezcla con el 606, el archivo puede pasar por accidente en Excel y seguir mal soportado en el expediente fiscal. Para esos casos conviene revisar cómo declarar pagos a Stripe, AWS y SaaS extranjeros en el Formato 609, incluyendo la retención de ISR del 27%.

Los e-CF no cambian el principio. Un XML del proveedor puede traer NCF, RNC, fecha, montos e ITBIS con menos riesgo de digitación, pero no decide por sí mismo si el gasto es deducible, si hay proporcionalidad, si existe retención o si la factura pertenece al período. El XML mejora la fuente de datos; el criterio de cierre sigue siendo contable. Para entender el flujo completo del receptor de e-CF en RD —canales de entrega, validación de firma, acuse de recibo y conservación por 10 años— conviene revisar el workflow para procesar el XML del e-CF y mapearlo al 606 antes de incorporar esos comprobantes a la planilla mensual.

Un filtro práctico antes de llenar filas es marcar cada documento con una salida clara:

• Factura con crédito fiscal o e-CF equivalente: evaluar e incluir en el 606.
• Nota de crédito o débito: incluir con NCF modificado cuando aplique.
• Proveedor informal sin comprobante válido: evaluar comprobante de compras antes del 606.
• Pago al exterior sin NCF: revisar Formato 609.
• Consumidor final: no tratar como crédito fiscal ordinario del comprador.

Ese filtro evita que el archivo se vuelva una mezcla de documentos reportables, gastos administrativos y pagos que necesitan otro formato.

La planilla base: una fila limpia por cada comprobante

La planilla del 606 debe parecerse más a un auxiliar de compras que a una hoja de captura rápida. Cada fila representa un comprobante. Cada columna debe guardar un dato que pueda volver a la factura fuente o una decisión contable que alguien pueda defender después.

La estructura mínima empieza con identificación del proveedor: tipo de identificación, RNC o cédula, razón social y, si el archivo de soporte lo permite, nombre comercial. Después vienen los datos del comprobante: tipo de bien o servicio, tipo de NCF, número de NCF o e-NCF, NCF modificado si es nota de crédito o débito, fecha del comprobante y fecha de pago. Luego se separan los montos: bienes, servicios, total facturado, ITBIS facturado, ITBIS retenido, ITBIS sujeto a proporcionalidad, ITBIS llevado al costo, retención de ISR y forma de pago.

El error frecuente es usar Excel como libreta de apuntes y confiar en que el pre-validador ordenará la casa al final. Si una fecha se capturó como texto ambiguo, si un RNC quedó con guiones en unas filas y sin guiones en otras, o si el NCF tiene un espacio invisible copiado desde un PDF, el problema ya está sembrado. El pre-validador solo lo hará visible cuando el cierre esté contra el reloj.

Una planilla sana separa captura, criterio y cálculo. La fecha, el NCF, el RNC y los montos salen de la factura. La clasificación de bienes o servicios, proporcionalidad, retención y forma de pago salen del criterio contable. Las sumas, validaciones de longitud y alertas de campos vacíos pueden quedar en columnas auxiliares. Mezclar todo en una sola fórmula hace más difícil encontrar quién se equivocó: la factura, la digitación o el criterio.

El mapeo mínimo debe quedar visible:

• RNC o cédula del proveedor: identificación del proveedor.
• Tipo y número de NCF o e-NCF: tipo de comprobante y NCF.
• Fecha de emisión: fecha de comprobante.
• Evidencia de pago: fecha de pago y forma de pago.
• Subtotal de bienes: monto facturado en bienes.
• Subtotal de servicios: monto facturado en servicios.
• ITBIS cobrado: ITBIS facturado, sujeto a revisión.
• Nota de crédito o débito: NCF modificado y signo del ajuste.

Para un negocio con 30 facturas al mes, una planilla disciplinada puede ser suficiente. Para un contador externo con varios clientes o una mipyme con 80, 250 o más comprobantes mensuales, la trazabilidad pesa igual que la captura. Conviene guardar una referencia de archivo, página, carpeta o lote en cada fila. Si el pre-validador señala la línea 137, el equipo debe llegar a la factura en segundos, no buscar en correos, WhatsApp y carpetas descargadas.

Esa misma trazabilidad sirve cuando el cierre ya fue presentado. Si DGII o el cliente pregunta por una compra, el expediente mensual debe mostrar la cadena: factura fuente, fila en la planilla, línea en el TXT, validación y acuse. El 606 no es solo un archivo subido a la OFV; es la evidencia estructurada de cómo se registraron las compras del período.

ITBIS, retenciones y forma de pago: donde se gana o se pierde el cuadre

El ITBIS facturado es el punto de partida, no la respuesta final. La factura dice cuánto ITBIS cobró el proveedor; el cierre determina cuánto se adelanta como crédito, cuánto se retuvo, cuánto queda sujeto a proporcionalidad y cuánto se lleva al costo. Si esas columnas se llenan por reflejo, el 606 puede cuadrar aritméticamente y aun así distorsionar el IT-1.

La primera separación es sencilla de nombrar y delicada de aplicar:

• ITBIS facturado: ITBIS cobrado por el proveedor en la factura.
• ITBIS retenido: ITBIS que el comprador retiene y debe reportar según su obligación.
• ITBIS sujeto a proporcionalidad: ITBIS asociado a actividades mixtas, gravadas y exentas.
• ITBIS llevado al costo: ITBIS que no se toma como crédito y se incorpora al costo o gasto.
• ITBIS por adelantar: crédito fiscal que alimenta la declaración de ITBIS.

En un comercio que solo vende bienes gravados, muchas compras ordinarias terminan siendo más directas: factura válida, gasto relacionado, ITBIS facturado revisado y crédito fiscal cuando corresponde. En un negocio con operaciones exentas y gravadas, la lectura cambia. Una parte del ITBIS puede estar vinculada a ingresos que no generan derecho pleno al crédito, y ahí entra la proporcionalidad. Esta guía no sustituye el cálculo tributario del caso; lo importante es que esa decisión se tome al clasificar la compra, no en la OFV.

Las retenciones exigen la misma disciplina. La condición del proveedor, el tipo de servicio, la naturaleza del pago y la obligación del comprador como agente de retención afectan si se reporta ITBIS retenido, ISR retenido o ambos. La fecha de pago tampoco es un adorno. Si la retención nace con el pago, una factura recibida en un mes y pagada en otro puede necesitar un tratamiento distinto al que sugiere la fecha de emisión.

En sectores con reglas más finas, la guía central del 606 debe abrir la puerta y no absorber el caso completo. Construcción es el ejemplo típico: materiales, servicios, partidas exentas, ITBIS gravado y retenciones sectoriales pueden convivir en una misma relación con el proveedor. Para ese escenario, conviene trabajar con una guía específica de clasificación de ITBIS en facturas de materiales de construcción antes de cerrar el archivo mensual, y revisar aparte el cálculo de la retención del ITBIS sobre servicios de construcción según la Norma 02-05 cuando el comprobante corresponde a un servicio y no a un material.

El cuadre útil no es solo "el TXT fue válido". El contador debe poder reconciliar libros, 606 e IT-1. Las compras registradas en contabilidad deben explicar el costo o gasto reportado. El ITBIS adelantado del 606 debe tener relación con el crédito tomado. Las retenciones reportadas deben amarrar con los pagos y con las obligaciones del agente de retención.

Cuando aparece una diferencia, la pregunta correcta no es "qué columna cambio para que pase", sino "qué hecho económico está mal interpretado". Puede ser una factura cargada como bien cuando era servicio, un ITBIS que no debía adelantarse, una retención omitida, una fecha de pago usada por conveniencia o una compra exenta tratada como gravada. Resolverlo en la planilla protege el archivo, el IT-1 y el expediente de auditoría.

Notas de crédito, NCF modificado y otros casos que rompen la línea

Una nota de crédito o una nota de débito no vive sola en el 606. Se reporta como comprobante del período en que fue emitida, pero su sentido tributario depende del comprobante original que modifica. Por eso el campo NCF modificado no es opcional en la práctica: es la forma de decirle al archivo qué factura está siendo ajustada.

El caso que más confunde al cierre es la nota de crédito recibida en un mes distinto al de la factura original. Si la factura B01 fue de marzo y la nota B04 llegó en abril, la nota se trabaja en el 606 de abril con referencia al NCF original. No se reabre marzo solo para que ambas piezas queden en el mismo período, y tampoco se registra la nota sin vínculo documental porque "el monto negativo cuadra".

Ese vínculo importa porque una nota sin relación puede esconder tres problemas distintos. Puede ser un error de captura del NCF original. Puede ser una nota aplicada a una factura que nunca se registró. Puede ser un ajuste que el proveedor emitió sobre un comprobante diferente al que el cliente tiene en archivo. En Excel los tres casos pueden verse como una resta; en una revisión, son historias distintas.

Los errores de NCF también suelen ser pequeños y caros en tiempo. Una letra mal digitada, una secuencia incompleta, un e-NCF copiado sin todos sus caracteres, un NCF duplicado en el mes o una nota apuntando a un comprobante inexistente puede detener la validación. Si el equipo trabaja desde PDF escaneados, conviene revisar especialmente ceros, letras B o E, y números largos copiados desde imágenes de baja calidad.

El RNC o la cédula del proveedor tiene su propio grupo de fallos. Un RNC suspendido, mal digitado o perteneciente a una razón social distinta no se resuelve cambiando el nombre en la planilla. Antes de generar el TXT final, el auxiliar debe revisar los proveedores nuevos, los comprobantes de mayor monto y cualquier factura que llegó con datos incompletos. Mientras más tarde se detecta, más probable es que el cierre se convierta en una cadena de correos al cliente o al proveedor.

Con e-CF, el riesgo cambia de forma. El XML reduce errores de lectura, pero si el archivo recibido no corresponde al PDF que el equipo está viendo, o si el proveedor envió una versión corregida después, el 606 puede quedarse con datos viejos. Por eso la línea del 606 debe tener una fuente definida: factura final aceptada, XML correspondiente y soporte de cualquier nota posterior.

Una revisión previa de casos dependientes ahorra más que una hora de prueba y error en el pre-validador. Antes de generar el TXT, conviene filtrar la planilla por notas de crédito, notas de débito, NCF repetidos, proveedores nuevos, RNC vacíos, fechas fuera del período y montos negativos. Si esas filas están limpias, el archivo tiene mucha menos probabilidad de rechazarse por una línea que nadie quería mirar.

Del Excel al TXT: encabezado, pre-validador y correcciones

Cuando la planilla ya está clasificada, el TXT debe ser una consecuencia, no un segundo ejercicio de digitación. La herramienta, plantilla o flujo que use el contador puede variar, pero la lógica es la misma: trabajar con la plantilla o herramienta vigente de DGII, cargar o exportar las filas limpias, confirmar encabezado y detalle, correr el pre-validador, leer la línea del error, corregir la planilla base, regenerar el TXT y validar otra vez.

El encabezado merece revisión separada. El RNC del informante debe ir limpio, sin guiones ni espacios. El período debe respetar el formato AAAAMM, con dos dígitos para el mes. Abril de 2026 no es 20264; es 202604. La cantidad de registros debe coincidir con las filas de detalle que se están enviando. Si la planilla tiene filtros activos, filas anuladas o líneas de control mezcladas con comprobantes, el conteo se rompe.

Después de generar el TXT, el pre-validador 606 DGII no debe tratarse como un trámite decorativo. Su función es detectar errores antes de que el archivo llegue a la Oficina Virtual. Si el reporte señala una línea, la corrección sana vuelve a la base: identificar la línea, abrir la factura fuente, corregir Excel, regenerar el TXT y validar otra vez. Editar el TXT final a mano puede resolver una alerta y crear dos problemas nuevos.

Los errores comunes suelen caer en patrones reconocibles:

• Período o encabezado incorrecto: formato de mes mal escrito, RNC del informante con caracteres sobrantes o cantidad de registros distinta al detalle.
• Identificación inválida: RNC o cédula del proveedor mal capturada, incompleta o no consistente con el comprobante.
• NCF mal formateado: longitud incorrecta, secuencia incompleta, tipo de comprobante incompatible con la operación o e-NCF copiado de forma parcial.
• Montos que no cuadran: bienes, servicios, ITBIS y total no reconstruyen la factura; ITBIS retenido mayor que el ITBIS facturado; nota de crédito con signo o referencia incorrecta.
• Campos obligatorios vacíos: fecha de pago, forma de pago, tipo de bien o servicio, NCF modificado en notas o retención cuando el caso la exige.

El orden de corrección importa. Primero se corrigen errores que afectan muchas líneas, como encabezado, período, formato de fecha o reglas de exportación. Luego se corrigen proveedores y NCF, porque un mismo proveedor puede aparecer en varias facturas. Al final se revisan montos individuales, notas y retenciones. Ir línea por línea desde el primer error hasta el último sin agrupar patrones hace que el equipo repita el mismo diagnóstico veinte veces.

También conviene conservar el TXT validado con el nombre que generó el proceso de validación. Si el archivo fue aceptado por la herramienta y luego alguien lo renombra, lo mueve o lo vuelve a guardar desde otro programa, puede introducir diferencias innecesarias. La versión que se sube debe ser la versión que se validó.

Un buen cierre mensual deja un rastro simple: planilla base, TXT generado, reporte de validación sin errores y archivo listo para OFV. Si cualquiera de esas piezas no coincide con las otras, todavía no hay un 606 terminado.

Subir el 606 a la Oficina Virtual y conservar el acuse

Con el TXT validado, el envío por la Oficina Virtual debe ser la parte más controlada del proceso. El contribuyente entra a la OFV, busca la opción de formatos de envío, selecciona el tipo 606, adjunta el archivo validado y completa la presentación. La pantalla puede cambiar con el tiempo; la lógica documental no cambia: se sube el archivo que ya pasó la validación, no una versión improvisada después.

El acuse o constancia no es una formalidad para guardar "por si acaso". Es la prueba de que el archivo fue recibido. Debe quedarse junto al TXT validado, la planilla base, el reporte de validación y las facturas fuente del mes. Si el cliente pregunta por el cierre, si aparece una diferencia con el IT-1 o si DGII solicita soporte, el contador no debería reconstruir el expediente desde cero.

Una carpeta mensual bien armada suele tener esta estructura:

• Facturas y e-CF recibidos del período.
• Planilla base con una fila por comprobante.
• Evidencia de validación del TXT.
• TXT final enviado.
• Acuse o constancia de presentación.
• Notas de revisión para casos especiales, como B11, proporcionalidad, notas de crédito o pagos fuera del 606.

La presentación tardía o mal soportada no solo causa fricción administrativa. Puede afectar créditos, deducciones, retenciones y la consistencia entre informativas y declaraciones. Aunque el 606 sea una informativa, se conecta con el cierre fiscal del mes; tratarlo como un archivo aislado abre diferencias que después aparecen en conciliaciones o fiscalizaciones.

Por eso muchos equipos trabajan con un cierre interno antes de la fecha límite. Un corte de recepción de facturas, una primera validación de RNC y NCF, una revisión de ITBIS y retenciones, y una prevalidación temprana entre el día 10 y el 12 reducen la presión de última hora. Esperar al último día convierte cualquier RNC inválido o nota mal vinculada en emergencia.

Si la OFV devuelve un error después de intentar subir, no conviene renombrar el archivo, guardar otra copia ni tocar el TXT final sin entender el rechazo. La ruta razonable es volver al reporte de validación, identificar si el problema es de estructura o de datos, regresar a la planilla y regenerar. Cuando el archivo ya tiene varias versiones llamadas "final", "final corregido" y "último final", el control del cierre se perdió.

Automatizar la extracción ayuda, pero no reemplaza el criterio del contador

La automatización encaja antes de la clasificación tributaria. Si el cuello de botella del cierre es digitar NCF, RNC, fechas, proveedor, montos, ITBIS, total y tipo de documento desde facturas PDF o imágenes, tiene sentido convertir esos documentos en una planilla estructurada antes de preparar el 606. Eso no decide si una compra va al 606, si hay proporcionalidad o si corresponde retención; solo evita que el equipo pierda horas copiando datos que ya están en la factura.

Para un contribuyente con 30 facturas al mes, una planilla manual revisada con calma puede funcionar. Para un contador externo con varios clientes, o una mipyme que recibe 80, 250 o 500 comprobantes mensuales, la digitación se vuelve un riesgo de cierre. Cada número copiado a mano es una oportunidad de invertir dígitos del RNC, cortar un e-NCF, confundir fecha de emisión con fecha de pago o arrastrar un ITBIS a la columna equivocada.

Invoice Data Extraction sirve en esa fase de captura: permite subir facturas y documentos financieros, indicar mediante un prompt qué campos se necesitan y descargar resultados estructurados en Excel, CSV o JSON. Para un flujo de 606, el pedido razonable sería extraer una fila por comprobante con NCF, RNC, proveedor, fecha, subtotal, ITBIS, total, tipo de documento y referencia del archivo fuente. La plataforma también conserva referencias a archivo y página, lo que ayuda cuando una línea rechazada necesita volver a su soporte.

Ese tipo de extraer datos de facturas a Excel es útil porque deja al contador mirando excepciones y criterio, no copiando campos repetidos. La herramienta puede preparar la base. El contador sigue revisando si el comprobante pertenece al 606, si el proveedor está bien identificado, si el ITBIS se adelanta o se lleva al costo, si hay retención, si una nota modifica otra factura y si el expediente mensual queda defendible.

La prioridad práctica es esta: ordenar primero la captura, luego separar los casos que no pertenecen al 606, después clasificar ITBIS y retenciones, y solo entonces generar el TXT. Automatizar una planilla desordenada produce errores más rápido. Automatizar una captura clara libera tiempo para revisar lo que sí exige juicio profesional.