WO2009079361A1 - Système et procédé de rapprochement automatisé de bons de commande - Google Patents

Système et procédé de rapprochement automatisé de bons de commande Download PDF

Info

Publication number
WO2009079361A1
WO2009079361A1 PCT/US2008/086559 US2008086559W WO2009079361A1 WO 2009079361 A1 WO2009079361 A1 WO 2009079361A1 US 2008086559 W US2008086559 W US 2008086559W WO 2009079361 A1 WO2009079361 A1 WO 2009079361A1
Authority
WO
WIPO (PCT)
Prior art keywords
parameters
comparisons
search
transaction
purchase orders
Prior art date
Application number
PCT/US2008/086559
Other languages
English (en)
Inventor
Randy Rucker
Lisa Rivers
David Nguyen
Brian Lochhead
Original Assignee
Paymetric, Inc.
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
Application filed by Paymetric, Inc. filed Critical Paymetric, Inc.
Publication of WO2009079361A1 publication Critical patent/WO2009079361A1/fr

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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • PO purchase order
  • a buyer may issue a purchase order to a vendor listing the goods to be purchased, the purchase amount, the payment terms, and any other required information.
  • the buyer will designate a PO number that should be included in an invoice.
  • the vendor will receive the purchase order, and assuming everything is correct, will subsequently ship the goods to the buyer.
  • the vendor may then send an invoice for the goods to the buyer.
  • the buyer can then use the PO number in the merchant reference field as a key to correlate the received invoice with the PO.
  • some vendors for various reasons e.g. their invoice systems do not support such functionality) do not include the PO number in the merchant reference field in their invoices.
  • level 1 transactions The above two types of transactions may be referred to as "level 1" transactions because they do not have a PO number in the merchant reference field. Automatic reconciliation for level 1 transactions may not be possible because of the lack of a PO number in the merchant reference field. Therefore, it would be beneficial to provide conventional reconciliation systems with a method and a system for improving the process of reconciling level 1 transactions.
  • Embodiments of the disclosure may provide a software system used for reconciling PO's and invoices.
  • An exemplary embodiment of the present disclosure introduces a method for reconciling transaction data, including identifying one or more transactions to be reconciled; aggregating one or more potential matching purchase orders; and creating a proposal that identifies one or more purchase orders that may correlate to the transaction to be reconciled; wherein creating a proposal comprises performing one or more search iterations to identify one or more purchase orders that fit within one or more parameters of the search iteration.
  • the one or more parameters may include at least one of following: city comparisons, card number comparisons, merchant to vendor relationship comparisons, date comparisons, or amount comparisons, and each subsequent search iteration may have a broader search criteria than a previous search iteration and a resulting list of purchase orders may be ranked in order from most narrow search parameters to most broad search parameters.
  • the method may further include automatically reconciling the transaction data if only one purchase order meets the one or more parameters.
  • Embodiments of the invention may further provide a computer program embodied on a computer-usable medium, the medium having stored thereon a sequence of instructions, when executed by a processor, causes the processor to execute a method for reconciling transaction data.
  • the method may include identifying one or more transactions to be reconciled; aggregating one or more potential matching purchase orders; and creating a proposal that identifies one or more purchase orders that may correlate to the transaction to be reconciled; wherein creating a proposal comprises performing one or more search iterations to identify one or more purchase orders that fit within one or more parameters of the search iterations.
  • the search iteration parameters may include at least one of following: city comparisons, card number comparisons, merchant to vendor relationship comparisons, date comparisons, or amount comparisons, and each subsequent search iteration may have a broader search criteria than a previous search iteration and a resulting list of purchase orders may be ranked in order from most narrow search parameters to most broad search parameters.
  • the computer program may further include automatically reconciling the transaction data if only one purchase order meets the one or more parameters.
  • Embodiments of the invention may further provide a system for reconciling transaction data, including a transaction identification module in communication with a database and configured to identify one or more transactions to be reconciled; a purchase order aggregation module in communication with a database and configured to aggregate one or more potential matching purchase orders; and a proposal module in communication with a database and configured to create a proposal that identifies one or more purchase orders that may correlate to the transaction to be reconciled, wherein creating a proposal comprises performing one or more search iterations to identify one or more purchase orders that fit within one or more parameters of the search iterations.
  • the one or more parameters may include at least one of following: city comparisons, card number comparisons, merchant to vendor relationship comparisons, date comparisons, or amount comparisons, and each subsequent search iteration may have a broader search criteria than a previous search iteration and a resulting list of purchase orders are ranked in order from most narrow search parameters to most broad search parameters.
  • the system may further include automatically reconciling the transaction data if only one purchase order meets the one or more parameters.
  • Embodiments of the invention may further provide a system for reconciling transaction data, including identifying means for identifying one or more transactions to be reconciled; aggregating means for aggregating one or more potential matching purchase orders; and creating means for creating a proposal that identifies one or more purchase orders that may correlate to the transaction to be reconciled; wherein creating a proposal comprises performing one or more search iterations to identify one or more purchase orders that fit within one or more parameters of the search iterations.
  • the one or more parameters may include at least one of following: city comparisons, card number comparisons, merchant to vendor relationship comparisons, date comparisons, or amount comparisons, and each subsequent search iteration may have a broader search criteria than a previous search iteration and a resulting list of purchase orders are ranked in order from most narrow search parameters to most broad search parameters.
  • the method may further include automatic means for automatically reconciling the transaction data if only one purchase order meets the one or more parameters.
  • FIG. 1 illustrates a flowchart of an exemplary process for reconciling purchase orders with a transaction.
  • FIG. 2 schematically illustrates an exemplary embodiment of an enterprise software environment including an exemplary purchase order reconciliation system of the present disclosure.
  • FIG. 3 schematically illustrates an exemplary embodiment an application communicably coupled to an exemplary purchase order reconciliation system of the present disclosure may create a proposal.
  • Fig. 4 schematically illustrates an exemplary embodiment of an application communicably coupled to an exemplary purchase order reconciliation system of the present disclosure may perform multiple searches in the matching logic of creating a proposal in Fig. 3.
  • FIG. 5 schematically illustrates embodiment of an application communicably coupled to an exemplary purchase order reconciliation system of the present disclosure may perform automatic reconciliation of transactions.
  • At least one embodiment of the invention may be implemented as a program product for use with a computer system or processor.
  • the program product may define functions of the exemplary embodiments (which may include methods) described herein and can be contained on a variety of computer readable media.
  • Illustrative computer readable media include, without limitation, (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive); (ii) alterable information stored on writable storage media (e.g., computer disks for use with a disk drive or hard-disk drive, writable CD-ROM disks and DVD disks, zip disks, portable memory devices, and any other device configured to store digital data); and (iii) information conveyed across communications media, (e.g., a computer, telephone, wired network, or wireless network). These embodiments may include information shared over the Internet or other computer networks. Such computer readable media, when carrying computer-readable instructions that perform methods of the invention, may represent embodiments of the present invention.
  • non-writable storage media e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive
  • software routines or modules that implement embodiments of the invention may be part of an operating system or part of a specific application, component, program, module, object, or sequence of instructions, such as an executable script.
  • Such software routines typically include a plurality of instructions capable of being performed using a computer system or other type or processor configured to execute instructions from a computer readable medium.
  • programs typically include or interface with variables, data structures, etc. that reside in a memory or on storage devices as part of their operation.
  • various programs described herein may be identified based upon the application for which they are implemented.
  • the present disclosure relates generally to reconciling purchase orders
  • PO's invoices and/or billing statements in an enterprise software environment.
  • a PO is a commercial document issued by a buyer to a seller, indicating the type, quantities and agreed prices for products or services that the seller will provide to the buyer. PO's also usually specify additional conditions such as terms of payment, terms for liability and freight responsibility, and required delivery date.
  • PO's are matched with transactions including invoices, purchasing card statements and packing slips before the transactions are paid, this process may also be referred to as reconciliation.
  • the present disclosure relates to a system used for reconciling PO's and transactions that do not have a PO number in the merchant reference field, which may be referred to as level 1 transactions.
  • Level 1 transactions are transactions that do not have a PO number in the merchant reference field which links an invoice or a line transaction on a credit card statement with a PO.
  • a PO number might be included on an invoice.
  • the receiving entity can then use the PO number included on the invoice to reconcile the invoice with a transaction.
  • a daily statement from a credit card issuing bank may contain information regarding only the amount, date, merchant and credit card number, but may not provide a purchase order number to reconcile the transaction.
  • An exemplary embodiment of the present disclosure may enable automatic reconciliation of level 1 transactions. Further, an embodiment of the present disclosure speeds up user-facilitated reconciliation of level 1 transactions by providing a user with additional information upon which the user can manually make a reconciliation decision.
  • modules may be general-purpose, or they may have dedicated functions such as memory management, program flow, instruction processing, object storage, etc.
  • the modules can be implemented in any way known in the art.
  • a module is implemented in a hardware circuit including custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.
  • One or more of the modules may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
  • one or more of the modules are implemented in software for execution by various types of processors.
  • An identified module of executable code may, for instance, include one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, procedure, or function. Further, the executables of an identified module need not be physically located together, but may include disparate instructions stored in different locations that, when joined logically together, include the module and achieve the stated purpose for the module.
  • a "module" of executable code could be a single instruction, or many instructions, and may be distributed over several different code segments, among different programs, and across several memory devices.
  • operational data may be identified and illustrated in association with one or more modules, and may be embodied in any suitable form and organized within any suitable type of data structure.
  • the operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, as electronic signals on a system or network.
  • higher-level components may be used as modules.
  • one module may include an entire computer acting as a network node.
  • Another module may include of an off-the-shelf or custom program, such as a database management system.
  • These higher-level modules may be decomposable into smaller hardware or software modules corresponding to different parts of a software program and identifiable chips (such as memory chips, ASICs, or a CPU) within a computer.
  • a network module defines a communications path between endpoints and may include an arbitrary amount of intermediate modules.
  • a network module may encompass various pieces of hardware, such as cables, routers, and modems, as well as the software necessary to use that hardware.
  • Another network module may encompass system calls or device-specific mechanisms such as shared memory, pipes, or system messaging services.
  • a third network module may use calling conventions within a computing module, such as a computer language or execution environment. Information transmitted using the network module may be carried upon an underlying protocol, such as HTTP, BXXP, or SMTP, or it may define its own transport over TCP/IP, IPX/SPX, Token Ring, ATM, etc.
  • a network module may transform the data through the use of one or more computing modules.
  • a PO is created with a payment term and purchasing card number.
  • the purchasing card and associated purchasing card number may be a credit card issued by American Express, Discover, Master-Card, Visa, or any other credit card issuing bank, for example.
  • the purchase order is transmitted to the supplier in step 104, and the supplier ships the goods in step 106, which are received by the buyer in step 108.
  • the supplier may charge the purchasing card at step 110, and the bank may authorize the charge at step 112.
  • the bank pays the supplier in step 114, referred to as "merchant" in the drawing.
  • the bank may bill the card account in step 118 and the transaction on the bank's statement may be loaded into an Enterprise Resource Planning ("ERP") software system, such as products offered by SAP AG, in step 120.
  • ERP Enterprise Resource Planning
  • the transaction may be matched with a PO and/or goods receipt (“GR"), an invoice receipt (“IR”) may be created, and the transaction, the PO, and the goods receipt may be correlated via a three way match in step 122.
  • ERP Enterprise Resource Planning
  • the POS 200 includes a memory 202, a computer readable medium 204, a matching module 206, a transaction database 208, and a PO database 210.
  • the POS 200 may be communicably coupled to a network including one or more other systems.
  • the POS 200 is communicably coupled to a terminal (not shown).
  • the terminal may include an output device, such as a monitor, and one or more input devices, such as a mouse and/or keyboard.
  • the transaction database 208 of the POS 200 may include records of one or more payment transactions or charges.
  • a transaction may be the electronic record of a charge on a payment card account.
  • a cardholder could be buying a widget over the counter, over the phone, or paying for a PO, or a paying a service invoice.
  • the merchant may have multiple transactions/payments for the PO for each shipment.
  • a payment transaction record may include charge data from an invoice, a purchase receipt, a daily file, a statement or any other data related to a transaction.
  • Each record may include transaction data such as purchasing card number, merchant, a predefined merchant to vendor relationship, transaction amount, transaction date, and merchant's city.
  • Merchant information may be provided by a purchasing card statement indicating the merchant account that processed the transaction.
  • Vendor information may be provided from the purchaser and listed on the PO.
  • a predefined merchant to vendor relationship may exist when the merchant listed on the transaction record is directly correlated to a vendor on a PO. This merchant to vendor relationship may be known prior to reconciliation, or the relationship may be derived from a prior transaction with a merchant that was reconciled to a PO with a vendor.
  • a PO database 210 of the POS 200 may include one or more PO's.
  • the PO's may be indexed using a key, such as a PO number, to improve search efficiency.
  • each record may include various information, such as payment terms, PO number, purchasing card number, purchasing organization or group, date created, vendor number, vendor city, total amount, ready to invoice amount, un-invoiced amount, and delivery date.
  • a daily batch process may import charges and other purchase information into the transactions database 208.
  • some of these transaction records may lack a PO number in the merchant reference field and it must be determined what PO matches the transaction record.
  • the transaction may tagged as such.
  • a transaction may be tagged as being based on a PO if, the card is marked for only PO-based transactions, the merchant is linked to a vendor number and the vendor has been identified as a PO Vendor, or a valid PO number is found in the merchant reference field of the transaction.
  • the transaction may still undergo further processing.
  • the transaction may not be tagged as based on a PO, but the transaction would still undergo processing to attempt to match a PO to the transaction because the transaction may have been based on a PO.
  • some purchase cards are used for both PO-based and non-PO-based transactions, and any transaction based on these purchase cards will require further processing as they may have been PO based.
  • a valid PO number can be found in the merchant reference field of the transaction record, that PO number is associated to the transaction record. Any transaction not having an associated PO requires further processing.
  • a proposal listing one or more candidate POs that may be associated with the transaction record may be created by the matching module 206 of the POS 200.
  • a method 300 for creating proposals 302 to list one or more PO candidates to be associated with a transaction may include a transaction identification module 304, a PO aggregation module 306, and a matching module 308 for matching PO's to transactions and creating proposals 302.
  • the transaction identification module 304 may receive one or more transaction records from the transaction database 208.
  • a purpose of the transaction identification module 304 may be to determine which transactions need a proposal 302 and output to the matching module 308 those transaction records that need proposals. For example, transactions without a PO number in the merchant reference field may require proposals 302.
  • one or more attributes may be associated with each transaction. For example, an "attempt proposal" attribute may be a yes or no value that indicates whether a proposal 302 should be attempted. In an exemplary embodiment, the default attempt proposal attribute value may be yes.
  • the attempt attribute is a mechanism for excluding certain transactions from being processed by the proposal creation process. Transactions that were not PO-based may be included in the proposal creation phase.
  • the PO aggregation module 306 is a database that may receive one or more PO's, which may include, without limitation, one or more PO's from the PO database 210.
  • One purpose of the PO aggregation module 306 is to summarize PO history to improve search efficiency.
  • An exemplary embodiment of the PO aggregation module 306 may build a list of PO's to search against and stores the PO's in new tables in the PO database 210.
  • only PO's that meet the following conditions are included in the list of PO's: (a) the payment terms of the PO must be purchase card; (b) the PO must have a purchase card number; and (c) the PO must have been created within a defined period of time.
  • the PO aggregation module 306 may create a PO header table and an un-invoiced goods receipts table.
  • the PO header table may include the following columns: 1 ) PO number, 2) purchase card number or internal ID, 3) purchasing organization and group, 4) date created, 5) vendor number, 6) vendor city, 7) total amount, 8) ready- to-invoice amount, and 9) un-invoiced amount.
  • the un-invoiced goods receipts table includes the following columns: 1 ) PO number and 2) goods receipt number, and 3) ready-to-invoice amount.
  • the matching module 308 may receive one or more inputs, including, without limitation, transaction records from the transaction identification module 304 that need a proposal because they do not have a PO number in the merchant reference field.
  • a function of the matching module 308 may be to identify one or more PO's that possibly correlate to a transaction and output this information as a proposal 302. In identifying one or more PO's that may correlate to a transaction, efforts may be made to eliminate a PO from being proposed for multiple transactions.
  • these efforts may include ranking the PO's according to how closely the dollar amounts match the transaction, exact dollar amount matches having a higher priority, and multiple search iterations to match PO's to a transaction with expanding or broadening search criteria may also be used, as discussed later.
  • the first search iteration may have very detailed search criteria that may result in a near exact match of the PO to the transaction to allow for automatic reconciling of the transaction without requiring a user to manually approve a PO/transaction match.
  • the matching module 308 may perform one or more search iterations. Each search iteration may return a set of data that includes one or more PO's from the PO aggregation module 306 that may correlate with the transaction.
  • configurable criteria may include, without limitation, city comparisons (e.g., comparing the merchant's city to the PO's vendor city), date comparisons wherein an exemplary embodiment includes a date range (e.g., comparing the transaction date to expected delivery date(s) or to PO create date), amount comparisons within a certain range, comparing the transaction amount to the total amount, un-invoiced amount, ready- to-invoice amount, goods receipt amount, and whether to include or exclude freight when summing PO amounts.
  • city comparisons e.g., comparing the merchant's city to the PO's vendor city
  • date comparisons wherein an exemplary embodiment includes a date range (e.g., comparing the transaction date to expected delivery date(s) or to PO create date)
  • amount comparisons within a certain range comparing the transaction amount to the total amount, un-invoiced amount, ready- to-invoice amount, goods receipt amount, and whether to include or exclude freight when summing PO amounts.
  • matching logic 402 may include a first pass 404 and a second pass 406.
  • first pass 404 the configurable criteria may include to match the city, match the delivery date, and no range on the amount comparison.
  • First pass 404 may find purchase order 408 and purchase order 410 that match this search criteria.
  • second pass 406 the search criteria may be broadened versus first pass 404, and might include PO's that match the creation date of the purchase order to the transaction date and a 3% range on the amount comparison between the PO's and the transaction.
  • Second pass 406 may then find the purchase orders 408 and 410, and purchase orders 412, 413 and 414.
  • the resulting list of PO's may be stored as a proposal 302 associated with the transaction and the resulting list of PO's in the proposal 302 may receive a ranking with purchase orders 408 and 410 ranked higher than purchase orders 412, 413 and 414.
  • the matching module 308 may include one or more configurable options.
  • configurable options may include, without limitation, 1 ) auto-accept (i.e. automatically accept the proposal if only one matching PO is found), 2) freight considerations (e.g., including/excluding freight when summing PO amounts), and 3) variable amount ranges (e.g., defining a percentage range above and/or below the transaction amount).
  • PO's and transactions may be reconciled either automatically or manually.
  • a proposal 302, such as the proposal 302 may be tied to a transaction that does not have a PO number in the merchant reference field as discussed above.
  • the proposal 302 may then be displayed to a user, the user may then individually accept a proposal 302 by accepting and matching a PO within the proposal 302 to a transaction.
  • the user may view the PO's within the proposal 302 and the various amounts, dates, etc., pertaining to each PO 1 that may be used in the matching module 308.
  • the user may also be able to view what other transactions have the same PO included on their proposals and may have facilitated acceptance.
  • a user may accept or decline multiple proposals 302 at a time.
  • accepting a proposal 302 associates a single PO to the transaction, and physically deletes the attached proposal.
  • transactions 502 and 504 each may have a single associated PO.
  • Reconciliation may be attempted at a step 506 for each transaction, and if the reconciliation is successful, an invoice receipt may be generated at a step 508, and if the reconciliation is unsuccessful, the results may be stored with the transaction at a step 510.
  • the present disclosure introduces a method for reconciling transaction data, including identifying one or more transactions to be reconciled; aggregating one or more potential matching purchase orders; and creating a proposal that identifies one or more purchase orders that may correlate to the transaction to be reconciled; wherein creating a proposal comprises performing one or more search iterations to identify one or more purchase orders that fit within the search iteration parameters.
  • the search iteration parameters may include at least one of following: city comparisons, card number comparisons, merchant to vendor relationship comparisons, date comparisons, or amount comparisons, and each subsequent search iteration may have a broader search criteria than the previous search iteration and the resulting list of purchase orders may be ranked in order from most narrow search parameters to most broad search parameters.
  • the method may further include automatically reconciling the transaction data if only one purchase order meets the designated search criteria.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Système et procédé destinés à rapprocher des données de transaction, comprenant les étapes consistant à identifier une ou plusieurs transactions à rapprocher; regrouper un ou plusieurs bons de commande correspondants potentiels; et créer une proposition qui identifie un ou plusieurs bons de commande qu'il est possible de corréler avec la transaction à rapprocher, la création d'une proposition comprenant l'exécution d'une ou de plusieurs itérations de recherche de manière à identifier un ou plusieurs bons de commande qui satisfont à un ou plusieurs paramètres des itérations de recherche.
