Indexing Tables in Kofax-Based Environments

We recently had a customer who needed to migrate off of an aging and highly customized Capture/indexing/workflow one-off solution. At the center of many of their form types in this system was a repeatable field collection object that functioned much like how you would expect a .NET DataTable control to function – values could be added horizontally to the current “row”, and at the end of it you could hit enter and a new “row” would be added. As you moved through, you also had the ability to validate the line item as a whole. In other words, nothing too out-of-the-ordinary.

Unfortunately, this stood out as a red flag for both myself and my coworker when we first saw it, since we were migrating the client to Kofax Capture. There’s nothing inherently wrong with Kofax’s flagship product, in fact it is an excellent tool for getting content where it needs to be, often in record time. One thing it doesn’t do well out-of-the-box, however, is table fields. Defining one looks normal enough, but when you actually get the chance to index them, each column ends up being a standard index field. Needless to say, turning the table 90 degrees counter-clockwise and forcing keyers to manually delimit values is not an ideal experience, especially when 99% of your form is tables that need to be indexed. Continue reading

Exporting Records Using KTM Medical Claims Add-on & Kofax Export Connector

Kofax provides an add-on pack for their Transformation Modules product to handle CMS-1500 (formerly HCFA) and CMS-1450 (alternatively, UB-04) medical claims forms called the KTM Medical Claims Add-on package. Related to this package is the Kofax Export Connector for Medical Claims. This Export Connector allows for the data captured off of said forms to be formatted in the HIPAA-compliant EDI/ASC X12 837 formats (to be exact, 837 Professional for the CMS1500 and 837 Institutional for the UB04).

Continue reading

Kofax 9.x – They’ve finally done it… Almost

I have been working with the Kofax Capture product for over ten years now. To prove that, let me tell you the configuration on one of my first installs. I remember setting up a Bell and Howell 3338 scanner (you know, the one that required a cherry picker to get out of the box and on to the desk) with the Kofax KF board and Kofax Capture version 2.x. Ah yes, I look back fondly on the old days of deploying a scanner with the Kofax card and software. I know it has been out for a while now, but I recently started working with version 9 of Kofax Capture and I am pleased to say that they have finally addressed some of the Kofax gotchas that have been plaguing us for years.

For starters, they made client deployment 100% easier by creating the MSI package. I can’t tell you how many conversation I have had with client admins that go like this:

Me: No we don’t have a SMS or other type deployment package you can use, but you can make your own.

Client Admin: (Furrows brow) Huh?

I will be much happier when those conversations are a little less embarrassing. Now the workstations can be deployed using Microsoft SMS, Group Policy, IBM Tivoli, Symantec Altiris, HP Openview, or whatever deployment suite you use. Kofax has only tested SMS, but Continue reading

Document Scanning and Some Best Practices

There are a number of variables to consider before determining the document capture best practices for an organization. The first question I would ask is: Is this a departmental/workgroup or enterprise scanning solution? The second question I would ask is:  Is this an intelligent capture solution? The definition of ‘intelligent capture’ I use is: the ability to automatically separate and extract data from documents. Those variables should always be in the forefront of your mind when designing the capture solution. Setting those variables aside, let’s think about why we are even scanning in the first place. The goal of any capture solution should be to save money, where that money is saved varies from organization to organization but the goal is the same. Scanning documents has a cost inherently associated with it; the goal of any solution design should be to walk that line between the cost associated with input and the savings associated with retrieval/Business Process and come up on the winning side. There are many things that could be considered a blanket ‘best practice’ techniques for document capture but I believe the end goal (where you see the savings) determines the priority of those best practices. Continue reading

The Importance of ECM Training – Kofax, ILINX, Oracle

While conducting a Kofax training class, I asked the students how their company uses Kofax Capture v8.  They told me that their system consists of 20+ servers and multiple installations of Kofax Capture.  This was very surprising to me.  My students told me that the previous administrator never received training on the software, and that his manager told him to “just make the system work”, rather than sending him to training.  The administrator was able to “make the system work”, but did so in a way that was inefficient and did not take advantage of the full power of the software.  If the administrator had received proper training on the software, he would have realized that, at the most, he would have only needed one server for Kofax and one server for his remote sites.  The lack of training proved to be costly to his company.

Never underestimate the importance of training.  A complete list of available training courses at ImageSource University can be found by visting the Training page.

Chris Sturiale
Training Manager
ImageSource, Inc.

Kofax KTM for Invoice Processing

KTM for Invoice Processing.

The Kofax Transformation Modules is an excellent addition to the Kofax Capture family when processing invoices. The product is able to “Read” the major invoice values from the invoice image accurately and with confidence. It has the ability to “Learn” where on the invoice image the values are located so its accuracy can be increased over time.

The major invoice values that KTM can read and “Learn” out of the box are:
Invoice Number
Invoice Date
Order Number
Subtotal
Tax
Shipping/Freight
Handling
Total

The accuracy out of the box is very low since the software needs to be “Trained” on sample invoices to learn where the values are located. It does this by layout classification so it can handle different vendor’s invoices and learn to accurately read the values.

In addition, there are lots of options for the builder of the Project to help the extraction of the values. These options include objects like Locators, Formatting, Key Word matching, and Validation. Through a combination of these options, just about any invoice can be read and processed with little user correction required.

However, it takes a lot of work to “tune” the Locators and Key Word matching to get the initial accuracy to as high a rate as possible. This is more an art then a science and therefore requires a person with intimate knowledge of KTM and all it’s abilities. Also, knowledge of basic script programming is required since there are things that cannot be done by KTM otherwise. ImageSource can provide such people that have the knowledge and experience to “tune” KTM to be as accurate as can be done with the current OCR technology.

Chris Hillenburg
Sr. Systems Engineer
ImageSource, Inc.