Accounting and Revenue Management is an important functional area in the context of Order to Cash management business process. It goes beyond and completes the entire life cycle for a customer.
Often the platforms tend to be more Billing platforms leaving a lot to be managed in ERP solutions. There is nothing, inherently, wrong in it as that is mostly by design and/or by choice. However, that leaves a lot for the target customer to manage. There is so much work that requires larger System Integration cycles not only to bridge the functional gap and integrate two platforms but more importantly reconciling the accounting and revenue data across more than one product or platform. For larger customers, with the traditional ERP solutions, you have often seen a third specialized platform around Revenue Recognition enter the mix to complete the Enterprise Architecture making the SI cycles even longer.
These challenges often lead to the decision on which product/platform (Billing or Revenue Management platform or ERP) becomes the “Source of Truth” for what functional component. The result for the target customer is often platforms that do too much and still not quite enough. If you attempt to look under the hood, the integration layers between the platforms ends up being a big part of the business process – an engine by itself. As a result, some customers may just make the compromise and give up on some key business benefits to stay with one of the two.
Additionally, the management team at the target customer needs a lot more regarding data insight with reports/dashboards. However, with the enterprise architecture mix (painted so far), this is often managed in yet another layer – ‘the Business Intelligence layer’. This, by itself, is not so much of an issue as the new age BI and Data science platforms are good. However, the effort in the setup there is quite big to bring all the data from these platforms together because of much larger functional split across the platforms then intended.
All of this begs a question – “What can be done about it and how do we address it”. To answer that question, we need to understand what is involved first. The topic on hand is very vast, so we will try to focus on the key components that will attempt to address the space.
The header itself had to be very generic. The reason being we are not only talking about Revenue Classification. We also must address EXPENSE, LIABILITY side of the equation. This may be required for many more reasons, but primarily for:
- Accounts Payable – Partner Revenue Sharing, Sales commissions, and more.
Data classification is done at two levels:
- ACCOUNT – Classify the Account between End-Customer, Partners (various types – Reseller, Value-Added partner, Interconnect partner, Roaming partner, Channel Partner, Data Supplier, etc.), Sales Agents, Inter-Company, etc.
- MONETARY – Classify the monetary data between various types of REVENUE, EXPENSE and LIABILITY.
Keeping the business rules aside, the account classification is relatively simple. The challenge is more on the Monetary classification as lot more setup is required, and this includes the following key elements:
1. Item Master
It needs to be a fully functional Item master managing the full life cycle of an item. To that effect, here are some of the key components that make up the fully functional item master.
- Multi Organization Structure Setup – This is setting up your Enterprise, Divisions, Legal Entities, Business Units, Departments and Cost Centers. The Items are for the owning entity and accounting and revenue management of the items require the multi organization structure setup.
- Product Family Setup – This makes up the classification of all the products involved, one of the basic elements of your Item master (Product Family, product Group, Product Line, Product Type, ….)
- Type – Is the item for a Revenue, Expense, Liability, etc.
- Revenue Type – For a Revenue item, what type of revenue is it – License, Subscription, Transaction, Time, Expense, Professional Services, etc.
- Revenue Recognition type – Many and covered in a separate sub-section.
- Inheritance – The calculation configuration with pricing, discounting, revenue sharing, sales commissions, etc. will need to reference the item to inherit all the item configuration when the item is transacted in your engine.
- And more – Item is discountable or not, taxable, or not, bundled item and with that item hierarchy, setup etc.
2. The 4 C’s
- Calendar – one or more Calendars for accounting based on the organization setup.
- Currency – For customers that support multi organizational structures, this not only covers the supported currencies, but also should cover the ‘Cross Currency Sale, ‘Cross Currency Payments’, ‘Cross Currency Journals’. In other words, you need a flexible currency conversion rates setup (many types of currency exchanges required) and a currency conversion process that gives the flexibility to record the sale, payment, or journals in primary and/or secondary currency.
- Chart of Account – As a pre-requisite, the Chart of Account setup requires a configuration setup to flexibly add segments with their own rules that make up the natural account, the supported range for each segment and the setup of each natural account.
- Accounting Convention – This covers the pre-requisites for the Ledger setup. The ledger setup and the definition of the revenue for the balance on the ledger will reflect the compliance for e.g., with GAAP (US) or IFS/IFRS (International) for the statutory and regulatory obligations and these need to be supported.
3. The Ledger Setup
This is natively in an ERP solution, but particularly important to complete the business process life cycle.
- Primary, Secondary and Reporting Ledgers – Based on the organizational structure, you may need the configuration and setup of one or more Secondary Ledgers, a primary ledger or even a Reporting Ledger.
- Accounting rules – The bookkeeping rules (e.g., the double entry bookkeeping) are one configuration setup required for the Ledgers.
- SLA – The module that posts the accounting entries based on the Accounting rules configured into the General Ledgers.
The Revenue Recognition
Based on the nature of the services offered and the types of contract, there are a host of Revenue Recognition models that need to be supported. On one hand, you have the ASC-606 revenue recognition that your business would need to comply with and on the other hand the more traditional revenue recognition methods.
When a transaction is recorded, with the item reference, it inherits all the properties directly or indirectly linked to the item. This process helps with the Classification of the Monetary data as it transacts in the engine in real-time. There are three steps that are required for a revenue recognition:
1. Revenue Split
If the item being transacted is a bundled item, it will require a Revenue Split configuration to split the Revenue. This revenue split configuration can be relatively static – changing at set frequencies for e.g., every month/quarter/year.
Management of intercompany revenue if the Selling Entity is different from the Item/Product owning entity.
Without going into many details, this may include the following and more:
- ASC-606. For long running contracts based on the obligations identified, the revenue is recognized when the obligations are met.
- Immediate Revenue – Revenue that is recognized immediately
- Deferred Revenue – Revenue that is deferred and may be recognized later.
- Revenue on Deferral
- Daily Straight-Line Amortization – Typically used for monthly recurring charges or smaller one-time fees.
- Monthly Straight-line amortization – Typically used for multi month recurring charges or large one-time fees.
- Manual – There may be external triggers that are not managed in the platform and will require a user to manually recognize the deferred revenue.
- Automatic – Usage transactions may consume grants and recognize the portion of the revenue automatically when the usage transaction is recorded
- Milestone based – Recognize the revenue based on pre-set milestone configurations.
- True-up – When the term obligations are complete, but there is still unused deferred revenue, the end of the term revenue true-up will recognize the remaining deferred revenue.
Once the Configuration is setup and supported, the process execution is simplified, and the steps involved are easily understandable. This includes:
- Account– The onboarding process provides the necessary classification of the account mapped to the organization structure.
- Transactions – The engine (rating, discounting, Revenue sharing, Sales Commissions, revenue recognition jobs, manual transactions, etc.) record the monetary transactions and that in turn creates a corresponding journal object based on the supported configurations.
- Ledger – The SLA module picks the journal objects and posts the accounting entries. The jobs can then run the ledger reports for secondary, primary or reporting ledgers.
- Financial Closure – The jobs then facilitate the accounting admin to do all that is necessary to generate and tally the Balance Sheet, generate the P&L statement and to close the Financial Books.
The intent of the article is to point towards the additional setup and configuration and additional processing jobs and functionality that can go a long way in making the integrations to ERP much simpler. These can further assist the prospective customer in streamlining the decisions around which application would be the “Source of Reference” for what functional components. That in turn hopefully makes the Enterprise architecture relatively smaller and easier to manage – all that will reduce the TCO and increase the TTM.
To know how Embrix can help address the Accounting and Revenue Management needs as part of the Order-To-Cash business process, reach out to us. Schedule a Demo with Embrix.