GB2442759A

GB2442759A - Reconciliation of batch payments

Info

Publication number: GB2442759A
Application number: GB0620396A
Authority: GB
Inventors: Vladimir Rovinsky; Siddhartha Sinha
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2006-10-13
Filing date: 2006-10-13
Publication date: 2008-04-16
Also published as: GB0620396D0

Abstract

Submission identifier information is assigned to a batch of payment requests that is issued for payment. The submission identifier information is preserved during subsequent payment processing such that it is evident in one or more subsequently received bank statements that contain data representative of a payment or payments that correspond to payment requests in the batch. During a manual, automatic or partially automatic reconciliation process, submission identifier information is utilized to match payment documents in the accounting application to one or more corresponding withdrawals as reflected in the bank statement(s).

Description

--

SUBMISSION REFERENCE FOR

RECONCILING BATCH PAYMENTS

BACKGROUND

1] There are various organizations involved in the electronics payment industry. Such organizations include payment provider entities, which are service providers that process payment requests received from their clients, typically financial institutions and payment bureaus.

Examples of payment provider entities include the Automatic Clearing House (ACH) in the United States and the Bankers Automated Clearing Services (BACS) in the United Kingdom.

2] Finance-oriented software applications, such as accounting applications, often provide payment functionality configured to enable a user to arrange for and/or track payments to people (e.g., employees) or legal entities (e.g., creditors) . In some cases, there is support for multiple payment methods such as payment by cheque, by credit card, or through an online banking transaction. In many cases, making a payment involves two steps, namely, creation of a payment document (e.g., posting of a payment to a general ledger) and issuance of a corresponding payment request (e.g., printing and sending a cheque, electronically communicating a payment request, etc.) [0003] Some accounting applications are configured to combine multiple payment requests into a single issuance process rather than repeating the process for each separate request. This is referred to as a batched issuance of a payment request. In some cases, payments that constitute a batch request are recorded as separate payment documents within an accounting application, wherein each document has individual attributes such as payment date, amount, currency, etc. [0004] When a batch payment request is processed, for example by a payment provider entity, it is not uncommon that there be at least one bank account withdrawal (against an account maintained by the user) that covers more than one payment request in the batch. Further, the date of this combined withdrawal is frequently different than the representation in the accounting application of the date of corresponding payments in the batch. Accordingly, when the user views a bank statement reflecting account payment activity, it can be difficult to determine parallels to the same information in the accounting application. Therefore, the effects of batched issuance of a payment request, including grouped payment withdrawals and differences in transaction or processing dates, often make it a challenge to reconcile payment activities between an accounting

application and a bank statement.

(0005] The discussion above is merely provided for general background information and is not intended for use as an aid in determining the scope of the claimed subject matter.

SUMMARY

6] Submission identifier information is assigned to a batch of payment requests that is issued for payment.

The submission identifier information is preserved during subsequent payment processing such that it is evident in one or more subsequently received bank statements that contain data representative of a payment or payments that correspond to payment requests in the batch. During a manual, automatic or partially automatic reconciliation process, submission identifier information is utilized to match payment documents in the accounting application to one or more corresponding withdrawals as reflected in the

bank statement(s)

7] A first aspect is directed to a computer-implemented method of supporting reconciliation of data packets, the method comprising: generating a data packet from a plurality of input data elements; generating submission identifier information; assigning the submission identifier information to the data packet; transmitting the data packet and the submission identifier information to a data processing service; and retaining a record of the submission identifier information.

8] A second aspect is directed to a computer-implemented method of supporting reconciliation of data packets, the method comprising: receiving submission identifier information that corresponds to a data processing transaction, wherein the submission identifier information is indicative of a data packet, the data packet relates to a plurality of input data elements and the data processing transaction is associated with at least one of the plurality of input data elements; and incorporating the submission identifier information into an output data element associated with the data processing transaction.

9] A third aspect is directed to a computer-implemented method of supporting reconciliation of batch payments, the method comprising: generating a batch payment request; generating submission identifier information; assigning the submission identifier information to the batch payment request; transmitting the batch payment request to a payment processing service; and retaining a record of the submission identifier information.

