NZ564135A - Automated reconciliation of transaction records - Google Patents

Abstract

A system for automating reconciliation of a credit or charge card account includes (a) a point-of-sale terminal for processing one or more merchant sale transactions to generate a first input file including data relating to the merchant sale transactions; (b) a transaction processing component for generating a second input file including data relating to one or more customer account charge transactions; (c) a matching component for receiving a third input file including data relating to one or more merchant invoice records and searching for matches between the charge transactions and the invoice records, and (d) an output component for merging any matched transactions to an output file including data relating to one or more reconciled transactions for viewing by the customer. Each sale transaction is associated with a first unique identifier and each charge transaction is associated a first unique identifier derived from the first input file. Each invoice record is associated with a second unique identifier and each match is determined on the basis of corresponding first and second unique identifiers.

Description

DEC. 2007 14:00 PHILLIP *10055191993* "NO. 1269—P. T Patent Form No. 5 NEW ZEALAND Patents Act 1953 56 4 13 5 COMPLETE SPECIFICATION TITLE: Automated Reconciliation of Transaction Records We Australia and New Zealand Banking Group Limited, an Australian company (A.C.N. 005 357 522), of Level 6, 100 Queen Street, Melbourne, Victoria, 3000, Australia, do hereby declare the invention, for which we pray that a patent may be granted to us, and the method by which it is to be performed, to be particularly described in and by the following statement: Intellectual property office of n.z. 1 o DEC 2007 RECEIVED . DEC. 2007 14:01 PHILLIPS ORMONDE & FITZPATRICK' NO. 1 269 P. 8' ' 2 AUTOMATED RECONCILIATION OF TRANSACTION RECORDS This application claims priority from Australian Application No. 2006906966 filed on 13 December 2006, the contents of which are to be taken as incorporated herein by this reference.

Field of the Invention The present invention relates generally to methods and systems for reconciling transaction records. More particularly, the invention relates to automating reconciliation of a credit or charge card account.

Background to the Invention Most businesses use a commercial credit card facility for payment of business purchases and expenses. Credit card expenditure is recorded and monitored using accounting software to record transactions. Larger businesses or organisations may integrate their accounting software with an eProcurement, Enterprise Resource Planning (ERP) or other electronic ordering system which handles aspects of the business' inventory, invoicing, and accounting functions- A credit card provider typically issues a credit card statement to the business at monthly intervals. It is in the business' interests to ensure that all transactions charged to the credit card are authorised before paying the outstanding balance. This may be done by manually checking each charge transaction on the credit card statement against supplier invoices uploaded to the business' eProcurement or ERP system, There have been some attempts to automate the reconciliation process between the credit card statement and invoices in the business' online ordering, eProcurement or ERP system. However, for businesses which have significant numbers of transactions, hundreds or thousands per day, automatically matching invoices with the correct credit card charge transaction becomes extremely difficult and inaccurate.

Accordingly, it would be desirable to provide a method for automated reconciliation of credit card accounts which provides improved accuracy in matching transactions.

