Cómo crear una plantilla de extracción de documentos sin código

La palabra "plantilla" arrastra mucho lastre en el mundo del OCR. Durante veinte años significó un mapa de coordenadas: dibujabas un rectángulo sobre el número de factura, otro sobre el total, y el software leía los píxeles que caían dentro. Funciona hasta que un proveedor mueve el logo: el OCR de plantillas ata cada campo a una posición fija, así que un bloque de líneas reordenado o una caja nueva de datos bancarios rompe la extracción y obliga a rehacer la plantilla a mano (ADVISORI). Con doscientos proveedores, mantener esa biblioteca se convierte en un trabajo fijo, un fallo tan conocido que tiene nombre: template decay (Datamondial).

Una plantilla de extracción moderna es otra cosa completamente distinta. Es un esquema: una lista de los campos que quieres, cada uno con nombre, tipo y una descripción breve. Sin coordenadas, sin dibujar, sin código. La IA lee el documento como lo leería una persona y rellena tu lista, incluso en formatos que no ha visto nunca — lo que en el sector se llama extracción zero-shot (LlamaIndex).

Esta guía la construye campo a campo.

Empieza por la salida, no por el documento

El error típico es abrir el PDF y apuntar todo lo que está impreso. Acabas con 40 campos, 12 de los cuales no mira nadie, y cada campo de más es una cosa más que puede venir mal.

Abre el destino: las cabeceras de tu Excel, el fichero de importación del ERP, el formulario que alguien teclea hoy. Esas columnas son tus campos. Si un dato no tiene sitio aguas abajo, fuera. Siempre puedes añadirlo luego: una plantilla es una lista de texto, no un desarrollo.

Buen ejercicio de arranque: coge el último documento que alguien procesó a mano y pregunta qué tecleó realmente. En facturas suele ser NIF del proveedor, número, fecha, base imponible, IVA, total y las líneas. Poco más.

Paso 1: nombra los campos como los llama tu sistema

Usa los mismos nombres que el destino, en snake_case o el formato que espere tu importación: `nif_proveedor`, `numero_factura`, `fecha_emision`, `importe_total`. Por dos motivos:

El mapeo al ERP o al Excel pasa a ser una correspondencia directa de columnas, no una capa de traducción.
El nombre del campo es en sí una pista para el modelo. `fecha_emision` extrae mejor que `fecha` en un documento que también lleva fecha de vencimiento y fecha de entrega.

Evita nombres ambiguos dentro del propio documento. `fecha`, `numero`, `importe` y `nombre` son los cuatro peores.

Paso 2: pon tipo a cada campo

Los tipos trabajan más de lo que parece. Un esquema con nombres, tipos y restricciones convierte la extracción de un ejercicio de rellenar huecos en uno de satisfacer restricciones, y las descripciones dan al modelo una guía semántica fina campo a campo (Sandgarden).

En la práctica necesitas cuatro:

texto — nombres, direcciones, códigos de referencia. Ojo: un código como `0044` es texto, no número, o pierdes el cero inicial.
número — todo con lo que vayas a hacer aritmética: importes, cantidades, porcentajes. Decide una vez si quieres `1234.56` o el formato local, y dilo en la descripción.
fecha — especifica siempre el formato de salida (`YYYY-MM-DD` es el único que ordena bien en una hoja de cálculo).
tabla — filas que se repiten. Más abajo.

Paso 3: escribe las descripciones como si formaras a alguien nuevo

Aquí es donde una plantilla pasa del 80% al 97% de acierto, y es la parte que casi todo el mundo se salta.

Descripción floja: *"El total de la factura."*

Descripción buena: *"Importe final a pagar con IVA incluido, impreso abajo a la derecha del bloque de totales. Si el documento muestra subtotal y total, coge la cifra mayor que incluye impuestos. Si hay línea de pronto pago, coge el importe realmente exigible."*

Tres reglas que siempre compensan:

Di dónde está y junto a qué. Los documentos son ambiguos; "el número que sigue a la etiqueta *Nº Factura* o *Factura núm.*" elimina la adivinanza.
Di qué hacer en el caso raro. Dos candidatos, campo ausente, corrección a mano. El caso raro es el que produce el error que luego te cuesta una hora encontrar.
Nunca pongas como ejemplo un valor real de un documento real. Usa una muestra ficticia que solo enseñe el formato (`AB-0000/00`). Si escribes el número de factura de un proveedor real, el modelo lo copiará alegremente en documentos donde no pinta nada. Este error cuesta días.

Paso 4: las líneas, como campo de tipo tabla

Todo lo que se repite — líneas de factura, lecturas de contador, huéspedes, filas de producto — es un único campo de tipo tabla con sus propios subcampos.

Define los subcampos como escalares: `descripcion`, `cantidad`, `precio_unitario`, `tipo_iva_linea`, `total_linea`. Dos cosas que conviene acertar:

Un concepto por columna. Si un proveedor imprime dos columnas de código (su referencia interna y el modelo del fabricante), haz dos subcampos y no una cadena fusionada. Unir es trivial aguas abajo; separar es adivinar.
Decide qué pasa con las filas que no son producto: subtotales, arrastres de página, portes. Di en la descripción si se extraen o se ignoran; si no, tendrás una respuesta distinta por documento.

