EP3417383A1 - Vérification automatique de demandes sur la base de documents électroniques - Google Patents

Vérification automatique de demandes sur la base de documents électroniques

Info

Publication number
EP3417383A1
EP3417383A1 EP16890887.9A EP16890887A EP3417383A1 EP 3417383 A1 EP3417383 A1 EP 3417383A1 EP 16890887 A EP16890887 A EP 16890887A EP 3417383 A1 EP3417383 A1 EP 3417383A1
Authority
EP
European Patent Office
Prior art keywords
electronic document
template
data
request
determined
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16890887.9A
Other languages
German (de)
English (en)
Other versions
EP3417383A4 (fr
Inventor
Noam Guzman
Isaac SAFT
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vatbox Ltd
Original Assignee
Vatbox Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/361,934 external-priority patent/US20170154385A1/en
Application filed by Vatbox Ltd filed Critical Vatbox Ltd
Publication of EP3417383A1 publication Critical patent/EP3417383A1/fr
Publication of EP3417383A4 publication Critical patent/EP3417383A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/047—Payment circuits using payment protocols involving electronic receipts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • G06Q40/123—Tax preparation or submission

Definitions

  • the present disclosure relates generally to verifying files in data systems, and more particularly to verifying requests based on contents of electronic documents.
  • a customer may input credit card information pursuant to a payment, and the merchant may verify the credit card information in real-time before authorizing the sale. The verification typically includes determining whether the provided information is valid (i.e., that a credit card number, expiration date, PIN code, and/or customer name match known information).
  • a purchase order may be generated for the customer.
  • the purchase order provides evidence of the order such as, for example, a purchase price, goods and/or services ordered, and the like.
  • an invoice for the order may be generated. While the purchase order is usually used to indicate which products are requested and an estimate or offering for the price, the invoice is usually used to indicate which products were actually provided and the final price for the products. Frequently, the purchase price as demonstrated by the invoice for the order is different from the purchase price as demonstrated by the purchase order. As an example, if a guest at a hotel initially orders a 3-night stay but ends up staying a fourth night, the total price of the purchase order may reflect a different total price than that of the subsequent invoice.
  • Certain embodiments disclosed herein include a method for validating electronic documents.
  • the method comprises: analyzing a first electronic document to determine at least one transaction parameter, the first electronic document indicating the request, wherein the first electronic document includes at least partially unstructured data; creating a first template for the first electronic document, wherein the first template is a structured dataset including the determined at least one transaction parameter; retrieving, based on the first template, a second electronic document, wherein the second electronic document indicates evidence for verifying the request; and determining, based on the first template and the second electronic document, whether the request is verified.
  • Certain embodiments disclosed herein also include a non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to perform a process, the process comprising: analyzing a first electronic document to determine at least one transaction parameter, the first electronic document indicating the request, wherein the first electronic document includes at least partially unstructured data; creating a first template for the first electronic document, wherein the first template is a structured dataset including the determined at least one transaction parameter; retrieving, based on the first template, a second electronic document, wherein the second electronic document indicates evidence for verifying the request; and determining, based on the first template and the second electronic document, whether the request is verified.
  • Certain embodiments disclosed herein also include a system for validating electronic documents.
  • the system comprises: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configured the system to: analyze a first electronic document to determine at least one transaction parameter, the first electronic document indicating the request, wherein the first electronic document includes at least partially unstructured data; create a first template for the first electronic document, wherein the first template is a structured dataset including the determined at least one transaction parameter; retrieve, based on the first template, a second electronic document, wherein the second electronic document indicates evidence for verifying the request; and determine, based on the first template and the second electronic document, whether the request is verified.
  • Figure 1 is a network diagram utilized to describe the various disclosed embodiments.
  • Figure 2 is a schematic diagram of a validation system according to an embodiment.
  • Figure 3 is a flowchart illustrating a method for automatically verifying requests based on electronic documents according to an embodiment.
  • Figure 4 is a flowchart illustrating a method for creating a dataset based on at least one electronic document according to an embodiment.
  • Figure 5 is a flowchart illustrating a method for verifying a request based on a first electronic document and a second electronic document according to an embodiment.
  • the various disclosed embodiments include a method and system for automatically verifying requests based on electronic documents.
  • a dataset is created based on a first electronic document indicating information related to a request.
  • the request may be for a reclaim of value-added taxes (VATs) paid during a transaction.
  • VATs value-added taxes
  • a template of transaction attributes is created based on the first electronic document dataset.
  • it may be determined whether the transaction is eligible for the request.
  • a second electronic document indicating evidence supporting the request is retrieved.
  • a first data source may be queried to validate the first electronic document and a second data source may be queried to validate the second electronic document.
  • the verification may include creating a template for the second electronic document.
  • the first electronic document and the second electronic document may be stored in a database for later use.
  • Fig. 1 shows an example network diagram 100 utilized to describe the various disclosed embodiments.
  • a request verifier 120 an enterprise system 130, a database 140, and a plurality of web sources 150-1 through 150-N (hereinafter referred to individually as a web source 150 and collectively as web sources 150, merely for simplicity purposes), are communicatively connected via a network 1 10.
  • the network 1 10 may be, but is not limited to, a wireless, cellular or wired network, a local area network (LAN), a wide area network (WAN), a metro area network (MAN), the Internet, the worldwide web (WWW), similar networks, and any combination thereof.
  • LAN local area network
  • WAN wide area network
  • MAN metro area network
  • WWW worldwide web
  • the enterprise system 130 is associated with an enterprise, and may store data related to purchases made by the enterprise or representatives of the enterprise as well as data related to the enterprise itself.
  • the enterprise system 130 may further store data related to requests (e.g., requests for VAT reclaims) to be submitted by the enterprise (e.g., an image file showing a VAT reclaim request form submitted by an employee of the enterprise).
  • requests e.g., requests for VAT reclaims
  • the enterprise may be, but is not limited to, a business whose employees may purchase goods and services subject to VAT taxes while abroad.
  • the enterprise system 130 may be, but is not limited to, a server, a database, an enterprise resource planning system, a customer relationship management system, or any other system storing relevant data.
  • the data stored by the enterprise system 130 may include, but is not limited to, electronic documents (e.g., an image file showing, for example, a scan of an invoice, a text file, a spreadsheet file, etc.). Each electronic document may show, e.g., an invoice, a tax receipt, a purchase number record, a VAT reclaim request, and the like. Data included in each electronic document may be structured, semi-structured, unstructured, or a combination thereof. The structured or semi-structured data may be in a format that is not recognized by the request verifier 120 and, therefore, may be treated as unstructured data.
  • electronic documents e.g., an image file showing, for example, a scan of an invoice, a text file, a spreadsheet file, etc.
  • Each electronic document may show, e.g., an invoice, a tax receipt, a purchase number record, a VAT reclaim request, and the like.
  • Data included in each electronic document may be structured, semi-structured, unstructured, or a
  • the database 140 may store data verified by the request verifier 120 to be utilized for submitting requests.
  • data may include, e.g., sets of electronic documents, each set including at least a first electronic document indicating the request and a second electronic document utilized as evidence for the request of the first electronic document.
  • the web sources 150 store at least electronic documents that may be utilized as evidence for granting requests.
  • the web sources 150 may include, but are not limited to, servers or devices of merchants, tax authority servers, accounting servers, a database associated with an enterprise, and the like.
  • the web source 150-1 may be a merchant server storing image files showing invoices for transactions made by a merchant associated with the merchant server.
  • the request verifier 120 is configured to create a template based on transaction parameters identified using machine vision of a first electronic document indicating information related to a VAT reclaim request with respect to a transaction.
  • the request verifier 120 may be configured to retrieve the first electronic document from, e.g., the enterprise system 130. Based on the created template, the request verifier 120 is configured to retrieve a second electronic document indicating information evidencing the transaction.
  • the request verified 120 is configured to create datasets based on electronic documents including data at least partially lacking a known structure (e.g., unstructured data, semi-structured data, or structured data having an unknown structure).
  • the request verifier 120 may be further configured to utilize optical character recognition (OCR) or other image processing to determine data in the electronic document.
  • OCR optical character recognition
  • the request verifier may therefore include or be communicatively connected to a recognition processor (e.g., the recognition processor 235, Fig. 2).
  • the request verifier 120 is configured to analyze the created datasets to identify transaction parameters related to transactions indicated in the electronic documents.
  • the data integrity manager 120 is configured to create templates based on the created datasets. Each template is a structured dataset including the identified transaction parameters for a transaction.
  • the request verifier 120 is configured to create a first template based on the first electronic document.
  • the request verifier 120 may be configured to determine whether the transaction indicated in the first electronic document is eligible for a VAT reclaim.
  • the request verifier 120 may be further configured to compare data of the first template to at least one VAT reclaim requirement retrieved from, e.g., one of the web sources 150, based on the first template.
  • the VAT reclaim requirements may be in the form of, e.g., rules. For example, based on a first electronic document showing a scan of a VAT reclaim request form for a purchase made in Germany, VAT reclaim requirements are retrieved from a German tax authority server.
  • the retrieved VAT reclaim requirements include a requirement that the entity seeking the reclaim is not a German entity such that, if a "buyer country" field in the first template indicates that the buyer is a German entity, the transaction is determined to be ineligible for VAT reclaim.
  • the request verifier 120 is configured to retrieve the second electronic document for use as evidence needed to grant the request.
  • retrieving the second electronic document may include searching in at least one of the web sources 150 based on data in the first template.
  • the second electronic document may be retrieved from a web source 150-2 associated with a Russian tax authority.
  • the second electronic document may be retrieved from a web source 150-3 associated with ABC Company.
  • the request verifier 120 is configured to determine whether the request is verified based on the first electronic document and the second electronic document. In a further embodiment, determining whether the request is verified may further include generating a second template for the second electronic document based on machine imaging analysis of the second electronic document. In yet a further embodiment, determining whether the request is verified includes comparing data in the first template with data in the second template. As a non-limiting example, values in respective "VAT" fields of the first template and the second template may be compared and, if the compared values do not match, the request is not verified. The matching may be based on, e.g., a predetermined threshold.
  • a notification indicating the failed verification may be generated and sent to, e.g., the enterprise system 130.
  • the request verifier 120 may be further configured to validate each of the first electronic document and the second electronic document based on the first and second templates, respectively.
  • the validation may include, but is not limited to, determining whether each of the first electronic document and the second electronic document is complete and accurate.
  • Each electronic document may be determined to be complete if, for example, one or more predetermined reporting requirements is met (e.g., for a VAT, reporting requirements may include requiring each of type of goods or services purchased, country of seller, country of buyer, and amount of VAT paid).
  • predetermined reporting requirements e.g., for a VAT, reporting requirements may include requiring each of type of goods or services purchased, country of seller, country of buyer, and amount of VAT paid).
  • Each electronic document may be determined to be accurate based on data stored in at least one external source.
  • the at least one electronic source may include, but is not limited to, the enterprise system 130, one or more of the web sources 150, the database 140, or a combination thereof. Examples of determining accuracy follow.
  • the enterprise system 130 may be queried for data related to the enterprise, and the data related to the enterprise may be compared to at least a portion of data of the templates (e.g., data of fields related to enterprise information) to determine whether the at least a portion of the data is accurate.
  • data of the templates e.g., data of fields related to enterprise information
  • the web source 150-7 may be queried for metadata related to the second electronic document, and the queried metadata may be compared to data of the second template.
  • the database 140 may be queried for data of previously verified requests, and the previously verified request data may be compared to at least a portion of data of the first template, the second template, or both, to determine whether the at least a portion of data matches the previously verified request data and, therefore, is accurate. This is because previously verified transaction data may be considered to likely be accurate.
  • a cause of the failure to verify may be determined.
  • Potential causes of failure to verify may include circumstances or assumptions related to the cause of a difference between, e.g., the first template and the second template.
  • the potential causes may be determined based on one or more causation rules.
  • the causation rules may include potential causes associated with particular values for differences in price or multiples thereof.
  • the causation rules may further be based on whether the difference is positive (e.g., a price in an invoice is higher than a price in a request) or negative, (e.g., a price in an invoice is lower than a price in a request).
  • Fig. 2 is an example schematic diagram of the request verifier 120 according to an embodiment.
  • the request verifier 120 includes a processing circuitry 410 coupled to a memory 215, a storage 220, and a network interface 240.
  • the data integrity manager 120 may include an optical character recognition (OCR) processor 230.
  • OCR optical character recognition
  • the components of the request verifier 120 may be communicatively connected via a bus 250.
  • the processing circuitry 210 may be realized as one or more hardware logic components and circuits.
  • illustrative types of hardware logic components include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), Application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components that can perform calculations or other manipulations of information.
  • the memory 215 may be volatile (e.g., RAM, etc.), non-volatile (e.g., ROM, flash memory, etc.), or a combination thereof.
  • computer readable instructions to implement one or more embodiments disclosed herein may be stored in the storage 220.
  • the memory 215 is configured to store software.
  • Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code).
  • the instructions when executed by the one or more processors, cause the processing circuitry 210 to perform the various processes described herein. Specifically, the instructions, when executed, cause the processing circuitry 210 to perform automatic verification of requests based on electronic documents, as discussed herein.
  • the storage 220 may be magnetic storage, optical storage, and the like, and may be realized, for example, as flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs), or any other medium which can be used to store the desired information.
  • flash memory or other memory technology
  • CD-ROM Compact Discs
  • DVDs Digital Versatile Disks
  • the OCR processor 230 may include, but is not limited to, a feature and/or pattern recognition processor (RP) 235 configured to identify patterns, features, or both, in unstructured data sets. Specifically, in an embodiment, the OCR processor 230 is configured to identify at least characters in the unstructured data. The identified characters may be utilized to create a dataset including data required for verification of a request.
  • RP pattern recognition processor
  • the network interface 240 allows the data integrity manager 120 to communicate with the enterprise system 130, the database 140, the web sources 150, or a combination of, for the purpose of, for example, collecting metadata, retrieving data, storing data, and the like.
  • Fig. 3 is an example flowchart 300 illustrating a method for automatically verifying requests based on electronic documents according to an embodiment.
  • the method may be performed by a request verifier (e.g., the request verifier 120).
  • a first dataset is created based on a first electronic document including information related to a transaction.
  • the first electronic document may include, but is not limited to, unstructured data, semi-structured data, structured data with structure that is unanticipated or unannounced, or a combination thereof.
  • S310 may further include analyzing the first electronic document using optical character recognition (OCR) to determine data in the electronic document, identifying key fields in the data, identifying values in the data, or a combination thereof.
  • OCR optical character recognition
  • analyzing the first dataset may include, but is not limited to, determining transaction parameters such as, but not limited to, at least one entity identifier (e.g., a consumer enterprise identifier, a merchant enterprise identifier, or both), information related to the transaction (e.g., a date, a time, a price, a type of good or service sold, etc.), or both.
  • entity identifier e.g., a consumer enterprise identifier, a merchant enterprise identifier, or both
  • information related to the transaction e.g., a date, a time, a price, a type of good or service sold, etc.
  • analyzing the first dataset may also include identifying the transaction based on the first dataset.
  • a first template is created based on the first dataset.
  • the first template may be, but is not limited to, a data structure including a plurality of fields.
  • the fields may include the identified transaction parameters.
  • the fields may be predefined.
  • Creating templates from electronic documents allows for faster processing due to the structured nature of the created templates. For example, query and manipulation operations may be performed more efficiently on structured datasets than on datasets lacking such structure. Further, organizing information from electronic documents into structured datasets, the amount of storage required for saving information contained in electronic documents may be significantly reduced. Electronic documents are often images that require more storage space than datasets containing the same information. For example, datasets representing data from 100,000 image electronic documents can be saved as data records in a text file. A size of such a text file would be significantly less than the size of the 100,000 images.
  • S330 may include determining whether the created first template meets at least one predetermined constraint.
  • a request may be eligible for verification if, e.g., the first template meets the at least one predetermined constraint.
  • the at least one predetermined constraint may include, but is not limited to, requirements on types of information needed for verification, accuracy requirements, or a combination thereof.
  • the information needed for verification may further include information required for successfully submitting VAT reclaims requests.
  • Determining whether the request is eligible for verification may reduce use of computing resources by only verifying using templates meeting minimal requirements.
  • S340 may further include determining at least one constraint based on the first template.
  • determining the at least one constraint may include searching in at least one database based on the first template (e.g., using a location of the merchant enterprise indicated in the first template).
  • S330 may also include analyzing at least one reporting requirement electronic document (e.g., a VAT reclaim form) to determine the at least one constraint. The analysis may further include performing OCR or other image processing on each reporting requirements electronic document.
  • additional data, replacement data, or both may be retrieved from at least one data source and included in the first template.
  • additional or replacement data upon retrieving the additional or replacement data, execution continues with S350.
  • a second electronic document is retrieved based on the first template.
  • S350 includes searching, based on data in the first template, in at least one web source.
  • a transaction identification number "123456789" indicated in a "Transaction ID" field of the first template may be utilized as a search query to find the second electronic document based on, e.g., metadata of the second electronic document including the transaction identification number "123456789.”
  • S350 further includes selecting the at least one web source based on the first template.
  • S360 it is determined, based on the first template and the second electronic document, whether the request indicated in the first electronic document is verified and, if so, execution continues with S370; otherwise, execution continues with S380.
  • S360 includes generating a second template for the second electronic document (e.g., using the method described further herein below with respect to Fig. 4).
  • S360 further includes comparing data in the first template with data in the second template.
  • S360 may include validating at least one of the first electronic document and the second electronic document. Determining whether a request is verified based on a first electronic document and a second electronic document is described further herein below with respect to Fig. 5.
  • the first electronic document and the second electronic document are stored in, e.g., a database including first electronic documents indicating VAT reclaim requests and corresponding second electronic documents indicating evidence supporting the respective requests.
  • the first electronic document and the second electronic document may be submitted together for a VAT reclaim.
  • S380 when it is determined that the request is not verified, at least one cause is determined.
  • S380 includes analyzing each mismatched set of parameters to analyze differences therein and analyzing the identified differences.
  • the causes may include, but are not limited to, missing evidence as compared to the actual report, errors in reports, duplicated reports, etc.
  • S380 may further include providing indications of a source that actually provided the mismatched data, the reasons for the mismatches, or both.
  • an indication that a particular employee or department that submitted the actual report may be provided.
  • an indication that the mismatch occurred due to smudging of a VAT reclaim form may be provided.
  • the cause of the mismatch may be determined to be a failure to reclaim all potentially reclaimed VATs.
  • a notification may be generated.
  • the notification may indicate whether the request is verified.
  • the notification may include the determined at least one cause.
  • Fig. 4 is an example flowchart S310 illustrating a method for creating a dataset based on an electronic document according to an embodiment.
  • the electronic document is obtained.
  • Obtaining the electronic document may include, but is not limited to, receiving the electronic document (e.g., receiving a scanned image) or retrieving the electronic document (e.g., retrieving the electronic document from a consumer enterprise system, a merchant enterprise system, or a database).
  • the electronic document is analyzed.
  • the analysis may include, but is not limited to, using optical character recognition (OCR) to determine characters in the electronic document.
  • OCR optical character recognition
  • key fields and values in the electronic document are identified.
  • the key field may include, but are not limited to, merchant's name and address, date, currency, good or service sold, a transaction identifier, an invoice number, and so on.
  • An electronic document may include unnecessary details that would not be considered to be key values. As an example, a logo of the merchant may not be required and, thus, is not a key value.
  • a list of key fields may be predefined, and pieces of data that may match the key fields are extracted.
  • a cleaning process is performed to ensure that the information is accurately presented. For example, if the OCR would result in a data presented as "121 1212005", the cleaning process will convert this data to 12/12/2005. As another example, if a name is presented as "Mo$den”, this will change to "Mosden”.
  • the cleaning process may be performed using external information resources, such as dictionaries, calendars, and the like.
  • S430 results in a complete set of the predefined key fields and their respective values.
  • a structured dataset is generated.
  • the generated dataset includes the identified key fields and values.
  • Fig. 5 is an example flowchart S360 illustrating a method for determining whether a request is verified based on a first electronic document and a second electronic document according to an embodiment.
  • the method is based further on a first template created for the first electronic document (e.g., a template created as described further herein above with respect to Fig. 4).
  • the first electronic document may indicate a request for a VAT reclaim
  • the second electronic document may indicate information used as evidence to support the VAT reclaim request (i.e., the second document may be an invoice, a receipt, etc.).
  • a second template is created based on the second electronic document.
  • S510 includes performing machine imaging on the second electronic document.
  • the second template may be created as described further herein above with respect to Fig. 4.
  • S520 the first template and the second template are compared.
  • S520 includes comparing each portion of the first template to a corresponding portion of the second template.
  • S520 may further include identifying the corresponding portions based on a structure of each template. As a non-limiting example, data in fields occupying the same relative location in each template may be corresponding.
  • S530 based on the comparison, it is determined if the request is verified.
  • S530 includes determining whether each set of corresponding portions matches above a predetermined threshold based on one or more matching rules.
  • a predetermined threshold based on one or more matching rules.
  • the values " €100" and “100.00” in the field "Price (Euros)" of the first template and the second template, respectively, may be determined to match.
  • any reference to an element herein using a designation such as "first,” “second,” and so forth does not generally limit the quantity or order of those elements. Rather, these designations are generally used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element must precede the second element in some manner. Also, unless stated otherwise, a set of elements comprises one or more elements.
  • the phrase "at least one of” followed by a listing of items means that any of the listed items can be utilized individually, or any combination of two or more of the listed items can be utilized. For example, if a system is described as including "at least one of A, B, and C," the system can include A alone; B alone; C alone; A and B in combination; B and C in combination; A and C in combination; or A, B, and C in combination.
  • the various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof.
  • the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices.
  • the application program may be uploaded to, and executed by, a machine comprising any suitable architecture.
  • the machine is implemented on a computer platform having hardware such as one or more central processing units ("CPUs"), a memory, and input/output interfaces.
  • the computer platform may also include an operating system and microinstruction code.
  • the various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such a computer or processor is explicitly shown.
  • various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit.
  • a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Character Discrimination (AREA)

