50 XML de NF-e brasileñas, una sola hoja de cálculo
Cómo el procesamiento por lotes de múltiples proveedores elimina la conciliación fiscal manual
Procesar una NF-e de un proveedor de São Paulo toma 3 minutos. El XML está limpio, los campos son claros y la tasa de ICMS — 18% interna — es la esperada. El problema comienza cuando tienes 50 XML de NF-e de 14 proveedores distribuidos en 7 estados brasileños. El proveedor #3 de Paraná aplica un 19,5% de ICMS en envíos intraestatales, pero un 12% cuando te envía a São Paulo. El proveedor #8 de Pernambuco cobra un 20,5% — excepto en los artículos clasificados bajo NCM 8471.30, que tienen una tasa reducida. El proveedor #11 envió el PDF del DANFE pero no el XML. Y en algún lugar del lote, dos documentos NF-e diferentes comparten el mismo número de factura porque el proveedor #2 reinició su secuencia de numeración al inicio del año fiscal. Extraer una NF-e es sencillo. Extraer 50 y producir una hoja de cálculo de AP limpia y auditable donde cada fila tenga un tratamiento fiscal verificable — ese es un problema completamente diferente.
Cuando llegan 50 XML de NF-e — Por qué un lote no es "una sola factura repetida 50 veces"
El procesamiento de NF-e en Brasil es inusual en un aspecto: los datos de origen ya están estructurados. A diferencia de las facturas en papel de proveedores estadounidenses o europeos que requieren OCR para digitalizarse, cada NF-e llega como un archivo XML que ya ha sido validado según más de 400 reglas de SEFAZ y firmado digitalmente con un certificado ICP-Brasil. La calidad de los datos de una sola NF-e XML es casi perfecta. El problema del lote en la AP brasileña no es la precisión en la captura de datos, sino la consistencia de los datos entre proveedores.
Cuando procesas 50 XML de NF-e de 14 proveedores en un solo lote, surgen cuatro problemas estructurales que el procesamiento de facturas individuales nunca expone:
Fragmentación de la tasa de ICMS. El ICMS de Brasil es un IVA estatal con tasas que varían según el estado del proveedor, tu estado, la dirección de la transacción (intraestatal vs interestatal) y, en algunos casos, la clasificación del producto NCM. Un lote de 50 XML de NF-e de proveedores en 7 estados puede contener tasas intraestatales de 17%, 18%, 19%, 19.5%, 20% y 20.5%, además de tasas interestatales de 4%, 7% o 12% según los pares de origen y destino. Una columna "Monto de ICMS" en tu hoja de cálculo no tiene sentido a menos que también conozcas la tasa, el estado aplicable y si la transacción es interna o interestatal — porque el mismo cargo de R$1,000 de ICMS puede significar una tasa del 17% sobre una base de R$5,882 o una tasa del 12% sobre una base de R$8,333. El módulo fiscal de tu ERP necesita la distinción.
Inconsistencias de CFOP. Cada item de una NF-e lleva un código CFOP de 4 dígitos que clasifica la naturaleza fiscal de la operación — 1.101 para compra para industrialización dentro del mismo estado, 2.102 para compra interestatal para reventa, 3.101 para importación. El primer dígito indica si la transacción es intraestatal (1), interestatal (2) o importación internacional (3). Cuando el proveedor A usa CFOP 1.101 para un envío de São Paulo a su almacén en São Paulo, y el proveedor B usa CFOP 2.102 para un envío interestatal de Minas Gerais, es correcto y deliberado. Pero si el proveedor C usa CFOP 1.101 en un envío originado en Río de Janeiro — una transacción interestatal — el CFOP no coincide con los datos de estado en los bloques <ide> y <emit> del XML. Esa discrepancia generará una alerta de auditoría en el SPED EFD, el sistema federal de escrituración digital que cruza códigos CFOP en toda la cadena de suministro. En un lote de 50 facturas, son comunes de 3 a 5 discrepancias — y encontrarlas manualmente implica revisar el CFOP de cada XML contra su par de estado origen-destino.
Fallo en la detección de duplicados solo por número de factura. En la mayoría de los sistemas de cuentas por pagar, la detección de duplicados se basa en el proveedor y el número de factura. Esta lógica falla con la NF-e brasileña porque el número de factura (número da nota) solo es único dentro de la serie de un proveedor. El proveedor A puede emitir la NF-e #1523 en la serie 001, mientras que el proveedor B también emite la NF-e #1523 en su serie 001. Incluso el mismo proveedor puede emitir números de factura idénticos en series diferentes. El identificador único global es la chave de acesso de 44 dígitos, pero la mayoría de las herramientas de extracción por lotes no la extraen, o la extraen sin entender su función como clave de desduplicación. Sin la chave de acesso, dos facturas diferentes de dos proveedores distintos con el mismo número de factura se marcarán como duplicadas y una se suprimirá, o peor aún, una factura reenviada con una chave de acesso corregida (que indica un evento de carta de corrección CCe) no se reconocerá como un reemplazo.
Fuentes de formato mixto. En un lote de 50 facturas de proveedores brasileños, rara vez se obtienen 50 XML limpios. Algunos proveedores, generalmente fabricantes más pequeños o productores agrícolas, envían solo el DANFE impreso como PDF o escaneado. Algunos envían el XML pero adjuntan un DANFE escaneado con anotaciones manuscritas. Un proveedor industrial mediano podría enviar el XML de la NF-e principal, pero el CT-e de flete (Conocimiento de Transporte Electrónico) como PDF. El flujo de trabajo de procesamiento por lotes debe manejar todos estos en una sola pasada: extrayendo datos estructurados del XML cuando esté disponible y leyendo el documento visual cuando falte el XML, y fusionando todo en columnas coherentes.
Estos cuatro problemas no existen con una factura. Con 50, los cuatro se activan simultáneamente, y resolverlos es lo que diferencia un flujo de trabajo de procesamiento por lotes de "extracción única, repetida 50 veces".
La Matriz de Tasas de ICMS en 7 Estados — Por Qué una Sola Columna de "Impuesto" Falla
Las alícuotas internas de ICMS en Brasil cambiaron significativamente en 2024, en parte anticipándose a la reforma tributaria que eventualmente reemplazará el ICMS con el nuevo IBS (Imposto sobre Bens e Serviços) entre 2029 y 2033. Once estados brasileños modificaron sus alícuotas estándar de ICMS el año pasado:
| Estado (UF) | Tasa Anterior | Tasa 2024–2026 | Fecha de Vigencia |
|---|---|---|---|
| Pernambuco | 18% | 20.5% | Ene 2024 |
| Ceará | 18% | 20% | Ene 2024 |
| Paraíba | 18% | 20% | Ene 2024 |
| Bahia | 19% | 20.5% | Feb 2024 |
| Maranhão | 20% | 22% | Feb 2024 |
| Paraná | 19% | 19.5% | Mar 2024 |
| Goiás | 17% | 19% | Abr 2024 |
| Rondônia | 17.5% | 19.5% | Ene 2024 |
| Distrito Federal | 18% | 20% | Ene 2024 |
| Espírito Santo | 17% | 19.5% | Abr 2024 |
| Rio Grande do Norte | 20% | 18% | Ene 2024 |
Fuentes: Vertex Inc., actos legislativos estatales (Leis Estaduais). São Paulo se mantuvo en 18%, Minas Gerais en 18%, Río de Janeiro en 20% (en el mismo período, con un aumento propuesto al 22% aún en debate legislativo).
La consecuencia práctica para el procesamiento por lotes: si tu base de proveedores abarca más de dos estados brasileños, tu hoja de cálculo de lotes debe registrar el ICMS a nivel de alícuota × estado × tipo de transacción, no en una sola columna que sume todos los valores de ICMS. Una NF-e de un proveedor en Pernambuco (20,5% intraestatal) y una NF-e de un proveedor en São Paulo (18% intraestatal) tendrán un tratamiento diferente del ICMS en tu ERP, incluso si la columna del monto de ICMS muestra la misma cifra.
Las alícuotas interestatales agregan una segunda dimensión, codificada según la ley tributaria brasileña:
| Región de origen | Región de destino | Alícuota interestatal |
|---|---|---|
| Sur y Sudeste (SP, RJ, MG, PR, SC, RS, ES) | Sur y Sudeste | 12% |
| Norte, Nordeste y Centro-Oeste | Cualquier estado brasileño | 12% |
| Sur y Sudeste | Norte, Nordeste y Centro-Oeste (incl. ES) | 7% |
| Cualquier estado — bienes importados con >40% de contenido extranjero | Cualquier estado | 4% |
Combine estos niveles de alícuotas interestatales con los 11 cambios de alícuotas estatales anteriores, y un lote de XML de NF-e de proveedores de 7 estados puede contener fácilmente 5 alícuotas de ICMS diferentes — cada una debe identificarse, separarse por tipo y registrarse en la cuenta fiscal correcta de su ERP. Las herramientas que extraen el ICMS como un solo número sin capturar la alícuota, el estado de origen y el tipo de transacción del XML generan una hoja de cálculo que crea más trabajo de conciliación del que ahorra.
Aquí es donde extraer directamente de la estructura del XML de la NF-e — no mediante OCR del DANFE — rinde a granel. El bloque <imposto> del XML contiene grupos de elementos separados para ICMS, IPI, PIS y COFINS, cada uno con la base de cálculo (vBC), la alícuota (pICMS, pIPI, etc.) y el valor (vICMS, vIPI, etc.) a nivel de ítem. Una extracción basada en nombres de columna que asigna estos campos estructurados — "Base ICMS", "Alícuota ICMS (%)", "Valor ICMS", "Valor IPI", "Valor PIS", "Valor COFINS" — a columnas separadas en la hoja de cálculo produce una tabla donde cada importe de impuesto se puede rastrear hasta su alícuota y base, sin necesidad de recálculo manual. Para un desglose detallado de la estructura del XML de la NF-e y el mapeo de campos, consulte la guía completa de extracción de XML de la NF-e.
Consistencia del Código CFOP entre Proveedores — La Bandera de Auditoría que Nadie Revisa en Lotes
Los códigos CFOP son clasificaciones de operaciones fiscales de 4 dígitos incorporadas en cada ítem de la NF-e. Existen más de 500 códigos CFOP definidos por las autoridades fiscales brasileñas, organizados por el primer dígito:
| Primer dígito | Significado | Ejemplo (Compra) |
|---|---|---|
| 1 | Entrada intraestatal (mismo estado) | 1.101 – Compra para industrialización |
| 2 | Entrada interestatal (diferentes estados) | 2.102 – Compra interestatal para reventa |
| 3 | Importación internacional | 3.101 – Importación para industrialización |
| 5 | Salida intraestatal (ventas) | 5.101 – Venta de producción propia |
| 6 | Salida interestatal (ventas) | 6.102 – Venta interestatal de bienes de terceros |
| 7 | Exportación | 7.101 – Exportación de producción propia |
Em uma única NF-e, uma divergência de CFOP é fácil de identificar: se o estado do fornecedor é Minas Gerais e sua empresa está em São Paulo, todo CFOP deve começar com 2 (entrada interestadual). Se um item exibe CFOP 1.101 — intraestadual — há um erro de dados. Em escala, com 50 notas fiscais de vários fornecedores, esse tipo de validação se torna essencial e complexa. Um fornecedor pode usar corretamente o CFOP 1.101 para remessas locais (para seus próprios clientes), mas deve usar 2.101 ao enviar para você entre estados. Se o ERP dele preencheu automaticamente o CFOP errado, você herda uma exposição fiscal que o SPED EFD detectará — pois o sistema de escrituração digital cruza os registros de CFOP do comprador e do vendedor para cada transação. Uma divergência entre seu CFOP de entrada e o CFOP de saída correspondente do fornecedor gera uma marcação automática de auditoria.
A validação em lote de CFOP significa verificar três relações para cada item do lote:
- Primeiro dígito vs par de estados. O primeiro dígito do CFOP deve corresponder à situação de mesma UF (1/5) ou UFs diferentes (2/6) entre fornecedor e comprador. Extraia o código IBGE do estado dos blocos
<emit>e<dest>— códigos 35 (SP), 33 (RJ), 31 (MG), 41 (PR), etc. — e valide o prefixo do CFOP conforme a determinação de mesma UF ou UF diferente. - Consistência do sufixo do CFOP em operações similares. Se o fornecedor A usa CFOP 2.102 (compra interestadual para revenda) e o fornecedor B usa CFOP 2.101 (compra interestadual para industrialização) para o mesmo tipo de produto, pelo menos um deles está errado — o sufixo do CFOP deve refletir a finalidade real da transação.
- Sem contradição entre CFOP e NCM. O CFOP codifica a natureza da operação, o NCM codifica a classificação do produto. Um CFOP que sugere insumo industrial combinado com um NCM de produto final de consumo é um sinal de alerta — significa que ou o CFOP ou o NCM está incorreto, e ambos afetam o tratamento tributário.
A validação manual de CFOP em 50 NF-e com 2 a 15 itens cada, cada um com seu próprio CFOP, leva meio dia e tem alta taxa de erro. A extração em lote que captura CFOP, NCM, UF do fornecedor e UF do comprador em colunas separadas permite uma verificação condicional simples: se UF(emit) ≠ UF(dest) E prefixo_CFOP ≠ 2, sinalize a linha. Essa única regra detecta 80% dos erros de CFOP em um lote com múltiplos fornecedores.
A Chave de Acesso de 44 Dígitos — A Chave de Deduplicação Nativa do Brasil que a Maioria das Ferramentas em Lote Ignora
A chave de acesso é uma string de 44 dígitos que identifica de forma única cada NF-e emitida no Brasil, para sempre. Não é apenas um número de referência — é um identificador estruturado que codifica o estado do emissor (primeiros 2 dígitos, conforme código IBGE), ano-mês de emissão (próximos 4), CNPJ do emissor (próximos 14), modelo do documento (2), série (3), número sequencial (9), tipo de emissão (1), código aleatório de colisão (8) e um dígito verificador módulo 11 (1). Todo XML de NF-e carrega essa chave no atributo <infNFe Id="NFe[chave]"> e no elemento <chNFe>. É o mais próximo de um identificador global único de fatura que qualquer sistema tributário no mundo oferece.
No entanto, a maioria das ferramentas de lote extrai uma coluna "Número da Nota Fiscal" e encerra. No Brasil, essa coluna não é suficiente:
- O Fornecedor A pode emitir NF-e #1523 na série 001 e NF-e #1523 na série 002 — mesmo número de nota, dois documentos fiscais completamente diferentes, distinguíveis apenas pela série e chave de acesso.
- O Fornecedor B pode emitir NF-e #1523 em sua própria série 001 — mesmo número de nota do Fornecedor A, fornecedor diferente, transação diferente — e uma verificação simples de duplicidade por fornecedor+número da nota suprimirá uma como duplicata.
- O sistema de cancelamento e correção da SEFAZ depende da chave de acesso. Quando um fornecedor emite uma Carta de Correção (CCe) para corrigir um erro na NF-e original, a chave de acesso original permanece válida — mas o histórico de eventos vinculado a essa chave registra a correção. Uma ferramenta de lote que não rastreia a chave não consegue distinguir entre a versão original e a corrigida.
Em um lote de 50 XMLs de NF-e, extraia a chave de acesso como uma coluna própria. Em seguida, implemente três verificações:
- Unicidad dentro del lote. No debe haber dos filas con la misma chave de acesso. Si las hay, la misma NF-e se cargó dos veces: suprima la fila duplicada y marque la incidencia.
- Unicidad del número de factura dentro de proveedor × serie. Agrupe por CNPJ + serie + número de factura. Si la misma combinación aparece dos veces con diferentes chaves de acesso, una es probablemente una corrección: la chave con la fecha de emisión más reciente prevalece.
- Verificación SEFAZ para facturas de alto valor. Para facturas que superen un umbral de materialidad, use la chave de acesso para consultar el portal público de SEFAZ o una API de terceros como la consulta NF-e de TF Fiscal para verificar el estado de autorización (Autorizada/Cancelada/Denegada). Una NF-e cancelada en su lote significa que el proveedor la reemitió — y usted necesita la chave de reemplazo.
Los 44 dígitos pueden parecer intimidantes para el personal de AP no brasileño. Pero son la clave de desduplicación más confiable disponible en cualquier régimen de facturación electrónica a nivel global. No usarlos en el procesamiento por lotes es como tener un número de seguro social e identificar a las personas por su nombre de pila.
El Lote Mixto XML + DANFE — Cuando Algunos Proveedores Envían la Factura Completa y Otros Solo Papel
Los proveedores brasileños más grandes — especialmente fabricantes industriales y distribuidores que usan SAP, TOTVS Protheus u Oracle — envían el XML de la NF-e como rutina. Es generado por su ERP, firmado con su certificado ICP-Brasil y transmitido a SEFAZ automáticamente. Enviarlo al comprador junto con el DANFE es una operación de un solo clic.
Proveedores más pequeños — cooperativas agrícolas, proveedores de servicios locales, algunos proveedores de materiales de construcción — pueden no tener la infraestructura ERP para gestionar la transmisión XML. Imprimen el DANFE, se lo entregan al camionero, y ese es el único documento que ve el comprador. La factura es real, ha sido autorizada por SEFAZ (el protocolo de autorización está impreso en el DANFE), pero el departamento de cuentas por pagar receptor solo tiene un PDF escaneado o una fotografía del documento en papel.
Un flujo de trabajo de cuentas por pagar por lotes que maneja solo XML o solo PDF obliga al equipo de cuentas por pagar a dividir su ingreso mensual de facturas en dos procesos separados — uno para XML estructurado, otro para DANFEs escaneados — y luego fusionar manualmente los resultados en un solo asiento contable. El costo de fragmentación es real: sesiones de carga separadas, revisiones separadas y un paso de conciliación al final para asegurar que todas las facturas del mismo proveedor (algunas XML, otras PDF) lleguen al mismo lote de cuentas por pagar.
Extracción de Columnas Personalizadas — el enfoque de ImageToTable.ai de extraer datos por significado del campo en lugar de por coordenadas de plantilla — maneja ambas fuentes en una sola carga por lotes. Usted define los nombres de sus columnas una vez: "Chave de Acesso", "CNPJ del Proveedor", "Nombre del Proveedor", "Número de NF-e", "Serie", "Fecha de Emisión", "CFOP", "NCM", "Descripción del Artículo", "Cantidad", "Precio Unitario", "Total del Artículo", "Base ICMS", "Tasa ICMS", "Monto ICMS", "Monto IPI", "Monto PIS", "Monto COFINS", "Valor Total NF-e". La IA lee datos estructurados de archivos XML donde los campos son legibles por máquina, y extrae los mismos campos de DANFEs escaneados en PDF al entender visualmente qué significa cada etiqueta — independientemente del diseño. Ambas fuentes se fusionan en la misma hoja de cálculo, con las mismas columnas, en un solo lote.
La ventaja práctica no es solo la velocidad, sino la consistencia. La columna de chave de acesso de los archivos XML se extrae directamente del elemento <chNFe>. La misma columna de un escaneo de DANFE se lee del código de barras de 44 dígitos en la esquina superior derecha del documento impreso. Ambas entradas llegan a la misma columna, permitiendo la misma lógica de deduplicación descrita anteriormente. Sin un flujo de trabajo por lotes unificado, la chave de acesso del lote XML y la chave de acesso del lote de DANFE escaneado viven en hojas de cálculo separadas, y la detección de duplicados entre ellas es manual.
La Transición de la Reforma Tributaria 2026–2033 — Cumplimiento Dual en un Solo Lote
La reforma del impuesto al consumo de Brasil — promulgada mediante la Enmienda Constitucional 132 de diciembre de 2023 y regulada por la Ley Complementaria 214 de enero de 2025 — está reestructurando todo el sistema de impuestos indirectos del país durante una transición de ocho años. Para 2033, cinco impuestos heredados (PIS, COFINS, IPI, ICMS e ISS) serán reemplazados por un sistema de IVA dual: el CBS federal (Contribuição sobre Bens e Serviços) y el IBS estatal-municipal (Imposto sobre Bens e Serviços), más un Impuesto Selectivo (IS) sobre bienes nocivos para la salud y el medio ambiente. La transición comenzó el 1 de enero de 2026.
Para los equipos de AP que procesan lotes de NF-e brasileños, la preocupación operativa inmediata es el cumplimiento dual en el esquema XML. Durante los años de transición, los XML de NF-e contendrán simultáneamente campos de impuestos heredados (ICMS, IPI, PIS, COFINS) y nuevos campos de impuestos (CBS, IBS), lo que significa que el ya complejo XML de NF-e con más de 500 campos se volverá más grande. Este es el cronograma que afecta el diseño de extracción por lotes:
| Año | Estado de impuestos antiguos | Estado de nuevos impuestos | Impacto en extracción por lotes |
|---|---|---|---|
| 2026 | ICMS, PIS, COFINS, IPI totalmente activos | CBS 0,9% + IBS 0,1% tasas de prueba (deducibles de PIS/COFINS, sin carga adicional neta) | El esquema XML de NF-e ahora incluye campos CBS/IBS junto con los antiguos. La extracción debe analizar ambos, incluso si las tasas de prueba no cambian la obligación tributaria neta. |
| 2027 | PIS, COFINS eliminados. ICMS, IPI permanecen. | CBS totalmente aplicada a tasas completas | El XML de NF-e elimina grupos PIS/COFINS, mantiene ICMS/IPI, agrega CBS. Las definiciones de columnas cambian a mitad de año para algunos proveedores. |
| 2029–2032 | Las tasas de ICMS bajan 10%/año (90% en 2029 → 60% en 2032). ISS e IPI se reducen gradualmente. | Las tasas de IBS suben proporcionalmente (10% en 2029 → 40% en 2032) | Los valores de la columna de tasa ICMS disminuyen año tras año. Los valores de la columna IBS aumentan. Las comparaciones entre años requieren etiquetado de tasa-año. |
| 2033 | ICMS, ISS, IPI eliminados | CBS + IBS totalmente operativos | El XML de NF-e contiene solo grupos de impuestos CBS + IBS. Corte limpio, pero los datos históricos para auditorías conservan la estructura antigua. |
La implicación práctica para la extracción por lotes en 2026: si estás definiendo columnas ahora, incluye las columnas CBS e IBS junto a las de ICMS y PIS/COFINS, aunque sea con tasas de prueba. Los datos ya están en el XML hoy. Extraerlos no cuesta nada. Tenerlos en tu hoja de cálculo cuando la transición se acelere en 2027 significa que tus datos históricos por lotes ya contienen la base para informes basados en CBS, sin necesidad de reextraer retroactivamente XML de NF-e archivados de 2026.
Un sistema de extracción por lotes que lea nombres de campos semánticamente — "Base ICMS", "Tasa ICMS", "Base CBS", "Tasa CBS", etc. — maneja esta transición sin reconfiguración por proveedor. Las definiciones de columna siguen siendo las mismas; la IA encuentra los campos impositivos presentes en la versión actual del esquema XML. A medida que las actualizaciones de la Nota Técnica agreguen nuevos campos y eliminen antiguos en los próximos siete años, la lógica de extracción se adapta al XML que llega, no a una plantilla que deba reconstruirse cada vez que SEFAZ publique una nueva versión de diseño.
Un Flujo de Procesamiento por Lotes de NF-e que Supera el Cierre de Mes
Con los problemas estructurales mapeados, aquí hay una secuencia de procesamiento por lotes diseñada para la realidad de la AP brasileña multi-proveedor y multi-estado:
- 1Recolecta y normaliza los archivos fuente. Reúne todos los XML de NF-e, PDF de DANFE y documentos de flete CT-e del período del lote (generalmente mensual). Renombra los archivos con una convención uniforme —
{CNPJ}_{NF-eNumber}_{Series}_{IssueDate}.xml— para que la trazabilidad del origen quede en el nombre. No descartes los nombres originales; agrégalos como metadatos. - 2Define las columnas de extracción una vez, para todos los proveedores. Configura nombres de columna que cubran todos los datos de NF-e que necesitas: identificadores del proveedor (CNPJ, Razão Social, Inscrição Estadual), identificadores del documento (Chave de Acesso, Número, Série, Data de Emissão), ítems (NCM, CFOP, Descrição, Quantidade, Preço Unitário, Total da Linha) e impuestos (Base ICMS, Alíquota ICMS, Valor ICMS, Valor IPI, Base PIS, Valor PIS, Base COFINS, Valor COFINS, Valor Total da NF-e). Incluye columnas CBS e IBS para la transición de 2026. Estos nombres funcionan con todos los proveedores porque la extracción lee el significado del campo, no su posición — el mismo enfoque que usas al extraer datos de facturas a Excel por lotes con formatos mixtos de proveedores.
- 3Sube todo el lote en una sola sesión. Arrastra los 50 archivos — XML, PDF, escaneos — al área de carga. El sistema los procesa juntos y combina la salida en una sola hoja de cálculo. Cada fila se etiqueta con su archivo fuente para trazabilidad.
- 4Ejecuta las tres validaciones por lote. (a) Verificación de unicidad de la Chave de acesso — sin duplicados. (b) Par primer dígito del CFOP vs. estado — marca discrepancias donde un CFOP intraestatal (1xxx) aparece en transacciones interestatales. (c) Razonabilidad de la tasa de ICMS — compara las tasas extraídas con las esperadas por estado. Un ICMS del 20,5% en un proveedor de São Paulo (18% intraestatal, 7–12% interestatal) indica un proveedor mal clasificado de Pernambuco o un error de datos. Marca para revisión.
- 5Separa por tratamiento fiscal para contabilización en ERP. Usa las columnas extraídas de Tasa de ICMS y Estado de Origen para agrupar filas en lotes de contabilización: entradas intraestatales (tasa = 17–22%), interestatales al 12%, interestatales al 7% y al 4% (bienes importados). Cada grupo se contabiliza en cuentas fiscales distintas en tu ERP. La misma lógica de agrupación aplica a las columnas de IPI, PIS y COFINS.
Este flujo asume que tu herramienta de extracción por lotes puede manejar documentos XML y visuales en la misma sesión de carga — porque la AP brasileña rara vez recibe un solo formato exclusivamente. Si tu proceso actual requiere un flujo separado para el análisis de XML y otro para el OCR de PDF, el paso de fusión en el paso 5 duplica tu tiempo de procesamiento e introduce el riesgo de mapeos de columna inconsistentes entre los dos pipelines.
Preguntas Frecuentes
¿Puede el procesamiento por lotes manejar XML de NF-e y PDF de DANFE en la misma carga?
Sí — si la herramienta de extracción interpreta la semántica en lugar de depender solo del análisis XML. La extracción semántica lee las etiquetas estructuradas del XML de la NF-e para datos que existen en ambos formatos (CNPJ, número de NF-e, totales, montos de impuestos) y lee visualmente el DANFE cuando solo está disponible el documento impreso. El resultado se fusiona en una sola hoja de cálculo con columnas consistentes. Si tu herramienta solo analiza XML o solo hace OCR, necesitarás dos flujos de trabajo separados y un paso de fusión manual.
¿Qué sucede cuando dos XML de NF-e tienen el mismo número de factura pero diferente chave de acesso?
Es un escenario legítimo — generalmente una NF-e corregida reemitida tras un evento CCe, o dos documentos NF-e de series diferentes con el mismo número secuencial. La chave de acesso es única en ambos casos. Tu validación por lotes debe agrupar por chave de acesso (no por número de factura) para deduplicar, y conservar la relación entre número de factura, serie y chave para fines de auditoría. Si el mismo CNPJ + serie + número de factura aparece con dos chaves de acesso diferentes, revisa las marcas de tiempo de emisión — la chave posterior reemplaza a la anterior.
¿Cómo manejo el ICMS-ST (sustitución tributaria) en un lote?
El ICMS-ST aparece en el XML de la NF-e como un grupo de impuestos separado (<ICMSTot> en el bloque de totales) con su propia base, tasa y monto. Debe extraerse en columnas separadas ("Base ICMS-ST", "Monto ICMS-ST") — no fusionarse con el ICMS regular. El ICMS-ST representa impuestos ya pagados aguas arriba por un contribuyente sustituto, y tu ERP lo trata de manera diferente al ICMS regular para fines de crédito. Mezclarlos en una sola columna "ICMS" inflará tus créditos disponibles.
¿Puedo extraer solo ítems específicos de una NF-e en lugar de todos?
Sí. Al definir tus columnas de extracción, incluye los campos que necesites a nivel de ítem (NCM, CFOP, descripción, cantidad, precio unitario, total del ítem e impuestos por línea). La IA extrae cada ítem de cada NF-e que coincida con la definición de tus columnas. Si solo necesitas ciertas columnas —por ejemplo, NCM + cantidad + CFOP, sin precio unitario— omite las columnas no deseadas de tu definición. La extracción produce solo lo que solicitas.
¿La reforma tributaria de 2026 cambia lo que necesito extraer de los XML de NF-e?
En 2026, el esquema XML de la NF-e ahora incluye campos de CBS e IBS con tasas de prueba (0,9% y 0,1%, respectivamente) junto a los campos existentes de ICMS, PIS y COFINS. Estas tasas de prueba son totalmente deducibles de PIS/COFINS, por lo que la obligación tributaria neta no cambia. Sin embargo, los campos existen en el XML y deben extraerse ahora —cuando CBS reemplace a PIS/COFINS con tasas completas en 2027, las definiciones de tus columnas de extracción por lotes ya estarán listas. El cronograma de la reforma tributaria está codificado en la Ley Complementaria 214/2025 y el análisis de 2025 de la OCDE sobre la reforma.
¿Por cuánto tiempo debo conservar los XML de NF-e y los registros de extracción?
La legislación tributaria brasileña exige que los XML de NF-e y los documentos fiscales relacionados se archiven por un mínimo de cinco años a partir del cierre del ejercicio fiscal en que ocurrió la transacción. Esto aplica tanto a los XML originales recibidos de proveedores como a tus registros de extracción. El DANFE no es un sustituto legalmente suficiente del XML durante una auditoría —si solo conservaste el DANFE escaneado y descartaste el XML, no podrás reconstruir el registro fiscal completo que SEFAZ solicitará. Buena práctica: archiva los XML tal cual y mantén la hoja de cálculo de extracción como un registro separado y buscable para conciliación interna.