SaaS, AI & Developer Infrastructure
Document Extraction API
Your customers are typing numbers from PDFs into your product. Every one of those keystrokes is a reason they still think of your software as administration rather than automation.
- ERP vendors
- Accounting and AP software
- CRM platforms
- Document management vendors
- Insurance and lending software
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Document entry is the least popular part of almost every business application. An accounts payable team receives invoices as PDFs, scans and email attachments, and somebody re-types the supplier name, the invoice number, the line items and the tax figures into a system that already knows what a supplier looks like. The same shape appears in lending with pay slips, in insurance with loss reports, and in logistics with delivery notes.
Vendors who sell into those teams keep hitting the same wall. Building extraction properly means handling hundreds of layout variants per document type, dealing with scans produced by a decade-old office multifunction device, reconciling line items that total to something slightly different from the stated total, and knowing when the answer is not good enough to pass through unchecked. That is a specialist build, not a sprint.
What makes it worth owning as an embedded layer is distribution. One integration into an AP product serves every merchant on that platform, and the extraction volume grows with the platform's own growth rather than with its sales effort. The engineering is paid for once and amortised across every downstream account.
Who buys this
ERP vendors, Accounting and AP software, CRM platforms, Document management vendors, Insurance and lending software
What the API returns
What comes back
- Extracted header fields with per-field confidence and source coordinates
- Line items as structured rows, with arithmetic reconciliation against stated totals
- Document type classification before extraction, so the right schema is applied
- Table detection across multi-page documents including continued tables
- Normalised values: dates to ISO, amounts to decimal with currency, tax codes to a canonical set
- Supplier or counterparty matching against your existing master records
- A review flag per document with the reason it was raised
- Bounding boxes so your UI can highlight where each value came from
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/documents | Submit a document for extraction, synchronously or as a job |
| GET | /v1/documents/{id} | Extraction result with fields, line items and confidence |
| POST | /v1/documents/{id}/corrections | Return human corrections so the model improves |
| GET | /v1/schemas | Available document types and the fields each returns |
| POST | /v1/schemas | Define a custom document type for your own vertical |
| GET | /v1/queue | Documents awaiting review with the reason each was flagged |
Request and response
illustrativeRequest
{
"document_type": "invoice",
"file_url": "https://files.yourplatform.com/inbox/inv_99214.pdf",
"options": {
"return_coordinates": true,
"line_items": true,
"review_threshold": 0.90
},
"match_against": "supplier_master_v4"
}Response
{
"document_id": "doc_4f1a92",
"document_type": "invoice",
"pages": 3,
"processing_ms": 2140,
"fields": {
"invoice_number": { "value": "INV-2026-10822", "confidence": 0.99 },
"invoice_date": { "value": "2026-10-14", "confidence": 0.97 },
"supplier_name": { "value": "Northbridge Components Ltd", "confidence": 0.94,
"matched_record": "SUP-00418", "match_confidence": 0.91 },
"total_amount": { "value": 18420.50, "currency": "EUR", "confidence": 0.98 },
"tax_amount": { "value": 3193.55, "currency": "EUR", "confidence": 0.72 }
},
"line_items": [
{ "description": "Bearing housing, 60mm", "quantity": 120,
"unit_price": 48.20, "net": 5784.00, "confidence": 0.95 },
{ "description": "Freight surcharge", "quantity": 1,
"unit_price": 240.00, "net": 240.00, "confidence": 0.88 }
],
"reconciliation": { "line_items_sum": 15226.95, "stated_net": 15226.95, "balanced": true },
"review": { "required": true, "reason": "tax_amount below confidence threshold" }
}Where the data comes from
| Your customers' own documents | The only training material that genuinely matters — real layouts from the real senders your platform receives, used under an agreement you obtain from them |
| Your master data | Supplier, customer and product records, so extracted names resolve to identifiers your product already uses |
| Public form and document specimens | Government forms, standardised shipping documents and tax forms that are published openly and vary little |
| Open OCR and layout corpora | Published document-understanding datasets with licences that permit commercial training |
| Human correction history | Every edit a reviewer makes is a labelled example; capturing it is what makes accuracy improve after launch |
| Tax and currency reference data | Rate tables and currency formats, so a figure is validated rather than merely read |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Document classification first, extraction second — applying an invoice schema to a credit note is a common and avoidable error
- Layout-aware models that use token position and table structure, not plain text, because reading order in a PDF is frequently wrong
- Arithmetic validation as a first-class check: line items that do not sum to the stated total lower confidence rather than being silently returned
- Per-field confidence calibration measured against held-out human-verified documents, so a stated 0.95 actually behaves like 0.95
- Active learning from reviewer corrections, with the correction set versioned so accuracy changes are attributable
- Separate handling of digital-native PDFs and scans, since one has a text layer and the other has image noise
- Accuracy reported per field and per sender, because an average figure hides the three suppliers causing most of the rework
- Drift monitoring on confidence distributions and review rates, which catch a changed supplier template before customers complain
What it changes for the business
Entry work removed
The keystrokes your customers spend on document entry collapse to a review step, which changes how they describe your product internally.
One integration, many accounts
Extraction built once serves every customer on your platform, and volume grows with their business rather than your sales cycle.
Usage-based revenue
Per-document pricing gives you a line item that expands without a renegotiation each time a customer grows.
Cleaner downstream data
Normalised dates, amounts and matched counterparty identifiers improve every report your product already produces.
How it fits into your product
How it embeds
- White-label by default: your brand, your domain, your pricing, no MLPivot marks in any response
- Synchronous endpoint for interactive upload, asynchronous jobs with webhooks for bulk and email ingestion
- Bounding-box output so your existing viewer can highlight the source of each field without a new UI
- Per-tenant API keys and rate limits, so you can meter and bill extraction per customer
- A review queue component you can embed, or raw JSON if you would rather build your own
- Deployment inside your infrastructure or a named region where customer documents cannot leave it
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How accurate is it on handwriting?
Much worse than on print, and we would not sell it otherwise. Handwritten amounts and names on scanned forms are the weakest case in document extraction; expect low confidence and a high review rate. If your volume is predominantly handwritten we would say so during discovery rather than shipping something that quietly produces wrong numbers.
What about poor scans and unusual document types?
Skewed, low-resolution or faxed scans lose accuracy sharply, and a document type you see twice a month will never reach the accuracy of one you see ten thousand times. Both cases are handled by routing to review rather than by pretending to be confident, and the API reports per-type accuracy so you can see which ones are not worth automating.
Should everything go through automatically?
No. We would set a confidence threshold per field below which human review is mandatory, and we would recommend keeping tax and total amounts above a higher bar than descriptive fields. Straight-through processing rates in the nineties are achievable on high-volume invoice types; treating them as a target for everything is how finance teams end up with reconciliation problems.
Can you train on our customers' documents?
Only with a basis to do so. Documents belong to your customers, not to you, and your terms of service may or may not permit model training on them. We check that in discovery, and where it is not permitted we train on per-tenant isolated data or on licensed and synthetic corpora instead.
How long before accuracy is acceptable?
For common types with a few thousand labelled examples, the prototype usually shows whether it will work within weeks. Reaching production accuracy on a long tail of layouts is a matter of months of correction feedback, and we would rather plan for that openly than promise it on day one.
Related blueprints
Enterprise Search API
Search across a customer's connected documents and structured records, built as the search layer inside your own product.
Data Quality and Deduplication API
Duplicate detection, record matching, normalisation and validation, built as the data hygiene layer inside your CRM, ERP or marketing platform.
Website Change Monitoring API
Alerts when pages your customers are permitted to monitor change — prices, terms, policies, stock or staff listings — as a feature inside your product.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.