Abstract

Cette invention concerne un système et un procédé de vérification automatique de demandes sur la base de documents électroniques. Ledit procédé comprend : l'analyse d'un premier document électronique pour déterminer au moins un paramètre de transaction, le premier document électronique indiquant la requête, le premier document électronique comprenant des données au moins partiellement non structurées; la création d'un premier modèle pour le premier document électronique, le premier modèle étant un ensemble de données structurées comprenant ledit/lesdits paramètre(s) de transaction déterminé(s); la récupération, sur la base du premier modèle, d'un second document électronique, le second document électronique indiquant des preuves pour la vérification la requête; et la détermination, sur la base du premier modèle et du second document électronique, du fait que la requête est vérifiée ou non.
EP16890887.9A 2016-02-15 2016-12-20 Vérification automatique de demandes sur la base de documents électroniques Withdrawn EP3417383A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662295159P 2016-02-15 2016-02-15
US15/361,934 US20170154385A1 (en) 2015-11-29 2016-11-28 System and method for automatic validation
PCT/US2016/067716 WO2017142618A1 (fr) 2016-02-15 2016-12-20 Vérification automatique de demandes sur la base de documents électroniques

Publications (2)

Publication Number Publication Date
EP3417383A1 true EP3417383A1 (fr) 2018-12-26
EP3417383A4 EP3417383A4 (fr) 2019-07-03

