THE FUTURE OF ACCOUNTS PAYABLE | PART 4 From Invoice to Payment: Open Banking and the New Payment Infrastructure Pay by Bank, A2A, real-time payments
In Part 3, I looked at how e-invoicing and Peppol are changing the invoice from something Accounts Payable has to read and interpret into structured, machine-readable data. But that raises another question.
What happens after the invoice has been validated and approved?
For many organisations, the answer still involves a surprisingly fragmented journey.
AP processes the invoice.
The ERP records the liability.
A payment proposal is created.
Treasury manages liquidity.
A payment file is generated.
The bank executes the payment.
And sometime later, Finance reconciles what actually happened.
Each stage may be digitised. But that does not necessarily mean they are connected.
And I believe that is where another significant change in Invoice-to-Pay is beginning.
Payment infrastructure is changing
Open Banking, Pay by Bank, account-to-account payments and real-time payment infrastructure are creating new ways for money to move between businesses. Pay by Bank is a good example. Rather than relying on a card network, the payer can authorise a payment directly from their bank account using Open Banking infrastructure.
For Finance teams, the significance goes beyond another payment method. It creates the opportunity to connect the payment itself directly into the digital Invoice-to-Pay process.
Open Banking adoption continues to grow, while the infrastructure supporting faster and more connected payments is also evolving. The direction of travel is increasingly clear. Payments are becoming more connected, programmable and real-time.
Why should Accounts Payable care?
Because payment is not separate from Invoice-to-Pay. It is the outcome of it. Consider the journey we have discussed through this series.
An invoice is received.
The data is structured.
It is enriched.
The supplier is validated.
The PO and receipt are matched.
Tax is checked.
Declarative guard rails are applied.
Exceptions are resolved.
Approval is obtained.
We now have what I have been describing as: Trusted Data. (It's all about trusted data, without this automation of the above flow fails). At that point, why should the transaction suddenly fall into a disconnected payment process?
The opportunity is to connect the two.
Invoice → Validate → Enrich → Control → Approve → Pay → Reconcile
And increasingly:
Trusted Data → Trusted Payment !
This changes the relationship between AP and Treasury
Traditionally, Accounts Payable and Treasury have had different responsibilities.
AP establishes: What do we owe, to whom and when?
Treasury determines: When and how should the cash move?
Those responsibilities remain important. But technology increasingly allows the data and decision-making between them to become connected.
Imagine an environment where Finance knows:
Which invoices are approved
Which suppliers are validated
When every invoice is due
What early-payment discounts are available
Current and forecast cash positions
Which payment methods are available
The cost of each payment method
Which transactions require additional approval
Whether supplier bank details have changed
The working-capital impact of paying today versus tomorrow
That begins to create something more interesting than payment automation. It creates payment orchestration.
From processing payments to deciding how to pay
Historically, Finance has often processed payments in batches. But in a more connected environment, the question could increasingly become: What is the optimum way to settle this particular obligation?
That decision could take account of:
Due date.
Cash position.
Currency.
Payment cost.
Supplier terms.
Discount opportunities.
Risk.
Payment method.
Approval authority.
AI can potentially help Finance evaluate those variables. But, as I argued in Part 2, AI should not have unrestricted authority over financial transactions.
The final decision must remain subject to strict declarative guard rails.
Is the supplier approved?
Are the bank details validated?
Is the invoice approved?
Is the payment within authority limits?
Does segregation of duties remain intact?
Has anything changed since the invoice was validated?
What is the impact on working capital
Only when those controls have been satisfied should payment be released. Intelligent does not mean uncontrolled.
Real-time payment does not mean pay immediately
This is an important distinction. The ability to pay somebody instantly does not mean the organisation should always do so.
Working capital still matters.
Payment terms still matter.
Cash forecasting still matters.
Early-payment discounts still matter.
Treasury policy still matters.
The opportunity presented by real-time infrastructure is therefore not simply: “Pay faster.”
It is: “Pay at the optimum time, using the optimum method, with complete visibility and control.” That is a fundamentally different proposition.
Reconciliation could change as well
The process should not end when the bank sends the money. If the payment instruction carries the appropriate transaction and reference data, the resulting confirmation can flow back into the financial environment automatically.
That creates a closed loop:
Invoice → Approval → Payment → Confirmation → Reconciliation → Ledger
Instead of Finance having to determine later which bank transaction relates to which invoice, the relationship can increasingly be established from the beginning. That improves another important component of Trusted Data: knowing not simply that an invoice was approved for payment, but exactly when, how and whether it was settled.
The bigger opportunity for CFOs
This is why I do not think Finance Leaders should view Open Banking simply as another payment technology. The bigger question is: What happens when invoice data, AP controls, treasury information and payment infrastructure become connected?
We begin moving towards an Invoice-to-Pay environment capable of understanding not simply: “Can we pay this invoice?” but potentially: “Should we pay it now, how should we pay it, what will it cost, what is the working-capital impact and have all the required controls been satisfied?”
That is where AP and Treasury begin to converge. Not necessarily organisationally. But through data, decisions and technology.
At CloudConnect, this is how we see the opportunity
The future of Invoice-to-Pay is not simply about extracting invoice data faster. And it is not simply about making payments faster. It is about connecting the entire journey:
Receive → Understand → Enrich → Validate → Control → Approve → Pay → Reconcile
With Trusted Data flowing through every stage. Because once invoice processing, financial controls and payment infrastructure become connected, Finance has the opportunity to move beyond process automation towards something considerably more valuable: Intelligent financial orchestration.
And perhaps the ultimate measure of Invoice-to-Pay automation should not be how quickly we can process an invoice. It should be: Can we make the right payment, to the right supplier, at the right time, through the right payment method — with the right controls and complete confidence in the underlying data?
To learn more about CloudConnect technology and services, explore our website and schedule a FREE consultation.
Missed the previous blogs in the "Future of Accounts Payable" series?
Part 2 - THE FUTURE OF ACCOUNTS PAYABLE | Is Touchless Invoice Processing Already Becoming an Outdated Ambition?
Part 3 - THE FUTURE OF ACCOUNTS PAYABLE | E-Invoicing, Peppol and the End of the Traditional Invoice?
NEXT IN THE SERIES
Part 5 – The Connected Supplier: Why AP Transformation Cannot Stop at the Buyer’s ERP
What happens when we extend Invoice-to-Pay transformation beyond the buyer’s internal processes and connect suppliers directly into the data, transaction and exception lifecycle?
Comments