Method and system for matching remittances to transactions based on weighted scoring and fuzzy logic

[0001] Embodiments of the present invention relate to the field of business technology. Specifically, embodiments of the present invention relate to a method and systems for matching remittances to transactions based on weighted scoring and fuzzy logic.

[0002] Companies and other entities that deploy and use computer financials applications use services to process payments from their own customers. These services are commonly known as lockbox services. Lockbox services allow business entities to take advantage of economies of scale available at financial institutions such as banks. The business entity takes advantage of these economies of scale by consolidating their payment processing with that of the financial institution's other clients.

[0003] Some conventional lockbox technologies use a row-by-row (e.g., payment line-by-payment line) processing paradigm. However, a row-by-row processing paradigm can be difficult to maintain. Further, logic based on the summarization of payments can be difficult to implement with this conventional method. However, financials applications developers may for example, want to create trade deductions for a given invoice based on the final sum of all payment lines for the invoice, which could be troublesome to implement conventionally.

[0004] Typically, most lockbox files are created by human data-entry clerks. Thus, lockbox files are prone to typographical and other related errors. One significant limitation of lockbox solutions in general is the incapability of the lockbox solutions to handle user error. Also, to participate in lockbox remittance handling, a business entity typically may request that its customers mark their remittances with a unique identifier or another identifying feature, such as an identifying number or other such marker. Sometimes, the marker is be placed in a particular location on the remittance.

[0005] How customers respond to a billing entity's request for marking their remittances with an identifying number depends on several factors. One such factor is that customers cooperatively respond to the entity's request. Where customers willingly provide the requested identifying marker, other issues can arise that may hamper the lockbox remittance handling efforts. For instance, the marker may not be placed in the requested or most ideal location: customers may place the identifier based on their own whims and judgment, which can be error prone.

[0006] In order to utilize and bolster their lockbox remittance handling efforts, business entities and business financials applications developers have engaged in on-going efforts to work around these issues. Conventional efforts to correctly (e.g., accurately and precisely) match a remittance to the transaction it is intended to pay have generally aimed at attempting to render an exact match between the identifying number provided by the customer to a variety of the possible identifying numbers or other identifiers associated with a transaction.

[0007] Conventionally, the amount of a payment and the identity of the customer remitting it are also typically taken into consideration when matching the remittance to a transaction. In conventional approaches to correctly match a remittance to the transaction it is intended to pay, users also typically have to provide an order of significance of the types of identifying numbers to be matched. For instance, one exemplary possible user selected hierarchy can be to match against invoice numbers first; if that fails, match against sales order numbers, and so on.

[0008] These conventional workarounds however require precise entry of the identifying information, which as discussed above is prone to error. Conventional techniques also tend to discard possible matches because of inflexibility inherent in the selection of ordering hierarchy, such as what types identification numbers are tried. For instance, customers may sometimes remit amounts other than the invoiced amount. Thus, inflexible conventional techniques may discard matches because the payment amounts are not equal to the amount due remaining on the transaction.

[0009] The inability to accurately and precisely match a remittance with its correct corresponding transaction can be costly. A business entity may forestall applying the remittances until the correct match is made. Delay in applying the remittances can result in concomitant delay in availability of funds. Where a match is not returned on the basis of information supplied with the remittance, direct human intervention can be required in the form of research conducted, which can be painstaking, in order to match the remittance and transaction. Costs of such research can be significant.

[0010] Thus, conventional approaches matching remittances to transactions that are undertaken by business entities can be inadequate. Their processing paradigm can be difficult to maintain and can deter use of logic based on the summarization of payments. They are prone error. Identifiers used to match remittances to particular transactions may be misplaced by customers and then overlooked by the receiving entity. Conventional workarounds are constrained by inflexibility, such that they discard or overlook information that can result in proper matches between the remittance and the transactions to which they should be matched.

[0011] A method is needed that can match remittances to transactions that uses a processing paradigm that is not complicated to maintain and fosters the use of logic based on the summarization of payments. A system and/or method is also needed that can match remittances to particular transactions with relaxed sensitivity to where identifying markers are placed on a remittance and that is resistant to typographical data entry errors. Further, a system and/or method is needed that can match remittances to transactions that is flexible with regards to handling various kinds of information that can result in accurate, precise matching without discarding or overlooking such information.

[0012] A method for matching remittances to transactions is disclosed. The method for matching remittances to transactions disclosed herein uses a processing paradigm that is easy to maintain and fosters the use of logic based on the summarization of payments. The method disclosed herein also matches remittances to particular transactions with relaxed sensitivity to where identifying markers may be placed on a remittance and is resistant to typographical data entry errors. Further, the method disclosed herein is flexible with regard to handling various kinds of information that can result in accurate, precise matching without discarding or overlooking such information.

[0013] Computing power is currently available to business entities that can process large, even massive amounts of data in a cost-effective manner. Business entities currently have access to computers that have gigabytes of main memory at reasonable prices. Such low cost, high power and capacity computing resources allow implementation of computing paradigms such as those which can effectuate practical computation with imprecise data and on problems with non-unitary solutions. One such computing paradigm utilizes fuzzy logic.

