WO2005017791A1

WO2005017791A1 - Improvements in cash accounting

Info

Publication number: WO2005017791A1
Application number: PCT/GB2004/002420
Authority: WO
Inventors: Christopher Lare; Matthew Fortunka
Original assignee: Tellermate Group Limited
Priority date: 2003-08-08
Filing date: 2004-06-08
Publication date: 2005-02-24
Also published as: GB2404768A; GB0318689D0

Abstract

Method and apparatus for reconciling an actual cash holding with an expected cash holding by comparing cash actually held, represented as CASH data, with cash expected to be held, derived from POS data, comprising capturing and caching items of CASH data, capturing and caching items of POS data, pairing a cached item of CASH data with a cached item of POS data, comparing the CASH data and POS data of each pair of items to determine a match or mismatch, logging the result of each comparison, removing the paired items of CASH data and POS data from cache and at intervals, removing from cache and logging any non-paired items of CASH data or POS data.

Description

Improvements in cash accounting

This invention relates to cash accounting and in particular to the reconciling of real and predicted cash values in cash registers after transactions.

It is standard practice for any operation that handles cash transactions to periodically compare the real cash value held in a cash register with the cash value predicted to be present in the cash register after a series of cash transactions. This is done so that any discrepancy between the two cash values, for example due to cash register operator error or fraud, may be noticed at an early stage and corrected. The act of comparing the real and predicted cash values in this context is known as cash reconciliation.

The cash value held in a cash register may be manually counted during a period of inactivity between cash transactions but this method is time consuming, labour intensive and open to human counting errors. An improved method and apparatus of obtaining the value of cash in a cash register is described in the Applicant's co-pending European patent application EP 0724242, which describes a cash register comprising weighing means arranged to take weight readings from the cash compartments of the cash register. The weight readings of each compartment may then be converted to a cash value by a processing unit so that the total cash value contained in the register may be obtained without manual intervention.

A further apparatus for obtaining the value of cash in a cash register is described in US 4,522,275 to Anderson, comprising a plurality of weighing means connected to a plurality of coin compartments and generating a signal sent to a totaliser which computes and displays the monetary value in each coin compartment.

Cash registers exemplified by EP 0724242 that can determine the value of their contents are hereinafter referred to as intelligent cash registers. It is to be noted that cash tendered as part of a sale is not restricted to notes and coins and may comprise, as an example, any combination of notes, coins, cheques, vouchers and credit notes.

Information relating to the amount tendered and the type of payment made is usually logged by point-of-sale (POS) terminals as part of the POS data for each transaction, and/or it may be transmitted for storage on a central server for later processing. The predicted cash value is then ascertained from the starting cash value set in each till at the start of the shift or day, and modified by the relevant POS data for each successive transaction. Usually the POS terminal records details of the sale which triggers a cash transaction. In addition to the basic set of cash transaction details such as date and time of sale, sale amount and cash tendered, other variables such as total cash collected by money type, cashier identification name or number for each transaction, sales by type, money collected by type, sales recorded by type, total recorded, total collected and transaction number may also be recorded to assist in the reconciliation or other analytical procedures to be carried out on the cash transactions. As with the CASH data, POS data may also be transmitted from the POS terminal and saved on a central server for later processing.

Although POS data items can be recorded on a cash register roll upon which is printed a list of all transactions since the last reconciliation, typically at the start of the shift or at the start of the day and in the order in which the transactions occurred, POS data information is nowadays stored in the POS terminal for electronic retrieval at the end of a shift. As mentioned before, the reconciliation process is time consuming and as a result reconciliation is often left to the end of an operator's shift or undertaken at the end of a day. For operations where a large volume of cash transactions take place in a short time period, for example in a retail food outlet during meal times, waiting until the end of an operator's shift or waiting until the end of the busy meal period may allow a significant error, or a significant level of fraud, to occur before it is noticed - by which time it may be too late to apply corrective measures.

Delay is all the more damaging where discrepancies have a cumulative effect and it becomes impossible to identify where the mismatch between the actual cash holding and the expected cash holding occurred. It is therefore evident that control of the cash holding is easier to achieve if the cash in the cash drawer is reconciled at more frequent intervals, perhaps between every transaction. With known, essentially manual, methods of reconciliation, it is not practical to achieve this frequency of reconciliation in a commercial environment.

Purely by way of example, specimen formats of CASH and POS data items are provided in respectively Table 1 and Table 2 below which may be considered to form part of a database. It is to be appreciated that additional parts of any database within which these data items are stored may contain additional information relating to the relationship between data items, and these are not shown in Tables 1 and 2. Where appropriate, an example of the size of the data item is also shown, although the size of each data item is not strictly defined as it will depend upon the needs of the operator. In addition, some of the items shown in Table 1 and Table 2 are optional but may assist the overall operation.

POS data may be generated at any user-specified interval, for example, after each individual cash transaction at the POS terminal. Alternatively, a partial reconciliation whereby only the change in cash value is compared to the change in predicted value since the last reconciliation was taken may be carried out.

For ease of reference, the set of POS data captured by the POS terminal and relevant to reconciliation will henceforth be referred to as an item of POS data, and the set of cash data captured by an intelligent cash register relevant to reconciliation will henceforth be referred to as an item of CASH data. It is noted that capture of POS data may not involve a direct connection to the POS terminal itself and other methods described below, such as capturing POS receipt information or using a data transfer from a POS database server, are equally suitable.

Table 1 - Specimen format of CASH data items

Table 2 - Specimen format of POS data items

In Table 2 above, the term 'cash lift' relates to the practice of removing excess cash from a cash drawer during a shift for additional security.