0] A fourth aspect is directed to a computer-implemented method of supporting reconciliation of batch payments, the method comprising: receiving a collection of payment instructions; receiving submission identifier information that corresponds to the collection of payment instructions; and communicating the submission identifier information to one or more banks associated with accounts with which transactions are conducted based on the collection of payment instructions.

1] A fifth aspect is directed to a computer-implemented method of supporting reconciliation of batch payments, the method comprising: receiving submission identifier information that corresponds to a withdrawal transaction, wherein the submission identifier information is indicative of a batch payment request; and incorporating the submission identifier information into a bank

statement.

2] A sixth aspect is directed to an accounting tool comprising: means for generating a batch payment request; means for generating submission identifier information; means for assigning the submission identifier information to the batch payment request; means for transmitting the batch payment request to a payment processing service; and means for retaining a record of the submission identifier information.

3] A further aspect is directed to an accounting tool comprising: means for receiving a collection of payment instructions; means for receiving submission identifier information that corresponds to the collection of payment instructions; and means for communicating the submission identifier information to one or more banks associated with accounts with which transactions are conducted based on the collection of payment instructions.

(0014] Another aspect is directed to an accounting tool comprising: means for receiving submission identifier information that corresponds to a withdrawal transaction, wherein the submission identifier information is indicative of a batch payment request; and means for incorporating the submission identifier information into a bank statement.

5] A further aspect is directed to a system substantially as described herein and shown in FIG. 1.

6] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended for use as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted

in the background.

BRIEF DESCRIPTION OF THE DRAWINGS

(0017] FIG. 1 is a schematic diagram of a payment system.

8] FIG. 2 is a block flow diagram demonstrating a series of steps associated with the creation and processing of a batched payment request.

9] FIG. 3 is a flow chart diagram demonstrating steps associated with the establishment and utilization of submission identifier information.

(0020] FIGS. 4 and 5 are example screen shots, each of which is an application user interface configured to include an indication of submission identifier information.

(0021] FIG. 6 is an example of a portion of a statement.

(0022] FIG. 7 illustrates an example of a computing system environment.

DETAILED DESCRIPTION

3] FIG. 1 is a schematic diagram of a payment system 100. System 100 includes an accounting application 102.

Application 102 illustratively, although not necessarily, includes a payment method selection component 104.

Component 104 is configured to provide a user interface component that enables a user of application 102 to select any of a plurality of means for disbursing a payment.

System 100 also illustratively, although not necessarily, includes a payment driver 106 having backend implementation for each of the payment methods available to the user. For example, in one embodiment, component 104 interacts with a cheque driver 106 that is configured to facilitate payment by enabling cheques to be printed, and/or by enabling cheque numbers to be assigned within application 102 for cheques that are written manually, and/or by supporting other cheque-related functionality. Other drivers are configured to support functionality for other payment methods (e.g., for credit card transactions, online banking transactions, etc.) (0024] Accounting Application 102 is illustratively configured to enable a user to create payment documents 108. Each payment document 108 represents an instance of a payment. In one embodiment, each payment document has an "originating account" from where funds are to be withdrawn to cover the affiliated payment. The originating account could be a bank account, a cash account, etc. Each payment document 108 also includes an indication of a "payee," which is the intended recipient of the affiliated payment.

(0025] Within system 100, one payment method that is available to a user of application 102 is payment through a payment provider entity 110. Entity 110 is a service provider that processes payment requests and facilitates (or enables) transfers of funds accordingly. Examples of payment provider entities, not by limitation, include the Automatic Clearing House (ACH) in the United States and the Bankers Automated Clearing Services (BACS) in the United Kingdom.

(0026] It is not uncommon for a particular payment provider entity to require clients that wish to submit payment requests for processing to comply with certain requirements. In some cases, these requirements may force the client to purchase expensive software, provide staff with specialized training, and/or implement complex security and contingency procedures. While it is certainly within the scope of the present invention for accounting application 102 to be configured to directly submit payment requests to payment provider entity 110 for processing, the requirements of entity 110 may make this a relatively unlikely scenario.

