Home · Solutions · Legal & compliance
Solution · Legal & complianceEvery policy, renewal date and claim deadline in one register the whole group can see
Insurance policies, renewals and claims on one register
Policies and endorsements are read into a group register; renewal data, certificates and claim deadlines run from it, and only the decisions reach a person.
Executive summary
Your whole insurance programme is administered from one workbook and one person's mailbox.
Two things this solution deliberately does not do: advise on what cover to buy, and decide claims.
The renewal submission describes the group as it is today, because the values come from the ERP rather than from a plant remembering what it wrote…
the policy and claims register on SharePoint; the evidence archive on SharePoint; Power BI
Business problem
Risk & insurance
A group buys its insurance as a programme: property and business interruption, liability, motor fleet, cargo, machinery breakdown, D&O, cyber. The broker places it and advises on it. What no broker can do is run the group's own side, and that side is a permanent job: a register of what is covered where, a renewal fed with real numbers, proof of cover on demand, and claims reported inside the window the policy sets. In most groups it has landed on one person, whose register is a spreadsheet and whose evidence is a mailbox folder.
The renewal round shows the cost first. Once a year the plants are asked by email for insured values, turnover, headcount, the fleet list and the claims they remember. Answers arrive in twelve spreadsheet shapes, several of them last year's numbers copied forward, and the last lands days before the submission is due. The group then goes to market describing assets it may no longer own.
Claims show it second, and more expensively. Every policy sets a period within which an event must be notified, and that period sits in a PDF the site manager has never opened. The event happens at a plant, the deadline lives with the coordinator, and the two meet only when somebody remembers. A late notification rarely ends a claim, but it reliably turns a straightforward one into a negotiation.
How it works today
This is the administration in a group that grew by acquisition rather than by design.
- PersonThe coordinator keeps the register in a workbook, one tab per entity: insurer, policy number, period, limit, deductible
- PersonRenewal data is requested by email each spring; plants return values, turnover, headcount and fleet lists in their own formats
- WaitingHalf the returns arrive only after a reminder, and the last plant answers in the week the submission is due
- SystemPolicies and endorsements are saved to the mailbox folder, and the workbook is updated when there is time
- PersonRequests for proof of cover are answered by searching that folder and forwarding the document
- Risk of errorClaims are notified when someone thinks of it, because the deadline sits in a document the site does not hold
- WaitingReserves appear only when the broker sends a statement, so finance accrues from last year
Why the current process costs more than it appears
The cost grows where nobody is looking.
- Renewal submissions built from copied-forward numbers price the wrong company: insured values drift from what the group owns, and the gap surfaces while a loss is being adjusted.
- Missing a notification deadline carries no clerical cost, which is why it is tolerated. It converts a claim into an argument about whether the delay made the loss harder to establish.
- Proof of cover sits on the critical path of a tender or a lease, so a day's wait for one person lands in sales rather than administration. And because claim causes are never analysed on the group's side, the renewal runs on the insurer's loss history alone.
Cost of inaction
Only the first two rows are made of working time. The €40,000 in the third stands for an illustrative mid-sized fire, water or transit loss the group would carry itself if the insurer reduced or refused the benefit; it is not an average, not a benchmark, and no probability is attached to it. Polish law is clear that a policy may set a notification period, and that a serious breach can cost part of the benefit where the delay made the loss larger or harder to establish. The point is not the odds. It is that a deadline written only in a PDF is a control that does nothing.
What continues meanwhile is quieter. Insured values keep drifting from what the group owns because each submission repeats the last, the renewal stays evidence-free on the group's side, and the programme remains legible to one person, whose annual leave is a risk nobody has been asked to accept.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
An industrial group with 12 legal entities in 5 countries on SAP S/4HANA and Microsoft 365 E3; 34 policies across property, business interruption, liability, motor fleet, cargo, machinery breakdown, D&O and cyber; one insurance coordinator in group finance, a deputy in legal, one broker.
About 95 administrative events a month and 180 claims a year: roughly 15 claim notifications, 22 requests for proof of cover, 26 register changes such as vehicles on and off the fleet, 18 incoming policy documents, and 14 renewal chases averaged over the year.
A workbook, a mailbox folder and one email round every spring; documents forwarded by hand, claims notified when a site calls, reserves known when the broker reports.
About 28 minutes of handling per event, and a renewal round compressed into six weeks in which the coordinator does very little else.
A register on SharePoint holds cover, limits, deductibles, periods, notification deadlines and the broker per entity. Robots assemble the renewal pack from SAP and a pre-filled questionnaire, read policies and endorsements into the register, drive claim notification from the contractual deadline, and track reserves.
The share of events reaching a person falls from 100% to between 20% and 25%, the renewal pack is assembled in days rather than six weeks, and every reported event enters a record with its deadline already running. Every figure is an assumption of this scenario, and none was measured at a client.
Proposed solution
Two things this solution deliberately does not do: advise on what cover to buy, and decide claims. Advice stays with your broker, and the insurer decides what it pays. What Mientha builds is the administration around both, on the Microsoft 365 tenant and the UiPath Platform the group already runs.
The register is the centre of it, and it is a SharePoint list rather than a new system: one row per policy per entity, with insurer, broker, period, limit, deductible, the notification deadline the contract sets and the evidence checklist for each claim type. Version history shows what the group believed it was covered for on any past date. Documents keep it current instead of a person: policies and endorsements are read by UiPath Document Understanding using Generative Extraction, which handles unstructured wordings without a model per insurer. We extract the schedule and endorsement pages, and file the full wording alongside.
Renewal and claims then run as scheduled work. A robot pulls insured values, turnover, headcount and the fleet from SAP, then sends each plant a Microsoft Forms questionnaire pre-filled with last year's answers. A reported event opens a record with a countdown, a checklist and a named owner. Proof of cover is answered from the current valid document, and where none is valid the robot raises a request to the broker and tracks it.
UiPath Document Understanding Generative Extraction with Validation Station; UiPath Orchestrator queues, time triggers, credential store and audit; UiPath Integration Service connectors for SAP OData, Microsoft Teams and Microsoft OneDrive & SharePoint; UiPath Action Center actionable notifications in Microsoft Teams; Microsoft Forms; SharePoint versioning; Power BI
The register schema and its rules, the deadline and evidence-checklist engine, the renewal pack and its chasing cycle, extraction and validation for policies and endorsements, proof-of-cover answering, reserve tracking, dashboards
SAP S/4HANA extraction of insured values, turnover, headcount and fleet through OData and BAPI; claim statements collected from a monitored SharePoint library or an SFTP drop where the broker offers none
How the automated process works
- AutomationThe register holds every policy per entity with its period, limits, deductible, notification deadline and evidence checklist, and every change is versioned
- AutomationOn the renewal calendar a robot assembles the data pack from SAP, setting this year's values, turnover, headcount and fleet beside last year's figures
- PersonWhat no system holds goes to each plant as a Microsoft Forms questionnaire with last year's answers pre-filled; an Action Center task in Teams chases what is open
- AutomationPolicies and endorsements are read by Document Understanding and written to the register; low-confidence fields go to Validation Station
- PersonA site reports an event in Teams; the record opens with the deadline running and a named owner who decides whether it is notified
- AutomationThe notification goes to the broker or insurer, the acknowledgement is filed, and missing evidence is chased until the file is complete
- AutomationClaim statements update reserves, finance gets a monthly extract, and Power BI shows the renewal calendar, claim causes and deductible spend
Human-in-the-loop model
Automation handles
- Keeping the register current from the documents that arrive, with every field traceable to a page
- Assembling the renewal pack from SAP, distributing the questionnaire and chasing what is late
- Running notification deadlines and checklists, and filing acknowledgements against the claim record
- Answering proof-of-cover requests, and tracking new requests to the broker
People decide
- Whether an event is reported as a claim, and what the notification says
- The values and estimates the group puts its name to at renewal
- Anything the extraction flags as uncertain, and any register change that contradicts a document
- What cover the group buys, with the broker, which stays outside this process entirely
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- broker and insurer emails carrying policies and endorsements
- SAP asset, revenue and headcount data
- plant returns from Microsoft Forms
- event reports from sites in Microsoft Teams
- broker claim statements
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Document Understanding
- UiPath Integration Service
- UiPath Action Center
Target systems
- the policy and claims register on SharePoint
- the evidence archive on SharePoint
- Power BI
- the monthly extract for finance
Human touchpoints: Action Center validation and claim tasks in Microsoft Teams; the Microsoft Forms renewal questionnaire; the proof-of-cover request in Teams
Technologies used
Generative Extraction reads policy schedules, endorsements and claim statements; Validation Station handles low-confidence fields
Atime triggers for the renewal calendar and notification deadlines; queues, retries, credentials, audit
Apulls renewal data from SAP, writes the register, posts tasks
Afield validation, claim confirmation and renewal chasing without leaving Teams
Athe plant renewal questionnaire and the proof-of-cover request form
Athe policy and claims register, the evidence archive, version history
Arenewal calendar, claim causes by site, open reserves, deductible spend
AIllustrative economic model
Start by questioning the assumptions.
The 95 events are a mix rather than one repeated task: about 15 claim notifications, 22 requests for proof of cover, 26 register changes, 18 incoming policy documents and 14 renewal chases, which is where the 28-minute average comes from. €35 an hour is a fully loaded cost for a group finance or legal role in Central Europe. Only administration is priced: premium, broker remuneration and the claims themselves stay outside the model.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- The renewal submission describes the group as it is today, because the values come from the ERP rather than from a plant remembering what it wrote last year
- Claim notification stops depending on memory: the deadline is attached to the policy and the checklist reaches the site with the task
- Proof of cover goes out the same day from a current document, so a tender does not wait for one person to return from leave
- Deductible spend, claims by cause and open reserves become the group's own numbers for the renewal, and a machine commissioned or a van added appears as an exception while cover can still be arranged
The management view
- Renewal season becomes a calendar with a state against every entity, not a promise that the submission will be ready
- Gaps surface while they can still be closed: an asset the register was never told about appears as an exception, not as a discovery during loss adjustment
- Every notification and register change carries a named person and a timestamp, so the role becomes transferable: a new coordinator inherits a register and a rulebook
Board-level KPIs
Security and governance
An auditor should be able to reconstruct every decision.
- Policy documents, claim files and the register linking them stay in your Microsoft 365 tenant; robots run on your UiPath Automation Cloud tenant, EU region, and write nothing outside those two places
- SAP is read by a dedicated technical account with display rights on the asset, revenue and headcount views the submission needs and nothing else; its secrets live in the Orchestrator credential store or Azure Key Vault
- Claim files carry personal data about employees, drivers and third parties, so the claims library is separately permissioned, labelled in Microsoft Purview and given a retention rule set with legal
- Generative extraction is governed rather than trusted: confidence thresholds per field, every correction recorded in Validation Station, and the UiPath AI Trust Layer deciding which models run and where
Why now
Every policy sets its own notification period, and Polish law attaches consequences to breaching it (Civil Code, art. 818); groups operating in several countries usually face stricter contractual conditions on top. A register that knows the deadline is the cheapest control for that exposure
The group's footprint changes faster than an annual questionnaire captures it: entities acquired, lines commissioned, assets revalued, fleets grown. Meanwhile the modelled €1,552 a month of administration continues regardless of whether the register is right
Reading unstructured policy documents no longer needs a model per insurer or a bespoke OCR project, and human tasks now complete inside Microsoft Teams, so this is built on what the group already licenses
Relevant executive roles
Insured values, deductible spend and open reserves become numbers finance owns, and the renewal submission stops being a leap of faith taken once a year
Notification deadlines become enforced controls with an evidence trail, rather than clauses in documents nobody re-reads
Sites get proof of cover the day they ask, and reporting an incident becomes one message in Teams rather than a search for whoever holds the policy
Common questions and objections
The broker places the cover, advises on it and usually runs the claim with the insurer. What no broker knows is that a machine moved between two plants in March, or that a site already holds three of the five documents a claim needs. The register sits on your side of that relationship and makes the broker faster, not smaller.
The policies are not the work; the events around them are, and there are roughly 95 a month in the modelled group. Even so, the stronger case is the deadline and the evidence rather than the hours, which is why the model prices both.
No, and it should not. The automation opens the record, starts the deadline, attaches the checklist and puts the decision in front of a named person. Nothing reaches an insurer until that person acts.
When this is not the right solution
- A single entity with a handful of policies and a few claims a year, where a shared calendar and a tidy document library do the same job for nothing
- The group has handed the whole administration to its broker or a captive manager, and treats the broker's system as the register of record
- Policies exist only on paper and there is no appetite to digitise the back file first; the register has to be built on documents before it can be kept by them
A question for the next management meeting
If a serious loss happened at our smallest site tonight, which policy would answer it, who would notify the insurer, and by what date does the contract say that has to be done?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- A review of your policy schedule and one renewal round: what was asked of the plants, what came back, and where the submission lost time
- The register on SharePoint: cover, limits, deductibles, periods, deadlines, brokers and insurers per entity, with version history and access rules
- Extraction of policies and endorsements tuned on your own wordings, with validation for anything uncertain
- The renewal pack: SAP extraction, the plant questionnaire in Microsoft Forms with previous answers pre-filled, and the chasing cycle
- The claim path: deadline countdown, evidence checklist per claim type, notification, acknowledgement filing and reserve tracking, with Power BI reporting, the monthly finance extract and a runbook
We need from you
- The current policy schedule, and the policies and endorsements in force as files
- One renewal round's correspondence, including the plant returns as they arrived
- A process owner in group finance or legal, a broker contact, and a technical account with display rights on the SAP data
Stages
Discovery
Policy schedule, event mix, contractual deadlines and the data behind insured values
Design
Register schema, deadline and evidence rules, and the boundary between administration and decision
Build
Extraction models, robots, the SharePoint register, the Forms questionnaire and the Teams tasks
Validation
Last year's renewal round replayed on the built process, plus a sample of closed claims
Go-live
One entity or one policy line under supervision, then the rest of the group with hypercare
Departmental. Effort is driven by the number of entities and policy lines, the quality of the SAP data behind insured values, and how many brokers the group deals with.
The renewal round starts in six weeks and the data still lives in twelve spreadsheets.
Send us your policy schedule and one renewal round's email trail: what was asked of the plants, what came back, when the submission went out. You get back a register design, the deadline and evidence rules we would automate first, and a written assessment of what stays with people.
List every policy and its deadlineThe neighbouring process usually has the same problem
Last year's sustainability numbers cannot be reproduced without the people who sent them.
View solution Finance & accountingF&I commissions matched to the deal that earned themYour F&I income is checked when an adviser asks about a bonus, not when a partner underpays.
View solution ProcurementIndexation clauses that get applied, and renewals decidedYour suppliers calculate your annual price increase. Nobody on your side checks their arithmetic.
View solutionIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsRetail & e‑commerceServices & IT