Ertas for Data Extraction

The Challenge

Every organization drowns in unstructured documents. Invoices arrive in dozens of vendor-specific formats. Regulatory filings follow templates that change with every reporting cycle. Insurance claims, medical intake forms, shipping manifests, and legal contracts all contain critical structured information trapped inside PDFs, scanned images, and free-text fields. Traditional OCR and rule-based extraction systems are brittle: they break whenever a vendor changes their invoice layout or a form adds a new field. Maintaining hundreds of extraction templates is a full-time job that never ends.

Generic AI models can handle simple extraction tasks out of the box, but they struggle with domain-specific formats. They confuse 'invoice date' with 'due date' on non-standard layouts, misparse multi-line address fields, and fail to extract nested table structures common in financial and regulatory documents. Accuracy on edge cases, the 20% of documents that generate 80% of the manual correction workload, remains stubbornly low without domain-specific training. And for organizations handling sensitive documents like medical records, tax filings, or legal contracts, sending these documents to a third-party API for extraction creates unacceptable data exposure risks.

The Solution

Ertas Studio lets data engineering teams build extraction models trained on their actual document formats. Teams upload annotated examples as a JSONL dataset, or import one from Hugging Face: invoices paired with their labelled fields, forms paired with the key-value pairs they contain, reports paired with the structured output the team wants. Studio fine-tunes an open model on those examples with LoRA through a visual canvas, on Ertas's cloud GPUs, and can run several training runs in parallel so the team can compare base models and settings side by side. When a new document format appears, the team adds examples and trains again, instead of writing another template rule.

The trained model appears in Hub, where the team downloads it as GGUF for llama.cpp or Ollama, or as full safetensors for vLLM and other server runtimes. From there it runs on the company's own servers and slots into the existing document pipeline: text goes in, structured JSON comes out, and the documents being processed stay inside the company's network. The training examples are uploaded to Ertas for the training run, so teams handling sensitive documents should remove or mask personal and confidential details in the training set first. Datasets are stored so runs can be repeated, and the team can delete them.

Key Features

Example Workflow

A logistics company processes 15,000 invoices per month from 300 different vendors, each with a slightly different layout. The finance operations team annotates 5,000 representative invoices, marking vendor name, invoice number, line items, quantities, unit prices, tax amounts and payment terms, then masks personal contact details before uploading the JSONL dataset to Ertas Studio. The team trains Mistral 7B and Qwen 2.5 7B in parallel, compares both runs against a held-out set of invoices the models never saw, and keeps the better one. They export it from Hub as GGUF and run it on a server inside their own network, connected to the accounts payable workflow. Each incoming invoice goes to the model, which returns structured JSON. The team sets its own rules for which extractions flow straight into the ERP system and which go to a person for review with the model's output pre-filled. Corrected edge cases are reviewed in Data Craft and added to the training set for the next run.