(0027] The more likely scenario is that payment requests from accounting application 102 will be submitted through a payment interface entity 112. Entity 112 is illustratively configured to receive payment requests from accounting application 102. Application 102 is configured to communicate (e.g., electronically communicate) these payment requests to entity 112 in accordance with an application protocol 114. Entity 112 assumedly expects and accepts such requests formatted in accordance with that protocol.

8] Payment interface entity 112 is illustratively a client of payment provider entity 110 and complies with the requirements necessary to directly submit payment requests for payment processing. Accordingly, entity 112 is configured to communicate (e.g., electronically communicate), to payment provider entity 110, payment requests that correspond to the requests received from application 102. The requests communicated to entity 110 are illustratively formatted to comply with a public protocol 116. Entity 110 assumedly expects and accepts such requests formatted in accordance with that protocol.

Those skilled in the art will appreciate that while protocol 116 is referred to herein as "public," it may in fact be secured, proprietary, or otherwise protected so as to prevent or deter fraudulent payment processing.

9] From the perspective of application 102, payment interface entity 112 lowers the bar in terms of what is required to make payment provider entity 110 available as a method for processing payments. The cost of utilizing entity 112 is generally less than the overall cost of implementing entity 110 as a direct method of payment.

Typically, payment interface 112 will be a financial institution or payment bureau that offers payment services that include access to payment functionality associated with a payment provider entity 110.

(0030] Each payment document 108 illustratively has its own set of attributes such as payment date, amount, currency, etc. Thus, each payment document generally corresponds to an individual payment request. In one embodiment, accounting application 102 is configured to combine multiple payment requests that correspond to multiple payment documents 108 into a single issuance process rather than repeating the process for each separate request. This is referred to as a batched issuance of a payment request.

(0031] FIG. 2 is a block flow diagram demonstrating a series of steps associated with the creation and processing of a batched payment request within system 100. In accordance with block 202, a user of application 102 creates a plurality of payment documents 108 that designate one or more payment services provided by entity 110 as the applicable payment method. In accordance with block 204, the user initiates (e.g., through interaction with an application user interface) issuance of the plurality of payment documents 108.

(0032] In accordance with step 206, there is an execution of client side processing of the payment documents so as to generate a corresponding batch payment request. The applicable payment method driver 106 is illustratively responsible for this processing step. In one embodiment, this step involves preliminary validation on one or more payment documents to ensure that payment information meets certain predefined requirements. If there is some information missing or incorrect, an error message is presented to the user and payment processing (of erroneous or all payment document(s) in the batch) is at least temporarily suspended to afford an opportunity to correct the outstanding issues.

(0033] In accordance with step 208, the batch payment request (shown in FIG. 1 as box 120) is transmitted (e.g., over a computer network such as but not limited to the Internet) to payment interface entity 112. This request is illustratively formatted in accordance with application protocol 114. In one embodiment, the batch payment request comprises a "submission header." The submission header serves as an envelope of sorts for the associated payment information. While the content of the header is flexible, it illustratively includes data related to the payments reflected in the batch such as, but not limited to, the applicable currency of the payments, the total amount of all payments, etc. In one embodiment, for each payment to be processed, the submission header contains a "transaction" as a child. Payment driver 106 is illustratively configured to create a given transaction by culling information from a payment document 108, an associated payee account as reflected within the records of application 102, and an originating bank account also reflected within the records of application 102.

(0034] In accordance with box 210, the payment interface entity 112 processes the batch payment request and translates it into corresponding payment instructions appropriate for payment provider entity 110. In accordance with block step 212, the payment instructions, identified as box 122, are transmitted to payment provider entity 110.

This transmission is illustratively, although not necessarily, electronic in nature and could be across any of a variety of different computer network systems including, but not limited to, the Internet, a secured direct network connection, a secured public network connection, etc. Finally, in accordance with box 214, payment provider entity 110 facilitates transfers of funds between bank accounts based on the payment instructions.

