Procesar facturas Facturae XML recibidas: guía del receptor

Para procesar una factura Facturae XML recibida, el receptor abre el fichero con un visor (el Visualizador Facturae de firma-e, XolidoSign Desktop o el visor web de facturadirecta.com), valida la firma electrónica XAdES embebida y extrae los datos del libro de facturas recibidas: NIF y razón social del emisor, número y serie, fecha de expedición, base imponible, tipo y cuota de IVA, retenciones e importe total. A partir de 2026, el flujo no termina al asentar la factura: bajo el artículo 12 del Real Decreto 238/2026, el receptor también debe comunicar el pago efectivo completo de la factura a la solución pública de facturación electrónica, con independencia de si se ha utilizado la solución pública o una plataforma privada.

Esta guía está pensada para quien recibe los Facturae, no para quien los emite: empleados de cuentas a pagar, contables internos y asesores que abren un .xsig adjunto al correo y necesitan convertirlo en filas del libro de facturas recibidas y en un asiento contable, no en una explicación de qué es Facturae. El recorrido va de abrir el fichero a asentarlo, pasando por la validación de la firma, el mapeo XPath-a-libro y la decisión de cuándo el procesamiento manual deja de tener sentido.

Hay un cambio adicional que conviene tener delante desde el principio: tras la entrada del mandato Crea y Crece en B2B, el proveedor puede emitir la factura en Facturae 3.2.2 o en sintaxis UBL alineada con la norma europea EN16931. Ambos formatos son válidos y ambos pueden llegar a la misma bandeja en el mismo mes. El flujo del receptor tiene que tratar a los dos.

Qué hay realmente dentro de un Facturae XML 3.2.2

El esquema vigente que el receptor encuentra en producción es Facturae 3.2.2, dentro de la familia 3.2.x. Las versiones anteriores 3.2 y 3.2.1 todavía aparecen en facturas históricas y archivos antiguos, pero las facturas nuevas que llegan al sector público y, cada vez más, al B2B se emiten en 3.2.2. Para el flujo del receptor las diferencias son menores y no requieren tratamiento separado: el mapeo a las columnas del libro funciona igual en las tres versiones del 3.2.

El cambio relevante que introduce 3.2.2 está en los datos de referencia que el comprador puede usar para conciliar la factura con su pedido o su contrato. Tres elementos opcionales nuevos importan al receptor:

• ReceiverTransactionReference: referencia de la transacción tal como la conoce el receptor (típicamente, su número de pedido interno).
• FileReference: referencia del expediente o del fichero del comprador.
• ReceiverContractReference: referencia del contrato marco bajo el que se emite la factura.

Cuando el proveedor los rellena, el receptor puede automatizar la conciliación entre factura y pedido sin depender de campos libres ni de coincidencias por importe. Si llegan vacíos, no es un error de la factura; significa que el proveedor no los ha cargado en su sistema de facturación.

Dentro del fichero conviven tres componentes que conviene distinguir:

1. El cuerpo XML con los datos estructurados de la factura: partes, totales, líneas, impuestos, retenciones. Es la fuente de verdad para extracción.
2. La firma electrónica XAdES embebida dentro del propio XML. Vincula el contenido firmado a un certificado y permite verificar que el fichero no se ha alterado tras la firma.
3. La leyenda legible: una representación visual de la factura, normalmente en PDF, que algunos visores generan a partir del XML. Es útil para revisión humana, pero no es la fuente de verdad. Si la leyenda y el XML discrepan en un importe, manda el XML.

La extensión también suele generar dudas: .xml y .xsig contienen exactamente el mismo Facturae firmado. La diferencia es de convención (.xsig señala que el fichero lleva firma XAdES embebida) y no de formato. Cualquier visor del Facturae lee ambas extensiones, y la regulación trata el contenido, no el nombre del fichero.

