CN104471602A - 发票和运费结算单的匹配和争议解决 - Google Patents

Abstract

本申请公开了用于接收、验证和管理关于运费船运的争议的系统和方法。

Description

发票和运费结算单的匹配和争议解决

与其他的申请的关系

本申请要求于2012年5月16日提交的美国临时申请第61/647,790号的优先权，其内容明确地通过引用并入本文。

技术领域

本文描述的特征大体上涉及电子数据处理系统，特别地涉及用于船运的自动化数据处理系统。

背景

今天，船运货物是复杂的业务。承运人具有有限量的船货空间，并且据此，托运人经常地与多个承运人商谈以协调仅一个集装箱的运送。典型地，为了限制运送货物的不确定性和成本，托运人与多个承运人签合同以向每个承运人以双方商定的价格提供预定的业务量。这给予托运人从多个不同的承运人选择以把货物在不同的港口之间运输的灵活性并且增加当托运人需要运送集装箱而同时保证各个承运人的业务量时运送集装箱的可能性。在实践中，托运人相继地联系承运人以检查可用性。例如，多个集装箱可能需要冷冻。某些承运人可能不具有可用于在给定的那天运送被冷冻的货物的船货空间。据此，即使托运人和承运人已经在运送货物的商谈之前签署了合同，事实上仍然要求托运人与多个承运人商谈，此时确保船货的运输。

因为托运人通常与多个承运人签合同，所以要求托运人学习和理解多种不同的承运人特点。当每个承运人尝试通过互联网的自动化和/或直接预订时，承运人之间的差异被加大。每个承运人预订系统(或平台)在外观和感觉上以及在人们请求货物运输的过程上可能是不同的。这迫使每个托运人学习每个承运人的平台以有效地并且高效率地预订货物的装运。对于托运人来说，整个的过程是困扰的并且耗费时间的。承运人则面对不正确的或不可调和的预订报告，导致更多的丢失的资源。

货运代理人向这种复杂的业务添加又一层面的复杂度。货运代理人通常代表托运人协调货物的运输。例如，如果托运人期望从芝加哥将货物船运至东京，那么货运代理人代表托运人与承运人商谈和/或协调以安排待被运送的货物。

因为托运人或货运代理人通常使用多个承运人运送货物，所以追踪和跟踪不同的承运人当中的货物也是高成本的。因为托运人或货运代理人经常与多个承运人协调货物的运输，所以要求他们学习如何根据特定的承运人的平台追踪和跟踪货物。因为在任何给定的时间托运人可具有几百个正被许多不同的承运人船运的集装箱并且想要知道关于他们的装运货物的状态和相关的信息，所以托运人和承运人二者都贡献大量的资源以追踪和跟踪集装箱。非罕见的是，承运人贡献整个的工作组来操作来自托运人的要求关于他们的货物的地点信息的电话呼叫。

近年来，开发者已经使用互联网来创建把买方和卖方汇集在一起进行商谈并且给予公司和他们的供应商容易地共享信息的能力的虚拟市场。已经作出通过使用互联网降低托运人的成本的某些尝试。一个尝试是给予承运人张贴关于陆地、航运和空运承载货船的公布运价和折扣信息而允许顾客在预订之前评价价格的能力。另一个使用互联网的尝试给予托运人接收来自多个参与船货运输的实体的多个出价的能力。这些系统仅识别与所选择的承运人进行业务的成本并且不再识别其它。这没有解决必须使用多个承运人平台来向不同的承运人提交预订请求的问题。在多个承运人被用于单个船运的情况下，这也没有使得货物在承运人之间容易交换。

最后，仓储货物、运输货物、报关业务和贸易金融是非常复杂的业务的复杂的部分。据此，存在对用于操作货物的物流和运输的更高效率的系统的需要。

应付账款(A/P)是美国的几乎每个企业采用的过程。以其最简单的形式，A/P是结算债务(典型地用发票表示)的支付和确定花费的相关联的会计分录的创建和分配。虽然在小企业中的A/P可以由会计师或簿记员使用分类帐或电子数据表进行操作，但是在大企业中的A/P已经演变为高度专业化的应用，涉及把之前不同的系统(例如采购、库存、总分类帐(G/L)和应付账款)链接在一起成为单个集成的系统的企业资源规划(ERP)系统。

使用制造公司作为实例，采购获取了在支持制造过程中保持目标库存水平所必需的材料。为了记载采购、建立期望的项的精确的性质和它们的各自的量、设置价格等等，采购订单(P.O.)被买方电子地或以纸张形式创建并且被发送至卖方。卖方完全地或部分地(根据该P.O.的要求)按订单供应，并且把材料传送至买方的指定的地点。一旦被买方接收，那么材料被记录在库存控制系统中。同时卖方准备表示在所提供的材料的交换中的预期和应付款项的发票并且把该发票传送至买方。买方的应付账款部门把发票与最初的P.O.比较以确保正确地授权采购并且确认发票上的项是与在P.O.中记载的项是一致的。A/P部门还通过库存控制过程确认用发票表示的材料已经以令人满意的条件被接收。

概述

本概述不意图确定本文中要求保护的本发明的关键的或基本的特征，而是仅概括其某些特征和变化形式。

本公开内容的一个或多个方面涉及辅助卖主的发票与来自那些卖主的被提供至客户的之前的估计的匹配的增强的自动化匹配系统。在第一方面中，自动化匹配系统允许将多个行条目缩减成一组或两组收费以辅助匹配所估计的费用和实际的费用。在第二方面中，自动化匹配系统允许基于各个卖主和客户的错综复杂事物的业务规则的执行。

在一个方面中，提供一种使用电子数据交换的争议解决处理的方法，包括：把电子发票链接于电子运费结算单；把所述发票与所述运费结算单比较；确定与所述发票相关联的值和与所述运费结算单相关联的值的争议；传输EDI争议消息；以及接收EDI争议响应消息。

上文描述的各个特征可以使用计算机或处理设备来实施，其可以通过执行计算机可执行的指令操作以实现所描述的各种特征。据此，本文的某些实施方案包括存储那些指令的计算机可读介质。其他的细节和特征还将在下文的章节中进行描述。

附图简述

本文的某些特征在附图的各图中以示例的方式图示，并且不以限制的方式图示，并且在附图中相同的参考标号是指相同的元件。

图1示出了托运人和承运人通过其与彼此交互的常见承运人系统。

图2示出了常见承运人系统中的各部件的例证性的硬件实例。

图3示出了本文描述的特征可以在其中实施的例证性的计算环境。

图4示出了承运人、中介人和托运人及相关的实体之间的例证性的操作关系。

图5示出了例证性的具有争议解决时期的自动匹配操作。

图6示出了发票和结算单在实体之间的传递。

图7示出了对发票和运费结算单的操作。

图8-17示出了自动匹配系统如何尝试把发票和运费结算单关联的例证性的实例。

图18示出了关于自动匹配过程的状态图。

图19示出了关于在发票匹配门户中操作发票的状态图。

图20示出了关于付款人发票/贷项清单处理的状态图。

图21示出了关于与被链接的贷项清单的自动匹配过程的状态图。

图22示出了关于发票门户的状态图。

图23示出了关于运费结算单的自动匹配过程的消息状态图。

图24示出了关于运费结算单的自动匹配过程的状态图。

图25示出了关于运费结算单线路转移的自动匹配过程的状态图。

图26示出了关于争议现状状态转移的状态图。

图27示出了用于发票和运费结算单的初始处理的过程。

图28示出了用于操作业务规则并且保存执行结果的过程。

图29示出了用于接收并且处理发票和其他的文件的过程。

图30示出了用于操作运费结算单的过程。

图31示出了用于在发票门户上检查和呈现发票的过程。

图32示出了用于操作发票副本的过程。

图33示出了用于处理争议的过程。

图34示出了另外的用于处理争议的过程。

图35示出了用于匹配发票和运费结算单的过程。

图36示出了用于管理争议响应的过程。

图37示出了用于解决发票上的其余的问题的过程。

图38示出了另一个用于解决发票上的其余的问题的过程。

图39示出了另一个用于处理运费结算单的过程。

图40示出了用于匹配出口运费结算单的过程。

图41示出了与发票和贷项结算单的处理相关的过程。

图42示出了另一个与发票和贷项结算单的处理相关的过程。

图43示出了与自动匹配相关的过程。

图44示出了与自动匹配发票和运费结算单相关的过程。

详细描述

自动匹配系统尝试分别地匹配来自承运人和货运代理人/托运人的发票和运费结算单，以减少每个实体的人员产生的手动检查操作。为了允许发票的电子检查，自动匹配系统可以使用通过预定义的标准(包括，例如，联合国(EDIFACT)开发的并且被新泽西州的Parsippany的INTTRA公司进一步采用并且增强的电子数据交换(EDI)格式)的电子开票。其他的已知的电子发票标准也可以被使用并且不进行进一步描述。此外，图像发票可以进行OCR(光学字符识别)以产生用于后续的处理的文本内容。

通过自动匹配系统，出票人(在上文的实例中的承运人)受益于及时的发票检查和检测到的差异的及时通知。付款人(在上文的实例中的货运代理人)同样受益于对多个接收到的发票的自动化发票检查。

注意，元件之间的各种连接在以下的描述中进行了阐述。注意，除非另有规定，否则这些连接通常可以是直接的或间接的，并且本说明书不意图在该方面进行限制。

为了辅助理解在此描述的各个方面，以下的描述被如下地组织：

I.综述

A.各方

B.提交区间和争议解决区间

II.提交区间

A.各方提交

a.发票和贷项清单以及

b.所估计的发票

B.把发票和贷项清单链接于所估计的发票

C.缩减常见费用条目

1.解析标准费用代码

2.缩减方法和过程

3.缩减异常

4.所有费用代码和固定收费

5.包含仅非预期的费用或非预期的费用和正常的费用的混合的发票/贷项清单。

III.争议解决区间

A.验证/匹配发票

1.业务规则

a)业务规则驱动的自动匹配

b)字母和数字比较规则

c)日期和时间比较规则

d)列表值比较规则

e)使用阈值的比较

f)操作汇率比较

g)对特定方的变化

2.自动匹配发票标头条目

a)通过标头字段匹配

b)匹配专用标头字段

3.自动匹配费用行条目

a)通过费用代码或费用代码和其他的信息(例如集装箱大小类型)匹配

b)关于任何费用代码的业务规则

c)检测缺少的和另外的费用

d)出口发票费用的方向检查

e)不可缩减的费用

f)要求手动处理的电子邮件和EDIFACT消息

B.争议发票和解决争议

1.产生争议和矛盾

a)提出争议并拿回发票

b)争议解决时期和检查时间区间

c)响应于争议

d)限制自动匹配争议循环

e)手动争议相对于自动匹配

2.解释结果

a)一般的争议信息

b)全部的争议细节

c)矛盾细节

d)标头条目发票矛盾

e)费用行条目发票矛盾

f)发票争议计数

3.应用完全链接的贷项清单

IV.其他的考虑

A.设置出票人/付款人公司

B.使能EDI订购

C.订购电子邮件通知

D.配置偏好和业务规则选项

1.定义标头规则

2.定义费用行规则

a)用于特定的费用的业务规则

b)用于所有的费用的业务规则

3.维持业务规则

在说明书中使用了以下术语。

a.托运人--具有待被运输的货物的任何实体。该实体可以期望货物被运输或可以正在为了另一个实体运输货物。

b.承运人--把货物从起点运输至目的地的任何实体。承运人可以国内和/或国际运输货物。例如，承运人可以把托运人的货物从芝加哥运输至西雅图或同一个承运人可以把货物从芝加哥运输至巴黎。承运人可以使用卡车、火车、飞机、轮船和/或类似的来运输货物。

c.承运人平台--支持使能与承运人交换信息的接口的承运人计算机系统。

d.通用承运人系统--支持通用承运人接口的基础设施，包括在一个或多个硬件设备中的数据存储部(包括动态存储部(例如硬盘、光盘等等)、静态存储部(例如固态存储器等等)和其他的已知的存储介质)。

e.通用承运人接口--使多个托运人和多个承运人能够通信的接口。

f.用户--使用常见承运人系统的任何实体。所有的用户可以在使用常见承运人系统上具有不同程度的兴趣。常见承运人系统的主要用户可以是托运人、第三方物流提供者、货运代理人、收货人、经纪人、交易门户、承运人等等。

g.AM——自动匹配过程

h.CN——贷项清单

i.COMDIS——争议和争议响应

j.EDI——电子数据交换

k.FS——运费结算单

l.IFTFCC——借助于edifact或贷项清单的入站发票

m.IFTCCA——借助于edifact的运费结算单

n.TCC——运输费用/价格计算

o.FLCN——完全链接的贷项清单

p.PLCN——部分链接的贷项清单

q.LCN——经链接的贷项清单

本发明的各方面可以在由一个或多个计算机或其他的设备执行的计算机可执行的指令(例如程序模块)的一般情况下进行描述。计算机或处理设备可以通过执行计算机可执行的指令来操作以实施所描述的各个特征。据此，本文的某些实施方案包括存储那些指令的计算机可读的介质。通常，程序模块包括进行特定的任务或实施特定的抽象数据类型的例行程序、程序、对象、组成部分和数据结构。典型地，程序模块的功能可以在各个实施方案中根据需要进行被组合或分配。

I.综述

下文描述了各方以及在其期间发票被提交、匹配并且提出争议的解决的计时区间。

A.各方

图1图示了根据本发明的一个或多个实施方案的代表性的基础设施的实例。用户101a-101e经由终端通过包括服务器102b-102c和数据库102a的常见承运人系统102与多个不同的承运人103通信。在一个实施方案中，用户使用终端与常见承运人系统102交换信息。这些终端可以是如本领域中已知的标准个人计算机。在可选择的实施方案中，用户可以使用如本领域中已知的手持设备或其他的便携式设备来与常见承运人系统102通信。此外，来自多个用户的通信可以在向常见承运人系统102的传输之前在用户的地点处一起进行批处理。虽然图1示出了五个用户、五个承运人终端、一个数据库和三个服务器，但是图1仅是例证性的并且用户和/或用户终端、承运人和/或承运人终端、服务器和数据库的数量不以任何方式被限制。此外，虽然各种实施方案在单个系统的背景下进行描述，但是本领域的技术人员可以意识到所描述的功能可以在多个系统中进行实施。此外，网站可以在网络中的另外的系统处成镜像并且，如果期望的话，一个或多个管理系统或其他的计算机资源可以被用于促进各种功能。系统处的计算机程序包括合适的用于产生共同地包括该站点的用户界面的屏幕组的屏幕例行程序。

图2更详细地图示了常见承运人系统102。常见承运人系统包括，例如并且不限于服务器104a-104c。服务器104a包括可以被用于通过电子邮件接收和发送数据的邮件服务器105。服务器104a还包括用于通过互联网接收和发送数据的服务器106。服务器104b包括作为服务器108与服务器105和106之间的通信桥梁的服务器107。服务器107轮询服务器105和106以获得新的消息，把消息拆包并且发送至服务器108。针对来自服务器107的出站轮询，服务器108加入接收者的地址并且触发消息的传递。当服务器107不能够处理EDI消息时，电子邮件将被发送至预定义的电子邮件地址。

服务器108通过当被服务器107调用时验证数据并且把数据变换到常见承运人系统中以进行处理而处理EDI消息。对于出站EDI消息，服务器108被服务器109调用并且服务器109在常见承运人系统处理中为服务器108加入出站EDI消息。服务器104b包括服务器109和110。服务器109转换常见承运人系统布局并且把常见承运人系统布局加载至数据库表的集合，或反之亦然。服务器109还轮询服务器108以获得任何新的消息，打开与数据库的连接并且填充对应于EDI消息类型的数据库表。对于出站EDI消息，服务器109扫描由EDI处理器填充的数据库表且转换消息并且然后触发服务器108以处理常见承运人布局格式。参照服务器110，EDI处理器是处理被服务器109置入数据库表中的EDI消息的服务器110的一部分。服务器110扫描数据库表的抬头以查找被标记为例如已提交的的第一未处理的消息。状态然后从已提交的改变至在数据库111中处理并且如果成功的话，状态接着改变为完成。

在过去，承运人(出票人)和托运人/代理人/收货人(付款人)二者都花费大量的时间在发票检查、批准和争议解决上，这由于这些工作的手动的并且耗费劳动力的本质而导致高的成本。因此，及时的且精确的发票结算过程的缺乏最终影响出票人和付款人二者的操作，在资信情况(creditposition)、营运资金优化、船货延迟以及结合被设计为审计、改正和改进历史交易的增量业务处理的必要性的方面进行影响。根据在本申请中提出的构思，用计算机实施的匹配工具，通过其的被实施的过程，有利地解决例如围绕货运行业中高频率的发票不精确性的担忧。

本文描述的用于发票的自动匹配系统的优点中的某些是对海运运费结算过程的效率、精确度和透明性的引入；特别是关于精简海运运费发票的验证的能力。这通过利用付款人的以应计发票(或运费结算单)的形式的现有内部数据进行。自动匹配系统自动地通过把其与使用支配验证过程的预定义的业务规则提供的运费结算单进行比较而验证运费发票的精确度。在检测到发票数据不满足业务规则时，自动匹配系统自动地向出票人提出争议并且相应地告知付款人。

图3示出了自动匹配系统的例证性的实例，该自动匹配系统包括出票人(被称为承运人301)、付款人(被称为货运代理人/托运人/收货人302)、和自动匹配门户303。自动匹配门户303包括如本领域中已知的、访问如被设置在一个或多个计算机存储设备(硬盘驱动器、光盘驱动器、闪速存储器和其他的已知的存储设备)上的一个或多个数据库的一个或多个硬件网络服务器。与门户303通信并且已经接收(或在接收来自承运人301的服务的过程中)的实体在图1中作为货运代理人302被示出。