Con las filas limpias, exportarlas es lo fácil: mira cómo convertir un PDF a Excel automáticamente.

Paso 5: define qué significa "no está"

Toda plantilla necesita una regla explícita para los datos ausentes. Por defecto: si el campo no está en el documento, devuelve null y no lo deduzcas.

Sin esa instrucción, un modelo al que pidas fecha de vencimiento en una factura que no la lleva a veces la calculará sumando 30 días a la de emisión. Es una suposición plausible y un error silencioso, la peor combinación posible. Una celda vacía es un problema que ves; un valor inventado es un problema que descubres tres meses después conciliando.

Paso 6: añade comprobaciones que puedas ejecutar tú

Cumplir el esquema no es lo mismo que acertar el contenido: la salida estructurada garantiza un JSON válido con la forma correcta, no que los números de dentro estén bien (Sandgarden), y los modelos no dan de forma nativa una confianza fiable por campo (Docupipe). Así que monta tú la aritmética, fuera de la plantilla:

Base + IVA − IRPF = total.
La suma de totales de línea cuadra con la base.
Los NIF/CIF cumplen formato y dígito de control.
Las fechas caen en una ventana plausible.

El documento que falle una comprobación va a revisión humana; el resto pasa directo. Ese es todo el fundamento de una política de revisión sensata: dónde poner el listón lo tratamos en cuánta precisión necesitas de verdad.

Paso 7: prueba primero con los documentos más feos

No valides una plantilla con el PDF nativo y limpio de tu mejor proveedor. Elige diez documentos que incluyan:

Una foto torcida y con mala luz.
Un escaneo de un fax de una copia.
Un documento de dos páginas donde la tabla sigue en la segunda.
El del proveedor con el diseño genuinamente raro.
Un documento en negativo: un abono.

Pásalos, compara con lo que habría tecleado una persona y corrige la descripción solo de los campos que fallaron. Dos o tres rondas suelen bastar. Resiste la tentación de reescribirlo todo tras un mal resultado.

Plantillas por las que merece la pena empezar

Casi todos los casos son variaciones de cinco esquemas:

Factura de proveedor — nombre y NIF, número, fecha, base, tipo e importe de IVA, retención, total, tabla de líneas.
Documento de identidad / KYC — nombre completo, número, fecha de nacimiento, caducidad, nacionalidad, tipo de documento.
Factura de suministro — dirección de suministro, CUPS o referencia de contador, titular, periodo, consumo, total.
Albarán — proveedor, número, fecha, referencia al pedido, líneas.
Tarjeta de visita — nombre, cargo, empresa, email, teléfono, web.

Cada una es un cuarto de hora de teclear, no un proyecto. Ese es el cambio real: el coste de un tipo nuevo de documento pasó de ser una integración a ser una tarde. Para calibrar el dinero en juego, los benchmarks de Ardent Partners de 2025 sitúan el coste medio de procesar una factura a mano en 10,89 $, frente a 2,78 $ en equipos automatizados de referencia (Ascend Software, Truvio).

Cuándo una plantilla no basta

Un esquema por resultado, no por proveedor. Todas tus facturas de compra comparten plantilla aunque vengan de 200 empresas distintas: es justo el sentido de haber tirado las coordenadas, y la razón por la que las plantillas OCR por proveedor se rompen.

Necesitas una segunda plantilla cuando la *salida* es distinta: facturas y DNI alimentan tablas distintas, así que llevan esquemas distintos. Si un proveedor concreto exige un trato especial — un código que hay que recomponer de una forma determinada — resuélvelo como regla de mapeo en tu sistema, no como bifurcación de la plantilla. Mantener esa lógica aguas abajo es lo que te permite enviar los datos limpios a Excel o a tu ERP por API sin volver a tocar la extracción.

Preguntas frecuentes

¿Tengo que entrenar la IA con mis documentos? No. La extracción zero-shot parte de un esquema y un prompt y funciona con formatos que nunca ha visto, sin muestras de entrenamiento (LlamaIndex). Lo que afinas es el texto de las descripciones, no un modelo.

¿Cuántos campos son demasiados? No hay límite duro, pero cada campo cuyo uso no sepas señalar es solo riesgo. Empieza por las columnas que tu destino tiene de verdad y añade bajo demanda.

¿Y si un proveedor cambia el diseño? No pasa nada. Un esquema describe significado, no posición, así que un bloque movido o una cabecera nueva no lo rompen — al contrario que las plantillas por coordenadas, donde un cambio de diseño obliga a rehacerla a mano (ADVISORI).

¿Puedo extraer campos manuscritos? Números y comprobaciones del tipo "hay firma", a menudo sí; escritura libre, con menos fiabilidad. Trata los campos manuscritos como de revisión siempre, no de paso directo.

¿Cómo sé que la extracción es correcta? Con comprobaciones aritméticas y de formato que defines tú, no con la confianza autodeclarada del modelo: los modelos no dan de forma fiable una puntuación de confianza por campo (Docupipe).

---

Prueba tu primer esquema contra un documento real ahora mismo: extrae los datos de tu documento gratis, sin cuenta.