It should be noted that the present invention is not necessarily limited to an entity 110 that transfers money itself. Entity 110 could just as easily be a different kind of entity such as, but not limited to, an entity that validates financial data and acts as a sort of broker or policing entity that directs banks to make payments.

5] As is indicated by block 216, during transfers of funds facilitated by entity 110, the process includes crediting one or more accounts at one or more banks associated with one or more payees. FIG. 1 provides one example in that there is an indication of payments being made to accounts at multiple banks 130. For each bank 130, the payment may be disbursed across multiple payee accounts or directed at a single payee account, depending upon the nature of payment instructions 122.

6] As is indicated by block 218, the fund transfer process includes debiting one or more accounts at one or more banks associated with a person or entity affiliated with application 102. In the example shown in FIG. 1, a single debit 142 is made to an account at a bank 140 in order to cover the payments to banks 130. Depending on the nature of instructions 122, debit 142 may subtract funds from multiple accounts at bank 140 instead of just a single account (in one embodiment, as has been alluded to, all debits occur on the same date). The present invention is not limited to the illustrated scenario. Debits could just as easily be from multiple accounts at multiple banks, etc. Further, within FIG. 1, the dotted arrow labelled 144 represents an optional scenario wherein payment interface entity 112 is an organization that maintains an account from which funds are extracted based on instructions 122.

In theory, depending on the payment instructions, this debit could be in addition to or in place of the debit from the bank 140 account or accounts. The example scenarios shown in FIG. 1 are intended simply to demonstrate the flexibility of the system in terms of where funds are actually added and subtracted. Scenarios other than those illustrated should certainly be considered within the scope of the present invention.

7] It was stated above that, depending on the nature of instructions 122, debit 142 may subtract funds from multiple accounts and/or multiple banks. In one embodiment, application 102 is configured to prohibit some or all such scenarios. For example, application 102 may be configured to require all payment documents within a common batch to involve payment originating from the same account.

Alternatively, application 102 may be configured to require all payment documents within a common batch to involve payment originating from the same bank (i.e., but not necessarily the same account). Other similar restrictions are also within the scope of the present invention.

8] In one embodiment, entity 112 is a banking institution that also maintains one or more accounts on behalf of a user of application 102. As payment provider entity credits and debits accounts based on payment requests originating from application 102 and communicated through entity 112, one or more of the accounts maintained by entity 112 on behalf of the user of application 102 may be credited or debited accordingly. However, this need not necessarily be the case.

9] When batch payment request 120 is processed by payment provider entity 110 it is relatively likely that there be at least one bank account withdrawal against an account maintained by the user in an amount that covers more than one payment document 108 in the batch. Further, the date of this combined withdrawal is frequently different than the representation in the accounting application of the date of corresponding payments in the batch. As will be explained in detail below, this can make account reconciliation into a difficult undertaking.

0] As is shown in FIG. 1, banks that maintain accounts that are debited in response to the batch payment request 120 will typically provide account statements 150.

A statement 150 is provided to application 102 (e.g., in an electronic format) and/or to a user 152 of application 102 (e.g., in a paper and/or electronic format). These statements are utilized to reconcile application payment records (e.g., payment documents 108) with payments that have actually been made (e.g., debit 142, 144, etc.). This reconciliation process is typically executed automatically by application 102, manually by user 152 or semi-automatically by user 152 applying reconciliation tools integrated into application 102.

(0041] Unfortunately, during the reconciliation process, when application 102 and/or user 152 considers payments reflected in account statement(s) 150, it can be difficult to ascertain parallels to corresponding payment request information in the accounting application. The effects of batched issuance of a payment request, including grouped payment withdrawals and differences in transaction dates, often make it a challenge to reconcile payment activities between an accounting application and a bank statement.

2] In one embodiment, payments reflected in batch payment request 120 are assigned a submission identifier, which is generally indicated in FIG. 1 as submission identifier information 180. Identifier information 180 is preserved during subsequent payment processing such that it is evident in the one or more subsequently received bank statements 150 that contain data representative of a payment or payments that originated from corresponding bank account(s) that are linked to individual payments requests included in batch payment request 120. During a manual, automatic or partially automatic reconciliation process, submission identifier 180 is utilized to match payment documents in accounting application 102 to one or more corresponding withdrawals as reflected in the bank

