Extraer facturas dominicanas a Excel: NCF, RNC, ITBIS y 606

Para extraer facturas dominicanas a Excel hay que sacar de cada comprobante el RNC del proveedor, el NCF (11 caracteres: serie B más dos dígitos de tipo más ocho dígitos de secuencia), la fecha, el monto en bienes y el monto en servicios sin ITBIS, el ITBIS facturado y, cuando apliquen, las retenciones de ITBIS y de ISR. Con esos campos en columnas, la hoja queda lista para el registro de compras del mes, el Formato 606, la declaración del IT-1 y, al cierre del año, como insumo del IR-2.

Para el contador externo o el dueño de mipyme dominicana, el cierre del mes rara vez empieza en un sistema contable. Empieza en una carpeta del correo, una conversación de WhatsApp y, si la suerte acompaña, un par de PDFs ordenados que un proveedor formal envía por su cuenta — y el trabajo entre esa carpeta y la planilla es lo que ocupa este recorrido. Convertir facturas PDF a Excel en República Dominicana no es un problema de herramientas genéricas: el lote real es heterogéneo — PDF generado por software del proveedor, papel chemico escaneado, foto de WhatsApp tomada al apuro, algún XML de e-CF que ya empieza a aparecer — y los campos que importan son los del régimen dominicano, no los de una factura cualquiera.

Una nota sobre el alcance, para que el lector sepa qué llevarse de aquí. Este artículo recorre los campos, los formatos en que llegan las facturas y las maneras prácticas de poblar la planilla. No explica cómo armar el archivo TXT del 606, no enseña a verificar el RNC en Oficina Virtual, no entra en la mecánica del comprobante B11 cuando el proveedor es informal, ni recorre la estructura interna de un e-CF: cada uno de esos pasos tiene su propio recorrido enlazado al final. Si la pregunta inmediata es la del puente — facturas que entran, planilla que sale — este es el lugar.

Por qué Excel sigue siendo el destino real de muchas mipymes y contadores externos

El mercado dominicano tiene PSFE consolidados y software contable que sirven a buena parte del SME, eso es cierto. Pero junto a ese segmento hay una franja amplia — mipymes pequeñas, contadores externos que sirven a varias empresas a la vez, bufetes contables que reciben paquetes mensuales por correo — donde la contabilidad mensual vive en hojas de cálculo, y va a seguir viviendo ahí por razones que no son técnicas sino operativas.

La primera razón es el costo. Una suscripción mensual de software contable en USD pesa de manera desproporcionada en una mipyme con margen ajustado, y se compara mal contra una plantilla que el contador ya domina y que no tiene cargo recurrente. La segunda razón es preferencia profesional. Muchos contadores externos prefieren Excel porque controlan la plantilla, controlan los criterios de cuadre y pueden auditar cada celda en segundos sin depender de un proveedor de software para entender por qué un total no cuadra. La tercera razón es estructural: los flujos mixtos. El cliente trabaja con un sistema (a veces con un PSFE, a veces sólo con su facturación), y el contador externo arma su propia planilla en paralelo para preparar el 606, validar contra los recibos y entregar al cliente la revisión del mes. Esa duplicidad parcial no es accidente: es el modo de trabajo de buena parte del oficio.

Este artículo no argumenta contra los PSFE ni a favor de migrar a Excel; toma el dato como está. Si el lector llegó aquí, está poblando una planilla este mes, y lo que necesita es hacer ese flujo bien — con los campos dominicanos correctos, en el orden que el 606 espera, sin errores de tipeo en el NCF que rompan el cuadre al cierre.

Los campos que importa extraer de una factura dominicana y a dónde van

Lo que distingue al flujo dominicano del esquema general — que en su forma transversal recorre los campos que conviene extraer de una factura de proveedor para contabilidad — es la lista cerrada de campos fiscales que DGII espera y la lógica del NCF. Vale la pena enumerarlos uno por uno, con su uso aguas abajo, antes de pensar en cómo extraerlos.

