Home · Solutions · Other solutions
Solution · Other solutionsA daily rule decides which invoices earn their discount and which simply get paid on time
Discounts taken when they beat the cost of cash
A robot reads open items every morning, applies the rule the CFO and treasurer agreed, and proposes the payment run to treasury with the reasoning behind every item.
Executive summary
Your suppliers offer discounts. Your payment calendar decides whether you take them.
We build a payment-timing engine that runs every morning on top of SAP and whatever the treasury forecast currently is.
Discount windows are met because the deadline sets the payment date, not the calendar.
SAP S/4HANA payment proposal; SAP vendor master corrections; Power BI semantic model
Business problem
Treasury
Payment timing is decided by three people holding three different views and no shared rule. Accounts payable sees due dates and supplier pressure. Treasury sees the bank balance and a forecast. Procurement negotiated the terms and never told anyone a discount existed.
The vendor master is where this becomes concrete. Payment terms in it are often wrong, rarely carry the discount, and are never compared with what the invoice says. So a discount is captured when an invoice happens to be approved early, and lost by default the rest of the time. Late payments happen for the mirror reason: an invoice blocked or mislaid until after its due date, then settled with interest, a fee, or a call that costs goodwill.
The habit survives because the payment run is a routine rather than a decision. Nobody produces the one number that would change it: discounts offered this month, discounts taken, and the difference. Without that number there is nothing to put on an agenda, so the run keeps going out on Thursday and the windows keep closing on Wednesday.
How it works today
This is the shape we find in most companies with a weekly run, whatever the ERP.
- SystemThe weekly run is scheduled and accounts payable selects everything falling due before the next one
- PersonSupplier escalations are added to the list by hand, after phone calls and chasing emails
- WaitingThe treasurer sees the total on the morning of the run and defers items against the bank balance
- Risk of errorA discount is noticed only where the term happens to be correct in the vendor master
- SystemThe payment file is released; some items go early with no discount, others after their due date
- PersonLate fees and interest arrive as supplier charges and are posted without anyone asking why
- Risk of errorDiscount terms printed on the invoice are never written back to the vendor master
- PersonThe month-end report shows days payable outstanding and says nothing about discounts
Why the current process costs more than it appears
Behind every exception is an hour nobody logged.
- A 2% discount for paying twenty days early covers 5.48% of a year, so its annualised value is many times the 4.5% cost of cash assumed here. Finance teams know this in principle and lose it in practice, because nothing in the weekly routine tests it.
- Late fees are small one at a time and are booked as supplier charges rather than as a cost of the process, so nobody adds them up.
- Paying early without a discount hands the supplier free credit; paying late spends goodwill that returns as tougher terms at the next negotiation. Neither shows up in any report.
- Treasury holds a buffer sized for uncertainty instead of for a plan, because the plan arrives on the morning of the run.
- Master-data drift compounds. One payment term entered wrongly stays wrong on every invoice that vendor sends, and nobody is scheduled to look.
Cost of inaction
Not all of the first row is recoverable, and the case is stronger for saying so. The rule qualifies about nine tenths of what is offered, and moving €11,880,000 of spend twenty days earlier costs €29,300 in cash. What remains is roughly €237,600 of discounts plus the fees, paid away in fragments across nine hundred vendors, which is why no report has ever shown it.
Rates are the part that moves underneath. They changed the right answer twice in recent years and payment calendars did not move with them, so a company that leaves this alone either overpays for cash or leaves discounts unclaimed depending on the year. Meanwhile the vendor master drifts further, and procurement keeps negotiating discounts that finance does not take, which is a weak place to stand at the next renewal.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A consumer electronics distributor trading in Germany, Austria and Switzerland; about €180,000,000 a year through accounts payable to roughly 900 vendors on SAP S/4HANA, a weekly payment run, a treasury team of two.
Around 1,300 open vendor items a month reach the run. About 12% of spend, €21,600,000 a year, sits with vendors offering an early-payment discount, mostly 2% for payment within ten days against net thirty.
Accounts payable selects due items, adds escalations by hand, and the treasurer reviews the total against the bank balance on the morning of the run. Discounts are captured where the term is correct in SAP, a minority of cases.
Nobody compares the discount deadline with the run calendar, and nobody compares invoice terms with the vendor master. Six minutes of review and re-sorting per open item buys no answer to either question.
A robot reads open items, terms, deadlines, blocks and approval status every morning, compares invoice terms against the master, applies a rule the CFO and treasurer agreed, and proposes the run in Microsoft Teams with the reasoning per item. Treasury approves or adjusts; the robot prepares the SAP proposal.
Of €432,000 of discounts offered a year, €151,200 is taken today; the rule qualifies about 90%, or €388,800, an increase of €237,600. Paying €11,880,000 of spend twenty days earlier costs €29,300 at a 4.5% cost of cash, and €16,800 of late fees stop. Net modelled value is about €225,000 a year on stated shares, which is arithmetic rather than a client result.
Proposed solution
We build a payment-timing engine that runs every morning on top of SAP and whatever the treasury forecast currently is. A robot reads open vendor items with their terms, discount deadlines, blocks and approval status, then compares the terms printed on the invoice with the terms in the vendor master. Where they differ it raises a master-data task rather than quietly ignoring the discount, so the term becomes correct in SAP and stays correct for every future invoice from that vendor.
The decision itself is a written rule, not a model. Take the discount when its annualised value beats your cost of cash; otherwise pay on the due date, never later, and never earlier without a reason. When cash is short, the treasurer's priority order applies in sequence: statutory and payroll-linked items, penalties, discounts by value, strategic suppliers, everything else. Each deferral leaves the run carrying a reason, which is what makes it defensible to a supplier and to an auditor.
Treasury sees the result where it already works. The proposed run arrives as an Action Center task in Microsoft Teams with the total, the value dates, the discounts captured, the items deferred and the reasoning per exception. The treasurer approves or adjusts, the robot prepares the SAP payment proposal, and release stays exactly where it is today. Power BI carries the running picture: discounts offered, taken and lost, late fees, days payable outstanding and the cash requirement for the coming weeks.
SAP payment terms, open items and payment proposal; UiPath Orchestrator schedules, assets for the rule parameters, credential store and audit; UiPath Action Center tasks completed inside Microsoft Teams; Power BI semantic model, subscriptions and data alerts
The terms comparison and the master-data task it raises; the timing rule set with its priority order and cash constraints; the proposal assembly with reasoning per item; the Power BI model for discounts, fees, days payable outstanding and the weekly cash requirement
SAP S/4HANA open items, terms, blocks and payment-proposal preparation through UiPath SAP activities (BAPI and OData); the treasury forecast workbook through the UiPath Integration Service connector for Microsoft OneDrive & SharePoint
How the automated process works
- AutomationEach morning a robot reads open vendor items from SAP with terms, deadlines, blocks and approval status
- AutomationTerms on the invoice are compared with the vendor master; a difference raises a master-data task instead of disappearing
- SystemThe rule decides per item: pay by the discount date when the annualised discount beats the cost of cash, otherwise on the due date and never after it
- AutomationWhere cash is constrained, the treasurer's priority order is applied and every deferral is listed with its reason
- PersonThe proposal reaches treasury as an Action Center task in Microsoft Teams: total, dates, discounts captured, items deferred, reasoning per exception
- AutomationAfter approval the robot prepares the SAP payment proposal; the release itself stays with treasury under existing dual control
- AutomationPower BI updates discounts offered, taken and lost, late fees, days payable outstanding and the forward cash requirement
Human-in-the-loop model
Automation handles
- Reading open items, terms, deadlines, blocks and approval status every morning
- Comparing invoice terms with the vendor master and raising the corrections that follow
- Applying the discount-versus-cost-of-cash rule and the priority order to every item
- Assembling the proposal with its reasoning and preparing the SAP proposal after approval
People decide
- The rule itself: the cost-of-cash rate, the discount threshold and the priority order
- Approval of each run, and which items are deferred when cash is short
- Conversations with suppliers about terms, escalations and disputed fees
- Whether a master-data correction the robot raised is right, before the vendor record changes
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- SAP open vendor items and payment terms
- the vendor master
- the treasury forecast workbook on SharePoint
- supplier fee and interest notes
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- SAP S/4HANA payment proposal
- SAP vendor master corrections
- Power BI semantic model
Human touchpoints: the run proposal as an Action Center task in Microsoft Teams; master-data corrections; the quarterly rule review
Technologies used
daily reads and rule execution; schedules, assets holding the rule parameters, credential store, audit trail
Aopen items, payment terms, blocks and payment-proposal preparation
Athe run proposal as a task the treasurer completes inside Microsoft Teams, with a decision record
Awhere treasury approves, adjusts, questions a deferral and reads the cash requirement
Areads the treasury forecast workbook where it lives today
Adiscounts offered, taken and lost, late fees, days payable outstanding, forward cash requirement
Aour design, agreed with the CFO and treasurer and versioned as Orchestrator assets
CIllustrative economic model
Start by questioning the assumptions.
A per-item calculator can price desk work and nothing else, so desk work is what it prices here: 1,300 open items a month reviewed, questioned or re-sorted by hand ahead of the four weekly runs, six minutes each blended across accounts payable and treasury, at €48 an hour fully loaded for this market. The discount pool is the larger number and it is modelled from stated shares in section 05: €432,000 offered a year, €151,200 taken today, €237,600 recoverable against €29,300 of cost of cash. Nothing below was measured at a client.
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
- Discount windows are met because the deadline sets the payment date, not the calendar
- Late fees and interest stop, because nothing is paid late unless somebody deferred it deliberately
- Treasury sees the cash requirement for the coming weeks every morning, so the buffer is sized against a plan
- Payment terms in the vendor master become correct as differences surface, which fixes every future invoice from that vendor
- Free credit to suppliers ends: early payment happens where it earns something and nowhere else
- The AP manager stops defending the list and starts working the exceptions the rule surfaces
The management view
- The number that did not exist becomes a monthly report: discounts offered, captured and lost, by vendor and company code
- Days payable outstanding turns into the managed outcome of a written rule rather than an accident of the run schedule
- Changing policy when rates move is a parameter change with an approval behind it, not a project
- Every deferral leaves a reason that can be shown to a supplier, an auditor or the board
Board-level KPIs
Security and governance
Where the data sits and who can see it.
- The robot proposes and prepares. It never releases: release stays with treasury under the dual control that already exists in SAP and at the bank
- Every proposal, approval, adjustment and deferral is written to the Action Center record with user, timestamp and reason, which is what an auditor asks for when a supplier was paid late
- Rule parameters, the cost-of-cash rate and the priority order among them, are held as Orchestrator assets with change history; altering one needs the treasurer's approval, not a developer's afternoon
- The SAP service account is scoped to accounts-payable reads and proposal preparation, its secret held in an external credential store such as Azure Key Vault; no person's credentials are shared with a robot
- Bank details sit outside this process, which references vendors and open items, never account numbers; processing runs in the EU region of UiPath Automation Cloud and inside your Microsoft 365 tenant
Why now
Interest rates moved enough in recent years to change the right answer twice, and most payment calendars were set when it was different
Everything the rule needs already sits in SAP and the treasury forecast; what is missing is something that reads it every morning rather than once a week, while the model's €280,800 of discount windows closes at a steady rate
Treasury approval no longer needs a meeting or an inbox: a task completed in Microsoft Teams carries the total, the deferrals and the reasoning
Relevant executive roles
Discounts lost stop being invisible and become a reported number, with the cost of cash stated next to it
The cash requirement is known days ahead and every run arrives shaped by an agreed rule, so approval is a review rather than an investigation
The payment list stops being an argument, and the vendor master becomes correct as a by-product
Common questions and objections
The rule takes a discount only when it beats your own cost of cash, and cash constraints apply in the priority order you set. Deferrals become decisions with reasons attached rather than the default outcome of a busy Thursday.
It does, when the term is maintained in the vendor master. The discovery usually shows many are not, and the weekly run schedule ignores discount deadlines in any case.
It does not decide. It proposes with the reasoning attached, treasury approves every run as it does today, and release stays under the same dual control.
When this is not the right solution
- Few of your vendors offer discounts and late fees are rare, so the rule has almost nothing to act on; the discovery says so before anyone builds anything
- A treasury management system already optimises payment timing against the forecast and is genuinely used for every run
- Cash is so tight that every payment is deferred regardless of the discount; liquidity is the problem to fix first
A question for the next management meeting
Procurement negotiated early-payment terms worth a six-figure sum this year: can anyone here say how much of it finance actually took, and produce the evidence by Friday?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- A discovery comparison of twelve months of invoice terms against the vendor master: discounts offered, taken and lost, and the late fees paid
- The timing rule set and priority order, written down and agreed with the CFO and treasurer
- Daily reads of open items, terms, blocks and approval status, plus the master-data task where invoice and master disagree
- The proposal assembly with reasoning per item, delivered as an Action Center task in Microsoft Teams
- SAP payment-proposal preparation, tested against past runs before it touches a live one
- The Power BI model for discounts, fees, days payable outstanding and the weekly cash requirement
- Shadow running, then handover with a runbook and a standing rule review
We need from you
- Twelve months of paid items with payment terms, discount terms and actual payment dates
- A treasurer who owns the rule and a named AP process owner for master-data corrections
- An SAP service account for accounts-payable reads and proposal preparation, in test and production
- The treasury forecast in whatever form it exists today, the Excel workbook included
Stages
Discovery
Compare invoice terms with the vendor master, quantify discounts offered, taken and lost, count the late fees
Rule design
Cost-of-cash rate, discount threshold, priority order under a cash constraint, allowed deferral reasons
Build
Daily reads and comparisons, proposal assembly, SAP preparation, Teams task, dashboard
Shadow run
The engine proposes, treasury compares it with what it would have done, the rule is adjusted
Go-live
The proposal becomes the working list, approved in Teams, supervised over the first runs
Rate review
A standing look at the cost-of-cash rate, the priority order and the vendors whose terms drift
Quick win. Effort is driven by how many company codes and currencies the run covers, how reliable the payment terms in the vendor master are, and whether the treasury forecast exists in a form a robot can read.
A 2% discount that expired on Wednesday is worth more than the week it took to notice.
Send us twelve months of paid items with payment terms and payment dates. We return the discounts offered, taken and lost, and the late fees, as a baseline you can argue with.
Get the discount baselineThe neighbouring process usually has the same problem
Stop building the daily cash number by hand from four bank portals; it arrives late and nobody quite trusts it.
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 solutionsPrice and quantity mismatches resolved the day they appearA variance released under payment-run pressure becomes next quarter's price, and nobody negotiated it.
View solution Other solutionsSupplier statements reconciled the day they arriveYour suppliers tell you every month what they think you owe. Most of those letters go unread.
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