Financial Pinbal l: Scoring Revenue Assurance Points

In a CFO’s fantasy world, the game of payment processing and revenue posting would resemble a slot machine that hits jackpot every time. In the real world, that process looks more like a pinball machine—you get more points each time you bounce the billing or accounts receivable data back through the OSS maze. Every time you’re able to hit the marble back into the system, you’re closer to the jackpot, but the marble (or data, in this case) eventually falls through the paddles at the bottom. And even though there are few “pinball wizards” out there, tighter integration can be the key to revenue assurance teams scoring big.

Financial Systems In an RFP situation, financials integration is often not on the radar screen of small companies, says independent consultant John Konczal. “It’s an afterthought when they can’t map products and promotions to entries in the AR. Initially, there is a lot of focus on rating and discounting capabilities. What many people fail to realize is that granularity of financial reports is just as critical as pricing.” He advises service providers in an evaluation process for billing or financial systems to ask to see:

a sample display chart of accounts
the level of data analysis inherent in the system
what “canned” financial reports look like, and what ad hoc reports can be created
if data can be analyzed by call type and origin for financial purposes.

Lastly, he says, run through scenarios. “A multimillion-dollar financial system is not worth a dime if it can’t draw accurate and detailed information from the billing system.”

When the billing system is being replaced but the legacy financial system remains, the new billing system must be fine-tuned to support the existing structure for financial and historical data. This can be very tricky and complicated, Konczal says, because it gives vendors and systems integrators few reconfiguration options. “RBOCS are very difficult to work with in integrating the two, because they have a lot of practices and procedures for AR that don’t necessarily correspond with the billing system logic,” he says.

Accounts Receivable + Billing

“Accounts receivable management is a little more difficult, because you have to be able to track accounts though different systems,” Konczal says. “From a business process standpoint, separate billing and AR functions provide an opportunity for account information to be out of sync, because the logic is different between the two systems. Most billing systems don’t have APIs that allow for payment updates from another system.”

Many vendors have built-in receivables management functionality with logic between bill calculation and AR. In order to implement a separate AR system, the functionality has to be stripped from the billing system in order to effectively integrate the AR. “This is one of the most difficult points of integration,” Konczal says, “and I have frequently advised companies implementing a new billing system to postpone this integration to a later developmental phase.”

Stephanie Pang, PeopleSoft’s billing product strategy manager, says ineffective integration can devastate a carrier’s bottom line. “A typical scenario might be that a CIO has to maintain a front-office system, several billing systems, and some back-office systems so common data must be shared across all these different systems. Take the customer master data, for example. If a customer changes their billing address, it might have to be changed in the customer relationship management system, three different billing systems, and a financial system such as accounts receivable. Neglecting to update the data in just one system can result in a billing delay of weeks, and the cash flow ramifications directly hit bottom-line revenue.

“Another example where transactional data must be shared across systems is in the area of handling billing adjustments or corrections,” Pang says. “A billing error due to an incorrect price can require a change to a contract that lives in one system. A price adjustment may have to retroactively adjust historical billing on multiple systems. Finally, it must adjust the accounts receivable balance and the general ledger.”

Arthur Andersen partner Ronald Haas says that he’s seen a number of ILECs struggle with time-to-market issues in the financials integration area. “New products must be associated with unique revenue codes,” he says. “Most legacy billing systems map revenue to accounts based on a revenue code that is implemented within the billing system on usually some type of a USOC masked table, as an example. The USOC mask does a couple of things during bill day processing. It will pull recurring charges from the account, it will also point the billing process to the correct tax table so the taxes and surcharges can be applied to the bill.”

If the financial system doesn’t associate the amount with a revenue code, Haas says, “there’s nowhere to put it. You end up having hundreds of thousands of dollars put into some suspense account. Then you have to throw people at it to trace what type of service this is, what kind of product this revenue represents, in order to make manual journal entries in the financial system to balance the books.”

Administrators of mainframe, CRIS-based billing systems, he says, face the difficulty that most of these revenue codes are hard-coded into the system. “What ends up happening when you have a new product is that the implementation of that revenue code is put into the change management process that IT uses, and is thrown in with all the other enhancements and changes that have to be prioritized just like anything else. Unfortunately it doesn’t always get prioritized in a manner that gets it in there before you start recognizing revenue associated with the product.”