RNC del proveedor. Identifica al proveedor en el registro de compras y es el campo que se valida contra DGII antes de pagar. Cuando el proveedor es persona física sin RNC, en su lugar entra la cédula, pero ese caso cambia quién emite el comprobante y se trata aparte al final del artículo.

NCF. El Número de Comprobante Fiscal (NCF) está compuesto por 11 caracteres: la letra B indica la serie, los dos dígitos siguientes especifican el tipo de comprobante y los últimos ocho dígitos corresponden a la secuencia, según la estructura oficial del NCF publicada por la DGII. La letra B es la marca del comprobante en papel; los dos dígitos del medio son los que clasifican la factura para efectos del 606 y del crédito fiscal; la secuencia identifica el comprobante individual del proveedor. Equivocar la lectura del bloque del medio — confundir un B01 con un B11, por ejemplo — manda toda la fila al lado equivocado del cierre.

Tipo de comprobante. Se deriva del NCF pero conviene tenerlo en columna propia. Los códigos en papel que un contador encuentra con frecuencia al recibir facturas de proveedor:

• B01 — crédito fiscal. La factura típica de un proveedor formal, con derecho a crédito de ITBIS. Es el caso por defecto y representa la mayoría de las filas del 606 cuando el proveedor está formalizado.
• B02 — consumidor final. No genera crédito fiscal de ITBIS. Igual entra al 606 cuando el monto lo amerita, porque DGII reporta el gasto, pero el ITBIS de ese comprobante no se descuenta en el IT-1.
• B11 — comprobante de compras. No lo emite el proveedor: lo emite el comprador para registrar una compra a un proveedor informal sin RNC. Cambia quién es la fuente del NCF en la fila del 606.
• B14 — régimen especial. Aplica a proveedores acogidos a regímenes con tratamiento fiscal específico (zonas francas y similares). Se reconoce y se registra; la mecánica del régimen es del artículo del proveedor, no del cierre del comprador.
• B15 — gubernamental. Comprobantes emitidos a entes del gobierno. La mayoría de los contadores que cierran 606 de mipyme se cruzan con B15 sólo cuando su cliente es proveedor del Estado, no como factura de gasto entrante.

Cuando el proveedor ya emite electrónicamente, los códigos en papel se reemplazan por sus equivalentes en e-CF. La correspondencia funcional para los casos comunes: E31 ocupa el lugar del B01 (crédito fiscal electrónico), E32 el del B02 (consumidor final electrónico), E41 el del B11 (compras electrónico, emitido por el comprador), E45 el del B14 (régimen especial electrónico) y E46 el del B15 (gubernamental electrónico). Lo importante para el contador receptor: ver una E en lugar de una B no cambia la lógica de la fila del 606 ni el campo en la planilla; lo que cambia es el formato de entrada (XML en lugar de PDF), y ese cambio se trata aparte.

Fecha del comprobante. La fecha de emisión que aparece impresa o etiquetada en el comprobante. Determina el período fiscal de la fila para el 606 y el IT-1.

Fecha de pago. Sólo se separa cuando difiere de la fecha del comprobante y el momento del pago afecta retenciones — sobre todo el ISR retenido, que en algunos escenarios se causa al pagar y no al recibir la factura. Para el cierre mensual en régimen de devengo, queda como columna de respaldo y no como llave de cuadre.

Monto en bienes y monto en servicios, sin ITBIS. Se separan porque el 606 los pide en columnas distintas — y porque la lógica de retención y de proporcionalidad cambia entre un bien gravado y un servicio gravado. Sumar los dos en una sola columna obliga a desagregar después, y desagregar después es donde entran los errores.

ITBIS facturado. El ITBIS que el proveedor cobró sobre la operación. Es la base del crédito fiscal en el IT-1 cuando el comprobante es B01 o E31.

