CN1926568A - 用于自动化支付和调整处理的系统和方法 - Google Patents

Abstract

本发明提供了一种使用预先配置的多组商务规则来进行自动化的调整处理的系统和方法。卖方预先配置用于处理特定买方的调整的一组商务规则。所述组商务规则可以对于每个买方可变的和/或是全局的组。当从卖方接收到支付并且需要调整时，调整管理应用从卖方检索买方的一组商务规则。所述组的商务规则然后被应用以试图将所接收的支付匹配到买方的未付发票之一。如果所述匹配成功，则处理买方的支付。

Description

用于自动化支付和调整处理的系统和方法

技术领域

本申请一般地涉及用于管理针对发送到卖家的支付而由买家进行的诸如调整或扣除之类的例外情况的系统和方法。更具体而言，本申请提供了一种自动化系统和方法，用于处理针对发送到卖家的支付而由买家进行的诸如扣除或对于买家的记入贷方(credit to a buyer)之类的调整，在卖方侧处理所述交易，完结(close out)所述交易，并且更新卖家的记账系统。

背景技术

图1图解了根据现有技术的用于购买物品的典型交易100。如图1中所示，所述交易涉及买方110、卖方130和金融机构120。通常，买方110向卖方130发送购买请求102或购买订单。购买请求102标识买方110期望的物品。卖方130接收买方的购买请求，并且然后将物品运送到买方110。

卖方130可以与物品一起或与物品分开发送清单(statement)或发票105。发票105通常列出运送的物品，并且可以包括诸如价格、数量、诸如SKU编号的卖家代码或标识信息和/或其他订购信息之类的其他信息。或者，取代用于单次送货的单个发票，可以在其中向同一买方进行多次送货的情况下使用反映多次送货的清单。

一旦买方110已经接收到卖方的物品和发票105，则买方110必须在那时或其后的某时为所述物品付款。当前，在许多情况下，买方使用下述多种方法中的任何一种来为所述物品付款，所述方法包括现金、支票、信用卡、自动(票据)交换所(ACH)或其他的电子转账/电汇。与支付方法无关，买方的支付金额和/或信息被传送到金融机构120来作为汇款信息115。在某些情况下，所述支付金额和/或信息被首先发送到卖方130，卖方130然后将其传送到金融机构120。

金融机构120接收买方的支付金额和汇款信息115，并且将所述款项存在金融机构120的卖方帐户中。金融机构120然后通过向卖方130发送支付数据125来提醒卖方130已经接收到支付金额。

支付数据125可以采取每月、每周或典型的每日账户累计(accountsummary)的形式。在最为优选的配置中，一天几次地更新所述账户累计。所述支付数据也可以以电子方式发送到卖方130，或者可以通过允许卖方电子访问金融机构的记录而提供到卖方130，或者可以向卖方130邮寄复制品。

另外，如上所述，可以以多种方法中的任何一种来接收买方的支付。但是，与所接收的支付的类型无关，通常由金融机构将所述支付转换为电子表达形式。例如，由金融机构接收的纸张支票可以被扫描或成像，并且可以通过在金融机构120的数据录入人员将在支票表面上的支付数据转换为电子表达形式。ACH或电汇已经是电子形式，但是金融机构的交易记录也可以反映例如ACH的始发者或ACH的日期。通常，向卖方130发送银行的电子数据的大部分来作为支付数据125。

一旦卖方130已经接收到支付数据125，则卖方130必须随后开始将每一所接收的支付与对应的发票匹配的费力任务。即，为了确认买方110已经对所运送的物品进行了支付，卖方130将从金融机构120接收的支付数据125与发送到买方110的发票数据105匹配。一旦卖方130已经将发票数据105与支付数据125匹配，如果所述发票数据与所述支付数据精确地匹配，则称交易完结。对于具有大量发票的卖方，这个处理可能是非常耗时的。

另外，直到通过完结交易而所述支付数据125已经成功地与发票数据105匹配，卖方130不知道是否已经从买方110接收到正确的支付金额。买方110可能例如多支付或少支付。因此，直到已经完结了交易，卖方130不能肯定在金融机构120的卖方的账户中反映的当前余额是否表示可用的现金或是否例如因为多付而某一金额应当被支付回买方110。

如所能想象得到的，将支付数据与发票信息相匹配可能是十分耗时的，特别是当卖方130正在向许多买方110运送物品时。另外，将支付数据与发票信息相匹配可能由于在向买方110发送发票数据105的时间和卖方接收到支付数据125的时间之间的时间滞后(time lag)而进一步被复杂化。另外，将支付数据与发票信息相匹配可能因为所接收的支付数据125可能不匹配发票数据105而被进一步复杂化。

即，买方可能提交与所开发票的金额不同的支付金额。由买方提交的所述支付金额可能少于或多于所开发票的金额。例如，当买方的支付金额不是对于所有物品时(诸如当一些物品未被收到或被损坏时)，由买方提交的支付金额可能少于所开发票的金额。另外，买方的支付金额可能由于关于由买方接收的物品的价格或数量、或折扣的不一致而少于所开发票的金额。相反，由买方提交的支付金额可能由于买方的错误而多于所开发票的金额，所述错误诸如印刷错误或记账差异或当买方预付或多付时。

