The 20 pages invoice

0 comment

“You should call XXXX because they have big problems with their ERP: They have 20-pages bills and are worried about response times and the volume of data.” I look at the company’s website to look exactly at what they do and I finally understand that it is the provision of telecommunications infrastructure to telecom operators, and that the billing is done on the basis of these telco own clients usage, and therefore that the number of lines to invoice is very high.
It reminds me talking with the IT back office infrastructure manager of a business bank who was concerned about the ability of their new internal cloud to properly host their ERP. He told me: “You know, we have provided a server for processing and another for the database and the weak point of our architecture lies in the management of exchanges between the two servers. Or in the case of ERP as everything is highly configurable when you record any transaction the system will perform a lot of checks by querying a bunch of tables which will generate lot of exchange and saturate the channel. We do not have this problem in our business apps because as they are very focused these multiple controls are limited to the strict minimum. This system engineer had understood the intrinsic weakness of a generalist ERP which results precisely from its generalist character combined with the multiplicity of events it may encounter.
Take the case of a person working in the accounting department of a client of XXXX who receives a 20-pages bill to finally generate a journal that includes only the 3 lines before tax, VAT and tax included (we do not consider the analytical breakdown, anyway difficult to establish from a 20 pages invoice…). As the consumption is not known in advance how will this person proceed to check and book the invoice? They will not be able to reconcile the invoice from an order or a receipt. If there is no EDI between the two companies the answer is easy to find: Either they will manually input the 400 lines of the invoice one by one in their purchasing module, or they will open their favorite spreadsheet to calculate the accounting breakdown. Do not laugh it’s still often done that way.
On the supplier’s side it’s a slow and painful process with a lot of paper printing while on the customer’s side they must struggle inputting all that stuff in the purchasing or in the AP management module.
XXXX do not face a hardware architecture problem but a functional design issue.
The detail of service consumption by the consumers is stored in XXXX telco specialized management systems. What is the interest of re-keying it (or more likely to inject it by interface) in the ERP except to bill it as it is? One may answer: It is to bill it as is! But what is the point of billing it as is? Will it facilitate control by the client? No. Will it optimize the management of the invoice in the ERP? No since it generates an excessive amount of data. Why not calculate a summary of this consumption outside the ERP (by category of service for the billing period) and then bill this summary? Ask the question and you may laugh at the answer: “Because we did not think about it!”. It may happen because when you manage information systems in a company that is developing very quickly, you cannot always anticipate everything.
I am not smarter than the IT staff of XXXX or than anybody else. I even think that many people who have already met me are convinced that I am even less smart than them. It does not matter. Simply, I have already encountered in my professional life this type of problem several times and in very different contexts. That’s the reason why I am convinced that every management operation must be carried out in the right place of the company’s information system.
While the ERP is at a central place in the information system, it is not the only part. The business dedicated applications are another: Whether it is to measure consumption of raw materials in a shop floor, time spent in basic operations in a warehouse, consumption of utilities such as water , electricity or the volume of information transported on an optical fiber, or the number of km traveled on a highway or in a taxi, business dedicated applications are responsible for these measurements. But if they can collect this information and possibly make it available to other applications (the IoT has obviously made this easier and immediate), they do not necessarily worry about their pricing (which often depends on the type of customer) or their billing.
There is therefore a missing link in the information system. It is the application that compiles the raw consumption data to make it suitable for the billing system. This application brick must know how to connect to the business dedicated applications to collect the raw data and store and analyze it to provide them to the ERP so that it can invoice them correctly, but also ensure their exposure to the clients so that they can trust the billing accuracy.
That’s why we created Webill.
Built upon the most advanced technologies for the management and analysis of large data sets, Webill is the missing link between the business specialized application and the ERP to transform raw consumption data into synthetic data ready for billing. Webill makes it possible to reassure the consumer / client about the accuracy of the invoices they will receive and allows the provider to focus on their analysis and not on the issues raised by the volume of data.
Feel free to contact us to discuss any issue in your invoicing process.

Share this:

Leave a Comment

Your email address will not be published.