001: ON THE DESIGN OF A HYBRID FORMS / REMITTANCE
PROCESSING SYSTEM

Forms and remittance processing have traditionally been two separate areas in the imaging industry. The companies that handle forms processing have not been successful at remittance processing and vice-versa.

This separation of the two areas has been due to many reasons:

	The lack of availability of scanners and transports that can handle both multi-sized forms and checks adequately
	The lack of knowledge/expertise by the forms vendor community of the deep aspects of the check processing world, and the same lack of knowledge/expertise of the check vendor community in the intimate aspects of the forms processing systems
	This absence of expertise on both ends of the spectrum have caused little in the way of customer requirements combining both forms and checks to be processed together in one homogeneous system.
	Over the years, the vendor community in each area has developed its own systems and its own ways to automate the documents using their own appropriate methods. For instance, in the remittance world, all processing and automation are centered around the coupon exhibiting an OCR scan line rules. Similarly, in the forms processing world, the check is considered a "foreign" item, and the concepts of transaction and transaction balancing do not exist.

Since the mid nineties, this phenomenon has been changing. In fact, more and more users have been issuing requirements combining forms and checks under the hegemony of one system. This has been particularly true in the state and local tax marketplace.

Armed with this knowledge, and capitalizing on our tradition of excellence in image-based system and our expertise in both the check as well as the form processing marketplaces, Fairfax Imaging has been one of the early developers of an integrated forms and checks processing system using imaging.

We started the development of our Quick Modules product in the mid nineties. Quick Modules is our workflow based totally automated check and forms processing solution particularly suited for the high-end wholesale and wholetail marketplaces.

Our approach to this integration has always been simple, and it rests on the premise that a check is nothing but another form type in a batch of documents. The check is also a distinguished form type. Its identification is quite simple due to the universal MICR line present on every check. Also, the data can be captured off a check using similar technology as the data off forms. The choice of data capture technology is not the most important element in check processing. What is more important is what to do with the check data once captured. The basic premise is to balance those transactions containing checks in addition to capturing the rest of the data off the forms. The decision whether to balance and cashier the checks first, or capture the data off the forms first is left up to the user. Although, it is our experience that the majority of users prefer to balance their transactions and cashier their checks first ("deposit the money immediately at point of entry"), and subsequently extract the remaining data (be it reconciliation data or other types of data).

Armed with these facts, when we started out laying out the foundations of our hybrid form and check processing product, we decided that it must have the following ingredients at a minimum:

	It must be modular, scaleable, and flexible with the ability to add modules as needed to meet extra capacity (using the bookshelf integration principle);
	It must have true workflow (and not just job flow or porcess flow) in order to be able route, schedule, and prioritize batches;
	It must be able to identify and track transaction boundaries (based on the presence of the check(s) within each transaction within each batch;
	It must be able to perform automatic data capture off all documents within the batch, be it check or form. The application of the appropriate technology to perform the data capture to the appropriate form type was immaterial;
	It must offer a batch review function where all batch integrity review and repair functions can be performed;
	It must offer transaction balancing where the amount to be balanced off the form is lifted from the form solely for the purpose of balancing the transaction;
	It must offer check encoding and endorsing;
	It must write all the extracted data to an ODBC database;
	It must offer the traditional forms processing functions such as key entry from image, character correction an interface to legacy system.

As such, the following design was conceived. The design as shown below is still the foundation for our system, and the building block for many installations nationwide.