statement(s)

3] FIG. 3 is a flow chart diagram demonstrating steps associated with the establishment and utilization of submission identifier information 180. As was described in relation to FIG. 2, a payment method driver 106 generates a batch payment request 120 that is eventually transmitted to payment interface entity 112. In accordance with block 302, driver 106 is configured to assign, prior to transmission, submission identifier information 180 to batch payment request 120. The identifier information may be associated with each individual payment reflected within request 120 or may be associated collectively. The assignment of submission identifier information is illustratively done on a unique basis such that different batch payment requests 120 will have different submission identifier information 180. Submission identifier information is illustratively, although not necessarily, captured in the submission header, if such a header is included in a given implementation.

(0044] Those skilled in the art will appreciate that the present invention is not limited to an architecture that incorporates a payment method driver. Implementation of payment method drivers is described herein simply as an example implementation. Without departing from the scope of the present invention, functionality the same or similar to that described herein as being attributed to a payment method driver or drivers can be facilitated within an architecture that does not include any such driver.

5] In one embodiment, before or after transmission of the batch payment request 120, submission identifier information is presented to the user of application 102 in a user interface (UI) component. In one embodiment, during the process of issuing payments or creating a batch in the application, a processing date for the batch is assigned, either by the application or by a user.

6] In accordance with block 304, submission identifier information 180 is transmitted to payment interface entity 112. Illustratively, although not necessarily, information 180 is transmitted along with the affiliated batch payment request 120. In one embodiment, this transmission is accomplished through a web service call to a server associated with the payment interface entity (e.g., the submission header and/or the transactions are sent to the server) (0047] In accordance with block 306, a record of submission identifier information 180 is retained and made available to application 102. As is indicated by block 308, which is shown in dotted lines to signify the particular optional nature of the step, the identifier information 180 may be incorporated into one or more of the application user interfaces (as will become apparent, for applications 102 that have a reconciliation component, this step is likely to be included). For example, an indicator representative of information 180 may be listed as the uspayment display number" for related payment documents (e.g., similar to listing a cheque number for a cheque-oriented payment document).

8] In accordance with block 310, submission identifier information 180 is transmitted to payment provider entity 110 (e.g., transmitted with or separate from payment instructions 122). In accordance with block 312, payment provider entity 110 communicates the information 180 to the bank or banks from which debits are made to cover payments made in accordance with instructions 122. In accordance with block 314, submission identifier information 180 is incorporated into statement(s) 150 that are sent to a user 152 of application 102. Finally, in accordance with block 316, submission identifier information in statement(s) 152 is compared to the retained record of submission identifier information for any of a variety of purposes such as, but not necessarily limited to, for the purpose of reconciling an account associated

with statement(s) 150.

(0049] Those skilled in the art will appreciate that processing scenarios other than those specifically described herein are also within the scope of the present invention. For example, payment instructions could just as easily be sent directly to a bank (or banks) that directly initiate and/or facilitate the transfer(s) of funds. This is but one example of another scenario within the scope of the present invention.

(0050] In one embodiment, a user 152 can manually reconcile statement(s) 150 by comparing against a bank account register user interface associated with application 102. The bank account register interface illustratively displays a collection of transactions, such as a set of transactions affecting a particular bank or banks, or a particular account or accounts. The bank account register interface also illustratively includes submission identifier information on a payment-specific basis, as well as other information such as, but not limited to, payee information, amount paid information, etc. (0051] Accounting applications sometimes show, such as within an account register, cheque numbers, application document numbers, etc. In one embodiment, application 102 is configured, for documents in a batch, to place submission identifier information, within a reconciliation interface (or within a register interface or any other interface) in a field or location that is equivalent to placement of a cheque number (e.g., the identifier information appears within a transaction listing where a cheque number appears for cheque transaction).