[0014] One embodiment of the present invention implements a novel approach to lockbox remittance-to-transaction matching. The present embodiment takes advantage of the aforementioned currently available computing capacity to load all pertinent matching information into computer memory and process the information in memory using a fuzzy logic matching process that can compensate for inaccuracies in the data. In one embodiment, issues related to discarding possible matches due to the strict hierarchical order of identification numbers or the mismatch of the payment amount are solved by evaluating a substantial majority of possible matches.

[0015] In one embodiment, this evaluation proceeds using weights specified by the user. This evaluation provides a substantially comprehensive picture of effectively all possible matching invoices. Further, this evaluation prevents a possible match from being removed from consideration by an unfavorable hierarchy of identification numbers or an unfair weighting of the payment amount.

[0016] In one embodiment, a computer implemented method matches a remittance to a transaction by receiving remittance lines, transaction information, and matching rules wherein the matching rules assign a weight to a parameter considered in the matching, computing a weighted matching score corresponding to the parameter based upon that weight wherein the matching score corresponds to a probability of an accurate and precise match between the remittance and the transaction, and generating a match recommendation based on that weighted matching score.

[0030] A system and method for matching remittances based on weighted scoring and fuzzy logic is disclosed. Reference will now be made in detail to several embodiments of the invention, examples of which are illustrated in the accompanying drawing figures. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims.

[0031] Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art will realize that embodiments of the present invention may be practiced without these specific details. In other instances, well-known methods, processes, algorithms, procedures, networks, systems, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present invention.

[0032] A computer system that embodies a system and performs a method for matching remittances to transactions can comprise any kind of computer system with sufficient computing power and memory capacity. For example, the computer system can comprise a workstation computer system, a personal computer system, a specialized business and financial computing system, a main-frame computer system, or a supercomputer system. Modules of the system for matching remittances to transactions can be implemented in software, firmware, and/or hardware or any combination of software, firmware, and/or hardware.

[0033] Portions of the detailed descriptions of embodiments of the invention that follow are presented and discussed in terms of processes. Although specific steps and sequence thereof are disclosed in figures herein (e.g., FIG. 2, FIG. 5) describing the operations of these processes (e.g., processes 200, 500), such steps and sequence are exemplary. Embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in the flowcharts of the figures herein, and in another sequence than the sequence depicted and described.

[0034] In one embodiment, such processes are carried out by processors and electrical/electronic components under the control of computer readable and computer executable instructions comprising code contained in a computer usable medium. In one embodiment, a graphical user interface (GUI) is also effectuated by such processors and components under the control of computer readable and computer executable instructions. The computer readable and computer executable instructions reside, for example, in code within a computer usable medium and used in the processor, data storage features, memory, registers and other components of a computer system performing the method for matching remittances to transactions. However, the computer readable and computer executable instructions may reside in any type of computer readable medium.

[0035] One embodiment of the present invention provides significant reduction in miss rate (e.g., failing to accurately and precisely match a remittance to a correct, corresponding transaction). Advantageously, use of the present embodiment by a business entity can provide a business entity user with a significant savings in what must conventionally be expended on research costs associated with unapplied receipts (e.g., research conducted by trained personnel to correlate unmatched/mismatched receipts to their correct corresponding transactions). Further financial advantages can accrue to the concomitant ability to more quickly apply remittances received, once they are matched to their respective transactions.

[0036] Exemplary System for Matching Receipts

[0037] FIG. 1 depicts a computer-based system 100 for matching remittances based on weighted scoring and fuzzy logic and flow there through, according to one embodiment of the present invention. A graphical user interface (GUI) provides a plurality of matching rules setup screens 101 that allow a scoring model to be programmed. The computer controlled by the setup screens 101 provided by its GUI outputs a set of matching rules 102. Matching rules 102 specify the scoring model programmed by interactive setup screens 101 that stipulate the weight (e.g., relative scoring significance) that a variety of conditions and attributes will hold individually and with respect to each other.

[0038] A data staging program 106 stages data such as receivables data retrieved from a database 105. The receivables data comprises information that is relevant to matching remittances to corresponding transactions, based on weighted scoring and fuzzy logic. Data staging program 106 provides the information 107 that it stages to a matching program 110.

[0039] Matching program 110 receives matching rules 102 from setup screens 101 and the staged transaction information 107 from data staging program 107. Further, matching program 110 receives data from lockbox file 109. Matching program 110 then matches transactions to remittance lines to match remittances to the transactions. In one embodiment, matching program 110 uses weighted scoring according to rules 102 and applies fuzzy logic to effectuate the matching. Upon computing matches for remittance lines to their respective transactions, matching program 110 provides application recommendations 111 to a post-match handler 120.

[0040] Upon receiving application recommendations 111, post match handler (applier) 120 calls a receipts application program interface (API) 130 of an applications database to create corresponding receipts and apply matched remittances to appropriate transactions. In the event of unmatched remittances, post-match applier 120 calls a notification initiator 140 to handle them.