当从买方接收的支付金额不匹配卖方的发票时，通常进行对于发票的调整。当所述调整导致所开发票的金额的减少时，所述调整被称为扣除(也称为回收费(chargeback)或争议(dispute))。通常，客户要求调整，这个调整要求通常被称为调整请求。虽然扣除不是必然需要参考特定卖方的发票，但是调整请求通常是以扣除发票金额的形式。例如，当客户接收到受损的物品时，他或她要求减少发票金额以反映所述物品已经被损坏，因此以扣除发票金额的形式来提出调整请求。另外，如果卖方的发票从开始就有错误，则买方的支付金额可能不匹配卖方的发票。或者，可能例如对于买方的发票进行诸如买方特有的折扣之类的调整。

调整请求可以以几种形式。例如，所述调整请求可以是从买方到卖方的请求调整的电话。而且，调整请求可以从客户到卖方的信件或电子邮件。另外，调整请求可以是要求退还多付或扣除在发票上所写的发票金额情况下的发票。或者，调整请求也可以是诸如来自网站的电子数据之类的电子通信的任何形式。

一旦卖方已经接收到调整请求，则所述调整请求通常被传送到人以便查看。查看者是查看调整请求和相关文件以便批准或拒绝所述调整请求的个人。可能需要多个查看者的同意来允许特定的客户可以进行调整。一旦所有的查看者已经查看了所述调整请求和所有的相关文件，则所述调整请求或者被批准或者被拒绝。

如果卖方批准了所述调整请求，则卖方向客户发放款项(issue a credit tothe customer)。对于买方重新开发票通常与向客户发放款项具有对于卖方的账户系统类似的效果。相反，如果客户请求以扣除发票金额的形式的调整、并且卖方批准了所述调整请求，则卖方减少发票金额并且从买方接受较低的支付金额。

图2图解了用于处理用以销售物品的交易的典型工作流200。首先，在步骤210，卖方侧201向买方侧202发送发票。接着，在步骤S220，买方初始地查看发票。例如通过进行调整而在步骤230处理任何争议。而且，在步骤230，由买方查看和批准任何争议或调整。如在下面进一步讨论和在图2中所示，对于卖方而言，争议和调整处理可能很耗时和费力的。最后，在步骤240，从买方向卖方发送支付金额。

注意在步骤240中，在卖方，从买方接收的支付金额经常被手工地匹配到发票，这是相当耗时的。即使电子地提供了某些数据，买方的支付系统通常不被配备来在没有实质的人交互的情况下处理所接收的数据。另外，在步骤230，识别调整或争议处理对于买方和卖方两方都是费力和耗时的。

因此，用于解决调整的当前系统由于多种原因而过于昂贵。首先，对于监控器有大量的信息。所述信息包括客户信息、发票信息、调整请求的目的(即是寻求扣除还是退还)、客户的过去的发票、来自客户的过去的调整和卖方对于客户的赊账最高额(credit line)，并且可以包括其他信息。

其次，在大型商业中，经常不能保证卖方的所有相关部门(例如特别是财务部门、运输部门和信贷部门)能够查看、编辑和批准或拒绝调整请求。所述不能保证卖方的所有相关部门查看所述调整请求源于人工匹配调整请求与相关的文档，如上所述。无疑，经常发生错误，例如在查看者没有接收到他要求正确地查看所述调整请求所需要的所有文档的情况中。

第三，在相关联的问题中，可能很难保证卖方的所有相关联部门及时地进行他们的查看，特别是当涉及几个部门时。例如，在保证第一查看者接收到他查看所述调整请求所需要的所有文档上的延迟引起后续查看者的进一步的延迟。以这种方式，当其他的查看者等待第一查看者完成他的对于调整文件和相关文档的查看时，在调整请求的处理中的延迟随之发生。当卖方要求多级的查看(即一个查看者必须等待和查看第一查看者对于调整请求的决定)时，这个延迟变得更为麻烦。例如，当卖方要求查看者的经理查看调整请求的所有初始查看时，在将所述信息路由到一个或多个查看者或从一个或多个接收者接收决定上的延迟将仅仅会引起另外的延迟。

最后，在保证所有相关部门查看调整请求上的任何延迟将引起在寻求收回客户的欠款或在发出客户的退款中的额外的延迟。这会导致由于长时间的累积延迟而引起商业方面的损失和在客户处丢失信誉。另外，当前的系统和方法不提供在调整管理系统和卖方的银行之间的一体化。这继而引起在调整请求的最后决定上的额外的延迟。这种延迟将是因为卖方必须通知客户，客户然后需要向卖方发送支付金额而产生的。以类似的方式，也将延迟对于客户所拥有的款项进行的任何过帐。

因此，已经长期感到需要一种消除或最小化与当前系统相关联的许多问题的销售调整管理解决方案。特别感到需要能够处理大量的调整请求以便减少由卖方的不必要的勾销(write-off)的系统。而且，已经长期感到需要一种用于减少处理所述调整的工作量和时间投入的系统。另外，已经长期感到需要一种灵活的系统，它可以用于处理多种调整请求。最后，已经长期感到需要一种直接地与卖方的金融机构一体化的调整系统。

