WO2002017201A1 - System and method for account reconciliation - Google Patents

System and method for account reconciliation Download PDF

Info

Publication number
WO2002017201A1
WO2002017201A1 PCT/US2001/026583 US0126583W WO0217201A1 WO 2002017201 A1 WO2002017201 A1 WO 2002017201A1 US 0126583 W US0126583 W US 0126583W WO 0217201 A1 WO0217201 A1 WO 0217201A1
Authority
WO
WIPO (PCT)
Prior art keywords
list
merchant
transactions
card
match
Prior art date
Application number
PCT/US2001/026583
Other languages
French (fr)
Inventor
Shirley Provinse
Original Assignee
American Express Travel Related Services Company, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to JP2002521820A priority Critical patent/JP2004507823A/en
Priority to BR0113492-2A priority patent/BR0113492A/en
Priority to AU8528401A priority patent/AU8528401A/en
Priority to MXPA03001652A priority patent/MXPA03001652A/en
Priority to EP01964431A priority patent/EP1323093A4/en
Priority to KR10-2003-7002501A priority patent/KR20030024896A/en
Application filed by American Express Travel Related Services Company, Inc. filed Critical American Express Travel Related Services Company, Inc.
Priority to AU2001285284A priority patent/AU2001285284B2/en
Priority to NZ524362A priority patent/NZ524362A/en
Priority to CA002423113A priority patent/CA2423113A1/en
Publication of WO2002017201A1 publication Critical patent/WO2002017201A1/en
Priority to AU2005202263A priority patent/AU2005202263A1/en
Priority to AU2008203400A priority patent/AU2008203400B2/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/14Payment architectures specially adapted for billing systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/04Billing or invoicing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12Accounting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12Accounting
    • G06Q40/128Check-book balancing, updating or printing arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services