[0041] Receipt API 130 assigns an informative header to a receipt for use by a receipt application 131. Where the remittance line corresponding thereto in lockbox file 109 matches more than one customer (e.g., remitter), receipt API 130 assigns an appropriate receipt header to receipts.

[0042] Notification initiator 140 initiates a workflow notification 141 to a user entity 142 where matching program 110 does not determine a match for a remittance to a transaction.

[0043] Exemplary Process for Generating Match Recommendations

[0044] FIG. 2 is an exemplary flowchart of a computer-based process 200 wherein a matching program (e.g., matching program 110; FIG. 1) generates matching recommendations, according to one embodiment of the present invention. Process 200 begins with step 201, wherein the matching program receives matching rules, transaction information, and information from a lockbox file (e.g., matching rules 102, staged transaction information 107, lockbox file 109; FIG. 1).

[0045] In step 202 of FIG. 2, the matching program computes a weighted matching score for a remittance to a transaction. The matching program can compute the weighted matching score in several ways. In one embodiment, the matching program computes the weighted matching score by a process in which scores are computed over a number of parameters, each of which is weighted, strings comprising the multiplicity of weighted scores over the parameters are scored and combined, and a total score computed therefrom. One such process (e.g., process 500; FIG. 5) is discussed below.

[0046] In step 203, the matching program generates application recommendations of possible matches for use by a post match handler (e.g., post-match handler 120; FIG. 1). The recommendations may be based on the weighted matching score calculated, e.g., the higher the weighted score, the more probable it is that a particular remittance matches (e.g., corresponds to) a particular transaction.

[0047] In step 204, it is determined whether exceptions are encountered, such as scores falling below a match threshold. If it is determined that exceptions are encountered, then in step 205, the exceptions are handled.

[0048] In one embodiment, exceptions are handled by attempting to match a remittance against multiple transaction invoices. In one embodiment, matching the remittance against multiple transaction invoices is performed using a process employing a heuristic such as a Knapsack Heuristic, wherein the sum of the invoices is matched as closely as possible to the amount of the remittance.

[0049] Upon handling the exceptions (or if no exception is encountered), in step 206, the applications are handled, upon which process 200 is complete. In one embodiment, a post-match handler calls a receipt API with the matches and a notification initiator if no matches are found (e.g., post-match handler 120, receipt API 130, notification initiator 140; FIG. 1).

[0050] In performing process 200, according to one embodiment, the matching program takes the given lockbox file (e.g., lockbox file 109) and attempts to match the remittance lines contained therein to the data on transactions extracted by the data staging program (e.g., staged transaction information 107, data staging program 106; FIG. 1). In order to find the best match for a given remittance, all transactions selected by the staging program may first be scored.

[0051] The transaction with the best score is then selected and compared to a global match threshold defined by the user during set up in one example. If the score is equal to or above the given threshold, then the match is considered valid and is passed on to the receipt application program for processing. If the score is below the given threshold, the match is not considered valid.

[0052] Transmission Format definitions currently available in, for example a receivables application, are leveraged in one embodiment to control the manner in which the lockbox file is read from the file system. For instance, a user specifies the location and name of the lockbox file in a lockbox file parameter, and the format of the file using the transmission format parameter. In order to minimize memory use, in one embodiment the matching program (e.g., matching routine) first spawns a program to read the cognizant transmission format specifications from a database to a format specification file. This format specification file will then be used by the main matching program to read the lockbox file.

[0053] The lockbox transmission format specification file outlines to the main matching routine how to read the given lockbox file. Internal lockbox record entries store payment information for use during the matching and application phases. The fields in the lockbox record should correspond to fields defined in a transmission formats window. Table 1 below lists exemplary transmission format fields included in the lockbox record of one embodiment. It is appreciated that the fields in Table 1 below are exemplary; some of these fields may be omitted and/or other fields may be included in the lockbox record, in another embodiment.

[0054]

TABLE 1
Account: the payer's bank account. The bank account number and the
transit routing number make up the payer's magnetic ink character
recognition (MICR) number.
Amount Applied 1 to 8: The amount applied to each invoice, debit memo,
or chargeback in the transaction currency. Each payment or overflow
payment record can accommodate up to eight debit item numbers in one
example. For cross currency applications, this can be the amount to apply
in the transaction currency and corresponds to the Amount Applied field in
the Applications window.
Bank Transaction Code: A code defined for each account that is used by
the bank to uniquely identify the kind of transaction in a bank statement
(for example, debit, credit, void). This is also used by a cash management
application or similar application to determine a receipt's effective date.
Customer Bank Branch Name: The name of the customer's bank branch.
Customer Bank Name: The name of the customer's bank.
Customer Number: The identification number of the customer who
submitted a payment.
Deposit Date: The date the bank receives and deposits the customer's
payment.
Effective Date: The date on which the bank determines a customer's
balance to apply interest (used by a cash management application's
forecasting feature).
Invoice 1 to 8: The invoices, debit memos, and chargebacks to which a
business entity applies the payment. Each payment or overflow payment
record can accommodate up to eight debit item numbers.
Invoice 1 to 8 Installment: The installment number for this invoice.
Lockbox Number: The identification number for a specific lockbox.
Payment Method: The payment method associated to this lockbox.
Payment Number: The identification number of a payment. For example, a
check number.
Receipt Date: The date the customer made a payment.
Record Identifier: A number that identifies the kind of transmission record
(e.g., Overflow Payment, Payment, Lockbox Header, etc.).
Remittance Amount: The amount of the payment.
Transit Routing Number: The number that uniquely identifies the payer's
bank. The transit routing number and the customer bank account number
make up the payer's MICR number.