ITBIS retenido. Cuando el contribuyente comprador actúa como agente de retención, una porción del ITBIS facturado se retiene y se paga directamente a DGII. La retención de ITBIS aplica en escenarios reglamentados — entre ellos los servicios profesionales pagados por personas jurídicas a personas físicas y ciertos servicios de construcción — y la matemática de cada caso tiene su propio recorrido. Aquí basta con tener la columna y reconocer que existe.

ITBIS proporcionalidad e ITBIS llevado al costo. Cuando el comprador realiza tanto operaciones gravadas como exentas, una parte del ITBIS facturado no se puede deducir como crédito fiscal y se lleva al costo del bien o servicio. La proporción se calcula con la fórmula que define el reglamento, y la planilla necesita columnas separadas para que ese ajuste no contamine la columna de ITBIS deducible.

ISR retenido. El monto retenido al proveedor sobre la base imponible del comprobante, en los escenarios donde aplica retención de renta (servicios profesionales, alquileres, dividendos, ciertos pagos a personas físicas).

ISC. Impuesto selectivo al consumo cuando el bien o servicio lo causa — combustibles, bebidas alcohólicas, tabaco, telecomunicaciones, seguros. Para el contador de una mipyme promedio, la columna queda con cero la mayor parte del tiempo; para el contador de una distribuidora de combustible, es columna de uso diario.

Forma de pago. La columna que el 606 espera. Efectivo, cheque, transferencia bancaria, tarjeta de débito o crédito, cuenta por pagar, compensación, permuta o mixto. Es campo declarado, no decorativo.

El B01 es el caso por defecto del cierre: extraer una factura de crédito fiscal a la hoja de cálculo es lo que el contador hace varias veces al día, y concentra la mayoría de las filas del 606 de un mes típico. El patrón de la planilla se diseña sobre el B01; los demás tipos de comprobante son variaciones que la columna de tipo absorbe.

---

Los formatos en los que llegan las facturas y cómo afecta cada uno al flujo

Si la lista de campos describe lo que hay que extraer, la lista de formatos describe contra qué hay que extraerlo. Y la realidad del lote mensual del contador dominicano es que los formatos se mezclan: el mismo cierre puede traer un PDF nítido del distribuidor de cemento, un escaneo deslavado de la factura de la ferretería del barrio, dos fotos de WhatsApp del suplidor de oficina y, cada vez con más frecuencia, un XML que el cliente reenvió porque su proveedor ya emite electrónicamente. Cada formato impone un techo distinto al flujo de extracción.

PDF generado por software del proveedor. El caso fácil. Cuando una distribuidora formal de combustible o un proveedor mayorista emite la factura desde su sistema, el PDF llega con texto seleccionable y layout consistente entre comprobantes del mismo proveedor. La mayoría de los campos sale directo: el RNC y el NCF se leen sin ambigüedad, los montos están en su sitio mes tras mes. El trabajo cuesta menos por factura y la tasa de error es baja, sea cual sea la herramienta.

Papel chemico escaneado a PDF. Aquí empieza la fricción. La impresión térmica que usan muchos pequeños comercios y suplidores se desvanece con el calor, con la luz y con el paso de los meses; cuando el papel llega al escáner del contador, ya viene con caracteres pálidos, bordes borrosos y zonas que el OCR lee a medias. Los NCF parciales o cortados son comunes — el último dígito de la secuencia que se perdió en el corte del papel, la letra B que se confunde con un 8 cuando el contraste es malo. El flujo manual sobrevive con el contador apretando los ojos; el OCR genérico se equivoca en el campo crítico precisamente cuando más cuesta detectarlo, porque "B0100000123" leído como "80100000123" pasa una validación superficial sin ser un NCF válido.