Another CRIS limitation is the level of data detail; NPA/NXX breakdowns don’t provide any meaningful product analysis information. Haas says the ideal solution for both problems is separation of the AR system from the billing system, with a concurrent migration to a table-driven environment for rate plan creation and financial analysis. “We have several clients right now that have actually just finished” this process, he says. One is an ILEC that has “stripped that functionality out of their billing system, and the whole classification of revenue and guiding of revenue to accounts is now separate from CRIS. It’s a stand-alone application now; it’s still a mainframe-based application, but it’s table-driven. The architecture is flexible enough to allow them to respond to the market quickly and to support the product development process.”

General Ledger + Billing

The general ledger integration usually causes fewer problems than accounts receivable integration, Konczal says. “On the general ledger side, billing vendors generally have good data flows and APIs; most problems arise when the billing system can’t properly segment billing data in order to support required financial reporting schemes.” The two areas of biggest concern for service providers with GL and billing system interaction, he says, are taxation and discounts: “The GL must properly journalize discounting. Often, problems arise when the billing system reports revenue incorrectly by booking discounts by general code and not by product. You need to have a GL code for each specific product, and for each product within a specific geographic region, so that the financial manager or CFO can track financial information by product.” Konczal says that some systems are limited in their reporting capability to the level of detail a company would present in its annual stockholder report—which makes life difficult for upper management. He also says taxation applied at the GL-code level can be highly erroneous—especially in a multiple-service or cross-geographical offering, where service providers need to show tax by product code, municipality, and so on.

TMNG consultant Michael McGutkin says that this is an area that lends itself to more problems downstream. An error in applying tax affects credit handling and carrier-to-carrier reconciliation, especially in a finite or automated environment. The billing to accounting mapping is especially crucial for large business customers, whose internal accounting structure may be quite different from that of the carrier. “If I have one company that has its 15 or 20 cities, I may have a fairly complex structure for that customer that has to allocate to each one of those, and also have different taxes and allocations for each of those jurisdictions, as well as from a city and county and state level, for taxing and profit/loss calculations. So taxing is a big problem there,” he says.

Accounts Receivable + Financial Institution

A number of sources should be examined for leaks that will be evidenced eventually in a company’s financial systems, McGutkin says. The company needs to look at how much money is coming into the lockbox, how much is outstanding, the metrics being used to measure returns on billing, how quickly, how many exceptions are generated, why the exceptions occur, and what is being done about it. Even with scan lines on the remittance slips, errors can occur in lockbox processing. The number of mismatched amounts or partially paid invoices increases with the size of the holes in dispute resolution processes. And AR has an even bigger job with consumers embracing multiple payment options. Service providers need to perform due diligence on third-party financial institutions before having them process on-line and credit card payments.

“In a lot of cases, we find errors that are not our errors—they were errors with the bank,” says one carrier representative. “We have to make sure that we’re in alignment with the banking vendor and the issues that arise with revenue assurance when you’re dealing with an outside vendor. A lot of times when they’ve made production moves that could impact you, you’re not aware. They might not have as strong revenue assurance practices as you do. I think it’s really important when you do find issues to determine whether it’s an external or internal problem immediately, so that you’re not spending a lot of time on issues that aren’t yours. And then get the appropriate person or liaison involved, if it is an issue that’s outside the company, and ensure that they’re following up on the issue,” she says.

Financial Institutions + General Ledger

Some of the most obvious, and most common, problems are consumer-generated, says Becky Dancy, senior solutions consultant at Intertech Management Group. Errors occur in AR processing if the lockbox receives a payment with no account or invoice number, or conversely a remittance slip with no payment. This requires the system to handle unapplied payments. Unallocated payment support must be considered in the case of an amount received that is greater than the amount due. The service provider must also consider payment allocation prioritization rules. For instance, in a convergent system, payments must first be applied to local charges before long distance or Internet.

Frequently when a consumer submits a single payment for multiple accounts it must be processed manually, she says. The system must also support insufficient fund (NSF) processing, which is even further complicated by cancelled bank accounts and expired credit cards.