发明内容

本发明的实施例提供了一种系统和方法，用于通过使用由卖方为买方选择的一组预先配置的商务规则来自动化对于从买方接收的支付的调整的处理。即，卖方为特定买方预先配置在处理调整中使用的一组商务规则。每一买方可以具有其本身独立配置的一组商务规则。当在卖方从买方接收到不精确地匹配买方的任何未付的发票的支付时，在卖方的调整管理应用应用所述用于买方的那组商务规则。所述调整管理应用然后试图使用所述买方的那组商务规则来将所接收的支付与买方的未付发票之一匹配。如果所述调整管理应用成功地找到了匹配，则自动地记入买方的支付。如果所述调整管理应用未成功地找到匹配，则选择买方的支付来用于进一步的处理，例如，可以将所述支付路由到人查看者。

附图说明

图1图解了按照现有技术的用于购买物品的典型交易。

图2图解了用于处理销售物品的交易的典型工作流。

图3图解了按照本发明的一个实施例的自动化调整管理系统。

图4更详细地图解了图3的调整管理应用的一个实施例。

图5图解了可以在支付数据中包括的一些类型的信息源的示例。

图6图解了按照本发明的一个实施例的商务数据过滤器的操作的流程图。

具体实施方式

图3图解了按照本发明的一个实施例的自动化支付处理和例外管理系统300。所述支付处理和例外管理系统300包括买方310、金融机构320、卖方330、调整处理应用340以及支付和调整管理应用350。所述支付和调整管理应用350包括金融机构320和调整处理应用340。

如下进一步所述，购买请求302从买方310传送到卖方330。发票信息305从卖方330传送到买方310。发票信息305可以与由卖方330提供的物品和/或服务分开传送，或者可以与物品和/或服务一起传送。从买方310向卖方的金融机构320发送支付信息315。从金融机构320向调整处理应用340发送支付和汇款数据325。从卖方向调整处理应用340发送订单数据335。订单数据335可以在向买方针对下层的物品开发票时被发送到调整处理应用340，或者可以在以后某个时间被发送到调整处理应用340。从调整处理应用340向支付和调整管理应用350发送记入数据345。

在操作中，支付处理和例外管理系统300一般如下进行。首先，买方310可以确定例如从卖方330购买物品。通常，买方310然后通过向卖方330发送购买请求302而通知卖方330买方310希望进行购买。卖方330然后接收买方的购买请求302。卖方330然后将期望的物品运送到买方310，并且也向买方310发送发票信息305。

优选的是，发票信息305包括与从卖方330向买方310运送的物品相关联的信息。例如，优选的是，发票信息305包括卖方代码，用于标识所运送的物品、价格、数量和/或其他订单信息。

如上所述，发票信息305和物品由买方310接收。买方310然后查看所接收的物品。优选的是，买方310然后对所接收的物品进行支付。但是，买方的支付金额的数量可能由于多种原因而与由卖方330开发票的支付金额不同。

例如，如果所接收的物品与在发票信息305中标识的物品不匹配，则买方的支付金额可能与发票不同。另外，例如，一些物品可能被损坏或破坏。或者，所接收的实际物品的议定价格或数量可能与在发票信息中出现的物品的价格和数量不匹配。另外，卖方可能运送了除买方期望的物品之外的物品。这些仅仅是可能在向买方运送物品中遇到的无数困难的一些示例，它们可能导致与发票信息305不符。

返回图3，一旦买方310已经接收到物品，则买方通过向金融机构320发送支付信息315来为所述物品进行支付。即，买方310向卖方的金融机构320提交包括支付金额的支付信息315。但是，如图3中所示，本实施例操作来通过将金融机构320与调整处理应用340一体化而将金融机构320转换为支付和调整管理应用350。

即，一旦已经由买方310接收到物品或者按照伴随发票的条款，买方然后为物品进行支付。但是，如果已经发生了关于所述物品的上述困难的一个或多个，则买方可以作为支付金额而提交的金额可能与在发票信息305中包括的金额不同。当由买方310提交的支付金额不同于并且少于在发票信息305中包括的支付金额时，在支付金额中的不同被称为扣除。

如上在背景技术部分中所述，当买方310以典型的方式来进行扣除时，扣除的进行需要卖方的大量工作。通常，卖方必须协调从买方接收的支付金额与发送到买方的物品和发票信息，这可能是复杂和耗时的过程。

在一些先前的系统中，为了减少用于协调发票信息所花费的时间量，卖方可以请求买方提交借项凭单(debit memo)，以便使得买方可以手动地或通过网站来进行扣除。通过使用这种的形式来管理扣除可以有助于卖方的内部记账，但是可能在卖方的批准和向买方的付款或记入贷方中需要另外的延迟。因此，这样的系统经常被买方和卖方都看作是麻烦的。在其他的先前系统中，买方可以拒绝对发票进行支付，除非它是准确的，即，除非已经由买方接收到示出所有调整的最后的修订的发票，或者贷项凭单被发出来抵消错误发票，或在支付之前授权了扣除。但是，这样的系统通常被卖方看作是不适宜的，因为它通常涉及用于支付的另外延迟。