Si tu trabajo está en el lado opuesto del flujo, es decir, emitir Facturae al sector público a través de FACe, el recorrido es distinto y queda fuera del alcance de esta guía; para ese escenario, la guía de FACe para emisores al sector público español cubre la presentación, el seguimiento y los códigos DIR3. El resto de este artículo asume que el Facturae ya ha llegado a tu bandeja.

Abrir el Facturae XML: visores prácticos y alternativas

Para abrir una factura Facturae XML recibida hay tres herramientas que cubren razonablemente el caso del receptor en España, más la opción de inspeccionar el XML directamente. Ninguna es la mejor en abstracto: encajan distinto según el volumen, si se trabaja conectado o sin conexión, y si la misma persona que recibe también firma facturas de salida.

Visualizador Facturae de firma-e. Utilidad gratuita y web, próxima al ecosistema oficial. Sube el .xml o .xsig, y muestra la representación legible de la factura, los datos de las partes, las líneas, los totales, y el detalle de la firma con el certificado del firmante. Es razonable como primera opción cuando el volumen es bajo, no se quiere instalar software y se necesita una validación rápida con un visor reconocible. La limitación obvia es la dependencia de subir cada fichero al servicio web, lo que no encaja con flujos masivos ni con políticas internas que prohíban exponer facturas a servicios externos.

XolidoSign Desktop. Cliente de escritorio que abre el Facturae, verifica la firma XAdES y también permite firmar ficheros de salida. Encaja bien cuando el receptor también firma documentación propia (presentaciones a la Administración, facturas que sí emite, contratos), porque concentra la operativa de firma en una sola herramienta. Funciona sin conexión, lo que es útil cuando hay restricciones de red o cuando se procesa fuera de oficina. Requiere instalación y mantenimiento, y la actualización de las cadenas de certificados depende del usuario.

Visor de facturadirecta.com. Visor web que renderiza el XML y la leyenda a partir del fichero subido. Útil para una comprobación puntual cuando no merece la pena instalar nada, por ejemplo, cuando alguien fuera del equipo de contabilidad recibe una factura por error y quiere confirmar de qué se trata. No sustituye a las dos anteriores en un flujo diario, pero resuelve bien el caso de uso ocasional.

Queda una alternativa que conviene mencionar para no dejarla en el aire: abrir el XML directamente en un editor de texto o en el navegador. Un Facturae es texto, así que cualquier editor lo muestra y un navegador lo formatea con su árbol XML. La factura se lee, los importes son visibles, y los XPaths quedan a la vista. Lo que no se obtiene es la firma verificada ni una representación de factura como tal; queda como inspección cruda. Para la operativa diaria de un departamento contable es incómodo, pero es la herramienta natural cuando hay que revisar un campo concreto, comparar dos versiones del mismo fichero, o depurar un problema de extracción donde el visor no muestra lo que se busca.

Los criterios para elegir entre ellas son concretos: el volumen mensual de Facturae que se procesa, si se necesita validación de firma in situ o se delega en una herramienta externa, si se trabaja con conexión continua o no, y si la misma persona gestiona también la firma de salida. En la práctica, los equipos pequeños tienden a quedarse con un visor web; los que firman habitualmente, con un cliente de escritorio; y los que reciben volumen alto acaban moviéndose a un flujo distinto, que se trata más adelante.

---

Validar la firma electrónica XAdES en una factura recibida

XAdES es una firma electrónica avanzada sobre XML, embebida dentro del propio Facturae, que vincula el contenido firmado con un certificado del firmante. Para el receptor, lo relevante no es la mecánica criptográfica sino lo que la firma demuestra: que la factura la ha emitido quien dice emitirla, y que el fichero no se ha tocado desde que se firmó.

Al recibir el Facturae, la validación cubre cinco puntos:

• Integridad del contenido firmado. La firma es válida sobre el XML completo y nadie ha alterado el fichero después.
• Emisor del certificado reconocido. El certificado del firmante lo ha emitido una autoridad de certificación admitida por la regulación de firma electrónica (FNMT, ACA, Camerfirma, ANF AC y similares).
• Validez del certificado en el momento de la firma. El certificado no estaba caducado ni revocado cuando se firmó, no solo cuando lo estás validando hoy. Esta distinción importa: una factura firmada hace dos años con un certificado que caducó hace seis meses puede seguir siendo válida si se firmó cuando el certificado estaba vigente.
• Cadena de certificados completa. La cadena desde el certificado del firmante hasta una raíz de confianza está completa y se valida sin huecos.
• Algoritmo de firma admitido. El algoritmo y la longitud de clave son alguno de los aceptados por la regulación vigente. Algoritmos antiguos como SHA-1 ya no se consideran admisibles para firma de facturas.

Cuando la validación falla, el modo de fallo determina la respuesta del receptor:

• Bloqueante. La firma no es válida sobre el contenido (alguien ha modificado el XML, lo más habitual al re-guardarlo desde un editor que cambia codificación o saltos de línea), el certificado estaba revocado en el momento de la firma, o el certificado lo emitió una autoridad no reconocida. La factura no se posta hasta resolverlo. Lo correcto es solicitar al proveedor el fichero original tal como lo emitió, sin manipulación intermedia, o un Facturae re-firmado.
• Recuperable. La firma es técnicamente válida, pero el certificado caducó después. Si el Facturae lleva sello de tiempo (firma XAdES-T o superior), la marca temporal demuestra que la firma se hizo cuando el certificado aún estaba vigente y la factura se acepta. Si no lleva sello de tiempo, hay que pedir al proveedor un Facturae re-firmado con un certificado válido.
• Artefacto de herramienta. El visor local marca un fallo que no se reproduce en VALIDe, la herramienta de validación de la Sede Electrónica de la Administración (valide.gob.es). Suele indicar que el visor está desactualizado o que la cadena de certificados de la autoridad emisora no se ha cargado en el almacén local. La factura es válida; el problema está en la herramienta que la abre.

VALIDe es la referencia natural de contraste cuando el visor del día a día discrepa: subir el .xsig y comparar el resultado cierra la duda sobre si el fallo está en la factura o en el visor. Para flujos diarios, no sustituye al visor de escritorio, pero sí es el árbitro cuando algo no cuadra.

Los detalles más finos del esquema XAdES (perfiles XAdES-T, XAdES-A, sello de tiempo, archivado a largo plazo) importan al emisor que decide cómo firma, y a quien diseña el archivado regulatorio. Para validar una factura recibida y decidir si se posta o no, los cinco puntos de arriba son suficientes.

---

Del XML al libro de facturas recibidas: mapeo de campos

El paso operativo donde la factura se convierte en libro es la extracción de los campos del XML a las columnas que pide el libro de facturas recibidas. La tabla siguiente recoge los elementos del Facturae 3.2.2 que cubren los datos básicos del libro, con XPaths relativos a Facturae/Invoices/Invoice, la columna del libro a la que alimentan y la observación correspondiente para SII y Modelo 303.

