Hail Claim Payment Automation for an Italian Insurer

We built a UiPath robot that works the claims system the way a claims handler does: it picks up each claim ready for payment, reads the settlement document, runs the controls, keys the bank transfer and closes each run with a report of every payment and every refusal.

From settlement document to bank transfer

1. Work picked up automatically. The robot logs into the claims system with credentials held in UiPath Orchestrator, opens the claim message inbox and puts each claim onto an Orchestrator queue.
2. Data read from the document, not retyped. For each claim it opens the settlement PDF and extracts the beneficiary's tax code, IBAN and total amount, with Microsoft OCR as a fallback for scanned documents.
3. Authority threshold. Amounts above a threshold set in Orchestrator are not paid by the robot; they go to a person.
4. No double payments. Claims already marked as paid are stopped.
5. Right beneficiary, right account. The robot selects the beneficiary, stops if the tax code does not match the document, and checks the IBAN on the payment form against the document twice before confirming.
6. Payment keyed end to end. Amount, total payment, bank transfer, today's date, confirmation and print, all in the claims system.
7. Report as the final step. Every run ends with an Excel report emailed to the claims team, listing the payments made and the claims held back, each with its reason.

Built to UiPath best practice

• Robotic Enterprise Framework, with business exceptions (over threshold, already paid, mismatch) kept separate from system exceptions.
• Safe logout and recovery after errors.
• Configuration, threshold and credentials in Orchestrator, not in code.
• One queue item per claim, so a storm peak is absorbed without anyone changing how the robot runs.

Technology

The robot was built and tested against the insurer's claims system test environment. In the designed flow, a settled claim goes from document to bank transfer without anyone retyping a field, and every exception lands with a person.

• Settlement document to bank transfer with no manual keying in the designed flow.
• Four controls applied to every payment, every time: authority threshold, already-paid check, tax code match and IBAN match.
• Exceptions routed to people and visible in the report after every run.

The risk most teams miss

Automating payments is easy; automating them safely is the work. A robot that pays fast will also pay wrong fast, so the controls matter more than the clicks: a threshold that keeps large claims with people, a duplicate check, and an IBAN and tax code checked against the source document, not against what was typed. The second risk is the storm itself: the robot has to absorb a peak of thousands of claims without anyone changing how it runs, which is why each claim is its own queue item and every run ends in a report.