相反，如图3中所示，买方310向卖方的金融机构320提交包括支付金额的支付信息315。但是，如图3中所示，本实施例操作来通过将金融机构320与调整处理应用340一体化而将金融机构320转换为支付和调整管理应用350。

即，买方的支付和汇款信息315被发送到金融机构320。支付金额315可以是多种形式的任何一种，其范围例如从现金或支票到诸如电子数据交换(EDI)之类的电子资金转帐。金融机构320接收支付和汇款信息315和产生支付和汇款数据325。优选的是，支付和汇款数据325包括所有的支付和汇款信息，并且可以包括附加的汇款数据，诸如所接收的支票、所接收的汇款通知单和/或借项凭单的扫描图像。支付和汇款数据325然后被发送到调整处理应用340。

除了支付和汇款数据325之外，调整处理应用340也从卖方330接收订单数据335。优选的是，订单数据335包括三种信息：发票相关联的信息、买方相关联的信息和卖方相关联的信息，并且订单数据335可以包括另外的信息。

关于发票相关联的信息，优选的是，订单数据335包括在被发送到买方310的发票信息305中包括的所有信息，并且也可以包括与物品的传送相关联的信息，诸如提货单或发票信息305的电子图像。

即，优选的是，支付和汇款数据325的一个单元识别进行支付的买方。优选的是，例如在发票被原始地发送到买方时，未付的发票已经被预先发送或预先交付到调整处理应用340。如果调整处理应用340不能找到特定卖方的特定发票，则调整处理应用340可以默认标准的扣除形式，如下进一步所述。或者，调整处理应用340可以随后查询卖方330，并且检索用于所示的买方的所有未付发票的列表来作为订单数据335。如果在支付数据325中未指示买方，则优选的是，调整处理应用340可以检索所有买方的所有未付发票。即，支付和汇款数据325最好指示买方。调整处理应用340可以随后向卖方330查询与买方相关联的任何信息。另外，调整处理应用340可以以多种方式的任何一种来从卖方330检索数据。例如，订单数据335可以被调整处理应用340接收作为一批表示用于一个或多个买方的几个发票的信息，这与买方的单个发票的信息相对。另外，从买方310接收的支付信息315可以表示一批几个发票而不是单个发票。

关于买方相关联的信息，订单数据335也最好包括与买方本身相关联的信息，诸如买方的先前订单的编号、适用于买方的任何协商的折扣或其他动机，如下进一步所述。

关于卖方相关联的信息，订单数据335可以包括例如关于诸如始发订单的销售人员之类的卖方的信息或用于调整批准的内部路由信息，如下进一步所述。

一旦调整处理应用340接收到支付和汇款数据325以及订单数据335，则调整处理应用340进行来试图将所接收的支付和汇款数据325与从订单数据335检索的一个或多个未付的发票匹配。

如下参照图6进一步所述，如果支付和汇款数据325与一个或多个发票立即可匹配，则调整处理应用340向卖方330发送成功匹配的指示来作为记入数据(posting data)345。所述记入数据345最好指示通过支付数据正在对那个或那些发票进行支付。卖方330接收记入数据345，并且在卖方330的记账系统记录然后被更新以反映已经支付了发票以便完成交易。虽然本讨论着重于在逐个发票的基础上的调整处理应用340的操作，所述调整管理应用也可以在批的基础上操作。例如，可以一次处理一批发票。在所有的发票已经被匹配和/或对于发票的所有的例外已经被处理——如下进一步所述——后，所述一批发票可以一次成批地被发送到卖方。例如，调整管理应用340可以处理所述一批发票，将所述能够匹配的发票匹配，然后着重于在将整个一批发票传送到卖方之前分类在剩余的发票中的例外，如下进一步所述。在卖方的查看者可以随后进一步查看、修改和/或批准/拒绝所述例外。

如果支付和汇款数据325不是立即可匹配到一个或多个发票，则卖方可能在要求调整或已经发生了错误，并且调整处理应用340可以随后将支付数据标记来用于进一步的处理，如下参照图6进一步所述。

调整处理应用340可以随后试图向支付数据应用一组卖方可配置的商务规则，以便试图自动地决定和处理调整，如下进一步所述。例如，可以利用用于每个买方的一组规则来配置调整处理应用340，以便自动许可低于特定门限值或小于发票金额的特定百分比的调整。

如果调整处理应用340不能自动地决定调整，则在应用了商务规则后，可以向卖方参见支付和汇款数据以用于进一步的处理。

在XXXX提交的、题目为“用于自动化的输入支付和发票调解的系统和方法”的美国专利申请第XX/XXX,XXX号(通过引用而将其整体并入在此)中进一步描述了所述初始发票和支付匹配的操作。另外，在XXXX提交的题目为“用于自动化的调整处理的系统和方法”的美国专利申请第XX/XXX,XXX号(通过引用而将其整体并入在此)中进一步描述了自动化调整处理的操作。

一旦调整处理应用340已经处理了支付和汇款数据325以及订单数据335并且买方的调整已经被决定，则调整处理应用340向卖方330发送记入数据345。如下进一步所述，记入数据345可以采取几种形式的任何一种，诸如建立贷项凭单的指令、对于库存的调整或用于将扣除转发到集合的指令。