[0055] In one embodiment, the following lockbox record fields are used by the Matching Program to identify matches:

[0056] Account Number (in conjunction with the Transit Routing Number);

[0057] Amount Applied 1 to 8;

[0058] Customer Number;

[0059] Invoice 1 to 8;

[0060] Invoice 1 to 8 Installment;

[0061] Payment Number;

[0062] Transit Routing Number (in conjunction with the Account Number).

[0063] In one embodiment, the following fields are used when the actual applications are made:

[0064] Bank Transaction Code;

[0065] Customer Bank Branch Name;

[0066] Customer Bank Name;

[0067] Deposit Date;

[0068] Effective Date;

[0069] Lockbox Number;

[0070] Payment Method;

[0071] Receipt Date.

The matching routine reads these fields in to communicate them along with the applications it recommends to the application routine.

[0072] In one embodiment, cross-currency applications are not considered. In the present embodiment therefore, the following field types (available for cross-currency applications) are not included in the lockbox record. The routine logs an error and exits immediately if any are encountered in the lockbox file:

[0073] Amount Applied From;

[0074] Currency Code;

[0075] Exchange Rate;

[0076] Exchange Rate Type;

[0077] Invoice Currency Code;

[0078] Trans to Receipt Rate.

[0079] In another embodiment supporting cross-currency applications, such field types can be considered. In one embodiment, flexfields and all other fields not mentioned herein are not be included in the lockbox record; they are not required to match the remittance or apply it to a transaction and are effectively ignored by the matching program.
A format specification file that can be written by the matching routine has a format that can be illustrated by the exemplary lines below in Table 2.

[0080]

TABLE 2
Exemplary Code Format
	<transRecord recordtype=“[Transmission Format Record
	Type 1]
	identifier=“[transmission record
	identifier 1]”>
	<field type=“[field 1 type]”
	start=“[start position 1]”
	end=“[end position 1]”
	justification=“[justification 1]”
	pad=“[pad character 1]”>
	<field type=“[field 1 type]”
	start=“[start position 2]”
	end=“[end position 2]
	justification=“[justification 2]”
	pad=“[pad character 2]”>
	...
	<field type=“[last field type]”
	start=“[last start position]”
	end=“[last high char position]”
	justification=“[last justification]”
	pad=“[last pad character]”>
	</transRecord>
	<transRecord recordtype=“[Transmission Format Record
	Type 2]
	identifier=“[transmission record
	identifier 2]”>
	...
	</transRecord>
	...
	<transRecord recordtype=“[last Transmission Format
	Record Type]
	identifier=“[last transmission record
	identifier]”>
	...
	</transRecord>

Each transRecord entry corresponds to a Transmission Record entry of the Transmission Format specified by the user. Each of the field entries corresponds to the Transmission Field entries that belong to the Transmission Record. The type attributes of the field records correspond to the value of the Field Type of the specified Transmission Field. The start and end attributes of the field records correspond to the matching start and end positions, respectively, for the given Transmission Field. An Extensible Markup Language (XML) schema definition for the file format is illustrated by the exemplary lines below of Table 3.

[0081]

TABLE 3
Exemplary XML Schema Definition for File Format
	<xsd:element name=“transRecord”
	type=“transRecordType”/>
	<xsd:complexType name=“transRecordType”>
	<xsd:sequence>
	<xsd:element name=“field” type=“fieldTYpe”
	minOccurs=“1” maxOccurs=“unbounded”>
	</xsd:sequence>
	<xsd:attribute name=“recordtype”
	type=“xsd:NMTOKEN”/>
	<xsd:attribute name=“identifier”
	type=“xsd:NMTOKEN”/>
	</xsd:complexType>
	<xsd:complexType name=“fieldType”>
	<xsd:attribute name=“type” type=“xsd:NMTOKEN”/>
	<xsd:attribute name=“start” type=“xsd:decimal”/>
	<xsd:attribute name=“end” type=“xsd:decimal”/>
	<xsd:attribute name=“justification”
	type=“xsd:NMTOKEN”/>
	<xsd:attribute name=“pad” type=“xsd:NMTOKEN”/>
	</xsd:complexType>.

[0082] The lockbox reading routine takes the format specification file and use it to read the lockbox file specified by the user. The routine reads the lockbox file line-by-line. Each transmission line in the lockbox file ends with a carriage return and/or linefeed, and begins with a recognized transmission record identifier for the transmission format specified by the user.

[0083] The program validates that none of the fields within a transRecord rule have a start and end position that does not overlap with another field's. The transmission record identifier at the beginning of a lockbox line specifies the transRecord rule to be used for reading the line. As discussed above, the transmission record identifier is at the beginning of the line. Although the program should expect the transmission record identifier at the beginning of a lockbox line, the transmission format file specifies, in one embodiment explicitly, the start and end position of the transmission record identifier, as it may be 1 or 2 characters in length.

