Payment orders and the lifecycle of a payment

Payments are key to the operations of companies across a number of industries such as financial services, insurance, real estate, or temp work. Yet, scaling payment operations is complex and error-prone. In this article, we explain how Numeral abstracts the complexity of initiating, tracking, and reconciling payments by capturing the entire lifecycle of a payment in a payment order.

The lifecycle of a payment

Managing complex payments operations requires a thorough understanding of the lifecycle of a payment. Although the exact process might vary for a given company, depending on its business model, internal organisation, processes, and tools, below are the most common steps:

Business event: The company decides that a payment needs to be made as part of its day-to-day operations. The payment can result from an exchange of goods or services or be part of a contractual obligation (e.g. insurance disbursements, loan disbursement or repayment, or capital call).

Preparation: Finance and operations teams prepare payment instructions and key them into their system. Payment instructions typically include beneficiary name and account number, payment amount and currency, remittance information, and execution date. At this stage, counterparties have already been verified and created in the company’s system.

Approval: The payment is approved by the relevant stakeholders within the company. In smaller companies, this is usually done by the CEO. As companies grow, this becomes the responsibility of the finance and / or operations teams as a whole.

Sending: The payment instruction is sent to the bank. There are multiple secure channels that this step can happen through:

• Manually creating payment using a web banking platform

• Generating (manually of automatically) uploading a payment file on the web banking platform

• Using a cash / treasury management system to send a payment file to the bank

• Developing a direct integration from the company’s systems to the bank's systems, using direct connectivity solutions (e.g. SFTP, EBICS, API, or SWIFTNet)

Processing by the bank: The payment instruction is processed by the bank and followed by a series of steps usually invisible to the company initiating the payment. Those steps can be broadly simplified as:

• Verifying the payment instructions. This can be done directly on the web banking platform or by verifying the format and content of payment files

• Approving the payment. The bank will run a number of controls to make sure the payment complies with European regulations on AML (anti-money laundering) and CFT (combatting the financing of terrorism)

• Routing the payment to the beneficiary’s bank

Updating the company on the payment status: The bank updates the status of the payment on its web banking platform. It also generates a payment status report file containing the updated status of the payments originally included in a payment file. The company needs to download and interpret such file to update the status of the corresponding payments in its system.

Triggering business processes on payment status: Different payment statuses will trigger different business processes. For instance:

• If the payment has been successfully sent or received, the company will typically update different accounts and balances and notify their customers, vendors, or partners. Common use cases include crediting a customer account and updating its balance, freeing up credit line for a borrower, notifying a buyer of a pending refund, or notifying an insurance policy holder of a pending claim repayment.

• If the payment is rejected, the finance team needs to investigate why. There are 30+ possible SEPA error codes which need to be managed separately. These can range from insufficient funds to account closed to compliance reasons. Depending on the response, different team might be involved in the process.

Reconciling bank accounts: The company needs to verify that the bank’s account statement matches the bank account entries in the company's system. This includes verifying that all payments have been booked as transactions on the accounts and that all transactions booked on the accounts correspond to legitimate payments. Depending on the volume of transactions, bank reconciliation can be done on a daily, weekly, or monthly basis.

Capturing the lifecycle of a payment with a payment order

The Numeral API and dashboard simplify the management of the entire lifecycle of a payment for finance and operations team with a payment order. In this section, we highlight how a payment order captures the initiation, tracking, and reconciliation of a payment. For an in-depth description of a payment order, you can refer to our API documentation.

Preparation: A company using Numeral can create a payment order by providing information about the payment method, amount, currency, beneficiary, and remittance information. A payment order can be the instruction to send a €10 SEPA instant credit transfer to a vendor or to collect €20 from a customer through SEPA direct debit.

In the examples above, both payments would originate from a bank account connected to Numeral, named a connected account. Now, let’s say the company wants to initiate payments from two different accounts at two different banks. One of the strengths of Numeral is its ability to seamlessly connect to multiple banks with a single API. To originate the payment from a different bank, the same payment order would be created with the relevant connected account corresponding to the account in the other bank.

Approvals: If relevant for its specific internal controls and processes, the company can approve the payment order. Payment orders approved are batched into a payment file, which the company can also approve to instruct Numeral to send it to the bank.

Sending: Sending the payment order is done automatically in the background by the Numeral platform once the payment order and payment file are approved.

Managing the response: A few minutes or hours later, the bank informs Numeral about the status of the payment. Numeral parses the bank responses to update the status of the payment. There are three possible outcomes:

• If the bank states that the payment is accepted, the payment order is marked as executed.

• If the bank states that the payment is rejected, the payment order is marked as rejected.

• If the bank states that the payment is pending, the payment order is marked as pending. A payment order marked as pending will eventually be executed or rejected and will be updated accordingly.

• In case of rejections, Numeral provides visibility on the SEPA error code directly in the payment order. The full list of return reasons can be found here.

Reconciling bank accounts: In the next bank account statement (usually by the end of the business day depending on the bank), the account transaction corresponding to the executed payment order will be created. Once created in Numeral, the transaction will be automatically reconciled with the executed payment order by our reconciliation engine.

For corporate customers, the payment order flow ends here. At this step, a payment order has been created, approved, sent to the bank, updated, and reconciled with the corresponding account transaction. All that with a single API object.

Accelerating your payment operations with Numeral

If you are a business for which payments are a crucial dimension of your product or operations, Numeral can help accelerate how you send and receive payments, without changing banking partners.

Our Payments Advisors are here to support your business in improving its payment operations. You can schedule a call by reaching out to us.