Definitions

  • the invention relates generally to account reconciliation and, in particular, to travel "central bill” account reconciliation. More specifically, the invention relates to a system and method for identifying transactions on a centrally billed travel account and reconciling to the account balance.
  • Central billing is a common accounting practice often used by large employee-based companies. In general, central billing typically occurs when a card vendor assigns a common account billing number that can be used by multiple employees or authorized personnel to charge authorized items to the company. The company usually receives a single bill at the end of the billing cycle for all its employees' charges.
  • Company A may request a charge card company to assign a Company account number to be used for all of Company As charged airline tickets or other travel related charges. In this manner, when an authorized person from Company A requests a ticket from Company As travel agency, the charges will be automatically placed on the Company account instead of the individual's account. Charges throughout a specified billing cycle, e.g., monthly, accrue on the Company's account number for numerous employees and tickets. At the end of the billing cycle, a single bill for all the charges made using the Company account number as the form of payment is usually remitted to the Company for payment. Most companies enjoy the simplicity of receiving one bill for payment at the end of each billing cycle instead of having literally hundreds of individual bills remitted to their travelers.
  • Central billing creates numerous problems in the area of account reconciliation. Often times the bill recipient, e.g., Company A, includes in its contract with its travel vendor the non-trivial requirement to reconcile the monthly statements issued by its card vendor for its centrally billed account(s): i.e., identify each charge and credit on each account, calculate the total amount of the charges determined to be correct and ready to be paid, and properly apply applicable rebates and fees. In addition, the central billing reconciliation process often escalates as the volume of individual items on each account increases.
  • the traditional account reconciliation process for centrally billed accounts is a "match/non-match" approach.
  • the travel agency typically receives an electronic copy of the card statement listing all the travel transactions (charges and credits) billed during the cycle.
  • the travel agency conducts a one-time match against Company As charges and Company As travel records typically based on a ticket number and creates a list of matched items and a list of unmatched items. Matched items are subsequently forwarded to the Company on a report, which includes the identifying accounting information, such as the travel authorization number, employee ID, project code, or the like captured in the employees' original travel records.
  • the unmatched items which include any charge records that do not have corresponding travel records, e.g., tickets that were voided after the day of issue, modifications to tickets made at the airport, and data entry errors (e.g., misspellings), remain unidentified.
  • companies refuse to pay for unmatched items because many times the company is unable to establish a proper explanation of the charge, e.g., which employee charged the travel ticket.
  • the bill reconciler must then research each unmatched item in order to explain the charge and resubmit for payment. In a voluminous industry, such as the travel/ticket industry, this research process is cumbersome and very time consuming. In addition, it is often the case that the reconciler is simply unable to identify the item when the airline provides incomplete data. Thus, the unmatched item is left unpaid and eventually becomes a write-off for the card vendor.
  • a charge record for Company A is presented for matching to a ticket record for a ticket that was issued in week one, but which no longer exists.
  • the credit for the voided ticket, which was generated by ARC in week two, is also presented with no matching charge record.
  • a system and method for account reconciliation that includes a traditional matching technique to identify and resolve matched items, as well as a tracking, research and correction technique to identify and resolve the unmatched items is needed. Moreover, a system and method for account reconciliation that identifies, tracks and reconciles pending transactions to the account balance, including all accounting items whether matched or unmatched, is needed.
  • the present invention provides an improved system and method for account reconciliation that expands and builds on traditional matching techniques.
  • the present invention provides an account reconciliation system and technique to reconcile each entry on an account, irrespective of whether the item is a matched or unmatched entry.
  • the system includes a client side and a server side with a communication channel that joins the sides together and includes an accounting database capable of receiving and storing data relating to an account.
  • a software program may also be included that includes programming to automatically match the received data and automatically compile the matched data and remaining unmatched data.
  • a user is permitted to view the unmatched data and direct the system to search the database and accept a match.
  • a user is also permitted to edit the unmatched data.
  • the system further includes programming to generate a reconciliation report comprising a verification that the account is reconciled to the account balance.
  • Figure 1 a is an exemplary diagram of a computer-based architecture that can be used to implement an account reconciliation system of the present invention
  • Figure 1b is an exemplary top level block diagram illustrating an environment in which an account reconciliation system can function and operate according to one embodiment of the present invention
  • Figure 2 is an exemplary flowchart describing one embodiment for account reconciliation in accordance with the present invention
  • Figure 3 is an exemplary flowchart describing one embodiment of the present invention for refund management
  • Figure 4 is an exemplary flowchart describing one embodiment of the present invention for matching transactions
  • Figure 5 is an exemplary flowchart describing one embodiment of the present invention for washing out transactions
  • Figures 6a and 6b are exemplary flowcharts each describing one embodiment of the present invention for unresolved transaction management
  • Figure 7 is an exemplary flowchart describing one embodiment of the present invention for report generation.
  • Figure 8 is an exemplary screen shot of a Summary Reconciliation Report available to a user in accordance with the system and methods of the present invention.
  • the present invention provides an improved system and method for account reconciliation having particular usefulness in the reconciliation of centrally billed accounts.
  • the system and methods disclosed herein may be suitable for reconciliation of centrally billed accounts in a variety of applications, the present invention is conveniently described with reference to the travel industry, and more particularly to account reconciliation of travel records and charge records.
  • the present invention expands the traditional match/non-match technique for account reconciliation.
  • simply matching debits to credits in the traditional approach routinely reconciles the majority of the items on an account, and hence, the traditional approach is maintained in the initial steps of the present invention.
  • the present invention then goes beyond simply identifying matched and unmatched items and provides complete management of every item on an account.
  • the present invention reconciles the entire account balance through management of each item on the account regardless of its reconciliation status.
  • the present invention redefines the traditional approach of determining when an item is ready for payment by recognizing that clients generally pay according to their own definitions of a "match".
  • Traditional approaches generally do not sufficiently consider the quality of data used to determine a match. Often times what appears to match may not meet the stricter reconciliation requirements set by the client.
  • the present invention permits flexibility in the reconciliation process according to each client's criteria, such as, for example, accounting criteria. Clients can also set guidelines to indicate when their reconciliation requirements are met, to indicate that they are willing to remit payment. In other words, one client may be satisfied that an item is ready for payment under certain conditions which are quite different from the conditions established by another client.
  • the system and method of the present invention identifies most the problems that keep entities from paying and provides a solution and opportunity to correct them, by tracking each one until it is sufficiently resolved, i.e., reconciling the account balance.
  • This technique ultimately results in resolution of all of the account items, because unmatched items are not forgotten, as with traditional techniques, but are instead tracked until each item is removed from the outstanding account balance.
  • the reconciler and the client are ensured that ultimately all the items on the account will be resolved.
  • FIG. 1a is a simplified diagram illustrating an exemplary computer-based architecture 10 that can be used to implement the account reconciliation system in accordance with the present invention.
  • the account reconciliation system may be implemented in a commonly known client/server architecture having a client side 12, 13 and a server side 17.
  • the client side 12, 13 typically includes a computing device that includes, in one embodiment, a display and input means such as a keyboard, mouse, kiosk, personal digital assistant, handheld computer, portable computer and/or cellular phone.
  • client 12 is a portable computer and client 13 is a personal computer. It should be realized that two clients are illustrated for exemplary purposes only and that any number of clients may be included in the architecture.
  • the client typically includes an operating system (e.g., a version of Windows (Windows NT, Windows 98/2000/Millenium)), as well as various conventional support software and drivers typically associated with computers, computing devices, and the like.
  • an operating system e.g., a version of Windows (Windows NT, Windows 98/2000/Millenium)
  • the client side generally includes a modem (e.g., 56K baud) 14, 15 for facilitating access to a network.
  • the server side 17 may broadly include a server 18, a system administrator 19, and a modem pool 20, electrically linked together. Modem pool 20 send electrical signals to server 18 and is used to transceive electrical signals from the client modems 14, 15. The modem pool 20 may provide some protocol conversion to optimize modem performance, eliminate handoff retrain, and provide precise setting of transmit levels.
  • the server side 17 typically includes a computing device having a processor for processing digital data, a memory coupled to the processor for storing digital data, an input digitizer coupled to the processor for inputting digital data, and an application program stored in the processor.
  • Server 18 may be implemented as any suitable processing server, in an exemplary embodiment, including tables, objects, triggers, and stored procedures. For example, a Microsoft® SQL 6.5 Server database has been successfully utilized as server 18.
  • system administrator 19 includes a computing device that preferably includes a display and input means such as a keyboard, mouse, kiosk, personal digital assistant, handheld computer, portable computer and/or cellular phone to facilitate communications with server 18.
  • System administrator 19 further preferably includes a suitable operating system stored thereon, e.g., Microsoft® NT Workstation.
  • System administrator 19 suitably receives data which is loaded onto one or more databases of server 17.
  • travel data 21 , card data 22, and third party data 23 are electronically loaded and stored in server 17.
  • Third party data 23 may or may not be included in the system and generally includes travel and card data from vendors not associated with travel data 21 and card data 22.
  • American Express® travel data, American Express® card data, and non-American Express (third party) card and travel data may be electronically received and stored in the server.
  • FIG. 1 b is a top level block diagram illustrating an environment in which an account reconciliation system in accordance with the present invention can function and operate.
  • the account reconciliation system (hereinafter, referred to as the "system") 110 includes a front end (client) 102 and a back end (server) 107.
  • the front end 102 typically includes a computer, computing device, or the like.
  • the back end 107 typically includes a server, such as a host server or other computing system, and a plurality of databases.
  • system 110 includes one or more relational databases, which reside in a data storage medium. Travel or merchant data 112 and financial (card) data 114 are included in the relational databases for each client.
  • any databases, systems or components of the present invention may consist of any combination of databases or components at a single location or at multiple locations, wherein each database or system includes any of various suitable security features, such as firewalls, access codes, encryption, de-encryption, compression, decompression, and/or the like.
  • Database may be any type of database, such as relational, hierarchical, object-oriented, and/or the like. Common database products that may be used to implement the databases include DB2 by IBM (White Plains, NY), any of the database products available from Oracle Corporation (Redwood Shores, CA), Microsoft Access by Microsoft Corporation (Redmond, Washington), or any other database product. Database may be organized in any suitable manner, including as data tables or lookup tables.
  • Association of certain data may be accomplished through any data association technique known and practiced in the art.
  • the association may be accomplished either manually or automatically.
  • Automatic association techniques may include, for example, a database search, a database merge, GREP, AGREP, SQL, and/or the like.
  • the association step may be accomplished by a database merge function, for example, using a "key field" in each of the manufacturer and retailer data tables.
  • a "key field” partitions the database according to the high-level class of objects defined by the key field. For example, a certain class may be designated as a key field in both the first data table and the second data table, and the two data tables may then be merged on the basis of the class data in the key field.
  • the data corresponding to the key field in each of the merged data tables is preferably the same.
  • data tables having similar, though not identical, data in the key fields may also be merged by using AGREP, for example.
  • Communication between the front end and back end is accomplished through any suitable communications network 105 for exchanging data or transacting business such as, a telephone network, intranet, Internet, extranet, WAN, LAN, satellite communications, point of interaction device, online communications, off-line communications, wireless communications, and the like.
  • the system is implemented as an Internet-based application having a front end, a back end, a web browser and web pages.
  • the computer may provide a suitable website or other Internet-based graphical user interface which is accessible by users.
  • the Internet Information Server, Microsoft Transaction Server, and Microsoft SQL Server are used in conjunction with the Microsoft operating system, Microsoft NT web server software, a Microsoft SQL database system, and a Microsoft Commerce Server. Additionally, components such as Access Sequel Server, Oracle, MySQL, Intervase, etc., may be used to provide an ADO-compliant database management system.
  • the term "web page" as it is used herein is not meant to limit the type of documents and applications that might be used to interact with the user.
  • a typical website might include, in addition to standard HTML documents, various forms, Java applets, Javascript, active server pages (ASP), common gateway interface scripts (CGI), extensible markup language (XML), dynamic HTML, cascading style sheets (CSS), helper applications, plug-ins, and the like.
  • standard HTML documents various forms, Java applets, Javascript, active server pages (ASP), common gateway interface scripts (CGI), extensible markup language (XML), dynamic HTML, cascading style sheets (CSS), helper applications, plug-ins, and the like.
  • a computer reservation system (CRS) 118 or global distribution system (GDS) captures the travel and charge data in a travel reservation.
  • the CRS issues the travel ticket and forwards travel records 116 to a suitable storage or accounting system.
  • the CRS notifies the charge card vendor 120 that a travel purchase is made on the traveler's credit card.
  • the CRS, or travel agency submits the weekly report of tickets issued and dollars charged to ARC 122.
  • the client's card vendor 120 issues a periodic card statement to the client which includes all of the charges incurred on the client's charge account during the billing period.
  • the present system is configured to work in conjunction with the client's charge account statement and provide an identification or accounting of each item on the statement (as it relates to the travel data).
  • the client's travel and card transactions are loaded into an accounting database of system 110.
  • the system includes receipt of travel-related data (suitably stored in a travel database by the Company's travel or merchant vendor) from a stored travel record 116 and receipt of charge-related data (suitably stored in the charge card vendor's expense database) from a charge card vendor 120.
  • the travel and card vendors' databases may be networked to the accounting database of system 110, such as when the travel vendor and the card vendor are within the same corporate entity and stored on a back office accounting or billing system (e.g., American Express® Card Services and American Express® Travel Related Services); however, under most circumstances, data from the travel and card databases is remotely received, such as via a communications channel in an electronic format.
  • a back office accounting or billing system e.g., American Express® Card Services and American Express® Travel Related Services
  • the present system and method includes various functions to reconcile the client's account to the account balance.
  • Each function may be a logic routine within a suitable computer program stored in the accounting database of system 110 or in a computer program stored on the client workstation 102. It should be appreciated that the following brief description of the system and methods of the present invention are provided merely as representative of exemplary routines and therefore, all or some of the following functions and their corresponding block representations may be present, combined or modified as needed in a particular application.
  • the present invention builds on the traditional techniques of matching travel records with charge records.
  • the system considers each transaction on the client's card statement and searches the database for a corresponding travel transaction. If the matching ticket number is found in the travel data, the system verifies that the remaining basic matching criteria are met and the match is confirmed. An optional second verification may also be performed to confirm the presence of any additional client-defined accounting data elements as required by the client. Transactions that meet all the criteria are ready to be processed for payment and moved to an "Approved Items" list 111. Used herein, "list” may include any suitable means for processing, collecting, sorting, storing, retrieving, and the like, a group of processed data.
  • Unresolved Transactions Transactions that fail any of the basic matching criteria during auto- reconciliation (with the exception of transactions that are washed out, as described in detail below) are moved to an "Unresolved Transactions" list 115.
  • moved may refer to an electronic movement of data from one list or data table to another, or alternatively, may refer to maintaining or establishing a data link.
  • Unresolved Transactions list each item on the list is tracked through to correction.
  • the system includes, in an exemplary embodiment, a research tool to facilitate the research and correction of pending items.
  • the research tool displays all the details of the card transaction (from the database) and allows the user to specify criteria by which to search for a matching transaction (also in the database). When a matching (or closely related) transaction is located, the tool facilitates the correction of the card transaction and when complete, the corrected transaction is moved to the "Ready for Approval" list 113.
  • the Ready for Approval list 113 may be restricted to users with approval authority. A before-and-after picture of each transaction may be displayed to the user so that any edits made to the transactions may be reviewed. If the transaction is approved, the system moves the item from the Ready for Approval list 113 to the Approved Items list 111. Transactions that are not approved are moved back to the Unresolved Transactions list 115. A Billed Transaction Report 117 is created of all charges that are ready
  • a Summary Reconciliation Report 121 automatically reconciles account activity to the card account balance.
  • the system reads the beginning balance amount from the card statement, adds in the current month's activity (debits less credits per the monthly billing statement), subtracts payments received, and subtracts payments expected (i.e., totals from pending Billed Transaction Reports). The difference is the amount of the unresolved transactions.
  • the total of the transactions in the Unresolved Transactions list 115 is retrieved and displayed on Report 121. When the two amounts (the difference from the card statement and the Unresolved Transaction list) match, the account is in balance.
  • the system if during auto-reconciliation the system identifies an offsetting debit and credit for the same travel ticket, or if the system finds a credit which offsets a debit pending on the Unresolved Transactions list, the system "washes out” the transactions. Offsetting debits and credits are moved to a "Washed Out” list 119. This feature reduces the number of unmatched transactions that require research by identifying unmatched credits that offset unmatched debits, e.g., for tickets which have been voided. In addition, the number of transactions to process for payment is reduced by eliminating unnecessary entries on the Billed Transaction Report.
  • the system may further include a Refund module 123.
  • a Refund module 123 As tickets are turned in to the travel office for refund, the ticket information is entered into the module.
  • the system may print out a receipt for the traveler and then add the ticket to a refund log.
  • the refund log can be used to facilitate the refund process.
  • the refund log may print out transmittal logs for tickets to be forwarded to the Company's travel vendor for refund processing, or transmittal letters for tickets to be forwarded to the airline for refund processing.
  • the system updates the refund log, e.g., with the date and amount of the credit received, as well as the status of each credit (included on a Billed Transaction Report; on the Washed Out list; or on the Unresolved Transaction list).
  • the system may include the ability to reconcile transaction fees charged by, for example, the travel vendor. Often times, commissions paid by the airlines to the travel vendors are rebated back to the client. The system calculates the amount of the rebate due to the client for each ticket issued and subtracts the amount from the client's Billed Transaction Report. This amount can then be paid by the travel vendor directly to the card company. In this manner, clients are not required to reconcile and process rebate payments separately.
  • the system and methods of the present invention reconcile to an account balance by tracking all open items on the account through the reconciliation process until they are paid by the client or "washed-out" (clear themselves). Moreover, the system facilitates the research and correction of unmatched transactions, tracks pending refunds, and reconciles transaction fees.
  • the system and methods of the present invention reconcile to an account balance by tracking all open items on the account through the reconciliation process until they are paid by the client or "washed-out" (clear themselves).
  • the system facilitates the research and correction of unmatched transactions, tracks pending refunds, and reconciles transaction fees.
  • FIG. 2 is a flowchart 200 describing an exemplary embodiment for account reconciliation for a given cycle (e.g., monthly) in accordance with the present invention.
  • flowchart 200 (as well as any conjoining flowchart) is conveniently illustrated and described in connection with a particular industry, i.e., the travel agency industry. Therefore, reference is made herein to travel-related topics, modules, routines, and the like.
  • Travel tickets may get voided, returned or be otherwise unused.
  • the present invention includes management of all items on an account, including voided or unused items.
  • a refund log suitably stored on a Refund module of the system, is systematically updated with information pertaining to tickets returned for refund (step 201).
  • the Refund module is described in more detail below in Figure 3.
  • the system includes an accounting database configured to, among other functions, receive and store travel-related data and card-related data (i.e., charges) for each specific account (step 202).
  • travel-related data and card-related data i.e., charges
  • the travel and card data may be received from various databases within the system or, in many cases, from outside the system.
  • the reconciliation process generally begins with an auto-reconciliation process whereby for each charge transaction listed on the account, the system searches the travel-related data for a corresponding match (step 204).
  • the matching process occurs over several individual steps which will described in more detail below in Figure 4.
  • Matched items (as defined by the matching criteria) are automatically moved to an Approved Items list (step 205).
  • the Approved Items list holds (stores) all approved transactions until the system generates the accounting statements and/or reports. Because the accounting database pulls together many different functions and modules, and has access to a variety of data tables within itself, it is often the case that during auto- reconciliation, offsetting debits and credits that sum to zero are matched.
  • Unresolved Transactions list Travel and card transactions that do not meet the established matching criteria and do not "wash out” are moved to the Unresolved Transactions list (step 210). In this manner, unmatched or unresolved items are tracked and researched until they are reconciled, i.e., identified and corrected (step 212). Many times, a minor data entry error or misspelling triggers an unresolved item, e.g., incorrect ticket number on card statement. In one embodiment, authorized users may edit the erred data to correct unmatched items. The corrected item, i.e., travel entry, can now be matched with a corresponding charge entry.
  • the corrected item is moved, in an exemplary embodiment, to a Ready for Approval list and approved by the same or another authorized user (step 214).
  • the particular features of the Unresolved Transactions list and Ready for Approval list are described in more detail below in Figures 6a and 6b.
  • the remaining steps of the system include reports generation and will be described in greater detail below in Figure 7.
  • the system creates a Billed Transaction Report ("BTR") for the amount of all the charges that are ready to process for payment from the Approved Items list (step 216).
  • BTR Billed Transaction Report
  • the Payment Reconciliation Module is updated with the total of the BTR or, in other words, the amount of payment expected from the client (step 218).
  • the system suitably generates a Summary Reconciliation Report that expresses the reconciliation to the account balance (step 220).
  • the account balance includes, for example, all the activity on the account such as the prior billing cycle's outstanding balance, current cycle's activity, payments received, payments expected (BTR totals), and the total of the transactions in the Unresolved Transactions list.
  • BTR totals payments expected
  • Figure 3 is a flowchart 300 describing one embodiment for implementing an exemplary Refund Module in accordance with the present invention (i.e., step 201 ).
  • Figure 3 and the accompanying description further demonstrate, for example, that the system can operate as a complete refund management system.
  • data specific to each item returned for refund such as travel tickets, may be manually entered or electronically downloaded to the Refund Module (step 302).
  • the system generates a receipt for the client/traveler with complete details of the ticket which has been returned.
  • the system updates the Refund Log with the details of each item and maintains a list of the returned tickets (step 304). In this manner, the Log may be viewed at any time to check the status of a pending returned item.
  • This technique also helps to ensure that returned items are not forgotten after a long passage of time. In fact, until the offsetting credit is received or an authorized user approves the removal of the item, the pending returned item, in an exemplary embodiment, remains on the Log.
  • the system generates a transmittal log and/or letter for use in forwarding returned items for refund processing (step 306).
  • a transmittal log may be periodically generated indicating newly received returned items, or a changed status of a pending item, etc.
  • the system may generate an appropriate letter indicating the tickets that are to be returned to a particular airline, or the like, for refund processing. If a ticket is returned to an airline, or a letter is mailed out, the Refund Log is automatically updated to reflect, for example, where, when and to whom tickets and/or letters were sent (step 308).
  • Refunds for the returned items may be received from the airline directly and appear as credits in the client's card data.
  • auto-reconciliation will identify the information received relating to the credit (e.g., ticket number) and automatically match the offsetting credit with the pending returned item. Once the match is made (regardless of the manner), the Refund Log is automatically updated with the particular information of the credit, such as the date and the amount of the credit received, as well as the status of each credit (i.e., credit washed out against a pending debit on the Unresolved Transactions list; credit moved to the Unresolved Transactions list; credit included on a Billed Transaction Report) (step 310).
  • the user may specify an age for pending refunds (i.e., 30 days) and the system automatically causes the generation of a follow-up letter(s) or reminder(s) to the airline(s) to check on the status of any refunds not yet received (step 312).
  • the Refund Module may include a reporting function which generates activity reports for monitoring and managing the refund process (step 314).
  • FIG. 4 is a flowchart 400 describing one embodiment for implementing an exemplary matching process in accordance with the present invention (i.e., step 204).
  • matching criteria includes one or more factors which determine whether a match is present. In this manner, the system does not make assumptions on items that are "nearly matched", but rather, during auto-reconciliation the system considers whether all the factors are met and if so, a match is made.
  • the matching criteria may include, for example, "basic” matching criteria that determines a high level match, and "specific" data capture criteria that further determines if the matched items are ripe for payment.
  • the basic matching criteria may be non-negotiable by the client, while specific matching criteria may include client factors that are specific to a particular client, and defined by the client.
  • specific matching criteria may include client factors that are specific to a particular client, and defined by the client.
  • the client is able to set parameters for the user that define when the client perceives the item to be ripe for payment.
  • This additional criteria helps to reduce the number of charge disputes and client complaints.
  • the system reliably moves items to the Approved items list only after all the matching and data capture criteria (if any) are met and thus, providing enhanced confidence for the user and the client.
  • the matching criteria may include a matching tolerance.
  • a matching tolerance may include a dollar matching tolerance that will allow the system to override the strict matching criteria and make a match.
  • a client may approve specific matching criteria of $0.99 dollar tolerance.
  • the user e.g., travel agency, may include a dollar tolerance to automatically adjust and write off small differences to facilitate a match and payment processing. It should be noted that even if a matching tolerance is included, the system, in an exemplary embodiment, adheres to the predetermined matching criteria. In the present example, the matching criteria allows the system to make a match between transactions that do not have an exact dollar match.
  • the system considers each charge or card transaction and identifies one or more high level basic matching criteria to find a match (step 402).
  • a search of travel-related data is performed to find a matching transaction (step 404) by identifying a match of the first basic matching criteria.
  • the match is then confirmed (step 408). Confirmation further ensures that the match is valid by verifying that the remaining basic matching criteria are met. If no match is found (step 407) or the match cannot be confirmed (step 409), then the transaction is moved to the Unresolved Transactions list.
  • the basic matching criteria includes four factors, i.e., passenger name, ticket number, card number, and dollar amount.
  • the system searches for a matching ticket number and then verifies that the other three criteria match. If, for example, the passenger name, ticket number, and card number match, but the dollar amount is different, then the system will not match the card and travel transactions. Even though the ticket was used by the listed passenger, the passenger may have refunded part or all of the travel ticket at the airport and thus, the dollar amounts do not match.
  • the specific data criteria is the client defined data.
  • the system allows the individual client to develop parameters for the user to follow once the basic matching criteria have been met.
  • the client's parameters or factors may be more or less strict than the basic criteria, however, it is preferable that the basic criteria not be adjusted or waived.
  • client- specific data may include employee I.D., project code, department code, or travel authorization number; however, it should be appreciated that this criteria may be defined by the client and thus varies from application to application. In some instances or with some clients, there may not be any specific client defined data. In these cases, the transaction is automatically moved to the Approved Items list for payment processing (step 414).
  • step 412 If the system confirms the presence of all the specific client defined data (step 412) and the basic matching criteria is, in an exemplary embodiment, already verified, then the transactions are ready to be processed for payment and are automatically moved to the Approved Items list (step 414). Transactions that fail any of the matching criteria are moved to the Unresolved Transactions list so that they can be researched and corrected (step 413).
  • WASHOUT EXEMPLARY FLOWCHART Figure 5 is a flowchart 500 describing one embodiment for implementing an exemplary washout process in accordance with the present invention (i.e., step 206).
  • wash out includes a process during auto-reconciliation that results in offsetting debits and credits being automatically matched.
  • the system identifies a debit and a credit for the same travel transaction that sum to zero, the system recognizes that these two items are a match and may move them to the Washed Out list. It is not necessary to further process or reconcile either of the washed out card or travel transactions because, although there may have been a debit charge for the travel at one time, an offsetting credit has been received to clear the transaction.
  • both the card and travel data flows into the accounting database and occasionally a credit and a debit for the same travel transaction appear during the same processing cycle.
  • the system searches the card transactions which have been loaded into the accounting database (but not yet included on a Billed Transaction Report) for transactions where a debit and a credit have been received for the same ticket number (step 502).
  • the credit and debit completely offset (the summation is zero); therefore, the system queries whether this has occurred (step 504). If the credit and debit do not sum to zero, then no match is made and the credit and debit transactions are moved to the Unresolved Transactions list for research and correction (step 508).
  • the system may automatically move the credit and the debit transactions to the Washed Out list (step 506).
  • the client may choose not to use the Washed Out feature and thus in this situation the transactions would not move to a Washed Out list, but would move to the Approved Items list. Similar to the matching processes within the system, the wash out process does not make assumptions or "near matches".
  • the Washed Out List contains, in one embodiment, transactions that no longer require processing so the placement or storage of transactions here must be accurate.
  • wash out process occurs when the credit and debit do not appear within the same cycle.
  • the accounting database receives the charge-related data, there may be a charge corresponding to a voided ticket.
  • the auto-reconciliation process is unable to match the charge with a corresponding travel transaction because the ticket was voided and therefore no record of the travel transaction was ever loaded into the accounting database. Hence, the charge entry is an unmatched item and moved to the Unresolved Transaction list.
  • the offsetting credit for the voided ticket charge may be loaded into the accounting database and during subsequent auto-reconciliation processes, the system recognizes that the credit corresponds to an item on the Unresolved Items list (step 510).
  • the system queries whether the credit and debit sum to zero (step 504) and if so, may move the transactions to the Washed Out list (step 506). If the sum is not zero, then the credit transaction is also moved to the Unresolved Transactions list (step 508).
  • Figures 6a and 6b are a flowchart 600 describing one embodiment for implementing an exemplary unresolved transaction process in accordance with the present invention (i.e., steps 210-214).
  • the Unresolved Transactions list further demonstrates that the system is a management tool that reconciles to the entire account balance. In this sense, unmatched or otherwise unresolved transactions are moved to the Unresolved Transactions list to be researched and corrected. Items that do not wash out and fail to meet one or more of the auto reconciliation criteria are moved to the Unresolved Transactions list. Each item on the list is monitored, researched and corrected by authorized users of the system.
  • the system is, in an exemplary embodiment, not configured to process "near matches" or make assumptions on the quality of the data. Rather, the system, in an exemplary embodiment, identifies absolute matches and the user and client have little or no room to question the accuracy of the transactions which have been automatically approved. To maintain the integrity of the system, in an exemplary embodiment, the system is incapable of approving card and travel transactions if there is even a minor data entry error. For example, a passenger's name misspelled on a charge may preclude the system from approving the transaction which does not match the name on the related travel record. In one specific embodiment, the system permits authorized users to view the unresolved transactions (step 602). Authorized users (step 604) may be permitted to make edits to the unresolved transaction (step 606) and forward the edited transaction to the Ready for Approval list (step 609).
  • the user accesses a research tool created to facilitate the correction of pending unresolved items (step 608).
  • the tool causes the display of all the details of the pending item, e.g., a card transaction, and allows the user to specify criteria to search for a matching transaction, e.g., a travel transaction (step 610).
  • the tool may offer suggested search criteria or default criteria.
  • the user may override the strict matching criteria set by the system and thus the system can search for exact or near-exact corresponding matching transactions (step 612) (i.e., near-matches).
  • the system tool displays the located transactions and allows the user to choose the correct match (step 614).
  • the system moves the items to the Ready for Approval list (step 609).
  • the user is permitted to research items which partially match. For example, assume that a ticket is issued and a corresponding charge is made for $420.00. At the airport, the passenger is informed that his next flight has been cancelled, e.g., due to bad weather, and the airline issues a partial credit in the amount of $120.00. The traveler returns and informs Company A that he did not travel and thus Company A refuses to pay the original ticket charge in the amount of $420.00. The charge of $420.00 is moved to the Unresolved Items list.
  • the system When the credit for $120.00 is received, the system will not match the credit with the debit of $420.00 because the dollar amounts do not match.
  • the credit of $120.00 will also be moved to the Unresolved Transactions list.
  • An authorized user viewing the Unresolved Transactions list can easily recognize there are multiple card transactions (credit and debit) for the same ticket number and deduce that a partial credit was received. The user is allowed to apply the credit against the debit and match the remaining balance with the travel transaction. Again, the transaction is moved to the Ready for Approval list pending approval and payment processing (step 609).
  • This process ensures that unmatched transactions are not forgotten or partial matches are not improperly captured on a BTR, but rather, the client is properly billed for the correct amount (e.g., in the above example, the client would be billed for $300.00 (the original debit less the received credit)).
  • the Ready for Approval list provides a security measure to further maintain the integrity of the processes.
  • several tiers of approval authority may be installed to permit varied levels of access. At one level, an authorized user may be granted access to edit ticket numbers, passenger's names and dollar amounts, but will be restricted access to approve the transaction and move it to the Approved Items list. Any change by a user may cause concern for creating additional errors. In this sense, a final approval made by a user with a higher level of authority may be preferred.
  • a transaction selected for approval is displayed to an authorized user (step 618).
  • the system may query the authority level of the user and restrict access if the authority level required is not met (step 620).
  • the system may cause the display of a "before-and-after" picture of the corrected transaction for the authorized approval user (step 622).
  • the viewer may see the pre-edit or pre-matched transactions and the post-edit or post-matched transactions.
  • the approver can view the correction and verify the accuracy of the change, if any. In some cases, there may not have been an edit to the transactions, but a billing amount that is different than the travel invoice amount has been accepted by the authorized user.
  • step 624 If the approver agrees with the match or change (step 624), the transaction is moved to the Approved Items list (step 626). If, however, the approver does not approve the transaction, the approver can send the transaction back to the Unresolved Transactions list for further research and correction (step 625).
  • REPORTS GENERATION EXEMPLARY FLOWCHART Figure 7 is a flowchart 700 describing one embodiment for implementing an exemplary reports generation process in accordance with the present invention (i.e., steps 216-222). It should be appreciated that various items may be summarized and generated into a desired report. The description of reports provided herein are provided as examples and not intended to be limiting in any manner.
  • the Approved Items list holds all the transactions that have met the matching criteria during auto-reconciliation, and all the transactions that have been finally approved by an authorized user (i.e., Figures 6a-6b).
  • the system automatically captures all of the transactions that are ready to be processed for payment (step 702) and generates a Billed Transaction Report ("BTR") (step 704). No further approval is typically required because each of the transactions have either met the predetermined matching criteria or have been finally approved.
  • BTR Billed Transaction Report
  • the Billed Transaction Report is generally not a billing statement, but rather, is used as a reconciliation tool for the client to identify each of the charges on its card statement (i.e., received from its credit card company).
  • the client typically receives a bill from its credit card company for all charged transactions during a given billing cycle.
  • the Billed Transaction Report, and present invention in general, are designed to complement the client's current billing and payment methods by providing an identification of all charges on the client's billing statement (i.e., reconciling to the account balance) that the client has specified are ripe for payment.
  • the system prints a copy of the Billed Transaction Report during a given cycle for the client's review.
  • the Billed Transaction Report may be provided to the client in an electronic format, e.g., over a suitable communications network.
  • the client side may include suitable software to enable the Billed Transaction Report to be imported into the client's own accounting system.
  • a Payment Reconciliation Module for the client is updated to reflect the total amount of the current Billed Transaction Report (step 706).
  • the Payment Reconciliation Module is an accounting for the Billed Transaction Report.
  • the Payment Reconciliation Module may include an entry for the total of the Billed Transaction Report and an entry for the "open" amount remaining.
  • the open amount remaining is reduced by the amount of the payment.
  • the client will submit payment that equals the total of the Billed Transaction Report, however, this may not always be the case. For instance, the client may have disputed a charge on the statement, and even on the Billed Transaction Report, and thus not submitted payment for that charge.
  • the Payment Reconciliation Module tracks the amount of payments received from the client and identifies any remaining balance (open amounts) on the Billed Transaction Report (step 708). The user can then match the remaining balance with a particular transaction on the Billed Transaction Report and determine which item was unpaid by the client (step 710).
  • a Summary Reconciliation Report for the client's account automatically reconciles the activity on the client's account to the account balance (step 712). This operation is described in more detail below.
  • Figure 8 illustrates an example of the Summary Reconciliation Report screen 800 a user (client side) will see. The screen 800 shows the user that the account (expressed in dollar amounts) is reconciled to the account balance.
  • the system begins with and displays the prior billing cycle's ending balance from the client's card statement 801.
  • the current cycle's activity (new charges and credits) 804 is then displayed and added to the ending balance, along with any new fees 806 the client is to be responsible for.
  • the dollar amounts of payments, if any, received on the account 808 are subtracted from the balance.
  • Expected, or pending payments 810 are displayed on the screen 800.
  • the expected payments include total amounts from the BTR(s) and more specifically, from the Payment Reconciliation Module.
  • the Payment Reconciliation Module tracks the BTRs and any payments received on the account are applied against the outstanding BTR balance.
  • the BTR total 810 is subtracted from the balance (at this point the balance equals 802 + 804 + 806 - 808).
  • the total dollar amount of all the pending transactions in the accounting database 812 is then displayed. These transactions were loaded into the database from the client's card statement, but have not undergone auto-reconciliation. Therefore, this dollar amount is accounted for (albeit still pending) and subtracted from the remaining statement balance.
  • the totals of the Ready for Approval list 814 and Approved Items list 816 are then subtracted from the remaining balance.
  • the ending balance 818 after all additions and subtractions is the final remaining balance.
  • the account is reconciled to the client's account balance.
  • the total of the transactions pending on the Unresolved Transactions list 820 is displayed.
  • the ending balance 818 and Unresolved Items 820 amounts match, the account is in balance.

