Should an organization design its own online billing solution?

Although there is a lot of third-party online billing/invoicing solutions available in the market these days, none of these can be entirely tailored to any one organization’s needs. For this reason, it must be worth spending a little time looking at whether a billing solution can be developed or built with internal accounting staff and IT people. This would mean that an exact specification could be put forward and, if it was executed to plan, this could be integrated with other internal systems. Once the system was up and running, customers would “flock” to it and the cost of sending out paper bills in the mail would reduce considerably. This would all have the potential to save a lot of money-wouldn’t it? In this brief blog post, let’s look at the six major issues that need to be considered in choosing to go down this path.

Before we look at these six issues, let’s briefly consider an organization’s motivation to undertake a project such as this. The typical logic of most companies is “After an order, we interact with customers today by sending out a paper bill, but it is expensive. Putting that ‘piece of paper’ on our own web site will be cheaper and we can still directly interact with our customers via our web site”. Hence, the internal business case might be “We invoice 100,000 customers a year and our current cost to bill by paper is £15 each time or £1.5 million. As the cost of doing billing via our web site will be £10 (including new internal operating expenses), or a 35%/£0.5 million saving an internal capital build cost of £0.5 to £1 million would be justified.” Where this model is flawed is that research tells us that only 4-6% of customers pay at any Biller’s site (for a lot of reasons that we have covered in other blog posts). This means the real cost per invoice ends up being higher than issuing paper and no ROI is achieved. Under these circumstances, a project is on very shaky ground before it starts. However, despite these problems, let’s assume that an organization stills wants to go ahead. What are the issues to think about?

The first issue to consider is can the organization build an application of sufficient scope and quality? After all, few companies would try to build spreadsheet or word processing software from “scratch” these days. These are usually far cheaper and superior to anything that could be developed in house. In general, widely available software designed for mass market consumption is considerably superior to applications developed in house, primarily because of the economies of scale that can be achieved. An online billing solution would not be any different in this regard? In other words, any in-house solution would probably lack the security, features and reporting capabilities needed and would not be as robust, stable or as user-friendly as a professionally developed application built by specialists in that field.

The second big issue to consider is the overall interface design of your potential online billing system.On the surface, an in-house solution provides the greatest scope to design this interface to suit all corporate requirements. However, third-party apps have changed greatly in recent years and allow almost as much customization and any one organization is likely to need. In addition, a third-party app (if well chosen) is likely to have designed in easy payment reconciliation and settlement (to the organization’s accounting system and even their bank –by electronic bill-matching means). This is often missed by in-house system builds or just adds major development costs to the project, thereby making the return on investment much worse than planned.

The third issue to consider is the need to protect an organization’s customers when using the new online billing solution. At a basic level this means bearing the additional cost to purchase a Secure Socket Layer or SSL certificate and to develop a payment plug-in, which necessitates a proper software development cycle (including specification design, build, test and installation). This potential cost alone can finance years of service from an online invoicing application service provider. In addition, as soon as the organization is processing credit or debit cards online, they may need to be PCI compliant (and bear the cost of maintaining this and being audited to meet bank standards). Direct debit mandates (if they are to be made available) are a further cost in this area that need to be taken into account, as these have high admin costs associated with them.

The fourth issue to consider is the immediate and tangible additional costs that are likely to be incurred with an in-house developed solution. A typical online application development project would likely have at least some of the following tasks, if not more: Needs analysis assessment; Application interface design; Database design; Technology assessment, costing and procurement; Server and security setup; Application build and Testing; Trial Rollout; ALPHA and BETA Testing; Full Production Rollout; Ongoing Support and Maintenance etc. Whether these tasks are done internally or out-sourced, projects of this nature will take many months (and possible more than a year) to complete and result in costs of many tens of thousands depending on the complexity of the application and the security level required. For a large organization this may even run into hundreds of thousands or even millions. This is a large capital cost that may not get a real return on the investment for many years.

Quite apart form the direct costs there are also the indirect costs to consider, because many application development project costs are hidden. The use of internal resources to stop working on other projects or tasks or even give up their “normal” job for a while is one example of a hidden cost that often goes unaccounted for. Every hour a development team member spend developing a new billing system, they could be focusing on an organization’s core business activities. In addition, if project development team members are not experienced in online invoice application development, there will be a high learning cost added to the project, and increase the chance the project will be delayed or even fail completely.

The fifth issue to consider is system-side issues. In other words, an in-house billing system (which is likely to be available 24/7) will inevitably have system costs that can easily be overlooked when initial specifications are done by an organization. There is the cost of the space and setup required for a secure and sufficiently large and secured server. This hosting environment will need careful protection (in maintenance terms and against hacking) proper virus protection and firewalls. In addition, back-ups will typically need much more care than other applications that may be running in the organization.

Last but not least such a project must consider the overall risks that are involved. Recent research suggests that over 35% of all technology projects fail in large and sophisticated companies (who have well-trained IT departments). Although this means that almost 65% succeed, this is not to say that even they were not over time or over budget before they “succeeded” of course. If an organization is therefore not a “large and sophisticated company”, chances are a new online application development project is at even greater risk of failing and/or being late/going over budget.

Conclusion
It is clear that developing an in-house online billing and payment system is a highly time sensitive, high cost and high risk undertaking. Some organizations may be tempted to start the process but may lack the expertise to specify it properly, build it to plan, run it cost effectively and maintain it well (and with the necessary level of security, compliance and control).

With all of these issues to consider, as well as the fact that third-party systems are now so well-developed (and in many cases available on a pay-as-you-go basis) this looks to be an easy decision, especially when given serious thought. In answer therefore to the question we asked at the outset- Should an organization design its own online billing solution? We think the answer is simply No (or at least only if it thinks it can overcome all of the obstacles mentioned above).