Data integration in the O2C process

Data projects have to be linked to business value, so why is more transparency in the order-to-cash process worth pursuing? Getting more transparency in the O2C process allows us to see where we can shorten the throughput time to get a faster cash conversion cycle and free up more working capital. It's also a possible first step in a more fine-grained profitability calculation.Trying to get to insights in the process, you will have to solve a couple of challenges that will steer you towards a clear, efficient and automated process along the way. This allows your people to transition from doing low value input work to high value analysis and optimization work.

3 systems to integrate

In a typical O2C process you have 3 systems that have to be aligned for you to know how long it takes between the time an order is placed and the time the cash hits your bank account.

Nowadays the system where quotes, orders, deliveries and sales invoices are managed is usually one and the same. For example a software like Teamleader can handle these steps seamlessly. We call this System A.

The second system in scope is your accounting software, where the sales invoice is booked on a certain GL. In order to link the order to the payment later, you have to make sure the unique identifier of the invoice in System A is put in the accounting software as an analytical dimension as a cost bearer for instance. An example is Exact or Visma | yuki. We call this System B.

The booking of the sales invoices can be largely automated if you have very strict logic that applies to every invoice, but usually an accountant is still needed to start the process, double check if everything went well and handle exceptions. Then we have System C: the database at the bank where the payment by the customer of the sales invoice is registered. Using Coda you can get these payments on your bank account into you accounting software. If you don't use structured payment reference, you still need to link the payment to the invoice manually.

Start tracking the time between Order and Cash

Since we now can identify the different steps in the process, we can track the time between an order and a payment.

But the transactional systems A, B and C are not well suited to facilitate analysis on the whole data flow. That's why we use an analytical tool, like a data warehouse where the actual data integration occurs and where it is enriched with relevant properties of the transactions - like what product, customer, geography, sales rep the order is about.

Now we can link a visual dashboard to the analytical system to show trends and distributions in a visual way to generate insights about the process.

Sounds easy enough, right? It can be, if you always have one order, one corresponding invoice, and one payment per invoice. However, in reality it is usually a lot complexer, with a lot of exceptions and manual interventions. Imagine a rebate as of a certain volume, or a bulk payment of a set of invoices, or ... you know how it goes.

Good luck!