承运人301和货运代理人302中的每个都包括一个或多个被连接到互联网以与门户303通信的常规的计算机和存储设备。承运人301包括具有关于包装/集装箱的各种船运价格305和与针对货运代理人302(或在302处的任何其他的实体)进行的各种作业相关联的作业文件集的数据库304。通过与数据库304的交互，承运人301准备发票307并且把已准备的发票308通过电子数据消息传送系统314(例如EDI)发送至门户303。承运人301接收并且张贴支付款项(在321和322)。如果任何争议发生，那么它们在326处被操作和解决。可以由门户303通过EDI、电子邮件和/或网页的用户界面等将该争议通知给承运人301，如示出为消息交换328的。

货运代理人302(在本文中出于简单性而被使用，但是可以视情况而定指托运人或收货人)包括含有价格信息310(可能对各个承运人通用的或特定的)和与船运操作相关的作业文件311的数据库309。通过与数据库309的交互，货运代理人302收集费用细节312并且准备运费结算单313且把其通过电子数据消息传送系统315(例如EDI)发送至门户303。在接收(在步骤323中)已批准的发票319(例如通过EDI)时，货运代理人302准备支付(在步骤324中)并且授权支付(在步骤325中)以结算发票319。如果发票受到争议，那么可以由门户303通过电子邮件和/或网页的用户界面等(可能包括EDI)将该争议通知给货运代理人302，如示出为消息交换329的。货运代理人在步骤327中检查并且解决该争议。

门户303从承运人301接收电子发票308并且从货运代理人302接收运费结算单313。门户303在步骤316进行包括代码标准化的各种自动化匹配操作。然后，在步骤317中，门户303尝试匹配发票308和结算单313。对于被匹配而没有争议的发票308和结算单313，生成发票319并且将其例如通过EDI传输至货运代理人302。对于具有一个或多个与它们相关联的争议的发票308和结算单313，它们被转发至争议操作，如在步骤324中示出的关于承运人301和货运代理人302之间的解决。最后，分析报告330和331在争议操作步骤320产生并且根据需要或期望分别转发至承运人301和货运代理人302。

在图3中进行的操作的各个方面在下文关于图4进行描述。图4示出了三个实体：出票人401、付款人402、和门户403。出票人401是执行服务的实体。例如，出票人401可以是将执行服务、正在执行服务或已经执行服务(例如把集装箱从一个港口运输至另一个)的承运人。出票人401包括如本领域中已知的管理其操作404(其中记载了费用产生)和出票405(其中针对提供的服务，执行了开发票，应用贷记并且发生重开票)的计算机系统。

付款人402可以是相关的托运人、代理人或收货人。付款人402，相似于出票人401，包括常规的操作系统408(管理应计费用)和应付账款系统409(管理开发票和贷记重开票操作)，如目前本领域中已知的。争议操作系统410被用于接受或拒绝来自出票人401的争议响应。

开发票门户403管理争议的接收、匹配、产生，以及对出票人401和付款人402之间的争议的响应的传输。开发票门户403包括包含例如安全/认证层411、管理层412和主数据层413的应用层407。主数据层413可以包括关于每个出票人401和付款人402之间的与每个如何指定其的发票、贷项凭单和运费结算单中的信息相关的细微差异的一个或多个表格。

应用层407执行以下的四个主要的过程：接收发票和贷项清单414，自动匹配发票/贷项清单/运费结算单415，争议操作416，和工作流程控制417。

图4示出了各种消息在出票人401、门户403和付款人402之间进行交换。这些消息如下地在以下的表格1中进行识别：

参照图4，对于消息流动01，出票人发送的发票和贷项凭单被上传至处理匹配工具。对于消息流动01a，出票人可以可选择地发送以不可改变的格式的发票和贷项凭单图像。例如，格式可以包括TIFF、PDF、PNG、JPG、GIF，和任何已知的其中对内容的文本改变被禁止的格式。这些文件可以被加载至匹配工具并且链接于入站发票。对于消息流动02，在匹配工具处理完成时，该工具可以把发票和贷项凭单电子化发送至含有结果的付款人。对于消息流动03，任何作为匹配工具处理的结果被发现的发票争议将通过EDI消息发送至出票人。争议消息还将含有关于在发票上检测到的矛盾的信息。对于消息流动04，付款人还可以接收含有任何作为匹配工具处理的结果被发现的发票矛盾的争议消息的副本。对于消息流动05，出票人将研究关于发票提出的争议并且相应地通过接受或拒绝争议来响应于争议。争议响应消息还将含有来自出票人的指示响应原因的信息。对于消息流动06，出票人发送的争议响应将被转发至付款人以告知他们出票人的关于提出的发票争议的决定。

B.提交区间和争议解决区间

图5示出了例证性的承运人、中介人、托运人和相关的实体之间的操作关系。

通常，争议解决过程涉及出票人对付款人的争议进行回复，以及付款人反过来采取合适的行动，作为出票人的回复的结果。如果出票人承认具有开发票错误，那么他们将取消错误的发票并且再发出具有合适的改正的新发票。付款人将交叉检查新的发票以确保正确地进行所有合适的改变。相反地，如果出票人相信开发票是正确的并且付款人的争议是无效的，那么付款人将需要再检查它们的应计项目，或有时是指他们的与出票人的最初的协议，以再检查发票。争议解决过程可以被重复多次，直到双方都最终地一致同意正确的发票。

当自动匹配过程检测到主体发票和运费结算单之间的矛盾时，争议被送入第一争议解决时期中。对于在匹配工具中提出的争议，出站COMDIS争议提交EDI消息被传输至出票人(以及可选择地传输至信息的付款人)。对于自动匹配过程，争议解决时期可以被唯一地捆绑于被争议的发票以及其后续相关的发票中的任意一个。如果自动匹配过程发现争议，那么出票人可以通过发送用于接受争议或拒绝争议的响应EDI消息来响应于EDI消息。在这样的争议被接受的情况下，出票人使用EDI消息传送来传输经链接的贷项清单以取消之前的发票(被争议的)。然后，出票人发出新的相关的发票以改正之前的发票的矛盾。该过程通常被称为贷记再出票。

可选择地，在争议过程中，如果出票人不接受争议(例如拒绝争议)，那么付款人传输已改正的运费结算单代替之前的运费结算单的EDI消息。如果没有从出票人接收到争议响应，那么匹配工具进入到流逝的时期，而与出票人是否发出“贷记再出票”或付款人是否发送已改正的运费结算单无关。在第一争议解决时期和第二解决时期内，预定义的区间根据付款人的偏好来指定。这些时间区间作为预定义的等待时间从第一争议解决时期开始相继地执行，直到时期304结束。

如果争议响应等待时间已经流逝，那么其意指无承运人争议响应(NCDR)被发出或争议响应(DR)和预期的经修改的文件不可用于匹配工具。在预定义的等待时间期满而没有发票与运费结算单的争议的解决之后，该过程延伸入第二争议解决时期中。自动匹配过程可以通过比较最新的活动的发票(作为“贷记再出票”的结果)与最新的活动的运费结算单(之前在结算时期期间或在先前的争议解决时期(例如第一争议解决时期)期间被发送)而执行。

具体地，在图5中，示出三个时期：结算时期501、第一争议解决时期502和第二争议解决时期503。为了容易的描述，参照四个时间点描述这三个时期：时间1——结算时期501的开始；时间2——结算时期501的结束和第一争议解决时期502的开始；时间3——第一争议解决时期502的结束和第二结算争议解决时期503的开始；以及时间4——第二争议解决时期503的结束。

时间段1在发票抵达时开始(结算时期501)。这开始自动匹配过程。有可能的是，如果用户提交了提交的文件或发送阻碍自动匹配过程的操作的响应，那么自动匹配被取消。在结算时期501，可以具有多个贷项凭单和/或重开票发票，如通过文件的接收504示出的。此外，在结算时期501期间，可以具有多个从付款人接收的运费结算单，如通过文件的接收505示出的。

然后，在距第一提交或后继任务预定量的时间(例如一个月、三个月等等)之后或在各方中的一个的请求时或当在业务规则中确定了事件(例如向港口传送集装箱)发生时，第一结算时期501结束并且在时间区间2处执行自动匹配过程的第一传递。

在时间区间2，当矛盾被检测到时，自动匹配过程发送争议511或基于其他的异常把发票发送至付款人。

在第一争议解决时期502期间，如果争议被确定并且被发送至各方，如通过争议511示出的，那么门户接收到争议响应506。争议响应可以是基于网络的门户(例如提供用于在用户的浏览器上显示的网页的服务器，该服务器将有关的信息填入网页以允许用户响应于争议511)的用户界面的一部分或作为被EDI传输的预定义的形式或其他的内容。然后，付款人还可以提交多个贷项凭单和/或再出票的发票，如通过文件的接收507示出的。相似地，付款人可以提交多个运费结算单，如通过文件的接收508示出的。

在第一争议解决时期502期间，自动匹配过程可以被如下执行：

A.如果发现争议响应，那么检查响应，

1.如果争议被接受，那么寻找来自出票人的贷记再出票。如果被发现，那么再次地执行自动匹配过程，否则等待贷项凭单或再出票或下一个争议响应或区间。

2.如果争议被拒绝，那么寻找已调整的运费结算单。如果被发现，那么再次地执行自动匹配过程，否则等待贷项凭单或再出票或下一个争议响应或区间。

B.如果没有发现争议响应，那么等待下一个区间。

基于该步骤，可以将争议提交或发票从门户发送至付款人和/或出票人512。

第一争议解决时期502在等待时间已经流逝之后结束。例如，第一争议解决时期502的持续时间(以及结算时期501和第二争议解决时期503的持续时间)可以由付款人的业务实践指定。

如果争议响应等待时间已经流逝(第一争议解决时期502的持续时间)，那么其意指没有出票人争议响应被发现或争议响应和预期的经修改的文件不可用于自动匹配过程的第一次执行(例如AM的第一传递)。如果这些中的任一个是真，那么系统寻找贷记再出票和/或已调整的运费结算单并且再次执行自动匹配过程。如果二者都是假，那么门户把发票发送至付款人，以及发送要求手动处理的确定。为了本文的目的，从门户发送发票被称为“出站”并且要求手动处理的指示被称为MPR。例如，争议提交或发票可以被发送，如由箭头513示出的。

在第二争议解决时期503期间，争议响应509可以通过基于网络的门户的用户界面或通过EDI进行接收。此外，贷项凭单和/或再出票可以被多次接收510。

在第二争议解决时期503期间，门户如下检查从出票人和/或付款人接收到的内容：

A.如果发现争议响应，那么检查响应，

1.如果争议被接受，那么寻找来自出票人的贷记再出票。如果被发现，那么再次执行自动匹配过程，否则等待贷项凭单或再出票或下一个争议响应或区间。

2.如果争议被拒绝，那么寻找已调整的运费结算单。如果被发现，那么再次执行自动匹配过程，否则等待贷项凭单或再出票或下一个争议响应或区间。

B.如果没有发现争议响应，那么等待下一个区间。

如果仍然发现争议，那么没有更多的争议细节(在本文中被称为COMDIS)将被产生并且发票将进行出站，且发送要求手动处理的指示。

最后，第二争议解决时期503结束并且执行最后的自动匹配过程。

如果该时期由于争议响应等待时间已经期满而结束，那么其意指无承运人争议响应被发现或争议响应和预期的经修改的文件不可用于自动匹配的最后传递。在这种条件下，以下的步骤被采取：

A.寻找贷项凭单或再出票或已调整的运费结算单并且然后进行自动匹配。

B.如果没有一个被发现，那么把发票515发送至付款人，且发送要求手动处理的标记。

如果仍然发现争议，那么没有更多的争议细节将被产生并且发票将出站，且发送要求手动处理的指示。

争议解决过程涉及出票人和付款人之间的使用EDI的电子双向通信。付款人负责检查出票人发出的发票并且如果具有任何矛盾的话则相应地提出争议。而出票人负责在研究所有的细节之后响应于付款人的争议。结算时期允许付款人有足够的时间来发送运费结算单以允许发票验证发生。在第一结算时期内，如果没有发现矛盾，那么发票被正确地链接于运费结算单。

II.提交区间

A.各方提交

各方(出票人和付款人)中的每个把一个或多个文件提交至开发票门户，开发票门户然后匹配它们，调整改变，并且尝试解决争议。

1.发票和贷项清单

发票和贷项清单由出票的实体产生。通常发票、贷项清单和再发出的/已改正的发票(再出票的发票)在出票的实体认为是最后的之前被多次提交。

2.所估计的发票

所估计的发票是付款人预期支付的发票。所估计的发票有时被称为运费结算单。

图6包括以下的实体：自动匹配过程601自动化运费发票的验证和争议逐步升级。发票操作过程602操作付款人的电子开发票。开发票门户603是协调自动匹配过程601和发票操作过程602之间的交互和那些过程与出票人604和付款人605之间的交互的基于互联网的平台。付款人605接收发票并且最终地支付在那些发票内的进行收费的货物和服务。出票人604是发送含有关于被传送的货物和服务的费用的发票的实体并且希望作为回报的支付。

下文确定在图6中被确定的各种消息：

运费结算单(IFTCCA)606。从付款人至开发票门户。付款人使用入站IFTCCA运费结算单EDIFACT消息格式把运费结算单发送至开发票门户以便提供必需的信息而使能自动匹配以能够自动验证来自出票人的发票。注意：运费结算单含有付款人预期支付的预期费用，可能从付款人的应计项目系统、合同管理系统、采购订单系统、BL定价系统等提取。

发票和贷项凭单(IFTFCC)607。从出票人至开发票门户。出票人使用入站IFTFCC商业发票EDIFACT消息格式把发票或贷项凭单发送至开发票门户。

加载发票和贷项凭单608。从开发票门户至开发票过程。开发票门户将验证IFTFCC消息并且最终地处理其以加载至发票操作过程平台上。处理发票包括使其运行整个安全审查并且解释某些数据以允许进一步的处理。

发票和贷项凭单图像(PDF)609。从出票人至开发票门户。出票人可以可选择地把他们的发票或贷项凭单的PDF图像文件发送至开发票门户。

加载和链接PDF文件610。从开发票门户至发票操作过程。使用指定的PDF文件名格式(例如将发票号码或贷项凭单号码作为文件名)，发票操作过程将能够把PDF文件链接于其相应的发票或贷项凭单。注意：所使用的PDF文件名格式是IFTFCC_PDF.参考编号.YYYYMMDD发出日期.出票人公司ID.ID代码.pdf。

发票/贷项凭单可用通知611。从发票操作过程至付款人或出票人。一旦发票或贷项凭单已经被成功地加载，那么发票操作过程平台将自动地把电子邮件通知发送至付款人(以及可选择地发送至出票人)，告知他们发票现在是可用的。该通知是可选择的并且可以基于顾客的偏好进行配置。注意：如果PDF文件已经由出票人提供，那么其可以被电子邮件通知包括。

提出自动匹配事件612。从开发票门户至自动匹配过程。开发票门户将检查是否针对出票人-付款人组合订购自动匹配服务并且通过把相应的发票和运费结算单发送至自动匹配服务而自动地触发自动匹配处理。

提出争议事件613。从自动匹配至发票操作。自动匹配基于之前在系统中定义的业务规则验证发票；如果检测到任何矛盾，那么将自动提出争议。注意：如果发票操作过程没有检测到矛盾(或争议)，那么步骤614-619将不发生。

发票争议通知614。从发票操作过程至出票人或付款人。发票操作过程平台将自动地把电子邮件通知发送至出票人(以及可选择地发送至付款人)，告知它们发票已经被争议。该通知是可选择的并且可以基于顾客的偏好进行配置。

争议细节(COMDIS)615。从开发票门户至出票人或付款人。开发票门户将使用出站COMDIS商业争议提交EDIFACT消息格式把关于发票的争议细节(矛盾)发送至出票人(以及可选择地发送至付款人)。

争议响应(COMDIS)616。从出票人至开发票门户。在检查任何发票争议之后，出票人使用入站COMDIS商业争议响应EDIFACT消息格式把他们的争议响应发送至开发票门户。争议响应可以是肯定的(接受争议)或否定的(拒绝争议)。争议响应也可以通过发票操作过程门户网站进行提交。

加载争议响应617。从开发票门户至发票操作过程。开发票门户将验证COMDIS消息并且最终地处理其以加载至发票操作过程平台上。

争议响应通知618。从开发票门户至付款人或出票人。发票操作过程平台将自动地把电子邮件通知发送至付款人(以及可选择地发送至出票人)，告知他们来自出票人的响应。该通知是可选择的并且可以基于顾客的偏好进行配置。注意：当争议最初地从网站界面提出时或当从任何界面提出时可以触发争议响应通知。

争议响应(COMDIS)619。从开发票门户至付款人。发票操作过程平台将使用出站COMDIS商业争议响应EDIFACT消息格式把从出票人接收到的争议响应发送至付款人。注意：发送至付款人的争议响应可能不一定与从出票人接收到的争议响应精确地相同，因为开发票门户可以在其把争议响应发送至付款人之前进行另外的处理(例如别名化)。争议响应也可以通过发票操作过程门户网站而进行在线察看。

提出发票出站620。从发票操作过程至开发票门户。如果自动匹配基于之前定义的业务规则没有检测到关于发票的任何矛盾，那么其将自动地处理通过EDI(如果被订购的话)或电子邮件(如果被订购的话)向付款人传送的发票。注意：与已经被发送至付款人的发票相关联的任何贷项清单也将被发送出。

发票和贷项凭单(IFTFCC)621。从开发票门户至付款人。开发票门户将使用出站IFTFCC商业发票EDIFACT消息格式把发票或贷项凭单发送至付款人。注意：发票和贷项清单也可以通过发票操作过程门户网站进行在线察看。

