Home · Solutions · Management & planning
Solution · Management & planningFourteen days of DSO above target, and four departments each blaming a different step
Order-to-cash process mining: where the cash gets stuck
Process mining on your order-to-cash event log measures how many DSO days each step, customer segment and rework loop costs, and turns the causes into a monthly cash review with owners.
Executive summary
DSO sits above target and every department has a theory. Measure how many days each step actually costs.
Mientha builds an order-to-cash process app on UiPath Process Mining from events your systems already write.
The days above target split between credit release, delivery confirmation, billing, disputes and payment behaviour.
the Power BI review pack; the Automation Hub pipeline; no writes to SAP or the CRM
Business problem
Process intelligence
Order-to-cash is a relay: an order is taken, checked against a credit limit, picked, shipped, confirmed, invoiced, sometimes disputed, eventually paid. Every handover is another team's system and another team's queue, and the clock runs through all of them. The board sees one number at the end, an average of averages that hides the customer who pays on day 30 and the segment that pays on day 95.
Each function does measure something, which is part of the problem. Credit reports how fast it releases blocked orders, billing reports counts and a run calendar, collections reports overdue buckets. Nobody measures the order end to end, so four measurements never add up to fourteen days. The quarterly DSO bridge is rebuilt by hand from an open-items export, and the meeting argues about whose extract is right instead of which step to fix.
Scale makes this worse: every new country or distribution centre adds variants, and rework loops multiply quietly. A credit block set, released and set again on the same customer within a fortnight; an invoice reissued over a wrong price condition; a dispute reopened after a credit note. None is an incident, none is counted, each carries days.
How it works today
This is the shape we usually find.
- SystemAn order arrives by EDI or from the order desk and stops on a credit block: the customer's exposure is over the limit
- WaitingThe block sits in the credit analyst's queue, typically half a day to two days, longer if it lands on a Friday
- PersonThe analyst checks open items in FBL5N, calls the account owner and releases the order by hand; the customer blocks again next week
- WaitingGoods leave the depot, the delivery is confirmed a day or two later, and billing has nothing to invoice
- SystemBilling issues the invoice; some are reissued over a wrong price condition, ship-to or order reference
- Risk of errorRepeat blocks, reissued invoices and reopened disputes count as ordinary work, so none becomes a number
- PersonOnce a quarter an analyst exports open items into Excel and builds a DSO bridge the management meeting then disputes
Why the current process costs more than it appears
Behind every exception is an hour nobody logged.
- Days are money at a price the group already knows. Fourteen days on a €480m revenue base is a pool of receivables financed all year, and it sits in no department's budget because it belongs to four.
- Rework is invisible precisely because it looks like work. A block released twice, an invoice reissued, a dispute reopened: each is reasonable, and together they carry more days than anyone guesses.
- Collections works the only list it can see, the overdue one. Days lost before the invoice existed never reach the people held responsible for DSO.
Cost of inaction
DSO is a lagging number, which is why nothing about it feels urgent in any particular month. Sixty-two becomes sixty-three and comes back, the treasury report absorbs it, and the pool is financed quietly at a price nobody argues about because it never arrives as an invoice.
What compounds is the base the gap applies to. Every new country and customer group joins the same relay, so a gap measured in days grows with revenue on its own, without a single step getting worse. Each unmeasured year is also another year of improvement budget spent on whichever director argued best.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
Distribution group, €480m of revenue, three distribution centres, about 4,000 active B2B customers in five countries; SAP S/4HANA for sales and finance, Microsoft Dynamics 365 Sales as the CRM, Microsoft 365 E3; order desk and collections in a shared-services centre.
Roughly 240,000 sales orders and 310,000 invoices a year; DSO 62 days against a board target of 48; about 6% of orders stop on a credit block and about 3% of invoices are reissued.
Each function measures its own leg with its own clock, and the DSO bridge is rebuilt in Excel once a quarter from an open-items export.
No single timeline per order, so the fourteen days above target cannot be attributed to credit release, delivery confirmation, billing latency, disputes or payment behaviour, and no action can be sized before it is taken.
UiPath Process Mining on the order-to-cash event log with the Order-to-Cash app template; conformance checking against the target flow; days measured per step, segment and rework loop; a monthly cash review in Microsoft Teams with a Power BI pack, feeding the credit, billing and collections teams and an automation pipeline.
In the modelled case each of the fourteen days carries a step, an owner and a euro value, so the discussion moves from fault to arithmetic. The illustrative pool behind them is €18.4m of receivables, financed at an assumed 5.5% for about €1,012,000 a year. These are a model on stated assumptions.
Proposed solution
Mientha builds an order-to-cash process app on UiPath Process Mining from events your systems already write. The log is assembled from SAP sales, delivery, billing, credit and receivables documents, including change documents, and joined to CRM attributes: segment, account owner, and disputes where they are not kept in SAP. Extraction runs through Theobald Xtract Universal or CData Sync, scheduled, incremental and read-only, and is reconciled against your own totals before anyone sees a dashboard. The Order-to-Cash app template supplies the structure: Summary, End-to-end process, Event Analysis and Customers dashboards, throughput metrics, tags and due dates.
What makes it an executive instrument is the conversion of time into cash. Conformance checking compares every case against the target flow you agree, and we tag the deviations that belong here: a credit block released twice for the same customer, an invoice reissued, a delivery confirmed after dispatch, a dispute reopened, a term overridden at order entry. Each step and deviation carries a duration, which we express as DSO days and, at daily revenue, in euros. That conversion is our design on the template's metrics, as is the touchless order rate, defined once from entry to cash application.
Findings land where the decision is taken. A Teams channel carries the monthly cash review with the Power BI pack as a tab, and a data alert reaches the review owner in the Teams activity feed when the billing lag or the touchless rate crosses its threshold. A recurring cause becomes a policy change or an automation candidate, sent to UiPath Automation Hub with its volume and days; UiPath Insights later shows what it delivered. No language model takes part, and every figure traces back to SAP document numbers. Where the Order-to-Cash control tower described elsewhere on this site executes the exceptions, this one tells you which are worth executing differently.
UiPath Process Mining Order-to-Cash app template (dashboards, tags, due dates, automation potential); conformance checking against a target process; incremental loading through Theobald Xtract Universal or CData Sync; automation ideas sent to UiPath Automation Hub; Power BI as a Microsoft Teams tab with data alerts; UiPath Insights dashboards
The extraction scope and the event log; the target process and its conformance rules; the deviation tags above; the days-to-cash conversion and the segmentation; the Power BI review pack, its thresholds and the review routine
The CRM join carrying account owner, segment and the dispute record where disputes sit outside SAP; nothing on the SAP side
How the automated process works
- AutomationA scheduled incremental load reads new and changed sales, delivery, billing, credit and clearing documents from SAP and account attributes from the CRM
- AutomationThe event log is rebuilt per order item and per invoice, from order entry to cash application, and every case is checked against the target process
- AutomationDeviation tags are applied identically across countries and months: repeat blocks, reissued invoices, late confirmations, reopened disputes, overridden terms
- AutomationStep durations become DSO days and, at daily revenue, euros, split by customer segment, country and account owner
- AutomationThe review pack refreshes, and a data alert reaches the review owner in the Teams activity feed when a threshold is crossed
- PersonCredit, billing, collections and sales meet monthly on the days bridge and decide: change a term, correct a price condition, re-segment a dunning strategy, fix a depot's practice
- SystemEach action is recorded against its cause with an owner and a date, candidates go to Automation Hub with their volume, and the next cycle shows whether the days moved
Human-in-the-loop model
Automation handles
- Extraction, event-log construction and conformance checking for every order, delivery, invoice and payment
- The deviation tags and the conversion of durations into days and euros, applied the same way in every country and month
- Refreshing the review pack, raising threshold alerts and passing candidates to Automation Hub with their measured volume
People decide
- Which deviations are acceptable: a strategic account released above its limit, a seasonal term, a depot that confirms next morning
- What the target process is and where the thresholds sit; that definition belongs to finance and sales
- The commercial actions: payment terms, credit limits, dunning strategies, price conditions
- Whether a customer's payment behaviour is a process defect or a negotiation for the account owner
Before and after
Systems and integrations
We do not add technology to make an architecture look serious. Every element below has a specific job in this process.
Inputs
- SAP sales, delivery, billing, credit and receivables tables with change documents
- customer master and payment terms
- account owner, segment and dispute records from the CRM
Automation layer
- UiPath Process Mining with the Order-to-Cash app template
- Theobald Xtract Universal or CData Sync
- UiPath Automation Hub
- UiPath Insights
Target systems
- the Power BI review pack
- the Automation Hub pipeline
- no writes to SAP or the CRM
Human touchpoints: the monthly cash review in Microsoft Teams; the Power BI tab and dashboard links; threshold alerts in the Teams activity feed
Technologies used
event log, conformance against the target process, throughput per step, tag and customer
Ascheduled, incremental, read-only extraction from the SAP tables
Arecurring causes become assessed candidates with their measured volume and days
Awhat the automations that follow the review actually deliver
Athe cash review pack as a Teams tab, with data alerts on thresholds
Athe review channel holding the pack, the alerts and the decisions
Aorder, delivery, billing, credit and clearing events
Athe CRM here: segment, account owner and disputes kept outside SAP
AIllustrative economic model
What it is worth, with the arithmetic shown.
One number does the work here, and it is a day of sales. €480m of revenue divided by 365 means the group invoices about €1.32m a day, so each day of DSO above target is that much cash held in receivables rather than in the bank. The 5.5% is an assumed all-in cost of capital, not a quoted rate, and the €18.4m is a one-off cash release rather than a yearly saving; what recurs is the carrying cost in the last row. Nothing was measured at a client.
Business benefits
- The days above target split between credit release, delivery confirmation, billing, disputes and payment behaviour, each with a euro value at daily revenue
- Rework loops are counted for the first time: repeat credit blocks per customer, reissued invoices, disputes reopened after a credit note
- The customers behind the average become visible, so a term, a limit or a dunning strategy changes for the segment that really generates the days
- Credit, billing, collections and sales stop arguing from four extracts and start from one timeline traceable to SAP documents
The management view
- Cash conversion stops being a monthly outcome and becomes a list of causes with values, owners and due dates
- Finance, sales and the shared-services centre plan from the same timeline, refreshed automatically and reconciled against the ledger
- Every initiative starts from a measured baseline, so its effect shows in the operating dashboard, not in a project report
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- Nothing here writes to SAP or the CRM. One dedicated read-only service account, limited to the tables in scope, is the only credential involved
- Process data is held in the UiPath Automation Cloud EU region; the review pack and its alerts stay in your Microsoft 365 tenant, with access by Microsoft Entra ID group
- Customer names and payment behaviour are commercial data: named views go to the finance and sales roles that need them, while the wider review works on aggregates
- Identifiers of the people who release blocks or cancel invoices are pseudonymised unless finance, HR and employee representatives agree otherwise; the target process, tags and thresholds are versioned and need sign-off to change
Why now
Receivables are financed at whatever your group pays for money, a price set by lenders rather than by the process; the modelled €1,012,000 a year is what the fourteen days cost before anyone recovers a single one
A DSO target missed for two years reappears as a headcount request in collections. A measured split settles whether the days are made there or before the invoice exists
The app template, incremental SAP extraction and Power BI inside a Teams channel are standard, documented components; this is a configuration and a review routine, not a data-warehouse programme
Relevant executive roles
The DSO gap stops being an outcome and becomes causes with values, owners and a monthly bridge that survives questioning
Credit, billing and collections work from one timeline, and effort goes to the largest measured cause, not the loudest complaint
Payment behaviour by segment and account owner turns a finance grievance into a commercial conversation backed by evidence
Read-only extraction from standard tables, no change to SAP or the CRM, one process app instead of quarterly Excel bridges
Common questions and objections
DSO tells you the result, not where it is made. The same 62 days can be four days of billing latency and ten of payment behaviour, or the reverse, and the two need opposite decisions. Process mining splits it by step, customer and cause.
Those are the findings, not obstacles to them. The first load shows which depots confirm late and how many disputes sit outside the ERP; where a dispute leaves no event at all, we say so rather than model around it.
The control tower executes: blocked orders, disputes and limit breaches run through one flow with approvals in Teams. This measures where the days are made, so you know which exceptions are worth routing that way, and whether the number moved.
When this is not the right solution
- Order-to-cash runs largely outside the ERP: orders by phone, invoicing in a separate tool with no link to deliveries. There is no timeline to mine, and getting the process into one system comes first
- The gap is already understood and agreed. If everyone accepts where the days sit and the case is written, spend the money on fixing it rather than measuring it twice
- You want a picture of the desk work behind the process, or one look across several processes. That is the four-week process X-ray with KYP.ai, which usually comes first
A question for the next management meeting
Our DSO is fourteen days above the target we set ourselves: which step owns how many of those days, and what does each day cost us at our own cost of capital?
Implementation approach
What we deliver, and what we need from you to start.
We deliver
- A data-availability check on your sales, delivery, billing, credit and receivables tables and on the CRM attributes carrying segment and owner
- The target process agreed with finance, sales and the shared-services centre, and the conformance rules behind it
- The event log and the scheduled load, reconciled against your own totals before anyone reads a number
- The app template configured with your tags, due dates, segmentation and days-to-cash conversion, and the Power BI pack with its thresholds
- The first three monthly cash reviews facilitated by us, with the first candidates assessed in Automation Hub
We need from you
- Read access to the SAP tables in scope, or the extraction layer you already operate
- One owner in finance and one in the shared-services centre who will chair the monthly review
- Your DSO target, payment terms by segment, the dispute record wherever it is kept, and the credit release rules as applied
Stages
Discovery
Target process, deviation tags, customer segmentation, DSO definition, data availability
Data and configuration
Extraction, event log, reconciliation against the ledger, tags, KPIs, review pack, thresholds
Validation
First results read with credit, billing and collections; definitions and thresholds corrected
Review routine
Three facilitated monthly reviews, actions with owners, first candidates in Automation Hub
Continuous monitoring
Scheduled loads, threshold alerts, a target per cause, further company codes
Departmental. Effort follows the number of company codes and sales organisations, whether disputes live in the ERP or only in mailboxes, and how consistently depots post delivery confirmations.
Your DSO gap has four owners, which means it has none.
Send us your monthly DSO for the last year, your sales-order and invoice counts, and the SAP release you run. You get back a data-availability check and a written view of which steps your event data can already price.
Split your DSO gap into daysThe neighbouring process usually has the same problem
Nobody knows what share of purchases bypass contracts and POs, or how often an invoice is touched. Measure it monthly.
View solution Finance & accountingIntercompany balances that agree before the group closeYour entities disagree about what they owe each other, and the consolidation waits for an email.
View solution Customer serviceService levels reported before the customer disputes themMonthly SLA reports are rebuilt in Excel from ticket exports, and the customer finds the service credits first.
View solution Management & planningThe management pack in Power BI, not fourteen Excel filesThe board pack should not depend on which analyst merged which spreadsheet on which day.
View solution Case studyOrder-to-Cash control towerEvery blocked order, disputed invoice and breached credit limit flows into one process: an agent diagnoses, a robot executes, a human approves with one decision on Teams.
View case study Case studyThe receivables agent: cash comes back soonerIt prioritises, writes, escalates and proposes decisions — you just approve.
View case studyIndustries we deliver this in most oftenManufacturing & industryRetail & e‑commerceServices & IT