I recently received a requirement to account for the entire deferred revenue amount of a sale, then recognize the revenue over time, based on consumption or clicks from a customer. Oracle Receivables has two “commitment” transaction classes to support this type of requirement.

The two commitment transaction classes are:

Guarantees: as you associate invoice transactions the amount due “moves” from the guarantee to the invoice associated to it.

Deposits: as you associate invoice transactions the amount due on the invoice is reduced or wiped out and all cash, collections, and aging can be tracked on the single deposit.

In my situation Deposits is the way to go for the following reasons:

One bill to the customer is required; we are billing the entire amount of the “deal” using installment terms (example: 25% of invoice every 30 days). Opposed to guarantees where there is an amount due on each invoice associated to the guarantee (not acceptable in my case).

Also, cash can be applied to the deposit, guarantees do not allow cash applications.

Finally, aging can be “centralized” as the deposit and installment payments are managed and reported under a single transaction. The impression invoice transactions are simply recognizing revenue in my model, in a supported, auditable way.

Accounting Flow for my setup:

1. Create the Deposit with installment terms
Example: $400K, $100K due at 30, 60, 90, 120 days.

Note: Detailed aging would show 4 installments of $100k due every 30 days.

2. Create a cash receipt applied to first installment.
Example: $100K paid for first amount due.

3. Create the impressions Invoice to recognize revenue - Linking it to the Deposit commitment Invoice.
Example: $90K in impressions delivered

Balance goes to $0 once associated to the deposit which has enough remaining dollars to cover entire invoice.

Why customize an application when you can rework the process.

Working with Oracle Enterprise Applications for over 18 years, I’ve seen many changes. Most changes are for the better, improved functionality, streamlined processes etc. However although the applications are growing rich in functionality, there’s an underlying trend that raises a concern. In today’s market it seems more and more, the path of least resistance is to customize applications vs. reviewing and re-engineering business processes.

A technical solution to a business problem often seems a cheaper path. This is often a misconception. Whilst a technical fix can provide a quick solution, the long term issues tend to be overlooked.

Often customizations are designed around facilitating a current business requirements. As business requirements change and evolve, companies find themselves in a constant state of changing their customization to facilitate the new requirements.

Business Process Re-Engineering or BPR was a buzz phrase in the 80’s and 90’s. It conjured up images of massive change in Organization processes, and practices, forced upon corporations by men in power suits, and aluminum briefcases.

I say it’s time to bring back BPR, minus the power suits and aluminum briefcases. BPR should be treated as a harmonization of business requirements and software functionality, change is good, change works….