Service

Document intelligence

Extraction accuracy is the wrong headline number. If a value lands on a financial record, someone is accountable for it, and the question that matters is whether they can check it in one click and whether the uncertain cases were routed to a person instead of posted silently. We build document workflows around verification, and we ship two products that do exactly this.

The work

Document workflow design: intake, classification, extraction, review, and the record that results
Confidence thresholds and human-review routing calibrated on the customer’s own documents
Structured e-invoice handling, where the data is read from XML rather than inferred from a picture of a page
Integration of extraction output into Salesforce or back-office systems as real records, with an audit trail
Evaluation on a customer sample set, so the accuracy discussion is about your paperwork rather than a vendor benchmark

Where we stop

We do not publish a headline accuracy figure, because we have no benchmark methodology on record that would make one meaningful. We would rather run your documents and show you the result.

The decisions this work exists to get right

Verification before accuracy: A field with a confidence score and a link to its exact location on the source page can be checked in seconds. A field without one has to be trusted. That difference matters more to a finance team than a percentage on a slide.
Where the human belongs: The design question is not whether to keep a reviewer, but which cases reach them. Threshold tuning per field type — and per document type — is what makes review sustainable instead of a second full data-entry job.
Structured formats are not OCR problems: Factur-X, ZUGFeRD, KSeF, and UBL 2.1 carry the data as XML. Reading the XML directly avoids OCR transcription errors; running OCR over the rendered page throws away the structure and introduces errors that were not there.
Evaluate on your documents: Extraction quality is a function of your document set: layouts, languages, scan quality, and supplier variety. A benchmark on someone else’s corpus predicts very little about yours, which is why we run a sample batch instead of quoting a number.

Extraction result · output structurereview below 0.80

Illustrative extraction output showing each field with its value, confidence score, and source location on the document.
Field	Value	Confidence	Source evidence
supplier.name	Northwind Components BV	0.99	p.1 · 62,118 · 214×18
invoice.number	INV-2026-004471	0.98	p.1 · 431,96 · 132×16
invoice.issueDate	2026-03-04	0.96	p.1 · 431,124 · 96×16
total.net	18 420.00 EUR	0.97	p.2 · 388,642 · 118×18
total.vat	3 868.20 EUR	0.94	p.2 · 388,668 · 110×18
paymentTerms	30 days net	0.61	p.2 · 64,712 · 176×16

The last row is the point. paymentTerms scored below the review threshold, so it is flagged for a person instead of being written silently — and the source column means checking it takes one click, not a document hunt.

Illustration of the output structure — field, value, confidence, and source coordinates — using an invented document. Not a screenshot, not a benchmark, and not an accuracy claim.

Questions we get asked

Answers are here in the page rather than hidden behind a script — open or closed, the text is the same.

What accuracy should we expect?

That depends on your document types and scan quality, so we do not quote a single headline number. Every extracted value carries a confidence score, and low-confidence fields route to human review rather than being filed automatically. The useful benchmark is your own paperwork — send a sample batch and we will show you the results on it.

Should we use DocAI or Scanforce?

DocAI is a standalone web application: you use it in the browser and export structured results to CSV, JSON, or XLSX. Scanforce runs inside your Salesforce org and files extraction results onto Salesforce records. They are separate products — the right one depends on where the workflow already lives.

Do our documents get used to train a model?

DocAI’s stated policy is that your documents never train a model, its own or a provider’s. The application itself is the authoritative source for the current data-handling terms, and we will point you at them rather than paraphrase them here.

Working on something like this?

Tell us the systems and the constraint. You will get an engineer's answer, not a capability deck.

Talk to an engineer