Home · Solutions · Finance & accounting

Solution · Finance & accounting

Every payment claim assembled from the project ledger, with the gaps named up front

Grant settlements without the week of photocopying

Robots pull the eligible cost lines from the project ledger, gather each invoice, payment confirmation and signed protocol, test them against the grant's rules and build the claim pack.

DepartmentalMicrosoft TeamsHuman in the loopAI where it earns its place
24payment claims a year, and each one is a folder this illustrative company rebuilds from invoices, bank confirmations and signed timesheets.

Executive summary

Challenge

Your project managers spend a week a claim proving costs the ledger already recorded.

What changes

What Mientha builds starts at the project structure in the ERP, not at the folder.

Business value

Claims leave on the contractual date rather than in the week before it, because assembly starts the day the period closes.

Systems involved

the claim library on SharePoint with its metadata and retention; the grantor's reporting portal; the project office's claim register

Business problem

Funded projects

A grant pays a share of costs the company has already incurred, and it pays against evidence rather than against a ledger. Every claim has to prove four things of each cost line: that it is real, that it was paid, that it sits on an approved budget line, and that it falls inside the eligible period and category. The ledger knows the first two. The rest is a document hunt.

That hunt is the process. The invoice sits in the finance archive under a supplier name, the payment confirmation in a bank export, the timesheet on somebody's drive, the acceptance protocol on paper at a site, signed by someone who has since moved on. None of it was filed with a claim in mind, so each is retrieved, renamed to the grantor's convention and matched by hand to its line.

Three roles carry this and none owns it. The project manager assembles, because only the project manager knows what the money bought. Finance produces the payment confirmations, and team leads sign whatever somebody forgot to collect. All three do it after a period closes, on top of the work the project exists for.

Scale is unkind. A second grant adds a calendar, a budget structure and a set of evidence rules to the same project office. The deadline never moves, because a contract sets it, so what compresses is the checking. Claims go out complete enough to submit, not complete enough to survive an audit three years later.

How it works today

This is the shape of a claim in companies running more than one co-funded project.

  1. PersonThe project manager exports the project's costs into Excel and marks which lines belong to this period
  2. PersonEach marked line is traced back to its invoice in the archive, a mailbox or a supplier folder, then renamed and saved
  3. WaitingPayment confirmations are requested from finance and arrive when somebody has time, two to four days later
  4. PersonSigned timesheets, protocols and delivery notes are collected from team leads, scanned, and matched to cost lines one at a time
  5. Risk of errorEligibility is checked from memory rather than against the agreement, so a cost outside its budget line or its period is caught late or not at all
  6. PersonThe pack is uploaded to the grantor's portal file by file, with a description retyped for each attachment
  7. WaitingWeeks later the grantor asks for what was missing, and the claim rejoins the queue behind the next period
PersonWaitingRisk of error

Why the current process costs more than it appears

Behind every exception is an hour nobody logged.

  • Assembly time is the visible cost and the smallest one. Underneath sits the money held back: a claim queried for missing evidence delays a payment the project's cash flow already assumes.
  • Evidence decays faster than anyone plans for. A protocol not collected in the month it was signed becomes a favour asked of somebody who has left the project, sometimes the company.
  • Nothing about the eligibility check is repeatable. Two project managers reading the same agreement apply different tests, and no record of either survives the claim.
  • Because the deadline is contractual and the checking is not, the checking gives way when a period is busy, and an audit years later meets people who have moved on and a drive that has been reorganised.

Cost of inaction

A full year of claim packs assembled by hand≈ €4,104
The remaining three years of the current project portfolio≈ €12,312
Three more co-funded projects, 36 claims a year≈ €6,156

Grantors do not query assembly time. They query cost lines, and a line whose evidence cannot be produced is refused at its own value rather than at €38 an hour, long after the project spent the money. The arithmetic above is therefore the smallest thing here: it prices the work, not the exposure, and the exposure is carried for as long as the grant makes the company keep its records.

The second risk is quieter. Claim assembly lives with two or three people who know which drive holds the protocols, which postings belong to which budget line and what the grantor accepted last time, and none of it is written down. Projects run for years and the retention obligation runs longer. The people do not.

Illustrative scenario

A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.