如上所述，发票信息305可以采取几种形式的任何一种。例如，发票信息305可以是纸张文件或电子文件，所述电子文件诸如电子邮件、万维网使能的形式或其他的EDI信息交换。

虽然针对订购物品的买方而如上所述了本实施例，但是买方可能相反地感兴趣于安全服务。在获得关于调整管理的服务的环境中也有类似的考虑。虽然当前的说明聚焦在物品上，但是本支付处理和例外管理系统也同样地良好适用于服务，而不限于物品。

如上所述，发票信息可能包括大量的信息，如下进一步所述。但是，不需要在发票信息中提供下面列出的信息的所有项目。卖方可以配置包括一个项目来作为发票信息的一部分。例如，发票信息可以包括关于由卖方330向买方310销售的物品和/或服务的数量和价格的信息。所述发票信息305也可以包括信息，诸如运输日期、买方310的名称和地址、卖方330的名称和地址、从买方310向卖方330的过期的任何数量的钱款、或买方310对于卖方330具有的任何可用的记入贷方。另外，发票信息305可以包括要由卖方330用于识别和跟踪目的的发票编号。例如，发票信息305可以包括发票编号，以便卖方330可以能够跟踪那些物品和/或服务已经被传送或提供到买方310。另外，发票信息305也可以包括提货单和/或其他文档，诸如运费清单、交货证明和/或报价。

类似于上面的发票信息，支付信息可以采取由买方选择的多种形式中的任何一种。例如，支付信息315可以因此包括支票、金融机构汇票、银行开出的支票、汇票、记入赊账最高额帐内的订单、本票或示出对于所接收的物品和/或服务的支付金额的任何其他文件。另外，支付信息315也可以包括支付表格的电子图像。例如，支付信息315可以包括用于支付物品和/或服务的支票的电子图像。

继续如上讨论，最好由金融机构320构造支付和汇款数据到支付数据和/或汇款信息不是已经以电子形式从买方可获得的程度。即，金融机构320可以查看诸如支票之类的输入支付信息，然后发展与所述支票相关联的一组数据。例如，金融机构320可以电子地标注接收日期、数量、支付方、被支付方和任何计帐、MICR(磁墨水字符识别)或在支票上的发票编号。金融机构也可以电子地成像所接收的支票。由金融机构320作出的注解可以被传送到调整管理应用来作为支付和汇款数据325的一部分。

或者，如果向金融机构320电子地提供支付信息，则所述支付信息可以采用多种形式的任何一种。金融机构320通常处理所接收的支付信息，并且按照金融机构的内部处理需要来重新表达或重新格式化所述支付信息。所述被重新处理的电子接收的支付信息可以随后被传送到调整处理应用340来作为支付和汇款数据的一部分。

支付和汇款数据本身可以采取由金融机构320选择的多种形式的任何一种。例如，支付和汇款数据325可以或者包括XML文件、EDI文件、来自基于因特网的金融服务的信息或与物品或服务的支付相关联的电子数据的任何其他形式。

订单数据335和记入数据345也可以采取多种形式的任何一种，诸如电子邮件、XML文件、HTML文件或EDI。

另外，调整处理应用340可以被例如实现为封装软件应用或者被安装在金融机构或作为应用服务提供者(ASP)的其他第三方上。作为ASP，调整处理应用340可以直接地驻留在金融机构320、卖方330或第三方中。调整处理应用340的实际物理位置无关，只要它保持与金融机构320和卖方330通信。例如，调整处理应用340可以被驻留在或安装在第三方，或者否则可以来自外部。

图4更详细地图解了图3的调整理应用340的一个实施例。如图4中所示，调整管理应用340包括商务数据过滤器410和调整文件建立器420。如上参照图3所述，调整管理应用340接收来自金融机构320的支付和汇款数据325以及来自卖方330的订单数据335。所述支付和汇款数据325以及订单数据335然后被传送到调整管理应用340的商务数据过滤器410。

在操作中，商务数据过滤器410接收订单数据335以及支付和汇款数据325，并且试图将支付和汇款数据325与在订单数据中包括的一个或多个发票匹配。如果商务数据过滤器410能够将支付和汇款数据325与在订单数据335中的一个或多个发票匹配，则所述商务数据过滤器向卖方330发送记入数据345以完结交易，如上所述。如果商务数据过滤器410不能将支付和汇款数据325与在订单数据335中的一个或多个发票匹配，则支付和汇款数据325被商务数据过滤器进一步处理，如下参照图6所述。

例如，如果所接收的订单数据匹配特定买方的未付发票编号并且所接收的支付金额的数量匹配发票的金额，则记入数据345被发送到卖方330以向卖方的记账系统记入所接收的支付金额。

但是，如果所接收的支付金额的数量不匹配发票的金额，则商务数据过滤器410应用一系列商务规则，以便试图匹配订单数据335以及支付和汇款数据325，如下参照图6所述。如果商务数据过滤器410在应用商务规则后能够找到匹配，则商务数据过滤器410向卖方330发送记入数据345。另外，商务数据过滤器410向调整文件建立器420发送支付和汇款数据325，以便可以建立调整文件。调整文件425然后也被发送到卖方330。但是，因为买方的调整已经满足了所述商务规则，因此卖方可能自动地接受买方的调整，而不需要进一步的人的交互或批准。