Family

ID=59626190

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16890887.9A Withdrawn EP3417383A4 (fr) 2016-02-15 2016-12-20 Vérification automatique de demandes sur la base de documents électroniques

Country Status (3)

Country Link
EP (1) EP3417383A4 (fr)
CN (1) CN108713198A (fr)
WO (1) WO2017142618A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10878514B2 (en) 2018-08-22 2020-12-29 International Business Machines Corporation Expense validator

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7827079B2 (en) * 2003-06-30 2010-11-02 Ebay Inc. Method and system for assessing and reporting VAT charges for network-based marketplace services
JP2006244238A (ja) * 2005-03-04 2006-09-14 Oki Electric Ind Co Ltd 識別コード確認装置
CN101075316A (zh) * 2007-06-25 2007-11-21 陆航程 一种电子票证交易认证管理方法、载体结构、系统、终端
US8774516B2 (en) * 2009-02-10 2014-07-08 Kofax, Inc. Systems, methods and computer program products for determining document validity
GB2471072A (en) * 2009-06-12 2010-12-22 Provenance Information Assurance Ltd Electronic document verification system
CN101593338A (zh) * 2009-07-13 2009-12-02 招商银行股份有限公司 一种处理电子交易请求的方法和系统
CN101950457A (zh) * 2010-09-06 2011-01-19 浪潮齐鲁软件产业有限公司 一种支持两种税控ic卡的自助办税终端的自助报税方法
CN102903171B (zh) * 2012-09-21 2014-05-07 国网山东省电力公司物资公司 自助式智能录入验审发票处理系统与方法
WO2014132256A1 (fr) * 2013-02-27 2014-09-04 Saft Isaac Système en ligne et procédés associés, destinés au traitement d'une récupération de la taxe sur la valeur ajoutée (tva)
US20150106247A1 (en) * 2013-02-27 2015-04-16 Isaac SAFT System and method for pursuing a value-added tax (vat) reclaim through a mobile technology platform

