80 facturas alemanas, una sola hoja de cálculo
Cómo gestionar el procesamiento por lotes de Rechnung sin entrada manual
El cuello de botella en las cuentas por pagar alemanas no es extraer datos de una sola Rechnung. Cualquier herramienta OCR decente puede obtener un número de factura y un total de un PDF limpio. El cuello de botella es lo que ocurre cuando extrae las 80 — y descubre que la Rechnung n.º 12 del Elektriker local tiene un 7 % de IVA sobre la mano de obra pero un 19 % sobre los materiales divididos en la misma línea, la Rechnung n.º 37 de Metro aplica un descuento Skonto del 4 % oculto en el pie de página, y la hoja de cálculo combinada que produjo su herramienta no tiene ninguna columna para indicarle qué factura aportó cada fila. Extraer una Rechnung tarda 3 minutos. Verificar y corregir 80 tarda toda una tarde.
Cuando llegan 80 Rechnungen — por qué el procesamiento por lotes no es solo "individual × 80"
Procesar una factura a la vez funciona hasta que deja de hacerlo. El punto de inflexión para la mayoría de las empresas alemanas se sitúa entre 30 y 50 Eingangsrechnungen al mes: el umbral donde se abre la brecha entre "puedo hacerlo el viernes por la tarde" y "esto me está comiendo el fin de semana". Con 80 facturas, el problema no es la velocidad de captura de datos por factura. Es que los flujos de trabajo de factura individual introducen cuatro problemas estructurales que el procesamiento por lotes hereda y amplifica:
Deriva de formato. Cuando procesas facturas una por una e introduces datos manualmente en Lexware o sevDesk, tu cerebro compensa las diferencias de diseño: ves "Rechnungs-Nr." en una factura de Metro y "Rechnungsnummer" en una de Transgourmet y sabes que son el mismo campo. Una extracción automática por lotes no tiene esa intuición a menos que le hayas enseñado qué buscar, no por posición en la plantilla, sino por significado semántico. Ocho proveedores, ocho diseños y una salida por lotes que los mezcla todos en una sola hoja de cálculo.
Fragmentación del IVA. Las Eingangsrechnungen alemanas no usan uniformemente un solo tipo de IVA. En un lote de 80 facturas de proveedores de hostelería, aparecen hasta cuatro tratamientos de IVA: 19% estándar (equipamiento, limpieza), 7% reducido (alimentos, libros), inversión del sujeto pasivo §13b (trabajos de construcción de subcontratistas) y §19 Kleinunternehmer (sin IVA). Una sola columna "Impuesto" que captura un número de cada factura es inútil, porque ese número significa algo diferente en cada fila, y tu cálculo de Vorsteuerabzug necesita separarlos por tipo. Los campos obligatorios del §14 UStG de cada factura determinan qué debe extraerse, pero el procesamiento por lotes añade la capa de mantener esa extracción semánticamente consistente en las 80 filas.
Propagación de errores. Cuando introduces 80 facturas manualmente, cada una es una operación independiente: un error tipográfico en la Rechnung n.º 44 no se extiende a la n.º 45. En una extracción por lotes, si la IA identifica mal el nombre del proveedor en una factura porque cambió la posición del logotipo, no lo sabrás hasta revisar toda la salida. Y si el mapeo de columnas está desviado —por ejemplo, la columna Leistungsdatum capturó el Rechnungsdatum en un proveedor que formatea las fechas de manera diferente—, necesitas revisar cada fila, no solo la que notaste.
Brechas de trazabilidad. Una hoja de cálculo combinada de 80 filas debe indicarte qué fila proviene de qué archivo. Si necesitas volver a la factura original para verificar una USt-IdNr o revisar una línea de descuento, necesitas un mapeo fiable de nombre de archivo a fila. Las herramientas por lotes que escupen un CSV sin columna de documento de origen convierten la auditoría en una búsqueda del tesoro en tu carpeta de Descargas.
Ninguno de estos problemas existe cuando procesas tres facturas. Con 80, los cuatro están activos simultáneamente — y resolverlos es lo que separa un flujo de trabajo de procesamiento por lotes de "extracción individual, repetida 80 veces".
El problema de los formatos de proveedores: una hoja de cálculo, ocho diseños distintos
Una factura de Metro y una de Transgourmet comparten la misma estructura legal según el §14 UStG, pero no se parecen en nada. Metro coloca el Rechnungsnummer en el bloque superior derecho; Transgourmet, en el encabezado de una tabla. La panadería local podría enviar una Rechnung manuscrita donde el bloque de dirección del proveedor no tiene ninguna etiqueta explícita: la reconoces porque está en la esquina superior izquierda y comienza con el nombre de la calle. Este es el argumento central contra la extracción por lotes basada en plantillas para facturas alemanas: cada nuevo proveedor te obliga a crear y mantener una nueva plantilla de extracción.
Para ponerlo en perspectiva: un grupo de restaurantes alemanes de tamaño mediano podría recibir facturas de Metro (mayorista de alimentos), Transgourmet (bebidas), un Gemüsehändler local (productos frescos), varios Getränkelieferanten (distribuidores de bebidas), un servicio de limpieza, una Wartungsfirma (mantenimiento de equipos) y una agencia de marketing, además de proveedores ocasionales. Son ocho formatos de factura distintos antes de considerar las variaciones dentro de Metro (factura estándar, albarán, Stornorechnung), que usan el mismo diseño de marca pero reorganizan los campos. Las herramientas basadas en plantillas requieren una configuración separada para cada variante. Con la extracción semántica, defines los nombres de las columnas una sola vez.
Esta es la diferencia entre el enfoque de nombres de columna y el enfoque de plantillas a escala. Extracción de Columnas Personalizadas — el mecanismo que usa ImageToTable.ai — funciona comprendiendo el significado de los campos, no por coordenadas. Escribes los nombres de columna deseados: "Rechnungsnummer", "Lieferant", "Rechnungsdatum", "Leistungsdatum", "Nettobetrag", "USt-Satz", "USt-Betrag", "Bruttobetrag", "USt-IdNr" — y la IA localiza cada valor en cada factura del lote comprendiendo qué significa la etiqueta, sin importar dónde aparezca ni si el texto de la etiqueta varía ("Rechnungs-Nr." vs "Rechnungsnummer" vs "RNr."). Una definición de columna cubre los ocho diseños de proveedores en una sola carga por lotes.
La implicación práctica: subes la carpeta completa de Eingangsrechnungen del mes — 80 PDF, JPG y documentos escaneados de todos los proveedores — y obtienes una hoja de cálculo combinada donde cada fila representa una Rechnung con las mismas columnas, sin importar el formato. Sin plantilla por proveedor, sin clasificación previa por formato, sin "las facturas de este proveedor deben subirse por separado porque el diseño es diferente".
El desglose del IVA en 80 facturas: por qué una sola columna de "Impuesto" falla
Ahora supongamos que la extracción por lotes funcionó: las 80 facturas están en su hoja de cálculo con columnas consistentes. El siguiente problema es que la columna USt-Satz contiene cuatro valores diferentes — 19%, 7%, 0% (o en blanco) y "§13b" — y cada uno exige un tratamiento contable distinto. Si simplemente SUMA la columna USt-Betrag, está sumando el IVA regular del 19% que puede recuperarse como Vorsteuerabzug (según §15 UStG), el IVA reducido del 7% que también califica para deducción pero debe declararse por separado (línea 66 de la Umsatzsteuervoranmeldung), y los montos §13b donde la obligación del IVA se transfiere al destinatario — lo que significa cero deducción y una obligación de declaración separada.
La Umsatzsteuervoranmeldung — la declaración mensual o trimestral de IVA de Alemania, presentada a través de ELSTER — requiere que los montos de IVA se declaren bajo códigos fiscales específicos (Kennzahlen):
| Escenario de IVA | Kennzahl de ELSTER | Qué significa en un lote | Qué necesita su hoja de cálculo |
|---|---|---|---|
| Tasa estándar del 19% | Kennzahl 66 | IVA soportado recuperable: la categoría más grande para la mayoría de las empresas | Filas donde USt-Satz = 19% → SUMA(USt-Betrag) → va a Kz 66 |
| Tasa reducida del 7% | Kennzahl 66 (subconjunto) | También recuperable, pero su Steuerberater puede querer ver el desglose | Filas donde USt-Satz = 7% → SUMA(USt-Betrag) → subtotal separado, aún Kz 66 |
| Inversión del sujeto pasivo §13b | Kennzahl 46+47 | Usted autoliquida el IVA y lo deduce en la misma declaración — neto cero, pero debe declararse | Filas donde USt-Satz = §13b → marcar para atención del Steuerberater, no sumar en Kz 66 |
| §19 Kleinunternehmer | Irrelevante | Sin IVA en la factura = sin deducción que reclamar. Sigue siendo un gasto empresarial válido. | Filas donde USt-Satz = en blanco/0 — no se necesita entrada de IVA, pero el Nettobetrag sigue siendo relevante como Aufwand |
| Kleinbetragsrechnung (§33 UStDV) | Kz 66 (si el IVA está incluido) | Facturas de menos de 250 € brutos — Pflichtangaben simplificados, pero el IVA sigue aplicándose | Puede no indicar el IVA explícitamente — calcule 19/119 o 7/107 del Brutto si es necesario |
Un enfoque práctico para manejar esto en una extracción por lotes: defina una columna inferida — una columna donde la IA clasifica la factura según su contenido en lugar de extraer un valor que esté explícitamente en la página. Por ejemplo, una columna llamada VAT Type (options: Standard 19%/Reduced 7%/§13b Reverse Charge/Kleinunternehmer §19) le indica a la IA que lea cada factura, determine qué régimen de IVA corresponde y genere la etiqueta de categoría correcta. Esto le da una columna filtrable — y a partir de ahí, agrupa por tipo de IVA y suma el USt-Betrag de cada grupo por separado para su presentación de Vorsteuerabzug. La extracción y la clasificación ocurren en una sola pasada, no en dos operaciones separadas.
Esto también es importante para el lado de los gastos de su Buchhaltung. El Nettobetrag en una factura §13b sigue siendo un gasto operativo (Aufwand), aunque tenga cero IVA soportado — si lo excluye de su resumen de costos porque "sin impuestos = no relevante", está subestimando los gastos. La extracción por lotes debe capturar el panorama financiero completo, no solo la parte relevante para el IVA.
De la Extracción por Lotes a Su Steuerberater — Listo para DATEV en un Solo Export
Extraer 80 facturas a una hoja de cálculo resuelve el problema de entrada de datos. No resuelve automáticamente el problema de la transferencia — el paso donde esa hoja de cálculo debe convertirse en algo que su Steuerberater pueda importar a DATEV sin volver a teclear cada fila. Los asesores fiscales alemanes usan las plataformas Kanzlei-Rechnungswesen y Unternehmen Online de DATEV, que importan datos mediante dos mecanismos principales por lotes:
Importación CSV (Formato DATEV) para Kanzlei-Rechnungswesen — un CSV de columnas fijas con un orden de campos específico: Belegdatum, Buchungstext, Gegenkonto, Betrag, indicador Soll/Haben y, opcionalmente, el Buchungsschlüssel (clave de contabilización) y la Kontierung (número de cuenta según SKR03 o SKR04). El archivo debe usar punto y coma como delimitadores, codificación ISO-8859-1 y formato de fecha DD.MM.YYYY — las exportaciones CSV de herramientas en inglés que usan comas y MM/DD/YYYY por defecto fallarán silenciosamente.
Importación XML (trabajos dxso) para DATEV Unternehmen Online — un envío de trabajos por lotes que usa el esquema XML propietario de DATEV. El mecanismo dxso (DATA XML Send Online) acepta datos de facturas estructurados como documentos XML, validados contra los esquemas XSD de DATEV. XML es obligatorio para Unternehmen Online; CSV es para la aplicación de escritorio Rechnungswesen — y su Steuerberater puede usar uno u otro, o ambos, según su flujo de trabajo.
La idea clave: sus columnas de extracción deben reflejar las columnas de importación que espera su sistema de destino. Si su Steuerberater necesita Belegdatum en formato DD.MM.YYYY, defina su columna de extracción como "Belegdatum" — no "Invoice Date". Si contabilizan gastos en la cuenta 4930 (SKR03: Sonstige Kosten), incluya una columna llamada "SKR03 Konto" con el código correspondiente. Esto elimina el paso intermedio de reformatear una salida de extracción genérica para que coincida con los esquemas del software contable. La extracción es el archivo de importación.
Para un lote de 80 facturas con destino a DATEV, el conjunto de columnas podría verse así:
- Belegdatum — DD.MM.YYYY
- Buchungstext — combinación de Lieferant + Rechnungsnummer
- Gegenkonto — el número de Kreditor del proveedor (serie 70000 en SKR04)
- Betrag — Bruttobetrag (importe bruto)
- Soll/Haben — "S" para débito (gasto), "H" para crédito
- SKR03 Konto — la cuenta de gastos (p. ej., 4930 para costos diversos, 3400 para Waren)
- USt-Satz — 19 o 7 o 0
- Vorsteuerbetrag — el importe de IVA deducible
Lexware Office y sevDesk utilizan sus propias plantillas CSV, pero el principio es el mismo: definir columnas de extracción que coincidan con el esquema de importación, exportar como CSV e importar directamente. La propuesta de valor del procesamiento por lotes — 80 facturas en minutos — solo se realiza plenamente si la salida no requiere otra hora de reformateo en la hoja de cálculo.
El Flujo de Trabajo — Cómo Procesar 80 Eingangsrechnungen de una Vez
Con los desafíos estructurales mapeados — diversidad de formatos, fragmentación del IVA y compatibilidad con DATEV — aquí está el flujo de trabajo por lotes de extremo a extremo desde una carpeta de 80 Rechnungen hasta una hoja de cálculo lista para el Steuerberater:
VAT Type (options: Standard 19%/Reduced 7%/§13b Reverse Charge/Kleinunternehmer §19) para clasificar automáticamente cada factura. Si exporta a DATEV, alinee los nombres de las columnas con el esquema de importación (Belegdatum, no "Date"; Bruttobetrag, no "Total"). Esta definición de columnas se reutiliza para cada lote: la define una vez, no por lote.Los archivos se procesan de forma segura y no se almacenan. Suba varias Rechnungen para ver la extracción por lotes en acción.
En cuanto al paso de verificación específicamente: los elementos de mayor riesgo en un lote no son los que parecen incorrectos, sino los que parecen correctos pero contienen un campo que fue leído sistemáticamente de forma errónea debido a una peculiaridad de formato específica del proveedor. Una factura de Metro que alinea su Nettobetrag de manera diferente a las otras 79 facturas no mostrará un error: la celda contendrá un número, y el número parecerá plausible. La comprobación que detecta esto es la verificación puntual del top 10 por Bruttobetrag: abra la factura original de Metro, compare el total bruto con el total bruto extraído. Si coinciden, es probable que la extracción sea correcta. Si no coinciden, hay una peculiaridad de formato que investigar.
Archivado por lotes conforme a GoBD: no archive el Excel, archive los originales
El procesamiento por lotes crea un atajo tentador: extraer 80 facturas en una sola hoja de cálculo ordenada, archivar la hoja y eliminar los originales desordenados. Este es el error de cumplimiento de GoBD más común en el procesamiento automatizado de facturas, y falla en múltiples niveles en una auditoría.
La GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern), revisada en julio de 2025 para alinearse con el mandato de facturación electrónica de Alemania, exige que los documentos relevantes para impuestos se conserven en su formato original recibido, no en una versión derivada o transformada. Específicamente:
- Facturas electrónicas estructuradas (XML XRechnung, PDF híbrido ZUGFeRD): El XML es el registro fiscal autoritativo. Si la factura llegó como PDF ZUGFeRD, el archivo PDF/A-3 completo (incluido el XML incrustado) debe archivarse como una sola unidad. La enmienda de julio de 2025 confirmó que no se requiere una copia PDF legible por humanos por separado, a menos que contenga información adicional relevante para impuestos que no esté presente en el XML, como notas de pago manuscritas en la capa visual.
- PDF simples y documentos escaneados: El archivo original debe conservarse sin alteraciones durante 10 años según §147 AO. Una fila extraída en Excel es una copia de trabajo, no un sustituto de archivo.
- Facturas en papel fotografiadas: La foto digital se convierte en el registro. El principio de Unveränderbarkeit (inmutabilidad) de la GoBD significa que el archivo de foto debe almacenarse de manera que impida modificaciones posteriores: con marca de tiempo, hash o almacenado en un sistema con bloqueo de revisiones.
El resultado de la extracción (su hoja de cálculo de Excel con 80 filas) es un documento operativo, no un documento de archivo. Sirve para su Buchhaltung diaria, el cálculo de Vorsteuerabzug y la importación a DATEV. Para una Betriebsprüfung (auditoría fiscal), el auditor solicitará los archivos de factura originales, no su hoja de extracción. La extracción solo necesita permitir la trazabilidad de vuelta a esos originales, lo que significa que la hoja de cálculo debe incluir una columna que identifique el archivo fuente de cada fila (nombre de archivo o número de referencia). Sin esta columna de trazabilidad, una extracción por lotes de 80 facturas crea 80 filas de datos que no pueden verificarse contra sus fuentes: un fallo de cumplimiento de GoBD sin importar cuán precisa haya sido la extracción.
El flujo de trabajo práctico de archivado por lotes: conserve los archivos originales en una carpeta con fecha (p. ej., /Eingangsrechnungen/2026-05/), nómbrelos de manera consistente (2026-05-03_Metro_INV-48291.pdf) y asegúrese de que su resultado de extracción conserve el nombre de archivo como columna. Si su Steuerberater usa DATEV Unternehmen Online, los archivos de factura originales pueden adjuntarse a las entradas contables correspondientes mediante la función Belegverwaltung (gestión de documentos), cerrando el ciclo de trazabilidad desde la hoja de cálculo hasta el documento fuente y dentro del rastro de auditoría de DATEV.
El mandato de facturación electrónica por fases de Alemania (recepción obligatoria desde enero de 2025, envío obligatorio para empresas con facturación superior a 800 000 € desde 2027, envío universal desde 2028) está reduciendo gradualmente el problema de los "originales desordenados". A medida que los proveedores migran a ZUGFeRD y XRechnung, la capa XML incrustada entrega datos estructurados sin OCR. Pero durante el período de transición, su canalización por lotes manejará una mezcla: algunos PDF ZUGFeRD, algunos PDF simples, algunas Rechnungen escaneadas de proveedores que no cambiarán hasta 2028. El flujo de extracción debe manejar los tres tipos, y el flujo de archivado debe conservar los tres en sus respectivos formatos originales.
Preguntas Frecuentes
¿Puedo procesar facturas de Metro, Transgourmet y un Handwerker local en el mismo lote?
Sí. Dado que la extracción se basa en la semántica de los nombres de columna — la IA lee el significado del campo, no su posición — la misma definición de columna (Rechnungsnummer, Lieferant, Bruttobetrag, etc.) funciona en diferentes formatos de proveedor. No necesita una plantilla separada por proveedor. La única salvedad: si dos proveedores usan una etiqueta idéntica para cosas distintas (por ejemplo, ambos tienen un campo "Datum" pero uno significa fecha de factura y el otro fecha de entrega), defina sus columnas con precisión — "Rechnungsdatum" y "Lieferdatum" en lugar de un genérico "Date".
¿Cómo manejo la división del IVA cuando algunas facturas tienen artículos con 19% y 7%?
Para facturas con tipos de IVA mixtos, defina pares de columnas separados: "Nettobetrag 19%", "USt-Betrag 19%", "Nettobetrag 7%", "USt-Betrag 7%". La IA extrae cada grupo de tipo de IVA de forma independiente de la factura. Si una factura solo tiene artículos al 19%, las columnas del 7% estarán vacías — y viceversa. En su salida por lotes, puede SUMAR la columna USt-Betrag 19% y la columna USt-Betrag 7% por separado para su cálculo de Vorsteuerabzug. Para facturas complejas donde la división no es clara — una factura de restaurante que mezcla comida y alcohol (19%) en la misma línea — agregue una columna calculada para recalcular la división correcta a partir de las cantidades de los artículos y los precios unitarios, y verifique contra el desglose de IVA indicado en la factura.
¿Qué sucede si una factura del lote tiene un campo faltante — rompe todo el lote?
No. La IA procesa cada factura de forma independiente dentro del lote. Si la Rechnung #23 no tiene el campo USt-IdNr (común en Kleinbetragsrechnungen por debajo de €250, que no lo requieren), esa celda estará vacía para esa fila — todas las demás filas no se ven afectadas. El paso de verificación en el flujo de trabajo está diseñado para detectar esto: ordene por la columna obligatoria y busque espacios en blanco. Luego puede completar el valor faltante manualmente (si conoce la USt-IdNr del proveedor de una factura anterior), aceptar el espacio en blanco si es legítimo (Kleinbetragsrechnung), o marcarlo para seguimiento con el proveedor si es un campo obligatorio en una factura completa.
¿Puedo exportar directamente al formato CSV de DATEV desde la extracción por lotes?
Puede exportar a Excel (XLSX) o CSV, y luego asignar las columnas al formato CSV de DATEV que su Steuerberater requiere. La salida de la extracción por lotes es una hoja de cálculo estructurada — las columnas que definió se convierten en las columnas de Excel. Si nombra sus columnas para que coincidan con los campos de importación de DATEV (Belegdatum, Buchungstext, Gegenkonto, Betrag, etc.), la exportación ya tiene la estructura correcta — es posible que necesite reorganizar el orden de las columnas y asegurarse de que el delimitador y los formatos de fecha coincidan con las especificaciones exactas de DATEV (punto y coma, DD.MM.YYYY, codificación ISO-8859-1). La herramienta no produce CSV en formato DATEV de forma nativa, pero los datos extraídos se asignan directamente con un reformateo mínimo.
¿El procesamiento por lotes funciona con facturas XML ZUGFeRD y facturas en papel escaneadas mezcladas en la misma carga?
Sí, el lote puede contener una mezcla de PDF ZUGFeRD, PDF simples, escaneos JPG y fotos: la IA lee la capa visual de cada documento. Para facturas ZUGFeRD, lee la representación PDF visible; no analiza el XML incrustado. En la práctica, esto significa que la precisión de extracción en una factura ZUGFeRD está determinada por la calidad del diseño visual, no por si el XML está presente, igual que con un PDF simple. Para archivos XML XRechnung puros (sin PDF visual), la herramienta no está diseñada para procesarlos; use un convertidor de XML a CSV para esos casos, o pida al proveedor que también proporcione la versión PDF legible.
¿Cómo manejo el Skonto (descuento por pago anticipado) en la extracción por lotes?
El Skonto — normalmente un 2-3% de descuento por pago dentro de 7-14 días — suele indicarse en una nota en lugar de un campo dedicado (p. ej., "2% Skonto bei Zahlung innerhalb 10 Tagen"). Si necesita rastrearlo, defina una columna llamada "Skonto (%)" — la IA extraerá el porcentaje si aparece en la factura. Para el Nettobetrag, normalmente se quiere el importe completo antes del Skonto (Bemessungsgrundlage), no el importe descontado, porque el IVA se calcula sobre el importe completo según §10 UStG. Si la factura indica el total descontado, use una columna calculada para recalcular el Nettobetrag antes del Skonto para fines de Vorsteuerabzug, ya que la oficina de impuestos determina el IVA soportado sobre el importe bruto antes del descuento.
Ponga en marcha su flujo de trabajo por lotes de facturas alemanas
El procesamiento por lotes de Eingangsrechnungen alemanas se sitúa en una intersección específica: es el punto donde el número de facturas pasa de "la entrada manual es molesta pero manejable" a "la entrada manual es una pérdida de tiempo estructural". Para la mayoría de las PYME alemanas, esa línea se sitúa entre 40 y 60 facturas al mes. Por debajo de eso, la fricción proviene del flujo de trabajo — abrir DATEV, escribir campos, guardar. Por encima, la fricción es sistémica: diversidad de formatos, fragmentación del IVA y brechas de trazabilidad que sobreviven a cualquier flujo de trabajo de factura individual.
El enfoque de procesamiento por lotes descrito aquí — extracción basada en nombres de columna que funciona en todos los formatos de proveedor, columna inferida para la clasificación automática del IVA y esquemas de exportación alineados con DATEV — aborda los problemas sistémicos, no solo la velocidad por factura. La ganancia de eficiencia de 18x (3 minutos por factura manualmente frente a 5-10 segundos con extracción) es la cifra principal. Pero el cambio operativo más grande es este: todas las Eingangsrechnungen del mes se convierten en una sola operación. No 80 operaciones realizadas rápidamente — una operación hecha una vez. La diferencia es la diferencia entre "me volví más rápido en la entrada de datos" y "la entrada de datos dejó de ser parte de mi cierre de mes".
Suba varias Rechnungen — prueba gratuita, sin necesidad de cuenta para las primeras 50 páginas.