See Invoice Status in Real Time.
Finexer’s OB Invoice Tracker gives platforms bank-confirmed invoice status at each payment stage.
Each invoice tracked by the Finexer OB Invoice Tracking status model depicts the status right from the creation of a payment request, its authorisation, its submission, its receipt at the payer bank, its matching to the invoice and its culmination as a settlement.
This obviates bank check iterations with human intervention, even as it delegates reconciliation and UI to the platforms. So invoice tracker has come a long way.
The issue and why it arises
Finance businesses have a legacy dependence on decoupling billing and bank activity, entailing manual intervention in checking bank portals and lags and delays in obtaining batch reports. This disconnect – invoice records in the billing system, payment events in the bank – is where visibility breaks down.
When it comes to a payment that takes a route from beyond a platform’s ambit, which, in this case, is Faster Payments, by way of a retail bank app, for instance, the platform has no real and present insight regarding the invoice’s status in real-time. This results in a long-drawn-out reconciliation, lags in cash use, and bottlenecks in customer service.
How does this issue impact business?
Delayed or inconsistent invoice status updates creates delays in DSO, increases finance team workload and creates friction in customer support – particularly for platforms handling high volumes of bulk payments.
Product managers find themselves scuttled off payment user experience and struggle to make known dependable signals of “paid” status within billing flows. For bulk payment clients like market-wide and payroll services, ambiguity regarding per-invoice settlement results in liability further down the payment chain and grid-locked customer support.
What constitutes a solution?
A solution is one where the following stipulations are met:
- Per invoice visibility at every event in the journey, rather than just the final bank balance
- Discernment of payment intent from payment settlement
- Webhooks on payment lifecycle events for live, see-it-as-it-happens end-to-end financial journeys
- Provision of structured bank data and event webhooks to support the platform’s own reconciliation logic
- Reconciliation policies and user interface to be left in its entirety to the platform
How Finexer resolves this issue
Finexer provides the Open Banking infrastructure layer underlying the dichotomy of payment intent and bank receipt. PIS tracks payment requests, and AIS steps in for authentication of transaction events at the bank level and applies individual-payment webhooks upon status change, enabling platforms to be up to speed with live invoice records. Finexer stops short of turning in a finished, composite console, leaving the building of the user interface to the platform.
Finexer Open Banking Invoice Tracking Status Model

- Created: An invoice record is in place and a payment request is created, with the payer yet to act on it.
- Payment Requested: A payment request to payment links is sent to the payer; payment intent is added to the records.
- Payer Opened Flow: The payer has opened the payment request link. Payment intent is logged before bank authorisation is given.
- Authorised: With the payer having given the go-ahead to the payment on their bank platform, the banking green signal is given by way of PIS.
- Submitted: The payer bank enters the instruction to pay into the payment processor.
- Received: The payment is now in the payee bank account per AIS data.
- Matched: The platform matches the bank receipt with the original invoice.
- Settled: Funds are accessible and add to the final balance in the payee account, as a result of Faster Payments.
The above is the norm but not the rule, given the following exceptional states:
Partial, Overpaid: Receipt amount does not match invoice amount, causing the system to requisition exception management.
Failed: Payment go-ahead or authentication fails, calling for redoing it or using alternative arrangements.
Expired: Payment request lapses beyond the stipulation without being acted upon.
Needs Review: A bank receipt cannot be extrapolated to automated invoice reconciliation, under which it could be matched to an open invoice – the platform’s finance team must review and reconcile manually.
Open Banking brings invoice platforms on the same page as bank accounts