Abstract

An account reconciliation system having a particular usefulness in the reconciliation of centrally billed accounts and more specifically, in the reconciliation of centrally billed accounts (107) in the travel industry is provided (116). The system and methods of the present invention expand on the traditional match/non-match techniques and provide complete transaction management for every item on a client's account (102). In another sense, reconciliation is redefined to include each and every transaction on an account regardless of it's reconciliation status, i.e., matched (111), unresolved (115), pending, etc. Consequently, the present invention reconciles the client's account to the account balance (121).

Description

SYSTEM AND METHOD FOR ACCOUNT RECONCILIATION
FIELD OF INVENTION
The invention relates generally to account reconciliation and, in particular, to travel "central bill" account reconciliation. More specifically, the invention relates to a system and method for identifying transactions on a centrally billed travel account and reconciling to the account balance.
BACKGROUND OF THE INVENTION Central billing is a common accounting practice often used by large employee-based companies. In general, central billing typically occurs when a card vendor assigns a common account billing number that can be used by multiple employees or authorized personnel to charge authorized items to the company. The company usually receives a single bill at the end of the billing cycle for all its employees' charges.
In the travel industry, central billing is especially popular and a service offered by most card vendors. As an example, Company A may request a charge card company to assign a Company account number to be used for all of Company As charged airline tickets or other travel related charges. In this manner, when an authorized person from Company A requests a ticket from Company As travel agency, the charges will be automatically placed on the Company account instead of the individual's account. Charges throughout a specified billing cycle, e.g., monthly, accrue on the Company's account number for numerous employees and tickets. At the end of the billing cycle, a single bill for all the charges made using the Company account number as the form of payment is usually remitted to the Company for payment. Most companies enjoy the simplicity of receiving one bill for payment at the end of each billing cycle instead of having literally hundreds of individual bills remitted to their travelers.
Central billing, however, creates numerous problems in the area of account reconciliation. Often times the bill recipient, e.g., Company A, includes in its contract with its travel vendor the non-trivial requirement to reconcile the monthly statements issued by its card vendor for its centrally billed account(s): i.e., identify each charge and credit on each account, calculate the total amount of the charges determined to be correct and ready to be paid, and properly apply applicable rebates and fees. In addition, the central billing reconciliation process often escalates as the volume of individual items on each account increases.
The traditional account reconciliation process for centrally billed accounts is a "match/non-match" approach. Continuing with the above example, the travel agency typically receives an electronic copy of the card statement listing all the travel transactions (charges and credits) billed during the cycle. The travel agency conducts a one-time match against Company As charges and Company As travel records typically based on a ticket number and creates a list of matched items and a list of unmatched items. Matched items are subsequently forwarded to the Company on a report, which includes the identifying accounting information, such as the travel authorization number, employee ID, project code, or the like captured in the employees' original travel records.
The unmatched items, which include any charge records that do not have corresponding travel records, e.g., tickets that were voided after the day of issue, modifications to tickets made at the airport, and data entry errors (e.g., misspellings), remain unidentified. Typically, companies refuse to pay for unmatched items because many times the company is unable to establish a proper explanation of the charge, e.g., which employee charged the travel ticket. The bill reconciler must then research each unmatched item in order to explain the charge and resubmit for payment. In a voluminous industry, such as the travel/ticket industry, this research process is cumbersome and very time consuming. In addition, it is often the case that the reconciler is simply unable to identify the item when the airline provides incomplete data. Thus, the unmatched item is left unpaid and eventually becomes a write-off for the card vendor.
Most credit card companies have moved to electronic credit card processing which often further complicates central bill account reconciliation. For example, if an authorized employee from Company A purchases a travel ticket from the travel agency on Monday using the centrally billed card account, the card charge is processed electronically and nearly immediately by the card company. So on Tuesday, Company As travel company shows the record of the ticket issued and its charge card company shows receipt of the charge record. At the end of each week, travel agencies submit reports of ticket sales to the airlines through the Airline Reporting Corporation (ARC). ARC oversees settlement processing for all airlines and charge card vendors to include an accounting of the number of tickets issued and dollars charged. Until Friday of each week, the travel agency has the opportunity to void the travel record/ticket from Company As ARC report as if it never existed; however, it cannot similarly void the transaction on the Company's central bill account. If the travel agency voids Company As ticket on Thursday, for example, the charge on the Company's credit card account, which has already been processed, will remain. At the end of the week, when the travel agency submits its sales report to ARC, ARC sees that a ticket has been voided and generates a correcting credit to the Company's central bill account for the voided ticket. When these transactions appear on the Company's account, they are unmatched items. In other words, a charge record for Company A is presented for matching to a ticket record for a ticket that was issued in week one, but which no longer exists. The credit for the voided ticket, which was generated by ARC in week two, is also presented with no matching charge record. In the event that these transactions take place within the established billing cycle of Company A, a chance exists that these debit and credit transactions will appear together on the same month's central bill account. However, in about at least twenty-five percent of the cases, the debit and credit will not appear on the same monthly statement, thus further complicating the reconciliation process.
Additionally, many credit card vendors, like American Express® and Diners Club®, do not permit "carry-over" balances and all charges during the billing cycle are due upon receipt of the bill. In this sense, the Company is asked to pay all the transactions on their account, whether or not a reconciled match is made for each one. Thus, if the debits and credits do not appear in the same cycle, the company may be billed for an item which has been voided, returned, or otherwise not received. Many times, this "overbilling" results in a charge dispute. Therefore, while traditional reconciliation processes generally match a high percentage of the items, this approach is still inadequate. Even a small percentage of unmatched items can equate to a large number of unmatched and unresolved entries that must be researched and corrected.
A system and method for account reconciliation that includes a traditional matching technique to identify and resolve matched items, as well as a tracking, research and correction technique to identify and resolve the unmatched items is needed. Moreover, a system and method for account reconciliation that identifies, tracks and reconciles pending transactions to the account balance, including all accounting items whether matched or unmatched, is needed.
SUMMARY OF THE INVENTION The present invention provides an improved system and method for account reconciliation that expands and builds on traditional matching techniques. In particular, the present invention provides an account reconciliation system and technique to reconcile each entry on an account, irrespective of whether the item is a matched or unmatched entry.
The system includes a client side and a server side with a communication channel that joins the sides together and includes an accounting database capable of receiving and storing data relating to an account. A software program may also be included that includes programming to automatically match the received data and automatically compile the matched data and remaining unmatched data. A user is permitted to view the unmatched data and direct the system to search the database and accept a match. A user is also permitted to edit the unmatched data. The system further includes programming to generate a reconciliation report comprising a verification that the account is reconciled to the account balance.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other features, aspects and advantages of the present invention may be best understood by reference to the following description taken in conjunction with the accompanying drawings in which like numerals represent like elements:
Figure 1 a is an exemplary diagram of a computer-based architecture that can be used to implement an account reconciliation system of the present invention;
Figure 1b is an exemplary top level block diagram illustrating an environment in which an account reconciliation system can function and operate according to one embodiment of the present invention;
Figure 2 is an exemplary flowchart describing one embodiment for account reconciliation in accordance with the present invention; Figure 3 is an exemplary flowchart describing one embodiment of the present invention for refund management;
Figure 4 is an exemplary flowchart describing one embodiment of the present invention for matching transactions; Figure 5 is an exemplary flowchart describing one embodiment of the present invention for washing out transactions;
Figures 6a and 6b are exemplary flowcharts each describing one embodiment of the present invention for unresolved transaction management;
Figure 7 is an exemplary flowchart describing one embodiment of the present invention for report generation; and
Figure 8 is an exemplary screen shot of a Summary Reconciliation Report available to a user in accordance with the system and methods of the present invention.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
The present invention provides an improved system and method for account reconciliation having particular usefulness in the reconciliation of centrally billed accounts. Although the system and methods disclosed herein may be suitable for reconciliation of centrally billed accounts in a variety of applications, the present invention is conveniently described with reference to the travel industry, and more particularly to account reconciliation of travel records and charge records. In addition, reference is made throughout to the travel ticket industry; however, it should be recognized that the present invention has equal application to various other industries within the travel agencies' domain, such as lodging and rental car account reconciliation and outside of the travel domain, such as office supplies, computer access and/or expenses that could be consolidated into centrally billed accounts.
In general, the present invention expands the traditional match/non-match technique for account reconciliation. In other words, simply matching debits to credits in the traditional approach routinely reconciles the majority of the items on an account, and hence, the traditional approach is maintained in the initial steps of the present invention. The present invention then goes beyond simply identifying matched and unmatched items and provides complete management of every item on an account. In another sense, the present invention reconciles the entire account balance through management of each item on the account regardless of its reconciliation status.
The present invention redefines the traditional approach of determining when an item is ready for payment by recognizing that clients generally pay according to their own definitions of a "match". Traditional approaches generally do not sufficiently consider the quality of data used to determine a match. Often times what appears to match may not meet the stricter reconciliation requirements set by the client. The present invention permits flexibility in the reconciliation process according to each client's criteria, such as, for example, accounting criteria. Clients can also set guidelines to indicate when their reconciliation requirements are met, to indicate that they are willing to remit payment. In other words, one client may be satisfied that an item is ready for payment under certain conditions which are quite different from the conditions established by another client. The system and method of the present invention identifies most the problems that keep entities from paying and provides a solution and opportunity to correct them, by tracking each one until it is sufficiently resolved, i.e., reconciling the account balance. This technique ultimately results in resolution of all of the account items, because unmatched items are not forgotten, as with traditional techniques, but are instead tracked until each item is removed from the outstanding account balance. By tracking and managing each item on a client's centrally billed card account, the reconciler and the client are ensured that ultimately all the items on the account will be resolved. Reconciliation to the account balance (i.e., the tracking of all open items on the account) results in less write-offs due to nonpayment of unreconciled account balances, and the research and correction of unmatched transactions results in a simpler bill reconciliation process with less margin for dispute. One skilled in the art will appreciate that resolution of "all" the account items may include various tolerance levels for resolutions or predetermined numbers or levels of matched items implemented by the system and/or requested by the client. ACCOUNT RECONCILIATION SYSTEM
Exemplary system components are provided below to facilitate understanding of the invention and its best mode. It should be recognized that various other components may be used without departing from the spirit of the invention as intended. For the sake of brevity, conventional techniques for signal processing, data transmission, signaling and network control, and other functional aspects of the systems (and components of the individual operating components of the systems) may not be described in detail herein. Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in a practical network communications system.
Figure 1a is a simplified diagram illustrating an exemplary computer-based architecture 10 that can be used to implement the account reconciliation system in accordance with the present invention. The account reconciliation system may be implemented in a commonly known client/server architecture having a client side 12, 13 and a server side 17. The client side 12, 13 typically includes a computing device that includes, in one embodiment, a display and input means such as a keyboard, mouse, kiosk, personal digital assistant, handheld computer, portable computer and/or cellular phone. As illustrated in the present example, client 12 is a portable computer and client 13 is a personal computer. It should be realized that two clients are illustrated for exemplary purposes only and that any number of clients may be included in the architecture. The client typically includes an operating system (e.g., a version of Windows (Windows NT, Windows 98/2000/Millenium)), as well as various conventional support software and drivers typically associated with computers, computing devices, and the like. For example, the client side generally includes a modem (e.g., 56K baud) 14, 15 for facilitating access to a network.
The server side 17 may broadly include a server 18, a system administrator 19, and a modem pool 20, electrically linked together. Modem pool 20 send electrical signals to server 18 and is used to transceive electrical signals from the client modems 14, 15. The modem pool 20 may provide some protocol conversion to optimize modem performance, eliminate handoff retrain, and provide precise setting of transmit levels. The server side 17 typically includes a computing device having a processor for processing digital data, a memory coupled to the processor for storing digital data, an input digitizer coupled to the processor for inputting digital data, and an application program stored in the processor. Server 18 may be implemented as any suitable processing server, in an exemplary embodiment, including tables, objects, triggers, and stored procedures. For example, a Microsoft® SQL 6.5 Server database has been successfully utilized as server 18.
As will be appreciated, system administrator 19 includes a computing device that preferably includes a display and input means such as a keyboard, mouse, kiosk, personal digital assistant, handheld computer, portable computer and/or cellular phone to facilitate communications with server 18. System administrator 19 further preferably includes a suitable operating system stored thereon, e.g., Microsoft® NT Workstation. System administrator 19 suitably receives data which is loaded onto one or more databases of server 17. For example, with respect to one particular application relating to the travel industry, travel data 21 , card data 22, and third party data 23 are electronically loaded and stored in server 17. Third party data 23 may or may not be included in the system and generally includes travel and card data from vendors not associated with travel data 21 and card data 22. For example, in one specific embodiment, American Express® travel data, American Express® card data, and non-American Express (third party) card and travel data may be electronically received and stored in the server.
Figure 1 b is a top level block diagram illustrating an environment in which an account reconciliation system in accordance with the present invention can function and operate. The account reconciliation system (hereinafter, referred to as the "system") 110 includes a front end (client) 102 and a back end (server) 107. As those skilled in the art will appreciate, the front end 102 typically includes a computer, computing device, or the like. The back end 107 typically includes a server, such as a host server or other computing system, and a plurality of databases. In an exemplary embodiment, system 110 includes one or more relational databases, which reside in a data storage medium. Travel or merchant data 112 and financial (card) data 114 are included in the relational databases for each client. One skilled in the art will also appreciate that, for security reasons, any databases, systems or components of the present invention may consist of any combination of databases or components at a single location or at multiple locations, wherein each database or system includes any of various suitable security features, such as firewalls, access codes, encryption, de-encryption, compression, decompression, and/or the like. Database may be any type of database, such as relational, hierarchical, object-oriented, and/or the like. Common database products that may be used to implement the databases include DB2 by IBM (White Plains, NY), any of the database products available from Oracle Corporation (Redwood Shores, CA), Microsoft Access by Microsoft Corporation (Redmond, Washington), or any other database product. Database may be organized in any suitable manner, including as data tables or lookup tables. Association of certain data may be accomplished through any data association technique known and practiced in the art. For example, the association may be accomplished either manually or automatically. Automatic association techniques may include, for example, a database search, a database merge, GREP, AGREP, SQL, and/or the like. The association step may be accomplished by a database merge function, for example, using a "key field" in each of the manufacturer and retailer data tables. A "key field" partitions the database according to the high-level class of objects defined by the key field. For example, a certain class may be designated as a key field in both the first data table and the second data table, and the two data tables may then be merged on the basis of the class data in the key field. In this embodiment, the data corresponding to the key field in each of the merged data tables is preferably the same. However, data tables having similar, though not identical, data in the key fields may also be merged by using AGREP, for example. Communication between the front end and back end is accomplished through any suitable communications network 105 for exchanging data or transacting business such as, a telephone network, intranet, Internet, extranet, WAN, LAN, satellite communications, point of interaction device, online communications, off-line communications, wireless communications, and the like. In one particular application, the system is implemented as an Internet-based application having a front end, a back end, a web browser and web pages. The computer may provide a suitable website or other Internet-based graphical user interface which is accessible by users. In one embodiment, the Internet Information Server, Microsoft Transaction Server, and Microsoft SQL Server, are used in conjunction with the Microsoft operating system, Microsoft NT web server software, a Microsoft SQL database system, and a Microsoft Commerce Server. Additionally, components such as Access Sequel Server, Oracle, MySQL, Intervase, etc., may be used to provide an ADO-compliant database management system. The term "web page" as it is used herein is not meant to limit the type of documents and applications that might be used to interact with the user. For example, a typical website might include, in addition to standard HTML documents, various forms, Java applets, Javascript, active server pages (ASP), common gateway interface scripts (CGI), extensible markup language (XML), dynamic HTML, cascading style sheets (CSS), helper applications, plug-ins, and the like.
As previously stated, the present invention has a particular application to the travel agency industry. In general, a computer reservation system (CRS) 118 or global distribution system (GDS) (e.g., at the travel agency) captures the travel and charge data in a travel reservation. The CRS issues the travel ticket and forwards travel records 116 to a suitable storage or accounting system. In a similar manner, the CRS notifies the charge card vendor 120 that a travel purchase is made on the traveler's credit card. The CRS, or travel agency, submits the weekly report of tickets issued and dollars charged to ARC 122. The client's card vendor 120 issues a periodic card statement to the client which includes all of the charges incurred on the client's charge account during the billing period. The present system is configured to work in conjunction with the client's charge account statement and provide an identification or accounting of each item on the statement (as it relates to the travel data). In this sense, the client's travel and card transactions are loaded into an accounting database of system 110. The system includes receipt of travel-related data (suitably stored in a travel database by the Company's travel or merchant vendor) from a stored travel record 116 and receipt of charge-related data (suitably stored in the charge card vendor's expense database) from a charge card vendor 120. In some instances, the travel and card vendors' databases may be networked to the accounting database of system 110, such as when the travel vendor and the card vendor are within the same corporate entity and stored on a back office accounting or billing system (e.g., American Express® Card Services and American Express® Travel Related Services); however, under most circumstances, data from the travel and card databases is remotely received, such as via a communications channel in an electronic format.
The present system and method includes various functions to reconcile the client's account to the account balance. Each function may be a logic routine within a suitable computer program stored in the accounting database of system 110 or in a computer program stored on the client workstation 102. It should be appreciated that the following brief description of the system and methods of the present invention are provided merely as representative of exemplary routines and therefore, all or some of the following functions and their corresponding block representations may be present, combined or modified as needed in a particular application.
With continued reference to Figure 1b, the present invention builds on the traditional techniques of matching travel records with charge records. The system considers each transaction on the client's card statement and searches the database for a corresponding travel transaction. If the matching ticket number is found in the travel data, the system verifies that the remaining basic matching criteria are met and the match is confirmed. An optional second verification may also be performed to confirm the presence of any additional client-defined accounting data elements as required by the client. Transactions that meet all the criteria are ready to be processed for payment and moved to an "Approved Items" list 111. Used herein, "list" may include any suitable means for processing, collecting, sorting, storing, retrieving, and the like, a group of processed data.
Transactions that fail any of the basic matching criteria during auto- reconciliation (with the exception of transactions that are washed out, as described in detail below) are moved to an "Unresolved Transactions" list 115. It should be noted that "moved" may refer to an electronic movement of data from one list or data table to another, or alternatively, may refer to maintaining or establishing a data link. On the Unresolved Transactions list, each item on the list is tracked through to correction. The system includes, in an exemplary embodiment, a research tool to facilitate the research and correction of pending items. The research tool displays all the details of the card transaction (from the database) and allows the user to specify criteria by which to search for a matching transaction (also in the database). When a matching (or closely related) transaction is located, the tool facilitates the correction of the card transaction and when complete, the corrected transaction is moved to the "Ready for Approval" list 113.
The Ready for Approval list 113 may be restricted to users with approval authority. A before-and-after picture of each transaction may be displayed to the user so that any edits made to the transactions may be reviewed. If the transaction is approved, the system moves the item from the Ready for Approval list 113 to the Approved Items list 111. Transactions that are not approved are moved back to the Unresolved Transactions list 115. A Billed Transaction Report 117 is created of all charges that are ready
(approved) to process for payment and includes all the transactions on the Approved Items list 111. A Summary Reconciliation Report 121 automatically reconciles account activity to the card account balance. The system reads the beginning balance amount from the card statement, adds in the current month's activity (debits less credits per the monthly billing statement), subtracts payments received, and subtracts payments expected (i.e., totals from pending Billed Transaction Reports). The difference is the amount of the unresolved transactions. To verify the reconciliation, the total of the transactions in the Unresolved Transactions list 115 is retrieved and displayed on Report 121. When the two amounts (the difference from the card statement and the Unresolved Transaction list) match, the account is in balance.
Additionally, if during auto-reconciliation the system identifies an offsetting debit and credit for the same travel ticket, or if the system finds a credit which offsets a debit pending on the Unresolved Transactions list, the system "washes out" the transactions. Offsetting debits and credits are moved to a "Washed Out" list 119. This feature reduces the number of unmatched transactions that require research by identifying unmatched credits that offset unmatched debits, e.g., for tickets which have been voided. In addition, the number of transactions to process for payment is reduced by eliminating unnecessary entries on the Billed Transaction Report.
The system may further include a Refund module 123. As tickets are turned in to the travel office for refund, the ticket information is entered into the module. The system may print out a receipt for the traveler and then add the ticket to a refund log. The refund log can be used to facilitate the refund process. For example, the refund log may print out transmittal logs for tickets to be forwarded to the Company's travel vendor for refund processing, or transmittal letters for tickets to be forwarded to the airline for refund processing. When the credits for the refunds appear on subsequent billing statements, the system updates the refund log, e.g., with the date and amount of the credit received, as well as the status of each credit (included on a Billed Transaction Report; on the Washed Out list; or on the Unresolved Transaction list).
Moreover, the system may include the ability to reconcile transaction fees charged by, for example, the travel vendor. Often times, commissions paid by the airlines to the travel vendors are rebated back to the client. The system calculates the amount of the rebate due to the client for each ticket issued and subtracts the amount from the client's Billed Transaction Report. This amount can then be paid by the travel vendor directly to the card company. In this manner, clients are not required to reconcile and process rebate payments separately.
As briefly discussed, the system and methods of the present invention reconcile to an account balance by tracking all open items on the account through the reconciliation process until they are paid by the client or "washed-out" (clear themselves). Moreover, the system facilitates the research and correction of unmatched transactions, tracks pending refunds, and reconciles transaction fees. In addition to the above briefly described features, there are various other features and options of the present invention which will become apparent from the following description and referenced flowcharts.
ACCOUNT RECONCILIATION EXEMPLARY FLOWCHART
The various operations of the present invention will now be discussed to further facilitate understanding of the invention and its best mode. It should be appreciated that the particular implementations shown and described are illustrative of embodiments of the invention (including its best mode) and are not intended to limit the scope of the present invention in any way.
Figure 2 is a flowchart 200 describing an exemplary embodiment for account reconciliation for a given cycle (e.g., monthly) in accordance with the present invention. For ease of understanding, flowchart 200 (as well as any conjoining flowchart) is conveniently illustrated and described in connection with a particular industry, i.e., the travel agency industry. Therefore, reference is made herein to travel-related topics, modules, routines, and the like.
As is common in the travel industry, travel plans are often changed and/or canceled altogether. Travel tickets may get voided, returned or be otherwise unused. The present invention includes management of all items on an account, including voided or unused items. In this manner, a refund log, suitably stored on a Refund module of the system, is systematically updated with information pertaining to tickets returned for refund (step 201). The Refund module is described in more detail below in Figure 3.
As previously mentioned, the system includes an accounting database configured to, among other functions, receive and store travel-related data and card- related data (i.e., charges) for each specific account (step 202). The travel and card data may be received from various databases within the system or, in many cases, from outside the system.
The reconciliation process generally begins with an auto-reconciliation process whereby for each charge transaction listed on the account, the system searches the travel-related data for a corresponding match (step 204). In one embodiment of the present invention, the matching process occurs over several individual steps which will described in more detail below in Figure 4. Matched items (as defined by the matching criteria) are automatically moved to an Approved Items list (step 205). The Approved Items list holds (stores) all approved transactions until the system generates the accounting statements and/or reports. Because the accounting database pulls together many different functions and modules, and has access to a variety of data tables within itself, it is often the case that during auto- reconciliation, offsetting debits and credits that sum to zero are matched. These "washed out" transactions (i.e., add to zero) may not be forwarded to the client on a statement or report since there is no payment or credit due. Rather, the washed out transactions may be are moved to a Washed Out List (step 206). The Washed Out list is described in more detail below in Figure 5.
Travel and card transactions that do not meet the established matching criteria and do not "wash out" are moved to the Unresolved Transactions list (step 210). In this manner, unmatched or unresolved items are tracked and researched until they are reconciled, i.e., identified and corrected (step 212). Many times, a minor data entry error or misspelling triggers an unresolved item, e.g., incorrect ticket number on card statement. In one embodiment, authorized users may edit the erred data to correct unmatched items. The corrected item, i.e., travel entry, can now be matched with a corresponding charge entry. In this particular embodiment, the corrected item is moved, in an exemplary embodiment, to a Ready for Approval list and approved by the same or another authorized user (step 214). The particular features of the Unresolved Transactions list and Ready for Approval list are described in more detail below in Figures 6a and 6b. In general, the remaining steps of the system include reports generation and will be described in greater detail below in Figure 7. The system creates a Billed Transaction Report ("BTR") for the amount of all the charges that are ready to process for payment from the Approved Items list (step 216). The Payment Reconciliation Module is updated with the total of the BTR or, in other words, the amount of payment expected from the client (step 218). The system suitably generates a Summary Reconciliation Report that expresses the reconciliation to the account balance (step 220). The account balance, as previously explained, includes, for example, all the activity on the account such as the prior billing cycle's outstanding balance, current cycle's activity, payments received, payments expected (BTR totals), and the total of the transactions in the Unresolved Transactions list. Lastly, as payments are received from the client, the Payment Reconciliation Module is updated and expected payments (BTR totals) are reconciled with the amounts received (step 222).
REFUND MODULE EXEMPLARY FLOWCHART
Figure 3 is a flowchart 300 describing one embodiment for implementing an exemplary Refund Module in accordance with the present invention (i.e., step 201 ). Figure 3 and the accompanying description further demonstrate, for example, that the system can operate as a complete refund management system. As travelers return unused coupons and/or tickets for refund, data specific to each item returned for refund, such as travel tickets, may be manually entered or electronically downloaded to the Refund Module (step 302). In one specific embodiment, the system generates a receipt for the client/traveler with complete details of the ticket which has been returned. The system updates the Refund Log with the details of each item and maintains a list of the returned tickets (step 304). In this manner, the Log may be viewed at any time to check the status of a pending returned item. This technique also helps to ensure that returned items are not forgotten after a long passage of time. In fact, until the offsetting credit is received or an authorized user approves the removal of the item, the pending returned item, in an exemplary embodiment, remains on the Log.
In a specific embodiment, the system generates a transmittal log and/or letter for use in forwarding returned items for refund processing (step 306). For example, a transmittal log may be periodically generated indicating newly received returned items, or a changed status of a pending item, etc. In yet another embodiment, the system may generate an appropriate letter indicating the tickets that are to be returned to a particular airline, or the like, for refund processing. If a ticket is returned to an airline, or a letter is mailed out, the Refund Log is automatically updated to reflect, for example, where, when and to whom tickets and/or letters were sent (step 308).
Refunds for the returned items may be received from the airline directly and appear as credits in the client's card data. In some instances, auto-reconciliation will identify the information received relating to the credit (e.g., ticket number) and automatically match the offsetting credit with the pending returned item. Once the match is made (regardless of the manner), the Refund Log is automatically updated with the particular information of the credit, such as the date and the amount of the credit received, as well as the status of each credit (i.e., credit washed out against a pending debit on the Unresolved Transactions list; credit moved to the Unresolved Transactions list; credit included on a Billed Transaction Report) (step 310). In one specific embodiment, the user may specify an age for pending refunds (i.e., 30 days) and the system automatically causes the generation of a follow-up letter(s) or reminder(s) to the airline(s) to check on the status of any refunds not yet received (step 312). Lastly, the Refund Module may include a reporting function which generates activity reports for monitoring and managing the refund process (step 314). MATCHING EXEMPLARY FLOWCHART
Figure 4 is a flowchart 400 describing one embodiment for implementing an exemplary matching process in accordance with the present invention (i.e., step 204). It should be noted that used herein, "matching criteria" includes one or more factors which determine whether a match is present. In this manner, the system does not make assumptions on items that are "nearly matched", but rather, during auto-reconciliation the system considers whether all the factors are met and if so, a match is made. The matching criteria may include, for example, "basic" matching criteria that determines a high level match, and "specific" data capture criteria that further determines if the matched items are ripe for payment. For example, the basic matching criteria may be non-negotiable by the client, while specific matching criteria may include client factors that are specific to a particular client, and defined by the client. In this manner, the client is able to set parameters for the user that define when the client perceives the item to be ripe for payment. This additional criteria helps to reduce the number of charge disputes and client complaints. Moreover, the system reliably moves items to the Approved items list only after all the matching and data capture criteria (if any) are met and thus, providing enhanced confidence for the user and the client.
In one specific embodiment, the matching criteria may include a matching tolerance. For example, because the system is, in an exemplary embodiment, configured to provide accurate and absolute matches, often times a minor error such as a $0.01 difference between the travel and charge transactions will prevent a match. As such, the system includes a dollar matching tolerance that will allow the system to override the strict matching criteria and make a match. In the above example, a client may approve specific matching criteria of $0.99 dollar tolerance. Alternatively, the user, e.g., travel agency, may include a dollar tolerance to automatically adjust and write off small differences to facilitate a match and payment processing. It should be noted that even if a matching tolerance is included, the system, in an exemplary embodiment, adheres to the predetermined matching criteria. In the present example, the matching criteria allows the system to make a match between transactions that do not have an exact dollar match.
In one specific embodiment, the system considers each charge or card transaction and identifies one or more high level basic matching criteria to find a match (step 402). A search of travel-related data is performed to find a matching transaction (step 404) by identifying a match of the first basic matching criteria. When a record with the matching criteria is found in the travel data (step 406), the match is then confirmed (step 408). Confirmation further ensures that the match is valid by verifying that the remaining basic matching criteria are met. If no match is found (step 407) or the match cannot be confirmed (step 409), then the transaction is moved to the Unresolved Transactions list.
In one embodiment, the basic matching criteria includes four factors, i.e., passenger name, ticket number, card number, and dollar amount. The system searches for a matching ticket number and then verifies that the other three criteria match. If, for example, the passenger name, ticket number, and card number match, but the dollar amount is different, then the system will not match the card and travel transactions. Even though the ticket was used by the listed passenger, the passenger may have refunded part or all of the travel ticket at the airport and thus, the dollar amounts do not match.
Once the match is initially confirmed (all of the basic matching criteria is met) the system continues the auto-reconciliation process by verifying the presence of the specific data criteria, if any (step 410). The specific data criteria is the client defined data. The system allows the individual client to develop parameters for the user to follow once the basic matching criteria have been met. The client's parameters or factors, may be more or less strict than the basic criteria, however, it is preferable that the basic criteria not be adjusted or waived. Examples of client- specific data may include employee I.D., project code, department code, or travel authorization number; however, it should be appreciated that this criteria may be defined by the client and thus varies from application to application. In some instances or with some clients, there may not be any specific client defined data. In these cases, the transaction is automatically moved to the Approved Items list for payment processing (step 414).
If the system confirms the presence of all the specific client defined data (step 412) and the basic matching criteria is, in an exemplary embodiment, already verified, then the transactions are ready to be processed for payment and are automatically moved to the Approved Items list (step 414). Transactions that fail any of the matching criteria are moved to the Unresolved Transactions list so that they can be researched and corrected (step 413).
WASHOUT EXEMPLARY FLOWCHART Figure 5 is a flowchart 500 describing one embodiment for implementing an exemplary washout process in accordance with the present invention (i.e., step 206). Used herein, "wash out" includes a process during auto-reconciliation that results in offsetting debits and credits being automatically matched. In other words, if the system identifies a debit and a credit for the same travel transaction that sum to zero, the system recognizes that these two items are a match and may move them to the Washed Out list. It is not necessary to further process or reconcile either of the washed out card or travel transactions because, although there may have been a debit charge for the travel at one time, an offsetting credit has been received to clear the transaction. As previously mentioned, both the card and travel data flows into the accounting database and occasionally a credit and a debit for the same travel transaction appear during the same processing cycle. During auto-reconciliation, the system searches the card transactions which have been loaded into the accounting database (but not yet included on a Billed Transaction Report) for transactions where a debit and a credit have been received for the same ticket number (step 502). In one embodiment, to qualify as a washout, the credit and debit completely offset (the summation is zero); therefore, the system queries whether this has occurred (step 504). If the credit and debit do not sum to zero, then no match is made and the credit and debit transactions are moved to the Unresolved Transactions list for research and correction (step 508).
Once the system verifies that the credit and debit completely offset each other for a single ticket number (or other identifying factor), the system may automatically move the credit and the debit transactions to the Washed Out list (step 506). It should be noted, that in one particular embodiment, the client may choose not to use the Washed Out feature and thus in this situation the transactions would not move to a Washed Out list, but would move to the Approved Items list. Similar to the matching processes within the system, the wash out process does not make assumptions or "near matches". The Washed Out List contains, in one embodiment, transactions that no longer require processing so the placement or storage of transactions here must be accurate.
Another example of the wash out process occurs when the credit and debit do not appear within the same cycle. For example, when the accounting database receives the charge-related data, there may be a charge corresponding to a voided ticket. The auto-reconciliation process is unable to match the charge with a corresponding travel transaction because the ticket was voided and therefore no record of the travel transaction was ever loaded into the accounting database. Hence, the charge entry is an unmatched item and moved to the Unresolved Transaction list. At a later time, the offsetting credit for the voided ticket charge may be loaded into the accounting database and during subsequent auto-reconciliation processes, the system recognizes that the credit corresponds to an item on the Unresolved Items list (step 510). As in the previous description, the system queries whether the credit and debit sum to zero (step 504) and if so, may move the transactions to the Washed Out list (step 506). If the sum is not zero, then the credit transaction is also moved to the Unresolved Transactions list (step 508).
UNRESOLVED TRANSACTIONS EXEMPLARY FLOWCHART
Figures 6a and 6b are a flowchart 600 describing one embodiment for implementing an exemplary unresolved transaction process in accordance with the present invention (i.e., steps 210-214). The Unresolved Transactions list further demonstrates that the system is a management tool that reconciles to the entire account balance. In this sense, unmatched or otherwise unresolved transactions are moved to the Unresolved Transactions list to be researched and corrected. Items that do not wash out and fail to meet one or more of the auto reconciliation criteria are moved to the Unresolved Transactions list. Each item on the list is monitored, researched and corrected by authorized users of the system.
As previously described, the system is, in an exemplary embodiment, not configured to process "near matches" or make assumptions on the quality of the data. Rather, the system, in an exemplary embodiment, identifies absolute matches and the user and client have little or no room to question the accuracy of the transactions which have been automatically approved. To maintain the integrity of the system, in an exemplary embodiment, the system is incapable of approving card and travel transactions if there is even a minor data entry error. For example, a passenger's name misspelled on a charge may preclude the system from approving the transaction which does not match the name on the related travel record. In one specific embodiment, the system permits authorized users to view the unresolved transactions (step 602). Authorized users (step 604) may be permitted to make edits to the unresolved transaction (step 606) and forward the edited transaction to the Ready for Approval list (step 609).
In another embodiment, the user accesses a research tool created to facilitate the correction of pending unresolved items (step 608). The tool causes the display of all the details of the pending item, e.g., a card transaction, and allows the user to specify criteria to search for a matching transaction, e.g., a travel transaction (step 610). The tool may offer suggested search criteria or default criteria. In this specific embodiment, the user may override the strict matching criteria set by the system and thus the system can search for exact or near-exact corresponding matching transactions (step 612) (i.e., near-matches). The system tool displays the located transactions and allows the user to choose the correct match (step 614). When the match and/or correction is complete (step 616), the system moves the items to the Ready for Approval list (step 609). In yet another embodiment, the user is permitted to research items which partially match. For example, assume that a ticket is issued and a corresponding charge is made for $420.00. At the airport, the passenger is informed that his next flight has been cancelled, e.g., due to bad weather, and the airline issues a partial credit in the amount of $120.00. The traveler returns and informs Company A that he did not travel and thus Company A refuses to pay the original ticket charge in the amount of $420.00. The charge of $420.00 is moved to the Unresolved Items list. When the credit for $120.00 is received, the system will not match the credit with the debit of $420.00 because the dollar amounts do not match. The credit of $120.00 will also be moved to the Unresolved Transactions list. An authorized user viewing the Unresolved Transactions list can easily recognize there are multiple card transactions (credit and debit) for the same ticket number and deduce that a partial credit was received. The user is allowed to apply the credit against the debit and match the remaining balance with the travel transaction. Again, the transaction is moved to the Ready for Approval list pending approval and payment processing (step 609). This process ensures that unmatched transactions are not forgotten or partial matches are not improperly captured on a BTR, but rather, the client is properly billed for the correct amount (e.g., in the above example, the client would be billed for $300.00 (the original debit less the received credit)).
The Ready for Approval list provides a security measure to further maintain the integrity of the processes. In one specific embodiment, several tiers of approval authority may be installed to permit varied levels of access. At one level, an authorized user may be granted access to edit ticket numbers, passenger's names and dollar amounts, but will be restricted access to approve the transaction and move it to the Approved Items list. Any change by a user may cause concern for creating additional errors. In this sense, a final approval made by a user with a higher level of authority may be preferred.
On the Ready for Approval list, a transaction selected for approval is displayed to an authorized user (step 618). The system may query the authority level of the user and restrict access if the authority level required is not met (step 620). In one embodiment, the system may cause the display of a "before-and-after" picture of the corrected transaction for the authorized approval user (step 622). In other words, the viewer may see the pre-edit or pre-matched transactions and the post-edit or post-matched transactions. The approver can view the correction and verify the accuracy of the change, if any. In some cases, there may not have been an edit to the transactions, but a billing amount that is different than the travel invoice amount has been accepted by the authorized user. If the approver agrees with the match or change (step 624), the transaction is moved to the Approved Items list (step 626). If, however, the approver does not approve the transaction, the approver can send the transaction back to the Unresolved Transactions list for further research and correction (step 625).
REPORTS GENERATION EXEMPLARY FLOWCHART Figure 7 is a flowchart 700 describing one embodiment for implementing an exemplary reports generation process in accordance with the present invention (i.e., steps 216-222). It should be appreciated that various items may be summarized and generated into a desired report. The description of reports provided herein are provided as examples and not intended to be limiting in any manner.
In one embodiment, the Approved Items list holds all the transactions that have met the matching criteria during auto-reconciliation, and all the transactions that have been finally approved by an authorized user (i.e., Figures 6a-6b). From the Approved Items list, the system automatically captures all of the transactions that are ready to be processed for payment (step 702) and generates a Billed Transaction Report ("BTR") (step 704). No further approval is typically required because each of the transactions have either met the predetermined matching criteria or have been finally approved. It should be realized that the Billed Transaction Report is generally not a billing statement, but rather, is used as a reconciliation tool for the client to identify each of the charges on its card statement (i.e., received from its credit card company). In other words, the client typically receives a bill from its credit card company for all charged transactions during a given billing cycle. The Billed Transaction Report, and present invention in general, are designed to complement the client's current billing and payment methods by providing an identification of all charges on the client's billing statement (i.e., reconciling to the account balance) that the client has specified are ripe for payment.
In one specific embodiment, the system prints a copy of the Billed Transaction Report during a given cycle for the client's review. Alternatively, the Billed Transaction Report may be provided to the client in an electronic format, e.g., over a suitable communications network. The client side may include suitable software to enable the Billed Transaction Report to be imported into the client's own accounting system. In one specific embodiment, a Payment Reconciliation Module for the client is updated to reflect the total amount of the current Billed Transaction Report (step 706). The Payment Reconciliation Module is an accounting for the Billed Transaction Report. For example, the Payment Reconciliation Module may include an entry for the total of the Billed Transaction Report and an entry for the "open" amount remaining. As payments are received on the account (step 707), the open amount remaining is reduced by the amount of the payment. Ideally, the client will submit payment that equals the total of the Billed Transaction Report, however, this may not always be the case. For instance, the client may have disputed a charge on the statement, and even on the Billed Transaction Report, and thus not submitted payment for that charge. The Payment Reconciliation Module tracks the amount of payments received from the client and identifies any remaining balance (open amounts) on the Billed Transaction Report (step 708). The user can then match the remaining balance with a particular transaction on the Billed Transaction Report and determine which item was unpaid by the client (step 710). This transaction can then be removed from the Billed Transactions Report list and placed in the Unresolved Transactions list for further research on why the transaction was not paid (step 711). In another specific embodiment, a Summary Reconciliation Report for the client's account automatically reconciles the activity on the client's account to the account balance (step 712). This operation is described in more detail below. Figure 8 illustrates an example of the Summary Reconciliation Report screen 800 a user (client side) will see. The screen 800 shows the user that the account (expressed in dollar amounts) is reconciled to the account balance. It should be appreciated that various system operations, such as retrieving from a suitable storage, processing and formatting, may not be fully detailed for each of the following entries on the Report; however, it should be recognized by those of skill in the art, that these various operations, as well as others, may be necessary to carryout the desired display. The system begins with and displays the prior billing cycle's ending balance from the client's card statement 801. The current cycle's activity (new charges and credits) 804 is then displayed and added to the ending balance, along with any new fees 806 the client is to be responsible for. The dollar amounts of payments, if any, received on the account 808 are subtracted from the balance.
Expected, or pending payments 810 are displayed on the screen 800. The expected payments include total amounts from the BTR(s) and more specifically, from the Payment Reconciliation Module. For example, as previously mentioned, the Payment Reconciliation Module tracks the BTRs and any payments received on the account are applied against the outstanding BTR balance. As illustrated on screen 800, there are two outstanding BTRs remaining on the exemplary account: MAY BILL 807 and APRIL BILL 809. Any payments applied to the BTRs 811 is displayed and the remaining BTR total 810 is the expected payment. Because the BTR includes only transactions on the Approved Items list, the system considers the BTR total to be items ripe for payment and thus reconciled. In this sense, the BTR total 810 is subtracted from the balance (at this point the balance equals 802 + 804 + 806 - 808). The total dollar amount of all the pending transactions in the accounting database 812 is then displayed. These transactions were loaded into the database from the client's card statement, but have not undergone auto-reconciliation. Therefore, this dollar amount is accounted for (albeit still pending) and subtracted from the remaining statement balance. The totals of the Ready for Approval list 814 and Approved Items list 816 are then subtracted from the remaining balance. The ending balance 818 after all additions and subtractions is the final remaining balance.
To verify the account is reconciled to the client's account balance, the total of the transactions pending on the Unresolved Transactions list 820 is displayed. When the ending balance 818 and Unresolved Items 820 amounts match, the account is in balance.
The present invention has been described above with reference to exemplary embodiments. However, those skilled in the art having read this disclosure will recognize that changes and modifications may be made to the embodiments without departing from the scope of the present invention. For example, while conveniently described in connection with the travel industry, and in particular the travel agency industry, the present invention is not so limited. Rather, a variety of industries desiring an automated, efficient and cost-saving approach to account reconciliation may benefit from the system and methods of the present invention as expressed in the following claims.

Claims

1. A method of providing account reconciliation for an account comprising the steps of: a. receiving at a computing device a plurality of merchant transactions and a plurality of charge transactions; b. storing said merchant transactions and said charge transactions on a pending list within a database of said computing device; c. identifying a match from said pending list comprising at least one of said merchant transactions and at least one of said charge transactions, said match determined by a commonality shared between said transactions; d. storing said match on an approved items list within said database; e. repeating steps c-d to identify other matches; f. storing the unmatched merchant and charge transactions, if any, from said pending list on an unresolved transactions list within said database; g. searching said database for a near-match comprising one of said merchant transactions and one of said charge transactions; h. receiving an approval notification of said near-match; i. storing said near-match on said approved items list; and j. repeating steps g-j to approve other near-matches.
2. The method of claim 1 wherein the step of identifying a match comprises the steps of: d . selecting a charge transaction from said pending list; c2. identifying a match criteria on said charge transaction; and c3. searching said merchant transactions for said match criteria.
3. The method of claim 1 wherein said merchant transactions comprise travel transactions.
4. The method of claim 3 wherein said match criteria comprises a travel ticket number.
5. The method of claim 3 wherein said travel transactions comprise one of airline, lodging or rental car.
6. The method of claim 1 further comprising the steps of: k. compiling said matches and said near-matches on said approved items list; and
I. generating a report from said compilation.
7. A method of travel account reconciliation comprising the steps of: storing a plurality of travel transactions in a database, each of said travel transactions comprising travel ticket information; storing a plurality of card transactions in said accounting database, each of said card transactions comprising travel charge information; searching said travel ticket information for a matching counterpart to said travel charge information; automatically repeating said searching step for each card transaction; storing the travel transaction and the card transaction forming said matching counterpart on an approved list within said database; in the event that there exists unmatched transactions, then said unmatched transactions are automatically stored on an unresolved transaction list within said database; compiling said approved list and said unresolved transactions list; and displaying a reconciliation report comprising said compilation upon request.
8. The method of claim 7 wherein said searching step comprises searching in said accounting database to include on said unresolved transactions list of said database.
9. The method of claim 7 further comprising the step of storing said travel transaction and said card transaction forming said matching counterpart on a washed out list when the travel ticket information of said travel transaction includes a dollar amount and the travel charge information of said card transaction includes an equal but offsetting dollar amount.
10. The method of claim 7 further comprising the step of storing travel transactions comprising refund information on a refund list of said database.
11. A computer-implemented method for reconciling a plurality of merchant records to a card account balance, said method comprising: receiving, at an accounting database, merchant data pertaining to said plurality of merchant records; receiving, at said accounting database, card data pertaining to said card account balance, said balance comprising charges corresponding to said merchant records; searching, in said accounting database, for a merchant record match between said merchant data and said card data; compiling a first list of merchant record matches; compiling a second list of merchant record non-matches, said non- matches comprising said merchant data and said card data; searching, in said accounting database, for a merchant record near- match between said merchant data and a card data from said second list; compiling a third list of merchant record near-matches; upon approval from an authorized user, combining said third list into said first list; generating a report comprising said first list, said second list and said third list; and verifying said report is in balance with said card account balance.
12. The method of claim 11 wherein said step of searching for a merchant record match comprises searching for a common set of numbers within said merchant data and said card data.
13. The method of claim 11 further comprising the step of identifying a basic matching criteria and said merchant record match includes at least one of said basic matching criteria.
14. The method of claim 13 further comprising the step of confirming said merchant record match by matching all of a plurality of basic matching criteria between said merchant data and said card data.
15. The method of claim 14 further comprising the step of confirming said merchant record match by matching a set of client-defined criteria.
16. The method of claim 11 wherein said verifying step comprises the steps of: calculating a first list total by tallying together a dollar amount from each of said merchant record matches from said first list; calculating a second list total by tallying together a dollar amount from each of said merchant record non-matches from said second list; calculating a third list total by tallying together a dollar amount from each of said unapproved merchant record near-matches from said third list; calculating an ending balance by subtracting said first list total and said third list total from said card account balance; and comparing said ending balance with said second list total.
17. An account reconciliation method for reconciling a plurality of merchant records with a card statement, said method reconciling to a dollar balance on said card statement and comprising the steps of: inputting, to a computer database, merchant-related data pertaining to said plurality of merchant records; inputting, to said computer database, card-related data pertaining to said card statement, said dollar balance on said card statement comprising charges corresponding to said merchant records; viewing, on a computing device display, a computer-generated reconciliation report having: a beginning balance comprising said dollar balance on said card statement; a pending payment comprising a combined dollar total of automatically approved and user-approved matches of said merchant-related data and said card-related data; an ending balance comprising an aggregate of said beginning balance less said pending payment; and an unresolved balance comprising a dollar total of unmatched merchant-related data and unmatched card-related data; and confirming said ending balance equals said unresolved balance.
18. The method of claim 17 further comprising the steps of: viewing, on said computing device display, a computer-generated unresolved balance list comprising said unmatched merchant-related data and said unmatched card-related data; identifying, on said display, one of said unmatched data; viewing, on said display, a detailed description of said merchant record pertaining to said identified unmatched data; selecting, on said display, a matching criteria from said detailed description; activating a research tool to search said computer database for a match or near-match of said matching criteria with at least one other of said unmatched data; viewing, on said display, a result of said research tool search; selecting, on said display, a resolved match comprising said one of said unmatched data and an item from said result; and transferring said resolved match to said pending payment list.
19. The method of claim 18 further comprising the steps of: transferring said resolved match to a ready for approval list; viewing, on said display, said ready for approval list; and accepting said resolved match and transferring said resolved match to said pending payment list or denying said resolved match and transferring said resolved match to said unresolved balance list and repeating the steps of claim 18.
20. The method of claim 17 for reconciling a plurality of travel records with a card statement.
21. The method of claim 20 wherein said travel records comprise one of airline, lodging or rental car.
22. An account reconciliation system for reconciling an account, said system comprising: a client side computing device having a display and an input means; a server side having a database and an account reconciliation software program stored thereon; a communication channel linking said client side with said server side; said database capable of receiving and storing merchant-related data and card-related data, said merchant-related data comprising a plurality of merchant records and each of said merchant records including information specific to a particular affair, said card-related data comprising a plurality of charges and each of said charges corresponding to at least one of said merchant records; said account reconciliation software including programming to automatically match said merchant-related data and said card-related data when said merchant record information is identical, and automatically compile said merchant-related data and said card-related data which did not match on an unresolved list; said account reconciliation software permitting a user to view said unresolved list and direct said software to search the database for a near-match between said merchant-related data and said card-related data, and further permitting said user to approve said near-match; said account reconciliation software also permitting said user to view said unresolved list and edit said data, and further permitting said user to approve a match between the edited data and a corresponding merchant or card related data; and said account reconciliation software further including programming to generate a reconciliation report for the user to view, said report comprising a verification to the user that said merchant account is reconciled to an account balance.
23. The account reconciliation system of claim 22 wherein said account reconciliation software further including programming to automatically manage refunds of affairs.
24. The account reconciliation system of claim 23 wherein said account reconciliation software programmed to automatically manage refunds includes programming to: update a refund log within said accounting database with information pertaining to a refund of an affair; identify a credit received from said plurality of card-related data corresponding to said refund of said affair; automatically match said credit and said refund of said affair; update said refund log with information pertaining to said credit.
25. A computer program embodying instructions executable by a computer for reconciling a merchant account to a card account balance, the instruction steps comprising: an auto-reconciliation process comprising the steps of: sorting a plurality of data comprising a plurality of merchant transactions and a plurality of charge transactions; identifying a matching criteria on each of said charge transactions; searching said plurality of merchant transactions for said matching criteria on one of said charge transactions; compiling a list of matching merchant and charge transactions; compiling a list of unmatched merchant and charge transactions; repeating said auto-reconciliation until all of said transactions are compiled on a list; and an unresolved transactions process comprising the steps of: displaying said list of unmatched merchant and charge transactions; searching said accounting database for information pertaining to a selected transaction on said list of unmatched transactions; displaying said searched information; accepting commands to match said selected transaction with another transaction; and compiling said matched selection on said list of matching merchant and charge transactions.
26. The computer program of claim 25, wherein said matching criteria comprises a basic matching criteria and a client-specific criteria.
27. The computer program of claim 26 further comprising during auto- reconciliation verifying the presence of all basic matching criteria and all client- specific criteria.
28. The computer program of claim 25, wherein said merchant account comprises a travel account.
29. The computer program of claim 25, wherein said merchant account comprises one of airline, lodging or rental car.
30. The computer program of claim 28, wherein said matching criteria comprises said individual's name, a ticket number, a card number, and a dollar amount.
31. The computer program of claim 25 further comprising during auto- reconciliation compiling a list of two or more transactions that when summed equal zero.
32. The computer program of claim 25, further comprising during said unresolved transaction process accepting commands to edit said selected transaction.
33. The computer program of claim 25, further comprising programming to authenticate a user prior to acceptance of commands.
34. The computer program of claim 25, further comprising a report generation process.
PCT/US2001/026583 2000-08-25 2001-08-27 System and method for account reconciliation WO2002017201A1 (en)

Priority Applications (11)

Application Number Priority Date Filing Date Title
BR0113492-2A BR0113492A (en) 2000-08-25 2001-08-27 Account reconciliation methods for one account and account reconciliation and various business recordings for a card account balance, account reconciliation system, and computer program
AU8528401A AU8528401A (en) 2000-08-25 2001-08-27 System and method for account reconciliation
MXPA03001652A MXPA03001652A (en) 2000-08-25 2001-08-27 System and method for account reconciliation.
EP01964431A EP1323093A4 (en) 2000-08-25 2001-08-27 System and method for account reconciliation
KR10-2003-7002501A KR20030024896A (en) 2000-08-25 2001-08-27 System and method for account reconciliation
JP2002521820A JP2004507823A (en) 2000-08-25 2001-08-27 System and method for account reconciliation
AU2001285284A AU2001285284B2 (en) 2000-08-25 2001-08-27 System and method for account reconciliation
NZ524362A NZ524362A (en) 2000-08-25 2001-08-27 System and method for account reconciliation
CA002423113A CA2423113A1 (en) 2000-08-25 2001-08-27 System and method for account reconciliation
AU2005202263A AU2005202263A1 (en) 2000-08-25 2005-05-24 System and method for account reconciliation
AU2008203400A AU2008203400B2 (en) 2000-08-25 2008-07-30 System and method for account reconciliation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US22823600P 2000-08-25 2000-08-25
US60/228,236 2000-08-25

Publications (1)

Publication Number Publication Date
WO2002017201A1 true WO2002017201A1 (en) 2002-02-28

Family

ID=22856350

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/026583 WO2002017201A1 (en) 2000-08-25 2001-08-27 System and method for account reconciliation

Country Status (10)

Country Link
US (4) US7693787B2 (en)
EP (1) EP1323093A4 (en)
JP (2) JP2004507823A (en)
KR (1) KR20030024896A (en)
AU (2) AU8528401A (en)
BR (1) BR0113492A (en)
CA (1) CA2423113A1 (en)
MX (1) MXPA03001652A (en)
NZ (1) NZ524362A (en)
WO (1) WO2002017201A1 (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1542147A2 (en) * 2003-11-24 2005-06-15 Cargill Incorporated Global balancing tool
JP2008509482A (en) * 2004-08-06 2008-03-27 アメリカン・エキスプレス・トラベル・リレイテッド・サービシズ・カンパニー・インコーポレーテッド Method and system for billing and matching for improved travel transactions
JP2009501978A (en) * 2005-07-15 2009-01-22 レボリューション マネー,インコーポレイテッド System and method for putting doubt on individual items to be traded
AU2004273117B2 (en) * 2003-09-12 2009-07-16 Swiss Reinsurance Company Ltd. Computer-based system for transactions processing
US8301554B2 (en) 2005-06-30 2012-10-30 American Express Travel Related Services Company, Inc. System and method for managing meetings budgets and allocating and reconciling expenditures
US8326712B2 (en) 2003-04-16 2012-12-04 American Express Travel Related Services Company, Inc. Method and system for technology consumption management
US8326713B2 (en) 2003-04-16 2012-12-04 American Express Travel Related Services Company, Inc. Method and system for technology consumption management including allocation of fees
US11373151B2 (en) * 2002-12-09 2022-06-28 Live Nation Entertainment, Inc. Apparatus for access control and processing
US11593501B2 (en) 2002-12-09 2023-02-28 Live Nation Entertainment, Inc. System and method for using unique device identifiers to enhance security

Families Citing this family (139)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7809642B1 (en) 1998-06-22 2010-10-05 Jpmorgan Chase Bank, N.A. Debit purchasing of stored value card for use by and/or delivery to others
US6615189B1 (en) 1998-06-22 2003-09-02 Bank One, Delaware, National Association Debit purchasing of stored value card for use by and/or delivery to others
US7660763B1 (en) 1998-11-17 2010-02-09 Jpmorgan Chase Bank, N.A. Customer activated multi-value (CAM) card
US7536307B2 (en) * 1999-07-01 2009-05-19 American Express Travel Related Services Company, Inc. Ticket tracking and redeeming system and method
US7529681B2 (en) * 1999-07-01 2009-05-05 American Express Travel Related Services Company, Inc. Ticket tracking, reminding, and redeeming system and method
US20050256750A1 (en) * 1999-07-01 2005-11-17 American Express Travel Related Services Company, Inc. Ticket tracking and refunding system and method
US7228313B1 (en) 1999-07-01 2007-06-05 American Express Travel Related Services Company, Inc. Ticket tracking and refunding system and method
US8793160B2 (en) 1999-12-07 2014-07-29 Steve Sorem System and method for processing transactions
US7313546B2 (en) 2001-05-23 2007-12-25 Jp Morgan Chase Bank, N.A. System and method for currency selectable stored value instrument
WO2003010701A1 (en) 2001-07-24 2003-02-06 First Usa Bank, N.A. Multiple account card and transaction routing
US8020754B2 (en) * 2001-08-13 2011-09-20 Jpmorgan Chase Bank, N.A. System and method for funding a collective account by use of an electronic tag
AU2002326775A1 (en) * 2001-08-28 2003-03-18 Diners Club International Ltd. Method and system for presenting charge related data on a worldwide basis through a network
US9286601B2 (en) 2012-09-07 2016-03-15 Concur Technologies, Inc. Methods and systems for displaying schedule information
US8712811B2 (en) 2001-10-16 2014-04-29 Concur Technologies, Inc. Method and systems for detecting duplicate travel path
EP1446754A4 (en) * 2001-10-16 2007-07-04 Outtask Llc System and method for managing booking and expensing of travel products and services
US7720702B2 (en) * 2003-02-26 2010-05-18 Concur Technologies, Inc. System and method for integrated travel and expense management
US7974892B2 (en) 2004-06-23 2011-07-05 Concur Technologies, Inc. System and method for expense management
US8620750B2 (en) 2010-10-21 2013-12-31 Concur Technologies, Inc. Method and system for targeting messages to travelers
US9400959B2 (en) 2011-08-31 2016-07-26 Concur Technologies, Inc. Method and system for detecting duplicate travel path information
US20100030675A1 (en) * 2001-12-06 2010-02-04 Hanan Christopher C Payor focused business to business electronic invoice presentment and accounts payable reconciliation system and method
US20030158944A1 (en) * 2002-02-19 2003-08-21 International Business Machines Corporation Software control in a business transaction environment
WO2003077080A2 (en) * 2002-03-08 2003-09-18 Jp Morgan Chase Bank Financial system for isolated economic environment
US8392301B1 (en) * 2002-03-08 2013-03-05 Jpmorgan Chase Bank, N.A. Financial system for isolated economic environment
US7899753B1 (en) 2002-03-25 2011-03-01 Jpmorgan Chase Bank, N.A Systems and methods for time variable financial authentication
AU2003230751A1 (en) 2002-03-29 2003-10-13 Bank One, Delaware, N.A. System and process for performing purchase transaction using tokens
US20040210498A1 (en) 2002-03-29 2004-10-21 Bank One, National Association Method and system for performing purchase and other transactions using tokens with multiple chips
WO2003098494A1 (en) * 2002-05-17 2003-11-27 Colonial First State Investments Limited A transaction management system
AU2003229093B2 (en) * 2002-05-17 2008-05-15 Colonial First State Investments Ltd A transaction management system
US7630989B2 (en) * 2002-05-17 2009-12-08 Colonial First State Investments Ltd. Transaction management system
US9710852B1 (en) 2002-05-30 2017-07-18 Consumerinfo.Com, Inc. Credit report timeline user interface
US9400589B1 (en) 2002-05-30 2016-07-26 Consumerinfo.Com, Inc. Circular rotational interface for display of consumer credit information
US7539634B2 (en) * 2002-06-27 2009-05-26 Oracle International Corporation Account reconciliation system and method
US7809595B2 (en) 2002-09-17 2010-10-05 Jpmorgan Chase Bank, Na System and method for managing risks associated with outside service providers
US20040088204A1 (en) * 2002-10-30 2004-05-06 Christopher Plum Method of retrieving a travel transaction record and an image of its supporting documentation
WO2004053776A1 (en) * 2002-12-09 2004-06-24 Accubalance Corporation Personal digital account register
WO2004055698A1 (en) * 2002-12-17 2004-07-01 Stephen James Sullivan Tagging system
US7606721B1 (en) * 2003-01-31 2009-10-20 CDR Associates, LLC Patient credit balance account analysis, overpayment reporting and recovery tools
US7647257B2 (en) * 2003-05-06 2010-01-12 American Express Travel Related Services Company, Inc. System and method for web access to financial data
US8458067B2 (en) * 2003-05-06 2013-06-04 American Express Travel Related Services Company, Inc. System and method for emergency tracking
US8306907B2 (en) 2003-05-30 2012-11-06 Jpmorgan Chase Bank N.A. System and method for offering risk-based interest rates in a credit instrument
US7500598B2 (en) * 2003-11-25 2009-03-10 American Express Travel Related Services Company, Inc. Negotiable instruments and systems and processing same
US8600845B2 (en) * 2006-10-25 2013-12-03 American Express Travel Related Services Company, Inc. System and method for reconciling one or more financial transactions
US7895094B2 (en) * 2003-12-15 2011-02-22 American Express Travel Related Services Company, Inc. Global account reconciliation tool
US7797216B2 (en) * 2004-01-12 2010-09-14 Intuit Inc. Method and system for backfilling transactions in an account
US20050187852A1 (en) * 2004-02-24 2005-08-25 Finaplex, Inc. Method and system for account reconciliation in a wealth management system
US20050192876A1 (en) * 2004-03-01 2005-09-01 Mckee A. J.Jr. Software application for teaching cost accounting
US7603314B2 (en) * 2004-03-25 2009-10-13 International Business Machines Corporation Automatic billing event submission reconciliation for on demand systems
US20050240452A1 (en) * 2004-03-30 2005-10-27 Breed Johnnie C System and method of making travel arrangements
US20050251477A1 (en) * 2004-05-07 2005-11-10 Mitac International Corp. On-line billing system and method of the same
US20070288313A1 (en) * 2006-06-09 2007-12-13 Mark Brodson E-Coupon System and Method
US10248951B2 (en) * 2004-12-01 2019-04-02 Metavante Corporation E-coupon settlement and clearing process
US20060184422A1 (en) * 2005-02-17 2006-08-17 Sandy Cooper Method and apparatus for accessing transaction data in a travel settlement system using a graphical user interface
US8880417B2 (en) * 2005-05-20 2014-11-04 Biz Travel Solutions, Llc System and method for ensuring accurate reimbursement for travel expenses
US8478614B2 (en) * 2005-05-20 2013-07-02 Biz Travel Solutions, Llc System and method for ensuring accurate reimbursement for travel expenses
US7401731B1 (en) 2005-05-27 2008-07-22 Jpmorgan Chase Bank, Na Method and system for implementing a card product with multiple customized relationships
US7921043B2 (en) * 2005-07-28 2011-04-05 Intuit Inc. Intelligent reconciliation of database transfer errors
US7657575B2 (en) * 2005-12-30 2010-02-02 Sap Ag Sequencing updates to business objects
US7726561B2 (en) * 2006-07-21 2010-06-01 Intuit Inc. System and method for reconciling credit card payments with corresponding transactions
US8036979B1 (en) 2006-10-05 2011-10-11 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US20080154758A1 (en) * 2006-12-21 2008-06-26 Friedrich Schattmaier Systems and methods for maintaining credit information about an entity
US20080162196A1 (en) * 2006-12-29 2008-07-03 American Express Travel Services, Co., Inc. System and method for centralizing and processing ticket exchange information
US8700435B2 (en) * 2006-12-29 2014-04-15 American Express Travel Related Services Company, Inc. System and method for redemption and exchange of unused tickets
US9185123B2 (en) 2008-02-12 2015-11-10 Finsphere Corporation System and method for mobile identity protection for online user authentication
US20110208601A1 (en) * 2010-02-19 2011-08-25 Finshpere Corporation System and method for financial transaction authentication using travel information
US20090106170A1 (en) * 2007-10-18 2009-04-23 Thurlow Stephen H Method and system for air fare verification auditing
US8370230B2 (en) * 2007-11-21 2013-02-05 Early Warning Services, Llc System and method for expedited release of held items
US8127986B1 (en) 2007-12-14 2012-03-06 Consumerinfo.Com, Inc. Card registry systems and methods
US9990674B1 (en) 2007-12-14 2018-06-05 Consumerinfo.Com, Inc. Card registry systems and methods
US7970668B2 (en) * 2007-12-26 2011-06-28 American Express Travel Related Services Company, Inc. System and method for automated comprehensive reconciliation processing
US8078528B1 (en) 2008-02-21 2011-12-13 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US8095443B2 (en) 2008-06-18 2012-01-10 Consumerinfo.Com, Inc. Debt trending systems and methods
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US8060424B2 (en) 2008-11-05 2011-11-15 Consumerinfo.Com, Inc. On-line method and system for monitoring and reporting unused available credit
US8103561B2 (en) * 2008-11-14 2012-01-24 Oracle International Corporation Reconciling financial transactions
US8639920B2 (en) 2009-05-11 2014-01-28 Experian Marketing Solutions, Inc. Systems and methods for providing anonymized user profile data
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US10592792B2 (en) 2011-04-14 2020-03-17 Handle Financial, Inc. Systems and methods for barcode translation
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US9665854B1 (en) 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
US20130006785A1 (en) * 2011-07-01 2013-01-03 Richard Scott Perkins System and method to facilitate settlement of a transaction
US9483606B1 (en) 2011-07-08 2016-11-01 Consumerinfo.Com, Inc. Lifescore
US9106691B1 (en) 2011-09-16 2015-08-11 Consumerinfo.Com, Inc. Systems and methods of identity protection and management
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
GB2500275A (en) * 2012-03-15 2013-09-18 Anjum Alam Khan Cloud based reporting system
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US9626701B2 (en) 2012-05-23 2017-04-18 Paynearme, Inc. System and method for facilitating cash payment transactions using a mobile device
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US9916621B1 (en) 2012-11-30 2018-03-13 Consumerinfo.Com, Inc. Presentation of credit score factors
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
WO2014089565A1 (en) * 2012-12-07 2014-06-12 Electra Information Systems, Inc. Method and system for reconciling data from multiple resources
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
CA2941355A1 (en) * 2013-03-09 2014-10-09 Paybook, Inc. Thematic repositories for transaction management
US10366457B2 (en) 2013-03-09 2019-07-30 Paybook, Inc. Thematic repositories for transaction management
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US9870589B1 (en) 2013-03-14 2018-01-16 Consumerinfo.Com, Inc. Credit utilization tracking and reporting
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US10685398B1 (en) 2013-04-23 2020-06-16 Consumerinfo.Com, Inc. Presenting credit score information
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US8886570B1 (en) 2013-10-29 2014-11-11 Quisk, Inc. Hacker-resistant balance monitoring
US10102536B1 (en) 2013-11-15 2018-10-16 Experian Information Solutions, Inc. Micro-geographic aggregation system
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US10192407B2 (en) 2014-01-10 2019-01-29 Handle Financial, Inc. Systems and methods for cash payments for online gaming
USD760256S1 (en) 2014-03-25 2016-06-28 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759689S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
USD759690S1 (en) 2014-03-25 2016-06-21 Consumerinfo.Com, Inc. Display screen or portion thereof with graphical user interface
US9892457B1 (en) 2014-04-16 2018-02-13 Consumerinfo.Com, Inc. Providing credit data in search results
US9576030B1 (en) 2014-05-07 2017-02-21 Consumerinfo.Com, Inc. Keeping up with the joneses
CN105338164A (en) 2014-08-01 2016-02-17 阿里巴巴集团控股有限公司 Recharge prompting method and recharge prompting device
US10242019B1 (en) 2014-12-19 2019-03-26 Experian Information Solutions, Inc. User behavior segmentation using latent topic detection
US9959540B2 (en) * 2015-05-22 2018-05-01 Paypal, Inc. Security authentication using payment card display devices at accepted merchant locations
WO2017024080A1 (en) * 2015-08-03 2017-02-09 Citifyd, Inc. Transaction payment processing system implementing a virtual exchange platform
US10373169B2 (en) * 2015-08-11 2019-08-06 Paypal, Inc. Enhancing information security via the use of a dummy credit card number
US10438282B2 (en) 2015-10-09 2019-10-08 Oracle International Corporation Computerized invoice record and receipt record matching utilizing best match criteria
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US9830667B2 (en) * 2015-12-01 2017-11-28 Oracle International Corporation Computerized invoice record and receipt record matching with automatic discrepancy resolution
US10678894B2 (en) 2016-08-24 2020-06-09 Experian Information Solutions, Inc. Disambiguation and authentication of device users
WO2018144612A1 (en) 2017-01-31 2018-08-09 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
SG10201800546XA (en) * 2018-01-22 2019-08-27 Mastercard International Inc Electronic transaction data processing systems and methods
US10880313B2 (en) 2018-09-05 2020-12-29 Consumerinfo.Com, Inc. Database platform for realtime updating of user data from third party sources
US11315179B1 (en) 2018-11-16 2022-04-26 Consumerinfo.Com, Inc. Methods and apparatuses for customized card recommendations
US20200193415A1 (en) * 2018-12-14 2020-06-18 Jpmorgan Chase Bank, N.A. Systems and methods for using integrated pay-on-demand virtual cards
US11620403B2 (en) 2019-01-11 2023-04-04 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation
US11238656B1 (en) 2019-02-22 2022-02-01 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot
US11410246B2 (en) * 2019-06-06 2022-08-09 Salus Finance, LLC System and method for consolidation, reconciliation and payment management
CN110287200B (en) * 2019-07-02 2022-03-25 贵阳货车帮科技有限公司 Account checking method, account checking system, computer equipment and storage medium
US11562439B2 (en) 2019-07-24 2023-01-24 International Business Machines Corporation Multi-way optimal reconciliation and recommendation
US11270275B2 (en) * 2019-08-16 2022-03-08 Comenity Llc One card
CN111427918A (en) * 2020-03-27 2020-07-17 中国工商银行股份有限公司 Transaction detail data comparison method and device
US11669367B2 (en) 2020-04-01 2023-06-06 Bank Of America Corporation System and methods for generation and analysis of real-time resource requests
US20220044313A1 (en) * 2020-08-05 2022-02-10 Cgi Federal Inc. Hybrid electronic payment process for charge account
CN112822650B (en) * 2020-12-23 2022-08-05 北京思特奇信息技术股份有限公司 Method and system for auditing accounting accuracy of MAS (Multi-agent System) service
US20220253931A1 (en) * 2020-12-28 2022-08-11 Carbeeza Ltd. Computer system
CN113159748A (en) * 2021-02-27 2021-07-23 南京意博软件科技有限公司 Management method and device for business trip service
TWI820556B (en) * 2021-12-30 2023-11-01 財金資訊股份有限公司 Fund transfer automatic accounting system and method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5093787A (en) * 1986-06-12 1992-03-03 Simmons John C Electronic checkbook with automatic reconciliation
US5783808A (en) * 1996-01-11 1998-07-21 J. D. Carreker And Associates, Inc. Electronic check presentment system having transaction level reconciliation capability
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US5991750A (en) * 1997-10-24 1999-11-23 Ge Capital System and method for pre-authorization of individual account transactions

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5134564A (en) * 1989-10-19 1992-07-28 Dunn Eric C W Computer aided reconfiliation method and apparatus
US5870724A (en) * 1989-12-08 1999-02-09 Online Resources & Communications Corporation Targeting advertising in a home retail banking delivery service
US5550734A (en) * 1993-12-23 1996-08-27 The Pharmacy Fund, Inc. Computerized healthcare accounts receivable purchasing collections securitization and management system
US5521363A (en) * 1994-02-16 1996-05-28 Tannenbaum; David H. System and method for tracking memory card transactions
US5649115A (en) * 1994-06-02 1997-07-15 Intuit, Inc. Tracking method and apparatus
US5948040A (en) * 1994-06-24 1999-09-07 Delorme Publishing Co. Travel reservation information and planning system
US5740271A (en) * 1994-07-27 1998-04-14 On-Track Management System Expenditure monitoring system
US5598477A (en) * 1994-11-22 1997-01-28 Pitney Bowes Inc. Apparatus and method for issuing and validating tickets
JPH08297709A (en) * 1995-04-27 1996-11-12 Omron Corp Information data processing device and method
US5832460A (en) * 1995-06-02 1998-11-03 International Business Machines Corporation Method and system for bill presentation and payment reconciliation
US6442526B1 (en) * 1995-09-06 2002-08-27 The Sabre Group, Inc. System for corporate travel planning and management
US5859419A (en) * 1995-09-28 1999-01-12 Sol H. Wynn Programmable multiple company credit card system
US6301379B1 (en) * 1996-01-17 2001-10-09 Carreker-Antinori, Inc. Electronic check presentment systems and methods employing volatile memory datastore access techniques
US20050033659A1 (en) * 1996-01-17 2005-02-10 Privacy Infrastructure, Inc. Third party privacy system
US5832451A (en) * 1996-01-23 1998-11-03 Electronic Data Systems Corporation Automated travel service management information system
CN1254429A (en) * 1996-02-09 2000-05-24 国有花旗银行 Invoice purchase order system
US6072870A (en) * 1996-06-17 2000-06-06 Verifone Inc. System, method and article of manufacture for a gateway payment architecture utilizing a multichannel, extensible, flexible architecture
US6178409B1 (en) * 1996-06-17 2001-01-23 Verifone, Inc. System, method and article of manufacture for multiple-entry point virtual point of sale architecture
US6119105A (en) * 1996-06-17 2000-09-12 Verifone, Inc. System, method and article of manufacture for initiation of software distribution from a point of certificate creation utilizing an extensible, flexible architecture
US5903880A (en) * 1996-07-19 1999-05-11 Biffar; Peter C. Self-contained payment system with circulating digital vouchers
EP2028614A3 (en) * 1996-10-09 2010-01-06 Visa International Service Association Electronic statement presentation system
US5903881A (en) * 1997-06-05 1999-05-11 Intuit, Inc. Personal online banking with integrated online statement and checkbook user interface
US6128602A (en) * 1997-10-27 2000-10-03 Bank Of America Corporation Open-architecture system for real-time consolidation of information from multiple financial systems
JP3333126B2 (en) * 1997-11-27 2002-10-07 株式会社ビジネスブレイン太田昭和 Accounting system with automatic journalizing function for transfer payment data
US6006204A (en) * 1997-12-18 1999-12-21 International Business Machines Corporation Correlating transaction records via user-specified identifier creating uncleared transaction
US6068194A (en) * 1998-02-12 2000-05-30 Cummins-Allison Corporation Software loading system for an automatic funds processing system
US6189785B1 (en) * 1998-04-14 2001-02-20 International Check Services Demand deposit account data processing system
AU741608B2 (en) 1998-05-04 2001-12-06 Paul Joseph Bentley Variable timing poppet valve apparatus
JPH11328292A (en) * 1998-05-11 1999-11-30 Nec Software Kyushu Ltd Installment erasure system
GB2345775A (en) 1998-10-21 2000-07-19 Ordertrust Llc Analyzing transaction information
AU763571B2 (en) 1998-12-23 2003-07-24 Chase Manhattan Bank, The System and method for integrating trading operations including the generation, processing and tracking of and trade documents
US7117172B1 (en) * 1999-03-11 2006-10-03 Corecard Software, Inc. Methods and systems for managing financial accounts
WO2001084276A2 (en) * 2000-05-01 2001-11-08 American Express Travel Related Services Company, Inc. International payment system and method
US7395231B2 (en) * 2000-07-14 2008-07-01 American Express Travel Related Services Company, Inc. Fee allocator system and method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5093787A (en) * 1986-06-12 1992-03-03 Simmons John C Electronic checkbook with automatic reconciliation
US5783808A (en) * 1996-01-11 1998-07-21 J. D. Carreker And Associates, Inc. Electronic check presentment system having transaction level reconciliation capability
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US5991750A (en) * 1997-10-24 1999-11-23 Ge Capital System and method for pre-authorization of individual account transactions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1323093A4 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11373151B2 (en) * 2002-12-09 2022-06-28 Live Nation Entertainment, Inc. Apparatus for access control and processing
US11593501B2 (en) 2002-12-09 2023-02-28 Live Nation Entertainment, Inc. System and method for using unique device identifiers to enhance security
US8326712B2 (en) 2003-04-16 2012-12-04 American Express Travel Related Services Company, Inc. Method and system for technology consumption management
US8326713B2 (en) 2003-04-16 2012-12-04 American Express Travel Related Services Company, Inc. Method and system for technology consumption management including allocation of fees
AU2004273117B2 (en) * 2003-09-12 2009-07-16 Swiss Reinsurance Company Ltd. Computer-based system for transactions processing
EP1542147A2 (en) * 2003-11-24 2005-06-15 Cargill Incorporated Global balancing tool
EP1542147A3 (en) * 2003-11-24 2005-08-31 Cargill Incorporated Global balancing tool
JP2008509482A (en) * 2004-08-06 2008-03-27 アメリカン・エキスプレス・トラベル・リレイテッド・サービシズ・カンパニー・インコーポレーテッド Method and system for billing and matching for improved travel transactions
JP4908412B2 (en) * 2004-08-06 2012-04-04 アメリカン エクスプレス トラベル リレイテッド サービシーズ カンパニー, インコーポレイテッド Method and system for billing and matching for improved travel transactions
US8301554B2 (en) 2005-06-30 2012-10-30 American Express Travel Related Services Company, Inc. System and method for managing meetings budgets and allocating and reconciling expenditures
JP2009501978A (en) * 2005-07-15 2009-01-22 レボリューション マネー,インコーポレイテッド System and method for putting doubt on individual items to be traded
US8469268B2 (en) 2005-07-15 2013-06-25 Serve Virtual Enterprises, Inc. System and method for disputing individual items that are the subject of a transaction

Also Published As

Publication number Publication date
JP2006073031A (en) 2006-03-16
AU2001285284B2 (en) 2005-02-24
US7693787B2 (en) 2010-04-06
US7698216B2 (en) 2010-04-13
KR20030024896A (en) 2003-03-26
MXPA03001652A (en) 2004-04-02
BR0113492A (en) 2003-07-15
US20070112653A1 (en) 2007-05-17
NZ524362A (en) 2004-06-25
US20070130028A1 (en) 2007-06-07
JP2004507823A (en) 2004-03-11
US7693788B2 (en) 2010-04-06
US20020026416A1 (en) 2002-02-28
EP1323093A1 (en) 2003-07-02
EP1323093A4 (en) 2007-02-21
US20070130027A1 (en) 2007-06-07
AU8528401A (en) 2002-03-04
CA2423113A1 (en) 2002-02-28
US7756784B2 (en) 2010-07-13

Similar Documents

Publication Publication Date Title
AU2001285284B2 (en) System and method for account reconciliation
AU2001285284A1 (en) System and method for account reconciliation
US6993502B1 (en) Transaction tax collection system and method
US7552089B2 (en) Method and apparatus for automatically applying/linking transactions in a financial management system
US6343279B1 (en) System integrating credit card transactions into a financial management system
US7424455B2 (en) Method and systems for providing merchant services with right-time creation and updating of merchant accounts
US7970671B2 (en) Automated transaction processing system and approach with currency conversion
US8521613B2 (en) Expense tracking, electronic ordering, invoice presentment, and payment system and method
US20030055754A1 (en) Method, system and computer program product for facilitating a tax transaction
US20050246276A1 (en) Method for disbursing account payable
US20150228018A1 (en) System, method, and program products for compiling credits issued by a travel product provider
JP2000348099A (en) Processing system for small amount of expenses, client computer constituting the system and program recording medium for the computer
US10127558B2 (en) Expense tracking, electronic ordering, invoice presentment, and payment system and method
WO2001041020A1 (en) Server-based billing and payment system
CA2390379A1 (en) Transaction tax collection system and method
AU2008203400B2 (en) System and method for account reconciliation
JP3926674B2 (en) Database system, database system network, data item registration method, and data item registration program
WO2001008064A1 (en) Computer-based system for simplification of tax collections and remittances for internet and mail order commerce
US7634444B2 (en) Method and apparatus for applying/linking transactions in a financial management system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2423113

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2001964431

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2002521820

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020037002501

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: PA/a/2003/001652

Country of ref document: MX

Ref document number: 524362

Country of ref document: NZ

WWE Wipo information: entry into national phase

Ref document number: 2001285284

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 1020037002501

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2001964431

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 524362

Country of ref document: NZ

WWG Wipo information: grant in national office

Ref document number: 524362

Country of ref document: NZ

WWR Wipo information: refused in national office

Ref document number: 1020037002501

Country of ref document: KR