(NDuumMli and sctMqA*eirtiu>VjMil SuiMgMTtMpipy FM\OLKWV>NZ Trw* Entarati Dtrti PiajKt (C*P).ttc« . DEC. 2007 14:01 """PHILLIPS ORMONDE i FITZPATRICK' NO. 1269 P. 9' 3 The discussion of background to the invention herein is included to explain the context of the invention. This is not to be taken as an admission that any of the material referred to was published, known or part of the common general knowledge as at the priority date of any of the claims.

Summary of the Invention According to an aspect of the present invention, there is provided a method for automating reconciliation of a credit or charge card account, the method including the following steps: (a) receiving a first input file including data relating to one or more merchant sale transactions, each sale transaction being associated with a first unique identifier: (b) generating a second input file including data relating to one or more customer account charge transactions, each charge transaction being associated with a first unique identifier derived from the first input file; (c) receiving a third input file including data relating to one or more merchant invoice records, each invoice record being associated with a second unique identifier; (d) searching for matches between transactions in the second input file and invoice records in the third input file, each match being determined on the basis of corresponding first and second unique identifiers; and (e) merging any matched transactions to an output file including data relating to one or more reconciled transactions for viewing by the customer.

The first Input file or merchant sale transaction record includes details of one or more sale transactions processed by the merchant using a point-of-sale terminal or similar acquiring facility. Each sale transaction may be detailed by data including a merchant identifier, transaction date, transaction type, transaction amount, and credit or charge card number. The sale transaction is also associated with a unique identifier which may be input into the point-of-sale terminal by the merchant at the time of making the sale. The merchant sale transaction record will typically include details of a plurality of sale transactions processed by a particular merchant for a plurality of customers.

The second input file or customer account charge transaction record includes details of one or more transactions charged against a credit or charge frtfiocinianla n) String rtwirusirtLBCtf $0Hlniiri*«iip«Bfy internal FImolXbmnz Trwci ehmpioki dbui Prajca (CW)jao . DEC, 2007"" 14:01 PHILLIPS ORMONDE & FITZPATRICK' NO. 1269—P. 10" 4 card by the credit provider in response to sale transaction data received from a merchant. Each charge transaction may be detailed by of data including a credit or charge card number, posting date, transaction date, transaction type and transaction amount. The charge transaction record will typically include details of a plurality of transactions charged to a particular credit or charge card or one of a number of credit or charge cards associated with a particular customer by a plurality of merchants.

The merchant invoice transaction record may include details of one or more invoices issued by the merchant to one or more customers. Each invoice record may indicate an invoice number, unique order number, date, customer name, cost centre, and list of products or services including quantities and prices. Invoice records are typically held in the merchants' sales system.

In an embodiment, the step of generating the second input file in (b) includes the following steps: (a) generating a charge transaction file including data related to one or more transactions charged against the credit or charge card account; (b) searching for matches between the sale transactions in the first input file and the transactions charged against the credit or charge card account, each match being determined on the basis of predefined matching criteria; and (c) merging any matched transactions to generate a second input file including one or more charge transactions each being associated with a first unique identifier derived from the corresponding sale transaction.

In another embodiment, the step of generating the second input file in (b) includes: (a) generating a charge transaction file including data related to one or more transactions charged against the credit or charge card account; and (b) copying the first unique identifier from a sale transaction and associating it with a corresponding charge transaction, the corresponding charge transaction being identified on the basis of predefined matching criteria.

These steps for generating the second input file represent alternative embodiments for facilitating the insertion of a unique identifier into the charge transaction so it can be matched with the corresponding merchant invoice record on the basis of a unique matching criterion.

CMfeeuiwfito urn! SfihgriTtmpeiWy IfHwW FDM\£LKHMN2 Trtrftl Etfrnrtwd Data Prqjtd (OAPJdw Preferably, the first and second unique identifiers each include at least one of either a merchant invoice number or an order number.

Any suitable matching criteria may be used to define what will constitute a match between a sale transaction and a corresponding charge transaction. However, a plurality of data fields will require matching to increase the accuracy of the data matching step.

In searching for a match between the charge transactions and the merchant invoice records, the unique identifiers should match before a match is declared, however, it may be desirable to also match additional data selected from at least one of the following data fields: (a) transaction amount; (b) posting date; (c) transaction date; (d) merchant name; (e) card holder name; and (f) credit or charge card account number.

In one embodiment, the method further includes the step of adding enhanced data to the output file, the enhanced data including one or more of the following items: (a) customer name; (b) line item detail; (c) GST amount; (d) legal name; or (e) credit or charge card type.

According to another aspect of the present invention, there is provided a system for automating reconciliation of a credit or charge card account, the system including: (a) a point-of-sale terminal for processing one or more merchant sale transactions to generate a first input file including data relating to the merchant sale transactions, each sale transaction being associated with a first unique identifier; (b) a transaction processing component for generating a second input file including data relating to one or more transactions charged to a customer credit X:\SASKIA\Patent Spec\NZ15795-07.doc intellectual property OFFICE OF IM.Z Z 6 FEB 2008 r-k T~ f \ T~ 11/ r— r—v "10. DEC. 2007 14:02 PHILLIPS ORMONDE k FIT2PATRICK "NO. 1269 P. 12' j 6 or charge card account, each charge transaction being associated a first unique identifier derived from the first input file; (c) a matching component for receiving a third input file including data relating to one or more merchant invoice records, each invoice record being associated with a second unique identifier, and searching for matches between transactions in the second input file and invoice records in the third input file, each match being determined on the basis of corresponding first and second unique identifiers; and (d) an output component for merging any matched transactions to an output file including data relating to one or more reconciled transactions for viewing by the customer.

In one embodiment, the transaction processing component generates the second input file, by: (a) generating a charge transaction file including data related to one or more transactions charged against the credit or charge card account; (b) searching for matches between the sale transactions in the first input file . and the transactions charged against the credit or charge card account, each match being determined on the basis of predefined matching criteria; and (c) merging any matched transactions to generate a second input file including one or more charge transactions each being associated with a first unique identifier derived from the corresponding sale transaction.

In another embodiment the transaction processing component generates the second input file by; (a) generating a charge transaction file including data related to one or more transactions charged against the credit or charge card account; and (b) copying the first unique identifier from a sale transaction and associating it with a corresponding charge transaction, the corresponding charge transaction being identified on the basis of predefined matching criteria.

According to yet another aspect of the present invention there is provided computer software for use in a system for automating reconciliation of a credit or charge card account, the system including a processor and associated memory device for storing the computer software including a series of instructions to cause the processor to: C:\DMiiRisnla ond MUng^oGBntsrtLocal faWnatfTwuaprw/ Nirmi FlwWUWANZ TT*»+I EfNFWfl MM |CAP)i<fc* . DEC. 2007 14:02 PHILLIPS ORMONDE & FITZPATRICK NO. 1 269 P. 13' 7 (a) receive a first input file including data relating to one or more merchant sate transactions, each sale transaction being associated with a first unique identifier; (b) generate a second input file including data relating to one or more customer account charge transactions, each charge transaction being associated with a first unique identifier derived from the first input file; (c) receive a third input file including data relating to one or more merchant invoice records, each invoice record being associated with a second unique identifier; (d) search for matches between the transactions in the second input file and invoice records in the third input file, each match being determined on the basis of corresponding first and second unique identifiers; and (e) merge any matched transactions to an output file including data relating to one or more reconciled transactions for viewing by the customer.

In one embodiment, the computer software further includes a series of instructions to cause the processor to generate the second input file by: (a) generating a charge transaction fife including data related to one or more transactions charged against the credit or charge card account; (b) searching for matches between the sale transactions in the first input file and the transactions charged against the credit or charge card account, each match being determined on the basis of predefined matching criteria; and (c) merging any matched transactions to generate a second input file including one or more charge transactions each being associated with a first unique identifier derived from the corresponding sale transaction. in another embodiment, the computer software further includes a series of instructions to cause the processor to generate the second input file by: (a) generating a charge transaction file including data related to one or more transactions charged against the credit or charge card account; and (b) copying the first unique identifier from a sale transaction and associating it with a corresponding charge transaction, the corresponding change transaction being identified on the basis of predefined matching criteria.

Brief Description of the Drawings Gtfkxumenlfl wti SittingitoGawcrilMzf SatimprtTainpOfirylrrtimit FJMOUCflQtANZ TlWtf ErthtnOri Dita Project (CMP) das . DEC. 2007 14:02' PHILLIPS ORMONDE & FITZPATRICK NO. 1269—P. 14" 8 The invention will now be described in further detail by reference to the attached drawings illustrating example forms of the invention. It i$ to be understood that the particularity of the drawings does not supersede the generality of the preceding description of the invention.

Figure 1 is a flowchart illustrating a method for automating reconciliation of a credit or charge card account according to an embodiment of the present invention, Figure 2 is a schematic diagram showing a computer-enabled system for automating reconciliation of a credit or charge card account according to an embodiment of the invention.

Figure 3 is a schematic diagram showing a computer-enabled system for automating reconciliation of a credit or charge card account according to another embodiment of the invention.

Figure 4 is a flowchart illustrating a method for automating reconciliation of a credit or charge card account according to an embodiment of the present invention.

Figure 5 is a schematic diagram showing various functional elements of the computer-enabled system of Figures 2 and 3 in block form.

Detailed Description A typical credit card transaction involves a customer or credit card holder initiating a transaction by placing an order with the merchant using a credit card. The merchant sends a request for authorisation of the sale transaction to a financial institution or acquiring bank via a payment gateway. The acquiring bank is the bank which has approved a merchant for accepting credit card payments, and is responsible for processing and collection of the merchant's credit card charges.

The payment gateway sends the transaction request to a payment processor, The payment processor examines the credit card number to determine the identity of the issuing bank that is the bank that issued the credit card to the customer. Once the issuing bank has been identified, the payment processor forwards customer details and the transaction request to the issuing bank.

CtfttifMnta and SatUngAMfliuadLMBl aeHnpiVTiMpafftiy li«M F1MW5U<0®AN2 Twd Enhanced DM Pn^aet (CAP) (toe . DEC. 2007~14:03' PHILLIPS ORMONDE & FITZPATRICK' 'NO. 1269—P. 15' 9 The issuing bank verifies that the customer information is valid and whether there is sufficient credit available to cover the transaction. If the account is valid and there is sufficient credit, the issuing bank sends an authorisation code back to the payment processor and puts a hold on the funds in the customer's account. If the account is not valid or there isn't enough credit to cover the transaction, the issuing bank sends a "transaction declined" message back to the payment processor. The authorisation code (or "transaction declined" message) is sent back to the merchant via the payment gateway.

If the transaction is approved, the merchant completes the sale transaction and sends the sale transaction information to the payment gateway. The sale transaction information may include a merchant identifier, transaction date, transaction type, transaction amount, credit card number and authorization code. The payment gateway sends the sale transaction data to the payment processor.

The payment processor then examines the information for each transaction to determine which issuing bank to send it to and forwards the information to the issuing bank or banks. The role of the issuing bank is to settle the transaction by transferring the funds from the card holder's account to the acquiring bank. The acquiring bank then deposits the funds in the merchant's account, minus a transaction fee. The issuing bank then issues a periodic statements to the credit card holder.

Any references made herein to a credit card are to be taken to generally include charge cards, e.g. DINERS™ and AMEX™. Charge cards are a specific type of credit card wherein the balance of the charge card account is payable in full at the end of each billing period. That is, the account balance cannot be carried over from one billing period to the next which means that no interest is payable on the balance. The method and systems described herein are considered to be equally applicable to reconciliation of charge card accounts as to credit card accounts.

Referring now to Figure 1, there is illustrated a method of automating reconciliation of a credit or charge card account 100 associated with a credit card holder in accordance with an embodiment of the present invention. Automatic reconciliation of a credit or charge card account is particularly C:\Dfieumann and CedingrticflruKriLoc*! dMlntyATainpoiwy Inlarmrt FUiWLKWiAMZ Trwti EnNftMd Pw Prtjtq (&AP),dK , DEC, 2007 14:03 PHILLIPS ORMONDE & FITZPATRICK' NO. 1 2 69—P, 16' desirable in the cases of business and commercial credit or charge card accounts, where literally hundreds of transactions may be charged against a single credit or charge card every single day.

At first step 110 reconciliation of the account involves a merchant sending a first input file including data relating to one or more sale transactions to a payment gateway via a communications network. The sale transaction file may include a plurality of data fields holding sale transaction details such as a credit or charge card number, the transaction amount, transaction date and merchant identifier. Each sale transaction is also associated with a first unique identifier.

At second step 120 a second input file is generated. The second input file includes data relating to one or more transactions charged to a customer credit or charge card account, each of those charge transactions being associated with a unique identifier derived from the sale transaction data. This step may occur at the end of a billing cycle to provide a record of all charge transactions made to a customer's credit or charge card during the billing period.

A third step 130 involves receipt of a third input file including data relating to one or more merchant invoice records. The invoice record may include a plurality of data fields including a list of products or services supplied to the customer, quantity, price, date of invoice, customer details, and cost centre details. Each invoice record is associated with a second unique identifier.

A fourth step 140 involves searching for matches between the charge transactions and the invoice records, each match being determined on the basis of corresponding first and second unique identifiers. At fifth step 150, any matched transactions are written to a reconciled transaction output file, and at sixth step 160, the output file is displayed to the customer or credit card holder.

An example of a unique identifier to be used as a matching criterion is a merchant invoice number or a unique order number. For instance, if the unique identifier is to be a merchant invoice number, the first input file or merchant sale transaction record will include a first unique identifier which corresponds to a merchant invoice number corresponding to the transaction being processed. The merchant invoice number or first identifier is entered at the point-of-sale terminal by the merchant at the time of making the sale. The CADoGumnla art SatllngBhnutflja! Sotfnpffwnporanr intomel ftaMLKBMNZTrwrel Enhanced EMaFnfcd (CAP).dw . DEC. 2007 14:03' PHILLIPS ORMONDE & FITZPATRICK' 'NO. 1 26 9 P. 17' 11 third input file or merchant invoice transaction record will Include a second unique identifier or merchant invoice number as a matter of course, This process facilitates accurate an efficient transaction matching since each transaction processed is associated with a unique identifier which is derived from the merchant's invoice transaction records which is also entered at the credit or charge card transaction processing stage. Accordingly, in the case of a corresponding sales transaction and merchant invoice record, the first and second unique identifiers will be identical, i.e. they will correspond, since both the first and second unique identifier originate from the same source but are included in different input files.

Optionally, a plurality of data fields will need to correspond in order to declare two transactions as being a match since, for example the fact that a merchant invoice record and a charge transaction were recorded on the same date (i.e. the invoice date and the posting date are the same) will not in itself suffice to suggest that the data relates to the same transaction. Preferably, up to five data fields will be matched in addition to the unique identifier before a match will be declared.

Referring now to Figures 2 and 3, there is shown an example of a computer-enabled system for automating reconciliation of a credit or charge card account according to embodiments of the present invention. The system 200 includes a merchant user terminal 220 including a point-of-sale terminal or acquiring facility 210. The merchant user terminal 220 is in communication with a payment gateway 260 associated with a financial institution 250. The merchant user terminal 220 and payment gateway 260 are interconnected by means of the Internet 240 or any other suitable communications network. A client user terminal 320 associated with a credit card holder is in communication with the financial institution 250 by means of the communications network 240.

The point-of-sale terminal 210 captures data relating to a merchant's sale transactions including a first unique identifier associated with each sale transaction. The unique identifier may be manually input into the point-of-sale terminal 210 by the merchant, The unique identifier will preferably be an invoice number or unique order number which is also detailed in the merchant's invoice records. The resulting first input file or sale transaction file 230 is transmitted to the financial institution 250 via the payment gateway 260 over the Internet 240.

C^OoewnmntiMd Sfli|l«ipMcirufl(ALocalfi«HlngrtTampQnr|r1riMn0cPIW0LKHMNZTraval Enhanced (Ma . DEC. 2007"~ 14:04 PHILLIPS ORMONDE & FITZPATRICK' NO. 1 269—P. 13' 12 On receipt of the sale transaction record 230, at least a selection of the data contained therein is used to generate a record of transactions charged to a customer's credit or charge card account 270. This transaction record which forms the second input file 270, may relate to a single credit or charge card number associated with a particular customer, or may relate to a plurality of credit and/or charge card numbers which have been assigned to a particular customer. The resulting transaction record 270 will have associated with each charge transaction, a first unique identifier derived from the first input file 230.

Figures 2 and 3 represent two alternative embodiments concerning generation of the second input file 270. Referring firstly to Figure 2, the record of transactions charged to the credit or chaige card account 230 may be generated by extracting data fields relating to a particular customer from the sale transaction file 230 received from the merchant and supplementing the sale transaction data with data from the financial institutions database 310 which holds data relating to the customer's account details and credit or charge card charges, whether the customer be associated with one or more credit and/or charge cards. The resulting charge transaction file 270 will therefore include customer specific data. In Figure 2 the unique identifier is not however, one of the data fields that are extracted directly from the charge transaction file 270.

Since it is desirable to include the unique identifier to improve the accuracy of the final matching step, the sale transaction file 230 and change transaction file 270 are merged to insert the unique identifier into the merged file 280 as a data field. This merging step involves searching for matches between each charge transaction and a corresponding sale transaction, each match being determined on the basis of predefined matching criteria. Any matched transactions are merged into a merged charge transaction file 280, the merged transaction file including one or more charge transactions each being associated with a first unique identifier derived from the corresponding sale transaction.

In regards to the matching criteria, these will generally be a plurality of the data fields which appear in both files to be matched. Whilst identical values will constitute a match, it may also be desirable to apply predefined tolerances CAhAnptt ftp* eMltytetkhjeAUK*! S*UrtJtfrTirt»OWy MMrm FMAQLK061AMZ TUMI EfltlMWd OBUk Pn|Hl(CAP).<tM '10. DEC. 2007'14:04" PHILLIPS ORMONDE & FITZPATRICK' 'NO. 1269—-P. 19- 13 to one or more of the matching criteria, to allow for common typographical errors and/or transaction price discrepancies of up to say 2%.

Referring now to Figure 3, the record of transactions charged to the credit or charge card account 270 including unique identifiers derived form the sale transactions file 230 is generated directly, without merging of the sale transaction Hie 230 and charge transaction file 270 as shown in Figure 2. In this embodiment, the charge transaction file 270 is generated directly by sending the unique identifier to the financial institutions database 310 which holds data relating to customer account details associated with one or more credit and/or charge cards. The resulting charge transaction file 270 includes customer specific transaction data including a unique identifier associated with each transaction.

The subsequent or final matching step involves matching the merged transaction file 280 or the charge transaction file 270 (i.e. the second input file) with a merchant invoice record 290 provided by the merchant. The merchant invoice record provides invoice records from the merchant's invoice system relating to sales made during the billing period or some other predetermined interval of time. This next matching step involves matching the charge transactions with the invoice records based on corresponding unique identifiers. Of course, the unique identifiers for a single transaction should match since the merchant assigns a unique identifier such as an invoice number or a booking reference or the like to the relevant invoice record and then enters that unique identifier when processing the sale transaction using the point-of-sale terminal or similar acquiring facility.

The result is a reconciled output file 300 which contains customer specific data detailing the charges raised against one or more credit and/or charge cards held by a particular customer, This output file 300 can be uploaded to a website for viewing by the customer, or transmitted to the customer by electronic mail or any other suitable means. The customer may or may not choose to upload the output file to their electronic ordering system, e.g. e-procurement, Expense Management System or ERP system.

Referring now to Figure 4, the method for reconciling a credit or charge card account may further include one or more optional steps to enhance the process and the condition of the reconciled transaction data provided to the QlDNUMrii and fi«NflptiHiitariLoa! SetikvtTtrQomi? irifrftil FHWMSUWAK? Trtwol Enhansftd Data Projod (CM*).dac . DEC. 2007"14:04" PHILLIPS ORMONDE & FITZPATRICK" NO. 1 269—P. 20' 14 customer. For instance, following the step at 150 of writing any matched transactions to a reconciled transaction output file, any unmatched transactions are optionally retained at step 170 to enable attempts to search for a match to be repeated when subsequent Invoice records are received from the merchant. This step allows for any differences between the dates on which a merchant records a sale transaction, that is the transaction date, and the date on which the issuing financial institution or credit provider processes the credit or charge card charge transaction, referred to as the posting date. Unmatched transactions are retained in a database for a predefined period, such as for instance 30 days. At the end of each month, an output file containing those transactions which have remained unmatched for 30 days (or some other predefined interval of time) after the charge transaction date may be sent or displayed to the credit card holder.

A further optional step 180 involves the addition of enhanced data in the output file prior to uploading the reconciled transaction output file for viewing by the customer. For instance, the output data may be enhanced by addition of one or more of the following items, invoice number, unique order number, line item detail, the merchant's Australian business number (ABN), the merchant's legal name, and/or credit or charge card type. Line item detail provides detailed invoice information including item description, quantity, unit of measure, price, and the like. These types of additional information assist the customer in streamlining their accounting and business practices, facilitate merging of payment data with ERP systems and enable purchases to be audited to ensure policy compliance.

In particular embodiment of the present invention, the merchant is a travel management company which handles travel related bookings and provides travel related services to one or more customers. The travel management company is provided with a point-of-sale terminal or similar acquiring facility by financial institution X. In addition to being the acquiring financial institution, financial institution X is also the card issuing financial institution, that is, provides credit to one or more of the merchant's customers. It is for the benefit of those customers that the financial institution provides credit or charge card account reconciliation. This can be regarded as a "closed loop" type arrangement. Financial institution X may develop similar GflDteWMMIcnd plngflpcAAJirtUMfli SitinguTamporaiy irtaixt FiiwtoLKBEtariZ Trar«i Enbamd Dan Pre)vet . DEC. 2007 14:05' PHILLIPS ORMONDE k FITZPATRICK" m 1269—P. 21 relationships with a plurality of travel management companies or other merchants in order to facilitate the provision of reconciled credit or charge card transaction data to their credit card customers, The system 500 may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or processing systems. The computer system 500 includes one or more processors, such as processor 510. The processor 510 is connected to a communication infrastructure 520. The computer system 500 may include a display interface 530 that forwards graphics, texts and other data from the communication infrastructure 520 for supply to a display unit 540. The computer system 500 may also include a main memory 550, preferably random access memory, and may also include a secondary memory 560.

The secondary memory 560 may include, for example, a hard disk drive, magnetic tape drive, optical disk drive, etc. The removable storage drive 580 reads from and/or writes to a removable storage unit 590 in a well known manner. The removable storage unit 590 represents a floppy disk, magnetic tape, optical disk, etc.

As will be appreciated, the removable storage unit 580 includes a computer usable storage medium having stored therein computer software in a form of a series of instructions to cause the processor 510 to carry out desired functionality. In alternative embodiments, the secondary memory 560 may include other similar means for allowing computer programs or instructions to be loaded into the computer system 500. Such means may include, for example, a removable storage unit 600 and interface 610.

The computer system 500 may also include a communications interface 620. Communications interface 620 allows software and data to be transferred between the computer system 500 and external devices. Examples of communication interface 620 may include a modem, a network interface, a communications port, a PCMIA slot and card etc. Software and data transferred via a communications interface 620 are in the form of signals 630 which may be electromagnetic, electronic, optical or other signals capable of being received by the communications interface 620. The signals are provided to communications interface 620 via a communications path 640 such as a wire fcWwb wd SttttanMBfuwUiwai iriwnrt FIMOLKMANZTtofel Enhwtml D*li . DEC. 2007~14:05' PHILLIPS ORMONDE & FITZPATRICK' NO. 1 269—P. 22' 16 or cable, fibre optics, phone line, cellular phone link, radio frequency or other communications channels.

An advantage of the present invention is that automation of account reconciliation in the manner described improves the accuracy of reconciling credit or charge card statements with a merchant, invoice records by using a unique identifier to match each credit or charge card charge transaction with a corresponding merchant invoice record. Automation of the process further limits the opportunities for error and enables businesses to more closely monitor spending habits.

Although in the above described embodiments the invention is implemented primarily using computer software, in other embodiments the invention may be implemented primarily in hardware using, for example, hardware components such as an application specific integrated circuit (ASICs). Implementation of a hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art. In other embodiments, the invention may be implemented using a combination of both hardware and software.

While the invention has been described in conjunction with a limited number of embodiments, it will be appreciated by those skilled in the art that many alternative,. modifications and variations in light of the foregoing description are possible. Accordingly, the present invention is intended to embrace all such alternative, modifications and variations as may fall within the spirit and scope of the invention as disclosed.

Also, future patent applications may be filed in Australia or overseas on the basis of or claiming priority from, the present application. It is to be understood that the following provisional claims are provided by way of example only, and are not intended to limit the scope of what may be claimed in any such future application. Features may be added to or omitted from the provisional claims at a later date so as to further define or re-define the invention or inventions.

C:\dfifiumtmb and srtunqflfloarukrlthhl aotflngrtTMipofirp Inumwi FlMAOLKHMP& Travel Eniurad Dole Prejia (cap)jh

Claims (14)

10. DEC. 2007"14:05' PHILLIPS ORMONDE & FITZPATRICK' 'NO. 1269—P. 23' 17 The claims defining the invention are as follows:

1. A method for automating reconciliation of a credit or charge card account, the method including the following steps; (a) receiving a first input file including data relating to one or more merchant sale transactions, each sale transaction being associated with a first unique identifier; (b) generating a second input file including data relating to one or more customer account charge transactions, each charge transaction being associated with a first unique identifier derived from the first input file; (c) receiving a third input file including data relating to one or more merchant invoice records, each invoice record being associated with a second unique identifier; (d) searching for matches between transactions in the second input file and invoice records in the third input file, each match being determined on the basis of corresponding first and second unique identifiers; and (e) merging any matched transactions to an output file including data relating to one or more reconciled transactions for viewing by the customer. v

2. A method according to claim 1, wherein the step of generating the second input file in (b) includes the following steps: (a) generating a charge transaction file including data related to one or more transactions charged against the credit or charge card account; (b) searching for matches between the sale transactions in the first input file and the transactions charged against the credit or charge card account, each match being determined on the basis of predefined matching criteria; and (c) merging any matched transactions to generate a second input file including one or more charge transactions each being associated with a first unique identifier derived from the corresponding sale transaction.

3. A method according to claim 1, wherein the step of generating the second input file in (b) includes; (a) generating a charge transaction file including data related to one or more transactions charged against the credit or charge card account; and CiVDwumanUwd SrtngAaarartLMri SutUngtffonvorary Mwnd FiwWLKWMNZ Trwri Enhanced Data Prajrt {CAP>.Ax 18 (b) copying the first unique identifier from a sale transaction and associating it with a corresponding charge transaction, the corresponding charge transaction being identified on the basis of predefined matching criteria.

4. A method according to any one of claims 1 to 3, wherein the first and second unique identifiers each include at least one of either a merchant invoice or an order number.

5. A method according to any one of claims 1 to 4, wherein the step of searching for matches in step (d) further includes matching data selected from at least one of the following data fields: (a) transaction amount; (b) posting date; (c) transaction date; (d) merchant name; (e) card holder name; and (f) credit or charge card account number.

6. A method according to any one of claims 1 to 5, further including the step of adding enhanced data to the output file, the enhanced data including one or more of the following items: (a) customer name; (b) line item detail; (c) GST Amount (d) legal name; or (e) credit or charge card type.

7. A system for automating reconciliation of a credit or charge card account, the system including: (a) a point-of-sale terminal for processing one or more merchant sale transactions to generate a first input file including data relating to the merchant sale transactions, each sale transaction being associated with a first unique identifier; X:\SASKIA\Patent SpecWZ15795-G7.doc 10. DEC. 2007 14:06 PHILLIPS ORMONDE & FITZPATRICK' 'NO. 1269—P. 25' 19 (b) a transaction processing component for generating a second input file including data relating to one or more customer account charge transactions, each charge transaction being associated a first unique identifier derived from the first input file; (c) a matching component for receiving a third input file including data relating to one or more merchant invoice records, each invoice record being associated with a second unique identifier* and searching for matches between the charge transactions and the invoice records, each match being determined on the basis of corresponding first and second unique identifiers; and (d) an output component for merging any matched transactions to an output file including data relating to one or more reconciled transactions for viewing by the customer.

8. A system according to claim 7, wherein the transaction processing component generates the second input file, by; (a) searching for matches between the sale transactions and the charge transactions, each match being determined on the basis of predefined matching criteria; and (b) merging any matched transactions to a merged transaction file, the merged transaction file including one or more charge transactions each being associated with a first unique identifier derived from the corresponding sale transaction,

9. A system according to claim 7, wherein the transaction processing component generates the second input file, by: (a) copying the first unique identifier from a sale transaction; and (b) associating It with a corresponding charge transaction, the corresponding charge transaction being identified on the basis of predefined matching criteria. 10. Computer software for use in a system for automating reconciliation of a credit or charge card account, the system including a processor and associated memory device for storing the computer software including a series of instructions to cause the processor to: CADflOfMrli ml SctthgAaamnriUiDaf SvtHnfrfrcmporiry Irtomot PWiflLKKWkhETrwal Snhanead Data Prajtral (GAP)jfcia

10. DEC. 2007~14:06 PHILLIPS ORMONDE & FITZPATRICK" -NO. 1 269—P. 26' 20 (a) receive a first input file including data relating to one or more merchant sale transactions, each sale transaction being associated with a first unique identifier, (b) generate a second input file including data relating to one or more customer account charge transactions, each charge transaction being associated with a first unique identifier derived from the first input file; (c) receive a third input file including data relating to one or more merchant invoice records, each invoice record being associated with a second unique identifier; (d) search for matches between the charge transactions and the invoice records, each match being determined on the basis of corresponding first and second unique identifiers; and (e) meiige any matched transactions to an output file including data relating to one or more reconciled transactions for viewing by the customer.

11, Computer software according to claim 9, further including a series of instructions to cause the processor to; (a) generate the second input file by searching for matches between the sale transactions and the charge transactions, each match being determined on the basis of predefined matching criteria; and (b) merging any matched transactions to a merged transaction file, the merged transaction file including one or more charge transactions being associated with a first unique identifier derived from the corresponding sale transaction.

12. Computer software according to claim 9, further including a series of instructions to cause the processor to: (a) generate the second input file by copying a first unique identifier from a sale transaction; and (b) associate it with a corresponding charge transaction, the corresponding charge transaction being identified on the basis of predefined matching criteria. CtyDKunNMti Md amngltafvuttLoaal SMlng ATwirporay Msirwl FlertOLKMtaNZ Tranl Enhanced Data Projw* (CaPJjJog *"10. DEC. 2007"14:06 "PHILLIPS ORMONDE & FITZPATRICK —NO. 1269 P. 27 21

13. A method for automating reconciliation of a credit or charge cart) account substantially as hereinbelbre described with reference to any one of the embodiments shown in the drawings.

14. A system for automating reconciliation of automating reconciliation of a credit or change card account substantially as hereinbefore described with reference to any one of the embodiments shown in the drawings. C:\QooMwh ml S fitting tiucaruuUacil MflngATtorparwr mama) FteAOLtfKMNZ Trwol Enhoroad Data PidJ«4 (CAP)^k