It would be possible to manually reconcile the POS and CASH data items either as they are generated or at some time later such as at the end of a cashier shift. In practice, faster and more efficient reconciliation may be achieved through computerised techniques whereby cash data from a suitable intelligent cash register is reconciled automatically with captured POS data. A full reconciliation of the whole contents of the cash register compared to the instantaneous predicted cash value derived from the POS data may be undertaken at any user-specified interval, for example, after each individual cash transaction. Alternatively, a partial reconciliation whereby only the change in cash value is compared to the change in predicted value since the last reconciliation was taken may be carried out.

In the above computerised reconciliation model, there is reliance upon the simple assumption that for every piece of POS data there is a matching piece of CASH data available for reconciliation purposes and that the two data entries occur in order. When this correlation holds true the above computerised reconciliation model works effectively.

However, in practice there are many circumstances where the correlation breaks down and the simple model above will not work. For example, in a busy store where one cash transaction is the result of two POS transactions (e.g. when a cashier leaves the cash drawer open between transactions), or in a business model where there may be a significant delay between POS and CASH data capture (e.g. a drive-through food outlet) related POS and CASH data items may become out of step.

Additionally, when an additional cash activity occurs, such as a manual opening of an intelligent cash till drawer to issue a cash correction to a customer, or initiating a cash lift or issuing change replacement, or producing a management or void report associated with the POS terminal, any subsequent reconciliation will fail until the POS and CASH data recording system is reset or additional data of another type (typically additional CASH or POS data to reacquire data correlation) is generated. However, it is unrealistic to rely on an additional piece of data being generated by happenstance that will realign the out of step POS and CASH data streams due to the unmatched piece of POS or CASH data.

For example, in the above case when an intelligent cash till drawer is manually opened independently of a POS transaction when one POS operator 'buys' change from another POS operator, CASH data will be generated without corresponding POS data being generated: intelligent cash registers are commonly set up to generate a cash value reading after each drawer closure. However, as this CASH data is not related to any piece of POS data it will therefore be compared with the next piece of POS data captured from the POS activity. A reconciliation based upon this CASH data and the next POS data will not be successful and lead to an erroneous signal that reconciliation has failed. This effect would not allow such an automated reconciliation system to function correctly.

In the above example, the out of step behaviour will continue until the system is reset, thus re-synchronising the CASH and POS data sources, or possibly when a POS data transaction (such as a manager report) is generated that is not accompanied by a piece of CASH data. The converse is also true when POS data is generated without accompanying CASH data being generated.

The perpetuation of the out of step CASH and POS data items may lead to a significant number of incorrectly matched data CASH and POS data items. If an unmatched CASH or POS data item is generated early in the day and the reconciliation is only carried out at the end of the day, this involves a significantly increased workload to exclude unmatched POS or CASH data items and manually pair up matching POS and CASH data items. This procedure is time consuming and represents a significant time commitment for the responsible staff member as well as rendering the system ineffective for one of its main objectives of detecting a potential problem quickly.

What is required therefore is a method of reconciling POS and CASH data which takes into account out of step POS and CASH data so that erroneous findings of failed reconciliation are avoided. It is with a view to solving the above problems that we provide, in a cash- handling point of sale (POS) environment, a method of reconciling an actual cash holding with an expected cash holding by comparing cash actually held, represented as CASH data, with cash expected to be held, derived from POS data, the method comprising capturing and storing items of CASH data, capturing and storing items of POS data, pairing a stored item of CASH data with a stored item of POS data, comparing the CASH data and POS data of each pair of items to determine a match or mismatch, logging the result of each comparison, removing the paired items of CASH data and POS data from cache and, at intervals, removing from cache and logging any non- paired items of CASH data or POS data.

Further optional features to the invention in the above embodiments are described in the appended claims.

Although the method described in the above embodiments provide a realistic method of recovery from mismatched data, it will not remove short periods of unsynchronised data as it only uses the most recent POS and CASH data items for pairing. Furthermore, as it is common for POS terminals to provide POS data in bursts wherein several individual POS data items are combined into a batch of data, this method will not be able to match data items within the batch. It is also found to be common for the POS terminal operator to cause a delay in the transmitting of CASH or POS data, for example when the operator has to deal with an unexpected query during a transaction after CASH data has been processed but the POS data has not been processed yet. Another important problem not addressed is one wherein the order of related CASH and POS data items are processed out of sequence.

A further problem not previously appreciated which causes difficulties for reconciliation methods occurs when a POS operator accidentally enters erroneous transaction data, or where some other clearly defined action such as buying change takes place. This type of transaction where a constant CASH data value yields several POS data items causes difficulties to the aforementioned embodiments as several sets of POS data items may all legitimately relate to one CASH data or set of CASH data items. Examples of this previously unappreciated problem follow: Example 1

A POS terminal operator receives a request to provide coins in exchange for a banknote. The operator opens the drawer of the intelligent cash register and removes a sum of cash in form of coins and closes the drawer. The exchange of coins for banknote then takes place, and the operator re-opens the cash drawer to deposit the banknote. Since the cash drawer has been opened and closed twice, two sets of CASH data will have been generated but there will not be any corresponding POS data generated; yet, it is clear that the overall balance is still correct. The problem here is for the method of reconciliation to recognise this combination of transaction data items and allow this combination as being legitimate.

Example 2

During periods of intense transaction activity, more than one POS terminal operator may be using the same cash drawer at the same time for CASH transactions that result from multiple POS transactions. The total cash data is likely to correspond to the sum of the individual POS transactions, but the order in which the POS and CASH data are processed may be different. The problem here is for the method of reconciliation to recognise this permutation of transaction data items and allow this permutation as being legitimate.

Other scenarios are possible whereby recognition of both a combination of data items in addition to different permutations of these combinations is required.