Foto de WhatsApp tomada con el celular. El formato más complicado de todos. Llegan con perspectiva torcida, brillo del flash sobre la zona del NCF, dedos en el borde y, ocasionalmente, sólo media factura porque el cliente cortó la foto al enviarla. Sigue siendo procesable — y para muchos contadores externos que reciben paquetes mensuales por WhatsApp es la única opción disponible — pero la tasa de error es la más alta de los cuatro formatos. Vale la pena reconocer la fricción real con el cliente antes que asumir que el flujo va a tener el mismo techo que el PDF limpio.

e-CF en XML. Caso técnicamente limpio pero estructuralmente distinto. El XML llega ya etiquetado: el RNC del emisor está en su elemento, el NCF en el suyo, el ITBIS en el suyo. El trabajo no es extraer de un PDF sino leer un XML y mapearlo a las columnas de la planilla. La precisión es máxima cuando el flujo está armado, pero el flujo es otro: requiere un parser, no un lector visual. Conforme el mandato e-CF avanza para mipymes, este formato va a representar una porción creciente del lote mensual, y el contador receptor termina con un flujo bifurcado — extracción visual para PDF e imagen, lectura estructurada para XML.

Las notas de débito y de crédito merecen una nota dentro de los formatos en papel y PDF. Comparten la estructura general de una factura — RNC del emisor, NCF, fecha, montos, ITBIS — pero llevan su propio bloque de tipo de NCF y, en el caso de las notas de crédito, cambian de signo en la planilla. La columna de tipo de comprobante absorbe la diferencia: el contador identifica el código y el resto del flujo no se altera.

Hay un patrón regular de quién manda qué. Las distribuidoras formales — cemento, combustible, mayoristas de oficina — mandan PDF generado, y el flujo desde ellas es predecible. La ferretería del barrio y el suplidor pequeño mandan papel chemico escaneado o foto de WhatsApp. El cliente formalizado del contador externo empieza a mandar XML conforme su sector entra al mandato e-CF. El contador no decide el formato de entrada; lo que sí decide es cómo arma su flujo para que el lote mixto no le rompa el cierre.

---

Tres maneras de pasar facturas a Excel: tipear a mano, OCR genérico y extracción por campos

Con los campos en la cabeza y los formatos del lote claros, queda la pregunta operativa: cómo poblar la planilla. Hay tres rutas reales, y cada una tiene un techo distinto.

Tipear a mano. Es la línea base del oficio, y para muchos contadores sigue siendo la elección razonable. Un contador concentrado, leyendo facturas medianamente legibles, sostiene un ritmo de 30 a 60 facturas por hora; con 80 comprobantes en el cierre de una mipyme pequeña, eso son entre una hora y media y casi tres horas de digitación pura, sin contar verificación ni cuadre. Cuando un contador externo lleva tres o cuatro clientes y el lote mensual cruza las 300 facturas, el flujo manual deja de ser una decisión y pasa a ser un problema: las últimas 50 facturas se tipean al final del día con la atención agotada, y los errores de digitación caen exactamente en el campo que más duele — el NCF — donde un dígito mal copiado rompe el cuadre del 606 contra el pre-validador de DGII.

Lo manual tiene su lugar. Volumen mensual bajo y estable, regularidad operativa, presupuesto cero para herramientas, y el beneficio real de la lectura cruzada del contador con la factura — donde el ojo entrenado detecta una factura del proveedor equivocado o un monto que no encaja con el patrón de gasto del cliente — son razones legítimas para quedarse en el flujo de leer y tipear. Lo que vale la pena no es defender el flujo manual ni atacarlo, sino conocer su techo: cuando el lote mensual crece o el cliente se multiplica, el costo del flujo manual deja de ser cero porque el tiempo del contador entra en la cuenta.