如果所述订单数据和支付数据在在商务数据过滤器410中应用所述商务规则后仍然不匹配，则仍然向调整文件建立器420发送支付和汇款数据325，并且产生调整文件。但是，所建立的调整文件可能不由卖方的记账系统自动处理，这是因为所述调整不满足所述商务规则。另外，由商务数据过滤器应用的商务规则最好被配置成买方专用的，如下进一步所述。

在XXXX提交的、题目为“卖方帮助的自动化支付处理和例外管理的系统和方法”的美国专利申请第XX/XXX,XXX号——通过引用而将其整体并入在此——中进一步描述了调整批准表格的结构和批准表格的路由。

调整文件425最好包括支付数据以及所有与买方相关联的数据。所述买方相关联的数据最好包括其中包括任何买方的信用评级的买方的先前购买和支付行为以及关于买方的卖方侧信息，诸如针对买方的卖方的账户或被提供到买方的任何先前的折扣。

商务数据过滤器410还可以在买方的信息从交易丢失时寻求验证支付数据。例如，如果所述支付数据不包括买方的标记，则商务数据过滤器410可以试图将所述支付数量或任何其他可用的信息与所有买方的未付发票匹配。如果发现匹配，则商务数据过滤器410可以自动地提示用户从辅助标准——诸如非发票识别字段——确认所尝试的匹配。

优选的是，由所述商务规则提供的交易验证包括验证交易的下述方面：买方310的客户信息的验证；被传送到买方的物品的交付信息的验证，最好包括例如发票和/或提货单和美元数量；买方的支付金额的验证，诸如确定是否买方的支付金额是已经接收的支付金额的重复、或者是否由买方汇款的数额与发票数额相差少于预定门限容差的一个和、或者是否总的发票数额小于预定数量。

图5图解了可以在支付数据325中包括的一些类型的信息源的示例。如上所述，支付数据325可以包括从XML文件510得到的数据、EDI文件520、电子数据540和/或来自万维网服务530的数据。所述电子数据540可以包括汇款信息315的电子图像，如在图3中所述。可以以由金融机构期望的任何内部格式来配置支付数据325，所述内部格式能够由调整管理应用340来进行语法分析。

因此，本实施例用于自动地将支付数据与发票数据匹配。如上所述，用于将支付数据与发票数据匹配的现有技术的方法涉及大量的人力并且很慢。对于本实施例，可以自动地匹配和处理大多数的输入支付，因此降低了人力和成本，并且提供了对于可用现金的更准确评估。

另外，本实施例最好直接地与卖方的金融机构一体化。因此，不需要任何额外的处理步骤来向金融机构或内部记账子部门通知在金融机构的卖方的账户。

图6更详细地图解了调整管理应用的操作的流程图600。首先，在步骤601-602接收支付数据和订单数据。接着，在步骤605，金融机构接收支付数据和将其成批化。即，金融机构可以以队列来累积多个支付以形成一批。然后，在卖方的人可以访问金融机构的记录以整体地处理所述批的支付。

在步骤610，评估在所述批的支付中的每个支付。优选的是，支付数据601包括发票信息，用于将由买方进行的支付链接到由卖方向买方发送的特定发票编号。最好从卖方检索所述发票编号的列表来作为订单数据602的一部分。在步骤615，确定是否所述支付包括与由订单数据提供的发票编号匹配的发票编号。如果发现了匹配的发票编号，则处理进行到步骤630，并且所述发票与所述支付匹配。如果没有找到发票编号匹配，则处理进行到步骤620。

在步骤620，可能需要另外的处理——诸如卖方的人的交互——来将所接收的支付数据与在订单数据中检索的一个或多个发票匹配。在XXXX提交的、题目为“用于卖方帮助的自动化支付处理和例外管理的系统和方法”的美国专利申请第XX/XXX,XXX号——通过引用而将其整体并入在此——中进一步描述了这样的进一步处理。

现在进行到步骤630，所接收的支付已经匹配到特定发票编号。接着，在步骤632，将在发票中包括的发票支付金额与所接收的支付相比较。如果所接收的支付匹配发票支付，则处理进行到步骤635。在步骤635，标记所述支付，以向卖方的记账系统记入。

相反，如果所接收的支付不匹配发票支付，则处理进行到步骤640。在步骤640，应用商务规则，以便使得所述支付与所述发票“匹配”，即使所述支付数量不正好是所述发票金额。例如，可以对于系统设置全局门限值，以便即使所接收的支付不同于发票的支付数量，如果所述差足够小，则仍然认为所述发票和支付匹配。例如，作为全局门限值，如果所接收的支付与发票数量相差小于1％或小于$100，则仍然将发票和支付当作匹配。最好由卖方来设置所述全局门限值。

除了可以被应用到所有买方的全局商务规则之外，可以应用买方专用的商务规则。例如，可以使用比所述全局门限值更为宽松的买方专有的门限值来取代或补充所述全局门限值，以便使得所接收的支付和发票匹配。例如，卖方可以配置2％或$500的买方专用的门限值，并且直到所接收的支付与发票金额的不同不大于所述买方专用的门限值，则将所述支付当作匹配所述发票。例外，可以应用诸如折扣之类的其他买方专用的标准或其他的激励。