To solve the above problems there is provided a further embodiment of the invention wherein, in a cash-handling point of sale (POS) environment, a method of reconciling an actual cash holding with an expected cash holding by comparing cash actually held, represented as CASH data, with cash expected to be held, derived from POS data, comprises capturing and caching items of CASH data in a stack of CASH data items, capturing and caching items of POS data in a stack of POS data items, seeking in one stack a match for an item of data from the other stack, in the event of a match being found between items from the different stacks, pairing the matching items of CASH data and POS data; and reconciling the CASH data and POS data of the matched pair of items.

Further optional features to the second embodiment of the invention are described in the appended claims.

This embodiment of the invention solves the above problems by taking into account not only the most recent CASH and POS data items and also allows consideration of whole batches of data items. Unexpected delays in the processing of data items for reconciliation, for example if the POS terminal operator is delayed mid-transaction after one of the data items has already been processed, will not result in miscalculation.

The applicant has found that the performance of the invention is significantly enhanced in dealing with these circumstances by employing deductive logic, generally referred to as fuzzy logic, as explained in detail below. The implementation of fuzzy logic improves the invention by allowing combinations of transaction data to be detected as being genuine, and hence, reconcilable whereas previous methods would have produced a failed reconciliation. This iterative process is employed when it is clear that a number of combinations, or permutations, of CASH and POS data items are reconcilable.

In order that the invention may be more readily understood, some embodiments in accordance therewith will now be described, by way of example, with reference to the accompanying drawings, in which:- Figure 1 is a hardware diagram showing a representative network which comprises intelligent cash registers and related computer-related hardware in accordance with the claimed invention;

Figure 2 is a flow diagram of the actions followed during a simple reconciliation of a single cash transaction;

Figure 3 is a flow diagram of the procedures employed in a method according to a first embodiment of the invention comprising time resynchronisation;

Figures 4 and 5 depict how time resynchronisation affects CASH and POS data according to the method shown in Figure 3;

Figure 6 is a flow diagram of the procedures employed according to a second embodiment of the invention comprising stacked data management;

Figure 7 is a flow diagram of the procedures employed in a third embodiment of the invention comprising fuzzy logic; and

Figure 8 is a detailed flow diagram of the iterative matching process shown in Figure 7.

In Figure 1 there is shown a representative network corresponding to the invention comprising an intelligent cash drawer 2 able to generate CASH data, a point of sale (POS) terminal 3, a POS display screen 4 and a POS printer 5 to typically print customer and management receipts. This group of components is repeated at each checkout terminal employed in the retail establishment. Each checkout terminal is connected in a network arrangement via standard networking apparatus 6, e.g. RS-232 interface or Ethernet, with an intelligent accounting server (IAS) 7. Provided with the IAS are peripherals 8 comprising display means and input means to control and monitor IAS and network functions. Connected in turn to the IAS is a database server 9 which has amongst its functions a role as a repository, or cache, for CASH and POS data. As with the IAS 7, there are peripherals 10 comprising display means and input means for control and monitoring of the database server 9. Also connected to the IAS 7 are alerting means 11 , for example a lamp and display screen, for alerting a supervisor when an abnormal state is detected from the IAS 7. Connected to the POS printers 5 is a receipt capture unit 12 which captures and provides a store of POS data as shown on customer receipts and management printouts available from each POS terminal 5. Should a direct link between each POS terminal 5 and the database server 9 be available, the receipt capture unit 12 may be omitted. As between the components of each checkout terminal, the other components of the network shown in Figure 1 are also connected by standard networking apparatus and protocols, for example RS-232, TCP/IP and Ethernet.

In use, the intelligent cash drawers 2 will be responsible for initiating CASH data transfer and the IAS 7 will simply receive the CASH data and transfer it to the database server 9 for storing, or caching, before processing either on demand or at a later time. POS data will be generated by the POS terminals 5. The POS data may be captured by the receipt capture unit 12 when intercepting receipt print-out data which is then decoded subsequently, or POS data may be obtained by interrogating the database server 9 which normally contains a log of all transaction data. Cached data on the database server 9 may then be transmitted. Exchange of CASH and POS data between the intelligent cash drawers 2, the POS terminals and the IAS 7 may be initiated by any party.

The data transmitted by the intelligent cash drawers 2 and the POS terminals may be streamed individually or they may be streamed in batches. As CASH and POS data items are stored, or cached, in memory, the CASH and POS data items may be stored in the form of stacks of CASH and POS data. Alternatively, both CASH and POS data items may be stored in one contiguous communal stack by common multiplexing techniques, and individual data items retrieved from this communal stack by similarly common de-multiplexing techniques. Henceforth, references to CASH or POS data streams during transmission may be considered as references to CASH or POS data stacks once such data has been stored.

The IAS 7 conducts reconciliation actions between CASH and POS data items using the CASH and POS data sent from the intelligent cash drawers 2, the POS terminals 3 and/or from the database store 9. When an anomaly is detected a supervisor may be alerted via alerting means 11 , and the nature and location of the anomaly is displayed for the supervisor to provide attention.

In a first method, as represented by the flow diagram of Figure 2, a single transaction 20 is made at a cash register which in turn generates a single item of POS data 22 and a single item of CASH data 24. As shown in Figure 2, the stimulus for producing the CASH data 24 is the entering of cash or removal of cash from the cash drawer of an intelligent cash register, but may also be triggered by the action of opening or closing the cash drawer 2 (not shown in Figure 2). Reconciliation occurs when the instantaneous POS predicted cash value calculated from a running total of POS transaction data 2 and the actual cash register cash value obtained at 3 are compared at operation 26. If the two values are equal, or within a margin of error set by the supervisor, the transaction 20 has been correctly reconciled at 28 and the cash register is ready to continue with the next transaction. Should the reconciliation 26 produce an anomalous reading 30 between the instantaneous POS predicted cash value and the measured CASH data value, an alert signal may be sent via alerting means 11 (not shown in Figure 2) to alert a supervisor and corrective measures may then be taken to determine why the transaction does not balance and/or correct the imbalance.

