Use case

Invoices in. System-ready data out.

A complete intelligent document processing pipeline: mixed batches split into documents, each classified, read and extracted to your schema, with review signals.

Deploy LM-Kit One Build with LM-Kit.NET
Splits mixed batches Classifies every document Schema-valid JSON Runs fully local

The batch is the problem before the invoice is.

Real intake is not clean single invoices. It is scanner runs and shared mailboxes where five documents arrive as one PDF, and keying costs grow with every page.

  • Mixed files. One scan holds an invoice, its delivery note and someone's claim form; without boundary detection, fields merge across documents.
  • Manual triage. People open, split and rename files before the real work starts, all day, every day.
  • Template death. Per-supplier templates multiply, then break on the next layout change; schema-driven extraction retires the wreckage.
  • Blind spend. Per-page cloud pricing turns your highest-volume process into your least predictable bill.

From mailbox to system of record.

Six stages, one engine, no document leaving your infrastructure. Extraction is only as good as the stages in front of it.

01

Intake

Scanner runs, mailbox exports and uploads land in one queue.

02

Split

Boundary detection finds each document inside a mixed batch.

03

Classify

Each segment gets a type and routes to its own handling.

04

Read

OCR and layout recovery preserve tables and reading order.

05

Extract

Fields decode against your schema and always parse.

06

Review & post

Low-confidence fields queue for a person; the rest post through.

One scan in, each document found.

Boundary detection reads content, not page counts: it finds where one document ends and the next begins, labels each, and says how sure it is.

split-result.txt 
scans-0818.pdf → 4 documents · confidence 96%

  pages 1-2   invoice          → extraction
  pages 3     delivery-note    → order matching
  pages 4-7   claim-form       → claims queue
  pages 8-9   correspondence   → routing

Boundaries

Found by content

A new supplier header, a new document voice: boundaries come from meaning, not blank-page heuristics that miss double-sided scans.

Labels

Classified at the boundary

Every segment carries a type the moment it is found, so invoices, claims and correspondence route to different handling automatically.

Files

Physically split

Segments become real per-document PDFs, so every downstream system receives exactly one document per file.

JSON that matches the schema you defined.

Three properties make extraction output safe to automate on: it parses, it carries confidence, and it admits what is missing.

Schema

You define the fields

Supplier, dates, currency, line items, tax, totals, bank details. Grammar-constrained decoding means output always parses; a malformed answer cannot reach your pipeline.

Confidence

Per field, not per document

A document-level score is not actionable. Per-field figures let you accept the total and route only the tax line to a person.

Nulls

Silence is not a guess

When the document does not state a purchase order, the field returns null and flagged, never filled with something plausible.

The parts that usually break a pipeline.

Real invoice streams are scans, new suppliers and foreign paperwork. The pipeline holds because these are handled before extraction, not patched after.

Scans

Documents that were never digital

OCR and layout recovery for scans and photographs, tables and multi-column layouts included, so extraction sees structure in reading order.

Layouts

Every supplier is different

Extraction follows your field definitions, not a per-supplier template, so a new layout is not a new template to maintain.

Languages

Paperwork in any language

Suppliers write in their language, not yours. Detection and multilingual models handle mixed-language intake without per-language setup.

Define the fields, parse the document.

Define the fields, attach the document, parse: typed results in a few lines of C#. LM-Kit One serves the same extraction over HTTP.

ExtractInvoice.cs 
using LMKit.Data;
using LMKit.Extraction;
using LMKit.Model;

var model     = LM.LoadFromModelID("qwen3.5:4b");
var extractor = new TextExtraction(model);

extractor.Elements = new List<TextExtractionElement>
{
    new("supplier",        ElementType.String),
    new("invoice_number",  ElementType.String),
    new("invoice_date",    ElementType.Date),
    new("total_amount",    ElementType.Double),
    new("currency",        ElementType.String),
    new("purchase_order",  ElementType.String),
};

extractor.SetContent(new Attachment("invoice-4187.pdf"));
var data = extractor.Parse();

Console.WriteLine(data.Json);
Console.WriteLine(data.GetConfidence("total_amount")); // 0.96

The technology underneath.

Every stage of this pipeline is a documented capability you can use on its own.

Split

Document splitting

Content-driven boundary detection with per-segment labels and confidence.

How splitting works

Classify

Document classification

Type detection that routes each document to the right handling.

How classification works

Read

Local OCR

Native and VLM OCR for scans and photographs, with no page leaving the machine.

How OCR works

Structure

Layout understanding

Reading order, tables, columns and regions recovered before any downstream step.

How layout analysis works

Extract

Structured data extraction

Grammar-constrained fields with per-field confidence; malformed output cannot reach your pipeline.

How extraction works

Engine

Dynamic Sampling

The adaptive inference layer underneath: structured output that always parses, on any supported model.

How Dynamic Sampling works

Then archive

From posted to preserved

Processed invoices convert to validated PDF/A and get signed and timestamped, so the retention copy holds up as long as the ledger does.

The archiving use case

Beside your systems, or inside them.

The same pipeline ships two ways; pick by where the documents live.

Deploy

LM-Kit One

Post a document to LM-Kit One and read back JSON: a shared service several systems call, with an admin surface.

See LM-Kit One

Embed

LM-Kit.NET

Run the pipeline in process with LM-Kit.NET where the AI travels with your product or runs with no network at all.

See LM-Kit.NET

Owned compute replaces per-page billing: for thousands of documents a month, that is usually the deciding factor.

Frequently asked questions.

Do we need to train a model per supplier?

No. Extraction is schema-driven: you declare the fields once and grammar-constrained decoding fills them from any layout, so a new supplier is a new document, not a new template or training run.

What happens with low-quality scans?

OCR and layout recovery run before extraction, preserving tables and reading order, and every field carries its own confidence, so a blurry total routes to a person while the clean fields post automatically.

How does this integrate with our ERP or workflow system?

Two ways. LM-Kit One serves splitting, OCR, and extraction as REST endpoints any system can call; LM-Kit.NET embeds the same pipeline in your own .NET services as typed calls. Both return schema-matching JSON that always parses.

What does high volume cost?

There is no per-page meter in either form. Throughput comes from your hardware, which means month-end spikes and historical backfills are scheduling decisions rather than budget events.

Private Document Intelligence

Try it on your own invoices.

Deploy LM-Kit One How extraction works