(0052] Bank statement 150 illustratively, although not necessarily, contains an indication of a single withdrawal of the total amount of all payments withdrawn (e.g., from a particular bank account) following processing of a batch payment request 120. The date of this withdrawal is illustratively the processing date as specified by the user. The submission identifier information 180 assigned to the batch is reflectedin the statement, such as in a reference/memo field associated with the transaction.

(0053] To reconcile manually, the user need simply match payments in the account register interface to the single transaction in the bank statement. Thus, the user is not forced to manually track information such as issuance date, payments that correspond to a given batch, the amount of a batch payment, etc. in order to be able to make associations as necessary to support an efficient process of reconciliation.

4] Application 102 is illustratively configured to support user interface components that incorporate, in a variety of different ways, the described support for the tracking of submission identifier information through payment processing system 100 as described herein. For example, submission identifier information is illustratively incorporated into application 102 user interface components such as but not limited to lists, reports, reconciliation processing screens, etc. FIGS. 4 and 5 are example screen shots 400 and 500, each of which is a user interface configured to include an indication of the identifier information.

(0055] Screen shot 400 is a payment report display within which column 402 shows what payment method was assigned to a given payment, column 404 shows an applicable identifier, and column 406 shows an applicable payment date. Within column 402, the top two payment transactions are identified as "BACS" transactions, which means that they are affiliated with payment through a payment provider entity. Column 404 shows that each of these payment transactions was included in a batch issuance process.

This is known because the applicable submission identifier information is listed within that column. In one embodiment, at least for the transactions included in batch payment processing, the date in column 406 is the assigned batch processing date and not the date of submission for processing.

6] Screen shot 500 is a reconciliation/matching display configured to provide specific support for reconciliation functionality. A user is able to select transactions during the reconciliation process. As is shown in column 502, submission identifier information is -19-included in the display. Thus, specific transactions can be balanced or matched against a summary entry or entries

in a bank statement(s) that is identified with

corresponding submission identifier information. In one embodiment, application 102 provides specific support (e.g., specific UI components and related functionality) for reconciling batch payment requests with corresponding entries in bank statements that are identified with submission identifier information.

(0057] FIG. 6 is an example of a portion of a statement 600. Statement 600 could be either a paper or electrically

submitted statement. Those skilled in the art will

appreciate that an actual statement is likely to contain additional information such as account and bank information. Statement 600 is a simplification intended for illustrative purposes only. Statement 600 contains an indication of a single withdrawal of the total amount of all payments following processing of a batch payment request (e.g., payments in batch 120 originating from a bank account at bank 140). In the illustrated case, the total amount, shown in the withdrawal column, is "1468.57".

The date of the withdrawal, shown in the first column, is illustratively the processing date as specified by the user or assigned by application 102. The submission identifier information assigned to the batch is shown in the third column. Statement 600 is likely to show other withdrawals from the same account during the time period. If these withdrawals were not part of a batch payment request, then, illustratively, no submission identifier information would be provided.

(0058] FIG. 7 illustrates an example of a suitable computing system environment 700 in which embodiments may be implemented. The computing system environment 700 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the claimed subject matter.

Neither should the computing environment 700 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 700.

(0059] Embodiments are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with various embodiments include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, telephony systems, distributed computing environments that include any of the above systems or devices, and the like.

(0060] Embodiments have been described herein in the general context of computer-executable instructions, such as program modules, being executed by a computer.

Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Embodiments can be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located on both (or either) local and remote computer storage media including memory storage devices.

(0061] With reference to FIG. 7, an exemplary system for implementing some embodiments includes a general-purpose computing device in the form of a computer 710. Components of computer 710 may include, but are not limited to, a processing unit 720, a. system memory 730, and a system bus 721 that couples various system components including the system memory to the processing unit 720.

(0062] Computer 710 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 710 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 610.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

Combinations of any of the above should also be included within the scope of computer readable media.

3] The system memory 730 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 731 and random access memory (RM) 732. A basic input/output system 733 (BIOS), containing the basic routines that help to transfer information between elements within computer 710, such as during start-up, is typically stored in ROM 731. RAN 732 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 720. By way of example, and not limitation, FIG. 7 illustrates operating system 734, application programs 735, other program modules 736, and program data 737. As is indicated, programs 735 may include accounting application 102 as described above in relation to FIG. 1. This need not necessarily be the case.

