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.
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.
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; extract naively and 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, and someone maintains the wreckage forever.
- 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.
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 → routingLabels
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.
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.96The 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 worksClassify
Document classification
Type detection that routes each document to the right handling.
How classification worksRead
Local OCR
Native and VLM OCR for scans and photographs, with no page leaving the machine.
How OCR worksStructure
Layout understanding
Reading order, tables, columns and regions recovered before any downstream step.
How layout analysis worksExtract
Structured data extraction
Grammar-constrained fields with per-field confidence; malformed output cannot reach your pipeline.
How extraction worksEngine
Dynamic Sampling
The adaptive inference layer underneath: structured output that always parses, on any supported model.
How Dynamic Sampling worksBeside 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 OneEmbed
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.NETOwned compute replaces per-page billing: for thousands of documents a month, that is usually the deciding factor.
Private Document Intelligence