B.把发票和贷项清单联接链接于所估计的发票

本章节详细描述自动匹配过程如何把发票链接于其相应的运费结算单以及其如何利用可配置的业务规则来验证发票并且潜在地向出票人提出争议。本章节还包含关于如何在出站COMDIS争议提交EDIFACT消息以及出站IFTFCC发票EDIFACT消息上呈现自动匹配结果的信息。争议管理和解决由于其涉及自动匹配处理，故也在下文进行解释。

在可以通过自动匹配过程验证发票之前，必须以某种方式将发票链接于正确的运费结算单。类似于付款人的职员将如何获得来自出票人的纸质发票，并且使用某个关键的信息(例如提货单(Bill of Lading))搜寻全部的订单或作业文件以确定正确的信息从而开始发票验证；出票人和付款人必须提供使能自动匹配过程以正确地把发票链接于相应的运费结算单的必需的关键的信息。

可以在把发票链接于运费结算单时使用以下的关键词：

·承运人ID——存储在开发票门户中并且在识别海运承运人中使用的唯一标识符(公司ID)。海运承运人是被托运人/代理人/收货人雇佣以船运货物的承运人，其不同于出票人，出票人可以通常是实际上发出发票的、海运承运人的地区的办公室或运营办公室。

·付款人ID——存储在开发票门户中并且在识别负责支付被船运的物品的付款人中使用的唯一标识符(公司ID)。付款人ID可以是预付费付款人ID或货到付款(Collect)付款人ID，取决于其是被链接的进口发票还是出口发票。

·提货单参考编号——海运承运人发出的作为传送货物的合同的提货单文件的参考编号。

·托运人的识别号码(SID)——托运人用于识别特定的船运的参考编号。

·预订号码(BN)——海运承运人用于识别货物的船运的特定的预订的参考编号。

发票至运费结算单链接依从一组规则。需要这些规则在发票验证过程中提供一致性和审计能力。重要的是注意，贸易伙伴应当确保待被用于链接的关键参考编号被识别并且在业务过程中的正确点处将是可用的。

本章节提供对链接规则的描述以及用于更好地图示链接逻辑的实例。

发票和运费结算单可以被分类为是出口或进口文件，取决于贸易的方向。出口发票始终被链接于出口运费结算单；而进口发票通常被链接于进口运费结算单。具有其中进口发票可以被链接于出口运费结算单的情况。

图7示出了发票和运费结算单的操作。已预付费的出口发票701仅含有已预付费的费用。出口运费结算单702将始终含有已预付费的费用并且可选择地也可以含有货到付款费用。

进口发票703和进口运费结算单704将始终仅含有货到付款费用。如在图7中示出的，出口发票701待通过链接部705链接于出口运费结算单702并且进口发票703待通过链接部706链接于进口运费结算单704。此外，进口发票703可以通过链接部707链接于出口运费结算单702。

为了本文的目的，结算单、发票等之间的链接可以是存储在数据库、表格中或在每个条目的文件名或另外的内容字段中的数据。

图8-17示出了自动匹配系统如何尝试关联发票和运费结算单的例证性的实例。

图8示出了发票801，包括例如出票人ID 803、承运人ID 804、付款人ID 805，以及提货单参考编号806、托运人识别号码808、代理人参考编号809、顾客参考编号811、收货人参考编号812和预订号码813中的任何一个。运费结算单802包括出票人ID 814、承运人ID 815、预付费或货到付款付款人ID 816、提货单参考编号818、托运人识别号码819、预订号码820和期满日期821。

下文提供自动匹配系统用于把发票链接于其的相应的运费结算单的规则。所有的规则必须在链接可以发生之前被满足：

1.发票和运费结算单二者上的承运人ID必须精确地匹配。

2.发票和运费结算单二者上的付款人ID必须精确地匹配。

a.出口发票：发票上的付款人ID必须匹配运费结算单上的预付费付款人ID

b.进口发票：发票上的付款人ID必须匹配运费结算单上的货到付款付款人ID

3.索引(BL索引#、托运人识别#、预订#)中的至少一个必须在发票和运费结算单之间匹配。

a.来自运费结算单的索引以以下的顺序进行检查：BL索引#，随后是托运人的识别#，随后是预订#。

b.一旦一对索引匹配，那么系统不继续到检查下一个参考编号。

c.当匹配来自运费结算单的托运人的识别#时，其与来自发票的以下的索引中的任何一个匹配：托运人的识别#、代理人索引#、顾客索引#、和收货人索引#。

d.索引使用不分大小写比较进行匹配并且必须是全价匹配。这意指如果发票具有同一个类型的个索引(即多个托运人的识别#)，那么相应的运费结算单必须也含有具有相同值的索引的相同精确的号码。

4.正在被链接的运费结算单必须不具有小于当前日期的期满日期。允许付款人提供运费结算单期满日期以动态地停用已过期的文件的链接。

5.发票和运费结算单二者都必须通过OFAC(外国资产控制办公室)审查。

6.正在被链接于发票的运费结算单不能已经在之前的自动匹配执行中被更换、取消或使用。

7.一个发票仅可以被链接于1个运费结算单。同样地，一个运费结算单在任意时间点仅可以被链接于1个发票。

以下适用于上文的规则：

1.不在链接过程中使用用于识别发出发票的海运承运人的地区办公室或运营办公室的出票人ID。这背后的基本原理是付款人通常不是100％确定哪个承运人的办公室将正在向他们发出发票。

2.出票人ID，虽然不是链接过程的一部分，但在确定哪个自动匹配业务规则集将执行中进行使用。更具体地，发票(不是运费结算单)上的出票人ID被用于确定这样的业务规则。

3.不在链接过程中使用发出运费结算单的付款人ID。一个运费结算单含有3种类型的付款人：运费结算单发出人、预付费的付款人和货到付款的付款人；可能的是，在链接过程中使用后两者。

4.在发票上的不同的索引中搜寻来自运费结算单的托运人的识别#的背后的基本原理是，出票人通常不100％确信付款人已经在他们的自己的内部系统中使用哪个索引并且已经在历史上把托运人的识别#置于这四个参考类别中的一个中。

通常，进口发票被链接于进口运费结算单。这是因为两个文件都含有使用在自动匹配中定义的业务规则匹配和比较的货到付款费用。出口发票始终被链接于出口运费结算单，这是由于两个文件都含有已预付费的费用的同一个原因。

然而，自动匹配过程允许付款人提供他们在出口运费结算单上的已预付费的和货到付款费用的灵活性。这背后的基本原理由两部分组成：

·这允许付款人能够在出口文件处理期间提供货到付款费用(并且不是仅已预付费的费用)，如果该费用已经是已知的的话。如果它们预期的货到付款费用没有改变的话,那么不要求付款人发送进口运费结算单。

·这也使对出口发票上的费用的先进检查成为可能，以确定是否具有实际上应当意指货到付款(或进口)方的已预付费的费用。

以下是由自动匹配具体地用于进口发票的另外的链接规则(上文声明的规则仍然适用)：

1.仅含有货到付款费用的出口运费结算单可以被链接于进口发票。这些货到付款费用不能已经在之前的自动匹配执行中被使用。还针对更多的信息参见章节“理解发票和运费结算单状态和自动匹配发票验证过程”。

2.当链接进口发票时，进口运费结算单始终优先于出口运费结算单。这与进口运费结算单是否可以被自动匹配使用(例如由于OFAC非合规，等等)无关。

3.如果进口发票已经在之前被链接于进口运费结算单，那么后续的自动匹配执行应当把同一个进口发票仅链接于进口运费结算单。

4.如果进口发票已经在之前被链接于进口运费结算单，那么任何后续的相关的进口发票也应当仅被链接于进口运费结算单(见关于“用于自动匹配的相关发票”的章节)。

以下也可以适用：

1.可能的是，出口运费结算单可以具有其已经被使用的已预付费的费用，但是其的货到付款费用仍然没有被使用。这样的出口运费结算单仍然可以被链接于进口发票。

2.在仅把后续的进口发票链接于进口运费结算单的背后的基本原理(如果进口发票或之前的进口发票已经被链接于进口运费结算单的话)是因为出口方将不能够知道或恰当地提供对进口方的改正。

图9示出了正在被链接的出口发票和出口运费结算单的实例。对于本实施例和下文的实施例，发票中的字段与在图8中示出的那些大体上相同并且不详细地进行列出。在此，链接基于运费结算单的托运人的识别号码919相对于发票的顾客参考编号911，因为提货单参考编号918没有被设置在运费结算单902上。运费结算单期满日期也在当前日期之后并且两个文件都是OFAC合规的。

图10示出了尝试的链接的另一个实例。出口发票和出口运费结算单被链接。链接基于具有2个关于两个文件的精确匹配的预订号码(BN)的预订号码。运费结算单的托运人的识别号码不被用于链接，这是因为发票的索引每个仅具有1个值：SR007或SR008，而运费结算单具有2个索引SR007和SR008；这被认为是非全价匹配。

图11示出了尝试的链接的另一个实例。然而，在此，出口发票和出口运费结算单不能够被链接。虽然所有的索引是有效的并且有OFAC合规，但运费结算单已经期满并且链接不发生。

图12示出了尝试的链接的另一个实例。出口发票和出口运费结算单不能够被链接。虽然所有的索引是有效的并且虽然运费结算单具有有效的期满日期，但运费结算单不是OFAC合规的并且链接不发生。

图13示出了尝试的链接的另一个实例。进口发票不被链接于出口运费结算单，因为运费结算单不含有任何货到付款费用。虽然所有的索引是有效的并且虽然运费结算单具有有效的期满日期并且有OFAC合规，但链接不发生。

图14示出了尝试的链接的另一个实例。尽管出口运费结算单含有货到付款费用，其中所有的索引、OFAC和期满日期是有效的，但进口发票被链接于进口运费结算单。进口运费结算单货到付款费用优先于出口运费结算单货到付款费用。

图15示出了尝试的链接的另一个实例。进口发票和进口运费结算单二者不能够被链接，因为进口运费结算单不是OFAC合规的。虽然所有的索引是有效的并且虽然进口运费结算单具有有效的期满日期，但链接不发生。

此外，出口运费结算单将不被链接于进口发票，因为已经存在有进口运费结算单。虽然出口运费结算单具有货到付款费用，其中所有的索引、OFAC和期满日期是有效的，但链接不发生。

图16示出了尝试的链接的另一个实例。进口发票不能够被链接于2个进口运费结算单中的任意一个。虽然2个进口运费结算单具有有效的索引、期满日期和OFAC合规。这背后的原因是自动匹配过程将不能够恰当地执行，因为其将不能知道哪个运费结算单待使用以检查发票。将提出自动匹配异常并且将向付款人发送出发票。

下文解决其中在文件链接期间没有发现运费结算单的问题。发票和运费结算单被开发票门户在不同的时间接收。理想地，付款人将在出票人发送发票之前已经发送运费结算单；那样，发票可以被立即地自动匹配并且可以向出票人或付款人发出结果以进行进一步的处理或支付执行。然而，具有可以在发票相关的运费结算单到达之前的几小时通过门户接收或处理发票的情况；这防止发票在其被发送至付款人之前进行自动匹配。自动匹配系统提供允许发票和运费结算单在处理开始之前‘等待’预定义的时间段的灵活性。

虽然这样的等待时间提供关于付款人在来自出票人的发票已经被处理之后发送运费结算单的灵活性，但是仍然建议的是，在出票人发送他们的发票之前由付款人发送运费结算单。

在自动匹配系统不能够发现待链接于发票的运费结算单的情况下，来自系统的电子邮件通知可以被配置为告知来自付款人方的不能发现关于已处理的发票的运费结算单的具体个体。

被链接的贷项清单(或贷项凭单)是出票人发送至他们的付款人的文件，以调整发票上的不正确的费用或在某些情况下以完全地取消发票。出票人必须在把被链接的贷项清单发送至门户时提供相关的发票号码和发票发出日期。这提供自动匹配的手段以恰当地识别贷项清单改正正在的发票。

具有两个类型的被链接的贷项清单：部分被链接的贷项清单(PLCN)和完全链接的贷项清单(FLCN)。当出票人发送部分被链接的贷项清单时，他们的意图是主要改正相关的发票上的某些费用条目；发票本身具有其他的是正确的并且应当在已经应用PLCN之后保持有效的条目。当出票人发送完全链接的贷项清单时，他们的意图是通过归零发票上的所有费用来完全地使相关的发票无效。出票人可以在取消发票时具有不同的实践，使用FLCN是取消发票的一个手段；其他的出票人可以选择明确地取消发票而不发出任何完全链接的贷项清单。

当处理完全链接的贷项清单时，自动匹配使用其来撤销之前在相关的发票和相应的已链接的运费结算单之间进行匹配的任何费用。图17示出了完全链接的贷项清单正在被链接于发票和运费结算单的实例。

因为完全链接的贷项清单主要取决于正在被改正的相关的发票，所以把完全链接的贷项清单链接于运费结算单基于已经在相关的发票和运费结算单之间存在的现有的链接。类似于发票，完全链接的贷项清单必须通过OFAC审查，以便使其在自动匹配过程中被认为是有效的文件。

C.缩减常见费用条目

自动匹配发票验证过程的核心是所有关于确信出票人发送的发票上的费用符合付款人的预期。这些费用虽然对于出票人和付款人具有相同的意思，但实际上以各种不同的方式在出票人的和付款人的自己的系统内进行表示或存储。实施例：出票人可以在他们的系统中使用BSF的代码表示基本运费费用，而付款人可以简单地使用BF的代码将其存储。

此外，因为付款人可以不完全地知道他们的出票人可以如何分解他们的运费费用或额外费用，所以付款人可以把某些费用表示为一个单一代码，而出票人可以具有用于相似的费用的变化形式的多个代码。实施例：出票人可以具有海湾额外费用、油舱额外费用、运河额外费用和冷藏货船额外费用，全部表示为他们的系统中的差额代码，但是对于付款人，它们可以简单地把这些表示为关于额外费用的类型相关的任意运输的一个单一代码。

据此，重要的是自动匹配能够使出票人和付款人之间的费用代码统一以正确地匹配和验证发票条目费用。常见费用的缩减也是自动匹配中的重要特征以使出票人和付款人之间的各种相似的费用的多向匹配成为可能。

1.对标准费用代码的解决

自动匹配采用UN/ECE CEFACT贸易便利化建议(Trade FacilitationRecommendation)N°的子集合。23运费成本代码是在统一出票人和付款人之间的费用代码中使用的标准费用代码的列表。为了使用自动匹配来帮助发票费用的验证，有帮助的是出票人和付款人把他们自己的代码映射到标准费用代码(例如，来自新泽西州的Parsippany的INTTRA公司的工业标准费用代码)中；这种执行被称为别名化。

别名化允许出票人和付款人仍然保持他们自己的代码列表以用于内部系统处理，同时利用行业建议的标准代码集来使多个出票人和付款人当中的无缝处理成为可能。此外，更不用提到使用常见标准代码集也使使用自动匹配的自动化发票验证成为可能。

一旦出票人或付款人已经完成把他们自己的费用代码别名化至标准代码的执行，他们就可以选择发送他们自己的内部费用代码或在入站发票(IFTFCC)或运费结算单(IFTCCA)EDIFACT消息中使用标准的费用代码集。

如果定义有别名，那么开发票门户可以在出站EDIFACT消息中发送出票人自己的费用代码的或付款人自己的费用代码。对于不具有别名的标准费用代码，开发票门户将发送标准费用代码。

自动匹配过程在比较发票和运费结算单时将总是使用标准费用代码。在入站EDIFACT消息中的由出票人和付款人发送的所有费用代码将在发送用于自动匹配之前首先被解释为标准费用代码。

2.缩减方法和过程

缩减常见费用代码使可以在出票人发送的发票和付款人发送的运费结算单之间进行不同地表示的各种相似的费用的多向匹配成为可能。费用代码缩减仅可以在所有的出票人和付款人费用代码已经被解释为标准费用代码之后进行。

缩减也意指费用行上的数字字段例如基于具有相同的值的关键字段(包括标准费用代码)的集合的数量和金额的总计。自动匹配提供两种方法或类型的缩减以允许付款人在表示他们的运费结算单中的行条目费用时的甚至更多的灵活性。根据选择的缩减方法，自动匹配将基于缩减方法定义的不同的关键字段进行求和。

两种缩减方法为：对于费用代码——当指定运费结算单中的费用行时所有的集装箱大小/类型被忽略并且不要求由付款人进行提供，并且对于费用代码和集装箱大小/类型——当指定运费结算单中的费用行时要求集装箱大小/类型由付款人进行提供。

以下的表格示出了费用行上的字段，且具有特定字段是在缩减期间用作关键词被使用还是用作正在被求和的字段的指示。

费用行字段	样本值	对于费用代码和	对于费用代码
				预付费/货到付款指示符	P或C	关键词	关键词
费用代码	101000	关键词	关键词
				集装箱大小类型代码	40HC	关键词	被忽略的
数量	5	总计	总计
				价格	100.00	关键词	关键词
发票货币	USD	关键词	关键词
				发票金额	500.00	总计	总计
汇率	1.34	关键词	关键词

仅当被缩减的费用行或唯一的费用行时，自动匹配可以用于处理。不能够被缩减的费用行将从自动匹配中被过滤并且被作为争议分离地单独提出。

选择通过缩减费用代码和集装箱大小/类型的付款人主要能够在他们的运费结算单中提供使自动匹配能够更精确地匹配涉及每个被船运的集装箱大小或类型的费用的更详细的费用行。

选择仅缩减费用代码的付款人不能够在他们的运费结算单中提供在特定的集装箱大小或类型的详细的费用。即使提供了集装箱大小/类型，自动匹配将在缩减期间忽略其。

3.缩减异常

存在其中自动匹配不能够恰当地缩减发票上或运费结算单上的费用的情况。这些费用行被称为不可缩减的费用。

由于发票或运费结算单而是不可缩减的费用的一部分的发票费用行将被作为“不可缩减的”矛盾提出并且必须进行手动地检查。

在某些情况下，自动匹配可能甚至由于不可缩减的费用而不能成功地执行。在这样的情况下，自动匹配将引发异常并且向付款人发送出发票。

以下是缩减方案的实例：

案例1：所选择的缩减方法是关于费用代码和集装箱大小/类型但是付款人提供的运费结算单具有至少一个不提供集装箱大小/类型的费用条目。

结果：自动匹配将不能够继续发票验证，这是因为集装箱大小/类型没有针对非总费用代码或非固定收费进行提供。

基本原理：自动匹配将不能够部分地缩减具有集装箱大小/类型的行条目且简单地忽略其的集装箱大小/类型尚未被提供的那些，因为这可以导致不可预测的并且不一致的自动匹配结果。

解决：或者在缩减方法是关于费用代码和集装箱大小/类型进行选择时具有为所有的费用行提供的集装箱大小/类型；或选择具有仅关于费用代码的缩减。

案例2：不能够缩减发票上或运费结算单上的费用行，使得具有唯一的费用代码集(用于仅缩减费用代码)或唯一的费用代码和集装箱大小/类型的唯一的集(用于缩减费用代码和集装箱大小/类型)。

结果：自动匹配将提出关于不可缩减的费用行的“不可缩减的”矛盾。该矛盾作为在出站COMDIS争议提交EDIFACT消息中被发送至付款人的自动匹配结果的一部分提出。自动匹配将仍然能够继续发票验证以用于其他的能够恰当地缩减的费用行。

基本原理：因为自动匹配通过基于费用代码(以及可能地集装箱大小/类型，这取决于所选择的缩减方法)链接发票和运费结算单而在发票和运费结算单之间验证费用行，所以非唯一的关键词的集合将导致不可预测的并且不一致的自动匹配结果。针对更多的关于验证费用行的信息，参见关于“通过费用代码匹配”的章节。

解决：理解自动匹配如何起作用以及出票人和付款人费用代码到标准代码的恰当映射将最小化不可缩减的费用的概率。选择缩减费用代码和集装箱大小/类型而不是仅费用代码也可以帮助增加已缩减的费用行的唯一性。

4.总费用代码和固定收费

出票人有时针对集装箱船运收费，该收费作为可以包括港口费用、报关、国内运输等等的总费用，以及实际的海运运费费用。代替分解船运集装箱必需的分别的附加费用，出票人将代替发出在之前与付款人商定的一个单一费用。

出票人有时也可以针对不直接地与任何集装箱船运相关联的固定收费进行收费，例如文件费或邮费。

自动匹配支持总费用和固定价格的概念并且提供允许出票人和付款人能够进行这样的类型的费用的自动匹配的标准费用代码(即101021“总海运运费”、609079“邮费”)。

总费用和固定收费具有独特的属性，并且由于它们的是出票人和付款人之间的预协定的费用或简单地固定金额费用的本质，有时信息例如价格、数量等等可以不由出票人提供在发票的费用行上提供。以下的表格列出了可以可选择地不在发票上或运费结算单上提供(如果费用是总费用或固定收费)的费用行条目。

费用行字段	样本值
		集装箱大小类型代码	40HC
数量	5
		测量单位代码	UNI
价格	100.00

在费用行缩减期间，如果可选择的费用行字段中的任意一个被提供用于总费用或固定收费，那么这些字段将被用作缩减关键词的一部分。

有关的是理解可选择的费用行字段如何针对发票和运费结算单二者中的总费用和固定收费进行处理以确保精确的缩减和自动匹配过程。如果没有一致地提供用于总费用和固定收费的可选择的字段，那么可以具有其中自动匹配将不能够恰当地缩减费用行的情况。

总费用和固定收费必须在入站发票和运费结算单EDIFACT消息上明确地指示。这在运输费用/价格计算(TCC)片段中使用费用类型指示符“AI”用于总费用和“FF”用于固定收费而进行。如果没有提供指示符，那么自动匹配将进行假设费用代码是非总费用或非固定收费，即使费用代码本身被映射至INTTRA标准费用代码(即101021“总海运运费”)。以下是入站INTTRA发票(IFTFCC)和运费结算单(IFTCCA)EDIFACT消息的实例，其示出了总费用和固定收费指示符。

如果费用行涉及总费用或固定收费的话，INTTRA还将明确地把“AI”和“FF”费用类型指示符发送至付款人。以下是出站INTTRA发票(IFTFCC)EDIFACT消息的实例，其示出了总费用和固定收费指示符。

以下适用于总费用或固定收费：

1.当将总费用或固定费用用于费用行时始终恰当地指定费用类型指示符是重要的。使用总费用或固定收费费用代码而没有指示符意味着费用代码本身正在被用于正常的费用(即非总费用和非固定收费)。

2.建议不将被用作总费用或固定收费的相同的费用代码用于正常的费用(非总费用和非固定收费)，因为这可以导致不可预测的自动匹配结果或导致缩减异常。

3.发票/贷项清单含有仅非预期的费用或非预期的费用和正常的费用的混合。

在某些情况下，发票和贷项清单仅可以含有非预期的费用或非预期的费用和正常的费用的混合。自动匹配系统可以尝试通过忽略非预期的费用来处理发票/贷项清单。在其他的情况下，自动匹配系统可以针对关于出票人的信息的存储信息和对于该出票人特定的代码而尝试查阅那些非预期的费用。自动匹配系统也可以针对其他的出票人的信息而尝试检查非预期的费用。如果没有找到非预期的费用的解决，那么发票/贷项清单被确定为不可解决的并且被发送至付款人以用于手动处理。

III.争议解决区间

发票验证全部是关于出票人的发票上的、基于付款人预期的批准或争议费用和条目。为此，付款人将具有某些规则或条件集，他们通过其来确保出票人的发票精确地匹配他们基于他们的船运记录而具有的内容，或至少在他们乐于支付的某个阈值内。如果具有在发票上的不匹配付款人的记录的条目，那么他们将提出这些作为矛盾(或争议)并且潜在地把某些支持信息提供给出票人。出票人进而将需要研究并且潜在地重新发出新的发票或提供贷项凭单以改正任何错误。

自动匹配解决方案以相似的方式起作用，由此付款人定义业务规则以使发票与运费结算单的自动匹配成为可能。这些业务规则允许不满足付款人的最小要求的发票条目或费用的自动化检查。还通过自动匹配使用出站COMDIS争议提交和/或IFTFCC发票EDIFACT消息将任何自动匹配结果传送至付款人。

A.验证/匹配发票

通过其发生验证/匹配的过程是通过业务规则的使用进行的。

1.业务规则

自动匹配业务规则可以被定义为检查费用行条目(即价格、金额等等)以及发票标头条目例如运输细节(即船舶、航程、启航日期等等)。具有各个对付款人可用的以根据他们的发票验证实践和要求来界定不同的业务规则的发票字段。

即使各个付款人具有同一个出票人，他们也具有不同的发票验证要求。自动匹配具有定义每个出票人-付款人组合的唯一的业务规则集的灵活性。这种特征使付款人能够具有用于出票人1的一个业务规则集和用于出票人2的另一个完全不同的业务规则集。

a)业务规则驱动的自动匹配

自动匹配引擎基于在系统中预定义的业务规则验证发票条目。不具有业务规则的发票字段或费用将被引擎跳过，因为这些将被认为是对付款人的验证过程非重要的。同样地，如果正在检查的字段不具有在发票上或运费结算单或二者上的值(也被称为不足够的信息)，那么将跳过已定义的业务规则。

如果引擎遇到由此所有的已定义的业务规则由于不足够的信息而不能够被执行的情况，那么系统将为付款人引发异常，告知他们对于进行自动匹配数据是不足够的。该异常作为在出站IFTFCC发票EDIFACT消息中发送至付款人的自动匹配结果的一部分而提出。

在自动匹配中定义的每个业务规则独立于彼此。系统将基于目前正在被执行的规则提出矛盾。如果具有多个已定义的业务规则，那么每一个将单独地提出其自己的矛盾。业务规则默认使用“精确的匹配”比较，除非另有指示。

b)字母型和数字型比较规则

