Is Invoice processing a vertical problem with vertical solutions?

No. Invoice processing does have verticals, but is far from being one. For a data capture problem to be vertical it must have the same document type, same business process (business rules, fields extracted, and result usage), and have a repeatable solution for any organization with the same problem.

Most vendors and end-users consider invoice processing to be vertical because it solves the first and least important part of this definition, document type. The proof is clear when you read the industry articles, vendor marketing materials, and canned demos that lump invoices into one category (“invoice processing”). This assumption has lead companies astray before solution acquisition and after. The accounting software industry has understood the complexity of invoice verticals for a long time, but the relationship between data capture and accounting software today goes no deeper than integrated exports.

Data capture allows me to introduce you to accounting software. It is possible to take an “off-the-shelf” invoice processing solution and have it work on a class of common invoices, which I refer to as “commercial invoices.” They take up a chunk of volume, but some effort is required to get it to work for the population at large.

I identify four clear steps to determining where your invoice processing dilemma lies in the “invoice processing” solution space: first determine your objective invoice type(s), determine your concept of a document(s), determine how you separate invoices, and, finally, determine the use of data capture results.

In the last five years I have grouped invoices into the following seven objective types sorted by automation complexity:

1. Commercial Invoices
2. Transportation and Logistics
3. End-user Telecomm/Utility
4. Legal and Services
5. Aggregate/Manufacturing
6. B2B Telecomm/Utility
7. Healthcare Billing

Each type has its own series of unique elements and processes—with some obvious overlap. Thankfully, the market understands the difference between a commercial invoice and a HCFA say, but don’t seem to understand the difference between commercial invoices and telecommunication bills. The difference between one type and another could be as simple as different fields collected, but is usually much more than that. Reconciliation processes, different supporting documents, and different document structures make the difference between the types very clear.

Once an organization understands what vertical invoice type(s) they are dealing with, the next step is to define what they consider a complete document, its structure. I was surprised initially to find out that there are nearly as many definitions of document structure as there are companies trying to solve this problem. If you look at the invoices objectively you have one obvious choice, a document structure is page one to N of a single invoice, all data across pages compile to a complete invoice record. When you start adding checks, POs, and cover pages to the mix the document structure concept starts to vary widely.

Once the internal document structure is determined, the organization can address how a batch of documents is separated. This is a big deal for invoices and can have dramatic effects on your setup as it relates precisely to the number of definitions or templates the solution will contain. Do you wish to separate incoming invoices by vendor? If so, then you will need a new definition or template per vendor and their supporting documents. Do you wish to separate incoming invoices by time period and process all as type “invoice”? Then you need only one definition and you batch a set of invoices by duration of time for processing.

I bet at this point you are saying the latter option seems the best, and yes, this would be the first impression, but consider this: The time it takes to create a template or definition per vendor is equivalent or less than the time it takes to fine-tune a single definition to accommodate all vendors. This is the norm not the rule. The reason this is typically true is because in most solutions when you modify something to work on one vendor invoice you break it for a another vendor invoice adding the additional time for regression testing, and more rounds of fine-tuning. This is why organizations that successfully process all incoming invoices as type “invoice” have in reality 3 to 5 invoice definitions to handle the entire population. The concept being that the first definition gets the low-hanging fruit (the 60-80% of the volume that does not vary much) while definitions 2 through 5 deal with sub-classes of variation in the invoices that would interfere with the others.

Now, there is one last minimal requirement to identifying the nature of your invoices, and that is to determine what your desired downstream business process is. If you don’t exactly identify what you want to do with the data you will likely fall into the trap of the solution deciding for you. At which point you will spend additional time fitting a square peg into a round hole. Consider for example export format and how it should look, down to spacing, linking, even storing of line-items. In a CSV flat file should each line item be its own value, or should there be a single value for the entire collection of line-items? Also consider if you need the data capture system to perform the first steps in reconciliation or if this can be done downstream, are there benefits to combining them? It will be the seemingly trivial requirement that will be your highest professional services cost.

If you’re lost, you are not yet ready to implement an invoice processing solution.

The above steps allow an organization to identify their population of invoices exact vertical, and by doing so are now ready to approach solution vendors for demonstrations. While there are many other important questions to consider such as database lookups, exception handling, and quality assurance steps, these are not unique to “invoice processing” and to be answered during your vendor selection, and a later article.

Chris Riley (chris.riley@livinganalytics.com) is founder of Living@nalyitcs (www.livinganalytics.com) where he uses his in-depth knowledge of data capture technologies to advise clients and proselytize the value of these tools.