Elemento Facturae (XPath relativo a Facturae/Invoices/Invoice)	Columna del libro de facturas recibidas	Observación SII / Modelo 303
/Parties/SellerParty/TaxIdentification/TaxIdentificationNumber	NIF emisor	Identificador del emisor en SII y para deducción del IVA soportado en el 303
/Parties/SellerParty/LegalEntity/CorporateName (o /Parties/SellerParty/Individual/Name cuando el emisor es persona física)	Razón social emisor	Nombre o razón social en el libro
/InvoiceHeader/InvoiceNumber (con /InvoiceHeader/InvoiceSeriesCode si aplica)	Número y, en su caso, serie	Número de factura del emisor en SII
/InvoiceIssueData/IssueDate	Fecha de expedición	Fecha de expedición en SII
/InvoiceIssueData/OperationDate (cuando difiere de la expedición)	Fecha de operación	Fecha de operación en SII; afecta al periodo de devengo
/InvoiceTotals/TotalGrossAmountBeforeTaxes	Total bruto antes de impuestos	Total agregado a nivel factura, antes de IVA y retenciones
/TaxesOutputs/Tax/TaxableBase/TotalAmount	Base imponible por tipo de IVA	Casillas de base imponible en el 303 desglosadas por tipo
/TaxesOutputs/Tax/TaxRate	Tipo IVA	Determina la casilla del 303 (general, reducido, superreducido)
/TaxesOutputs/Tax/TaxAmount/TotalAmount	Cuota IVA	Cuota deducible (en general) en el 303
/InvoiceTotals/InvoiceTotal	Importe total factura	Total a registrar en el libro
/TaxesWithheld/Tax/TaxAmount/TotalAmount (con TaxRate para el porcentaje)	Retención IRPF	Reduce el importe a pagar; se declara fuera del 303, en el modelo correspondiente
Entrada adicional dentro de /TaxesOutputs con TaxTypeCode distinto de IVA general (típicamente código 03 para recargo de equivalencia)	Recargo de equivalencia	Casilla específica en el 303 para minoristas en este régimen

La tabla cubre la factura típica. Lo que rompe una extracción ingenua de una sola fila por factura son las casuísticas habituales que el receptor encuentra en la práctica:

• Múltiples tipos de IVA en la misma factura. Cada tipo aparece como un nodo Tax independiente dentro de TaxesOutputs. El número de filas a leer es el número de elementos Tax, no uno solo. En el libro, según la herramienta contable, cada tipo se registra en una fila distinta o en columnas paralelas (base 21, cuota 21, base 10, cuota 10, base 4, cuota 4).
• Recargo de equivalencia. Convive con el IVA general en facturas a minoristas en este régimen; no lo sustituye. En el XML aparece como un nodo Tax adicional con su propia base, tipo y cuota, y el libro lo distingue por columna específica. El total del cliente incluye IVA y recargo, pero el desglose es necesario para liquidar correctamente.
• Retención IRPF. Habitual en facturas de profesionales (autónomos prestando servicios a empresas) y en actividades agrícolas o ganaderas. Está en TaxesWithheld, no en TaxesOutputs. Reduce el importe que el receptor paga, pero la base imponible que viaja al 303 no varía: la retención se ingresa por separado en el modelo correspondiente (111 trimestral para profesionales, 115 para arrendamientos, 190 anual para el resumen). En el libro se registra como columna independiente.
• Líneas de factura para extracción línea a línea. Cuando la imputación analítica exige granularidad por concepto (proyectos, centros de coste, productos), cada InvoiceLine produce una fila propia que repite los campos de cabecera (NIF emisor, número, fecha) y añade los de la línea (descripción, cantidad, precio unitario, importe). El libro de IVA se sigue llevando a nivel factura, pero la hoja auxiliar de extracción puede ser línea a línea para alimentar la analítica.
• Suplidos. Los suplidos pagados por cuenta del cliente quedan fuera de la base imponible aunque aparezcan dentro del importe total a pagar. En el XML están como un nodo separado y no entran en la base que va al 303. Si se ignoran, la base imponible queda inflada y el IVA soportado calculado sobre ella, mal.

El destino útil de este mapeo es una hoja de cálculo, Excel o CSV, con una fila por factura para el libro de IVA, o una fila por línea de factura cuando la imputación analítica lo exige. CSV es el formato habitual cuando la herramienta contable importa un libro externo plano, porque casi cualquier ERP o software contable acepta CSV con separadores conocidos. XLSX preserva mejor los tipos numéricos y de fecha, lo que evita que importes con coma decimal o fechas en formato local se conviertan en texto al abrir el fichero. La elección depende de qué espera el sistema receptor.