自动匹配可以验证具有类型为字母型字符或数字型数字的发票字段或费用。字母型字符字段的实例是：合同号码、地点代码、集装箱号码、和货币代码。数字型数字的实例是：总税金额、集装箱的数目、数量、和价格

以下的规则在比较字母型字符字段时被使用：

·不分大小写——在大写字母的(大写)和小写字母的(小写)字母之间比较不产生任何差异。举个例子：“AbC”当与“aBc”比较时将被当做相等的。

·空格去除——在任何比较发生之前，任何前导的或结尾的空白和空白行将被除去。举个例子：“ABC”当与“ABC”比较时将当作相等的。

以下的规则在比较数字型数字字段时被使用：

·8小数位的——具有小数的数字型数字将最多比较至最大8小数位的位置。例子：1.123456789当与1.12345679比较时将被当作相等的，因为1.123456789将被四舍五入至1.12345679

四舍五入——小数位的四舍五入将合规“四舍五入远离零的半边”规则。以下的表格示出了正的和负的数字型数字当被四舍五入至8小数位时的某些实例：

最初的值(正号)	被四舍五入至8小数位	最初的值(正号)	被四舍五入至8小数位
				1.123456784	1.12345678	-1.123456784	-1.12345678
1.123456775	1.12345678	-1.123456775	-1.12345678
				1.123456785	1.12345679	-1.123456785	-1.12345679
1.123456786	1.12345679	-1.123456786	-1.12345679

c)日期和时间比较规则

自动匹配还可以验证具有日期和时间类型的发票字段。目前，仅具有日期和时间类型的一个字段，其是实际的启航日期字段。日期和时间字段可以被出票人和付款人以两种不同的格式进行发送：

格式	例子	备注
			CCYYMMDD	20101224	2010年12月24日
CCYYMMDDHHMM	201012241945	2010年12月24日

以下的规则在比较日期和时间字段时被使用：

·相同的格式——日期和时间字段仅可以在发票和运费结算单二者都使用同一个格式时被比较。举个例子：20101224和201012241945将被当作不相等的。

·字母型比较——日期和时间字段被当作字母型字符并且将使用用于字母型字符比较的规则进行比较

d)列表值比较规则

列表值是指具有多于一个值的发票或运费结算单条目(或字段)。列表值可以发生，这是因为发票或运费结算单字段允许多个值(即集装箱号码)。

自动匹配允许比较发票和运费结算单之间的列表值的灵活性。以下的规则在比较具有列表值的字段时被使用：

·不同的值——在被复制的列表值内的仅一个值将被用于比较。举个例子：如果列表值含有“ABC、ABC、DEF”，那么自动匹配将把列表简化为“ABC、DEF”。

·发票完全匹配——所有的来自发票的列表值的各个值必须匹配来自运费结算单的列表值的相应值。然而，所有的来自运费结算单的列表值的各个值不需要必需匹配来自发票的列表值的相应值。

发票	运费结算单	结果
			ABC、XYZ、123	ABC、XYZ、123	好
ABC、XYZ、123	ABC、XYZ、123、789	好
			ABC、XYZ、123	ABC、XYZ、789	矛盾

e)使用阈值的比较

当验证发票时，付款人可以不总是必需针对100％精确度进行比较。因为可以具有在发票上的付款人不能够精确地预测的条目(例如汇率)或某些可以潜在地在集装箱船运的过程期间改变的已知费用，所以付款人需要具有决定他或她乐于接受或支付多少差异的灵活性。自动匹配通过提供关于数字型数字的阈值比较来允许这种灵活性。

自动匹配允许付款人定义以下的阈值业务规则的类型：

·大于最初的值x％——正在被比较的发票字段上的值不能够大于运费结算单上的最初的值加上所设置的百分之x阈值。百分之x从运费结算单的值计算出并且该结果在比较之前被四舍五入至8小数位(见“字母型和数字型比较规则”已得到更多的关于8小数位的四舍五入的信息)。

·大于最初的值x——正在被比较的发票字段上的值不能够大于运费结算单上的最初的值加上所设置的x值阈值。x值在比较之前被加上运费结算单的值。

·小于最初的值x％——正在被比较的发票字段上的值不能够小于运费结算单上的最初的值减去所设置的百分之x阈值。百分之x从运费结算单的值计算出并且该结果在比较之前被四舍五入至8小数位(见“字母型和数字型比较规则”以得到更多的关于8小数位的四舍五入的信息)。

·小于最初的值x——正在被比较的发票字段上的值不能够小于运费结算单上的最初的值减去所设置的x值阈值。x值在比较之前从运费结算单的值减去。

f)操作汇率比较

自动匹配向付款人提供在发票和运费结算单之间追踪或比较汇率的灵活性。可以在EDIFACT消息中的标头或费用行水平处提供汇率。以下是入站发票(IFTFCC)和运费结算单(IFTCCA)EDIFACT消息的实例，其使用自由文本(FTX)片段来表示汇率。

因为汇率被设置为自由文本，所以以下是某些将在自动匹配过程中帮助的指南：

·始终将FromCurrencyRate设置为1，因为当在发票和运费结算单之间比较汇率时仅ToCurrencyRate被使用。

·汇率(或ToCurrencyRate)高至最大6小数位。

·汇率应当始终是正的非零数字型数字。

·汇率方向应当在提供在费用行水平处的FromCurrencyCode和ToCurrencyCode时是一致的。举个例子：具有1:USD:1.306021:SGD的费用行相对于另一个具有1:SGD:0.765684:USD的费用行将不进行恰当地缩减。

·具有不同的汇率的费用行将不被缩减，因为汇率是在缩减期间被使用的关键的字段中的一个。例子：具有1:USD:1.306021:SGD的费用行相对于另一个具有1:USD:1.306022:SGD的费用行将被认为是两个分别的行，即使所有的其他的关键词具有相同的值。

·汇率比较将仅当在发票和运费结算单之间的货币对是相同的时发生。举个例子：如果运费结算单具有含1:USD:1.306020:SGD的费用行同时匹配的发票费用行具有1:USD:0.718614:EUR，那么自动匹配将不发生。

·如果自动匹配检测到在匹配的发票费用行上的货币对是相同的货币对但是在相反方向上，那么其将自动地反转在运费结算单上的汇率。所得到的被反转的汇率的四舍五入将是高至6小数位。汇率的反转仅在费用行已经被成功地缩减之后发生。举个例子：运费结算单具有含1:USD:1.306020:SGD的费用行同时匹配的发票费用行具有1:SGD:0.765684:USD，运费结算单的汇率将被转换为：1:SGD:0.765685:USD。

·当比较在发票和运费结算单之间的汇率时，建议使用阈值比较并且避免精确的匹配。

以下的表格提供关于汇率比较的某些方案：

g)对特定方的变化

有时，可能具有提供对特定方的变化形式以验证和匹配操作的需要。在这种情况下，自动匹配过程可以从其的在上文概括的标准途径变化并且，通过识别所涉及的各方，应用这些对特定方的变化。

2.自动匹配发票标头条目

自动匹配提供验证在标头上的发票条目或字段的能力。在标头上的条目仅意指这些字段不关于实际的费用行，举个例子：合同号码、集装箱号码、总净金额等等。以下的表格列出了可以被自动匹配的标头字段以及在这些字段上的另外的信息，例如：入站发票(IFTFCC)和运费结算单(IFTFCA)EDIFACT消息位置、数据类型、字段是否可以具有阈值比较或列表值。

a)通过标头字段匹配

自动匹配通过将标头字段名称用作匹配关键词来验证标头条目并且接着比较关于该字段的在发票和运费结算单之间的所提供的实际的值。

以下的规则在自动匹配标头字段时被使用：

1.业务规则必须在自动匹配可以验证标头字段的值之前针对标头字段进行定义。

2.若在发票和运费结算单二者中都提供了值，那么自动匹配将仅执行针对标头字段定义的业务规则。如果文件(发票或运费结算单)中的至少一个没有提供任何值，那么业务规则将被跳过。

b)匹配专用标头字段

有害的指示符和非活动的冷藏船指示符二者都被认为是专用标头字段。这些字段很大地取决于其他的标头字段并且当进行自动匹配时要求专用规则。有害的指示符字段取决于HS代码，并且相应地，非活动的冷藏货船指示符取决于集装箱号码。以下的规则在自动匹配专用标头字段时被使用：

1.业务规则必须在发票自动匹配可以验证专用标头字段的值之前针对该专用标头字段济宁定义(见关于“定义标头规则”的章节3.6.1)。

2.专用标头字段仅可以在其依赖的标头字段的值在发票和运费结算单之间匹配时被验证。

3.自动匹配费用行条目

自动匹配发票验证的核心全部关于检查费用行。自动匹配提供验证在特定的费用行上的不同的条目或字段的能力，举个例子：数量、价格、开发票金额等等。以下的表格列出了可以被自动匹配的费用行字段以及在这些字段上的另外的信息，例如：入站发票(IFTFCC)和运费结算单(IFTFCA)EDIFACT消息位置、数据类型、和字段是否可以具有阈值比较。

a)通过费用代码或费用代码和其他的信息(例如集装箱大小类型)匹配

自动匹配通过使用以下作为关键词来验证费用行条目：预付费/货到付款指示符、费用代码、可能的集装箱大小/类型、和费用行字段。取决于付款人所选择的缩减方法，集装箱大小/类型可以或可以不是关键词的一部分。

费用行字段	样本值	通过费用代码和集装箱大小/类型	通过费用代码
				预付费/货到付款指示符	P或C	关键词	关键词
费用代码	101000	关键词	关键词
				集装箱大小类型代码	40HC	关键词	被忽略的
