Home · Solutions · Finance & accounting
Solution · Finance & accountingThe invoice arrives from KSeF with the commitment that authorised it already attached
Invoices from KSeF booked to the right budget line
Robots collect KSeF invoices for every registered unit, match each one to its commitment, propose the budget classification and put the substantive confirmation in Teams; people decide.
Executive summary
A structured invoice states the amount. It does not state which unit ordered the work.
A structured invoice arrives as data, so nothing has to be read from a picture and no document model is needed.
An invoice reaches the person who ordered the work on the day it arrives, so confirmation and payment term stop competing.
the finance and budget system, with classification and commitment reference; the SharePoint evidence record; the Power BI semantic model
Business problem
Public finance
Until this year a purchase invoice arrived with its context attached: a covering email to whoever had ordered the work, often a delivery protocol behind it. A structured invoice has none of that. It arrives addressed to a tax identification number, and the office reconstructs who ordered what, against which contract, and out of which budget line it is paid.
That is harder for an authority than for a company, which receives only its own. The Ministry of Finance has confirmed that the element in which an issuer can name a subordinate unit is not obligatory, technically or legally; where an issuer does complete it, it carries that unit's own tax identification number, and offices may also work with internal identifiers they give their suppliers. In practice a large share arrives with it empty, and the unit is worked out from the supplier, the amount, the description and, failing those, a telephone call.
The second half of the work cannot be shortened by anyone in accounting. Central accounting knows what the invoice says; it does not know whether the fence was repaired or the hours billed were worked. That confirmation belongs to the head of the organisational unit that ordered the work, and it travels as a printout that comes back with the classification in handwriting. Meanwhile the payment term runs, invoices concentrate at the start of the month and again at the reporting cut-off, and two people carry the knowledge of all eighteen units.
How it works today
- PersonSomebody in central accounting signs in for the authority and then for each unit in turn, and downloads yesterday's invoices into a folder tree
- PersonEach invoice is read for clues about who ordered it: the supplier, the value, the description, sometimes an identifier typed in by hand
- WaitingInvoices whose owner is not obvious sit on a desk for two to four working days, until a telephone call settles it
- PersonA printout goes to the head of the organisational unit and comes back with the budget classification written on it, to be keyed into the finance system
- Risk of errorAn invoice against no commitment, a duplicate, or one for a unit that ordered nothing surfaces at the payment run
Why the current process costs more than it appears
The cost grows where nobody is looking.
- Working out which unit an invoice belongs to is a task nobody records. It appears in no plan and no budget; it is simply why the morning is gone.
- Days spent waiting for a confirmation are days of the payment term, and a late payment costs interest from the same budget as the service itself.
- Knowledge of eighteen units and their suppliers sits with two people, so a holiday turns routing into guesswork and lengthens every queue behind it.
- Evidence appears only when somebody asks for it. The link between an invoice, its commitment and the person who confirmed the work is spread across three places, one of them paper.
Cost of inaction
Public money goes into this quietly and lawfully. The hours sit inside the establishment, so no line in any budget says what routing an invoice costs, and no decision has to be taken for it to continue. What changes without anyone choosing it is the volume.
The exposure that grows is evidential. An office that cannot show which commitment authorised a given invoice, and who confirmed the work, reconstructs that from folders and memory whenever it is asked. Late payment interest sits in the same column: small per invoice, never budgeted, paid from money meant for a service.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A city office of about 600 staff in Poland, keeping the accounting of 18 subordinate units: schools, a social-assistance centre, a sports facility, a road-maintenance depot. One finance and budget system from a domestic supplier, Microsoft 365 E3, contracts in a register kept by legal.
3,400 purchase invoices a month for the authority and its units, all received through KSeF; roughly 55% relate to a framework contract, 30% to a one-off order placed by a unit, 15% to no commitment anyone can find.
One person downloads per identifier each morning; the ordering unit is deduced from supplier and value; a printout travels there for confirmation and the classification is keyed back in.
About nine minutes per invoice of resolving the unit, finding the commitment, writing the classification and moving the document to whoever can confirm the work; the load doubles in the first ten days.
Robots collect invoices from KSeF for every registered identifier, match each against the contract and commitment registers, propose the classification, and open a confirmation task in Microsoft Teams for the head of the ordering unit.
In the modelled case the nine minutes shrink to the time a person needs to confirm the work was performed, invoices reach the ordering unit on the day they arrive, and any invoice traces back to the commitment behind it. Arithmetic on the assumptions above, not something measured in an office.
Proposed solution
A structured invoice arrives as data, so nothing has to be read from a picture and no document model is needed. What remains is matching and routing, which is a rules problem. The flow Mientha delivers is deterministic: every decision it makes is a rule the treasurer can read and change, and no language model or agent sits in it.
A scheduled workflow authenticates to KSeF for the authority and for every identifier the office has registered, and turns each new invoice into a queue item in UiPath Orchestrator, source file kept. Where the issuer named the subordinate unit, the robot takes it from there; where the issuer did not, the rules take over: contract number, commitment register, delivery point, the order identifier your units put on their orders. It then checks the amount against the balance available, compares prices with the contract and looks for a duplicate.
From the commitment the flow copies forward the classification, the task and the ordering unit, and the head of that unit receives a UiPath Action Center task inside Microsoft Teams: the invoice, what it matched, the balance left and the proposal. That person confirms the service happened, corrects the proposal if it is wrong and signs off; only then is the document booked. What ties to no commitment goes to a named exception queue with its reason attached, not to a mailbox where it becomes nobody's.
UiPath Orchestrator queues, schedules, folders, retries, audit log and credential store; UiPath API workflows; UiPath Integration Service Connector Builder with the Microsoft Teams and Microsoft OneDrive & SharePoint connectors; UiPath Action Center actionable notifications in Microsoft Teams
The collection schedule per identifier, the matching rules against the contract and commitment registers, the balance and duplicate checks, the classification proposal, the exception categories with named owners, the Teams tasks and the per-unit dashboard
The KSeF 2.0 API as a custom connector built with UiPath Integration Service Connector Builder; the finance and budget system through its API, or its interface where none exists
How the automated process works
- AutomationOn schedule, the workflow authenticates for every registered identifier and creates one queue item per invoice received since the last run
- SystemThe unit is resolved: from the element naming it where the issuer completed it, otherwise from the contract, the commitment or the order identifier
- AutomationThe invoice is tied to a contract or commitment; the robot checks the balance, compares prices, looks for a duplicate and copies the classification forward
- PersonThe head of the ordering unit receives an Action Center task in Teams, confirms the work was performed, corrects the classification if needed and signs off
- AutomationConfirmed invoices are written into the finance system with classification and commitment reference, and the evidence record is closed
- PersonInvoices with no commitment, an exhausted balance or a price outside the contract go to a named exception queue and to the person who owns it, and a dashboard per unit shows what waits for whom
Human-in-the-loop model
Automation handles
- Collection from KSeF for every registered identifier, with the source file kept as the original
- Matching to the contract and commitment registers, the balance check and the search for a duplicate
- The classification proposal, the routing to the ordering unit, reminders and the daily status per unit
People decide
- Whether the service, delivery or work actually happened; that confirmation stays with the head of the unit that ordered it
- The classification: the robot proposes what the commitment says, and what the authorised person accepts is booked
- What happens to an invoice with no commitment behind it, and the rules themselves, which belong to the treasurer and the head of accounting
Before and after
Systems and integrations
The stack is deliberately short: one engine, one execution layer, one place where a person decides.
Inputs
- KSeF, queried per registered identifier
- the contract register
- the commitment register
- the order and delivery records held by the units
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath API workflows
- UiPath Integration Service
- UiPath Action Center
Target systems
- the finance and budget system, with classification and commitment reference
- the SharePoint evidence record
- the Power BI semantic model
Human touchpoints: Action Center tasks in Microsoft Teams; the named exception queues; the daily per-unit summary in a Teams channel
Technologies used
one queue per unit, schedules, retries, folder-level access, audit log
Aa custom connector for the KSeF 2.0 API; retrieval per identifier with no user interface
Aconfirmation and classification correction where heads of units already work, with due dates
Athe evidence record per invoice: source file, match, decision, person, time
Aa page per unit: received, matched, waiting, exceptions, days to the payment date
Aregisters read; the booked document written with its classification
CIllustrative economic model
Numbers you can check against your own data.
Nine minutes is the routing work and not the accounting: resolving which of the eighteen units an invoice belongs to, finding the commitment, writing the classification and moving the document to whoever can confirm the work. Twenty euro an hour is a fully loaded cost of an administrative post in a Polish authority. The table prices capacity released inside the same establishment, not posts removed, and every input is an assumption.
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
- An invoice reaches the person who ordered the work on the day it arrives, so confirmation and payment term stop competing
- Every invoice is checked against a commitment and its remaining balance before anyone is asked to confirm it
- Capacity is released inside the same establishment: routing stops consuming the first ten days of every month, and bringing another unit into central accounting means a routing rule, not a post
- Local suppliers are paid on time more often, which matters most to the small contractor for whom one late transfer is a month of cash flow
The management view
- The treasurer sees at any hour how many invoices wait for whom, in which unit, and how long until a payment is late
- Budget discipline becomes a property of the flow: nothing is booked without a commitment reference and a named confirmation
- Exception statistics by cause show where the office's own ordering discipline leaks, and the routine survives absence, because routing knowledge sits in rules rather than memory
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- Each identifier authenticates to KSeF under the office's own authorisation model, and the robots read those credentials from the Orchestrator credential store rather than holding them
- Orchestrator folders follow the organisational structure, so a unit's accountant and its head see that unit's queue and nothing beyond it, while invoice files, the evidence record and the confirmations stay inside your Microsoft 365 tenant and the automation runs in the EU region of UiPath Automation Cloud
- No robot confirms that a service was performed and none books a document a person has not accepted; the confirmation, its author and its time are part of the record
- Rules that propose a classification or route an exception are versioned and changed only with the treasurer's sign-off
Why now
The inbound channel has already changed. Receiving invoices through KSeF applies in principle to every taxpayer including local-government units from 1 February 2026, and the Ministry of Finance issued a separate part of its KSeF 2.0 handbook for those units dated 19 February 2026. What happens after the download is the part nobody automated.
The 510 hours a month in the model are already being worked. They are not a line anybody budgets, and every unit brought into central accounting adds to them.
None of this needs a document model, because a structured invoice is already data. The pieces are verified: an API-only collection layer built with Integration Service Connector Builder, queues in Orchestrator, and Action Center tasks in Microsoft Teams.
Relevant executive roles
Budget discipline stops depending on when somebody gets round to checking; nothing is booked without a commitment reference behind it
The first ten days of the month stop being a routing exercise, and one absence no longer lengthens the queue in eighteen units
For any invoice the authority can show which unit ordered it, who confirmed the work and when
One authenticated integration per identifier, with credentials in a store and an audit log, instead of eighteen manual sign-ins
Common questions and objections
Their job is to download and to book, and that part will work. What it does not do is decide which of eighteen units an invoice belongs to when the buyer unit is blank, check it against a commitment balance and obtain a confirmation from whoever ordered the work. That is where the nine minutes go.
No. It proposes the classification carried by the commitment that authorised the spending, and the authorised person accepts or changes it. What is booked is what that person accepted, and the record keeps both.
That is the normal case, and the Ministry of Finance has confirmed the element is not obligatory. The rules do not depend on it: contract number, commitment, delivery point and your own order identifiers do the work, and where nothing matches, a named person gets it.
When this is not the right solution
- Accounting is not centralised: each unit receives and books its own invoices, and the volume per unit does not justify an integration
- Contracts and commitments are not held as data. If the register is a shelf of scans or one person's workbook, that comes first and the matching afterwards
- A small office with a few dozen invoices a month, where the download and the routing are half an hour of somebody's morning
A question for the next management meeting
An invoice arrived in KSeF this morning for one of our units: by the end of today, who will know which unit ordered it, against which contract and budget line, and where will that be written down?
Implementation approach
A scope without ambiguity, before anything is signed.
We deliver
- A read of one month of your KSeF traffic per identifier: volumes per unit, how many invoices name the unit, how many would match a commitment on the data alone
- The collection workflows per identifier, the queue structure per unit, and the matching rules with their balance, price and duplicate checks
- The classification proposal and the exception categories, each with a named owner and a deadline
- Confirmation tasks in Microsoft Teams for the heads of units, with reminders and escalation
- The write-back to the finance system, the evidence record, the per-unit dashboard and a runbook
We need from you
- KSeF access for the authority and each subordinate identifier, inside your own authorisation model
- The contract and commitment registers as they are, plus one month of history with the bookings that followed
- A process owner in central accounting, the treasurer's decision on the rules, and a contact for the finance system
- The list of units with the person who confirms for each
Stages
Discovery
One month of traffic per identifier, read for volumes, matchable share and the state of the registers
Design
Matching and classification rules, exception categories and owners, the authorisation model per unit
Build
Collection workflows, queues per unit, rules, Teams tasks, write-back and dashboard
Go-live
Parallel run on invoices already booked, then unit by unit with supervision and hypercare
Departmental. Effort follows the number of registered identifiers, whether the registers are usable as data, and how much ordering happens outside them.
Eighteen units share one KSeF inbox and one person who works out whose invoice is whose.
Send us one month of KSeF traffic for the authority and its units: counts per identifier, how many invoices carry a contract number, and the categories your team argues about. We return a matchable-share estimate and the exception taxonomy behind it.
Match one month of KSeF invoicesThe neighbouring process usually has the same problem
Your ERP sends invoices to KSeF. Who checks that each one came back with a UPO, and who fixes the ones that did not?
View solution Finance & accountingLocal tax accounts that reconcile themselvesForms are typed in twice, payments arrive without a usable reference, and the first letter a resident gets is a demand.
View solution ProcurementPublic procedures assembled from an approved clause libraryEvery new procedure starts as a copy of the last one, mistakes included.
View solutionIndustries we deliver this in most oftenPublic sector