可以在步骤602从卖方检索包括全局和买方专用的门限值的商务规则来作为订单数据的一部分。或者，当处理进行到步骤640时可以从卖方检索商务规则。作为另一种替代方式，所述商务规则可以被存储在调整管理应用中，或者可以由卖方获得来进行定期的更新。最好由卖方可以配置所有的商务规则。

现在转向步骤642，如果在应用商务规则后支付数量匹配发票金额，则处理进行到步骤650。在步骤650，建立诸如G/L(总账)勾销记录的调整文件以将在发票支付金额和所接收的支付金额之间的差记入贷方。处理然后进行到步骤635，并且将所述支付标记以记入。一旦将所述支付标记以记入，则在步骤690向卖方发送记入数据。

如果在应用商务规则后发票数量不匹配，则处理进行到步骤620，在此，可能需要进一步处理——诸如由卖方的人的交互——以将所接收的支付数据匹配在订单数据中检索的一个或多个发票。

所述买方专用的信息可以通过下述而对于买方始发：通过预先存在的默认值、通过由卖方直接编程或通过自动化地分析一组买方的行为。例如，商务数据过滤器可以被配置成根据最近的发票的大小或支付的大小而动态地提高门限百分比或其他门限值。此外，例如，可以根据在买方和卖方之间的关系的长度来动态地改变所述门限百分比或其他门限值。

因此，本系统可以当卖方要求诸如扣除之类的调整时从卖方提供对于支付的自动化处理。通过自动地处理落入预先配置的商务规则中的调整，可以由系统自动处理大量的调整，而不需要任何人的交互。相反，可能仅仅对于落在所述商务规则外部的少量调整需要人的交互。因此，因为现在可以自动处理许多调整/扣除，因此可以实现工人工作时间上的大的成本降低。

例外，本系统自动地更新卖方的记账系统以包括诸如在扣除时的勾销记录之类的调整文档。因此，即使自动处理卖方的调整，也在卖方的记账系统中包括买方的调整的记录——如果需要的话——以用于查看或一致的目的。

而且，本系统可以直接地与卖方的金融机构一体化。这使得更容易实现和处理速度更快。但是，本系统也可以被驻留在与金融机构和卖方通信的第三方中。

在首先试图自动将所有接收的支付与发票匹配的系统中，本实施例可能是最为有益的，所述系统诸如在XXXX提交的、题目为“用于自动化的输入支付和发票调解的系统和方法”的美国专利申请第XX/XXX,XXX号——通过引用而将其整体并入在此——中进一步描述的系统。不能直接地与由发票调解系统匹配的所接收的发票可能随后被本实施例的自动化调整管理系统查阅。此外，如果本自动化调整管理系统不能自动地处理买方的调整，则调整文件可以被建立和路由到人以批准或进一步处理。在XXXX提交的、题目为“用于卖方帮助的自动化支付处理和例外处理的系统和方法”的美国专利申请第XX/XXX,XXX号——通过引用而将其整体并入在此——中描述了这样的系统。此外，本实施例最好与卖方的金融机构直接一体化。

虽然已经示出和说明了本发明的特定单元、实施例和应用，可以明白，本发明不限于此，因为本领域内的技术人员可以进行修改，特别是根据上述的教程。因此考虑所附的权利要求涵盖这样的修改并且包含在本发明的精神和范围内的那些特征。

Claims (26)

1.一种用于自动化调整处理的方法，所述方法包括：

在卖方从买方接收支付；

从所述卖方检索所述买方的买方专用的信息，所述买方专用的信息包括所述卖方的至少一个未付发票和至少一个商务规则；

应用比较所述支付和所述至少一个发票的所述商务规则；

当在所述商务规则的标准内所述支付匹配所述至少一个未付发票时处理所述支付。

2.按照权利要求1的方法，其中，所述商务规则是对于所述发票的买方专用的折扣。

3.按照权利要求1的方法，其中，所述商务规则是在所述支付数量和所述发票金额中的买方专用的数值门限差。

4.按照权利要求1的方法，其中，所述商务规则是在所述支付数量和所述发票金额中的买方专用的百分比门限差。

5.按照权利要求1的方法，其中，所述商务规则是买方专用的确定，用于允许所述买方可以支付少于所述发票的总金额。

6.按照权利要求1的方法，还包括：

在所述接收步骤之前接收对于所述发票的调整；并且

在应用所述商务规则之前向所述发票应用所述调整。

7.按照权利要求1的方法，还包括：

当在所述商务规则的标准中所述支付不匹配所述至少一个未付发票时向销售调整文件建立器发送所述支付。

8.按照权利要求7的方法，还包括：

向所述卖方发送记入数据，以向所述卖方通知所述支付不匹配至少一个未付发票。

9.一种用于使用卖方可配置的商务规则来由卖方处理对于支付的调整的方法，所述商务规则可以对于不同的买方不同，所述方法包括：

在卖方存储在处理第一买方的调整中使用的第一组商务规则；

在所述卖方存储在处理第二买方的调整中使用的第二组商务规则，