In use, a failed reconciliation may trigger a signal to a supervisor to take corrective measures by temporarily suspending the relevant cash register and undertaking a detailed examination of the transaction covered by the reconciliation.

In a second method as represented by the flow diagram shown in Figure 3, the single cash transaction of Figure 2 is replaced by a series of transactions which in turn generates a stream of CASH data and a stream of POS data. As with the previous method, a single transaction generates a single item of CASH data and a single item of POS data. In Figure 3 the method provides for reconciliation of a single transaction 34 out of the series of transactions, and the single transaction 34 generates a single CASH data item 36 and a single POS data item 38. In Figure 3, when the CASH data 36 is added to a CASH data stream (not shown), a check step is carried out at 40 to determine whether there is POS data 38 in the POS data stream (also not shown) with which to reconcile the CASH data 36. If relevant POS data is not available for reconciliation with the CASH data, a check 42 is then made to determine whether a predetermined time limit set by the supervisor has been reached. If the time limit has not been reached, the check step of 40 is re-entered. If the time limit has been reached, the CASH data 36 is removed from further reconciliation at 44, but the CASH data itself is logged on the database server.

If the check performed at 40 concludes that there is relevant POS data in the POS data stream with which to reconcile the CASH data 36 in the CASH stream (not shown), the CASH data item 36 and relevant POS data item are compared at 46 in a similar procedure as explained in Figure 2 above, and the result of the comparison 46 is either a correct reconciliation established at 48 or an alert signal raised at 50. In either case, the compared data items are removed from further consideration but logged for further analysis.

A similar process is undertaken when a POS data item 38 is added to the POS data stream (not shown) first. In this case, the check state 52 is entered to determine whether there is relevant CASH data in the CASH data stream (not shown) with is eligible for reconciliation, and if not, a similar check to determine whether the time limit has been reached is conducted at 54, looping back to 52 if the time limit has not been reached yet. Should the time limit have been reached, the POS data item 38 is similarly removed from further reconciliation at 56 and the POS data item 38 logged. If an eligible CASH data item from the CASH data stack (not shown) is available the comparison step 46 is conducted on the two relevant data items, and the procedure following comparison step 46 is initiated, as described in the above paragraph.

In the example referred to in Figure 3, when the time limit is exceeded the most recent CASH and POS data items may be force matched and both removed from further consideration, and the sequence of alternating CASH and POS data items resynchronised to start again following the position in the data stream of the force matched pair of data items. In other words, the CASH and POS data streams are resynchronised and start again. In all cases, POS and CASH data items are preferably logged so that no data is lost to enable further analysis to be carried out on the CASH and POS data streams as appropriate.

This way, even though the force matched pair of data items may not be entirely accurate, the resultant resynchronisation of the data streams means that transaction data following the resynchronisation have a better chance of being accurately paired. Without resynchronisation, any inaccuracy leading to an inaccurate pairing would have been allowed to propagate throughout all the data items in the data streams.

The time limit referred to above may be an elapsed time since the last reconciliation action, the last matching action or the elapsed time since a POS or CASH data item was added to the POS and CASH data streams respectively. Examples of other appropriate triggers to force synchronisation would be a defined external influence such as a change of cashier. However, it is also recognised that forced matching may not be ideal in situations where there is valid data waiting to be processed and added to the data stream. An example of forced time matching according to the method described in Figure 3 is shown in Figure 4 and Figure 5, which show how data items in a CASH data stream and a corresponding POS data stream are force matched.

In Figure 4 there is shown a CASH data stream and a POS data stream, presented in tabular notation. The oldest data item in each data stream can be found at the bottom of each table, with the most recent data items in each data stream at the top of the table. For avoidance of doubt, the first recorded CASH data item shown in Figure 4 is ITEM 28, which in turn is triggered by a KEY OPEN operation by the operator. The first recorded POS data item shown in Figure 4 is ITEM 27, which in turn is triggered by a CASH TRANSACTION. As can be seen, the data items represented by ITEMS 1 to 28 are referenced in reverse chronological order.

The start of a new shift has an operator typically opening the cash drawer to insert a freshly made-up cash drawer with a known amount of cash, or the cash drawer is continued from the previous shift. It is remembered that with intelligent cash registers able to provide an indication of the cash present in the cash drawer, manually counting the amount of cash in the cash drawer at the start of the shift is not essential. The KEY OPEN action of the operator is a trigger for the IAS (shown in Figure 1) to reset synchronisation between CASH and POS data items. Three transactions pass, each producing a CASH data item (ITEM 26, ITEM 24 & ITEM 22) which is closely followed by a corresponding POS data item (ITEM 27, ITEM 25 and ITEM 23 respectively). Reconciliation after each pair of CASH and POS data items is carried out by the IAS and generally a good match is found immediately between each successive pair of CASH and POS data items, within error limits set by the operator, so no anomalies are detected. Reconciliation pairings are shown in Figure 4 by solid lines connecting paired data items. Further transaction data arrives as shown by ITEMS 15 to 20. No obvious good pairings can be found between these CASH and POS data items without exceeding the error limits so no immediate pairing is made. A CHANGE OF SHIFT action at ITEM 14 triggers a resynchronisation of the CASH and POS data streams so that forced pairings of all CASH and POS data items still unpaired before ITEM 14 are made. This is represented by the solid lines joining ITEMS 15 to 20 as shown in Figure 4.

The next resynchronisation trigger of KEY OPEN at ITEM 7, forces unmatched data items from ITEMS 13 to 8 to be force matched.

