Home · Solutions · Other solutions
Solution · Other solutionsOne operating pattern for four platforms, with each country's rules held as a rule set
E‑invoices validated and submitted, mandates absorbed
Outbound invoices are validated against each country's rules before submission, platform status is written back to SAP continuously, and every rejection reaches the person who owns its cause.
Executive summary
An invoice the platform rejects has not been issued, and nobody in finance reads XML for a living.
We build the operating layer around the transport you already bought.
Invoices are legally issued on the day they are billed, because the errors a platform would reject are caught before it ever sees them.
SAP S/4HANA billing and accounts payable; the access point or ERP add-on; SharePoint evidence archive
Business problem
E‑invoicing
E‑invoicing mandates are a moving target that finance is expected to hit with tools built for a static one. Poland's KSeF, Italy's exchange system, Belgium's PEPPOL obligation, Germany's structured formats and the French reception rules each define what a valid invoice is, how it is submitted, what comes back and at what moment the invoice counts as issued. None of that is optional, and none of it stays still.
The access point or the ERP add-on solves transport, which turns out to be the smaller half of the work. Transport does not repair a customer record with no tax identifier, a product with a unit code the schema will not accept, or a VAT rate a country's rules reject. Those failures arrive as codes, are noticed by whoever remembered to open the portal, and are fixed by re-keying. Meanwhile platform status and ERP status drift apart, so the VAT return is reconciled by hand at month end, and inbound invoices sit on a platform until somebody downloads them.
The pattern survives because every mandate is run as a project. The project ends, the team disperses, and each country's rules end up in one person's head. The next country is announced, another project starts, and the tax director is asked how many people this one will need.
How it works today
- SystemThe billing run creates invoices in SAP and the add-on converts and submits them
- PersonFinance opens each country's platform portal the next morning to look for rejections
- PersonRejected invoices are exported and examined by whoever can read the schema
- PersonMaster data or the invoice is corrected, the invoice re-issued and resubmitted
- Risk of errorThe customer asks why the invoice arrived late, or twice, and the revenue date has moved
- PersonPlatform statuses are copied into a spreadsheet for the VAT reconciliation
- WaitingInbound structured invoices are downloaded weekly and forwarded to accounts payable
Why the current process costs more than it appears
The cost grows where nobody is looking.
- A rejected outbound invoice is not a technical error but revenue not recognised, VAT not reported in the right period and a customer whose payment clock has not started.
- Batches of rejections at month end move numbers between periods, and once that happens twice the auditors treat it as a control question rather than a data question.
- Inbound invoices left sitting on a platform lose payment-term days, and in some regimes they eat into the period in which the tax can be deducted.
- Nobody was hired for the work this creates: a controller who reads XML, an analyst maintaining a mapping per country, a tax manager reconciling in a spreadsheet, none of it documented.
Cost of inaction
The mandates keep arriving whether or not anyone is ready, and each one handled as a project ends the same way: the project closes, the knowledge leaves with it, and the rules survive only in somebody's memory. Rejections rise with volume and with every new customer or product whose master data was never tested against a schema, and correction batches at month end move revenue and VAT between periods often enough to become an audit topic rather than an inconvenience.
The rest is quieter. Inbound invoices wait on platforms while payment terms run, group exposure settles at the level of the country receiving least attention, and within twelve months the question put to the tax director is answered with a number that is then paid every year.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A packaging manufacturer with entities in Poland, Italy, Belgium and Germany on a single SAP S/4HANA system, using an access-point provider and an ERP add-on for transport.
About 3,000 customer invoices issued and about 6,000 supplier invoices received each month through national platforms and PEPPOL, so roughly 9,000 structured documents across four countries.
Two controllers open the portals each morning, export what was rejected, diagnose it and resubmit. Platform status is reconciled to SAP monthly in a spreadsheet for the VAT return.
Rejections run at a few percent and are mostly master-data and tax-code issues, but each is diagnosed from a code by a person who happens to know the schema, and that knowledge is nowhere written down.
Every outbound invoice is validated against a versioned country rule set before it reaches the platform, submission and status polling are automated, statuses are written back to SAP as they arrive, and rejections become tasks in Microsoft Teams for whoever owns the cause.
In the modelled case three quarters of today's rejections never happen, the remaining ones arrive explained rather than encoded, the VAT reconciliation is continuous instead of monthly, and France becomes a rule set with a test run. Every figure below is modelled on stated assumptions rather than measured at a client.
Proposed solution
We build the operating layer around the transport you already bought. Before anything is submitted, a robot validates each outbound invoice against a rule set for its country: mandatory fields, tax identifiers, unit and tax category codes, rounding, permitted VAT rates, attachments and schema version. What fails is corrected in SAP where the fix is mechanical, and otherwise becomes a task for master data, billing or tax with the failed rule written in plain language. The invoice reaches the platform only when it will be accepted.
The robot then triggers submission through the add-on or access point, polls the platform for status and writes the result back to SAP, so every invoice carries its platform identifier and its acceptance timestamp on the document itself rather than in somebody's export. Rejections that still occur become tasks in Microsoft Teams naming the rule that failed and the fix that usually resolves it. Inbound structured invoices are collected from each platform daily, validated, matched to the vendor master and handed to the accounts-payable pipeline with the structured data intact rather than flattened into a PDF.
What decides whether this survives the next mandate is where the country rules live. They are versioned decision tables in UiPath Maestro and configuration in UiPath Orchestrator assets, released with test evidence like any other change, so a schema update is a rule change and a test run rather than a project. A continuous reconciliation compares the platform's record with SAP by entity and period and lists the differences, which is the evidence the VAT return needs. No AI is used anywhere in this flow: compliance logic a tax authority may question has to be deterministic and explainable, line by line.
UiPath Maestro decision tables for the country rule sets; UiPath Orchestrator assets, queues, time triggers, credential store and audit log; UiPath Action Center tasks with SLAs, completed in Microsoft Teams; SAP billing documents and document flow; your existing access point or ERP add-on for transport
The country rule sets and their test cases; pre-validation and the plain-language explanation of each failure; submission orchestration and status polling; status write-back and the continuous reconciliation; inbound collection and validation; the rejection task design and the compliance dashboard
Platform and access-point APIs through UiPath Integration Service Connector Builder; SAP billing reads and status writes through the SAP BAPI and OData connectors; alerts and tasks through the Microsoft Teams connector
How the automated process works
- AutomationAfter the billing run the robot reads the new invoices and validates each against its country rule set
- PersonWhat fails goes to master data, billing or tax as a task in Teams, naming the rule and the usual fix
- AutomationInvoices that pass are submitted through the access point or the ERP add-on
- AutomationThe robot polls each platform for status and writes the identifier, timestamp and result back to SAP
- PersonA rejection that still occurs becomes a task with the error explained, and the corrected invoice is resubmitted
- AutomationInbound structured invoices are collected daily from every platform, validated and handed to the AP pipeline
- AutomationPlatform and SAP status are reconciled continuously by entity and period, with the differences listed
Human-in-the-loop model
Automation handles
- Pre-validating every outbound invoice against its country's rule set before submission
- Triggering submission, polling platform status and writing identifiers and timestamps back to SAP
- Collecting, validating and handing over inbound structured invoices every day
- Reconciling the platform's record with SAP by entity and period, and listing what differs
People decide
- The master data and tax treatments behind rejections, which is where the causes actually are
- What to do with an invoice the rules cannot classify, rather than forcing it through
- Whether a rule-set change is correct, because tax approves every release
- The VAT return itself, with the reconciliation attached as its evidence
Before and after
Systems and integrations
Every entry can be checked in vendor documentation. The evidence class is stated next to each one.
Inputs
- SAP billing documents
- inbound structured invoices from national platforms and PEPPOL
- platform status responses
- rule-change requests from country tax owners in Microsoft Forms
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Maestro
- UiPath Action Center
- UiPath Integration Service
Target systems
- SAP S/4HANA billing and accounts payable
- the access point or ERP add-on
- SharePoint evidence archive
- Power BI
Human touchpoints: correction and rejection tasks in Microsoft Teams; the tax owner's approval of a rule release; the monthly VAT return with its reconciliation
Technologies used
validation, submission, polling and write-back, with per-country assets, queues, retries and the credential store
Aeach country's rules as versioned, testable decisions rather than logic buried in a workflow
Acorrection and rejection tasks with SLAs, routed to master data, billing or tax
Aplatform and access-point APIs; task and alert delivery
Abilling documents read; platform identifiers, timestamps and statuses written back
Acompliance position per country and rejection causes by master-data field, customer and product
AIllustrative economic model
The arithmetic is open, so it can be argued with.
Only two activities are priced here, and neither of them is transport: diagnosing rejections and checking portals. Today 360 rejections a month at 25 minutes each is 150 hours, and 45 minutes of checks and reconciliation per country per working day, over four countries and 22 days, is 66 more. In the target state pre-validation prevents three quarters of the rejections and the remaining 90 take 20 minutes each with the failure explained, which is 30 hours. The 186 hours between them, spread across all 9,000 structured invoices, are the 1.24 released minutes below. €37 an hour is an assumed fully loaded controller cost, and the effort of the next mandate is not in the model because it depends on the country.
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
- Invoices are legally issued on the day they are billed, because the errors a platform would reject are caught before it ever sees them
- The VAT return reconciles because platform status reaches SAP as it happens rather than being copied into a spreadsheet once a month
- Rejections are fixed by the owner of the cause with the failure explained, instead of by whichever colleague can still read a schema
- Inbound invoices reach accounts payable the day they land on a platform, which protects payment terms and deduction periods
- The next mandate is a rule set and a test run rather than a project, a mapping rebuild and a request for another head
The management view
- The tax director has a current compliance position per country: issued, accepted, rejected, pending and reconciled, with the differences named
- Rejection statistics by cause point at the master data and products worth fixing, which is where the remaining effort should go
- The CIO gets one operating pattern across countries, with the schema knowledge held in a versioned rule set instead of in a person who may resign in May
Board-level KPIs
Security and governance
An auditor should be able to reconstruct every decision.
- Platform credentials and certificates are held in Azure Key Vault through the Orchestrator credential store, never in a workflow or a spreadsheet, and the robot's SAP account can read billing documents and write status, nothing else
- Every submission, status response and rejection is logged per invoice in Orchestrator and written back to SAP, which is the submission history a tax authority expects to be shown
- Rule sets are versioned and released with test evidence through UiPath Solutions Management, and a rule change does not reach production without the country's tax owner approving it
- Invoice data stays in the EU: UiPath Automation Cloud in its EU region and your Microsoft 365 tenant within the EU Data Boundary, with the robot running on your own infrastructure where a platform requires locally held certificates; evidence in SharePoint carries Microsoft Purview retention labels aligned to tax retention periods
Why now
Mandates are now the European default rather than the exception: the VAT in the Digital Age package adopted by the Council on 11 March 2025 commits the EU to fully digital VAT reporting for cross-border business-to-business transactions by 2030, so the national pace will not slow
Most groups have already bought transport, an access point or an add-on, and have discovered that transport was the smaller half; the validation, reconciliation and rejection handling around it are deterministic, repetitive and country-specific, which is exactly what robots are for
Building the layer once returns the modelled €6,882 a month in capacity and removes the rebuild from every future mandate, which is the part that grows with each country added
Relevant executive roles
Revenue and VAT land in the period they belong to, and the next mandate arrives without a headcount request attached
A reconciled compliance position per country, with rejections owned, explained and counted by cause
One operating pattern across countries, with rules versioned and tested rather than embedded in a person or a mapping nobody documented
Common questions and objections
Providers handle transport and format conversion, and they do it well. The master data, tax treatments, rejections and reconciliation stay with you, and that is where the hours in the model above are spent.
SAP's document and reporting compliance capabilities cover much of the transport and the formats. The validation before submission, the ownership of a rejection and the continuous reconciliation are process work around whatever you use, not a replacement for it.
The transport differs and the rules differ. The pattern of validate, submit, poll, write back, reconcile and fix does not, which is why the differences belong in a rule set rather than a new project each time.
When this is not the right solution
- A single-country business with modest volumes whose provider already reports rejections into the ERP with enough detail to act on
- A group midway through an ERP replacement that will bring its own compliance layer, where this belongs in the new system's design rather than beside the old one
- An organisation with no tax owner per country, since robots can route a rejection but cannot decide a tax treatment
A question for the next management meeting
Our tax director has been asked how many people the next mandate will need: is the honest answer a rule set and a test run, or another project and another hire?
Implementation approach
Delivery runs in stages, so it can be stopped at any point.
We deliver
- An analysis of one month of platform logs and rejections per country with the causes ranked, many of them master-data fixes you can make immediately
- The country rule sets with their test cases, written with tax and owned by tax
- Pre-validation with plain-language explanations, submission orchestration, status polling and write-back to SAP
- Continuous platform-to-SAP reconciliation, inbound collection and validation, and the rejection tasks in Teams
- The compliance dashboard, per-country testing, documentation, training and rule updates when a platform changes
We need from you
- One month of rejection logs and platform status exports per country
- A service account in SAP limited to billing reads and status writes, in test and production
- Platform and access-point credentials, held in your own secret store rather than sent to us
- A named tax owner per country who can approve a rule set and decide a tax treatment
Stages
Discovery
One month of logs per country; rule sets drafted and rejection causes ranked
Design
Validation rules, correction routing, status model, reconciliation logic and release process
Build and pilot
One country end to end, outbound and inbound, with pre-validation in report mode before it blocks
Scale and run
One country at a time, each with a rule set and a test run, then continuous reconciliation and rule maintenance
Departmental. Effort follows the number of countries in scope, whether each platform offers a status interface or only a portal, and how far the master data behind today's rejections has to be cleaned before a rule set can block anything.
Forty-one of yesterday's invoices were never legally issued.
Tell us which countries you invoice in and send one month of rejection logs from the platforms. We come back with the causes ranked and the rule set that would have caught them before submission.
Review one month of rejection logsThe 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 & accountingInvoices from KSeF booked to the right budget lineA structured invoice states the amount. It does not state which unit ordered the work.
View solution Other solutionsInvoices read, coded and routed; people see only exceptionsSomebody still types the PDF into the ERP, guesses the cost centre and chases the approver.
View solution Other solutionsFCPA, Sunshine Act and VAT evidence collected continuouslyFour annual deadlines, one dataset, and none of it rebuilt from sixty spreadsheets.
View solution Case studyInvoice disputes without escalationA disputed invoice is not one task — it is an investigation: order, delivery, contract, correspondence.
View case study Case studyAutomated P2P query handlingInvoice copies, statuses and statements delivered instantly — around the clock.
View case studyIndustries we deliver this in most oftenManufacturing & industryRetail & e‑commerceServices & ITShared services