Add a new document type without a 4-week engineering project
An IDP platform where business users define new document types, mark up sample fields, and ship a working extraction pipeline. The engine is the one running our enterprise invoice extraction, and the UI is built for non-engineers.
Discuss a pilot →Quick facts
- Business size
- Mid-market and enterprise, operations processing diverse document types
- Timeline
- 6-10 weeks test (platform and first document type), 3-5 months pilot, 6-9 months production
- Budget range
- Pilot from €50k. License model varies.
- Hardware
- Cloud or on-prem.
- Data needed
- Sample documents per type. Initial human marking of 30-100 examples per type.
- Evolution
-
- Genesis
- Custom-built
- Product
- Commodity
A vendor sells this result ready-made. We set it up and tune it to you.
What this scale means
Further right means more proven and cheaper. Further left means newer and riskier. Here is the test for each step.
- Commodity
- You could get the result yourself from a ready service, with almost no work. We rarely take these on.
- Product
- A vendor already sells this result turnkey, like shelf recognition from Trax or document reading from ABBYY. If one of them fits you, use it. You come to us when it does not: when it has to run on your own servers, cost less, or fit systems the product cannot reach.
- Custom-built
- Vendors sell only the parts. A tool like Tableau hands you charts, but the dashboards and metrics for your business still have to be built. That build is the work, and that is us.
- Genesis
- The approach exists but does not work reliably yet. You are betting on it maturing, so it costs more and carries more risk.
Expected outcomes
The Problem
Document data extraction works, see document-data-extraction, but every new document type historically required an ML engineer to build the extraction pipeline. For an organization with one or two document types, that’s fine. For one with twenty different supplier formats, dozens of certificate variants, and a tail of one-off contracts, it becomes a bottleneck.
The conventional alternative is generic OCR with brittle templates. It works only for documents with rigid structure. The moment a new format appears, the template breaks and someone has to re-configure.
A no-code IDP platform changes the shape: business users (back-office leads, document-ops managers) define new document types themselves. They mark up sample documents. The platform trains the models. The pipeline goes live. The ML engineer is involved only for the underlying infrastructure. Each new document type no longer needs one.
What the Solution Does
A self-service platform on top of our enterprise document-extraction engine.
- Define document type: give it a name, describe its purpose.
- Mark up samples: upload 30-100 example documents, draw boxes around the fields you want extracted, and label them.
- Train: the platform trains the model in the background.
- Test: upload more documents to see extraction quality.
- Deploy: the pipeline is live, and downstream systems consume the extracted data via API.
- Improve: moderators correct mistakes, and the platform retrains automatically.
Where It Fits
This makes sense if you…
- Process diverse document types (5+ distinct formats)
- Have business users capable of working with a configuration UI
- Want to reduce engineering involvement per new document type
- Have the underlying infrastructure budget (this is a platform you run, distinct from a SaaS subscription)
This is probably not the right time if you…
- Process one or two stable document types, direct configuration is cheaper
- Don’t have business users willing to engage with markup workflows
- Need extreme accuracy on every document type, some require custom engineering
Business Value
Speed to onboarding. New document types ship in days, down from weeks. The business moves faster on new formats.
Reduced engineering bottleneck. ML engineers focus on the platform. Each new document type runs without them.
One shared engine. Accuracy is comparable to engineer-built pipelines on similar document types. The architecture is identical: the only difference is a no-code configuration surface.
How It Works
1. Configuration UI
Business users define:
- Document type name and description
- Field list (what to extract)
- Optional validation rules (number formats, date formats, required fields)
2. Sample markup
Upload 30-100 sample documents. Use a Label Studio-style UI to draw boxes around fields and label them. Markup time is typically 5-10 minutes per document.
3. Training (automated)
The platform handles training: YOLOv5 for field detection, OCR for text reading, post-processing for validation. Datapipe orchestrates.
4. Testing and validation
Upload more documents to check extraction quality. Confidence scores surface low-quality predictions. Users mark corrections; the platform retrains.
5. Deployment
When accuracy crosses your threshold, the pipeline is live. Downstream consumption via REST API. The architecture matches engineer-built deployments.
Stack
This matches document-data-extraction: YOLOv5, Google Cloud Vision OCR or self-hosted alternatives, Datapipe, a Label Studio-style markup UI, and audit logging.
What You Need to Make This Work
Data. Sample documents per type. 30-100 examples to bootstrap.
Integrations. Document ingestion. Downstream API for extracted data.
Hardware. Cloud or on-prem.
Team. A document-ops lead. Business users for markup (around 5-10 hours per new document type).
Implementation Roadmap
1. Test (6-10 weeks)
Deploy the platform. Configure one initial document type as proof. Train business users. Output: a working platform and one operational document type.
2. Pilot (3-5 months)
Business users onboard 3-5 additional document types. Build dashboards for accuracy and throughput. Output: 5+ operational document types, documented business outcomes.
3. Production (6-9 months)
Operations team owns the platform. Continuous addition of document types. Engineering involvement only for infrastructure maintenance.
Keep in Mind
- No-code has accuracy limits. Some document types benefit from custom engineering. We surface confidence scores during testing so you see where it weakens.
- Markup is real work. Business users need to invest in marking up samples. We tune the UI for speed, and the work is still non-trivial.
- Validation rules matter. Without validation, the platform extracts whatever the model produces, including garbage on bad documents. Rule design is part of the value.
- Some documents are intractable. Truly free-form documents (legal narratives, articles) do not fit this pattern. The platform is for structured documents.
FAQ
Can business users really do this without ML expertise?
Yes, for structured documents within the platform’s scope. We train users; first document type usually takes a few sessions to bootstrap; subsequent ones are quick.
How does this compare to commercial IDP platforms (Hyperscience, Rossum)?
Commercial IDP platforms are excellent off-the-shelf products. Our approach is the right choice when you need: custom underlying ML, fully on-prem deployment, integration with non-standard data sources, or substantially lower per-document cost at high volume.
Can the platform handle handwritten documents?
Partial. Printed handwriting is tractable. Cursive narrative is much harder. We surface measured accuracy per document type.
Ready to Discuss?
If you process diverse document types and your engineering bottleneck for new formats is a real cost, this is a useful platform investment. We’ll walk through your document mix and your team, and tell you what to expect.