The result of the force matching is shown in the table of Figure 5, with anomalous transaction reconciliations that fall outside the acceptable error limits underlined and in bold. It is clear to see that if forced resynchronisation had not taken place at the trigger points of ITEM 7 and ITEM 14, and merely a simple matching of alternate CASH and POS data items taken place, the number of anomalous reconciliations would have been significantly more.

It is also clear from Figure 5 that the method described in Figure 4 is equally applicable to on-the-fly reconciliation as it is to reconciliation after a number of data items have been received.

As described above, the criteria upon which CASH data and POS data are paired is user-defined and can vary between an exact match or within a user- set error variance. These parameters by which the suitability of paired data items are judged may also vary with time. For example, it may be preferable to have a strict variance error margin at the start of a shift, gradually allowing more and more variance throughout the shift. In practice, there are usually many periods during a day when a POS terminal is not used for a significant period of time, or a period of time where the POS terminal is used at a relatively low tempo. In a retail outlet, periods of relative inactivity will vary from store to store and even between POS terminal locations within each outlet. It is envisaged that different POS terminal locations in different stores will require different time limits and/or trigger items to those referred to in the description to Figures 3 to 5, according to the time of day and even the location of a particular POS terminal within a retail outlet.

Figure 6 shows a refined method for reconciliation over that shown in Figures 3 to 5 wherein matching of data items sent in batches or data items sent out of order is accomodated. Following a new till transaction 60 comprising of a CASH and a POS data item respectively (not shown), a decision is made at 62 to decide whether the transaction falls within the criteria for carrying out a reconciliation procedure. Should the decision be negative, the transaction details are then logged at 64 and the datalogs stored in the database server 9 (not shown in Figure 6). The criteria against which the decision at 62 is judged may comprise any of the trigger events mentioned thus far, for example, elapsed transaction count, elapsed time, change of shift and manual cash drawer opening.

Should the reconciliation decision at 62 result in a positive indication, the transaction details are then processed with the first step being the adding of the CASH data item to the CASH data stream (not shown) at 66. Once the CASH data has been added to the CASH data stream, a check is carried out at 68 to see whether a suitable POS data item (not shown) is ready for assessment in the POS data stack (not shown). If no POS data item is ready for assessment in the POS data stack, a wait state is entered at 70 until a notification message (also not shown) is sent from the POS data stack to signal that a POS data item is ready for assessment. As explained previously, the storage of data items from a data stream creates a data stack of data items held in memory.

Once the POS data stack ready signal is received, a comparison is made at 72 between the CASH data item and the POS data items on the POS data stack in turn. The comparison with CASH data items starts with the most recently added CASH data item and works back through all the POS data items on the POS data stack to find an appropriate close match. Should a close match be identified the reconciliation is considered to be successful and a resynchronisation of data has been achieved. These matching POS and CASH data items are then removed from the stack and the remaining data is processed wherein data items more recent than the reconciled data is removed from the stack and logged, and reconciliation continues at 68 with all the remaining CASH and POS data items to find further close matches. Should no further close matches be found between data items, nearest matches are made and reconciliation between these corresponding nearly- matched data items is forced at 74. Once reconciled, these further matches are also removed from the stack. Further matches are logged (not shown), and where there is a discrepancy between forced matched data items this discrepancy is also logged (also not shown). Any remaining unreconciled data items are marked as unmatched, logged, and removed from the stack at 76. Data logging shown generally at 78 applies to all the transaction data reconciled or otherwise.

In use, it is possible to further refine the method shown in Figure 6 by allowing CASH and POS data items to remain in the stack even after forced matches have been made if no close match within accepted limits can be found. Continued matching including the data items force matched could then be carried out again until a trigger such as a timeout signal, elapsed transaction counter or maximum stack depth stops any more matching and the best match found up to that point is then logged as the reconciling match. This makes use of the fact that each time a better match is made this data replaces the previous best match data. Figure 7 shows a further embodiment of the invention employing deductive logic and iterative procedures. The procedures shown in Figure 7 are shown to take place after previous less complex methods of reconciliation have been applied without acceptable success, although of course the method of Figure 7 may also be applied as a standalone method of reconciliation. A new transaction 80 takes place which generates at least one CASH data item. The

CASH data item is processed at 82 to deduce whether the CASH data item may be easily reconciled with a POS data item using any of the aforementioned reconciliation methods. If the CASH data item can be easily reconciled with a POS data item, reconciliation takes place at 84 and the rest of the method shown in Figure 7 is obviated. If the CASH data item cannot be reconciled easily, the CASH data item is added at 86 to the CASH data stack (not shown) and a close-match reconciliation is then attempted at 88.

The close-match reconciliation process 88 is an iterative step and this is shown and described in greater detail in Figure 8 and the narrative accompanying Figure 8.

Returning to Figure 7, should a close match, or a 'zero reconcile' (so-called because zero or an insignificant variance exists between the CASH and POS data values) be found after reconciliation at 88, the reconciled CASH data is logged and removed from future consideration at 90 by removing the CASH data from the CASH data stack. The CASH and POS data are considered to be paired.

Should a close match not be found an assessment is made at 92 whether there are other combinations of CASH data items which are appropriate to the transaction recorded, for it may be possible that more than one CASH data item is generated for a single transaction, and further possible that a combination of CASH data items are related to a single POS data item, or multiple POS data items. Should there be more combinations of CASH data items not yet assessed, a loop back to 86 is made to rematch new combinations of CASH data items with POS data in the POS data stack until a close match is found. Permitted combinations of CASH data items able to be considered for matching are predetermined by the operator and stored in computer memory. Typically, permitted combinations will vary from retail outlet to retail outlet depending upon the nature of the business.