OCR genérico. El segundo escalón es el OCR de uso general, y aquí es donde el lector que ya probó un convertidor de PDF a Excel suele tener una opinión formada. El problema central es concreto: el OCR convierte la imagen en texto plano, pero no entiende qué carácter del texto plano es el RNC, cuál es el NCF y cuál es la fecha. El contador se queda con una pared de caracteres reconocidos que hay que recolocar manualmente en columnas, y el ahorro de tipeo se devuelve en parte como tiempo de mapeo. Para una factura limpia con layout consistente — siempre el mismo proveedor, siempre la misma plantilla — un OCR bien configurado con plantillas por proveedor llega lejos; para el lote heterogéneo del contador externo, donde cada factura viene en su propio diseño, el flujo se rompe en el paso de mapeo.

El subproblema del NCF es ilustrativo. Un OCR razonable lee la cadena B0100000123 como una sucesión de caracteres, pero no separa serie + tipo + secuencia, no valida la longitud y no distingue entre B01 y B11 cuando el contraste del papel chemico es malo. El contador termina ejecutando manualmente la validación que el OCR no hace.

Extracción por campos con prompt. El tercer escalón cambia el patrón de configuración. En lugar de configurar plantillas por proveedor, el contador escribe — una vez — una instrucción en lenguaje natural que nombra los campos que quiere extraer: RNC del proveedor, NCF, tipo de comprobante derivado de los dígitos del medio del NCF, fecha del comprobante, monto en bienes sin ITBIS, monto en servicios sin ITBIS, ITBIS facturado, ITBIS retenido, ISR retenido, forma de pago. Sube el lote completo — PDFs, escaneos y fotos juntos — y recibe una hoja de cálculo con esas columnas pobladas, una fila por factura, con referencia al archivo y página de origen para verificación. El prompt se guarda y se reutiliza el mes siguiente, aplicado al lote del cierre nuevo.

Este flujo describe la extracción automática de facturas a Excel como herramienta: el contador sube el lote en la interfaz — PDFs, JPG, PNG mezclados, hasta varios miles de comprobantes en un solo trabajo — escribe el prompt nombrando los campos dominicanos que necesita en columnas, y descarga el archivo Excel con esas columnas pobladas y la referencia a la factura fuente en cada fila para auditoría. Los prompts se guardan en una librería personal, lo que significa que el cierre del mes siguiente se reduce a abrir el prompt del cliente, subir el lote nuevo y revisar la planilla. Para el contador que entiende qué pasa por dentro, los modelos multimodales aplicados a la extracción de facturas son lo que permite que el mismo prompt funcione contra PDF generado, escaneo y foto de WhatsApp sin reconfigurar plantillas por proveedor.

Cuándo encaja cada enfoque depende menos de la opinión del autor del artículo y más del lote del contador. Volumen mensual bajo y estable, lectura cruzada útil con cada factura: el flujo manual es defendible y la herramienta no compensa el costo de aprender el flujo nuevo. Volumen medio con lote heterogéneo y proveedores que repiten: el OCR genérico ayuda parcialmente y deja deuda de mapeo; vale la pena cuando el contador puede invertir en plantillas por proveedor, no cuando el lote cambia cada mes. Volumen mensual repetitivo con campos dominicanos consistentes — el caso típico del contador externo con varios clientes mipyme — la extracción por campos con prompt es donde se recupera más tiempo, porque el costo de configurar el flujo se paga una vez y el beneficio se acumula cierre tras cierre. Automatizar el registro de facturas de proveedores en RD se mide en cuánto tiempo del contador deja de gastarse en digitación al final del mes y vuelve a la revisión, al cuadre y a la conversación con el cliente.

---

Cómo armar la planilla para que cuadre con el 606 y el IT-1

Procesar facturas de compra para 606 desde Excel funciona cuando las columnas de la planilla anticipan los campos del informativo, en lugar de armarse improvisadamente y reformatearse al final del mes. El esquema de columnas que sigue está pensado para que el cierre se haga sobre la misma hoja en la que entró la información, sin reorganizar nada antes de generar el archivo del 606.

Las columnas, en el orden que la mayoría de los contadores externos termina usando:

• RNC del proveedor. Llave de la fila contra el registro de proveedores y campo directo del 606.
• Nombre o razón social del proveedor. No lo pide el archivo del 606 (que se construye con el RNC), pero hace la planilla legible al contador y al auditor.
• Tipo de NCF. B01, B02, B11, B14, B15 — o el equivalente E cuando es e-CF. Es el campo del 606 que clasifica el comprobante.
• NCF. Los 11 caracteres completos. Campo del 606 y llave de control contra el pre-validador.
• NCF modificado. Cuando el comprobante es una nota de débito o de crédito, el 606 pide el NCF original que la nota afecta. La columna queda vacía para facturas y notas independientes.
• Fecha del comprobante. Fecha de emisión que aparece en la factura. Determina el período del cierre.
• Monto en bienes (sin ITBIS). Columna del 606.
• Monto en servicios (sin ITBIS). Columna del 606, separada de bienes.
• ITBIS facturado. Columna del 606 y base del crédito fiscal en el IT-1.
• ITBIS retenido. Cuando el contribuyente actúa como agente de retención. Es columna directa del 606.
• ITBIS proporcionalidad. El monto de ITBIS no deducible por proporcionalidad del comprador. Columna del 606.
• ITBIS llevado al costo. El ITBIS no deducible que se carga al gasto. Columna del 606.
• ISR retenido. El monto retenido al proveedor por concepto de renta. Columna del 606.
• ISC. Cuando aplica. La mayoría de las filas lleva cero; se queda en la planilla porque es columna del 606.
• Forma de pago. Columna del 606. Efectivo, cheque, transferencia, tarjeta, cuenta por pagar, compensación, permuta o mixto — el código que el formato espera.

El detalle de cómo cada columna se serializa al archivo TXT plano que el pre-validador acepta — el orden, el separador, el formato de fechas y montos — es trabajo del flujo del 606, que tiene su propio recorrido. Lo que cuenta para esta sección es que cada columna en la hoja corresponde a un campo del informativo, sin uno que sobre y sin uno que falte.

Junto al esquema base, dos decisiones estructurales que vale la pena resolver explícitamente.

Granularidad de la fila. Hay dos opciones operativas, y elegir bien evita reformateos. Una fila por factura es el modo del 606: el informativo espera un registro por comprobante, con los montos consolidados al nivel del NCF. Una fila por línea de detalle es útil en otros contextos — análisis de gasto por categoría, reconciliación contra órdenes de compra, separación de bienes gravados y exentos en el mismo comprobante (el caso clásico es la factura de materiales de construcción). La elección depende del uso aguas abajo, y vale la pena consultar el principio general para decidir entre una fila por factura o una fila por línea de detalle. La regla práctica para el cierre del 606: empezar con una fila por factura, y bajar a línea sólo cuando un caso específico — bienes gravados y exentos en el mismo comprobante, gasto por categoría que el cliente pide — lo justifique para esa fila.

Fecha de pago como columna opcional. Cuando el comprobante se emite en un mes y se paga en otro, y el flujo de retención del ISR depende del momento del pago, la columna de fecha de pago se vuelve necesaria para el cuadre. Para el contador que cierra mensual contra el 606 en régimen de devengo, la columna puede quedar como apoyo de auditoría — útil en revisión, no llave del cierre. Para el contador que sigue régimen de caja en flujos específicos (servicios profesionales pagados a personas físicas, por ejemplo), la columna sí entra en el cuadre.

Una columna pequeña pero útil de añadir: la referencia al archivo fuente. Una celda que apunta al nombre del PDF y la página dentro del PDF de donde salió esa fila. No la pide el 606, pero salva tiempo en cualquier auditoría interna del cliente o externa de DGII — cuando una fila se cuestiona, el contador abre el archivo correcto en segundos en lugar de buscar en una carpeta de cien comprobantes. Las herramientas de extracción por campos suelen poblarla automáticamente; el flujo manual la pierde, salvo que el contador adopte la disciplina de nombrar los archivos por NCF.