PCT/US2008/086559 2007-12-14 2008-12-12 Système et procédé de rapprochement automatisé de bons de commande WO2009079361A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US1381807P 2007-12-14 2007-12-14
US61/013,818 2007-12-14

Publications (1)

Publication Number Publication Date
WO2009079361A1 true WO2009079361A1 (fr) 2009-06-25

Family

ID=40795875

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/086559 WO2009079361A1 (fr) 2007-12-14 2008-12-12 Système et procédé de rapprochement automatisé de bons de commande

Country Status (1)

Country Link
WO (1) WO2009079361A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10580021B2 (en) 2012-01-03 2020-03-03 International Business Machines Corporation Product offering analytics
CN111708767A (zh) * 2020-05-12 2020-09-25 苏宁云计算有限公司 数据核对方法、装置、存储介质及计算机设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020046147A1 (en) * 2000-03-06 2002-04-18 Livesay Jeffrey A. Method and process for providing relevant data, comparing proposal alternatives, and reconciling proposals, invoices, and purchase orders with actual costs in a workflow process

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020046147A1 (en) * 2000-03-06 2002-04-18 Livesay Jeffrey A. Method and process for providing relevant data, comparing proposal alternatives, and reconciling proposals, invoices, and purchase orders with actual costs in a workflow process

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10580021B2 (en) 2012-01-03 2020-03-03 International Business Machines Corporation Product offering analytics
CN111708767A (zh) * 2020-05-12 2020-09-25 苏宁云计算有限公司 数据核对方法、装置、存储介质及计算机设备
CN111708767B (zh) * 2020-05-12 2022-11-15 苏宁云计算有限公司 数据核对方法、装置、存储介质及计算机设备