4] The computer 710 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only, FIG. 7 illustrates a hard disk drive 741 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 751 that reads from or writes to a removable, nonvolatile magnetic disk 752, and an optical disk drive 755 that reads from or writes to a removable, nonvolatile optical disk 756 such as a CD ROM or other optical media.

Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAIVI, solid state ROM, and the like. The hard disk drive 741 is typically connected to the system bus 721 through a non-removable memory interface such as interface 740, and magnetic disk drive 751 and optical disk drive 755 are typically connected to the system bus 721 by a removable memory interf ace, such as interface 750.

(0065] The drives and their associated computer storage media discussed above and illustrated in FIG. 7, provide storage of computer readable instructions, data structures, program modules and other data for the computer 710. In FIG. 7, for example, hard disk drive 741 is illustrated as storing operating system 744, application programs 745, other program modules 746, and program data 747. Note that these components can either be the same as or different from operating system 734, application programs 735, other program modules 736, and program data 737. operating system 744, application programs 745, other program modules 746, and program data 747 are given different numbers here to illustrate that, at a minimum, they are different copies. As is indicated, programs 745 may include accounting application 102 as described above in relation to FIG. 1. This need not necessarily be the case.

(0066] A user may enter commands and information into the computer 710 through input devices such as a keyboard 762 and a pointing device 761, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, microphone, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 720 through a user input interf ace 760 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (tJSB).

A monitor 791 or other type of display device is also connected to the system bus 721 via an interface, such as a video interface 790. In addition to the monitor, computers may also include other peripheral output devices such as speakers 797 and printer 796, which may be connected through an output peripheral interface 795.

(0067] The computer 710 is operated in a networked environment using logical connections to one or more remote computers, such as a remote computer 780. The logical connection depicted in FIG. 7 is a wide area network (WAN) 773, but may also or instead include other networks.

Computer 710 includes a modem 772 or other means for establishing communications over the WAN 773, such as the Internet. The modem 772, which may be internal or external, may be connected to the system bus 72]. via the user-input interface 760, or other appropriate mechanism.

8] By way of example, and not limitation, FIG. 7 illustrates remote application programs 785 as including functionality for the support of remote payment processing.

In one embodiment, applications 785 represent payment functionality provided by payment interface 112 or payment provider entity 110 as described above in relation to FIG. 1.

9] It is worth emphasizing that inclusion of a payment interface entity 112 in the payment process is not critical to the present invention. A system including entity 112 is provided as but one example of a system within the scope of the present invention. Any system wherein application 102 communicates with a payment provider, whether directly or indirectly through another entity or entities, is within the scope of the present invention. It is interesting that submission identifier information is preserved to the bank or banks. The path taken to the bank or banks is not critical to the present invention. All such paths are within the scope of the invention, whether specifically described herein or not.

0] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

WHAT IS CLAIMED IS: 1. A computer-implemented method of supporting