Organisation

A Central European manufacturer running six co-funded projects at once, about 900 employees; project costs sit on project structures in SAP S/4HANA; Microsoft 365 E3; a project office of two supports six project managers.

Volume

24 payment claims a year, each covering 40 to 200 cost lines evidenced by invoices, payment confirmations, timesheets and acceptance protocols; about a third of that evidence exists only as a scan.

Current process

Costs are exported to Excel and marked by hand, invoices and payment confirmations are retrieved one by one, signed documents are chased from team leads, eligibility is judged from memory, and the pack goes up file by file.

Bottleneck

About four and a half hours of assembly per claim before anything is queried, concentrated in the two weeks after each period closes and repeated when the grantor queries it.

Solution

Robots read the period's eligible cost lines, retrieve each invoice and payment confirmation, read the scanned timesheets and protocols with UiPath Document Understanding, test every line against the grant's rules table, assemble the pack on SharePoint and hand the gaps to the project manager in Microsoft Teams.

Potential outcome

In the modelled case the first complete pack exists within days of the period closing rather than in the week before the deadline, and gaps are chased while the people who signed are still on the project; modelled figures, not an outcome anyone has measured.

Proposed solution

What Mientha builds starts at the project structure in the ERP, not at the folder. On the reporting calendar a robot reads the period's postings for each project: budget assignment, cost category, amount, document number and posting date. That list is the claim's skeleton, produced from the system of record rather than by hand.

Evidence is then attached to the skeleton. For each line the robot retrieves the source invoice and the payment behind it. Scans go through UiPath Document Understanding, using a project configured on your own timesheet, protocol and delivery-note layouts, with Generative Extraction for free-form documents. Anything the extraction is unsure of becomes a validation task rather than a page in the pack.

The rules for each grant live in a table the project office owns: budget lines, accepted categories, ceilings, the open period and the evidence each needs. Every line is tested against it, and the result goes into a cover sheet. Whatever fails or is missing reaches the project manager in Microsoft Teams as a task naming the line, the document and who holds it; the finance lead approves the finished claim in the same place. Where the portal publishes an interface we use it, and where it does not a robot submits through the browser.

Native capabilities used

UiPath Orchestrator triggers, queues, credential stores and audit; SAP BAPI and SAP OData connectors; UiPath Document Understanding with Validation Station and Generative Extraction; UiPath Action Center actionable notifications in Microsoft Teams; UiPath Integration Service connectors for Microsoft OneDrive & SharePoint and Microsoft Teams; Microsoft Teams Approvals app; SharePoint libraries; Microsoft Purview retention labels

What we build

The eligible-cost extraction per project and period; the match between cost line, invoice, payment and signed document; the extraction configuration for your timesheet and protocol layouts; the rules table and its test; the cover sheet and pack structure; the tasks, the approval and the claim register

Custom integration

SAP S/4HANA cost extraction through BAPI and OData; the grantor's portal, through its interface where one exists and browser automation where it does not; payment confirmations in your bank's format

How the automated process works

  1. AutomationOn the reporting calendar Orchestrator starts one job per claim, and a robot reads the period's cost lines with budget line, category, amount and posting reference
  2. AutomationFor every line the robot retrieves the invoice and the payment confirmation, matching document number, amount and value date, flagging any payment it cannot find
  3. AutomationScanned timesheets, protocols and delivery notes are read by UiPath Document Understanding and matched to the person, the month and the cost line they support
  4. AutomationEach line is tested against the grant's rules table: budget line, category, eligible period, ceilings and the evidence that category requires
  5. AutomationThe pack is assembled in a SharePoint library named to the grant's convention, with a cover sheet listing every line, its evidence and its verdict
  6. PersonGaps and rule failures reach the project manager in Teams as tasks naming the line, the missing document and who holds it; low-confidence extractions go to validation there too
  7. PersonThe finance lead approves the completed claim in Microsoft Teams with the cover sheet attached
  8. AutomationA robot submits the approved pack through the portal, files the confirmation and archives the pack, the rule results and the decisions under a retention label
AutomationPerson

Human-in-the-loop model