Should a close match still not be made, and all permitted combinations of CASH data items have been assessed with the available POS data, a repetition of steps 86 to 92 is then carried out at steps 94 to 100 (not shown in detail), but applied to POS data instead of CASH data, to see if a close match between a combination of POS data items and a CASH data item is achievable. Should a close match reconciliation between combinations of CASH and POS data items still not be achieved at the end of 100, the CASH and POS data items are retained at 102 for further processing whereupon they will form part of future combinations to be assessed.

Of course, should combinations of CASH data items be predetermined to reconcile with combinations of POS data, this type of reconciliation may be attempted at the appropriate steps mentioned above.

As can be seen above, procedures 86 to 92 for the CASH data items and procedures 94 to 102 for the POS data items form iterative loops of recursive procedures that rely on deductive logic to compare combinations of CASH and POS data items to form a match.

These iterative procedures are shown in greater detail in Figure 8. For clarity, the following assumes the case of CASH data items be reconciled with POS data items, although the exact same procedure may be applied to POS data items being reconciled with CASH data items. At the start 110 of the iterative process there could initially be a single CASH data item to be matched or there could initially be a combination of CASH data items - Figure 8 exemplifies the case where a combination of CASH data items is being matched initially. The exact combination of CASH data items permitted, and if applicable, the permutation of CASH data items permitted, and the combination and/or permutation of pairable POS data items, are predetermined and set manually by the operator and preferably stored on the database server 9 or made available to the network by preformatted data carrier means. For example, it is already appreciated that a drive-through restaurant will have a generally staggered CASH and POS data pairing structure due to further orders being received before a first order is completed. Other examples where permutations of CASH and POS data may be considered are when a cashier does not immediately place money in the cash drawer owing to a customer crisis, or when POS data items are received much later than CASH data items (a large database working on a batch transfer basis providing POS data items in groups may be substantially delayed before processing a batch of POS data items).

Returning to Figure 8, a combination of CASH data items is processed at 112 and assessed for a close match with a corresponding POS data item. Should a close match be found, a check is made at 114 to determine whether the match is the best made so far out of all the combinations assessed. If the latest match is a better match than all previous matches, the new match data supplants any previous match data in the data store 116.

Following this, a check is carried out at 118 to determine whether there are further permitted combinations of CASH data items which have not been considered yet. If there are other combinations of CASH data items, the procedure loops back to 112 and the assessment procedure of checking the new combination of CASH data items with corresponding POS data items is carried out.

If at 118 there are no further combinations of CASH data items yet to be assessed, the best match stored at 116 is logged at 120 and all the data items from the contributing transactions involved in the best match are removed at 122 from further reconciliation consideration. The overall reconciliation procedure then continues at 124 after all relevant data items are logged. As shown in Figure 7, it is possible that iterative reconciliation using combinations of CASH data items with POS data items may fail, in which case following iteration of combinations of CASH data items, there then follows iteration of combinations and/or permutations of POS data items (94 - 100 in Figure 7) as appropriate.

In use, the definition of a close match is set by the user and includes, for example, variables such as the number of transactions to consider in any one iteration, the degree of closeness in a match before acceptance of a close match, adjusting the degree of match proportional to the number of transactions, the degree of closeness between time of transactions, and the number of iterations allowed before a cut-off is reached.

Although matching date and time of CASH and POS data item creation is a valid method of reconciliation, it is frequently the case that different components on a network each have their own internal clock, and data items are time and date stamped according to this local clock. Hence, date and time of item creation may not be a reliable method of reconciliation. The methods described above work irrespective of internal clock variation, although temporal matching would be an appropriate consideration between time- stamped POS and CASH data provided inter-clock accuracy can be assured.

The combinations of data items permitted to be assessed are determined by the number of transactions being considered. Limiting the number of transactions available for consideration will consequently limit the number of data points, hence the number of data point combinations available. It is also envisaged that a perfect match, should it occur during an iteration, be enough to end the iterative process to find other matches, and hence save processing time. Furthermore, the degree of closeness and the other variables set initially may be amended at the conclusion of each iterative process based upon user amendment of what is considered a close match or of the rules defining permitted combinations of data points relating to each transaction type. This may be achieved, for example, by defining a 'grey area' for matches that fall just outside the specified area within which a match will be considered to have been made. Any match falling within this grey area may then be referred to the user to decide whether the match is acceptable or not, and should the user decide that the match is good enough, the iterative process then remembers this set of circumstances and learns to accept matches repeating the same circumstances in future.

As mentioned previously, should a gross mismatch occur it is likely that operator intervention will be required. This may be as simple as an acknowledgement that the alert has been received and subsequently reset, or the alert could reset itself after a predetermined period of time. It is also possible that any alert could automatically generate a paging message, by way of transmitter means attached to the network, to a portable receiver that a supervisor carries about their person. For example, a short messaging service/enhanced messaging service (SMS/EMS) message or e-mail may be generated by the alerting means 11 or IAS 7 as shown in Figure 1, and sent via industry standard means to a mobile telephone or receiver-equipped personal digital assistant (PDA) carried by a supervisor.

In current implementations it is envisaged that the display used to show alerts, as mentioned in Figure 1, may employ colour highlighting to differentiate between different levels of reconciliation mismatch for each POS terminal. For example, red, yellow and green may be used to highlight the amount by which reconciliations differ from norm and offer the supervisor an immediate picture of the general state of POS terminal reconciliation across the board, or broken down to individual POS terminals. The alert screen may also display urgent alerts and a running cash variance graph, or other statistical or managerial tools, to aid management of POS terminals. It is envisaged that when displaying matches obtained from iterative processes, the details relating to each match, for example the combination of data points chosen, how many iterations it took to arrive at the final combination and whether the cut-off was reached without having tried all permitted combinations of data points, are displayed. It has also been found that colour-coding reconciliation matches that have been made through combinations of data points, in contrast to straightforward single data item to single data item matches, is useful in analysis of the reconciliation data.