费用行字段	数量	关键词	关键词

费用行水平业务规则使用费用代码+费用行字段名称的组合进行定义。以下的规则在自动匹配费用行字段时被使用：

1.业务规则必须在自动匹配可以验证费用代码+费用行字段的值之前针对其进行定义。

2.自动匹配将仅执行针对费用代码+费用行字段进行定义的业务规则，其假设：

a.能够发现匹配在发票和运费结算单二者上恰当地缩减的费用行。

b.在发票和运费结算单二者中提供关于费用行字段的值。

注意：如果以上的条件中的至少一个不被满足，那么业务规则将被跳过。

以下的表格提供关于自动匹配费用行字段的某些方案。除非另有具体地指示，否则所提供的方案使用成功的缩减已经发生的假设。为了简单性，使用以下的格式指示费用行实例：

·对于发票：<预付费/货到付款指示符>、<费用代码>、<关于数量的费用行字段值>

·对于运费结算单：<预付费/货到付款指示符>、<费用代码>、<关于数量的费用行字段值>

b)用于任何费用代码的业务规则

使用费用代码+费用行字段的组合定义费用行业务规则允许发票上和运费结算单上的费用行条目的详细的自动匹配。然而，可能存在其中要求业务规则用于所有类型的费用代码的情况。

自动匹配提供定义针对所有类型的费用代码应用的业务规则的灵活性。这种特征允许付款人设置不需要是特定于具体费用的业务规则。这些类型的业务规则作为通配符或包罗万象的规则起作用以确保这样的规则被执行，而与发票上显现的费用的类型无关。

这些类型的费用行水平业务规则使用“所有的费用代码”指示符+费用行字段名称的组合进行定义。以下的规则在把费用行字段与“所有的费用代码”业务规则自动匹配时被使用：

1.所有的支配针对特定的费用代码定义的业务规则的规则也适用于“所有的费用代码”业务规则。

2.针对特定的费用代码+费用行字段定义的业务规则将优先于针对“所有的费用代码”+费用行字段定义的业务规则。这意指如果自动匹配遇到具有精确的费用代码的费用行，那么其将执行对于费用代码和费用行字段特定的业务规则。将针对该费用行跳过用于同一个费用行字段的“所有的费用代码”业务规则。

c)检测缺少的和另外的费用

在海运货运行业中开发票是一个复杂的过程；各个步骤和程序涉及不同的部门和不接合的系统，最经常地要求手动介入，其涉及到最终生产或验证单一的发票。在沿着这个复杂的过程的某处，错误可能发生，导致费用被不计入发票或被偶然地加入至其上。

自动匹配具有通过自动地检查在发票或运费结算单的任一个上不具有相应的配对的费用行来检测这样的错误的能力。仅存在于发票上但是不存在于运费结算单上的费用行将作为“另外的费用”矛盾被提出，而仅存在于运费结算单上但是不存在于发票上的费用行将作为“缺少的费用”矛盾被提出。

以下的规则在检查另外的或缺少的费用时被使用：

1.所有的来自出口发票(预付费)的费用行将相对于所有的来自已链接的出口运费结算单(预付费和货到付款)的费用行进行检查。

2.所有的来自进口发票(货到付款)的费用行将仅相对于来自已链接的进口运费结算单或出口运费结算单中的任一个的货到付款费用进行检查。

3.根据所选择的缩减方法，自动匹配将使用费用代码或仅在发票或运费结算单上存在的费用代码和集装箱大小/类型配对来扫描费用行。

4.被检测到的作为另外的和缺少的的费用将不再具有针对它们执行的业务规则，因为它们不具有相对于其验证的匹配的费用行。

注意：自动匹配独立于系统内的业务规则设置进行另外的和缺少的费用行检测。然而，如果不具有用于出票人-付款人组合的业务规则设置，那么这将引发自动匹配异常并且付款人必须手动地检查发票。

d)出口发票费用的方向检查

自动匹配的独特的特征中的一个是其的检测在出口发票上的实际上应当意指作为进口发票上的货到付款费用的已预付费的费用的能力。这还可以间接地意指检查付款人不确定其应当在出口发票处理期间作为预付费还是货到付款被支付的费用。这种特征被称为方向检查。

以下的规则在进行关于出口发票的方向检查时被使用：

1.方向检查仅在出口发票上进行。

2.方向检查仅在付款人发送含有预付费的和货到付款费用二者的出口运费结算单时是可能的。

3.根据付款人所选择的缩减方法，每个来自出口发票的预付费的费用代码或费用代码和集装箱大小/类型配对将相对于运费结算单进行检查：

a.如果具有来自运费结算单的匹配的预付费的费用行，那么在发票上的费用行被认为是在正确的费用方向上。

b.如果不具有匹配的预付费的费用行，而是代替具有来自运费结算单的匹配的货到付款费用行，那么在发票上的费用行被认为是在错误的费用方向上。

4.在出口发票上的被认为是在错误的方向上的预付费的费用行将作为“不正确的预付费/货到付款指示符”矛盾被提出

5.业务规则仍然将针对在出口发票上的已经被提出作为具有错误的方向的预付费的费用行执行。这些预付费的费用行将相对于它们的来自出口运费结算单的相应的货到付款费用行进行检查。还将适当地提出任何另外的来源于业务规则的矛盾。

e)不可缩减的费用

在某些情况下，费用不是可缩减的。在这些情况下，发票被发送出站并且要求手动处理。

f)要求手动处理的电子邮件和EDIFACT消息

当要求手动处理时，电子邮件和EDIFACT消息可以被发送至各个用户。电子邮件可以指示没有自动匹配是可能的并且仅将实施手动处理。或可以邀请用户再提交发票和运费结算单以解决任何不可缩减的费用。

C.争议发票和解决争议

创建自动匹配的主要目的是实现海运运费发票的自动化检查和争议。手动地比较和检查各个发票和费用行的冗长的并且复杂的任务现在可以简单地通过定义业务规则而容易地完成。从长远来看，最终的目标是，通过经由分析从自动匹配执行采集的各个统计数字减少错误和过程改进，最终简单化开发票和争议解决。

据此，重要的是理解自动匹配过程以及其如何着手产生和解决争议。为什么在某些情况下自动匹配不能够继续自动化发票验证和要求为什么手动外部干以及应当如何操作这样的情况。

1.产生争议和矛盾

通常，矛盾基于付款人已经在自动匹配系统中设置的业务规则而产生。

然而，可以提出某些矛盾，但这不作为业务规则的直接的结果，而是因为自动匹配的处理或当另外的检查作为自动匹配执行的一部分进行时。

也可以在不同的水平提出矛盾：发票标头水平、以及在费用行条目水平处。

自动匹配被设计为捕获关于发票提出的每个单一的矛盾并且使用出站COMDIS争议提交EDIFACT消息向出票人和付款人发送出这些细节。因为具有仅一个单一的向外以捕获所有的这些信息的COMDIS争议提交消息，所以根据为什么发票被争议的总体原因区分各个条目矛盾是重要的。

对于INTTRA的途径，各个条目不匹配被称为“矛盾”，而总体的原因则被称为“争议”。一个发票可以具有多个矛盾但是仅可以具有一个总体的争议。自动匹配将使用最普遍的“矛盾”作为总体的争议。

以下是支配自动匹配如何产生各个条目矛盾以及其如何确定哪个矛盾应当是总体的争议的规则：

1.没有矛盾或争议将被提出，如果自动匹配遇到处理例外的话，例如：

o发票或运费结算单文件处理或字段验证失败

o遇到关键的缩减异常

o没有针对匹配的出票人和付款人配对设置业务规则

o其他的内部自动匹配处理故障

自动匹配将向付款人(通过出站IFTFCC EDIFACT消息)发送出发票，指示已经发生自动匹配异常。

2.标头水平矛盾：对于每个不满足至少一个业务规则的标头字段，将提出单独的矛盾。

3.费用行矛盾：

a.对于每个不满足至少一个业务规则的费用行字段，将提出单独的矛盾(见关于“自动匹配费用行条目”的章节2.3.3)。

b.费用行可以含有个矛盾，除了：

i.被提出具有“不可缩减的”矛盾的费用行不再能够具有其他的被提出的矛盾(见关于“缩减异常案例2”的章节2.2.3)。

ii.被提出具有“另外的费用”或“缺少的费用”矛盾的费用行不再能够具有其他的被提出的矛盾(见关于“检测缺少的和另外的费用”的章节)。

c.被提出具有作为方向检查的结果的“不正确的预付费/货到付款指示符”矛盾的费用行仍然能够具有其他的相对于其被提出的矛盾(见关于“出口发票费用的方向检查”的章节)。

4.确定总体的争议(基于最普遍的矛盾)：

a.如果至少一个矛盾代码被出票人别名化：

i.具有最高的发生率的被别名化的矛盾代码将是总体的争议。

ii.如果具有两个或多于两个具有最高的发生率的被别名化的矛盾代码，那么总体的争议将基于具有最高的业务规则字段优先级的被别名化的矛盾代码进行选择。

b.如果不具有被出票人别名化的矛盾代码：

i.具有最高的发生率的INTTRA矛盾代码将是总体的争议。

ii.如果具有两个或多于两个具有最高的发生率的INTTRA矛盾代码，那么总体的争议将基于具有最高的业务规则字段优先级的INTTRA矛盾代码进行选择。

c.具有最高的优先级的业务规则字段(在以下的表格中的最低的数字)将在断开最高的被别名化的矛盾代码或INTTRA矛盾代码之间的联系中使用：

费用行字段	优先级	费用行字段	优先级
				价格	1	开发票金额	4
数量	2	汇率	5
				开发票货币	3	支付金额	6

标头字段	优先级	标头字段	优先级
				合同号码	51	收货地点	61
合同类型	52	交货地点	62
				关于被指定的账户/客户的合同	53	装货港口	63
报价单号	54	卸货港口	64
				总净金额	55	实际的启航日期	65
集装箱的数目	56	船舶名称	66
				集装箱号码	57	航次	67
总税金额	58	HS代码	68
				汇率	59	有害的指示符	69
支付货币	60	非活动的冷藏货船指示符	70

d.不被与任何业务规则字段(即“不可缩减的”、“另外的费用”、“缺少的费用”、“不正确的预付费/货到付款指示符”)相关的矛盾代码不具有指派的优先级并且将被认为具有当断开最高的被别名化的矛盾代码或INTTRA矛盾代码之间的联系时的最低的优先级。

e.从ALL-DIFF比较提出的矛盾将不在确定总体的争议中使用

以下的实例示出如何提出矛盾以及自动匹配如何确定总体的争议：

注意：如果出票人不提供针对矛盾代码的别名，那么以上的同一个实例的总体的争议将是在INTTRA矛盾代码之间最普遍的DSC-8015-不正确的发票货币金额。

操作“要求手动处理”(MPR)

自动匹配产品的强度在于其自动地验证发票，并且如果其发现任何不一致相应地提出争议而完全不需任何人工介入的能力。然而，如同任何自动化系统，具有关于如其能够多远地完全地自动化整个的发票验证和争议过程的某些限制。

存在其中自动匹配不能够继续其的自动化过程并且因此要求付款人手动地检查或处理发票的各种情况。这样的情况被称为“要求手动处理”或MPR。

以下是支配自动匹配如何在要求手动处理(MPR)情况中操作发票的规则：

1.进入MPR中的发票将永远不被自动匹配处理并且因此将永远不具有任何相对于它们而提出的争议。

2.每当发票进入MPR中时，需要向付款人发送出出站IFTFCC发票EDIFACT消息以便于后续的手动处理。还需要向付款人发送出关于该发票(如果是可用的)的相关的完全链接的贷项清单(出站IFTFCC EDIFACT消息)。

3.如果出口发票在之前是MPR，那么任何后续的相关的出口发票也将进入MPR中。同样地，如果进口发票在之前是MPR，那么任何后续的相关的进口发票也将进入MPR中。

注意：如果自动匹配尝试验证任何后续的相关的发票并且自动地提出相应的争议，那么在为什么后续的发票被迫使进入MPR中的背后的基本原理是因为付款人或出票人可能已经开始某些可以潜在地导致不一致或混乱的手动过程。强迫后续的发票也进入MPR中将防止自动匹配执行。

理解发票和运费结算单状态

无论何时自动匹配执行以验证发票，其需要保持对各个条件的追踪以确保一致的结果并且避免发送出可能困扰出票人和付款人二者的错误的信息。自动匹配检查的许多条件中的一个是发票和运费结算单状态；这些状态使自动匹配能够精确地确定哪个发票或运费结算单能够或不能够被用于其的执行。

发票状态

运费结算单状态

注意：对于具有预付费的和货到付款费用的出口运费结算单：将分别追踪被争议的、可用的和被使用的状态；即，预付费状态将与货到付款状态分离。这允许出口运费结算单被自动匹配用于验证出口和进口发票二者的灵活性

用于自动匹配的相关发票

检查发票是冗长的任务，特别是在海运货运行业中。有时，付款人可以需要在发票最终是正确的之前检查发票几次。每次发票被改正，付款人需要再检查新的发票以确保所有的错误被恰当地改正，并且没有新的错误由于改正而被制造。

被组织的应付账款职员将具有某个形式的系统以保持对在他或她负责的一堆发票当中的一系列相关的发票的追踪。这将帮助确保过去的错误的发票被恰当地发出贷项清单并且新的已改正的发票可以通过参考之前的被用于争议错误的发票的文件(例如发票应计项目)而容易地进行再检查。这种追踪机制有时也可以对统计目的有用或对跟踪回可以以某种方式导致出票人和付款人之间的误解的之前的争议有用。

以相同的方式，自动匹配也需要在其着手关于其的发票验证过程时保持对一系列相关的发票的追踪。自动匹配利用出票人公司ID+付款人公司ID+进口/出口指示符+提货单参考编号字段以把相关的发票链接在一起。

出口发票将永远不与进口发票混淆(对于同一个出票人-付款人对)，即使它们可以具有相同的提货单参考编号，如它们指代同一个船运但是在相反的贸易方向上。

自动匹配发票验证过程

发票验证是涉及一系列的可重复的步骤的过程。不同的出票人和付款人可以具有关于它们如何着手检查发票以及管理或解决它们之间的矛盾的不同的途径。在高层处，这些不同的途径可以被归纳为两个不同的步骤：检查和争议，以及随后的争议解决。

检查和争议涉及出票人发送发票以及付款人相对于他们的内部应计项目对其交叉检查以查看是否具有任何违反他们预期的内容的矛盾。如果具有矛盾；付款人将提出相对于发票的争议并且出票人将需要交叉检查争议是否是有效的。自然地，如果不具有争议，那么付款人被预期支付发票。

争议解决涉及出票人回复付款人的争议，以及付款人反过来采取合适的行动，作为出票人的回复的结果。如果出票人承认具有开发票错误，那么他们将取消错误的发票并且再发出具有合适的改正的新的发票。付款人将交叉检查新的发票以确保正确地进行所有的合适的改变。相反地，如果出票人相信开发票是正确的并且付款人的争议是无效的，那么付款人将需要再检查他们的应计项目，或有时甚至提及他们的最初的协议，以再检查发票。可以重复多次争议解决，直到双方都最终地一致同意正确的发票(或应计项目)。

以相同的方式，自动匹配也在其着手自动地验证发票时依从同样的两个步骤途径。在自动匹配术语中，检查和争议步骤被称为“结算时期”，而争议解决步骤被称为“争议解决时期”。

结算时期

结算时期的目的是允许付款人有足够的时间发送运费结算单以允许自动化发票验证发生。理想地，付款人将在出票人发送发票之前已经发送他们的运费结算单。

以下的规则在结算时期处理期间被自动匹配使用：

1.结算时期等待时间持续时间可以被分别地针对进口和出口发票二者配置(见章节配置结算时期)。

2.结算时期在开发票门户成功地处理来自出票人的具有订购了自动匹配处理的付款人的发票时开始。如果在自动匹配执行之前任何被发送，那么结算时期将被唯一地联系于发票和其的后续的相关的发票中的任何(见关于用于自动匹配的相关发票的章节)。

a.如果尚未针对该结算时期执行自动匹配，则相关的发票的每个组将在任何给定的时间点仅具有1个结算时期，

b.如果一个结算时期已经存在，则被发送的后续的相关的发票将永远不开始结算时期

c.不能够与任何现有的发票相关的发票将开始其自己的结算时期

3.已经被取消(由于完全链接的贷项清单)的发票将永远不开始结算时期。这仅当开发票门户在处理正在被取消的相应的发票之前完成其的对于完全链接的贷项清单的处理(由于并行性)时发生。

4.具有其的在MPR中的之前的相关的发票的发票将永远不开始结算时期。这也暗示没有自动匹配执行将发生(见章节操作“要求手动处理” (MPR))。

5.在结算时期内的任何时间：

a.出票人具有通过使用完全链接的贷项清单取消其并且再发出新的发票改正他们的发票的选项。

b.付款人具有通过直接地代替运费结算单或取消并且再发出新的运费结算单来改正他们的运费结算单的选项。

6.一旦结算时期流逝，那么自动匹配将检查是否具有用于其的已链接的发票和运费结算单集以开始自动化发票验证。自动匹配将仅当以下的条件被满足时执行：

a.在相关的发票的整个的组中仅具有1个活动的发票(发票状态＝新的)并且活动的发票必须是该组中的最新的发票。这暗示所有的之前的相关的发票必须已经使用完全链接的贷项清单被成功地取消并且最新的活动的发票不在MPR状态中。

b.仅具有1个活动的运费结算单(运费结算单状态＝新的、已代替的、可用的、或与可以把其设置为可用的完全链接的贷项清单争议的)。这暗示活动的运费结算单必须是可以被链接的最新的运费结算单。

