As SAP consultants ply the waters of the SAP eco-system worldwide, they frequently come into contact with other guilds active in these environs. By “guilds” I mean other software shops like Vistex, Ariba, and Hybris. From time to time, such as in the case of the latter two companies, SAP will simply acquire these tools to build out the main product line.
As an SD consultant, I have been hearing more and more about Hybris in various projects. The purpose of this article is paint a general picture of Hybris Billing and Pricing– in a sales and distribution context – and identify components and some potential issues with this tool.
Before diving into the billing (everyone loves invoicing), it should be made clear that Hybris offers comprehensive multichannel e-commerce services, inclusive of product content management software. For the purpose of this article, however, I will focus on billing and pricing details, and what it adds to standard functionality within SAP SD.
Technically, the Hybris billing solution offers up 2 application servers, one called “Convergent Charging” which handles Pricing and another called “Convergent Invoicing” for Billing. Both integrate with SAP middleware to connect with SAP CRM and then ECC.
What the Convergent Invoicing (“CI”) application server provides – and what SAP SD does not – is a solution for metered billing, which is the standard business model for certain businesses like telephone and electric companies. Accordingly, Hybris can be seen as a type of bolt-on enhancement to ECC to enable additional potential billing scenarios. If it is more profitable to bill your heavy users under a metered billing format than on a flat-rate basis, then it is conceivably in your interest to consider it.
The Convergent Charging (“CC”) application server allows for new and different Pricing Groups, which can be added to Access Sequences when determining pricing. Consider, for example, a new Group “Time of Day” that interrogates data usage per time used on a 24 hour clock. If usage occurred between 7AM and 6PM, then higher “Day” hourly charges could apply. Otherwise, billing would be at the presumably cheaper “Night” rates.
After CI completes the Bill to the customer, it is transmitted via middleware to CRM and ECC for standard AR handling and visibility.
It should be noted that unlike ECC, Hybris is not written in ABAP, but rather in JAVA. As such, customizing is a parameter driven exercise with less baked-in configuration possibilities than in your classic ECC. This means your reliance on technical support is therefore heavier. Coding can be fun, as long as others are paying for it, right?
In some companies, billing is handled completely within CRM. No problem, Hybris can bolted on to CRM as well to support such solutions.
Before considering using Hybris in your company, a fundamental question needs to be resolved first – is metered billing appropriate for your business? If this is a change from your current billing scenario, all impacted internal groups need to sign off.
Imagine if Amazon or Apple were to consider metered billing, an unusual format for their industries. Currently, both provide online content on a flat-rate basis. The customer pays a fixed fee and then downloads the entire audio or video.
Let’s say that they were to be seduced by the prospect of metered billing. They could force heavy users, who download content continuously, to pay more than they would previously under a flat-rate scheme. If the content is truly proprietary and unavailable elsewhere, it could make sense to bill for access on such a clock or metered basis. Management may be also attracted by the greater potential for content control.
Companies contemplating switching from flat-rate to metered billing under Hybris nevertheless must consider latent issues in terms of Revenue Recognition – a known limitation with Hybris.
For example, a company could bill its customer upfront for a block of time. Going forward, the company would be forced to make hand journal entries to G/L sub-ledger accounts to allocate billable time as used (and also to track remaining balances). That can be a little too manual of a daily process to contemplate, especially if a Billing department is understaffed and under budgeted.
A creative consultant can come up with other solutions as well. A report can be created in Business Intelligence (“BI”) to capture usage by date and clock time for selected Revenue Recognition groups. This can be carried back to SD programmatically (assuming that your project has an appetite for writing code). (As noted above, not always true).
SAP, for its part, is aware of the problem. S/4 HANA release 11 is said to address it in its RAR (automated Revenue Recognition) module. Apparently, it includes the ability to take billing items out of CI and interface them easily by configuration into both CRM and ECC.
There may be other solutions as well. Consultants needs to be sensitive to situations where manual work-arounds (like manual hand journal entries as discussed above) may represent too great a burden. Other business constituencies may well be divided as to how to bill and recognize revenue (and who will do the work and bear the cost). Obviously, it would be better to resolve these issues first so that everybody can be on the same page at the onset. In an ideal world, of course, they are.
In our imperfect world, however, sometimes these issues are discovered only after the soil is tilled. This is where good consultants with lots of previous experience can step in and make helpful suggestions to reduce the pain points as they are encountered and help the company achieve its goal of increased revenues.
Author: James Olcott, SAP SD Lead Consultant (with thanks to Kurt Shallenberger for his time and assistance)