The introduction of on-line bill payment and the increase in consumer demand to have as many payment options as possible make things even more difficult, says Information Control Corp. consultant Scott Bushey. “One of the biggest hurdles is that the internal business processes for accepting a real-time payment often don’t exist,” he says. “Many companies accept a lot of paper bills with paper payments, and they are run through a very simple or even manual process. When you implement a real-time payment application, those transactions are automated, and a new business process must be put in place to handle a whole new breed of errors. Business procedures need to be established for error processing. How is that person who used to manually enter remittance amounts going to be notified? E-mail alerts and daily reports are two common answers.”

Marketing Thrown in the Mix

“At MCI, we have very complex product and promotions,” says Robbie Rutstein, director of ordering and billing control for MCI WorldCom’s mass-market segment. “They may appear to be simple to you, but in order to make our system work, they become very complex. MCI prides itself on speed to market; we can put a product out in 4 weeks. But that means we have to jerry-rig 60 systems to get to market. For a product like 5 cents every day, for instance, … you can have up to 30 different ways to qualify the plan. And when we try to check or audit our invoices, our systems don’t do that,” she says. “So I am in this situation [of automatically] auditing only one out of 30 different ways to determine the bill is correct. Because of the complexity, for the first time, we are beginning to have a little more revenue leakage than we like. Right now, in order to get around this antiquated system, we have to [practice] some manual ad hoc; we’ve got to get to all the different ways of qualifying how a customer can be rated for this particular invoice.

“We have so many tables that rely on code from another table, and are not sure how that code is going to impact this, and by the time it gets downstream it’s something totally different that what was intended,” Rutstein says. And while traditionally the IT department has been blamed for errors, product development and marketing organizations are creating their fair share by prematurely pushing products to market. “The marketing department intended the product to look like this, but by the time it got into a product description, by the time it got to the IT folks, by the time it got to the auditors, and by the time it got to the end result, it doesn’t look like anything they intended, and the customer calls and says, ‘What’s this, huh?’ It’s very difficult because before MCI WorldCom, [in the days of legacy] MCI, we were a marketing company. Marketing ruled us, and whatever marketing said, they threw it over the wall and [it was] yours to fix: ‘We don’t care. Here’s the product—you just make it work.’ And now, with WorldCom’s [financial focus] … the culture is beginning to change.”

Sometimes the billing system just can’t handle the marketing department’s newest products or pricing plans, says Haas. “What ends up happening with the introduction of new products and services, if your billing system isn’t flexible enough, is the revenue comes flying over from the billing and hits the financial systems, and there’s nowhere to book it. We’ve seen organizations staff up with people to do nothing more than investigate all of these out-of-balance conditions that exist because they don’t know where to put the revenue. They have to backtrack and do it manually.”

Outside Sales and Commissioning + Billing

From a wireless perspective, some of the biggest integration problems stem from the industry’s unique retail business and related point-of-sale systems. Commission and agent reseller percentages need to be allocated internally and externally with the financial systems. It is especially important to have open communications with third-party vendors. The carrier’s change policy must include impact assessment and some sort of communication procedure to ensure there are no negative impacts downstream.

Wireline and data services—especially those with complex account structures—also complicate commissioning, TMNG consultant McGutkin says. Assigning commissions for pieces of sales, regions within an account, retraction of commissions for customer credits, and “net” accounting systems are a nightmare with overly general revenue codes, he says.

Conclusion

There’s no doubt that technological advances both help and hinder carrier OSS integration. One recent e-mail testament of billing-related problems will keep all of us in jobs for a long time to come. It’s the story of a customer being the marble in the pinball game: “I just ran into a simple problem of double-billing with a long-distance telephone company. My first contact saw the problem on my account screen, then transferred me to the ‘billing department.’ The billing department could not see the same account information, and transferred me back to the customer service people again. There the person saw the problem again on my account screen, but then asked me to fax a copy of both original bill and the credit card statement showing that I had indeed paid twice. (Every time I was transferred, I had to give my account identifier, i.e., my phone number, and verify my address!),” he writes.

“I also noticed two strange call attempts charged to the personal 800 number that they had given me. Since that would need a pass code given out by me, I questioned it. Turns out they thought it might have been two test calls by the provider, made when they implemented that service feature. What will make the above scenario even more stupid and an ‘unsatisfying’ customer experience, will be the use of the Internet and web for bill presentation and customer account accessibility. Then, it will look even more inefficient when the customer service person can’t see the same information or fix an obvious error.”