以上的两个点还暗示自动匹配将在其进行自动化发票验证时始终使用最新文件。

7.一旦结算时期流逝并且具有1个活动的发票但是自动匹配不能够发现1个活动的运费结算单，那么发票将进入MPR中。

a.如果运费结算单不能够被发现或已链接的运费结算单不能够被使用(运费结算单状态＝被取消的、执行、被使用的、期满的或被争议的但是没有可以把其设置为可用的完全链接的贷项清单)——电子邮件通知将被发送至付款人，告诉他们不能够发现已链接的运费结算单

该信息将在出站IFTFCC发票EDIFACT消息上进行指示，因为运费结算单不针对发票存在

b.如果多于1个活动的运费结算单被发现——没有电子邮件通知将被发送；然而，出站IFTFCC发票EDIFACT消息将指示针对该发票发现具有多于1个运费结算单

8.一旦结算时期流逝并且自动匹配不能够发现1个最新的活动的发票，那么与是否具有1个活动的运费结算单无关，以下可以发生：

a.如果所有的相关的发票被取消——没有要求自动化验证，因为不具有待验证的发票。

b.多于1个活动的发票——自动匹配将提出例外并且在出站IFTFCC发票EDIFACT消息中声明自动匹配由于不足够的记载不能够执行(见关于自动匹配异常的章节)。

c.活动的发票不是最新的——自动匹配将引发异常并且在出站IFTFCC发票EDIFACT消息中声明自动匹配由于不足够的记载不能够执行(见关于自动匹配异常的章节)。

d.发票在INTTRAi-Act上受到争议——自动匹配将引发异常并且在出站IFTFCC发票EDIFACT消息中声明发票在自动匹配之前已经被争议(见关于自动匹配异常和手动争议相对于自动匹配的章节)。

e.最新的活动的发票在MPR中——自动匹配将引发异常并且在出站IFTFCC发票EDIFACT消息中声明手动处理已经针对该发票集开始(见关于自动匹配异常和操作“要求手动处理”(MPR)的章节)。

9.一旦自动匹配执行，那么其可以导致：

a.争议被提出——这是自动匹配发现发票和运费结算单之间的矛盾的结果。出站COMDIS争议提交EDIFACT消息将被发送至出票人(以及可选择地至付款人)。给付款人的出站IFTFCC发票EDIFACT消息在这种情况下将被拿回并且不进行发送(见关于提出争议和拿回发票的章节)。

b.“完美的匹配”——这是自动匹配没有发现发票和运费结算单之间的任何矛盾的结果。出站IFTFCC发票EDIFACT消息将被发送至付款人。

c.MPR发票——这是自动匹配由于各种阻止其能够成功地完成的原因提出异常的结果。出站IFTFCC发票EDIFACT消息将被发送至付款人，指示其导致MPR。这暗示后续的相关的发票也将不能够执行自动匹配(见关于操作“要求手动处理”(MPR)和自动匹配异常的章节)。也可以具有出票人的发票是缺乏的使得其被返回至出票人以进行改正而不转发至付款人的情况。

10.如果自动匹配成功地完成并且提出争议，这将开始争议解决时期。

11.关于某个特别的方案，自动匹配可能不能够提出争议，即使其发现矛盾，并且能够成功地完成，而不引发任何异常。这仅当正好先前的相关的发票是“完美的匹配”并且之前的相关的发票已经达到最大自动匹配争议循环时发生(见关于限制自动匹配争议循环的章节)，并且被验证通过自动匹配的当前的发票具有矛盾。在这样的条件下，没有出站COMDIS争议提交EDIFACT消息将被发送至出票人并且发票将进入MPR中，出站IFTFCC发票EDIFACT消息被发送至付款人，指示发票/运费结算单被多于所设置的限制地自动匹配(见关于自动匹配异常的章节)。

a)提出争议和拿回发票

自动匹配以每当争议作为自动化验证的结果被提出使得出站IFTFCC发票EDIFACT消息被阻止(并且不被发送至付款人)的方式设计。这防止付款人的自己的系统或过程继续任何下游发票处理，无论何时具有突出的并且未解决的自动化争议。

如果自动化验证已经成功地完成而没有矛盾或导致异常的自动匹配被提出，那么出站IFTFCC发票EDIFACT消息将被自动地发送出至付款人以进行进一步的下游处理。

无论何时出站IFTFCC发票EDIFACT消息被阻止，其将仅在以下的情况下向付款人发送出：

·自动匹配在争议解决时期期间再验证发票并且导致：

o“完美的匹配”——无论何时自动匹配未发现任何矛盾，发票始终被释放至付款人。

o自动匹配异常——无论何时自动匹配遇到要求手动处理的异常(见关于操作“要求手动处理”(MPR)和自动匹配异常的章节)，发票始终被释放至付款人。

o达到最大自动匹配争议循环——无论何时相关的发票集已经达到最大自动匹配争议循环极限，发票始终被释放至付款人。这意指如果自动匹配在再验证过程期间发现矛盾，则其不再能够提出任何进一步的争议(见关于限制自动匹配争议循环的章节)。

·手动争议通过覆写当前的自动化争议过程的开发票门户的网站界面被提出。在针对特定的发票提出手动争议的任意时间点，整个相关的发票集被认为是在MPR中并且将永远不被自动匹配处理(见关于手动争议相对于自动匹配的章节)。

注意：

1.无论何时自动匹配能够成功地提出争议，出站COMDIS争议提交EDIFACT消息将始终被发送至出票人(以及可选择地至付款人)。

2.出站IFTFCC发票EDIFACT消息的阻止不影响用于操作发票的网站平台如何在线呈现发票。一旦其已经被开发票门户成功地处理，则将仍然在网站上呈现发票，而与任何自动匹配过程无关。

b)争议解决时期和检查时间区间

争议解决时期的目的是允许出票人再检查被争议的发票并且如果需要的话采取必需的改正性动作。如果出票人拒绝他们的争议的话，其还允许付款人检查他们的应计项目，并且如果必要的话相应地调整他们的运费结算单。

以下的规则在争议解决时期处理期间被自动匹配使用：

1.争议解决时期等待时间持续时间被配置为用于进口和出口发票二者的单一的共用的等待时间(见章节配置争议解决时期)。

2.当自动匹配已经作为自动化发票验证的结果成功地提出争议时争议解决时期开始。如果在自动匹配再次地执行之前任何被发送的话，争议解决时期将被唯一地联系于被争议的发票和其的后续的相关的发票中的任意一个(见关于用于自动匹配的相关发票的章节)。

a.如果自动匹配尚未针对该争议解决时期被执行，则相关的发票的每个组将在任何给定的时间点仅具有1个争议解决时期

b.即使一个争议解决时期不存在，被发送的后续的相关的发票将永远不开始争议解决时期，因为争议解决时期仅作为自动化争议被提出的结果开始

3.争议解决检查时间区间可以被配置为使能够甚至在争议解决时期流逝之前潜在地执行自动匹配的对出票人和付款人完成的动作的小的被重复的区间检查成为可能(见章节配置争议解决时期)。

a.如果自动匹配能够在任何争议解决检查时间区间执行，那么其将继续到自动地验证最新的活动的发票。

b.如果自动匹配不能够在任何争议解决检查时间区间执行，那么其将尝试在下一个区间再次地检查。

c.最后的执行自动匹配的尝试将是在争议解决时期的流逝时。

4.在每个争议解决检查时间区间，自动匹配仅可以当从出票人接收到争议响应并且相应的已更新的文件作为对争议响应的动作被发送时继续以执行(见关于响应于争议的章节)。

a.出票人接受争议——出票人必须发送完全链接的贷项清单以取消之前的发票，以及，发出新的相关的发票以改正之前的发票的矛盾。该过程被共同地称为“贷记再出票”。自动匹配将通过比较最新的活动的发票(作为“贷记再出票”的结果)与最新的活动的运费结算单(之前在结算时期期间或在争议解决时期期间被发送)执行。

b.出票人拒绝争议——付款人必须通过直接地代替之前的一个或取消并且发出新的一个运费结算单来发送已改正的运费结算单。自动匹配将通过比较最新的活动的发票(之前在结算时期期间或在争议解决时期期间被发送)与最新的活动的运费结算单(其是在该争议解决时期期间被发送的已改正的运费结算单)执行。

c.没有争议响应——与出票人是否发出“贷记再出票”或付款人发送已改正的运费结算单无关，自动匹配将不在争议解决检查时间区间期间执行，因为没有争议响应被接收到。在该方案中，自动匹配将仅当争议解决时期流逝时执行。

5.在争议解决时期的流逝时，自动匹配仅可以当如果出票人初始化“贷记再出票”或付款人发送已改正的运费结算单时继续执行。如果没有响应被接收到，那么自动匹配不运行。

a.“假定的”出票人接受争议——出票人发送完全链接的贷项清单以取消之前的发票，以及，发出新的相关的发票以改正之前的发票的矛盾。

自动匹配将通过比较最新的活动的发票(作为“贷记再出票”的结果)与最新的活动的运费结算单(之前在结算时期期间或在先前的争议解决时期期间被发送)执行。

注意，虽然“拒绝”响应在争议解决时期期间被出票人发送，但是其被忽略，并且自动匹配假定出票人已经实际上“接受”来自付款人的争议。

b.“假定的”出票人拒绝争议——付款人通过直接地代替之前的一个运费结算单或取消并且发出新的一个运费结算单发送已改正的运费结算单。

自动匹配将通过比较最新的活动的发票(之前在结算时期期间或在先前的争议解决时期期间被发送)与最新的活动的运费结算单(其是在该争议解决时期期间被发送的已改正的运费结算单)执行。

注意，虽然“接受”响应在争议解决时期期间被出票人发送，但是其被忽略，并且自动匹配假定出票人已经分别地告知付款人以再检查，因为发票基于他们的约定条款被改正。

c.“假定的”出票人-付款人离线地约定——出票人和付款人二者发送他们的已改正的文件。

自动匹配将通过比较最新的活动的发票(作为“贷记再出票”的结果)与最新的活动的运费结算单(其是在该争议解决时期期间被发送的已改正的运费结算单)执行。

该特别的方案通常当没有争议响应被开发票门户接收到时发生。自动匹配假定出票人和付款人二者已经达成某个协议并且分别地改正他们的自己的文件。

可选择地，始终要求争议响应。

6.在自动匹配执行之前的任何时间(在每个争议解决检查时间区间或在争议解决时期的流逝时)：

a.出票人具有通过使用完全链接的贷项清单取消其并且再发出新的发票来改正他们的发票的选项。

b.付款人具有通过直接地代替运费结算单或取消并且再发出新的运费结算单来改正他们的运费结算单的选项。

7.在当自动匹配执行时的任何点，其将始终把最新的活动的发票(发票状态＝新的或被争议的)与最新的已链接的活动的运费结算单(运费结算单状态＝新的、已代替的、可用的、或与可以把其设置为可用的完全链接的贷项清单被争议的)进行比较。这类似于在结算时期期间正在被进行的内容(参照在结算时期章节下的点6、7和8)。

8.一旦自动匹配执行，那么其可以导致：

a.新的争议被提出——这是自动匹配在再验证期间发现发票和运费结算单之间的矛盾的结果。出站COMDIS争议提交EDIFACT消息将被发送至出票人(以及可选择地发送至付款人)。给付款人的出站IFTFCC发票EDIFACT消息在这种情况下将被阻止并且不被发送(见关于提出争议和拿回发票的章节)。

b.“完美的匹配”——这是自动匹配在再验证期间不发现发票和运费结算单之间的任何矛盾的结果。出站IFTFCC发票EDIFACT消息将被发送至付款人。

c.达到最大自动匹配争议循环——这是自动匹配在再验证期间发现发票和运费结算单之间的矛盾的结果；然而，之前的相关的发票已经被争议高至被付款人设置的极限(见关于限制自动匹配争议循环的章节)。当前的发票将进入MPR中并且没有出站COMDIS争议提交EDIFACT消息将被发送。

d.MPR发票——这是自动匹配在再验证过程期间由于各种阻止其能够成功地完成的原因引发异常的结果。出站IFTFCC发票EDIFACT消息将被发送至付款人，指示其导致MPR。这暗示后续的相关的发票也将不能够执行自动匹配。

还参见关于解释自动匹配结果的章节2.3.6。

9.如果自动匹配成功地完成再验证过程并且提出新的争议的话，这将再次开始新的争议解决时期。

c)响应于争议

争议解决过程涉及出票人和付款人之间的双向通信。付款人负责检查出票人发出的发票并且如果具有任何矛盾则相应地提出争议。而出票人负责在调查所有的细节之后响应于付款人的争议。该过程可以重复几次，直到出票人和付款人二者都最终地解决争议。

出票人通过接受或拒绝争议来响应于争议。出票人在检查之后意识到错误在他们的发票上，则他们接受争议。这将使出票人需要取消正在被争议的发票(使用完全链接的贷项清单)并且发出具有适当的改正的新的发票。另一个方面，出票人在检查之后意识到他们的发票是正确的，则他们拒绝争议；以及可能付款人可能已经误解他们的协议条款或已经在他们自己的应计项目中产生某个错误。这则将使付款人需要再检查他们的应计项目或协议以据此再调整他们的运费结算单(见关于争议解决时期的章节)。合理的是出票人始终发送他们的争议响应以帮助在自动匹配系统内的自动化争议解决过程。

出票人可以通过登录入向开发票门户的基于网站的界面中并且选择“接受”或“拒绝”关于特定的发票的争议来响应于争议。出票人也可以使用入站COMDIS争议响应EDIFACT消息发送他们的争议响应。

无论何时出票人发送入站COMDIS争议响应EDIFACT消息，开发票门户要求某个信息被填入EDIFACT文件中以使争议响应被正确地相关联于具有突出的争议的合适的发票。出票人可以选择提供以下中的任一个：

·争议ID——对于每个被提出的争议，门户将指派将被填入出站COMDIS争议提交EDIFACT消息中的唯一的ID(见关于COMDIS争议提交的章节)。如果提供了门户的争议ID，则INTTRA将始终尝试使用该门户的争议ID。

·出票人公司ID+发票号码+发票发出日期——如果没有提供门户的争议ID，那么门户将使用这种关键词的集合来检索发票并且把争议响应相关联于最后一个开放的争议(尚未被响应于其的争议)。

注意：如果COMDIS争议响应EDIFACT消息不能够发现匹配的突出的争议的话，则其将失败。

以下的表格提供关于这些字段(用于相关联争议响应)的在入站COMDIS争议响应EDIFACT消息内的精确的定位的更多的细节。

字段	COMDIS位置-片段-元素(合格者)
		INTTRA争议ID	0030-RFF-C506-1154(1153＝ZZZ)
出票人公司ID	0070-NAD-C082-3039(3035＝RE)
		发票号码	0110-DOC-C503-1004(1001＝380)
发票发出日期	0120-DTM-C507-2380(2005＝149)

出票人的对争议的响应，无论其是“接受”还是“拒绝”，也都在入站COMDIS争议响应EDIFACT消息上于消息的开始(BGM)片段下明确地进行指示。该同一个响应也在出站COMDIS争议响应EDIFACT消息上在同一个片段中被发送至付款人。以下是入站和出站COMDIS争议响应EDIFACT消息的实例，示出了“接受”或“拒绝”响应。

除了提供实际的争议响应(接受或拒绝)之外，出票人必须也提供争议响应原因(代码和描述)，以及可选择地与它们的争议响应一起的自由文本备忘录。争议原因和备忘录文本允许出票人提供关于为什么争议被接受或拒绝的另外的细节。为了保持当提供争议原因时的一致性，INTTRA保持在附录C争议响应代码下列出的标准的争议响应原因代码和描述的列表。并且为了进一步辅助下游自动化争议响应处理，INTTRA的标准的争议响应代码也可以被别名化；由此INTTRA的代码被解释为出票人的或付款人的自己的内部系统代码(或相反地)的过程。

出票人的争议响应原因代码和描述以及自由文本备忘录在入站COMDIS争议响应EDIFACT消息上在调整细节(AJT)片段组-位置140下进行指示。相同的细节也在出站COMDIS争议响应EDIFACT消息上在同一个片段组中被发送至付款人。

注意：

1.还要求出票人在入站COMDIS争议响应EDIFACT消息中发送他们自己的系统的争议ID。出票人的争议ID将作为出站COMDIS争议响应EDIFACT消息的一部分发送至付款人，并且将在出票人和付款人之间的通信过程中有帮助，特别是当要求手动争议操作时。

d)限制自动匹配争议循环

理想地，争议解决过程应当不永远地继续；在沿着付款人争议和出票人响应的某处，双方都需要最终地达到解决。以相同的方式，如果自动匹配继续无限地反复地争议发票，其将不是对于出票人和付款人二者都有益的。据此，自动匹配提供付款人限制针对相关的发票集提出争议的次数的数量的能力。建议的是，出票人和付款人二者都讨论并且联合地一致同意恰当的最大自动匹配争议循环。

以下的规则在确定自动匹配是否已经达到最大争议循环时被自动匹配使用：

1.最大自动匹配争议循环可以针对每个出票人-付款人配对被配置并且适用于所有的关于同一对的自动匹配过程的发票(见章节配置最大自动 匹配争议循环)。

2.最大自动匹配争议循环限制可以针对相关的发票集提出争议的次数的数量(见关于用于自动匹配的相关发票的章节)。这暗示其也限制可以针对相关的发票的同一个组开始争议解决时期的次数的数量。

3.最大自动匹配争议循环不限制可以执行自动匹配的次数的数量，其也不限制可以开始结算时期的次数的数量。

4.无论何时自动匹配成功地执行并且发现在发票上的矛盾，其将检查以确保针对相关的发票的组提出的争议的当前的总数量尚未超过针对出票人-付款人组合而设置的最大自动匹配争议循环。

