Home · Solutions · Finance & accounting
Solution · Finance & accountingEvery target counted every night, every claim evidenced, every payout matched line by line
Manufacturer bonuses claimed and matched to the payout
Robots track the position against every importer target, assemble the evidence behind each claim and match every payout to it, so differences are queried instead of written off.
Executive summary
Importer bonuses are a large part of your margin, and they are tracked in a workbook one person understands.
The centre of what we deliver is a register, not a robot.
The position against every target is known every morning, per site and brand, from the importer's own registration report.
the VIN register and claim folders on SharePoint; the claim entry in each importer portal; the group's accounting system
Business problem
Manufacturer incentives
A dealer group earns little on the new car itself. Much of what the car brings arrives later, from the importer, under a programme: a quarterly volume target, a model mix, a satisfaction score, demonstrator-fleet support, co-funding of a launch event. Each has its own target, counting rule (in most schemes the registration counts, not the invoice), evidence list, deadline and payout schedule. Three brands means three importers writing terms in three vocabularies and revising them during the year.
The work is spread across people with other jobs: the controller, two sales administrators, the marketing manager, the aftersales director. Whether the group is on track is known when somebody rebuilds the count; what one more registration is worth is known, if at all, in the brand director's head.
The payout side fails on its own. A credit note or statement arrives in the importer's line names and is matched to the claim from memory. When the figures differ, the evidence is scattered and the query window has closed, so the gap is booked as an adjustment.
How it works today
The shape of it in most multi-brand groups.
- PersonWhen a director asks, the controller copies registration counts from each importer portal into the workbook and compares them with a DMS report that counts differently
- WaitingThe position reaches the brand director a day or two later and is out of date the next morning
- PersonAfter the close, the controller emails four people for the evidence each programme needs
- SystemThe claim is keyed into the importer portal or sent in the brand's template; the deadline lives in the controller's calendar
- WaitingThe payout arrives weeks later as a credit note or statement, in the importer's vocabulary, netted against other items
- PersonWhat arrived is matched to what was claimed from memory; the gap is booked as a bonus adjustment
- Risk of errorA missed target, a late claim, a rejected photograph, a short payment never queried: each costs money and none appears in any report
Why the current process costs more than it appears
The budget shows headcount, not what it is spent on.
- Money left with the importer has no ledger line: a target missed by two registrations that could have been demonstrators, a co-op claim filed a day late, a rejected evidence item; none is reported as a loss.
- Matching from memory writes differences off by default: booking the gap as an adjustment closes the month fastest, so whether the importer paid what the terms say is never checked.
- Brand directors steer blind in the weeks that matter, on a snapshot built when the controller has time.
- Accruals inherit the guesswork: the bonus receivable at month-end is a workbook estimate, so the result moves when credit notes arrive, not when the bonus was earned.
- One person knows which importer counts registrations and which invoices, which evidence each portal rejects, when each deadline falls; her absence in a quarter's last week has never been priced.
Cost of inaction
Deliberately absent from the table is the programme money itself: a quarterly target missed by two cars that could have been demonstrators, a co-op claim filed a day late, a netted credit note nobody could check. We leave it unpriced because a reader who runs a dealer group knows the size of one lost quarterly bonus better than we do.
The other risk grows with every programme added: three importers' terms, the evidence each rejects and the dates each enforces live in one person's head, and an importer audit is answered from a workbook saved over a hundred times.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A dealer group in Poland: three brands, one premium, seven sites with showrooms and authorised workshops, about 430 employees, one DMS per brand, three importer portals, a six-person finance team, Microsoft 365 E3.
38 programme settlements a year: quarterly volume and mix targets, half-yearly standards and satisfaction bonuses, demonstrator-fleet support, co-funding claims; several are settled per site.
One workbook kept by the controller; positions rebuilt on request from portal screenshots and DMS reports; evidence collected by email after the close; credit notes matched from memory.
About 22 hours per settlement, most of it after the period closes when nothing can change the outcome, and no position anyone trusts while it runs.
Robots read deliveries, invoices and registrations from each DMS and importer portal nightly into one VIN register, compute the position against every programme from terms finance keeps in a Microsoft List, post position cards to Microsoft Teams, assemble the evidence per claim and match every credit note to its claim line by line.
Desk time moves from after the period to before it, brand directors see what one more registration is worth while it can still be done, and the accrual comes from the register. Everything here is modelled, not measured at a client.
Proposed solution
The centre of what we deliver is a register, not a robot. Every night, robots read each brand's deliveries, invoices and registrations from its DMS and the registration report from its importer portal into one VIN register on SharePoint. Beside it sits the programme list in Microsoft Lists, owned by finance: period, target, what counts, evidence expected, claim deadline, payout date. Nothing in it is interpreted by software: a rule finance cannot write as a row is not automated, and a change agreed with an importer is a new row with a validity date, not an overwritten cell.
From register and list the robot computes every site's position against every open programme and posts it as a card to the brand's Teams channel, weekly and then daily in the period's last two weeks: units registered, units to target, what one more registration is worth, and the VINs invoiced but not yet reported to the importer, the gap that most often costs a met target.
When a period closes, the robot assembles the evidence pack per claim, files it with an index, drafts the claim figures and hands them to the controller as a task in Teams; on approval it files the claim on the importer's route. When the payout lands, as a statement export or a credit note in the ledger, the robot matches it to the claim line by line. Matched lines are allocated in the accounting system; every other line becomes a task in Teams with both figures and the pack attached, to accept with a reason code or query while the window is open.
No AI is involved: scheduled robots, a list, a library, cards and tasks in Teams, and a Power BI view of bonus earned, claimed, paid and open, from which the month-end accrual is exported.
UiPath Orchestrator time triggers, queues, credential store, run log; UiPath Integration Service connectors for Microsoft OneDrive & SharePoint and Microsoft Teams; UiPath Action Center tasks with actionable notifications in Microsoft Teams; Microsoft Lists version history; Power BI as a tab in Teams
The register and nightly reads, the programme list, the position engine and cards, evidence assembly, claim approval, filing, payout matching, the difference queue, the accrual export, the Power BI view
Each brand's DMS through a report export, a database view or UI automation, agreed per system; each importer portal through UI automation where no export exists; the accounting system for accruals and credit-note allocation
How the automated process works
- AutomationNightly, robots read deliveries, invoices and registrations from each DMS and the registration report from each importer portal into the VIN register
- SystemEvery site's position against every open programme is computed from the register and the list, including cars invoiced but not yet reported
- AutomationA position card goes to each brand's Teams channel, weekly and then daily in the last two weeks, with what one more registration is worth
- PersonBrand and site directors decide what to do about the gap; the registration desk clears the unreported VINs
- AutomationOn period close the robot assembles the evidence pack per claim, files it with an index and drafts the claim figures
- PersonThe controller approves the claim as a task in Teams; the robot files it on the importer's route
- AutomationWhen a statement or credit note arrives, the robot matches it to the claim line by line, allocates matched lines in the accounting system and refreshes Power BI
- PersonEach difference reaches the controller as an Action Center task in Teams, with both figures and the evidence, to accept or query in time
Human-in-the-loop model
Automation handles
- Nightly reading of deliveries, invoices and registrations into one VIN register
- The position against every open programme and the cards in the brand channels
- Evidence assembly, the claim draft, the filing
- Matching every statement to its claim, allocation of matched lines, the accrual export
People decide
- What to do about a gap to target; the robot only shows the arithmetic
- The programme terms and their interpretation, as rows with owners and validity dates
- Whether a claim goes out as drafted, and every payout difference: accepted with a reason or queried
- Anything the importer changes mid-period: a target, an evidence requirement, a disputed VIN
Before and after
Systems and integrations
Everything below runs on licences and systems you already hold, or would need anyway.
Inputs
- the DMS of each brand
- the importer portals
- the marketing library on SharePoint
- the programme terms in Microsoft Lists
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- the VIN register and claim folders on SharePoint
- the claim entry in each importer portal
- the group's accounting system
- the Power BI semantic model
Human touchpoints: position cards in the brand channels in Microsoft Teams; claim approvals and difference tasks in Action Center in Teams; the Power BI bonus view
Technologies used
nightly reads, positions, evidence, matching; time triggers, queues, credential store, run log
Areads the list and the register, files evidence packs, posts position cards
Aclaim approvals and payout-difference tasks with due dates, completed in Teams
Aprogramme terms with validity dates and history, the VIN register, claim folders
Abrand channels for the position cards; the finance channel for the difference queue
Abonus earned, claimed, paid and open by brand, site and programme; a tab in Teams
Adeliveries, invoices, registrations, statements; read by export, database view or UI automation
CIllustrative economic model
A model, not a promise.
Rebuilding the position, assembling the evidence and matching the payout are the three jobs behind the 22 hours per settlement, done weeks apart by four people. Thirty-eight settlements a year is 3.17 a month for the calculator; €26 is a fully loaded hourly cost of a finance or sales-administration post in a Polish dealer group. Nothing was measured at a client, and the bonuses themselves are deliberately not in the table.
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 position against every target is known every morning, per site and brand, from the importer's own registration report
- What one more registration is worth is visible while the brand director can still act
- Evidence packs are complete the day the period closes, so claims go in before the deadline
- Every credit note is matched to a claim line, and differences reach the importer with the evidence, inside the query window
- The bonus receivable at month-end comes from the register, so the result stops moving when statements arrive
- The controller's knowledge becomes rows the whole finance team can read
The management view
- Bonus income becomes a managed line, earned, claimed, paid and open, by brand, site and programme, at any point in the quarter
- Targets are steered with numbers the importer will also see, so the quarter-end conversation is about actions, not about whose count is right
- Every claim carries its evidence and every payout its matching, which is what an importer audit asks for
- The terms are an artefact with an owner, a version and a validity date, so a March change is applied in March, not remembered in June
Board-level KPIs
Security and governance
The automation holds exactly the rights it needs, and not one more.
- Robot users on each DMS and portal are named accounts with read rights where reading is enough and claim-entry rights only where the robot files; passwords stay in Orchestrator's credential store or Azure Key Vault
- Whoever edits a programme row cannot approve a claim computed from it; every card, claim and match names the terms version behind it
- Registration lists carry customer names and VINs where the importer requires them, so claim folders are readable by finance and the brand director only, with retention set in Microsoft Purview
- Robots run from the EU region of UiPath Automation Cloud and write only into the group's Microsoft 365 tenant; the Orchestrator run log shows every read and every line matched or queued
- No AI is used: position and matching are arithmetic on rows finance can read
Why now
CECRA, the European dealers' body, calls dealer returns in recent years "negligible" and fair remuneration "a central success factor" as manufacturers move some brands to agency distribution; whatever model a group signs next, it is paid against terms it must be able to compute itself
Poland registered 597.4 thousand new passenger cars in 2025, 8.3% more than in 2024, and cars not driven solely by a combustion engine were already more than half of them (PZPM and KPMG, 3 February 2026); targets and mix bonuses follow the market
Nothing in the build is exotic: time triggers, connectors for SharePoint lists and Teams, tasks in Teams, a Power BI tab; the modelled desk cost of about €1,820 a month is the smallest of the three reasons
Relevant executive roles
Bonus income becomes a receivable built from a register, claimed in full and matched to the euro
The position against every target is in the channel every morning, with what one more registration is worth, while the quarter can still be changed
Three importers' terms are rows the group owns, so a fourth brand means more rows, not another person
Common questions and objections
Then the row changes with a validity date and the position is recomputed that night. The earlier version stays attached to the claims computed under it.
Most groups start with what the DMS already produces: a scheduled report export or a read-only database view. Where neither exists, the robot reads the same screens your staff use, under its own named user.
The primary source is the portal's statement export or the credit note in the ledger; a PDF is read with a fixed layout per importer only where no export exists. Anything that does not map becomes a task, not a guess.
When this is not the right solution
- A single-brand dealer with a handful of programmes a year, where a workbook costs less than a build
- Terms negotiated case by case and never written down as a target and a counting rule; agreeing them in writing comes first
- A DMS that does not record the registration date and model code per VIN
A question for the next management meeting
Put last year's largest bonus programme on one page, earned under the terms, claimed and paid: do the three figures exist in this group, and do they agree?
Implementation approach
The first week looks the same at every client: we look at the data.
We deliver
- One closed year read end to end: terms, claims, credit notes, adjustments
- The programme list as rows with owners and validity dates
- The VIN register and the nightly reads from each DMS and importer portal
- Position engine, Teams cards, evidence assembly, claim approval, filing, payout matching, difference queue, accrual export
- The Power BI bonus view, and a back-test on the last closed year before the first live claim
We need from you
- Each importer's programme documents for this year and last, with the claims filed and credit notes received
- Read access to each DMS (report export, database view or a robot user) and a robot user for each importer portal
- A programme owner in finance and one brand director who will use the position cards
Stages
Discovery
One closed year read programme by programme
Programme model
Terms as rows with owners and validity dates, agreed with the brand directors
Build
Register, reads, position engine, cards, evidence assembly, matching, accrual export, Power BI
Back-test
The last closed year re-claimed by the robots and compared with what was filed and paid
Go-live
First live quarter with the controller approving every claim and difference, then hypercare
Departmental. Effort is driven by the number of brands and portals, programmes settled per site, and the integration route each DMS allows.
38 programmes a year, and the credit note is checked against the claim by memory.
Give us one brand's programme terms and its last two credit notes. We come back with a written read-out: earned under the terms, claimed, paid, and where the three disagree.
Re-claim one quarter for one brandThe neighbouring process usually has the same problem
Four DMS, four importer portals and nine sites, and the board sees last month in the third week of this one.
View solution Sales & marketingPartner deal registration and rebates without disputesRegistrations live in a mailbox, rebates in spreadsheets, and every quarter ends in an argument.
View solution Sales & marketingSales commissions calculated and explainedCommission is calculated in one enormous workbook, and every dispute means rebuilding it.
View solutionIndustries we deliver this in most oftenAutomotive retail