A learning process may also be implemented from analysis of previous matches - the reconciliation process identifies patterns, or permutations or combinations, of data items which have been successfully paired with other patterns of data items. These patterns may be different from the permitted combinations of data items and the iterative process learns to try these permutations first when a corresponding permutation is identified, rather than try each permutation in turn.

As a further refinement of the iterative matching processes mentioned previously, a process of 'pair review' may also be undertaken. Each matched pair of CASH and POS data items, or combination of CASH and POS data items, is assigned a weighting factor according to how accurately matched they are. The pair review process would then review all weighting factors between matched data items and if necessary, re-process matches using data available at that later time to improve the overall pairing accuracy. This type of post-pairing processing is useful for correcting odd omissions not detected at the time of first reconciliation, for example, a banknote first placed in the wrong cup may be manually corrected several hours later. A reconciliation undertaken at the time of the first placement in the wrong cup may produce significantly different results to a further reconciliation several hours later after the initial placement error has been corrected. Post-pairing processing accommodates such errors by allowing pairings with poor weighting factors to be reprocessed at a later time using the latest available data. As this review process may be done at any time after the initial pairing matches are made, this does not affect the ongoing ability of the abovementioned methods to identify anomalous reconciliations on-the-fly, and hence does not affect the ability to identify problems as soon as they happen.

The weighting factor table from which the weighting factor value is determined for a paired match, as with the matching variance error margin value allowed for a pairing to be successful, is preferably user defined and also preferably determined from statistical analysis of results from sample transactions.

It is noted that the apparatus used with the invention does not necessarily require a central accounting server, database server or even a network. The techniques taught above work equally well with a standalone checkout unit provided that it has a POS terminal, an intelligent cash drawer and a local processing unit provided with hardware and firmware/software able to take data from the POS terminal and intelligent cash drawer, and process the data according to the aforementioned reconciliation techniques. A preferred solution would involve embedded processors to enable each standalone unit to deliver a simple status signal signifying the health of current cash reconciliations carried out at the unit. Such a standalone unit would preferably save the cash reconciliation information for at least 24 hours and be able to remotely forward reconciliation data to a server via modem or other transmission means, such as a wide area network (WAN) for consolidation and potential report generation. A standalone unit would also preferably have control facilities for safes, cashier displays and status lights to show the general accuracy of cash reconciliations and whether closer scrutiny was required. The standalone unit may have means available to produce printed reports, and this facility could be provided by an already existing customer receipt printer. As an option, attached to the printer could be a receipt capturing device to maintain a simple store of data sent to each printer in the simple network. By using common networking protocols (for example, proprietary TillBus protocol, wired RS-232 / Ethernet or wireless IEEE 802.11x / Bluetooth™ protocols) to link at least two standalone checkout units to each other and to a separate management console for a supervisor, a simple low-cost network may be established without the need for the significant network infrastructure investment required for implementing the network shown in Figure 1 above. This type of low-cost network could be expanded or reduced in size on an ad- hoc basis, and is typically suited to smaller users unable to justify the investment required for the larger network, or for users with unpredictable or seasonal busy periods as the number of checkout units in this simple network may be adjusted according to customer demand without the expense of reconfiguring a centralised network.

It is envisaged that the management console mentioned above be able to present to a supervisor a clear and simple indication of the current status of cash reconciliations in each standalone unit, indicated by a row of status lights - preferably red, yellow and green, with additional lights for skim and float anomalies. The console would also preferably have a display capable of displaying simple messages. For alerting the supervisor's attention in case of a detected anomalous reconciliation, warning lamps may be provided.

As the standalone checkout unit would be designed to complement existing anti-fraud measures, the reporting facilities would perhaps not be as extensive as in the implementation described in Figure 1. Specimen data fields to be included in the report include present cash value in till, total value of cash in all tills/safes, float requirement, skim requirement, discrepancies per till including number and total value (broken down), end of day skim and discrepancies per cashier.

Claims

1. In a cash-handling point of sale (POS) environment, a method of reconciling an actual cash holding with an expected cash holding by comparing cash actually held, represented as CASH data, with cash expected to be held, derived from POS data, the method comprising: capturing and caching items of CASH data; capturing and caching items of POS data; pairing a cached item of CASH data with a cached item of POS data; comparing the CASH data and POS data of each pair of items to determine a match or mismatch; logging the result of each comparison; removing the paired items of CASH data and POS data from cache; and at intervals, removing from cache and logging any non-paired items of CASH data or POS data.

2. The method of Claim 1 , wherein the intervals are pre-determined periods.

3. The method of Claim 2, wherein the periods are regular.

4. The method of any preceding Claim, wherein the intervals are periods whose length is determined by POS transaction activity.

5. The method of Claim 4 and practised in an environment having a plurality of POS positions, wherein the periods are of different length for different POS positions.

6. The method of any preceding Claim, wherein any non-paired items of CASH data or POS data are removed from cache and logged upon a change of cashier at a POS position.

7. The method of any preceding Claim, further comprising monitoring POS transaction activity and removing from cache and logging any non-paired items of CASH data or POS data preferentially at times of low or no activity.

8. The method of any preceding Claim, comprising awaiting capture of a second item of CASH data or POS data to pair with a first cached item of POS data or CASH data respectively, and removing from cache and logging the first item of POS data or CASH data upon expiry of a time period without capture of a second item of CASH data or POS data.

9. The method of Claim 8, wherein the time period commences upon capture of the first item of POS data or CASH data.

10. The method of any preceding Claim, wherein the intervals are determined by counting the number of POS data or CASH data transactions since previously removing from cache and logging any non-paired items of CASH data or POS data.

