Insurance policy entry software where the entry is already in the document.
Policy data entry is transcription: a human reads a schedule and types what it says into a form. Insoora removes the typing without removing the human — rules read the document, anything unclear is flagged rather than guessed, and a person confirms the record against the page it came from.
- Fields read from the PDF, not retyped
- Most policies need no AI call at all
- Unclear fields flagged, never invented
- A human confirms before it is saved
On this page
The work being replaced
What policy data entry actually costs
Not the minutes. The minutes are the smallest part of it.
A motor schedule has something like forty fields worth keeping: the vehicle, its engine and chassis numbers, five separate IDV figures, own-damage and third-party premium, a no-claim bonus percentage, two sets of cover dates. Typing them takes a few minutes. The cost is not the few minutes.
The cost is that transcription is lossy and silent about it. Most agents, faced with forty fields and a sheet with eight columns, keep the eight — insurer, policy number, name, premium, start, expiry, and two more — and the other thirty-two stay inside the PDF. A year later the information exists, in a file, in a folder, unsearchable.
The second cost is that a typed figure has no provenance. A cell saying ₹12,450 is a claim with nothing behind it; when a customer disputes it, the only recourse is to find the document again and read it again. And the third is that transcription errors are undetectable by inspection — a digit transposed in a policy number looks exactly like a correct one.
Why "faster data entry" is the wrong goal
Software that gives you a better form to type into has made the transcription faster and left all three costs in place. The fields you skip are still skipped, the figures still have no source, and the typo is still invisible.
The goal worth having is that the policy record is derived from the document and stays attached to it. Then the fields are not selected by whoever was typing, the figures can be checked against their page, and a mis-read is something the system can flag because it knows it was unsure.
How the reading happens
From uploaded PDF to confirmed record
The order matters, and so does which steps involve a model. Most policies never reach one.
- 1
The file is checked and classified
Before any extraction, a classifier decides whether this is an insurance document at all. An RC, an invoice, a bank statement or a payslip is rejected outright. A borderline document is held for an administrator to accept or reject rather than processed on a guess. - 2
Text is taken from the page
The PDF's own text layer is parsed first, which is exact. Only pages with almost no selectable text are rendered and put through OCR — Tesseract by default, with cloud OCR services available if an administrator configures one. OCR results are cached, so a page is never read twice. - 3
Deterministic rules extract the fields
Label-and-value pairs, inline values, period expressions, table cells, regular expressions and per-insurer templates. Then date and amount parsers normalise what was found. This is the part that does the work: a normal policy comes out of it complete, with no AI call at all. - 4
The figures are checked against each other
Net premium plus tax against the final premium, the IDV components against the total, a name split into parts. Arithmetic that does not reconcile is treated as a signal that the extraction needs a human, not rounded away. - 5
Only what is missing goes to a model
If a required field is still absent or genuinely ambiguous, and only if an administrator has enabled AI, a small number of narrowly-scoped calls run over the relevant chunk of text. The default configuration is AI off and a local model; cloud providers are an explicit choice with budget limits, never a silent fallback. - 6
A human confirms it
Values are validated against a schema, scored for confidence, and anything below the bar is flagged for review beside the page it came from. By default nothing is written to the policy record until a person confirms it.
At volume
A folder of policies, in one action
One policy at a time is a demo. A year's backlog is the actual problem.
Bulk upload accepts many PDFs in one go and processes them together. The queue shows the state of every file — read, needs review, failed — so attention goes only to the files that need it rather than to all of them.
A file that fails does not stop the batch. A duplicate is recognised as one rather than creating a second record of the same policy. And because each document's state is visible, a backlog becomes a finite piece of work: the number of files needing a human is a number you can see.
- Many files per upload, processed together
- Per-file state: read, needs review, or failed
- Duplicates recognised rather than re-recorded
- A failed file is isolated, not fatal to the batch
What it does not do
Large files and long documents take longer, and the queue is where that is visible. There is no promised throughput figure, because it depends on page count, whether OCR was needed, and what else the platform is processing.
When an insurer's layout fights back
A rule written once, by a person
Every agent has one insurer whose schedule reads badly. This is what is done about it.
An administrator can add per-insurer field aliases, regular expressions and validation rules — "on this insurer's layout, cover expiry is labelled Period of Insurance, or Valid upto" — and test the rule against a real document before saving it. Later policies from that insurer are then parsed with it.
A separate corrections view shows where extraction was changed by hand, which is what tells an administrator that a new rule is worth writing: eleven manual corrections to the same field on the same insurer is a pattern, and one rule retires it.
This is deliberately a human writing a rule rather than a model learning a layout. Insoora does not train on your documents and does not improve by itself, and the trade-off is worth being explicit about: the gain is that behaviour is inspectable and repeatable, the cost is that a new layout needs someone to notice it.
- Field aliases and patterns, per insurer
- Tested against a real document before it is saved
- A corrections view showing where humans had to intervene
What it does not do
Template rules are configured by an administrator, not by an agent in their own portal. Insoora does not learn an insurer's layout on its own and trains no model on your documents.
Three ways to get a policy into a system
Typing, templates and reading
Worth comparing honestly, because reading a document is not strictly better at everything.
| Typing it in | A fixed import template | Reading the document | |
|---|---|---|---|
| Setup needed | None. | A mapping per insurer, maintained whenever a layout changes. | None for common layouts; a rule for stubborn ones. |
| Fields captured | Whatever the person typing had time for. | Whatever the template defines. | Everything the schedule states and the platform models. |
| Provenance | None. The figure stands alone. | None. The source file is usually discarded. | The original PDF stays attached; coverages record their source page. |
| Failure mode | A silent typo. Looks correct, is not. | A layout change produces wrong values in the right columns. | An unreadable field is flagged, not filled. The failure is visible. |
| Scanned or photographed policies | Works, slowly. A human can read a bad scan. | Not applicable. | OCR runs, and accuracy drops. Sometimes a human still reads it better. |
| Effort at 400 policies | Weeks, and the fields get fewer as it goes on. | Fast once mapped, per insurer. | One upload, then a queue of the files that need attention. |
The honest row is the fifth. On a poor photograph of a printed policy, a careful human still beats OCR. The case for reading documents is not that it never fails — it is that when it fails it says so.
Expectations worth setting
What this does not promise
Extraction is the claim most easily oversold in this market, so here is what is not being claimed.
No accuracy percentage
Insoora publishes no extraction accuracy figure. One that was measured on a sample of insurers you do not sell would not predict your results, and a number invented for a landing page is worse than none. Upload your own documents.
Not zero-touch by default
The default configuration requires a human to confirm an extraction before it becomes a policy record. There is a setting an administrator can change, but the product as shipped assumes review.
Scans and photographs read worse
Insurer-issued digital PDFs read best because their text is selectable. A page with almost no text goes through OCR, and OCR on a phone photograph of a creased printout is the weakest case this product has.
No learning from your corrections
Correcting a field fixes that record. It does not teach the system anything. A recurring mis-read becomes a rule only when an administrator writes one, which is why the corrections view exists.
Frequently asked questions
Questions this page should answer
Keep reading
Where to go next
The pages that cover the next part of this, with what each one adds.
Upload the schedule you would least like to retype.
Extraction quality on your insurers' layouts is the one thing no page can tell you.