while the following description focuses on an exemplary embodiment of a check processing system that implements aspects of the present invention as it is applied to handling checks received by a retailer at a point of sale , it is to be appreciated that the invention has broad application to the various scenarios where a vendor , service provider , credit card company , or other non - banking entity , regularly receives a high volume of checks and where the automatic processing of checks through deposit is cost efficient . there is a considerable need to expedite check processing at the site of the retailer who regularly handles a large volume of checks . there is a further need to ensure that all data is captured early in the process and correctly such that the retailer is in a position to resolve any queries that may arise soon after the receipt of the check or at a later date ( for example , if a check is lost or if a check is returned for non sufficient funds ( nsf )). in order to expedite check processing and to ensure full capture of necessary data , it is one aspect of the invention to image a check at the retailer . the image of the check is then processed within the retailer or off - site , rather than using the physical check itself . pertinent data on the check is extracted from the check image and used to validate the check , so as , for example , to create a check listing ( add list ) to accompany the bank deposit slip that is presented with the physical checks to the bank , and to reconcile or balance the register or till . during this process , it is sought to validate the value set out on a check against the expected value for the check , that is , the value included as part of the transactional data ( pos data ) entered at the point - of - sale . this allows for rapid identification of discrepancies ( exceptions ) which are reported to the retailer to facilitate their subsequent validation , if possible , through manual intervention . this aspect of the invention eliminates the manual creation of an add list and the need to encode the check , with their attending human involvement , delays , mistakes and expense . this aspect of the invention does not necessarily change the way in which a bank processes checks . according to one embodiment , the bank receives the original checks ( along with , for example , a bank deposit slip including the add list generated by an embodiment of the invention ), and handles the physical checks as normal . the electronic images may be used to expedite the processing of deposits and / or the collection processes , and / or reduce the costs of such processes . for example , the electronic images of the checks may be submitted to and / or used by the bank or other third party , for example , a check collection agency , to pursue collection . the images may be used as an image replacement document ( ird ) when a check has been mutilated or lost . of course , if preferred , the electronic images of all deposited checks may be submitted to the bank with the bank deposit slip and with ( or without ) the physical checks . numerous advantages are obtained from aspects of the invention . by processing the image of the check by ( or for ) the retailer , it is possible to automatically derive data from the check image in order to automatically create the check or add listing . this is submitted with a bank deposit slip which accompanies the checks and possibly other payment media at the time of deposit with a bank . it also is unnecessary for the retailer to use internal resources in the check reconciliation process , because point - of - sale data and check image data can be used to automatically perform check reconciliation . in addition , discrepancies can be identified earlier in the payment cycle . also , the capture of check images and related data assists in expediting and better resolving bank reconciliation issues such as checks in the deposit not listed on the add list , checks missing , and checks of discrepant value . as noted above , the image of the check can be used to derive the necessary customer and check value information if a check is returned for nsf or if mutilated or lost . this information then can be forwarded to the appropriate in - house department or third party for further proceedings . image capture also has benefits with respect to the cost of processing checks due to economies of scale . checks are currently deposited at a local bank facility . economies of scale can be achieved for the retailer if all checks are sent directly to a central point ( a check processing center ). with the invention , there is no need to involve the local bank facility . with the images captured , the central check processing center can handle checks for multiple stores within the same retail chain . this is currently risky because if a check is lost , the retailer which sent the checks to the check processing center is expected to bear the cost of the lost check . however , because banks will allow checks to be replaced if an image of the check is available , the risk of incurring costs due to checks being lost during transportation directly to the check processing center is minimized by this aspect of the invention . thus , considerable savings can be made by eliminating the institutions and steps normally required between receipt of a check by a retailer and the clearing of the check at the central check processing center . the electronic image of the check also may be used in order to expedite the process of recovering funds when a check becomes a return item . it has been found that the chance of receiving payment on a check returned for nsf decreases significantly with time , particularly after about two weeks from when the check was originally presented . through the use of imaging , the retailer can review return - item images and capture from the image the data it needs to reach faster decisions about the return items , for example , if and when to re - present and / or to pursue collection through more aggressive recovery efforts . turning now to a preferred embodiment , fig1 shows an exemplative check 100 . the check includes a numerical or courtesy amount 110 , and a legal or written amount 120 , which should correspond to the courtesy amount , both of which are usually hand written onto the check by the customer . in addition , the check includes account holder information 130 , which usually sets out at least the name of the person or persons or entity having the checking account . information 130 also can include , for example , the address and / or the telephone number of the account holder . the typical check also includes the name 140 of the financial institution where the checking account is located . checks also include a code line comprising micr data 150 , which identifies the financial institution and account number for the checking account , as well as additional information on occasion , including the check number ( not shown ). a signatory line 160 also is provided for the signature of the person authorized to draw . a date line 170 also is provided . although these code lines are usually comprised of well known micr data , they may alternatively be ocr data . the principles of the present invention are readily adaptable to that situation as well . various aspects of an embodiment of the invention now will be explained with reference to the accompanying figures as identified . as shown in fig2 , a retailer typically has positioned throughout its store ( s ) a plurality of point - of - sale ( pos ) registers where checks , 100 1 , 100 2 , 100 3 , . . . and 100 n , and other payment media may be tendered in order to pay for items and / or services purchased from the retailer . each pos register , for example 200 1 , 200 2 . . . 200 n , where n is the number of such registers typically generates data for each sale . this data can be stored within the register , or can be transmitted to a data store in a host or central computer 250 over a communications network 270 1 , 270 2 . . . 270 n , coupled with each one of the 200 n pos registers . the communications network 270 1 , 2 . . . n may include a connection over one or more of a wide area network , a lan , a storage area network , intranet or extranet connection , internet , or any other distributed processing network or system . this data , hereafter referred to as pos data , typically includes a total amount of the transaction , a list of items purchased in the transaction , a transaction identifier such as , for example , a transaction number , the monetary value of the check as observed and entered into the register by the operator ( the “ expected ” value ) and , preferably a till and / or cashier identification number . since a significant percentage of all sales are paid for using checks , most pos registers are specially equipped to handle checks . such pos registers typically include a key that is pressed by the operator of the pos register to indicate that a particular transaction is being paid for with a check . the pos register also typically includes a magnetic reader 210 ( 210 1 - 210 n ) that is used to read the micr data from a check . this data is read in order to communicate with suitable databases , where a customer &# 39 ; s check cashing history and other relevant data are stored ( whether in - house or third party ) to provide authorization for accepting the check . for the purposes of this aspect of the invention , this micr data is included in the pos data generated by each pos register which is stored at 250 . other points of entry at a retailer where checks can be received include , but are not limited to , check cashing or bill paying stations which would be similarly connected to the data store of the computer 250 . these points also generate respective check identity and expected monetary value information which is stored at the data store in host computer 250 . collectively , hereinafter , for convenience all such points of entry shall be referred to as point of sale or pos registers . for the further processing according to this aspect of the invention , the data store at computer 250 preferably includes for each check item , the micr read ( data ), the expected value , the transaction number , and the till and / or cashier number . in the exemplary embodiment , the data is grouped in the data store by till and / or cashier . still further , a particular register will prepare and store for a particular time - interval or batch , a total value of the expected amounts of the checks involved in the time interval or batch . this total value if determined will be useful at a subsequent stage in practicing aspects of the invention as seen hereinafter . a check scanner 300 ( image scanner ) is shown functionally in fig2 . it includes an imaging camera and accompanying imaging software . one such check scanning device is the source ndp check imager available from unisys corporation . the capture of the check image may occur at the point - of - sale or at a location remote from the point - of - sale , for example , in the back office of the retailer . when the check scanning occurs at the point - of - sale , the electronic image of the check may be immediately associated with the other pos data corresponding to the transaction , which is obtained at the same time , and stored together in host computer 250 . the data yielded by the check scanner includes , for example , an electronic image of the check and micr data ( 150 in fig1 ) from the check if the check scanner 300 includes a magnetic reader as is the case with the source ndp imager . ocr ( optical character recognition ) data can be obtained from the electronic image of the check at any point after the image is captured . once the electronic image of a check has been captured , it is stored ( either permanently or temporarily ) onto a suitable hard disk , tape or other suitable data storage format . the image may be stored locally on the image capture device or communicated to a central data store 350 , which may or may not be located in host computer 250 , over a network 370 1 , 370 2 . . . 370 n . . . where a network is not present , the images may be stored on a portable data storage format such as flash cards , memory sticks or the like . in the situation where the further check processing is performed in the back office or off - site , the activity at the individual registers and / or other check receiving stations remains the same . check and transaction identity information including the check expected amount and micr data are obtained at the registers and forwarded to the data store in computer 250 . in this variation , however , no check image is made at the register . the checks are collected at the register and ordered according to their receipt at the register . they are arranged with the same orientation . they are routinely collected by store personnel and brought to a secure area for further processing . they are segregated by register by suitable means , which includes transaction identification data signifying the beginning and end of the transaction activity period reflected by the accompanying check grouping . in the back room , the groups of checks are reviewed to assure they are orientated the same , and then stored until ready for further processing . when the process is to continue , the batch is submitted to a document processing machine which includes an imaging capability . again , the unisys source ndp unit is a suitable processing machine for this function . at this point in the process there are two sets of data stored for further processing . one set comprises the pos data including for each check the micr read , the expected check amount and a transaction number . the other set available includes the check images and the micr reads obtained during scanning . both sets of data are at this point , un - validated , i . e ., both are potentially suspect as to accuracy of indicated value and to completeness . the process requires that both sets of data be validated so that at the end of the validation process , the reconciliation or balancing of the individual tills as to the check media can be achieved . then , the validated checks are accepted for deposit . the pos data and scanner data have been grouped and batched by time interval and / or transaction period with each group , further identified to till and / or cashier to establish a frame of reference for subsequent reconciliation . the complementing files of data , for a given interval are now processed . in addition to the specific data identified for each check being now available , the total number of checks processed through the register ( s ) and scanner ( s ) have been recorded and these numbers are available . computer 250 as noted above is a suitable host for storing the pos and scanner data . the computer may be accessed by an operator work station 400 which includes a display monitor 410 . this display may be provided with a touch screen . the display coupled with one or more of a keyboard and mouse complete the user interface by which an operator may communicate with the check processing system . a printer 420 provides a means to generate printed documents reflecting work product of the process including the check listings or deposit slips , as preferred , exception reports , management reports , transaction and customer profile data , etc . of course , the data would not only be available at the site , but also through appropriate data links available wherever management thought it might be needed . in addition to the data storage capability , the programmed computer 250 will perform other functions during the course of check processing according to aspects of the invention . these may include some or all of the following : routing of data ; analysis ; processing ; reconciliation ; data transformation ; work flow management and report generation . one example of a suitable software application which provides some of these elements of the processing activity is the cp4000 ™ payment media management system supplied by de la rue retail payment solutions located in new jersey . the cp4000 ™ application might be installed in the host computer 250 or other suitable computer , not shown . it would be directly involved in work flow management ; routing of data ; reconciliation ; processing and report generation . prior to validation , certain pre - validation activities take place . a typical daily procedure might transpire as follows . an operator would access the system through the work station interface 400 . the operator / user would identify the till and / or the till cashier through appropriate keyboard or touch screen entry of the respective ids , as well as the transaction period for which the process is to be run . it is assumed that pos data has been recorded throughout a transaction period which would include a cashier &# 39 ; s shift or a full day &# 39 ; s shift for a register till , or some other interval , and is available . it is assumed further that the checks were not imaged at the till and are in the possession of the user . there are advantages in imaging the checks remote from the point of sale , for example in the back office . the advantage of imaging at the back office location is that from a physical work flow perspective it is closer to the bank deposit , reducing the risk of checks being mislaid before deposit and simplifying the batching of checks in predetermined quantities that may be required by the bank . the pos data for the till should include the number of checks taken in , the micr data for each check received , and the relevant transaction data including the expected check value entered at the register . the work management software , for example the cp4000 ™ package would direct a search of the pos data store of computer 250 for the associated transaction period for the identified till . the system automatically loads the till number and quantity of checks to be imaged based on the retrieved pos data and prompts the user to run the checks through the check imaging device or scanner 300 . ( if the pos data file for the transaction period does not exist at the time of the check processing , the system would prompt the user to key in the till number and quantity of checks to be imaged and then proceed to run the checks through the scanner .) the user then loads the checks for the identified till in the scanner which transports and then images the checks . all correctly imaged checks are stored in a first pocket of the source ndp device . the rejected checks are placed in a second pocket . the user then reruns the checks from the second pocket until all checks are imaged and deposited in the first pocket or the imaged check count falls within a predetermined range of the pos check count , for example 10 %. the process can now proceed to the validation stage . the physical checks are placed in a secure storage container such as the counter cache ® device available from de la rue retail payment solutions until the check processing is complete and they are to be deposited . once the pre - validation step is complete , the validation procedure can begin , although not necessarily , immediately . the economies of scale , with the consolidation of one store &# 39 ; s further check processing activities ( the further steps of validation ) with those of others in the retail chain may dictate off - site processing . fig3 a and 3b show in flow form various portions of the processing in accordance with aspects of the present invention after the pos data and check image capture steps are performed . after the check count comparison step is accomplished , if performed , and assuming the check count tallied by the scanner is within the acceptable margin of the total number of checks determined from the pos data , both sets of data for complementing intervals are routed to a suitably programmed computer where validation of the check amounts can be automatically accomplished . this routing of the data sets to the computer can be initiated by an operator through the work station 400 , or rather , preferably , triggered by an appropriate parameter through the work flow management function of the controlling software , such as the cp4000 ™. a parameter that would initiate the routing step could , for example , be the time of day and / or availability of a complete set of check image data from the scanner and the corresponding complementary set of pos data . so , for example , in that circumstance where the data is to be processed by a central processing center , and that central processing center is involved in the validation of the data received from more than one retail outlet , for the same retailer , the data can be triggered by a prearranged time after the closing of the store but before its opening the next day . the data might be processed in the early morning hours and the validated results returned to the retailer before its opening the next day in time for necessary , remaining reconciliations to take place prior to the start of business that following morning . the first step in the validation process s 100 involves the extraction of the necessary data ( check amount ) from the captured image of the check . to accomplish this , a suitable ocr ( optical character recognition ) software application is installed on a computer , for example , 250 , if the activity occurs on - site . an example of software suitable to perform the ocr function is the softcar plus brand software also available from unisys . the ocr data typically would include the check amount , i . e ., the courtesy amount 110 and legal amount 120 from the check , each a further indicator of the monetary value of a check , account holder information 130 , financial institution information 140 and possibly the signature 160 and date 170 ( s 105 ). of course , the ocr determinations of the courtesy amount and the legal amount can be deficient for various reasons including the vagaries of human behavior in writing these amounts as well as possible shortcomings attributable to the image itself the validation process continues with appropriate software on the then processing computer necessary to compare , s 110 , the identity and expected amounts data for the checks as contained in the pos data with the established identity and check value amounts obtained from the interrogation of the check image , s 105 . the image data again will include the micr line , courtesy amount and legal amount . initially the check image micr line is compared to the micr line from the pos data file . if the lines are confirmed to be the same , the image can be attributed as a copy of the check received at the point of entry to the system . then in a subsequent comparison , if the amount in the pos data file equals the courtesy amount of the check image , the check is validated . if the courtesy amount cannot be confirmed as equal to the expected amount in the pos file , but the legal amount can be , at this point the check is validated . this embodiment of the present invention provides for a comparison of the pos expected value to the courtesy value and if not successful , comparison to the legal amount . without the availability of the pos value to allow for a comparison , the probabilities that the ocr determinations of the values in fact are identical to the actual value of the transaction would be considerably less . the ability to compare as provided for by the present invention significantly enhances the probabilities of automatically validating the checks , thus enhancing the system &# 39 ; s ability to automatically reconcile transactions and registers . validated checks are stored in a validated checks file 500 for eventual return to the retailer for further processing . if neither the courtesy nor legal amount equals the pos file amount , an exception is noted and the item is then available for additional processing directed to assisting in the resolution of its exception status . towards this end , the software continues its interrogation of the data by a series of queries leading to possible eventual validation through manual intervention . these queries lead to an exception file 510 containing the various anomalies which is returned with the validated check file 500 to the retailer where the discrepancies hopefully may be resolved . for example , the process step s 110 might consider a case where a micr line from the pos data for a given check could not be matched with a micr line accompanying the check image data . in this situation , two possibilities may arise which would be treated differently . this scenario assumes that the analyzing software has at least established an amount for the check from the scanned image . the first circumstance would be where the image of the check , typically the back of the check , reveals the supporting till or cashier identification data . although not mentioned earlier , the source ndp scanner has the capability of creating images of both the front and back of the check , as do other similar scanners . at the time of the receipt of the check at the point of sale register , where this capability might need to be exploited in the check validation stage , the register would enter the till and / or cashier id number , typically on the back of the check . assuming , in fact , that this information was available , such that the image would be able to associate the established amount with a supporting till and / or cashier then the data would be stored for subsequent attribution , again through the reconciliation software , i . e ., the cp4000 ™ software package , for example , to an appropriate till or cashier thus enhancing the probabilities of reconciliation when considered together with the available micr line data . the second circumstance would be where the till and / or cashier id is not anywhere present on the check image . in this situation , an exception would be identified and highlighted in the returned work product of the validation software . upon receipt back from the validation activity , the reconciliation software , again the cp4000 ™ package , would prompt an operator at the work station 400 to look at the physical check , perhaps assisted by an image of the check , to see if the check can be associated with a particular till or cashier . if the work station operator is successful , he / she would accordingly attribute the check to the appropriately stored till file accessible through the reconciliation software . if the work station operator can not resolve the issue , he / she enters it into the system through the reconciliation software as an un - reconciled item to be dealt with as the retailer &# 39 ; s procedures direct . a second scenario which the validation software is adapted to resolve involves the circumstance where the micr line obtained through the check scanning cannot be matched to a pos micr line , and further , the validation software was unable to establish an amount for the check . again , an exception report would be issued in this circumstance and made available to the retailer with the return of the validation and exception files , with a prompt to the work station operator to look at the physical check . again the image could be made available at the work station to facilitate the subsequent investigation . if the amount and till identification can be established , the work station would enter this data and process it through the reconciliation software . if the amount could be established but not the till , then the operator would enter the event as an unreconciled item . if , however , the till could be established but not the amount from the operator &# 39 ; s observation of the check , the operator of the work station would access the till data file and enter a note that the check writer be contacted to resolve the discrepancy . yet another scenario that might be encountered during the validation process involves the situation where micr data lines can be matched between the pos data and the scanned data , however , the ocr software was unable to establish an amount from the check image . again , as an exception , upon review by the work station operator , he / she would be prompted to once again look at the physical check to see if in fact an amount could be established . if so , the operator enters the amount through the interface and the reconciliation software seeks appropriate disposition by comparing the keyed amount to the pos data file for the corresponding micr line . if in fact , a review of the physical check still leaves the amount in question , once again the operator would prompt the system to contact the check writer to resolve the amount . and yet another possible exception which might arise would involve the circumstance where the pos micr data is unmatched with the micr data from the scanned image . this event would be highlighted for the involved check , once again in the exception report accompanying the returned validation file ( s ) to be further analyzed in accordance with the reconciliation process inherent in the reconciliation software such as the cp4000 ™. as noted , the validated check file 500 and an exception file 510 are prepared and transmitted back to the sending site . once at the site , the file data is imported into the reconciliation software system such as included in the cp4000 ™ system . the cp4000 ™ system extracts the data and places check items in each till record for balancing and prepares the add list through printer 420 , for example , to accompany a bank deposit slip . the cp4000 ™ system can direct the printer to print the add listing , check exception report and other pertinent information extracted from the pos and image scan data bases as required . see fig3 b . once the check data has been captured and quality assured , it can be further processed to provide added value to the retailer . as noted above , some of the results of the process of the reconcilement of the pos check data and the check image data is the balancing of the till register ; the development of an add list to accompany the bank deposit slip and physical bundle of checks s 210 ; and the creation of an exception report s 220 which highlights for example the discrepancies between the pos and check image data as relates to missing entries in either data base to facilitate validation and subsequent reconciliation ; and image availability for transfer to third parties , s 230 , s 240 . by automatically generating the add list to accompany the deposit slip , rather than having this done manually , a significant time saving can be made . automatic generation of the add list also limits the possibility of human error . the bank deposit information may be handled in isolation to the banking data for other media ( bills , coins , etc .) or in combination with that payment media . the add list would include at least the check amount of each check and the checks would be sequentially listed thereon in the order they appear in the physical stack , which meets the standard bank check deposit requirements . obviously the handling of checks according to the processes described herein generates a significant amount of valuable data , all or some of which may be of use to the retailer . it is therefore possible to generate reports ( step s 220 ) both automatically and on request . in addition to the exception reports noted above , typically the reports will outline various aspects of check activity such as number of checks passed within a period , value of checks passed , number of mis - tendered checks , number of checks for re - presentment , etc . in addition to this reporting of check activity it also is possible to use information present on the check for other non - payment related purposes . for example many checks carry a significant amount of data about the payer . for example the payer &# 39 ; s name , address , bank details , zip or postcode , and in some instances their phone number . such information can be extracted from the check and then combined with pos data to build up a profile of the customer . for example , pos data not only contains information on the cost of goods but also details of the goods purchased . the invention therefore makes it possible to provide a link between the check payer and their purchases in a similar manner to loyalty card schemes . if the check also carried information such as the customer &# 39 ; s home or business address , the retailer can send the customer details of special offers or discount coupons based upon the customer &# 39 ; s past purchase history . similar to the handling of the pos and check image information by the off - site center , the check image and its associated pos data could be transmitted to the retailer &# 39 ; s home office ( ho ) ( step s 240 ), which would perform the processing described above . further , the home office can have ready access to the data on a near real time basis . together with information involving other forms of payment media , for example notes and coin , corporate decisions can be better made concerning optimizing safe values for individual stores and more broadly so as to enable better investment strategies as to surpluses . still further , the home office can identify on a relative basis , trouble areas so that losses can be investigated thoroughly and quickly . check images can be archived , s 270 , to support and facilitate check re - presentment and eventually , if necessary , nsf collections . also the archived checks are available to provide check reconstruction if the physical check is lost or mutilated . various alternative embodiments of the elements of the invention or the invention as a whole may be employed without departing from the broad scope of the invention . additional features may be added again without diminishing the breadth of the invention heretofore described . while the exemplary embodiment of the invention elaborated on the application of its principles to personal check media , the invention must be seen to have broader application so as to include other forms of payment media within its scope , for example money orders , travelers checks and other media where the transaction amount entered at the pos may differ from the value of the payment media exchanged for the goods or services . while the invention has been described with reference to preferred embodiments thereof , it is to be understood that the invention is not limited to the preferred embodiments or constructions . to the contrary , the invention is intended to cover various modifications and equivalent arrangements . in addition , while the various elements of the preferred embodiments are shown in various combinations and configurations , which are exemplary , other combinations and configurations , including more , less or only a single element , are also within the spirit and scope of the invention .