Financing in practice
Payment approval workflows: send the right exceptions to lenders
Design a payment approval workflow that distinguishes routine payments from lender exceptions, checks current evidence and prevents stale approvals being reused.
A payment approval workflow determines whether a proposed payment can proceed, who must approve it and what evidence they need. In a financed project, the answer depends on more than the amount. The account, facility terms, beneficiary, purpose and current restrictions can all affect the route.
Sending every invoice to a lender creates work without necessarily improving the decision. Sending none leaves the lender's controls disconnected from the money. A useful design defines standing authority for routine payments and a separate route for exceptions.
The model below is a suggested operating design. It is not a standard bank mandate or a statement of what any lender has agreed.
Agree the mandate before automating the payment
A standing mandate should identify the accounts, currencies, permitted payment categories and beneficiaries it covers. Record the approvers, individual and aggregate limits, evidence requirements, effective dates and withdrawal conditions.
An amount limit alone is insufficient. A small transfer to a newly changed beneficiary account may need more scrutiny than a larger recurring payment to an established supplier. A reserve account may prohibit an otherwise ordinary operating expense.
Approval products already support role-specific queues. Modern Treasury documents queues filtered by the reviewer's role and sequential review when several rules apply. That is a useful reference for interface behaviour, not evidence that its default rules implement your credit agreement. Modern Treasury: Managing your Approval Queue
Write the boundaries without overlap
Here is a fictional EUR mandate. Assume eligible beneficiaries, permitted categories, current evidence and an unrestricted account. Every other control must also pass.
| Individual payment | Route under the assumed mandate |
|---|---|
| Up to and including EUR 10,000 | Routine standing authority |
| Above EUR 10,000 up to and including EUR 50,000 | Producer finance-controller approval |
| Above EUR 50,000 | Authorised lender review |
Now add a EUR 25,000 daily cap on routine payments. Three eligible requests for EUR 9,000 each total EUR 27,000. After two have reserved EUR 18,000 of capacity, the third cannot use the routine route. It needs the mandate's specified exception process; the software must not invent a higher authority or allow splitting to bypass the cap.
Define what consumes the cap, when reservations expire and how confirmed failures release them. Otherwise two simultaneous requests can each see the same remaining allowance and both pass.
Give the reviewer a decision, not a document hunt
The review should show the source account, beneficiary and masked destination, amount, currency, purpose and expected balance after applicable reservations and known fees. Where a balance or fee is unavailable, say so and explain its effect on submission.
Beside that, state why approval is needed. "Above the routine limit" is useful. "Policy failed" is not enough. Show the relevant threshold, evidence age, initiator and response deadline. Only display actions the current assignment can perform.
Preserve the difference between legal review and release authority. Counsel may resolve an issue with a document or beneficiary arrangement without becoming the person authorised to release funds. The lender's consent belongs to its own authorised workflow.
Freeze the proposal, then recheck before release
Approval should refer to a specific payment proposal and the evidence it relied on. If the beneficiary changes, the approval should not silently follow the new destination. If the account is frozen, an earlier approval should not override the restriction.
We recommend a fresh control check before the payment reaches the provider. Material changes should stop the old route and explain what requires another review. Retain the prior approval so the operator can see what was approved, by whom and why it no longer applies.
A request timeout needs separate handling. Modern Treasury's API documentation explains how an idempotency key can prevent duplicate payment-order creation within its documented scope. The application still needs to retain the original request and reconcile its eventual outcome. Modern Treasury: Idempotent Requests
Test the exceptions before the happy path
Ask the supplier to demonstrate an expired mandate, an altered beneficiary, two simultaneous requests near a daily limit and revocation of an approver's authority while the review is open. Confirm that the initiator cannot acquire a second identity or role selection to bypass required separation of duties.
Measure how many legitimate routine payments reach completion without unnecessary review, but also count missed exceptions and incorrectly blocked payments. Reducing approval clicks is not a useful success measure if it weakens the control.
Questions treasury teams ask
Does standing authority remove human responsibility?
No. Authorised people establish and approve its scope. Routine processing then follows that scope, subject to fresh checks and revocation.
Is lender approval enough to mark a payment complete?
No. Provider processing and settlement remain separate. See our loan-servicing reconciliation guide for the connection between cash movements and obligations.
Can an AI agent choose the approval route?
An agent can prepare evidence and flag inconsistencies. The enforceable route should come from approved rules, current authority and account state, with a reproducible result.
Test one mandate against your actual operating needs
Request a FINKI demonstration focused on a routine payment and a lender exception. Ask to see the policy, the evidence and the response to a changed account restriction. FINKI's proposed value is fewer avoidable handoffs while preserving the institution's control; that needs to be demonstrated in your process.