#5. The Building Blocks of Quote To Cash (4/4)

In the previous articles (#1, #2, #3, #4), I covered:

• RLM will continue to use Quote To Cash (QTC) as its foundation.
• The role of CPQ, CLM, and Orders in the Sales cycle.
• The similarities and distinctions between Billing and Invoicing.
• Billing's function is to generate/split the price from an order line into the billable periods.
• Invoicing uses the billing schedules data to generate invoices with line items and process the remainder of the steps in delivering them to the customer. The invoice can also be created manually so that any ad-hoc charges can be passed on to the customer.

In this article, I'll cover two critical post-invoice processes - Collections and Revenue Recognition.

Closure of invoice (Collections, Credits & Payments)

Now that the customer has received an invoice from the seller, it's up to the customer to make timely payments.

Some customers make the payments, some choose to pay in multiple installments, and a few may not pay in time.

Whenever the payments are made, the seller's finance teams must apply it against the invoice so that the balance amount is reflected correctly on the invoice. This can help the customer care/support/success teams/collections teams to provide informed information to the customer on how much they own.

If the payments are not made (without any valid business reasons), the seller's collection makes a few attempts to connect with the customer to get the payments. The attempts can happen through - dunning (formal emails), formal letters, phone calls, or all of them.

In some cases, there may be some genuine business reasons as to why the customers won't make a payment - this usually happens with the perceived value of the products/services or some issue on the payment capabilities on the seller's side. In such cases, the collections can give some credits (or use the previously allocated credits to that customer) and apply them to the invoice. The invoice balance will be reduced, similar to the payments.

If unsuccessful with the pursuit attempts, the collections team can lower the credit availability for future orders to the customer and/or put future orders on hold. It might even forward payment lapse to the credit bureaus. This can hurt the customer's reputation externally as other sellers/vendors in the market might stop their products/services to this customer.

You agree that no customer wants to get into that situation. Likewise, no seller wants to incur the cost of products/services and collection pursuits to end up not receiving the money (that the seller was supposed to receive) and then straining the relationship with the customer. Eventually, the collections will 'write off' the invoices as they need help to keep that invoice open.

Let's now see the above scenarios using the same invoice we created from the last article. Here's the invoice for your quick reference.

Let's assume that there's a payment against the above invoice. See the details on the updated invoice. Pay attention to -

• Paid amount
• Current balance
• Payment status
• Updated to the credits & payments section
• Changes to the text at the bottom

In the "Credits, Payments & Late Fee" section, notice that there are two accounting entries. The 'revenue' account signifies the money received/credited due to the customer's payment, and the other represents a placeholder account where the remainder of the money is yet to be received. There can be many such accounting entries found on the invoice, but the above two are the most basic. This is where the invoice information can feed into accounting.

Now, back to the payments.

Say the customer missed the payment and automatically attracted a late fee on the above invoice. Assume that the penalty is 5% of the balance. The customer agrees to make the payment but refuses to pay the penalty.

The exchange looks like this. Pay attention to the header fields, the "Credits, Payments & Late Fee' section, and the text underneath.

After pursuing with the customer and understanding the reasons for not paying on time, the collections team can take further action. In this case, assume that collections 'wrote off' the late fee by issuing a credit against this invoice, thus bringing the balance to 0.00. Pay attention to the header fields, the "Credits, Payments & Late Fee" section, and the text underneath.

Note—the credit (write-off) is considered a credit memo in this transaction.

A credit memo is the opposite of an invoice amount, where the seller pays/refunds the customer.

As you can see, there are a number of updates an invoice can go through to complete its lifecycle.

The important takeaway is that any RLM solution must be able to produce such a capture on an invoice so that it can be helpful not only for reporting but also for disputes, applying penalties, and being just right about how you've treated your customer in financial matters.

Let's now go to the next topic - Revenue Recognition.

Revenue Recognition

There are two aspects of revenue recognition - number crunching and accounting. While the latter might be daunting to professionals with a non-finance background, the former should be less challenging (relatively), so let's focus more on the part for this article series.

Let's first begin with the definition of Revenue Recognition.

Revenue Recognition is the practice of splitting or apportioning money over the contract length of a product/service. The apportioning is done under the financial accounts so that financial reports are easy to obtain as per the standard/mandatory practices laid out by accounting bodies worldwide.

Currently, the world follows ASC606/IFRS15 as the standard accounting practice. These standards dictate the revenue recognition process so that it's uniform and fair and deters malpractices (e.g., showing more revenue to inflate the valuation or stock price of an organization artificially). Without going deep into those standards, let's see how the above invoice lines can be recognized individually or together.

Keep the following thumb rule in mind before we go into the scenarios -

The seller can recognize revenue against the products/services only when they are transferred or fulfilled to the customer.

Scenario #1 - if the lines can be/are sold separately

In this case, for every line, a separate revenue master record (call it a revenue agreement or revenue contract) is created. Depending upon how these agreements need to be recognized individually or separately, the number of "Performance Obligations" needs to be created accordingly.

If the two lines need to be recognized separately, two separate performance obligations are created.

If the two lines need to be recognized together, only one performance obligation is created.

We'll see these performance obligations in an example below.

Similar to billing, the revenue can be recognized in one go or in a recurring basis. It's usually dependent on the type of the product.

For a hardware item (e.g., an unlocked phone) - the revenue is recognized in one go and almost immediately after the item has been activated by the customer.

For a soft item (e.g., the 'Care' plan for the above phone) - the revenue must be recognized only after the service has been provided. The recognition can happen on a daily, monthly, or any pre-defined frequency.

For the ' Care' plan mentioned in the above example - It doesn't matter whether the customer has used the care service or not, but there must be a 'Phone' against which this 'Care' plan must be applicable. This is how the standards put the onus on the usability and applicability of the goods and services thus improving the transparency with recognition and posting them into accounting. In the absence of this, the 'Care' purchases can be inflated showing a higher numbers with subscriptions to manipulate the stock or valuation.

For the above two lines (whether they are in the same or different transactions) - the revenue will be recognized as shown below. You can see that two lines have two performance obligations created by the RLM solution.

• For the hardware items - the entire revenue is registered in the accounting books in one go.
• For the soft items - based on the thumb rule, if the recognition pattern is defined as 'monthly', the recognized pattern will always be from the 1st of the calendar month to the end of the month, but the amount prorated in case the service is provided only for the partial days in the given month. Since it's sold for 1 year or 12 months, the revenue recognition pattern will be as follows:
• For Aug'24 - since the service is provided only for 17 days of a month having 31 days, the revenue recognized = 17/31 * $4,083.33 = $186.60. The remainder [$4,083.33 - $186.60] is 'deferred'.
• For Sep'24 - the service is provided for the full month so the amount equivalent to the full month is recognized [i.e., $4,083.33/12]. The deferred amount will be 'Total - what has been recognized so far.' This pattern continues until there's nothing left to recognize.
• Notice that the same maintenance item was invoiced from 15 of a month to the 14th of the next month. However, the revenue recognition pattern/timeline differs. It goes by calendar month.

Scenario #2 - if the hardware and soft items are sold as a bundled product

This is equivalent to a 'locked' phone that must have a service (calling/messaging/data service) without which the device is unusable (this is not the case for an 'unlocked' device.)

In such scenarios, both the hardware and soft items need to be recognized together. Only one performance obligation is created.

In case the maintenance service is sold as a separate order, the seller's revenue team must tie the service to the same performance obligation created for the hardware item (or vice versa.)

Accordingly, the revenue pattern looks as below.

Note the 'hardware' item's revenue must be distributed across the term of the contract and can't be recognized in one go.

• For Aug'24, both the hardware & maintenance are computed on a prorated basis, i.e., 17 days of the calendar month [17/31 * (99000+4083.33)/12], and the remainder is deferred to future periods.
• For the full months, the computation is [(99000+4083.33)/12]. The deferred amount will follow the same formula I stated earlier.
• For the last but one period, the deferred amount will come down to the remainder period in the contract, i.e., 14 days of the calendar month.
• For the last month, the deferred amount will be recognized, thus not leaving a penny on the table.

Note - the recognition pattern can change for consumption or milestone-based services. We'll see that when we go into those respective articles.

Conclusion (for these five articles)

If you look at the overall QTC flow I presented so far, this is what it looks like:

Does the above flow seem familiar? If you've been following the announcements on RLM in recent times from various organizations, this is the same flow that was shown onstage, although in different colors and shapes.

This should conclude that RLM will continue to use QTC as the core foundation. If you've been in QTC domain and have worked on most of the flow above - you are RLM ready!

That said, what wasn't shown enough was - how the above 'horizontal' flow can be a 'cycle'?

Simple - well, use visual tools (such as MS Word's smart tool) to make it circular. You get the first wheel of that cycle.

So, are there more wheels? Certainly. I'll show them in the coming articles with recurring and consumption products.

But before we go there, you've to ask a question for yourself - will the above transaction flow be static for all scenarios? The answer is an absolute 'No'.

QTC was very dynamic and catered to so many different flows. What we discussed so far is the most basic flow but is used for the most business scenarios.

With that, I will now conclude the 'foundational' articles. From the following article onwards, I'll take you into the core of the RLM, starting with different flows for most enterprise/consumer scenarios.

Stay tuned! The journey has just begun.