Automation handles

  • Extraction of the period's cost lines with budget line, category and posting reference
  • Retrieval and matching of invoices, payments, timesheets and protocols to the line each supports
  • The rule test, the completeness check, the cover sheet, the assembled pack, the submission and the status of every claim in progress

People decide

  • Whether a cost line the rules cannot resolve belongs in the claim, which is a funding judgement rather than a data one
  • What happens when evidence does not exist, so a line is corrected, replaced or dropped before submission
  • The final approval, and the answers to whatever the grantor asks afterwards
  • The rules table itself, owned by the project office and versioned: budget lines, categories, ceilings and required evidence

Before and after

BeforeAfter
Assembly per claimabout 270 minminutes of review on an assembled pack
When missing evidence is founddays before the deadlineat extraction, weeks earlier
Cost lines traced to their evidenceby hand, in practice sampledevery line, by rule
Where a claim's evidence livesseveral drives and two mailboxesone library per claim, with retention

Systems and integrations

Where a rule suffices we do not use a model. Where judgement is needed, a person decides.

Inputs

  • project cost lines in SAP S/4HANA
  • supplier invoices from the finance archive
  • payment confirmations from the payment run and the bank export
  • scanned timesheets, protocols and delivery notes
  • the grant's rules and budget tables

Automation layer

  • UiPath Orchestrator
  • UiPath Robots
  • UiPath Document Understanding
  • UiPath Integration Service
  • UiPath Action Center

Target systems

  • the claim library on SharePoint with its metadata and retention
  • the grantor's reporting portal
  • the project office's claim register

Human touchpoints: missing-evidence tasks in Microsoft Teams; document validation in Action Center; the approval in the Teams Approvals app

project cost lines in SAP S/4HANAUiPath OrchestratorUiPath Robotsthe claim library on SharePoint with its metadatamissing-evidence tasks in Microsoft Teams

Technologies used

UiPath Robots + Orchestrator

one job per claim on the reporting calendar, queues, retries, credentials, audit

A
UiPath SAP automation (SAP BAPI and SAP OData connectors, SAP WinGUI activities)

cost lines, budget assignment and posting references out of the ERP

A
UiPath Document Understanding (IXP)

reads scanned timesheets, protocols, delivery notes and invoices; Validation Station for low-confidence fields

A
UiPath Action Center in Microsoft Teams

missing-evidence and validation tasks completed without leaving Teams

A
UiPath Integration Service (Microsoft OneDrive & SharePoint and Microsoft Teams connectors)

builds the claim library, raises tasks, posts status

A
Microsoft Teams (Approvals app)

the finance lead's sign-off, with the cover sheet attached

A
Microsoft SharePoint and Microsoft Purview

the claim library, its metadata and the Excel rules tables; retention labels and the audit of who approved what

A
Averified product capability (vendor documentation)

Illustrative economic model

Start by questioning the assumptions.

Illustrative model
2 payment claims a month (24 across the year) × 270 minutes of assembly= 9 h / month
9 h × €38 fully loaded hourly cost= €342 / month
× 12 months≈ €4,104 / year
Annual capacity released (illustrative)≈ €4,104

€38 an hour is a fully loaded project-office rate in Central Europe, and it is the least arguable number here. The 270 minutes per claim are the arguable one: they cover the cost-line export, the search for invoices and payments, the timesheet chase, the eligibility check and the upload, with nothing counted for the grantor's later questions. Twenty-four claims a year read as two a month, and nothing below was measured at a client.

Run the numbers on your data

hours released per month
of annual capacity released

An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.

Business benefits

  • Claims leave on the contractual date rather than in the week before it, because assembly starts the day the period closes
  • Missing evidence surfaces while the people who signed it are still on the project, when it costs a message rather than a favour
  • Every claimed line carries its evidence, the rule applied and the verdict, so an audit three years later is a search rather than a reconstruction
  • The eligibility test is the same whichever project manager runs it, and a seventh grant costs rows in a table rather than a quarter of somebody's year

The management view

  • Every project shows the same four numbers at any moment: lines in scope, lines with complete evidence, open gaps, days to the reporting date
  • Grant income becomes forecastable, because the date a claim can be submitted stops depending on who is free to assemble it
  • The rules this company applies to eligibility exist as an artefact somebody owns, so portfolio growth stops being a staffing question and a new grant is judged on its merits

