In the previous article on Financial Management, we focused on how money flows from customer bank account to merchant’s bank account. The number of hops it takes suggests the need for making sure every rupee is accounted for, and hence the need for reconciliation.

Reconciliation – Art of tracking money

Reconciliation is the process of making sure that whenever money moves from one entity to another, money is not ‘lost’ in transit. For example, if order value is Rs. 100, we expect the transaction amount should also be Rs. 100. Given so many manual and automated activities involved in the back end processing of money in various entities involved (your storefront, customer and your bank’s infrastructure, your payment gateway system, etc.), it is not surprising that ‘loss’ does happen. Let’s see how we can make sure money is not ‘lost’ in the system for our online store.

In the above example, following equations hold true:

  1. Order Value = Cash Collected
  2. Cash Collected = Cash Deposited + Fees

Given these, a basic reconciliation (and a must-do for all online store, in a manual or automated process) is this:

Order Value = Cash Deposited + Fees.

You might think this is a trivial equation and will be easy to verify. However, this is not the case. Here are the reasons why:

  1. Time Lag: There is at least 2-3 days of time lag between order placement and cash coming to your bank. Also, there is a lag between when cash is collected by payment gateway/CoD and when it is deposited in merchant account. This means that all the data may not be available to reconcile at any given time.
  2. Transaction Details availability: Depending on the capabilities of your payment gateway and CoD vendor, you may or may not have complete transaction level details from them. This means that the equation can’t be verified accurately. Most payment gateways do provide some kind of reports via their dashboard to help in this, CoD vendor capabilities are more suspect.
  3. Non-Purchase transactions: Above description is idealistic scenario. In a real world, you will also have refunds to take care of, as well as chargeback. Hence the equation becomes more complicated.
  4. Bank Statement details: It is assumed that the bank deposits (C2A and C2B) can be connected to the transaction information (I2A and I2B). Typically it is done by looking at bank statement details (information provided in the deposit instruction) and matching some unique identifier with the transaction details information provided by the payment gateway/CoD vendor. However, this relies on bank having all the details, and payment gateway/CoD vendor providing correct deposit instructions. Doesn’t happen all the time!

Your actual reconciliation steps will also depend on how you feed data into your accounting software (Tally or SAP OnDemand). If your accounting software requires data in a certain form, it is important to make sure such data transformation doesn’t create gaps. In addition, since accounting software is used to generate reports that are utilized by various stakeholders, these reports also need to reconcile against the information generated by the portal (orders) and payment gateways/CoD vendors (transaction details).

It is very easy to start a reconciliation process, and very hard create a fool-proof solution to it. Every merchant should strive to be somewhere in the middle, and constantly try to improve on it. Start with good old excel, and move up the automation ladder.

Goal of an online store is to make money, and if you can’t make sure you are getting your due, the business can’t grow.