a.假设被提出的争议的总数量<最大自动匹配争议循环——继续到提出争议并且把出站COMDIS争议提交EDIFACT消息发送至出票人(以及可选择地至付款人)。给付款人的出站IFTFCC发票EDIFACT消息在这种情况下将被阻止并且不被发送(见关于提出争议和拿回发票的章节)。

b.如果被提出的争议的总数量＝最大自动匹配争议循环—引发异常并且把发票置于MPR中。出站IFTFCC发票EDIFACT消息将被发送至付款人，并且没有出站COMDIS争议提交EDIFACT消息将被发送。

c.被提出的争议的总数量将永远不大于最大自动匹配争议循环。

e)手动争议相对于自动匹配

INTTRA的解决方案套件的特征中的一个是其使顾客能够通过各种可能的通道发送和接收与开发票相关的信息。信息可以通过在线网站界面、电子数据交换(EDI)以及甚至通过电子邮件流入和流出INTTRA系统。INTTRA的系统确保经过不同的通道的信息流动的一致性。

关于自动匹配，争议和争议响应可以来自多个通道源。争议可以通过自动匹配被自动地提出或其可以通过付款人用户登录入开发票门户的web界面中进行手动地提出。另一个方面，争议响应可以通过入站COMDIS争议响应EDIFACT消息或通过出票人用户登录入开发票门户的网站界面中并且选择“接受”或“拒绝”开放的发票争议而进行发送。

以下的规则被自动匹配使用以确保通过入站COMDIS争议响应EDIFACT消息发送的争议响应和出票人通过基于网站的界面提交至开发票门户的争议响应之间的一致性：

1.无论何时入站COMDIS争议响应EDIFACT消息被INTTRA发票接收到，其将仅当发票具有突出的争议(被自动匹配提出或被付款人通过INTTRA网站门户手动地提出并且没有响应已经在之前被接收到)时被处理。

2.无论何时争议响应被出票人通过INTTRA网站门户提交，其将以相同的方式检查发票是否具有尚未被响应的突出的争议。如果响应已经存在的话，则INTTRAweb门户将提出声明发票已经改变其现状的错误消息。

3.无论出票人的争议响应通过入站COMDIS争议响应EDIFACT消息进行发送还是通过INTTRAweb门户进行提交，出票人的争议响应始终通过出站COMDIS争议响应EDIFACT消息被发送至付款人。

以下的规则被自动匹配使用以确保自动匹配提出的争议和付款人通过开发票门户的网站界面手动地提出的争议之间的一致性：

1.无论何时自动匹配成功地执行并且发现在发票上的矛盾，其将检查以确保在其继续到提出自动化争议之前不具有对于同一个发票的突出的争议。

a.如果自动匹配发现突出的争议(在这种情况下来自INTTRA网站门户并且与出票人是否已经响应无关)的话，其将把发票置于MPR中并且把IFTFCC发票EDIFACT消息出站至付款人，在这种情况下没有出站COMDIS争议提交EDIFACT消息将被发送。

b.如果不具有突出的争议(在这种情况下来自INTTRA网站门户)，那么自动匹配将继续其他的检查且最终地提出争议并且把出站COMDIS争议提交EDIFACT消息发送至出票人(以及可选择地发送至付款人)。

2.无论何时由付款人通过INTTRA网站门户提出手动争议，自动匹配都将不再执行并且发票将被置于MPR中。

a.如果结算时期或争议解决时期目前是活动的，那么一旦手动争议已经被付款人提出的话，其将被终结。

b.如果自动匹配设法仅在手动争议被处理之前成功地提出自动化争议的话，INTTRA网站门户将提出声明发票已经改变其的现状的错误消息。

c.通过INTTRA网站门户提出的手动争议将以相同的方式把出站COMDIS争议提交EDIFACT消息发送至出票人(以及可选择地发送至付款人)。

注意：

1.自动匹配可以处理通过入站COMDIS争议响应EDIFACT消息被发送的或由出票人通过INTTRA网站门户提交的争议响应。

2.一旦手动争议针对特定的发票提出，那么任何后续的相关的发票将不再通过自动匹配进行处理。如果适用的话，其他的非相关的发票将仍然继续通过自动匹配来处理。手动地提出争议的付款人等效于告诉自动匹配他们不想要针对该特定的发票提出自动化争议。

关于ALL-DIFF比较

自动匹配提出的争议通常基于付款人设置的业务规则。当出票人或付款人接收到出站COMDIS争议提交EDIFACT消息时，有时仅通过观看含有矛盾的发票字段，其可以不足以完全地解决关于争议的实际的原因。这是因为可能实际上没有提出过矛盾的发票字段，由于业务规则如何被设置，可以潜在地是争议的实际的根本原因。据此，也是重要的是出票人和付款人能够分析不偶然提出任何矛盾的发票字段的其他的集合。自动匹配通过“ALL-DIFF”比较特征使这种能力成为可能。

ALL-DIFF比较在发票和已链接的运费结算单之间的所有的可争议的字段上进行全面检查，并且相似地提出很大地相似于通过业务规则提出的那些的矛盾。ALL-DIFF比较作为尝试提供更多的信息以支持通过业务规则发现的实际的矛盾的另外的检查起作用。

以下的规则被自动匹配当在发票和已链接的运费结算单之间进行ALL-DIFF比较时使用：

1.出票人或付款人具有选择是否在自动匹配处理期间进行ALL-DIFF比较的选项。

2.ALL-DIFF比较将仅当自动匹配能够成功地把发票链接于运费结算单时发生。

3.将仅当自动匹配能够成功地缩减在发票和运费结算单二者上的行条目时进行费用行条目上的ALL-DIFF比较。

4.ALL-DIFF比较利用“精确的匹配”比较并且将跳过不具有在发票、运费结算单或二者上提供的值的字段。

5.仅在可以针对其设置业务规则的标头和费用行字段上进行ALL-DIFF比较。

6.ALL-DIFF比较在所有的有效的标头和费用行字段上进行，与是否针对这些字段设置业务规则无关。

7.被用于业务规则执行的以下规则也适用于ALL-DIFF比较：

a.字母型和数字型比较规则

b.列表值比较规则

c.操作汇率比较

d.通过标头字段匹配

e.匹配专用标头字段

f.通过费用代码匹配

8.ALL-DIFF比较不进行出口发票费用的方向检查。据此，在出口发票上的预付费的费用将仅当匹配的预付费的费用在已链接的运费结算单上被发现时经历ALL-DIFF比较。

9.ALL-DIFF比较矛盾将仅当自动匹配能够作为来自被执行的业务规则或非业务规则检查(即另外的费用、缺少的费用、不可缩减的和方向检查)的矛盾的结果提出争议时被提出。

注意

1.为什么仅当争议被提出时进行ALL-DIFF比较的基本原理是因为其被意图作为另外的用于支持争议的信息。

2.解释结果

解释自动匹配结果是与理解自动匹配如何使用已链接的运费结算单验证发票同样地重要的。解释结果使出票人和付款人二者能够基于自动匹配的输出自动化他们自己的内部争议管理过程。如果当自动匹配由于关于发票或运费结算单或来源于自动匹配执行的异常的不足够的信息不能够进行自动化验证时需要出现的话，则其还帮助促进手动争议解决。

无论何时争议被提出，自动匹配(通过开发票门户)将使用出站COMDIS争议提交EDIFACT消息格式把争议细节发送至出票人。付款人也可以订购以接收相似的出站消息。此外，某个自动匹配争议信息也可以在出票人或付款人登录至开发票门户的网站界面上时进行在线察看，针对样品屏幕拍摄，参考附录F样品i-Act争议屏幕。

自动匹配利用标准的矛盾/争议代码集把提出争议的原因加标签。这些代码作为自动匹配结果的一部分为可用的并且可以被出票人和付款人使用以自动化下游争议处理。为了进一步辅助这样的自动化争议处理，INTTRA的标准的争议代码也可以被别名化；由此INTTRA的代码被解释为出票人的或付款人的自己的内部系统代码的过程。这些争议代码在附录B矛盾/争议代码下进一步进行详细地解释。

无论何时发票通过出站IFTFCC发票EDIFACT消息被发送至付款人，如果具有对手动操作的需要，另外的信息也通过自动匹配提供以帮助下游发票处理(见关于操作“要求手动处理”(MPR)的章节)。

COMDIS争议提交

对于每个自动匹配提出的争议，开发票门户将把出站COMDIS争议提交EDIFACT消息发送至出票人(以及可选择地发送至付款人)。争议提交消息将含有所有的在自动化发票验证过程期间被自动匹配发现的矛盾(见关于产生争议和矛盾的章节)。如果出票人或付款人选择接收ALL-DIFF比较，则同一个争议提交消息也可以含有ALL-DIFF比较。

a)一般的争议信息

重要的是，在进入矛盾如何在EDIFACT消息文件上被实际呈现的非常细节中之前，首先理解在出站COMDIS争议提交EDIFACT消息内提供的一般的信息，因为其涉及自动匹配提出的争议。

一个这样的信息是INTTRA争议ID。每个在INTTRA内被提出的争议将被指派唯一的ID以帮助促进争议与它们相应的争议响应的关联。INTTRA争议ID在出站COMDIS争议提交EDIFACT消息中在消息的开始(BGM)片段下进行指示并且可以被出票人在响应于特定的争议时使用(见关于响应于争议的章节)。

出站COMDIS争议提交EDIFACT消息也含有一般的争议信息，例如：

·发票号码——是指正在被争议的发票

·发票发出日期——是指发出被争议的发票的日期

·发票争议计数——是指当已经针对特定的发票提出争议(通过自动匹配或通过INTTRA网站门户)时的次数的数量

·争议创建方法——是指争议提交的来源：由自动匹配自动地提出的或由付款人通过开发票门户的网站界面手动地提出的发票

注意：对于也在出站COMDIS争议提交EDIFACT消息中提供的其他的一般的争议信息(例如各方、索引、商品细节或金额)，支持咨询可用于EDIFACT消息类型中的每个的消息实施指南。

b)总体的争议细节

无论何时在INTTRA电子发票中通过自动匹配自动地或通过INTTRA网站门户手动地提出争议时，总体的争议原因代码和描述在COMDIS争议提交EDIFACT消息中进行发送。总体的争议原因作为关于为什么发票正在被争议的主要的原因。关于自动匹配，总体的争议原因始终根据最普遍的矛盾确定(见关于产生争议和矛盾的章节)。

总体的争议原因代码和描述在COMDIS争议提交EDIFACT消息中在自由文本(FTX)片段组-位置160下指示。

为了帮助在出票人的或付款人自己的系统内的更平滑的争议处理，别名化也可以针对总体的争议原因代码进行设置。

c)矛盾细节

争议可以含有多于一个矛盾(见关于产生争议和矛盾的章节)，其可以是通过业务规则和非业务规则检查提出的矛盾(共同地被称为发票矛盾)，或作为ALL-DIFF比较的结果(见关于ALL-DIFF比较的2.3.5章节)。发票矛盾和ALL-DIFF矛盾可以来自标头条目或费用行条目。

所有类型的矛盾在COMDIS争议提交EDIFACT消息中在文件行识别(DLI)片段组-位置200下指示，其由以下组成：

·1个文件行识别(DLI)片段，随后是

·1个或更多个调整细节(AJT)片段子组，具有：

o 1个调整细节(AJT)片段，随后是

o 1个或更多个自由文本(FTX)片段

EDIFACT文件行识别(DLI)片段被用于区分与ALL-DIFF矛盾的发票矛盾；而调整细节(AJT)片段被用于区分标头条目矛盾和费用行条目矛盾。任何矛盾的实际的细节将在自由文本(FTX)片段下指示

d)标头条目发票矛盾

标头条目发票矛盾细节在COMDIS争议提交EDIFACT消息中在调整细节(AJT)片段子组-位置230(在AJT片段下描述为58-标头条目矛盾)下指示。每个被提出的标头条目发票矛盾都将具有一个相应的被产生的FTX+ABO行；并且所有的FTX+ABO行都将被包含在一个AJT片段(位置240)中。

为了帮助在出票人的或付款人的自己的系统内的更平滑的争议处理，别名化也可以针对矛盾原因代码中的每个进行设置。

e)费用行条目发票矛盾

费用行条目发票矛盾细节在COMDIS争议提交EDIFACT消息中在调整细节(AJT)片段子组-位置230(在AJT片段下描述为48-费用行条目矛盾)下指示。每个具有至少1个矛盾的费用行条目将具有一个相应的AJT片段(位置240)以识别费用行，随后是一个FTX+IND以识别实际的费用代码和描述，随后是关于针对费用行提出的每个矛盾的一个FTX+ABO。

为了帮助在出票人的或付款人的自己的系统内的更平滑的争议处理，别名化也可以针对费用代码和矛盾原因代码进行设置。

f)ALL-DIFF矛盾

ALL-DIFF矛盾仅在COMDIS争议提交EDIFACT消息中产生，如果：

·出票人或付款人已经选择接收ALL-DIFF信息，并且

·已经提出至少一个发票矛盾

类似于标头条目发票矛盾，ALL-DIFF标头条目矛盾细节也在COMDIS争议提交EDIFACT消息中在调整细节(AJT)片段子组-位置230(在AJT片段下描述为58-标头条目矛盾)下指示。每个被提出的ALL-DIFF标头条目矛盾将具有一个相应的被产生的FTX+AEZ(代替FTX+ABO)行；并且所有的FTX+AEZ行都将被包含在一个AJT片段(位置240)中。

类似于费用行条目发票矛盾，ALL-DIFF费用行条目矛盾细节也在COMDIS争议提交EDIFACT消息中在调整细节(AJT)片段子组-位置230(在AJT片段下描述为48-费用行条目矛盾)下指示。每个具有至少1个ALL-DIFF矛盾的费用行条目将具有一个相应的AJT片段(位置240)以识别费用行，随后是一个FTX+IND以识别实际的费用代码和描述，随后是一个FTX+AEZ(代替FTX+ABO)以用于每个针对费用行被提出的ALL-DIFF矛盾。

ALL-DIFF矛盾细节不含有矛盾原因代码和描述；这是因为ALL-DIFF矛盾意图支持由被执行的业务规则或非业务规则检查(即另外的费用、缺少的费用、不可缩减的和方向检查)提出的实际的矛盾。

IFTFCC发票消息

除了通过出站COMDIS争议提交EDIFACT消息提供争议和矛盾信息之外，自动匹配还通过被发送至付款人的出站IFTFCC发票EDIFACT消息提供信息。该信息帮助付款人确定如何自动地处理EDIFACT发票，特别是当自动匹配提出要求手动操作的异常时。

g)发票争议计数

类似于出站COMDIS争议提交EDIFACT消息，出站IFTFCC发票EDIFACT消息也含有是指当争议已经针对特定的发票被提出(通过自动匹配或通过INTTRA网站门户)时的次数的数量的发票争议计数。该信息，虽然不与自动匹配处理直接地相关，但可以被付款人使用以潜在地警告他们已经被反复地争议并且因此可以要求特别的注意的发票。

自动匹配地位

在出站IFTFCC发票/贷项清单EDIFACT消息中提供的信息中的一个是自动匹配现状标志。该标志告诉付款人发票或贷项清单是否被自动匹配处理。自动匹配现状标志在出站IFTFCC发票/贷项清单EDIFACT消息中在文件/消息细节(DOC)片段-位置80下进行指示。

以下的表格提供关于如何解释自动匹配现状标志的细节。

自动匹配异常

自动匹配引擎当尝试自动地验证来自出票人的发票时经历复杂的过程。这种复杂的过程也很大地依赖于在发票和运费结算单上提供的信息，以及，在争议解决过程期间被出票人和付款人采取的恰当的动作。据此，可以具有其中由于数据、过程或不太可能的系统错误的异常发生的情况，其防止自动匹配能够成功地验证发票。

在大多数情况下，例外发生不是因为自动匹配系统错误；而是因为在发票或运费结算单上提供的信息，或在更极端的情况下，在合适的时间针对自动匹配执行提供这样的信息的失败。在不太可能的自动匹配由于系统错误引发异常的事件中，以下是可能的原因中的某些：

·发票或运费结算单字段验证失败

·关键的缩减异常

·没有业务规则针对出票人和付款人组合被设置

·其他的内部自动匹配处理错误

无论何时引发自动匹配异常，没有业务规则将被执行并且在发票和已链接的运费结算单之间没有发生比较。遇到异常的发票将被发送至付款人(通过出站IFTFCC发票EDIFACT消息)，指示异常已经发生以及在这样的异常背后的原因。

自动匹配提供用于在出站IFTFCC发票EDIFACT消息中遇到的这种类型的异常的代码和描述，以辅助付款人决定如何最好地处理发票。还提供了要求手动解决标志以告知付款人他们需要开始对于发票的手动处理(见关于操作“要求手动处理”(MPR)的章节)。

以下的表格提供自动匹配异常原因代码和描述以及关于为什么遇到这样的异常的简短的解释的列表。

3.应用完全链接的贷项清单

被链接的贷项清单(或贷项凭单)是出票人发送至他们的付款人的文件，以部分地调整在发票上的不正确的费用或在某些情况下以完全地取消发票。自动匹配支持后者，其是出票人发送以取消之前的发票的完全链接贷项清单。

出票人必须在把完全链接的贷项清单发送至开发票门户时始终提供相关的发票号码和发票发出日期。这提供用于自动匹配的手段，以正确地识别正在被贷项清单改正的发票，并且由此应用(或“复位”)之前被用于相对于同一个发票进行匹配以提出争议的运费结算单费用。

以下的规则当复位用于相应的完全链接的贷项清单的已链接的运费结算单的费用时被使用：

·复位在运费结算单上的费用简单地意指把费用从“被争议的”更新至“可用的”(见关于运费结算单状态的章节)