Un último anclaje: las columnas que el libro de facturas recibidas exige no las decide la extracción, sino la regulación. Antes de fijar una plantilla de extracción para todo el equipo, conviene revisar los campos obligatorios de la factura completa española para confirmar que la hoja recoge todo lo que el libro debe contener y nada esencial se queda fuera.

Asentar la factura recibida en la contabilidad

Una vez extraídos los campos del Facturae a la hoja, la imputación contable de una factura recibida sigue un patrón estable. El asiento típico de una factura de proveedor con IVA soportado descompone el importe total en tres movimientos:

• Cargo a la cuenta de gasto correspondiente (grupo 6) o a una cuenta de inversión (grupo 2) por la base imponible.
• Cargo a la cuenta 472 (Hacienda Pública, IVA soportado) por la cuota de IVA.
• Abono a la cuenta 400 (Proveedores) cuando el emisor suministra bienes que se revenden o se incorporan al ciclo productivo, o a la cuenta 410 (Acreedores por prestaciones de servicios) cuando se trata de servicios. El importe abonado es el total de la factura (base más cuota), que es la deuda que se reconoce hasta el pago.

Hay dos matices habituales que el flujo del receptor encuentra cada mes:

• Si la factura incluye retención IRPF (típica en facturas de profesionales y en actividades agrícolas), aparece una cuenta adicional, normalmente 4751 (Hacienda Pública, acreedora por retenciones practicadas), por el importe retenido. El abono a la cuenta del proveedor se reduce en esa misma cifra, porque el receptor paga la factura menos la retención e ingresa la retención a Hacienda en el modelo correspondiente.
• Cuando coexisten varios tipos de IVA o aparece recargo de equivalencia, la cuenta 472 se desglosa en subcuentas auxiliares (472.21, 472.10, 472.04, 4757 para recargo) para que la preparación del Modelo 303 desde el libro de recibidas no requiera reconstruir el desglose desde el libro auxiliar. El detalle ya viaja en el asiento.

Los datos que el libro de facturas recibidas debe contener vienen marcados por la regulación de facturación: identificación del emisor (NIF y razón social), número y, en su caso, serie, fecha de expedición y, cuando difiere, fecha de operación, base imponible por tipo, tipo y cuota de IVA, total y tratamiento del IVA aplicable (régimen general, recargo de equivalencia, inversión del sujeto pasivo, exenciones). Si la hoja de extracción del paso anterior cubre estas columnas, el libro se alimenta directamente desde ella.

Esta sección no sustituye al criterio del responsable contable ni al plan de cuentas concreto de cada empresa, que puede tener subcuentas propias o reglas de imputación distintas. El propósito aquí es asegurar que el flujo de extracción produce datos que el asiento posterior puede consumir sin trabajo manual añadido y sin tener que recuperar información del XML una segunda vez.

---

Convivencia de Facturae y UBL EN16931 bajo el Real Decreto 238/2026

El Real Decreto 238/2026 publicado en el BOE desarrolla la obligación de facturación electrónica entre empresas y profesionales que introdujo la Ley Crea y Crece, y consolida una decisión que importa al receptor: las facturas B2B pueden emitirse en Facturae o en sintaxis UBL alineada con la norma europea EN16931, y ambas son válidas. El receptor no elige el formato. Lo elige cada proveedor según su propio sistema de facturación, lo que significa que en una misma bandeja conviven los dos.

El mapeo a las columnas del libro de facturas recibidas es el mismo en los dos formatos, el libro lo decide la regulación tributaria, no el formato del fichero, pero las rutas de los campos cambian. La tabla siguiente muestra la equivalencia para los datos básicos del libro:

Columna del libro	Elemento Facturae 3.2.2	Elemento UBL EN16931
NIF emisor	Parties/SellerParty/TaxIdentification/TaxIdentificationNumber	cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID
Razón social emisor	Parties/SellerParty/LegalEntity/CorporateName	cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName
Número de factura	InvoiceHeader/InvoiceNumber	cbc:ID
Fecha de expedición	InvoiceIssueData/IssueDate	cbc:IssueDate
Base imponible	InvoiceTotals/TotalGrossAmountBeforeTaxes	cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount
Tipo IVA	TaxesOutputs/Tax/TaxRate	cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:Percent
Cuota IVA	TaxesOutputs/Tax/TaxAmount/TotalAmount	cac:TaxTotal/cbc:TaxAmount
Importe total	InvoiceTotals/InvoiceTotal	cac:LegalMonetaryTotal/cbc:PayableAmount
Retención	TaxesWithheld/Tax/TaxAmount/TotalAmount	cac:AllowanceCharge con cbc:AllowanceChargeReasonCode propio para retención

Lo que merece la pena estandarizar internamente es la representación canónica del libro: las columnas que el receptor necesita en su hoja de extracción (NIF, razón social, número, fecha, base, tipo IVA, cuota IVA, retención, total) y las reglas de tratamiento de las casuísticas (múltiples tipos, recargo, suplidos, retenciones). Una vez fijada esa representación, ambos formatos se traducen a la misma forma de salida y la herramienta contable consume una sola plantilla. Mantener dos flujos paralelos, uno para Facturae y otro para UBL, multiplica el mantenimiento sin necesidad: las diferencias de ruta están en la traducción, no en el destino.

El RD 238/2026 introduce también una obligación que no existía en el flujo previo del receptor y que conviene tener clara desde el principio. El artículo 12 del Real Decreto 238/2026 obliga al receptor a comunicar el pago efectivo completo de las facturas a la solución pública de facturación electrónica, con independencia de si se ha utilizado la solución pública o una plataforma privada. Es decir: aunque el proveedor envíe la factura por una plataforma privada y la conciliación se gestione fuera de la solución pública, el receptor está obligado a notificar a la solución pública el momento en que la factura queda pagada al cien por cien.

La implicación operativa es directa. El flujo del receptor ya no termina al asentar la factura y reconocer la deuda. Incorpora una comunicación posterior, en el momento del pago efectivo, que afecta al diseño del proceso interno: qué dispara la comunicación (la conciliación bancaria, normalmente), en qué plazo se envía, desde qué sistema sale el aviso, y quién lo supervisa. Para empresas con volumen de Facturae alto, la comunicación de pagos no es un trámite manual viable: se ata al proceso de conciliación o al ERP y se resuelve por automatización. Para volumen bajo, se mantiene como tarea recurrente del equipo de pagos.

Esta sección queda dentro del flujo del receptor, sin entrar en el detalle de los plazos por tramos del mandato, las excepciones, o la presentación desde el lado emisor. Para el panorama completo, cómo Facturae, FACe, VeriFactu, SII, TicketBAI y Crea y Crece encajan entre sí, el marco completo de e-invoicing en España: VeriFactu, SII, TicketBAI y Crea y Crece cubre las piezas regulatorias y sus calendarios; si recibes una factura con código VeriFactu, también conviene saber cómo comprobar el QR de VeriFactu ante la AEAT.

---

Cuándo el procesamiento manual de Facturae deja de escalar

Abrir cada Facturae en un visor, copiar campos a una hoja y mantener el libro a mano funciona razonablemente cuando el volumen es bajo: una asesoría con pocos clientes con FACe, una empresa que recibe diez o quince facturas electrónicas al mes, alguien que solo ve Facturae de uno o dos proveedores recurrentes. Para ese tamaño, el coste del proceso manual es asumible y el riesgo de error está acotado por la propia revisión humana.

El flujo se rompe cuando el volumen sube. Los puntos de ruptura son concretos y aparecen en este orden:

• Errores de transcripción en NIF, número de factura, base e importe que solo se detectan cuando, semanas después, el extracto bancario no concilia con el libro. Para entonces, el asiento ya está cerrado y la corrección requiere localizar la factura, reabrir el periodo y ajustar.
• Retenciones IRPF olvidadas o mal asignadas en facturas de profesionales. Quien transcribe a mano tiende a fijarse en el total a pagar; el desglose entre base, IVA y retención se pierde si la plantilla no obliga a separarlo. El resultado es una declaración del 111 o 190 que no cuadra con los pagos.
• Drift en la validación de firma. Los visores de escritorio se quedan desactualizados respecto a las cadenas de certificados que llegan en facturas reales. El equipo de pagos empieza a aceptar fallos que VALIDe no replica, y la frontera entre fallo recuperable y artefacto de herramienta se difumina. Cuando alguien por fin actualiza el visor o pasa todo por VALIDe, aparece un acumulado de facturas que requieren revisión.
• Desfase entre recepción y libro. Las facturas llegan en lotes, el equipo las trata cuando puede, y el libro queda con días o semanas de retraso. Bajo el RD 238/2026, ese desfase ya no afecta solo a la liquidación trimestral del 303 o al envío SII: también afecta al plazo en que el receptor está obligado a comunicar pagos efectivos a la solución pública. La comunicación atrasada en cadena se convierte en un riesgo operativo.
• Convivencia de Facturae y UBL. Mantener un proceso manual paralelo para cada formato, dos plantillas, dos rutinas, dos hojas de salida, multiplica el trabajo en lugar de sumarlo. Cuando los proveedores empiezan a alternar formatos, el equipo dedica tiempo a decidir por qué flujo entra cada factura antes de tratarla.

La transición a un procesamiento automatizado parte de las decisiones que ya hemos tomado en las secciones anteriores. La representación canónica del libro está fijada (las columnas que el receptor necesita en su hoja). Las reglas de tratamiento de casuísticas están escritas (múltiples tipos de IVA, recargo, retenciones, suplidos). Lo que cambia es de dónde sale el contenido de la hoja: para los XML firmados, un parser que aplica los XPaths de la tabla de mapeo; para los PDFs y escaneos que conviven en la misma bandeja, una herramienta de extracción guiada por prompt.

Para esa parte del flujo, la del PDF y la imagen, extracción automática de datos de facturas Facturae y UBL hacia hojas de cálculo contables es el problema que resuelve nuestra herramienta. El receptor real maneja una mezcla: Facturae XML del sector público y de proveedores adaptados, leyendas PDF generadas por los visores cuando se prefiere trabajar sobre la representación legible, PDFs de proveedores que todavía no emiten en formato estructurado y escaneos de facturas en papel que siguen llegando. Los formatos soportados por la herramienta son PDF (nativo y escaneado) e imagen (JPG, PNG), con lotes de hasta 6.000 ficheros y PDFs individuales de hasta 5.000 páginas. El usuario sube el lote, describe en un campo de prompt las columnas que necesita su libro de facturas recibidas (NIF emisor, razón social, número, fecha, base imponible, tipo y cuota de IVA, retención IRPF, total) y descarga un Excel, CSV o JSON listo para importar al ERP o a la herramienta contable. Los prompts se guardan en una biblioteca y se reutilizan cada mes, lo que estabiliza el formato de salida que la herramienta contable espera. Cada fila de la hoja queda enlazada con el fichero y la página de origen, lo que permite cruzar contra el documento original si algo no cuadra.

Para receptores con volumen pequeño, las cincuenta páginas mensuales del plan permanente gratuito cubren un uso real sin compromiso ni configuración. Para receptores con volumen alto, subcontratistas del sector público, asesorías con cartera de clientes con FACe, departamentos de AP que reciben cientos de Facturae al mes mezclados con UBL y PDF, el modelo es de pago por uso con créditos comprados a medida y sin suscripción. La curva de aprendizaje es la del prompt: quien sabe qué columnas necesita en su libro tiene la herramienta configurada.