[0084] In one embodiment, the matching program looks at the start and end positions for each field specified and loads the corresponding lockbox record field. Before loading a data entry in the lockbox file into the lockbox record, the string must first be stripped of padding characters. The justification and pad attributes of the transmission format specification that corresponds to the field determines how the pad characters should be truncated are described in Table 4, below.

[0085]

TABLE 4
Pad	Justification
Attribute	Attribute
Value	Value	Truncation Action
Zero	Left	Remove all zeros (0) after last non-
		zero character in the string.
	Right	Remove all zeros (0) before the first
		non-zero character in the string.
Blank	Left	Remove all whitespace after the last
		non-whitespace character in the string,
		excluding carriage returns & linefeeds.
	Right	Remove all whitespace after the first
		non-whitespace character in the string,
		excluding carriage returns & linefeeds.

[0086] Multiple entry fields such as Invoice 1 through 8, Invoice Installment 1 through 8, and Amount Applied 1 through 8 each correspond to a different lockbox record entry from the point of view of the matching program and are loaded as independent records.

[0087] Each of the payment entries in the file will not necessarily have all of the fields required to completely fill in a lockbox record. For example, lockbox files can typically contain several overflow payment lines after a payment line, but the customer information for the payment will only appear on the payment line. In order to complete the lockbox record entry, the following records are searched, to fill in missing field values:

[0088] the associated Transaction entry before the next Transaction;

[0089] the associated Overflow Payment line;

[0090] the associated Payment line;

[0091] the associated Batch Header line;

[0092] the associated Lockbox Header line;

[0093] the associated Service Header line;

[0094] the associated Transmission Header line.

In one embodiment, these records are searched in the order specified above.

[0095] If none of these lines contain currency information, then the default functional currency is used. If any date value is missing, the current system date is substituted. If any other value is missing, then the process continues with no value in the corresponding field in the record. For example, one transRecord format specification is illustrated by the exemplary lines below in Table 5.

[0096]

TABLE 5
Exemplary transRecord Format Specification
	<transRecord recordtype=“Payment”
	identifier=“5”>
	<field type=“Record Identifier”
	start=“1”
	end=“1”
	justification=“Left”
	pad=“Zero”>
	<field type=“Customer Number”
	start=“2”
	end=“10”
	justification=“Left”
	pad=“Blank”>
	<field type=“Payment Number”
	start=“11”
	end=“20”
	justification=“Right”
	pad=“Zero”>
	<field type=“Receipt Date”
	start=“21”
	end=“28”
	justification=“Left”
	format=“MMDDYYYY”
	pad=“Blank”>
	<field type=“Currency”
	start=“29”
	end=“31”
	justification=“Left”
	pad=“Blank”>
	</transRecord>
	<transRecord recordtype=“Overflow Payment”
	identifier=“9”>
	<field type=“Record Identifier”
	start=“1”
	end=“1”
	justification=“Left”
	pad=“Zero”>
	<field type=“Invoice 1”
	start=“2”
	end=“10”
	justification=“Left”
	pad=“Blank”>
	<field type=“Amount Applied 1”
	start=“11”
	end=“20”
	justification=“Right”
	pad=“Zero”>
	<field type=“Invoice 2”
	start=“21”
	end=“29”
	justification=“Left”
	pad=“Blank”>
	<field type=“Amount Applied 2”
	start=“30”
	end=“49”
	justification=“Right”
	pad=“Zero”>
	</transRecord>

[0097] A lockbox file (e.g., lockbox file 109; FIG. 1) comprises lockbox lines. With reference to FIG. 3, the interpretation a matching program makes of exemplary valid lockbox lines 300 is illustrated, according to one embodiment. As depicted in interpretation field 303, lockbox line 1, beneath column guide 301, comprises a record identifier ‘5’, a customer number ‘1001’, a payment number ‘0000123456’, and a receipt date ‘02072002’, and denotes ‘USD’ (United States Dollars) as the currency.

[0098] As depicted in interpretation field 304, lockbox line 2, above column guide 302, comprises a record identifier ‘9’, a first invoice identity ‘INV123’ and a corresponding first amount applied ‘0000123.45’, and a second invoice identity ‘INV125’ and corresponding second amount applied ‘0003453.98’. Upon interpreting the lockbox lines 300, the matching program weighs the corresponding parameters reflected therein according to the matching rules and transaction information (e.g., matching rules 102, staged transaction information 107; FIG. 1) and scores them as possible matches of varying probability. In one embodiment, a matching process (e.g., process 500; FIG. 5) performed by the matching program can follow a scoring structure.

[0099] Exemplary Scoring Structure

[0100] FIG. 4 depicts an exemplary scoring structure 400, which is used to calculate a weighted matching score according to one embodiment of the present invention. The weighted matching score comprises the probability of a possible match being accurate and precise in order to seek the best possible (e.g., the most probable accurate and precise) match between a remittance and transactions in a database is computed.