·完全链接的贷项清单仅当相关的发票最近被链接于同一个运费结算单以用于自动化验证和争议产生时可以被用于复位运费结算单的费用。

·仅属于与相关的发票(正在被完全链接的贷项清单取消)相同的贸易方向的运费结算单费用将被复位：

o出口运费结算单预付费的费用仅当相关的发票是出口发票时被复位

o出口运费结算单货到付款费用仅当相关的发票是进口发票时被复位

o进口运费结算单货到付款费用始终被复位，因为相关的发票将始终是进口发票

·属于与相关的发票(正在被完全链接的贷项清单取消)相同的贸易方向的所有运费结算单费用将被复位：

o即使运费结算单费用行在相关的发票上但是不在完全链接的贷项清单上出现——假定完全链接的贷项清单含有所有的来自相关的发票的费用行

o即使运费结算单费用行不在相关的发票上也不在完全链接的贷项清单上出现——这些是作为缺少的费用被提出的费用行(见关于检测缺少的 和另外的费用的章节)

o即使运费结算单费用行不具有与相关的发票和完全链接的贷项清单相同的费用代码、集装箱大小/类型、数量、价格、货币或金额——这允许运费结算单通过另一轮的发票再验证，其中所有的费用得到再检查(见关于自动匹配费用行条目的章节2.3.3)

·已经被“复位”(或使得可用的)的运费结算单费用可以通过自动匹配在后续的发票验证过程中再使用。

以下的表格提供关于复位运费结算单费用的某些方案。为了简单性，费用行实施例使用以下的格式进行指示：

·对于被链接的贷项清单：<预付费/货到付款指示符>、<费用代码>、<开发票金额>

·对于运费结算单：<预付费/货到付款指示符>、<费用代码>、<开发票金额>、<被争议的/可用的>

IV.其他的考虑

以下的类型的代码在发票验证过程被自动匹配引擎中特别地使用：

·公司ID——INTTRA建立被用于代表承运人、出票人和付款人的唯一标识符(见关于发票至运费结算单链接关键词的章节2.1.1)。

·费用代码——来源于UN/ECE CEFACT贸易便利化建议N°.23-货运成本代码的子集合，并且被用于代表在发票上的费用条目。参见关于自动 匹配费用代码的完整列表的附录A(还参考关于对INTTRA标准费用代码 的解决的章节2.2.1)。

·集装箱大小/类型——利用标准的4字符ISO集装箱大小和类型代码(见ISO 6346)代表船运集装箱的大小和类型。

·货币代码——利用标准的3字符ISO货币代码(见ISO 4217)代表国际货币。

·地点代码——利用标准的5字符UN/ECE LOCODE代表被在贸易和运输功能中使用的地点，例如海港、铁路和道路终端、机场、邮局和边境通道点。见UN/LOCODE的完整列表。

·HS代码——INTTRA目前不保持商品代码集；然而，建议的是，世界海关组织(WCO)开发的协调商品描述和编码系统(HS)被用作标准。对于这些代码的完整列表，参考HS命名法2007版本。

·矛盾/争议代码——INTTRA创建的被用于代表各种矛盾和争议原因的代码。

·争议响应代码——INTTRA创建的被用于代表各种争议响应的代码。

出票人和付款人可以选择在入站EDIFACT消息中使用INTTRA标准代码或发送他们自己的被别名化至这些标准代码的系统代码。关键的是确保每个出票人或付款人系统代码正确地别名化至INTTRA标准代码以确保发票相对于运费结算单的精确的匹配和验证。

A.设置出票人/付款人公司

在承运人、出票人或付款人(运费结算单的主要的发出付款人、预付费付款人或货到付款付款人)可以在自动匹配系统中被识别，他们在开发票门户中需要被设置为公司。

此外，付款人公司(预付费付款人或货到付款付款人)需要与出票人公司合伙以创建使创建业务规则成为可能的付款人—出票人组合。

B.使能EDI订购

为了使自动匹配起作用并且执行业务规则，出票人需要能够发送EDI发票并且付款人需要能够把EDI运费结算单发送入开发票门户中。出票人和付款人需要针对INTTRA EDIFACT消息进行订购以使系统成功地处理入站和出站EDI文件二者。

关于自动匹配，要求出票人订购入站IFTFCC发票/借项清单/贷项清单EDIFACT消息。如果出票人在他们的争议解决过程中使用EDI消息，则他们也可以可选择地订购入站COMDIS争议响应以及出站COMDIS争议提交EDIFACT消息。

另一个方面，如果自动匹配针对它们的出票人中的任意一个被激活，则要求付款人订购入站IFTCCA运费结算单EDIFACT消息。如果付款人在他们的争议解决过程中使用EDI消息，则他们也可以可选择地订购出站COMDIS争议响应以及出站COMDIS争议提交EDIFACT消息。

此外，如果付款人将自动匹配用于自动化发票验证，则建议付款人也订购出站IFTFCC发票/贷项清单EDIFACT消息。出站EDI发票含有与自动匹配处理结果相关的信息，其可以帮助付款人决定如何最好地在他们自己的内部系统中进一步处理发票，特别是当可以要求手动处理时。

C.订购电子邮件通知

开发票系统是事件驱动的系统。每个过程，从发票或运费结算单消息加载，至自动匹配执行，至争议操作，都由系统内发生的某些事件触发。事件可以作为外部(即EDI消息被发送)或内部(即争议被自动匹配提出)动作的结果发生；并且这些动作可以由实际的人类用户(即鼠标点击来自网站门户的争议按钮)或由某些其他的系统事件(即结算时期流逝)引起。

系统提供用于出票人和付款人当某些事件发生时通过电子邮件通知被警告的手段。

D.配置偏好和业务规则选项

自动匹配提供以使付款人能够具有修改引擎当进行自动匹配时如何处理发票或运费结算单的灵活性的偏好的形式的各种设置。

配置结算时期

重要的是决定合适的结算时期持续时间，因为这影响对于任何特定的发票的最早自动匹配执行。结算时期持续时间必须被配置为允许足够的时间以便使付款人发送任何特定的发票的运费结算单以允许自动化验证发生；然而在相同的时间，其不应当被设置为过于长的，使得其影响在发票应得到支付之前的其余的可用于解决任何突出的争议的时间。

自动匹配提供用于针对进口和出口发票分别地配置结算时期持续时间(或等待时间)的手段。如果在准备运费结算单中需要的时间在贸易方向之间改变，则这允许甚至更大的灵活性。

默认出口发票等待时间是5日，而默认进口发票等待时间是2日。等待时间以分钟被计算，与周末或公共假期无关，并且可以具有由于机器处理循环的+/-一分钟差异。

配置争议解决时期

与确定合适的结算时期持续时间同样重要的是，确定合适的争议解决时期持续时间将进而影响自动匹配如何再执行以进行自动化的发票再验证。争议解决时期持续时间必须被配置为允许出票人和付款人有足够的时间以针对之前被提出的突出的争议采取恰当的行动；然而在相同的时间，其不应当被设置为过于长的，使得其成为长期的过程。

此外，自动匹配提供用于配置争议解决检查时间区间的手段，其使甚至在实际的争议解决时期流逝之前能够潜在地执行自动匹配的出票人和付款人完成的动作的小的重复的区间检查成为可能。进口和出口发票二者都利用一个共用的争议解决时期持续时间(或等待时间)并且一个共用的争议解决检查时间区间默认争议解决等待时间是1日，而默认争议解决检查时间区间是6小时。等待时间和区间以分钟被计算，与周末或公共假期无关，并且可以具有由于机器处理循环的+/-一分钟差异。

配置最大自动匹配争议循环

自动匹配也提供配置作为自动化发票验证的结果针对相关的发票集提出自动化争议的次数的数量的灵活性(见关于限制自动匹配争议循环的章节)。其被称为最大自动匹配争议循环(或最大自动匹配迭代)。重要的是，如果自动化过程不能够解决任何突出的争议，则出票人和付款人讨论并且一致同意最优的最大自动匹配争议循环以帮助后续的手动发票操作。

默认最大自动匹配迭代是2。

选择缩减方法

付款人可以选择缩减相似的费用行的方法。这将允许付款人在他们的运费结算单中表示行条目费用时的灵活性。缩减方法在自动匹配系统中也被称为“运费结算单费用选项”。两个缩减方法(或运费结算单费用选项)是：

·费用代码——所有的集装箱大小/类型被忽略并且当指定运费结算单中的费用行时不要求由付款人进行提供。

·费用代码和集装箱大小类型——当指定运费结算单中的费用行时要求由付款人提供集装箱大小/类型。

设置业务规则

业务规则是自动匹配引擎的核心。付款人可以配置标头(或发票)水平和费用行水平业务规则二者。因为业务规则由付款人—出票人组合定义，所以这意指可以针对每个启用与付款人的自动匹配的出票人定义唯一的业务规则集。

1.定义标头规则

可以定义标头水平业务规则。作为默认，当比较在发票上的条目时，“条件”始终被设置为精确的匹配。然而，自动匹配具有设置允许在数字字段上的阈值比较的业务规则的选项。

阈值条件可以是：

·大于最初的值的x—在正在进行比较的发票字段上的值不能够大于在运费结算单上的最初的值加上所提供的x值阈值。x值在比较之前被加入至运费结算单的值。

·大于最初的值的x％—在正在进行比较的发票字段上的值不能够大于在运费结算单上的最初的值加上所提供的百分之x阈值。百分之x由运费结算单的值计算并且结果在比较之前被四舍五入至8小数位。

·小于最初的值的x——在正在进行比较的发票字段上的值不能够小于在运费结算单上的最初的值减去所提供的x值阈值。x值在比较之前从运费结算单的值减去。

·小于最初的值的x％——在正在进行比较的发票字段上的值不能够小于在运费结算单上的最初的值减去所提供的百分之x阈值。百分之x由运费结算单的值计算并且结果在比较之前被四舍五入至8小数位。

如果已经选择了阈值“条件”，那么阈值的值可以通过“阈值百分数/金额”编辑框被键入。

2.定义费用行规则

可以针对发票上的特定的费用定义费用行水平业务规则；此外，它们也可以针对任何(或所有的)经过相同的发票的费用的类型定义

a)用于特定的费用的业务规则

针对特定的费用定义的费用行水平业务规则可以通过选择“规则类型”作为费用行并且然后从配置片段选择合适的“INTTRA费用代码”而进行。

b)用于所有的费用的业务规则

针对任何(或所有的)类型的费用定义的费用行水平业务规则也可以被修改。

复制业务规则

自动匹配允许业务规则从付款人—出票人组合的一个集合至付款人—出票人组合的另一个集合的复制。这使组织能够迅速地把现有的付款人业务规则集在同一个组织内的不同的付款人当中进行复制。业务规则仅可以当以下的条件被满足时进行复制：

·正在从其复制的源付款人—出票人组合必须具有活动的业务规则

·正在复制至其的目的地付款人—出票人组合必须不具有任何活动的业务规则

以下的表格描述了当自动匹配在结算时期或争议解决时期的流逝时执行时的各种方案。其还提供关于如果自动匹配执行使用哪个文件(发票、贷项清单和运费结算单)，以及可以遇到的不同的可能的自动匹配异常的信息。

方案假定：

·对于结算时期：开始结算时期的出口发票或进口发票已经被接收到

·对于争议解决时期：开始争议解决时期的争议被自动匹配提出

·在自动匹配执行时从方案排除多个活动的发票

·从方案排除多个活动的运费结算单

·一旦自动匹配成功地完成，就从方案排除实际的结果

·从方案排除由于系统非预期的错误导致的自动匹配执行失败

·贷记再出票被接收到暗示完全链接的贷项清单(取消之前的错误的发票)被接收到并且后续的已改正的发票由出票人发送。这可以发生多次但是必须当自动匹配执行时始终导致一个最新的活动的发票。

·进口或出口运费结算单被接收暗示有效的运费结算单被接收到(新的或已代替的)。这可以发生多次，但是必须始终导致一个可以被链接于相应的发票的最新的活动的运费结算单。

·空白的条目暗示没有文件或争议响应被接收到。

E.1结算时期流逝——出口发票

本章节解释当自动匹配在出口发票开始的结算时期的流逝时执行时的各种方案。

注意：在结算时期期间，出票人争议响应不被预期并且将最可能地失败，因为不具有可以匹配于争议响应的突出的争议。

E.2争议解决检查时间区间——出口发票

本章节解释当自动匹配可以在争议解决检查时间区间期间潜在地执行时的各种方案。争议解决时期通过针对被链接于出口运费结算单的出口发票提出的争议开始。

注意：在争议解决检查时间区间期间，自动匹配将仅当争议响应被接收到并且相应的已更新的文件(发票或运费结算单)作为对争议响应的动作被接收到时执行。

E.3争议解决时期流逝——出口发票

本章节解释当自动匹配在作为针对被链接于出口运费结算单的出口发票提出争议的结果而开始的争议解决时期的流逝时执行时的各种方案。

注意：在争议解决时期的流逝时，自动匹配将仅当已更新的文件(发票或运费结算单)被接收到时执行，与争议响应无关。

E.4结算时期流逝——进口发票

本章节解释当自动匹配在由进口发票开始的结算时期的流逝时执行时的各种方案。

注意：在结算时期期间，出票人争议响应不被预期并且将最可能地失败，因为不具有可以匹配于争议响应的突出的争议。

E.5争议解决检查时间区间——进口发票(被链接于出口FS)

本章节解释当自动匹配可以在争议解决检查时间区间期间潜在地执行时的各种方案。争议解决时期通过针对被链接于出口运费结算单的进口发票而提出的争议开始。

注意：在争议解决检查时间区间期间，自动匹配将仅当争议响应被接收到并且相应的已更新的文件(发票或运费结算单)作为对争议响应的动作被接收到时执行。

E.6争议解决时期流逝——进口发票(被链接于出口FS)

本章节解释当自动匹配在作为针对被链接于出口运费结算单的进口发票提出争议的结果而开始的争议解决时期的流逝时执行时的各种方案。

注意：在争议解决时期的流逝时，自动匹配将仅当已更新的文件(发票或运费结算单)被接收到时执行，而与争议响应无关。

E.7争议解决检查时间区间—进口发票(被链接于进口FS)

本章节解释当自动匹配可以在争议解决检查时间区间期间潜在地执行时的各种方案。争议解决时期通过针对被链接于进口运费结算单的进口发票提出的争议而开始。

注意：在争议解决检查时间区间期间，自动匹配将仅当争议响应被接收到并且相应的已更新的文件(发票或运费结算单)作为对争议响应的动作被接收到时执行。

E.8争议解决时期流逝—进口发票(被链接于进口FS)

本章节解释当自动匹配在作为针对被链接于进口运费结算单的进口发票提出争议的结果而开始的争议解决时期的流逝时执行时的各种方案。

注意：在争议解决时期的流逝时，自动匹配将仅当已更新的文件(发票或运费结算单)被接收到时执行，而与争议响应无关。

以下涉及图18-44。

图18示出了关于自动匹配过程的状态图。

图19示出了用于在发票匹配门户中操作发票的状态图。

图20示出了关于付款人发票/贷项清单处理的状态图。

图21示出了关于与被链接的贷项清单的自动匹配过程的状态图。

图22示出了关于发票门户的状态图。

图23示出了关于运费结算单的自动匹配过程的消息状态图。

图24示出了关于运费结算单的自动匹配过程的状态图。

图25示出了关于运费结算单线路转移的自动匹配过程的状态图。

图26示出了关于争议现状状态转移的状态图。

图27示出了用于发票和运费结算单的初始处理的过程。

图28示出了用于操作业务规则并且保存执行结果的过程。

图29示出了用于接收并且处理发票和其他的文件的过程。

图30示出了用于操作运费结算单的过程。

图31示出了用于在发票门户上检查和呈现发票的过程。

图32示出了用于操作发票副本的过程。

图33示出了用于操作争议的过程。

图34示出了另外的用于操作争议的过程。

图35示出了用于匹配发票和运费结算单的过程。

图36示出了用于管理争议响应的过程。

图37示出了用于解决发票上的其余的问题的过程。

图38示出了另一个用于解决发票上的其余的问题的过程。

图39示出了另一个用于处理运费结算单的过程。

图40示出了用于匹配出口运费结算单的过程。

图41示出了与发票和贷记结算单的处理相关的过程。

图42示出了另一个与发票和贷记结算单的处理相关的过程。

图43示出了与自动匹配相关的过程。

图44示出了与自动匹配发票和运费结算单相关的过程。

虽然本发明已经参照优选的并且示例性的实施方案进行描述，但是本领域的技术人员将理解，可以作出各种改变并且可以用等效物代替其的元件，而不偏离本发明的范围。此外，可以作出许多修改以使特定的情况或材料适应于本发明的教导内容，而不偏离其的范围。因此，意图的是，本发明不限于所公开的具体的实施方案，而是本发明包括所有的落入所附的权利要求的范围内的实施方案。

Claims (4)

1.一种使用电子数据交换的争议解决处理的方法，包括：

把电子发票链接于电子运费结算单；

把所述发票与所述运费结算单比较；

确定与所述发票相关联的值和与所述运费结算单相关联的值的争议；

传输EDI争议消息；以及

接收EDI争议响应消息。

2.根据权利要求1所述的方法，还包括要求精确的匹配否则发送争议消息的步骤。

3.根据权利要求1所述的方法，其中所述争议仅在容差范围外时被触发。

4.一种系统，包括：

发票门户，其从出票人接收发票并且从付款人接收运费结算单；

发票操作系统，其被配置为：

把所述发票链接于所述电子运费结算单；

自动匹配系统，其被配置为把所述发票与所述运费结算单比较并且确定与所述发票相关联的值和与所述运费结算单相关联的值的争议；

其中所述发票门户在发现争议时把争议消息传输至所述出票人和所述付款人。