reconciliation of data packets, the method comprising: generating (206) a data packet (120) from a plurality of input data elements (108); generating submission identifier information (180); assigning (302) the submission identifier information (180) to the data packet (120) transmitting the data packet (120) and the submission identifier information (180) to a data processing service (112, 110) ; and retaining (306) a record of the submission identifier information (180)
2. A computer-implemented method of supporting reconciliation of data packets, the method comprising: receiving (312) submission identifier information (180) that corresponds to a data processing transaction (144, 142), wherein the submission identifier information is indicative of a data packet (120), the data packet relates to a plurality of input data elements (108) and the data processing transaction is associated with at least one of the plurality of input data elements; and incorporating (314) the submission identifier information (180) into an output data element (150) associated with the data processing transaction.
3. The method of claim 2, further comprising: accessing data relating to at least one of the plurality of input data elements (108); and reconciling the accessed data and the output data element.
4. A computer-implemented method of supporting reconciliation of batch payments, the method comprising: generating (206) a batch payment request (120); generating submission identifier information (180); assigning (302) the submission identifier information (180) to the batch payment request (120); transmitting the batch payment request (120) to a payment processing service (112, 110); and retaining (306) a record of the submission identifier information (180).
5. The method of claim 4, wherein transmitting comprises transmitting (208) to a payment interface entity (112)
6. The method of claim 4, wherein transmitting comprises transmitting to a payment provider entity (110).
7. The method of any of claims 4-6, further comprising incorporating (308) a representation of the submission identifier information (180) into a user interface component (400, 500)
8. The method of claim 7, wherein incorporating (308) comprises incorporating into a user interface component (404, 502) configured to facilitate description of a financial transaction.
9. The method of claim 7, wherein incorporating (308) comprises incorporating into a user interface component (400, 500) that lists a summary of payment transaction information.
10. The method of any of claims 4-9, wherein transmitting the batch payment request (120) to a payment processing service (112, 110) further comprises transmitting a processing date that is a date assigned by a user of a client accounting application (102).
11. The method of claim 4, wherein transmitting the batch payment request (120) to a payment processing service (112, 110) comprises transmitting (304) to a payment interface entity (112) utilizing an application protocol (114).
12. The method of any of claims 4-11, further comprising utilizing the record of submission identifier information (180) to facilitate a semi-automatic reconciliation of payments involving user-interaction with a reconciliation tool that is an integrated part of application (102).
13. The method of any of claims 4-11, further comprising utilizing the record of submission identifier information (180) to facilitate an automatic reconciliation of payments.
14. A computer-implemented method of supporting reconciliation of batch payments, the method comprising: receiving (212) a collection of payment instructions (122) ; receiving (310) submission identifier information (180) that corresponds to the collection of payment instructions (122); and communicating (312) the submission identifier information (180) to one or more banks (140, 112) associated with accounts with which transactions (142, 144) are conducted based on the collection of payment instructions (122)
15. The method of claim 14, wherein communicating (312) comprises communicating (312) to a bank (140, 112) associated with an account from which funds are withdrawn to cover a plurality of payments made based on the collection of payment instructions (122).
16. The method of claim 14 or 15, wherein receiving (212) a collection of payment instructions (122) comprises receiving (212) a collection of payment instructions (122) from a payment interface entity (112)
17. The method of any of claims 14-16, wherein receiving (212) a collection of payment instructions (122) comprises receiving (212) a collection of payment instructions (122) that correspond to a batch payment request (120).
18. The method of any of claims 14-16, wherein receiving (212) a collection of payment instructions (122) comprises receiving (212) a collection of payment instructions (122) that correspond to a batch payment request originating from a client accounting application.
19. The method of any of claims 14-18, wherein communicating (312) the submission identifier information (180) to one or more banks (140, 112) comprises communicating a processing date is a date assigned by a user of a client accounting application (102).
20. The method of any of claims 14-19, wherein receiving (212) a collection of payment instructions (122) comprises receiving (212) instructions (122) formatted in accordance with a pre-established public protocol (116).
21. A computer-implemented method of supporting reconciliation of batch payments, the method comprising: receiving (312) submission identifier information (180) that corresponds to a withdrawal transaction (144, 142), wherein the submission identifier information is indicative of a batch payment request (120); and incorporating (314) the submission identifier

information (180) into a bank statement (150).
22. The method of claim 21, wherein incorporating (314) comprises incorporating (314) into a bank statement (150) that correspond to an account from which funds have been withdrawn to cover multiple payments made in accordance with the batch payment request (120).
23. The method of claim 21 or 22, further comprising incorporating a processing date into the bank statement (150), wherein the processing date is a date assigned prior to receipt of the submission identifier information (180)
24. A computer program comprising computer program code means adapted to perform all the steps of any of the preceding claims when said program is run on a computer.
25. A computer program as claimed in claim 24 embodied on a computer readable medium.
26. An accounting tool (102) comprising: means for generating a batch payment request (120); means for generating submission identifier information (180) means for assigning (106) the submission identifier information (180) to the batch payment request (120) ; means for transmitting the batch payment request (120) to a payment processing service (112, 110); and means for retaining a record of the submission identifier information (180)