[0101] In FIG. 4, a score value is denoted by ‘S’ and a weight is denoted by ‘W’. Scores S correspond to probabilities of matching between a remittance and a transaction based on particular parameters, such as invoice identifying numbers, other invoice information, and corresponding customer information. In scoring structure 400, each score S comprises a percentage calculated out of a maximum possible 100% for each particular parameter being scored.

[0102] FIG. 4 summarizes the components that comprise the total score S_total 401. At the highest level, the matching score for a transaction is a weighted average of a score based on transaction attributes and a score based on customer attributes.

[0103] Weights W correspond to values for the significance of certain factors taken into account in scoring. These values are determined by a user and entered by a GUI providing matching rule setup screens to generate a matching rule (e.g., GUI matching rule setup screens 101, matching rules 102; FIG. 1).

[0104] The significance a user assigns to determine a corresponding weight in generating a matching rule can be based on subjective and/or objective business considerations including but not limited to historical data and information specific to particular customers and groups of customers. The weights that are used to compute each score at each node of the tree are constrained in one embodiment to add up to 100% and reflect business rules prescribed by the user. At each node of scoring structure 400, weights W sum to 100%:
W_customer+W_trx=100%
W_customername+W_customerID+W_bank=100%
W_trx#+W_amount=100%
W_customerstr+W_customeracr=100%
The weights W for each parameter are multiplied by the corresponding score S for that particular parameter to generate a weighted score ‘W×S’ for that parameter.

[0105] In scoring structure 400, a total score 401 comprises a weighted customer score 410 combined with a weighted transaction score 420. Weighted customer score 410 comprises a combining of a weighted customer name score 411, a weighted customer identity score 412, and a weighted bank score 413. Weighted customer name score 411 comprises a combining of a weighted customer-associated acronym score 416 with a weighted customer string score 415. Weighted transaction score 420 comprises a combining of a weighted transaction number score 421 and a weighted transaction amount score 422.

[0106] Exemplary Process for Computing Weighted Scores

[0107] FIG. 5 is a flowchart of an exemplary process 500 wherein weighted scores are computed, according to one embodiment of the present invention. The steps described herein can be performed as discussed below in somewhat greater detail. Further, the steps and sequence thereof comprising process 300 as described herein are for the purpose of illustrating and describing one exemplary method by which weighted scores can be calculated by which a remittance can be matched to a transaction.

[0108] These steps and their sequence are not to be construed as limiting. Other embodiments of the present invention are well suited to computing scores to match remittances to transactions using other steps and/or sequencing of steps. For example, in another embodiment, the computation of a weighted transaction score (e.g., step 512 herein) can be performed prior to computation of a weighted customer score (e.g., step 508 herein).

[0109] Process 500 begins with step 501 wherein a weighted customer string score is computed (e.g., calculated). In step 502, a weighted customer acronym score is computed. In step 503, a customer name score is computed. In step 504, a weighted customer name score is computed.

[0110] In step 505, a weighted bank score is computed. In step 506, a weighted customer identity score is computed. In step 507, a customer score is computed. In step 508, a weighted customer score is computed.

[0111] In step 509, a weighted transaction number score is computed. In step 510, a weighted transaction amount score is computed. In step 511, a transaction number score is computed. In step 512, a weighted transaction number score is computed. In step 513, score components treated as strings are scored using, in one embodiment, a Levenshtein and Longest common substring fuzzy scoring heuristic. In step 514, a total score is computed.

[0112] In step 515, it is determined whether a score (e.g., a total score) falls below a match threshold, which can be set by a user. If a score falls below a match threshold, then in step 516, an attempt is made to match the remittance against multiple invoices. In one embodiment, matching the remittance against multiple transaction invoices is performed using a heuristic wherein the sum of the invoices is matched as closely as possible to the amount of the remittance. Upon handling the exceptions (or if no exception is encountered), process 500 is complete.

[0113] Exemplary Score Structure Fields Illustrate Computation of Parameters

[0114] Considering the exemplary scoring structure 400 introduced above (FIG. 4), the steps comprising a process for computing scores (e.g., process 500; FIG. 5) can be explained further.

[0115] Exemplary Customer Score Computation