Also Published As

Publication number Publication date
EP3417383A4 (fr) 2019-07-03
CN108713198A (zh) 2018-10-26
WO2017142618A1 (fr) 2017-08-24

Similar Documents

Publication Publication Date Title
US20190130495A1 (en) System and method for automatic generation of reports based on electronic documents
US11062132B2 (en) System and method for identification of missing data elements in electronic documents
US20170169292A1 (en) System and method for automatically verifying requests based on electronic documents
US11138372B2 (en) System and method for reporting based on electronic documents
US20170323006A1 (en) System and method for providing analytics in real-time based on unstructured electronic documents
US20180011846A1 (en) System and method for matching transaction electronic documents to evidencing electronic documents
US20170193608A1 (en) System and method for automatically generating reporting data based on electronic documents
US20170323157A1 (en) System and method for determining an entity status based on unstructured electronic documents
EP3494495A1 (fr) Système et procédé pour remplir des documents électroniques
US20180025225A1 (en) System and method for generating consolidated data for electronic documents
EP3430540A1 (fr) Système et procédé pour la génération automatique de données de rapport basées sur des documents électroniques
US20180046663A1 (en) System and method for completing electronic documents
US20170161315A1 (en) System and method for maintaining data integrity
US10387561B2 (en) System and method for obtaining reissues of electronic documents lacking required data
US20180025224A1 (en) System and method for identifying unclaimed electronic documents
EP3417383A1 (fr) Vérification automatique de demandes sur la base de documents électroniques
US20170169519A1 (en) System and method for automatically verifying transactions based on electronic documents
US20180025438A1 (en) System and method for generating analytics based on electronic documents
WO2018027130A1 (fr) Système et procédé de génération de rapports sur la base de documents électroniques
WO2017201012A1 (fr) Système et procédé pour fournir des analyses en temps réel sur la base de documents électroniques non structurés
WO2017142615A1 (fr) Système et procédé de gestion d'intégrité de données
US20170193609A1 (en) System and method for automatically monitoring requests indicated in electronic documents
EP3491554A1 (fr) Mise en correspondance de documents électroniques de transaction avec des documents électroniques de preuve
EP3430584A1 (fr) Système et procédé de vérification automatique de transactions sur la base de documents électroniques
EP3497589A1 (fr) Système et procédé d'identification de documents électroniques

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180903

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20190605

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 20/04 20120101ALI20190529BHEP

Ipc: G06Q 30/04 20120101ALI20190529BHEP

Ipc: G06Q 20/38 20120101ALI20190529BHEP

Ipc: G06Q 20/42 20120101AFI20190529BHEP

Ipc: G06Q 20/40 20120101ALI20190529BHEP

Ipc: G06F 16/00 20190101ALI20190529BHEP

Ipc: G06Q 40/00 20120101ALI20190529BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20210210