Similar Documents

Publication Publication Date Title
US20100153241A1 (en) System and method for automated reconciliation of purchase orders
US8131619B1 (en) Service fee-based payment processing
US7606766B2 (en) Computer system and computer-implemented method for selecting invoice settlement options
US7970654B2 (en) System and method for processing single sale transactions involving one or more payors
US10497000B1 (en) Dynamic return privileges
US20130054421A1 (en) Method and system for processing transactions
EP1877928A1 (fr) Systeme et methode automatises de traitement de transactions avec conversion monetaire
US10650472B2 (en) Single use account pool processing system and method
US20130144782A1 (en) Electronic invoice payment prediction system and method
US20180330351A1 (en) System and method for allocating charges away from a tax account
US20230281582A1 (en) Systems, methods, and apparatuses for facilitating transfers between user commerce accounts associated with a merchant of a commerce platform
US20130085913A1 (en) Automated sales tax payment system
US20190236694A1 (en) Predictive risk management for supply chain receivables financing
US8321281B2 (en) Automated sales tax payment system
US20060086787A1 (en) Systems and methods for facilitating purchases and tax recovery
US20060089890A1 (en) Performance monitoring system, method and apparatus
CN112750006A (zh) 农产品交易系统、方法、设备及存储介质
KR102288517B1 (ko) 정산 서버 및 그 방법
WO2009079361A1 (fr) Système et procédé de rapprochement automatisé de bons de commande
US20230359984A1 (en) Methods and systems for inventory management for blockchain-based transactions
US20210182304A1 (en) Distribution management system
US20210090035A1 (en) System and method for transmitting data over authorized transmission channels
US20140114820A1 (en) Method and system for managing credit disputes associated with account payables of an organization
CA2993716A1 (fr) Gestion de risque predictive destinee au financement de debiteurs de chaine d'approvisionnement
US11769151B2 (en) Methods and systems for rate-limiting control of transaction processing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08861768

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 27/09/2010)

122 Ep: pct application non-entry in european phase

Ref document number: 08861768

Country of ref document: EP

Kind code of ref document: A1