其中，所述第一组商务规则与所述第二组商务规则不同；

在所述卖方从第一买方接收第一支付；

在所述卖方从第二买方接收第二支付，所述第一支付和所述第二支付都需要调整；

使用所述第一组商务规则来处理对于所述第一支付的调整；并且

使用所述第二组商务规则来处理对于所述第二支付的调整。

10.按照权利要求9的方法，其中，在所述第一组商务规则和所述第二组商务规则之一中的所述商务规则的至少一个是对于所述发票的买方专用的折扣。

11.按照权利要求9的方法，其中，在所述第一组商务规则和所述第二组商务规则之一中的所述商务规则的至少一个是在所述支付数量和所述发票金额中的买方专用的数值门限差。

12.按照权利要求9的方法，其中，在所述第一组商务规则和所述第二组商务规则之一中的所述商务规则的至少一个是在所述支付数量和所述发票金额中的买方专用的百分比门限差。

13.按照权利要求9的方法，其中，在所述第一组商务规则和所述第二组商务规则之一中的所述商务规则的至少一个是买方专用的确定，用于允许所述买方可以支付少于所述发票的总金额。

14.按照权利要求9的方法，其中，通过应用服务提供者(ASP)来执行所述处理。

15.按照权利要求9的方法，其中，在金融机构执行所述处理。

16.按照权利要求9的方法，其中，所述处理来自外部的第三方。

17.一种用于对于由买方向卖方提交的支付的调整的自动化处理的系统，所述系统包括：

在卖方的数据源，所述数据源包括一组买方专用的的商务规则，它们被配置用于处理由买方对于支付的调整；

商务数据过滤器，用于从所述卖方接收所述买方的未付发票，并且从买方接收支付，所述支付需要调整，

其中，所述商务数据过滤器从所述数据源接收所述组的买方专用的商务规则，并且通过使用所述组的买方专用的商务规则将所述支付匹配到未付发票来处理所述支付。

18.按照权利要求17的系统，其中，在所述第一组商务规则和所述第二组商务规则之一中的所述商务规则的至少一个是对于所述发票的买方专用的折扣。

19.按照权利要求17的系统，其中，所述商务规则的至少一个是在所述支付数量和所述发票金额中的买方专用的数值门限差。

20.按照权利要求17的系统，其中，所述商务规则的至少一个是在所述支付数量和所述发票金额中的买方专用的百分比门限差。

21.按照权利要求17的系统，其中，所述商务规则的至少一个是买方专用的确定，用于允许所述买方可以支付少于所述发票的总金额。

22.一种用于对于由买方向卖方提交的支付的调整的自动化处理的系统，所述系统包括：

在卖方的数据源，所述数据源包括一组买方专用的商务规则，它们被配置成用于处理由买方对于支付的调整；

商务数据过滤器，用于从所述卖方接收所述买方的未付发票，并且从买方接收支付，所述支付需要调整，

其中，所述商务数据过滤器从所述数据源接收所述组的买方专用的商务规则，并且通过使用所述组的买方专用的商务规则将所述支付匹配到未付发票来处理所述支付，

其中，所述商务数据过滤器是应用服务提供者(ASP)。

23.一种用于对于由买方向卖方提交的支付的调整的自动化处理的系统，所述系统包括：

在卖方的数据源，所述数据源包括一组买方专用的商务规则，它们被配置成用于处理由买方对于支付的调整；

商务数据过滤器，用于从所述卖方接收所述买方的未付发票，并且从买方接收支付，所述支付需要调整，

其中，所述商务数据过滤器从所述数据源接收所述组的买方专用的商务规则，并且通过使用所述组的买方专用的商务规则将所述支付匹配到未付发票来处理所述支付，

其中，所述商务数据过滤器是在金融机构的软件应用。

24.一种用于自动化调整处理的方法，所述方法包括：

在卖方从买方接收支付；

从所述卖方检索所述买方的买方专用的信息，所述买方专用的信息包括所述卖方的至少一个未付发票和至少一个商务规则；

应用比较所述支付和所述至少一个发票的所述商务规则；

当在所述商务规则的标准内所述支付匹配所述至少一个未付发票时处理所述支付，

其中，通过应用服务提供者(ASP)来执行所述处理。

25.一种用于自动化调整处理的方法，所述方法包括：

在卖方从买方接收支付；

从所述卖方检索所述买方的买方专用的信息，所述买方专用的信息包括所述卖方的至少一个未付发票和至少一个商务规则；

应用比较所述支付和所述至少一个发票的所述商务规则；

当在所述商务规则的标准内所述支付匹配所述至少一个未付发票时处理所述支付，

其中，通过在金融机构的软件应用来执行所述处理。

26.一种用于自动化调整处理的方法，所述方法包括：

在卖方从买方接收支付；

从所述卖方检索所述买方的买方专用的信息，所述买方专用的信息包括所述卖方的至少一个未付发票和至少一个商务规则；

应用比较所述支付和所述至少一个发票的所述商务规则；

当在所述商务规则的标准内所述支付匹配所述至少一个未付发票时处理所述支付，

其中，通过已经向外提供给第三方的软件应用来执行所述处理。

Images