11. In a cash-handling point of sale (POS) environment, a method of reconciling an actual cash holding with an expected cash holding by comparing cash actually held, represented as CASH data, with cash expected to be held, derived from POS data, the method comprising: capturing and caching items of CASH data in a stack of CASH data items; capturing and caching items of POS data in a stack of POS data items; seeking in one stack a match for an item of data from the other stack; in the event of a match being found between items from the different stacks, pairing the matching items of CASH data and POS data; and reconciling the CASH data and POS data of the matched pair of items.

12. The method of Claim 11, wherein a match between items of CASH data and POS data is not an exact match.

13. The method of Claim 11 or Claim 12, comprising waiting for a matching item of CASH data or POS data in the event of a match not being found between items from the different stacks.

14. The method of any of Claims 11 to 13, wherein the items in a stack include chronological information indicating the order of entry of each item into the stack.

15. The method of Claim 14, wherein seeking a match is performed in reverse chronological order through a stack, assessing the most recent entries first.

16. The method of Claim 14 or Claim 15, wherein when a match is found between items from the different stacks, items of older data entered into the stacks before the matched items are reconciled with each other.

17. The method of Claim 16, wherein discrepancies of reconciliation are logged.

18. The method of Claim 16 or Claim 17, wherein a less close match governs whether items of older data can be reconciled than governs whether the items initiating said reconciliation can be matched.

- 19. The method of any of Claims 16 to 18, wherein older data that cannot be reconciled is retained in the stacks.

20. The method of any of Claims 16 to 19, wherein newer data entered into the stacks after the matched items is ignored.

21. The method of any of Claims 11 to 20, wherein any non-reconciled items of CASH data or POS data are removed at intervals from the stacks and logged.

22. The method of Claim 21, wherein the intervals are determined by time elapsed, transactions counted or the number of items in a stack.

23. The method of any of Claims 11 to 22, comprising removing matched or reconciled pairs of items of CASH data and POS data from their stacks.

24. The method of any of Claims 11 to 23, comprising matching an item of data from one stack with more than one item of data from the other stack.

25. The method of Claim 24, comprising matching more than one item of data from one stack with more than one item of data from the other stack.

26. The method of Claim 24 or Claim 25, comprising identifying a best match between combinations of items and then attempting to improve the best match by attempting other combinations of items.

27. The method of Claim 26, comprising selecting a combination of items for matching; determining closeness of match for that combination; assessing whether the match is the closest recorded; and if not, selecting a further combination of items for matching and determining closeness of match for that further combination; or if so, recording that match as the closest recorded.

28. The method of Claim 27, wherein iteration continues until all possible combinations of items have been exhausted.

29. The method of Claim 27, wherein iteration continues until a threshold number of iterations has been reached.

30. The method of Claim 29, wherein the threshold is dependent upon the number of transactions to be processed in each iteration.

31. The method of Claim 29, wherein the threshold is dependent upon the closeness of match that characterises an acceptable match.

32. The method of Claim 31, wherein the closeness of match that characterises an acceptable match is adjusted with regard to the number of transactions being processed.

33. The method of Claim 29, wherein the threshold is a predetermined number of iterations.

34. The method of any of Claims 28 to 33, wherein after the final iteration, the closest recorded match is logged.

35. The method of any of Claims 28 to 34, wherein after the final iteration, transactions the subject of the matching process are removed from future processing.

36. The method of any preceding claim wherein a weighting factor is assigned to each matched pair of POS and CASH data, the weighting factor representing closeness of the match between the paired POS and CASH data, and rematching of POS and CASH data takes place according to weighting factor.

37. The method of any preceding claim whereupon matching of POS and CASH data comprises temporal matching.

38. The method of any preceding claim wherein any data item matched in a first matching with available data items at the time of the first matching, is re- matched at a later time with available data items at the time of a later matching.

39. The method according to Claim 38 wherein any data item matched is assigned a weighting factor and only matched data items with an unsatisfactory weighting factor are re-matched.

40. Cash-handling point of sale (POS) apparatus for reconciling an actual cash holding with an expected cash holding by comparing cash actually held, represented as CASH data, with cash expected to be held, derived from POS data comprising: means for capturing and caching items of CASH data; means for capturing and caching items of POS data; means for pairing a cached item of CASH data with a cached item of POS data; means for comparing the CASH data and POS data of each pair of items to determine a match or mismatch; means for logging the result of each comparison; means for removing the paired items of CASH data and POS data from cache; and means for removing, at intervals, from cache and logging any non- paired items of CASH data or POS data.

41. Cash-handling point of sale (POS) apparatus for reconciling an actual cash holding with an expected cash holding by comparing cash actually held, represented as CASH data, with cash expected to be held, derived from POS data, comprising: means for capturing and caching items of CASH data in a stack of CASH data items; means for capturing and caching items of POS data in a stack of POS data items; means for seeking in one stack a match for an item of data from the other stack; means for pairing the matching items of CASH data and POS data in the event of a match being found between items from the different stacks; and means for reconciling the CASH data and POS data of the matched pair of items.

42. A network of cash-handling point of sale (POS) apparatus according to Claim 40 or Claim 41 wherein each cash-handling point of sale (POS) apparatus further comprises networking means.

43. A network according to Claim 42 further comprising a central accounting server.

44. A network according to Claim 42 further comprising a central database store.

45. A network according to Claim 42 further comprising audio-visual or wireless communication alerting means when an anomalous reconciliation is detected.

46. A network according to Claim 45 where the audio-visual means further comprises means of displaying the location of the anomalous reconciliation.

47. In a cash-handling point of sale (POS) environment, a method of reconciling an actual cash holding with an expected cash holding by comparing cash actually held substantially as hereinbefore described with reference to Figures 3 to 8 of the accompanying drawings.

48. A network of cash-handling point of sale (POS) apparatus substantially as hereinbefore described with reference to Figure 1 of the drawings.