PIS is about initiating and monitoring payment intent. Upon a platform’s issuance of an observable payment request to a payment link, PIS records a payer authentication and go-ahead and applies webhooks per payment as the transaction payment journey moves to Submitted. The webhooks applied by PIS allow the systems to depict real-time status even as the payer executes the payment.
AIS accesses the payee’s bank account data only with the account holder’s consent, granted through the Open Banking framework. Finexer acts as a conduit – it cannot make transactions, affect outcomes, or access passwords. When a payment registers in the payee’s bank account, AIS delivers the data that triggers the Received status.
For webhook architecture detail, see payment status tracking.
Why Does CSV-Based Invoice Tracking Fail at Scale?
Legacy invoice tracking, as opposed to Open Banking trackers, traditionally separates billing software from bank accounts. Such systems require regular, frequent and timely bank statements, CSV files and lags caused by delayed notification by accounts executives. This has the following implications:
- There is no proper visibility of each event over each payment’s lifecycle.
- Manual scrutiny of payer green signals and credits to the payee bank.
- Delays in reconciliation and raised DSO.
The Open Banking Invoice Tracking status model produces signals of each event over each payment’s lifecycle, which is pegged to and triggered by requests for payment and banking transactions.
Traditional vs Open Banking Invoice Tracking Status Model
| Stage | Traditional Tracking | Open Banking Invoice Tracking |
|---|---|---|
| Created | Invoice created and noted but no notification at further stages | Invoice created, payment request registered and observable |
| Payment Requested | Email or PDF sent; no receipt confirmation for payer | PIS-issued request; webhook fires when payer opens or authorises |
| Authorised | Event not traceable; downstream bank credit is proof of payment | PIS applies webhook on payer consent; platform receives confirmation immediately |
| Submitted | No event registers until bank statement is available | PIS applies webhook confirming submission instruction sent to bank |
| Received | Bank statement or CSV file required to confirm receipt | AIS data confirms payment has landed in payee bank account |
| Matched | Manual reconciliation by finance team | Platform uses AIS data to match bank receipt to open invoice |
| Settled | Settlement depends on when bank balance is updated | AIS confirms and records Faster Payments settlement |
| Exceptions | Exceptions found during manual reconciliation — delayed discovery | Partial, Overpaid, Failed, Expired, Needs Review — flagged immediately via webhook |
Which platforms are building Open Banking invoicing?

- Accountancy SaaS seeking granular-level visibility and notification
- B2B billing platforms seeking out nuanced collection-related user experience
- Markets that call for seller-side settlement traceability
- Payroll services that want bulk payouts a quick affair requiring the least amount of manual intervention
- LawTech platforms with similar needs for their clients’ ecosystems.
Decoding Finexer based on its rudiments
Finexer is an FCA-authorised Open Banking infrastructure layer. It provides the data and event feed that platforms use to build invoice tracking, matching logic, and finance workflows.
Core Insights
The signal that confirms payer intent
PIS applies webhooks on authorization confirming the payer’s consent to the payment, giving you an early paid-intent signal.
What is proof of settlement?
Finexer’s AIS bank data delivers the exact payment event that your app uses to mark Received and Settled after confirmation by Faster Payments.
When do platforms need to go it alone?
Platforms are on their own when putting into practice matching logic, transitioning user interface states and transaction flows. Finexer’s inputs are restricted to event feed and audit log.
What is exception handling?
Handling part payment and overpayment are exceptional states, and so are Failed or Expired payment requests for recovery.
What is the difference between PIS and AIS for invoice tracking?
PIS signifies intent and consent pegged to a payment request, informing you of payer approval for a transfer of funds. AIS purveys bank transaction records leading up to the actual instant when the payment reaches the payee’s bank account. AIS and PIS are vital to full invoice status tracking.
Is Finexer capable of automatically confirming an invoice’s full reconciliation?
Finexer provides AIS receipts and applies per-payment webhooks notifying receipts and flagging exceptions. However, reconciliation logic, Matching, and posting remain the platform’s onus for them to implement over and above Finexer’s data.
Do Request-to-payment links change invoice transaction flows?
Request-to-payment links let platforms attach an identifier to payment intent, the authorisation and submission of which PIS tracks. That identifier enables pegging payer actions to invoice records, curtailing manual intervention and improving user experience.
Will our Open Banking tracker cover all UK banks with this model?
Our Open Banking tracker supports almost all consumer and business banks in the UK, including Lloyds, Barclays and NatWest. Platforms should check their banking capabilities before planning integration of our infrastructure layer.
To see how Finexer’s Open Banking Invoice Tracker delivers per-invoice status from payment request to bank-confirmed settlement.