---

A dónde sigue el flujo: 606, verificación de RNC, B11, e-CF y pagos al exterior

Con la planilla armada y poblada, las preguntas que vienen después no son una sino varias, y cada una abre un flujo propio. Lo que sigue es el mapa del cluster — cada caso identificado, la pregunta clave reconocida, y la nota de que existe (o existirá) un recorrido dedicado para profundizar en su mecánica.

Generar el archivo del 606 desde la planilla. Una vez las columnas están pobladas, el siguiente paso del cierre es producir el archivo TXT plano con separador pipe que el pre-validador de DGII acepta. El orden de los campos en el TXT, el formato exacto de fechas y montos, los códigos numéricos para forma de pago y los validadores que el pre-validador aplica antes de enviar — todo eso es contenido del flujo del 606, que se trata como recorrido propio.

Verificar el RNC del proveedor antes de pagar. Un proveedor con RNC suspendido, no localizado o no inscrito cambia la mecánica de retención y de crédito fiscal: el ITBIS de un proveedor con RNC suspendido no se puede deducir, y la retención puede reclasificarse o aumentarse según el estado. Verificar el RNC en Oficina Virtual de DGII antes de procesar el pago es una rutina del contador externo experimentado, y la lectura correcta de cada estado — activo, suspendido, no localizado, no inscrito — define qué hacer con la fila. La consulta y la interpretación del estado tienen su propio recorrido.

Proveedor informal sin RNC: el comprobante B11. Cuando el proveedor es persona física sin RNC — un colmado, un servicio puntual de plomería, un suplidor pequeño que no facturará formalmente — la salida no es una factura del proveedor sino un comprobante de compras B11 que emite el comprador. La fila del 606 se construye con datos del B11, no de un comprobante recibido. La mecánica de emisión, los topes de monto y los criterios para usar B11 en lugar de exigir formalización al proveedor tienen su propio recorrido.

Recibir e-CF en XML. Cuando el proveedor ya emite comprobantes electrónicos bajo Ley 32-23 y Decreto 587-23, la factura llega como XML en lugar de PDF, y el flujo de cierre se bifurca. La validación de la firma electrónica del comprobante, el mapeo de las etiquetas del XML a las columnas de la planilla, y el manejo de la transición conforme el mandato e-CF avanza para mipymes se tratan en el recorrido sobre qué hacer cuando recibes un e-CF de tu proveedor y cómo mapear el XML al Formato 606.

Pagos al exterior: Formato 609. Cuando la factura es de un proveedor extranjero — servicios de un procesador de pagos como Stripe, infraestructura como AWS, transferencias internacionales, software como servicio en USD, un consultor remoto — el comprobante no tiene NCF y no entra al 606. Entra al 609, que es el informativo dedicado a pagos al exterior y a las retenciones de ISR e ITBIS asociadas. El armado del 609 desde la planilla, los conceptos retenibles según la naturaleza del pago, y la mecánica de los convenios para evitar la doble tributación se tratan en el recorrido sobre cómo declarar pagos a Stripe, AWS y SaaS extranjeros en el Formato 609 con la retención del 27%.

Casos de construcción: ITBIS exento vs gravado y retención del 10%. Las facturas de materiales de construcción mezclan en un mismo comprobante bienes gravados con ITBIS y bienes que el régimen trata como exentos, lo que afecta cómo se separan las columnas de monto en bienes y de ITBIS facturado en la planilla. La retención del 10% sobre servicios de construcción bajo Norma 02-05 es un caso aparte de retención de ITBIS con su propia matemática y su propia base de cálculo, recorrida en detalle en la guía sobre cómo aplicar la retención del ITBIS sobre servicios de construcción al 10% de la base imponible. Cada uno tiene su recorrido propio; aquí basta con que el contador del sector las reconozca como casos que rompen la regla general y que merecen lectura específica antes del cierre.