Board-level KPIs

days from period close to submissionshare of cost lines with complete evidence at first assemblyvalue of costs queried or disallowedclaims submitted before the contractual date

Security and governance

Control is not an add-on.

  • The ERP is read by a robot account with display rights on the project structures and nothing more; the automation posts nothing, every read is recorded, and the credentials for the ERP, the portal and the bank export are drawn at runtime from whichever store your tenant already runs
  • Everything in a claim pack, invoices, payment confirmations, scanned protocols, extraction results and approvals, is filed inside your Microsoft 365 tenant, with the platform on an EU-region tenant of UiPath Automation Cloud
  • Two people act on every claim, the project manager on the gaps and the finance lead on the approval; Microsoft Purview holds the retention and the record of who approved what, and timesheets carrying personal data sit under the access rules of the payroll evidence

Why now

01

A portfolio of co-funded projects only moves in one direction. Each grant adds a reporting calendar, a budget structure and its own evidence rules to a project office sized for the last one

02

The modelled €342 a month of assembly is the smaller argument. The larger one is that a claim assembled at speed carries lines whose evidence nobody has looked at, and those lines stay open for the retention period

03

Nothing in this flow needs a model to reason. Project costs come out of the ERP through standard interfaces, scans are read by a document model configured on your own layouts, and a rules table is a table

Relevant executive roles

CFO

Grant receipts stop moving with somebody's workload, and costs at risk of being disallowed are visible before submission rather than after an audit

Project Director

Reporting stops consuming the project's own weeks, and the next grant is absorbed by a rules table instead of by the project office

Financial Controller

Every claimed line has its evidence, its rule and its approver attached, for as long as the grant obliges the company to keep them

Common questions and objections

Our grants all have different rules, so one flow cannot fit them.

The flow is the same and the rules are not. What differs is a table: budget lines, categories, ceilings, eligible period and required evidence. Adding a grant means adding rows, which is why the second project costs a fraction of the first.

The portal is our problem, not the pack.

Usually it is the other way round: uploading takes minutes and assembling takes hours. Where a portal publishes an interface we use it, and where it does not a robot drives it as a person would. Either way the pack is complete before submission starts.

Who is accountable if an automated claim contains an ineligible cost?

The same people as today. The automation extracts, matches and tests, and it will not quietly include a line it cannot evidence; the project manager and the finance lead approve what is submitted, with the rule results in front of them.

When this is not the right solution

  • Companies running a single grant with a handful of claims over its lifetime, where a disciplined folder and a checklist cost less than an automation
  • Projects whose costs are not separated in the ERP, so nothing identifies which postings belong to which grant; that separation is an accounting fix that comes first
  • Grants settled on milestones or lump sums rather than on documented costs, where there is no evidence pack to assemble

A question for the next management meeting

What is stopping the next payment claim from leaving a week early without anyone working a weekend, given that the ledger already holds every cost line it needs?

Implementation approach

We start with one slice of the process and extend only once it is proven.

We deliver

  • One completed claim taken apart with you: cost lines, evidence sources and what the grantor queried
  • Extraction of eligible cost lines per project and period, plus the evidence match and the Document Understanding configuration for your own layouts
  • The rules table per grant, the line test, the cover sheet and the pack structure on SharePoint
  • Tasks and validation in Teams, the approval, the submission route and the archive, then rollout project by project

We need from you

  • Two completed claims from different grants, with the evidence packs behind them
  • A process owner in the project office, plus whoever decides that a cost is eligible
  • Technical accounts with display rights on the project structures, and access to the claim library
  • The grant agreements and the current budget structures, in whatever form they exist

Stages

Discovery

Two completed claims taken apart: cost lines, evidence sources, rules applied, queries received

Design

Rules table per grant, evidence per category, pack structure, gap and approval model

Build

Cost extraction, evidence match, document configuration, rule test, assembly, tasks in Teams

Validation

A closed period re-assembled and compared line by line with what was submitted

Go-live

One project through a live reporting period under supervision, then the rest

Departmental. Effort follows the state of the project accounting and the quality of the scans rather than the number of grants: clean cost separation and legible timesheets make a short project, free-text references and photographed protocols do not.