Capital operations
Payment approval is not settlement
Understand the difference between payment approval, provider submission and settlement, and how to reconcile fees, returns and repayments without double counting.
The short answer
Approval gives permission to attempt a payment. Provider submission records that an instruction was sent. Settlement records the movement confirmed under the relevant payment arrangement. Keep those states separate and reconcile the confirmed movement with the account, ledger and obligation before treating the job as complete.
Name the state the team can rely on
A supplier asks whether an invoice has been paid. The payment screen says approved. Treasury has sent an instruction, but the provider has not confirmed its outcome. Answering yes would be premature; answering no without explanation is not very helpful either.
The operator needs the actual state, the last confirmed event and the next owner. Awaiting approval belongs with an approver. A submitted instruction with no outcome belongs with the team responsible for provider follow-up. The same green badge cannot explain both situations.
The Bank of England distinguishes the transfer process from settlement between providers and explains the role of a settlement agent. The finality of a particular movement depends on the payment system and arrangement. A successful software response alone does not establish it.
Reference: Bank of England: Payment and settlement ↗
Confirm the payment you are about to send
Before submission, show the source account, beneficiary, masked destination, currency and amount. Make fees and expected arrival visible where the provider supports them. An estimate should remain labelled as an estimate.
The decision also needs current evidence. If an account is frozen, a beneficiary changes or the available balance no longer supports the payment, ask for a new evaluation. Do not carry forward a confirmation screen that was true five minutes earlier.
Routine payments can follow a standing mandate when the executed terms and effective authority permit that route. The product should still retain the evaluation and identify which mandate version allowed the action. An exception should go to the authorised party, not simply the person who happens to be online.
Reconcile the money, including the fee
Use a worked example: an account is debited EUR 10,000, of which EUR 20 is an explicitly agreed fee and EUR 9,980 reaches the beneficiary. The ledger needs to represent both components. Whether the obligation is satisfied depends on the contract's treatment of that fee; a matching gross amount does not settle that question.
Now consider a transfer between two accounts belonging to the same project. The source debit and destination credit should offset, apart from separately recorded fees or currency effects. Counting the destination receipt as new project revenue would inflate the picture.
Reconciliation should identify the provider event, statement line, ledger entry and obligation allocation. When one link is missing, show the unmatched item and its owner. Do not manufacture a balancing entry merely to make the dashboard look clean.
Treat an unknown outcome differently from a failed payment
A timeout tells you the caller did not receive an answer. It does not tell you whether the provider accepted the instruction. Retrying as a new payment can therefore create a duplicate.
Keep a stable instruction reference and follow the provider's idempotency and status-query contract. Duplicate notifications should not create another ledger posting. Store the event identity and the processing result so the operations team can see why a replay was ignored.
A returned payment needs its own linked event. Preserve the original movement and record the return, including any fee difference. Only then prepare a linked retry with fresh beneficiary and authority checks. Deleting the first attempt removes information the team will need to explain the account statement.
Follow collections through to repayment
A receipt into a collection account should first be matched to what was expected. Then apply the agreed allocation rules, including any waterfall and lender repayment. Keep the receipt and each resulting allocation connected.
The control question is simple: can someone start with a bank statement line and explain where the whole amount went? They should be able to identify fees, reserves, distributions, debt service and any unallocated remainder without relying on a spreadsheet outside the workflow.
Test that chain with a partial receipt and a reversal before relying on it for reporting. A happy-path transfer says little about what the numbers will mean after a correction.
Questions from the review room
Can a payment be submitted but not settled?
Yes. Submission records the instruction. The provider's later status and the relevant settlement evidence establish the outcome.
Should a returned payment erase the original transaction?
No. Preserve the original event, record the linked return and reconcile both. Any retry should be a separately identifiable attempt.
