Introduction
The ubiquity of the Internet, driven by availability of bandwidth is spawning a variety of new online businesses. Aggregated sales of products and services are changing the way in which businesses are being conducted. Increasing variety of channels for customer interfacing are rendering complex business models. A variety of payment gateways, payment collection services are enabling simpler integration of finance flow across customers and businesses. Banks are providing advanced services enabling businesses for online commerce. Governmental regulations are also advancing to address the changed nature of commerce. Customer touch-points are becoming simple. Mobile applications allow ordering a product or service with minimal inputs. Pre-paid and post-paid options are possible for most online transactions.
In such an online market, a number of stakeholders participate in product or service shopping and delivery processes. Platform providers, Product or Service merchants, Logistics, Payment Providers, Banks and Customers are all engaged in commercial transactions. These transactional processes span across a period of time. Since the processes in such cases are quite complex with many possibilities for the outcome, the financial settlement of the money transacted is also complex and is also conducted spanning a time period, mostly more extended than the transactional life cycle itself.
This paper aims to provide a framework for ongoing financial settlements across the various process stakeholders and reconciliation amongst these parties.
A sample scenario for multi-party transactions
While the business scenarios are many for the application of the multi-party settlement system, we shall consider an online shopping marketplace for descriptive purposes. An online shopping marketplace consists a technology platform provided by the marketplace along with additional services such as customer interfacing and support, logistics co-ordination, payment collection and bank interfacing, financial settlement, etc. Merchants register to sell their products (or services) at the marketplace and publish their catalogues along with the inventory details. Hence, the merchant’s products are showcased in the marketplace portal that is visited by customers. Customers are drawn to the marketplace portal by various means. Customers place orders for products. Such orders are assigned to the respective merchants. Merchants pack the product (usually with the packing material provided by the marketplace) and gets it ready for delivery. A Logistics partner who is assigned based on several criteria picks up the package and delivers the same to the customer. The customer may have paid for the product already (in the pre-paid scenario). Else (in the post paid scenario), the Logistics partner collects cash from the customer against delivery of the product. Additional processes are invoked if the merchant or the customer wants to cancel the order before it is shipped, if it is cancelled while in dispatch, if the package is lost, if the customer wants to return the product and so on.
Components of the Multi-Party Settlement System
The Multi party settlement system is largely made up of 2 parts –
- the process layer that defines the processes designed for every event
- an event accounting system that provides a ledger view for all the processed events
The MPSS needs input flow of events and optionally another system that consumes the summary accounting information. These external systems would be part of the already existing business eco system. The external systems would include:
- A transaction management system where orders are placed, tracked and managed
- A transactional event system where various events regarding the transactions are originated or recognized. This is a logically partitioned system and, in reality, may be part of the transaction management system itself
- A backend enterprise accounting system that is used among other things for accounting assets, liabilities, HR related expenses, revenue from other lines of businesses, etc.
enterprise accounting system
Event Accounting
The event accounting module of the MPSS includes a General Ledger system that maintains a chart of accounts. It provides user and programmatic interfaces to create ledger accounts, and post journals. Accounting principles implemented in this system are the standard double entry system.
Ledger accounts would include the following types of accounts
- Merchant accounts
- Logistics accounts
- Bank accounts
- Tax accounts
- Market place accounts (such as Revenue, Deferred Revenue, Marketing Expenses, etc)
Transactional Events
For the use case of an online shopping marketplace, the following financially significant events would occur with regard to the shopping transactions:
- Approve
- Deliver
- Reverse before delivery
- Reverse after delivery
- Chargeback [in case of customer returning a product with his own cost]
- Merchant change [when a different merchant is assigned to the order]
- Logistics change [when a different logistics partner is assigned to the order]
Accounting Rules
Accounting Rules
Accounting rules determine how an an event accounting is to be performed. The following table provides a brief outline for the accounting rules for a couple of sample transactional events – Approve and Deliver:
Process view of Events
Process view of Events
While the above section details the accounting rules by which the money is distributed into different ledgers, there is also a process view that details the actual event processing. The various amounts, payment types and such are evaluated in the process. Here is a sample process diagram for the “Approve” event.
The process instance is started upon an envent message being sent to the process. The event message would continue all the data attributes required for calculation, apportionment and evaluation of the accounting amounts and the ledger accounts.
The process first invokes a business rule task to evaluate the various amount variables from the message attributes. Once this is done, the ledger accounts (of the vendor, bank, etc) are assigned in a script task. The third task is to prepare the journal voucher message in a format that may be posted to the event accounting module. Further a service task posts the journal to the event accounting module. The return of this service call is checked for errors. The success or errors is suitable logged by script tasks and the process instance is terminated either with a success or error status.
Payment Advise
Summary Accounting
The detailed accounting of every event of every transaction would occur at the MPSS level in the event accounting module. This would provide a ledger view of all the accounts transaction-wise and event-wise. This level of detailed accounting, while desirable at this level, is not normally desired in backend accounting systems such as SAP or Oracle implemented by enterprises. Usually, the final accounting occurs in these backend accounting systems. Hence MPSS would provide a summarized accounting journal file or can be integrated with an API to the said backend system to post the summarized vouchers. Having posted the summary vouchers, it is incumbent that the references in the backend system are retained in MPSS. Hence a reverse flow of the backend system document numbers is required to update the references suitably.
Payment Advise
Accounting of the transactional events forms the basis for determining the basis of payments that need to be done to various stakeholders. Payment disbursements to merchants, logistics and others depend upon many business intricacies. These are again captured in payment rules. A sample set of payment rules may be as shown below:
A payment process is invoked occasionally that would select, for each vendor, the transactions to be selected for payment along with the amounts that are to be deducted. The net merchant-wise payment advise document would be generated with the document id. These may further be uploaded to the backend accounting system to actually make the merchant payments.
