Use cases and customer journeys for request-to-pay

Request-to-pay use cases can cover the whole payment universe

The EBA prepared a survey on the corporate customer needs regarding a request to pay which was published in June 2021 (Request to pay – What corporates want, Report on the Findings of the EBA Request to Pay Survey)[1].

In this study four use cases were identified and described in detail from a corporate perspective (see detailed descriptions in the report):

1. POS/POI in-store payments – together with the credit transfer that follows, request to pay could provide a new cashless option for paying at a physical point of sale.
2. E-commerce and m-commerce payments – request-to-pay can be a viable real-time payment option for all e-commerce and m-commerce transactions.
3. Payments for business-to-business transactions integrated with e-invoicing – this use case can radically increase invoice management process efficiency and enables reconciliation automation.
4. Recurring payments (bill payments, mortgage payments, buy-now-pay-later options, etc.) – executing recurring payments with request-to-pay provides unseen flexibility compared to existing solutions.

In the below table there are a couple of examples, showing that the use cases listed above can cover all kinds of business/payment transactions, so it can be said that request-to-pay can be used in all payment situations; it is not restricted to specific use cases. These use cases rather group the payment situations, and not limit them to specific cases.

Different use cases, but data flow will be the same

Although these use cases will differ from the implementation aspect, because even within an enterprise different IT systems may serve these processes and integrations should be done with all these different systems, all these use cases can be generalized into the order-to-cash processes of enterprises. 

The common thing is that in all these use cases the payment transaction will be accompanied by the issuance and delivery of an accounting document that is generated based on the data in the company’s ERP system(s). This accounting document will be a receipt or invoice. The timing of the creation of the accounting document and the payment transaction can be different or can be simultaneous with each other: the current challenge is to reconcile these invoice and payment data that are not digitally linked within the organization because they are handled by different systems that are not connected, or data is not available digitally, therefore the process becomes fragmented.

Request-to-pay is a great help in this because it can connect accounting document data with payment data: 

1. the generation of the payment request using the accounting document data creates a digitally traceable link between the two datasets,
2. the status of the payment request provides information about the payment status of the invoice/receipt.

As the accounting and payment data will be available digitally and with the payment requests having a reference number the reconciliation can be automated, which has never been possible before request-to-pay with 100% data accuracy.

Digital invoice data will be key

For banks the availability of standardized digital invoice data is crucial to make the onboarding of customers into the request-to-pay service seamless: in case there is a standardized digital invoice available at the company, then the integration for the request-to-pay use case will be much easier for enterprises as invoice data contains necessary data fields of the payment request, so individual integration needs on the corporate side will significantly decrease. Therefore, the e-invoicing/continuous transaction control mandates and growing e-invoicing penetration will be a positive trigger for the request-to-pay penetration as well. 

User journeys for the end customer

All the above use cases can be supported by similar user journeys in the online/mobile banking application differentiated by the payer’s customer segment, i.e., whether it is a retail, SME, or corporate customer and the actual payment is initiated from the mobile banking or online banking application that the customer uses for that specific payment.

The supported customer journeys will be:

 Payee side customer journey

1) Generating data for the business transaction from the ERP system as an input for invoices/receipts (manually and via API). From this transaction data, the ERP/invoicing system will generate the invoice/receipt.

2) Simultaneously with creating the invoice/receipt, a payment request will be generated based on the invoice/receipt data, which is sent to the customer’s account via the instant payment scheme,

3) The payee can view the sent payment request status and track it together with the respective invoice data and update the payment status of invoices based on RTP data,

4) Check and update RTP and invoice repository with the newly issued documents/messages.

Payer side customer journey

1) View incoming invoices & RTP messages in the online or mobile banking application,

2) Approve or reject RTP (triggering invoice payment),

3) View RTP status and connect it with the respective invoice and update the payment status of invoice based on RTP data,

4) Check and update RTP and invoice repository with the newly issued documents/messages,

5) In the case of businesses send relevant data to the ERP/accounting system.

What does this imply to banks?

Besides implementing the actual request-to-pay functionality in the bank’s system, banks must support corporate customers to be able to manage their payment requests, payment transaction data, and invoice data in an integrated way both on the payee and the payer side.

In addition to supporting these user journeys, banks must ensure painless integration with the corporate ERP systems. In case the bank ensures an easy integration the penetration into the service will be much faster on the payee side, which will drive the penetration growth of the payer side as well.

As the first wave of customers are likely to be large bill issuers, who can benefit the most from request-to pay the retail and SME banking online and mobile applications should be prepared for the integrated management of payment requests, receipts/invoices.

On the corporate side, the approval of payment requests and payments will be a slower process in the second wave of implementation, as corporate ERPs and corporate payment (approval) processes must implement this functionality. However, the bank can provide value-added services for the integrated management/presentation of payment requests/invoices and payment transactions to the midmarket segment, where the ERPs are already customized and this functionality could be an add-on, providing a user interface and an API connection to the ERP for seamless data exchange.

[1] https://eba-cms-prod.azurewebsites.net/media/azure/production/2764/eba_20210625_request_to_pay_corporate_survey_report.pdf