[0116] Referring to FIG. 6, field 600 illustrates that the customer score, S_customer, is computed as a weighted average over 100% from the following components: the Customer Name Score and Weight (S_customername and W_customername herein, respectively); the Customer Identifying Number Score and Weight (S_{customer #} and W_customer# herein, respectively); and the Customer Bank Account Score and Weight (S_bank and W_bank herein, respectively). As discussed above, the score is a weighted average over 100%; thus the weights sum up to 100%.

[0117] The customer name score, S_customername is in turn computed as a weighted average over 100% from the following components: the Customer Name's String Score and Weight (S_customerstr and W_customerstr herein, respectively); and the Customer Name's Acronym Score and Weight (S_customeracr and W_customeracr in this document, respectively). As the score is a weighted average over 100%, the weights add up to 100%.

[0118] Exemplary Transaction Score Computation

[0119] Referring to FIG. 7, field 700 illustrates that the transaction score, S_trx, is computed as a weighted average over 100% from the following components: the Transaction Identifying Number Score and Weight (S_trx# and W_trx# herein, respectively); and the Transaction Amount Score and Weight (S_amount and W_amount herein, respectively). As the score is a weighted average over 100%, the weights sum up to 100%. The Transaction Identifying Number Score is computed based on relevance factors provided by the user. The matching program allows users to place a different weight on closed transactions versus open transactions and other such factors.

[0120] Exemplary Customer Identifying Number Score Computation

[0121] Depending on the practice of the deploying company's (e.g., a business entity that deploys an embodiment of the present invention for use in matching remittances to transactions) business, the Customer Identifying Number can correspond to either the customer account number or the customer number. In one embodiment, the process scores on the customer number. In another embodiment, the process scores on the customer account number. Yet another embodiment scores using both numbers.

[0122] Referring to FIG. 8, field 800 illustrates that, in order to determine the Customer Identifying Number score (S_customer#), the matching program evaluates the match score between the customer identifying number provided by the customer on their remittance and the customer account number and the customer number. Both of these scores are multiplied by a user-set corresponding relevance factor. A higher relevance factor for the customer account number or customer number can indicate that the given identifying number is more likely to be used when the customer is identifying themselves. The Customer Identifying Number score (S_customer#) used in one embodiment to further score the transaction comprises the higher of these two scores. In another embodiment, S_customerID comprises a weighted average of both of these scores.

[0123] Exemplary Customer Name Score Computation

[0124] Referring to FIG. 9, field 900 illustrates that the customer name score S_customername is comprised of the following two components: the weighted score of the string match between the name of the customer associated with the transaction and the customer on the remittance (S_customerstr); and the weighted score of the string match between the acronyms of the customer associated with the transaction and the customer on the remittance (S_customeracr). The Customer Name score, S_customename, is computed as a weighted average over 100% from these two components. As the score is a weighted average over 100%, the weights provided add up to 100%.

[0125] Exemplary Bank Score Computation

[0126] Referring to FIG. 10, field 1000 illustrates a bank score computation. In order to determine the Bank score (S_bank), the matching program uses both the Transit Routing Number and the Account Number provided in the lockbox file. The matching program evaluates the match score between the concatenation of the Transit Routing Number and the Account Number provided by the customer on their remittance and the concatenation of the Customer Bank Number and Customer Bank Account database fields.

[0127] Exemplary Transaction Identifying Number Score Computation

[0128] Referring to FIG. 11, field 1100 illustrates a transaction identifying number score computation. Customers typically identify the transaction that they want to pay with their remittance with an identifying number for the transaction. Depending on the practice of the deploying company's business, this number could correspond to one of several numbers that can be used to identify the transaction, such as a transaction number or a bill of lading number.

[0129] In order to determine the Transaction Identifying Number score (S_trx#), the Matching Routine evaluates the match score between the identifying number for the targeted transaction provided by the customer on their remittance and each of the following numbers on the transaction:

[0130] Transaction Number;

[0131] Purchase Order Number;

[0132] Transaction Reference;

[0133] Bill of Lading Number;

[0134] Sales Order Number; and

[0135] Transaction Header External System reference number. These are reference numbers provided by an application such as a non-receivables application in a transaction flexfield (or similarly functioning field or other feature therein) to help identify a transaction. In one embodiment, the following external system reference numbers are supported:

[0136] Projects application project number;

[0137] Projects application draft invoice number;

[0138] Projects application agreement number;

[0139] Transaction line external system reference number. These are reference numbers provided by a non-receivables application in its transaction line flexfield to help identify a transaction.

[0140] One embodiment supports external system reference numbers such as a Contracts application contract number, a Service application service order number, and a Projects application project number. In addition, to handle installments, in one embodiment the matching routine can also score the following remittance against other transaction information. For instance, where the Installment Number is provided separately in the remittance, the concatenation of the identifying number on the remittance followed by a dash (“-”) and by the installment number on the remittance are compared against the transaction number followed by a dash and by the payment schedule terms sequence number. Where the installment number is not so provided, the identifying number on the remittance is compared against the transaction number followed by a dash and by the payment schedule terms sequence number.

[0141] The score obtained from matching the remittance identifying number against each of these transaction numbers is multiplied by the corresponding relevance factor that the user has set up. A higher relevance factor indicates that a given identifying number has more significance when trying to match a remittance to a transaction. In one embodiment, the Transaction Identifying Number score (S_trx#) that is used to further score the transaction will be the highest relevance-weighted score among all of the transaction number scores.

[0142] Exemplary Transaction Amount Score Computation

[0143] Referring to FIG. 12, field 1200 illustrates a transaction amount score computation. In one embodiment, the amount score for a transaction (S_amount) is derived by dividing the smaller of the amount on the transaction being considered and the amount of the remittance being matched by the larger of the two amounts:

[0144] $\begin{array}{cc}{S}_{\mathrm{undiscounted}}=\frac{\min \left({\mathrm{Amt}}_{\mathrm{transaction}},{\mathrm{Amt}}_{\mathrm{remittance}}\right)}{\max \left({\mathrm{Amt}}_{\mathrm{transaction}},{\mathrm{Amt}}_{\mathrm{remittance}}\right)}& \mathrm{Formula}1\end{array}$
In one embodiment, this computation is modified such that discounts are taken into consideration when scoring the amount match. In field 1200, whether the discount conditions have been met is not considered in scoring such matches. In the present embodiment, the matching routine match remittances to invoices in instances where customers incorrectly believe that they have met the discount conditions and they attempt to pay the discounted amount.

[0145] If there is a discount for the payment terms associated with the particular payment schedule matched against the remittance, the matching routine derives a discounted amount score by dividing the smaller of the discounted amount on the transaction and the amount of the remittance being matched by the larger of the two amounts:

[0146] $\begin{array}{cc}{S}_{\mathrm{discounted}}=\frac{\begin{array}{c}\min ({\mathrm{Amt}}_{\mathrm{transaction}}\times \\ \left(1-\mathrm{discount}\%\right),{\mathrm{Amt}}_{\mathrm{remittance}})\end{array}}{\max \left({\mathrm{Amt}}_{\mathrm{transaction}}\times \left(1-\mathrm{discount}\%\right),{\mathrm{Amt}}_{\mathrm{remittance}}\right)}& \mathrm{Formula}2\end{array}$
The amount score is then be returned as the maximum of the undiscounted and discounted scores.

[0147] The scores for the following score components are treated as strings:

[0148] Customer Name (S_customerstr), which are scored using Levenshtein and Longest common substring fuzzy-scoring heuristics:

[0149] Customer Bank and Bank Account (S_bank, also the same as the MICR number);

[0150] Transaction Number;

[0151] Customer Number;

[0152] Customer Account Number;

[0153] Purchase Order Number;

[0154] Transaction Reference;

[0155] Bill of Lading Number;

[0156] Sales Order Number;

[0157] Transaction Header External System reference number;

[0158] Transaction Line External System reference number.

[0159] The Levenshtein and Longest common substring fuzzy-scoring heuristics comprise two different methods of evaluating the similarity between two strings. The Levenshtein process produces a matrix of the hamming distances between two strings. One embodiment reuses this matrix to efficiently compute the Largest Common Substring score in a reduced computation time for the Largest Common Substring score. This combines the Levenshtein and Largest Common Substring heuristics to get a more efficient implementation than what is possible if both heuristics are run independently.

[0160] The total score, S_total, is computed as a weighted average over 100% from the following components:

[0161] The Customer Score and Weight (S_customer and W_customer herein, respectively); and

[0162] The Transaction Score and Weight (S_invoice and W_invoice herein, respectively).

As the score is a weighted average over 100%, the weights sum up to 100%. The formula for computing the total score given all of the aforementioned score is given by Formula 3 below.

[0163]
In one embodiment, the matching program can also match against open deposits transactions and against closed transactions that were credit memo'ed over a given period of time. In one embodiment, the matching routine allows users to place a different weight on closed transactions versus open transactions. In doing so, the matching program accepts a closed transaction penalty to allow users to adjust the scores of transactions if they have been closed. This factor is between 0 and 100% and penalizes the total score of the invoice (S_total) with a penalty P by multiplying the score by (1−P). In one embodiment, one payment is matched to a transaction. Another embodiment matches multiple payments to a transaction.

[0164] In summary, an embodiment of the present invention provides a method and system for matching remittances to transactions. The method for matching remittances to transactions disclosed herein uses a processing paradigm that is not complicated to maintain and fosters the use of logic based on the summarization of payments. The method disclosed herein also matches remittances to particular transactions with relaxed sensitivity to where identifying markers may be placed on a remittance and is resistant to typographical data entry errors. Further, the method disclosed herein is flexible with regards to handling various kinds of information that can result in accurate, precise matching without discarding or overlooking such information.

[0165] In one embodiment, a computer implemented method matches a remittance to a transaction by receiving remittance lines, transaction information, and matching rules wherein the matching rules assign a weight to a parameter considered in the matching, computing a weighted matching score corresponding to the parameter based upon that weight wherein the matching score corresponds to a probability of an accurate and precise match between the remittance and the transaction, and generating a match recommendation based on that weighted matching score.

[0166] One embodiment of the present invention provides significant reduction in miss rate (e.g., failing to accurately and precisely match a remittance to a correct, corresponding transaction). Advantageously, use of the present embodiment by a business entity can provide a business entity user with a significant savings in what must conventionally be expended on research costs associated with unapplied receipts (e.g., research conducted by trained personnel to correlate unmatched/mismatched receipts to their correct corresponding transactions). Further financial advantages can accrue to the concomitant ability to more quickly apply remittances received, once they are matched to their respective transactions. Thus, an embodiment of the present invention promotes commercial efficiency. The present embodiment provides a novel process and combination of tools which promote matching remittances to transactions in a useful, intuitive way.

[0167] An embodiment of the present invention, a method for matching remittances based on weighted scoring and fuzzy logic, is thus described. While the present invention has been described in particular embodiments, the present invention should not be construed as limited by such embodiments, but rather construed according to the following claims and their equivalents.