Insurance policy management software that starts from the policy document itself.
Most policy management software asks you to type a policy in. Insoora reads the PDF you were already sent, extracts the fields, files the record under the right customer and keeps the original document attached to it — so the record and its evidence never separate.
- Policy records built from the document
- One customer, every policy they hold
- Expiry dates taken from the schedule
- Original PDF kept against every record
On this page
What you are managing
A policy record, and the document it came from
The unit of work in Insoora is not a row in a register. It is a policy record with its source document still attached.
When a policy PDF is uploaded, Insoora parses the document's own text layer — or runs OCR over the page when it is a scan with no text — and extracts the fields an agent would otherwise retype: policy number, insurer, insured name, cover start and expiry dates, premium, and vehicle or asset details where the policy has them.
Those fields become a policy record. The original PDF stays attached to it, which is the part that matters when a customer disputes a figure or a claim needs the schedule: the record is a reading of the document, and the document is always there to re-read.
The policy list is the screen an agent works from. It is searchable by customer, insurer, policy number and status, filterable by expiry window, sortable, and its filters live in the URL — so a filtered view can be bookmarked or sent to a colleague who has the same access.
- Fields the parser cannot read confidently are flagged for review, not filled in with a guess
- Every record shows the extracted value beside the page it was read from
- Policies are classified by line of business: motor, health, life, travel, property, marine and personal accident
What it does not do
Insoora does not issue policies, quote premiums, connect to an insurer's system or submit a renewal. It manages the records of policies that have already been issued. Nothing here talks to an insurer.
What the record gives you
Six things that stop being manual
Each of these is a consequence of the record being derived from the document rather than typed beside it.
No re-keying
The fields come out of the PDF. An agent confirms what was read instead of transcribing a schedule into a form.
Findable in one search
Search by customer, insurer, policy number or status, then filter by expiry window and sort the result.
Year-on-year history
A customer's policies stack up by year with each year's original document kept against it.
Renewals from the schedule
The 30-day renewal list is built from the expiry date printed on the policy, not from a reminder someone set.
Access decided by role
Agents, sub-agents, policyholders and administrators each reach only what their role permits, checked on the server.
Your data, exportable
Authorised agents export policy and renewal lists as CSV or Excel, following the same access rules as the screen.
The lifecycle
What happens to one policy, from PDF to renewal
Five stages. The first four happen once per document; the fifth happens every day without anyone doing anything.
- 1
The document arrives
Upload one PDF or a few hundred. Each file is checked, classified as an insurance document or rejected before any extraction runs, and queued. - 2
The fields are read
Deterministic rules run first — label and value pairs, tables, date and amount parsers, arithmetic checks such as net premium plus GST, and per-insurer templates. Most normal policies are extracted without any AI call at all. - 3
Anything unclear is flagged
A field the parser could not read confidently is marked for review and shown beside the page it came from. You confirm or correct it; the document stays the source of truth. - 4
It files itself under the customer
The mobile number on the policy is matched against the numbers you hold on record. A policy that cannot be matched waits to be assigned rather than landing on the wrong customer. - 5
It appears on the renewal list
From the expiry date on the schedule. A policy uploaded a year ago and forgotten about still turns up thirty days before it ends.
The other end
The policyholder sees the same records
A policy record is only half useful if the customer still has to ring you for a copy of their own policy.
Every policyholder can be given a login to their own portal, where they see a year-wise history of the policies their agent has shared with them and can download the original PDFs. The portal is strictly read-only: a customer account holds no write permission anywhere in the system, so there is no action there that could change a record.
A policyholder sees only the policies assigned to them, never another customer's. That boundary is enforced on the server for every request, not by hiding a button.
- A year-wise list of everything shared with them, with the documents
- How long each cover has left, read from the policy
- Registration by the mobile number their agent already holds on record
What it does not do
The customer portal cannot renew, pay for, endorse or cancel a policy. It shows records and documents. Renewing is still a conversation with the agent.
The comparison that matters
A spreadsheet register against a policy record
Most Indian agencies manage policies in Excel today, and it works until one of these five things happens.
| The situation | In a spreadsheet register | With a policy record |
|---|---|---|
| A customer asks for last year's policy | Search a shared drive or an email thread for a filename nobody standardised. | Open the customer, open the year, download the document kept against that record. |
| A policy was endorsed mid-term | The sheet still shows the old expiry. Nothing anywhere flags the disagreement. | Re-read the revised document and the record updates with it; the old document is still there. |
| Two people are entering policies | Two copies of the sheet, or one that is locked whenever the other has it open. | One book of business. Sub-agents upload into it and the agency sees all of it. |
| You want to know what expires in March | Sort by a date column that was typed by hand, and hope every row was typed right. | Filter by expiry window. The dates were read off the schedules. |
| A figure is questioned | The cell says ₹12,450 and nothing says where that came from. | The field is shown beside the page of the PDF it was extracted from. |
None of this makes a spreadsheet wrong for a book of forty policies maintained by one person. It makes it a liability for four hundred maintained by four.
Before you commit a book of business
What this software does not do
Stated here rather than discovered after you have uploaded three hundred policies.
It is not connected to any insurer
There is no integration with an insurer's portal or API. Insoora reads the documents an insurer has already issued. It cannot fetch a policy, issue one, or submit a renewal on your behalf.
Extraction accuracy depends on the document
Insurer-issued digital PDFs read best. Photographs of printed policies and low-quality scans read worst. Insoora publishes no accuracy percentage because it does not measure one it could stand behind.
There is no commission or accounting module
Policy and premium figures are recorded as they appear on the document. Insoora does not calculate commission, raise invoices, reconcile brokerage or post to a ledger.
Security has stated gaps
Policy PDFs sit in private storage behind expiring links and all traffic is over HTTPS, but there is no multi-factor authentication yet, no security certification, no penetration test, and no published data-retention schedule.
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 three policy PDFs and see what it reads.
That is the only honest way to judge how well it handles your insurers' layouts.