WO2014041642A1 - 決済業務支援システムおよび決済業務支援方法 - Google Patents

決済業務支援システムおよび決済業務支援方法 Download PDF

Info

Publication number
WO2014041642A1
WO2014041642A1 PCT/JP2012/073362 JP2012073362W WO2014041642A1 WO 2014041642 A1 WO2014041642 A1 WO 2014041642A1 JP 2012073362 W JP2012073362 W JP 2012073362W WO 2014041642 A1 WO2014041642 A1 WO 2014041642A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
information
buyer
data
terminal
Prior art date
Application number
PCT/JP2012/073362
Other languages
English (en)
French (fr)
Inventor
光宏 可西
雄二 広瀬
優介 海老根
俊久 小山
隆博 杉浦
Original Assignee
株式会社 日立製作所
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 株式会社 日立製作所 filed Critical 株式会社 日立製作所
Priority to IN1841DEN2015 priority Critical patent/IN2015DN01841A/en
Priority to SG11201501757SA priority patent/SG11201501757SA/en
Priority to PCT/JP2012/073362 priority patent/WO2014041642A1/ja
Priority to US14/427,729 priority patent/US20160125486A1/en
Priority to CN201280075756.1A priority patent/CN104641390B/zh
Priority to JP2014535288A priority patent/JP5927304B2/ja
Priority to TW102124734A priority patent/TWI522947B/zh
Publication of WO2014041642A1 publication Critical patent/WO2014041642A1/ja

Links

Images

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/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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • 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/405—Establishing or using transaction specific rules

Definitions

  • the present invention relates to a settlement business support system and a settlement business support method.
  • the electronic payable debt information is received from the payable debtor terminal and stored in a memory, and a unique electronic bond code is allocated to each payable debt information in the memory, and the payable debt information is registered in the electronic bond ledger database.
  • the debt management department, the settlement management department that obtains information on deposits made by designating electronic bond codes from payable debtors from the terminals of financial institutions and stores them in the deposit database 6, and the deposit information stored in the deposit database
  • An application management unit that executes an application process such as deleting the electronic bond information from the electronic bond book database by reading and executing the electronic bond information search in the electronic bond book database and deleting the electronic bond information record identified by the search process
  • Application result notification unit that extracts attribute information of electronic claims that have been processed from the electronic claim book database and notifies them to the accounts payable terminal, etc. Configured, receivables clearing management system (see Patent Document 1) have been proposed.
  • BtoB platform services that share information among multiple businesses and become places for business-to-business transactions on the Internet have also appeared.
  • These platforms enable inter-company collaboration for various tasks such as product design, sales, production, procurement, and payment.
  • the transactions and debts between companies are determined by transactions on these platforms, but the settlement methods (for example, remittance, direct debit, bills, checks, etc.) are individually decided between the companies, and are not unified through the platform. . Therefore, significant cooperation is not achieved between the inter-company transaction on the above-mentioned platform and the bank transaction accompanying the subsequent settlement.
  • an object of the present invention is to provide a technique that enables inter-business transactions and bank transactions to be linked to improve the efficiency and cost reduction of various settlement operations.
  • a computer that mediates electronic commerce between companies receives invoice data addressed to a buyer from a supplier terminal in electronic commerce, stores it in a storage device, In response to an acquisition request from the buyer's terminal, the invoice data is read from the storage device and transmitted to the buyer's terminal, and the buyer's terminal issues an acquisition request for the invoice data addressed to the buyer.
  • Scheduled data is generated and transmitted to the computer, and the computer Among the payment schedule data received from the above, the payment schedule data common to the predetermined items determined in advance or specified items received from the buyer terminal is specified, and the payment amount in each of the specified payment schedule data is summed up.
  • the payment schedule data is merged, and the merged payment schedule data is stored in a storage device as aggregated payment schedule data.
  • the settlement service support system of the present invention receives invoice data addressed to a buyer from a supplier terminal in electronic commerce, stores it in a storage device, and responds to an acquisition request from the buyer terminal.
  • a process of reading data from the storage device and transmitting it to the buyer's terminal, and the buyer's terminal gives the invoice data predetermined payment information or payment information designated by the buyer from the input device.
  • the process of receiving the payment schedule data addressed to the supplier generated and the payment schedule data that is common to the predetermined predetermined item or the predetermined item specified from the buyer terminal among the received payment schedule data is specified. Then, the payment amounts in the specified payment schedule data are added together and merged with the corresponding payment schedule data, and the merged payment is supported.
  • a computer that performs processing for storing the schedule data in the storage device as aggregated payment schedule data, and sends a request for acquiring bill data addressed to the buyer to the computer. , Receiving the corresponding invoice data from the computer, and providing the invoice data to the supplier with predetermined settlement information or settlement information designated by the buyer from the input device.
  • a supplier having a computing device that executes a process for transmitting to the computer the terminal of the buyer, and a billing data addressed to the buyer in electronic commerce, and a computing device that executes the process to generate and send to the computer And a terminal.
  • inter-company transactions and bank transactions can be linked to improve the efficiency of various settlement operations and reduce costs.
  • FIG. 1 is a diagram showing an example of a network configuration including the settlement service support system of this embodiment.
  • a settlement service support system 10 shown in FIG. 1 is a computer system that enables inter-company transactions and bank transactions to be linked to improve the efficiency of various settlement operations and reduce costs.
  • This settlement service support system 10 is a computer that mediates electronic commerce between companies, and includes a platform server 100 that provides a BtoB platform, a supplier terminal 200 that accesses the platform server 100 and uses a platform service, and a buyer terminal 300. Contains.
  • the platform server 100, the supplier terminal 200, and the buyer terminal 300 are connected to be communicable via the network 120.
  • the above-described supplier terminal 200 is a terminal used by a supplier company that sells products to other companies in electronic commerce.
  • the buyer terminal 300 is a terminal used by buyer companies who purchase products from other companies in electronic commerce.
  • the above-described network 120 is also connected with a bank system 400 used for settlement along with electronic commerce.
  • the platform server 100, the supplier terminal 200, and the buyer terminal 300 may access the bank system 400 of the bank that has opened the account via the network 120 through authentication, etc., and request necessary information and processing. I can do it.
  • FIG. 2 is a diagram illustrating a configuration example of the platform server 100 of the present embodiment.
  • the platform server 100 which is a computer constituting the settlement transaction support system 10, includes a storage device 101 composed of a suitable non-volatile storage device such as a hard disk drive, a memory 103 composed of a volatile storage device such as RAM, and a storage device 101.
  • the stored program 102 is read into the memory 103 and executed to perform overall control of the device itself, and perform various determinations, computations, and control processes.
  • a communication device 105 is provided.
  • the storage device 101 stores a program 102 for implementing functions necessary as an information processing device that constitutes the settlement operation support system 10 of the present embodiment, and data 110 necessary for various processes.
  • the data 110 includes invoice data 125, which will be described later, and various data generated from the invoice data 125 and other information. The same applies to the supplier terminal 200 and the buyer terminal 300.
  • the above-described supplier terminal 200 has a general hardware configuration as a computer, and is configured with an appropriate non-volatile storage device such as a hard disk drive, like the platform server 100.
  • the storage device 201, a memory 203 composed of a volatile storage device such as a RAM, and a program 202 held in the storage device 201 are read out and executed in the memory 203 to perform overall control of the device itself, and various determinations, computations and controls
  • An arithmetic device 204 such as a CPU that performs processing, a communication device 205 that is connected to a network and handles communication processing with other devices, a keyboard that accepts input from a person in charge of a supplier company that is a user, an input device 206 such as a mouse, and a processing result Display, speakers, etc.
  • An output device 207 In the storage device 201, a program 202 for implementing functions necessary as an information processing device constituting the settlement service support system 10 of the present embodiment and data 210 necessary for various processes are stored.
  • the buyer terminal 300 also has the same hardware configuration as the above-described supplier terminal 200, and a storage device 301 composed of a suitable non-volatile storage device such as a hard disk drive, a volatile memory such as a RAM, etc.
  • a storage device 301 composed of a suitable non-volatile storage device such as a hard disk drive, a volatile memory such as a RAM, etc.
  • Arithmetic unit such as a CPU that performs various determinations, computations, and control processes as well as performing overall control of the device itself by reading out and executing a memory 303 configured by a volatile storage device and a program 302 held in the storage device 301 to the memory 303
  • the output device 307 is provided.
  • a program 302 for implementing functions necessary as an information processing device constituting the settlement service support system 10 of the present embodiment, and data 310 necessary for various processes are stored.
  • each information processing apparatus that is, the platform server 100, the supplier terminal 200, the buyer terminal 300, and the like constituting the payment transaction support system 10 of the present embodiment.
  • the functions described below can be said to be functions that are implemented by executing the programs included in the platform server 100, the supplier terminal 200, the buyer terminal 300, and the like that constitute the settlement business support system 10, for example.
  • the platform server 100 receives invoice data addressed to the buyer from the supplier terminal in the electronic commerce, that is, the supplier terminal 200, stores it in the storage device 101, and responds to an acquisition request from the buyer terminal, that is, the buyer terminal 300.
  • the bill data is read from the storage device 101 and transmitted to the buyer terminal 300.
  • the buyer terminal 300 sends an invoice data acquisition request addressed to the buyer to the platform server 100, receives the corresponding invoice data from the platform server 100, and sets the predetermined invoice data to the invoice data. It has a function of generating payment schedule data addressed to the supplier by giving information for payment specified by the buyer from the information or the input device 301 and transmitting it to the platform server 100.
  • the platform server 100 identifies the predetermined payment item received from the buyer terminal 300 described above, or the payment item data common to the predetermined item specified from the buyer terminal 300, and is identified here.
  • the payment amounts in the respective payment schedule data are added together and merged with the corresponding payment schedule data, and the merged payment schedule data is stored in the storage device 101 as aggregated payment schedule data.
  • the settlement business support system 10 having such a function automatically generates payment schedule data having utility value on the buyer side based on the invoice data (electronic data) obtained from the supplier side, and further, the bank account of the payment destination is stored.
  • the payment schedules that are calculated together, such as the same payment amount, are merged and aggregated to reduce the number of actual settlement processing (transfer processing to the bank account specified by the supplier) that will be performed thereafter. By reducing the number of transactions at the time of settlement, the processing efficiency can be improved, and the settlement cost as well as the labor and time of work can be reduced.
  • the buyer terminal 300 described above has a function of causing the output device 307 to display the invoice data received from the platform server 100.
  • the buyer terminal 300 uses the input device to display the result of the buyer collating the content indicated by the invoice data displayed on the output device 307 with the content indicated by the paper medium invoice sent from the supplier to the buyer.
  • 306 has a function to accept at 306.
  • the buyer terminal 300 pays based on the above invoice data. It has a function of executing generation of gold information and transmission of the information on accounts payable to the platform server 100.
  • the buyer terminal 300 sends the difference information to the platform server 100. It has a function to transmit.
  • the platform server 100 has a function of receiving the difference information described above from the buyer terminal 300, storing the difference information in the storage device 101, and transmitting a confirmation request regarding the difference to the supplier terminal 200.
  • Phapiao used in China is an example.
  • Pha Piao (Invoicing) is an invoice or receipt in China, which uses a statutory voting form issued by a tax institution.
  • the platform server 100 when the platform server 100 receives a payment request from the buyer terminal 300, the platform server 100 reads the aggregated payment schedule data related to the buyer from the storage device 101, and the bank system 400 of the buyer's using bank indicated by the aggregated payment schedule data. On the other hand, it has a function of transmitting a settlement processing request according to the contents indicated by the aggregated payment schedule data.
  • the platform server 100 generates a payment notification regarding the corresponding invoice data for which the settlement processing request is made in accordance with the processing for transmitting the settlement processing request to the bank system 400 of the buyer's bank, and the corresponding supplier terminal 200. It has the function to transmit to.
  • the settlement business support system 10 having such a function can transmit a settlement processing request based on pre-aggregated payment schedule data to the bank system 400, which can reduce the number of transfers and transfer costs associated therewith. It becomes possible. Further, by making the above-mentioned payment notification, the supplier side can detect that the payment action on the buyer side has been completed before the notification from the bank system 400. In addition, there is an effect that the platform server 100 and the bank system 400 in the settlement service support system 10 can be linked.
  • the buyer terminal 300 has a function of acquiring aggregated payment schedule data from the platform server 100 and displaying it on the output device 307 as the payment request is transmitted to the platform server 100. In this case, the buyer terminal 300 determines whether or not the payment request can be made by comparing the content indicated by the aggregated payment schedule data with the content indicated by the paper invoice sent from the supplier to the buyer.
  • the input device 306 has a function of receiving the result.
  • the buyer terminal 300 has a function of executing transmission of the payment request to the platform server 100 when the above result received by the input device 306 approves the payment request. .
  • the buyer terminal 300 does not transmit the payment request to the platform server 100 and indicates that the rejection has been made in advance. It has a function of transmitting to a predetermined terminal such as an administrator terminal in a defined buyer company.
  • the settlement business support system 10 reflects the result of collation between the invoice of the paper medium and the aggregated payment schedule data in the subsequent processing, and the accuracy of the payment request and the subsequent processing Good accuracy can be maintained.
  • the platform server 100 has a function of receiving information on accounts payable based on the invoice data from the buyer terminal 300 and storing the information on the accounts payable in the storage device 101.
  • the platform server 100 transmits the above-described payment processing request to the bank system 400 of the buyer's bank, and the payment information corresponding to the identification information of the invoice data included in the payment processing request is included. It has a function of specifying information in the storage device 101 and executing an application process related to the information on the corresponding accounts payable.
  • the settlement business support system 10 has such a function, so that the accounts payable application process is automatically executed, and the business efficiency can be improved.
  • the platform server 100 generates the above-mentioned payment notice or information on payment contents to the supplier included in the payment processing request or payment notice in response to an instruction from the supplier terminal 200, and the supplier in the supplier's bank uses the supplier. Information on the payment schedule of the current account and the function of storing the information in the storage device 101.
  • the platform server 100 has a function of receiving information on accounts receivable based on the invoice data from the supplier terminal 200 and storing it in the storage device 101. Further, the platform server 100 matches the above information of the payment schedule and the information of the accounts receivable, specifies the information on the accounts receivable corresponding to the identification information of the bill data included in the information of the payment schedule, in the storage device 101, It has a function of generating information on the application schedule for the corresponding accounts receivable.
  • the settlement business support system 10 can automatically generate information for receivables scheduled to be receivable, and the efficiency of the receivable revocation process when the actual payment is confirmed later. Can be good.
  • the platform server 100 receives a notification from the bank system 400 of the supplier's bank about the fact of payment to the above-mentioned supplier's account, and details of the payment indicated by the notification and information on the account receivable cancellation plan described above. Are matched, information on the account receivables corresponding to the above-mentioned payment contents is specified, and a determination is made as to whether or not the amount of money received for the specified accounts receivable is excessive or insufficient.
  • the platform server 100 executes the receivable clearing process specified above. If there is, there is a function of transmitting excess / deficiency information to the supplier terminal 200 and the buyer terminal 300. Even if there is an excess or deficiency of the deposit, the accounts receivable application process may be performed. In this case, if there is a shortage, only the deposit will be applied. In addition, both transmission and cancellation of excess / deficiency information may be performed.
  • the platform server 100 and the bank system 400 in the settlement business support system 10 can be linked, and the account receivable application business can be made efficient. In addition, it is possible to cope with a situation where there is an excess or deficiency in the deposit amount from the buyer.
  • the settlement business support system 10 of the present embodiment can identify invoice data and information on accounts receivable in which there is an excess or deficiency in the deposit amount, and track the contents.
  • office work such as confirmation of evidence when excess or deficiency of the deposit amount occurs is saved, and it is possible to prevent administrative errors and fraud.
  • the platform server 100 reads the above-described aggregated payment schedule data from the storage device 101 for each of one or more sets of suppliers and buyers, offsets the payment amount between the suppliers and buyers, and remains after the offsetting. Sends a request for settlement processing according to the contents indicated by the aggregated payment schedule data for the remaining bonds described above to the bank system 400 of the supplier or buyer's bank indicated by the payment schedule data that is only the contents of the bonds. It has a function to do.
  • the settlement business support system 10 offsets remittance transactions associated with receivables (receivables) and debts (accounts payable) held by electronic commerce participants, for example, on a certain date. Only the difference can be settled. For this reason, it is possible to reduce bank fees and administrative work compared to the case where settlement is made for each transaction.
  • the various operations corresponding to the settlement business support method described below are performed by programs that are read and executed by the platform server 100, the supplier terminal 200, and the buyer terminal 300, which constitute the settlement business support system 10, respectively. Realized. Further, part of the processing includes an exchange between the settlement business support system 10 and the bank system 400. These programs are composed of codes for performing various operations described below.
  • FIG. 5 is a data flow diagram showing a processing procedure example 1 of the settlement service support method in the present embodiment.
  • the supplier terminal 200 transmits invoice data, which is invoice data input by the person in charge of the sales department in the supplier company, to the platform server 100 (s100).
  • the platform server 100 receives the invoice data 125 transmitted from the supplier terminal 200 and stores it in the shared data folder in the storage device 101.
  • the buyer terminal 300 in the buyer's purchasing department serving as the destination of the invoice data 125 issues an invoice inquiry instruction to the platform server 100 (s101), and the invoice data 125 is received from the platform server 100. Obtain (s102). At this time, the buyer terminal 300 stores the invoice data 125 acquired from the platform server 100 in its own storage device 301.
  • FIG. 12 shows an example of the invoice data 125.
  • the invoice data 125 is a collection of records in which product information, money amount information, and supplier information are linked using invoice information as a key.
  • the invoice information is composed of a number for uniquely identifying the corresponding invoice and the issue date of the corresponding invoice.
  • the product information includes information on a product number, which is identification information of a product to be charged, and a product name.
  • the amount information includes information on each value of quantity, unit price, amount of money (quantity ⁇ value of unit price), tax rate, and total for each product included in the product information.
  • the supplier information includes the company name of the supplier company that is the merchandise seller, its taxpayer number, and bank account information that is the payment destination of each product included in the product information.
  • the buyer terminal 300 gives predetermined information for settlement to the invoice data 125 stored in the storage device 301 or information for settlement designated by a predetermined person in charge of the buyer company from the input device 301.
  • the payment schedule data 126 addressed to the supplier is generated and transmitted to the platform server 100 (s103).
  • the above-mentioned information for settlement given to the invoice data 125 includes, for example, information on the invoice payment date included in the invoice data 125, information on the scheduled payment date determined by the buyer, and payment funds.
  • Payment account information which is information on the bank account used by the buyer company for the transfer, can be assumed. Note that the scheduled payment date may be calculated by subtracting a certain number of days from the value of the invoice issuance date.
  • FIG. 12A shows an example of payment schedule data 126.
  • the payment schedule data 126 is a collection of records in which payment schedule information, invoice information, product information, amount information, payment schedule amount, deposit account information, and payment account information are linked to each other. Among these pieces of information, information different from the invoice data 125 described above is information of payment schedule information, payment schedule amount, and payment account information.
  • the payment schedule information includes the payment date information included in the invoice data 125, the payment date information determined by the buyer included in the invoice data 125, and the status information. Note that the scheduled payment date may be calculated by subtracting a certain number of days from the value of the invoice issuance date.
  • This status information indicates the stage of processing performed for the corresponding record in the payment schedule data 126.
  • the value indicating whether or not the buyer has collated (reconciled) the content indicated by the invoice data 125 (corresponding record) with the content indicated by the invoice of the paper medium possessed by the buyer. Is set.
  • the status value list 132A is illustrated in FIG. 13B. Subsequently, when the status value is updated with each process, the platform server 100 executes the update based on the list 132A shown in FIG. 13B.
  • the value of the amount that the buyer plans to deposit to the supplier is set for the corresponding record in the scheduled payment data 126.
  • it is the same amount as the total value in the amount information.
  • a value not equal to the total value in the amount information is set by the buyer's judgment based on the situation such as a shortage of deposit balance or a change in contract contents.
  • the payment account information is information on a bank account used by the buyer company to transfer the settlement funds, and includes the company name of the buyer company and bank account information from which the product price is withdrawn.
  • Pha Piao used in China is an example.
  • Pha Piao is an invoice or receipt in China, which uses a statutory voting form issued by a tax institution. It is assumed that the buyer company receives and stores this Phapiao from the supplier company.
  • a normal journal creation process (s104) is executed based on the invoice data 125, Farpiao, etc., and the receivable information 127 generated thereby is uploaded to the platform server 100.
  • the general ledger 128 (denoted as “GL” in the figure) is also generated as usual with the journal creation process (s104), and this general ledger 128 is held in the storage device 201 of the supplier terminal 200. .
  • the platform server 100 receives the account receivable information 127 from the supplier terminal 200 and stores it in the storage device 101.
  • An example of the accounts receivable information 127 is shown in FIG. 15A.
  • Accounts receivable information 127 includes a book date, an account receivable indicating the company to be sold, product information indicating the product number and product name of the product sold, amount information thereof, invoice data 125 identifying information and invoice information indicating the date of issue. And data such as collection schedule information.
  • the collection schedule information includes each information of the collection date of the corresponding account receivable and the status indicating the collection status.
  • the buyer terminal 300 displays the invoice data 125 received from the platform server 100 on the output device 307, and is used for collation by the person in charge described above.
  • This person in charge compares the description contents of the paper medium Pha Piao with the invoice data 125 displayed on the output device 307, and checks whether the values of the corresponding items match each other (reconcile).
  • the buyer terminal 300 thus accepts the result of the buyer's collation between the content indicated by the invoice data 125 displayed on the output device 307 and the content indicated by the paper medium Phapiao (s105).
  • Examples of the reconcile screen are as shown in FIGS. 17 and 17A.
  • FIG. 17 a list of invoice data 125 to be processed is displayed, and in FIG. 17A, detailed information of one of the invoice data 125 is displayed.
  • the buyer terminal 300 (s106: Y), the above invoice data 125 Journal entry creation (s109) based on the above, generation of accounts payable information 130 (see FIG. 14A), and transmission of the accounts payable information 130 to the platform server 100 are executed. Further, in accordance with this processing, the buyer terminal 300 updates the status of the corresponding record as “reconciled” in the payment schedule data 126. Note that by creating the journal entry in step s109 described above, a normal general ledger 131 (denoted as “GL” in the figure) is generated.
  • the above-mentioned accounts payable information 130 includes, as illustrated in FIG. 14A, a book date, a supplier indicating the purchase company, product information indicating the product number and product name of the purchased product, price information, invoice data, and the like. It includes data such as invoice information indicating 125 identification information and an application category indicating a payment status for accounts payable. In the example of FIG. 14A, the value of “consumption category” is “all paid” or “partially paid”. Since the accounts payable information 130 is created based on the invoice data 125, the accounts payable information 130 has the same configuration as the invoice data 125, except for the value of “consumption category” indicating whether or not it is applied.
  • the buyer terminal 300 has information on the difference. That is, the difference information 129 is transmitted to the platform server 100 (s107).
  • the above-described difference information 129 is, for example, data including the item name in which the above-described difference occurs, and the invoice data 125 and each value in the paper medium related to the relevant item.
  • the platform server 100 receives the above-described difference information 129 from the buyer terminal 300 and stores it in the storage device 101. Further, the platform server 100 transmits a confirmation request regarding the difference information 129 to the supplier terminal 200 (s108). On the supplier side, the difference information 129 is confirmed on the supplier terminal 200, and a predetermined person in charge decides subsequent actions such as correction and reissue of Phapiao, or correction and re-uploading of the invoice data 125, and necessary. Measures will be taken.
  • FIG. 6 is a data flow diagram showing a processing procedure example 2 of the settlement service support method in the present embodiment.
  • the platform server 100 repeats the process related to the payment schedule data 126 described above for each latest invoice data 125 received from the supplier terminal 200 until, for example, the night of the invoice issuance date. It is assumed that a plurality of payment schedule data 126 records are stored in the storage device 101 (s120).
  • the platform server 100 detects that a record of a predetermined number or more of payment schedule data 126 has been stored in the storage device 101, and notifies the buyer terminal 300 of the payment schedule aggregation proposal (s121). At this time, the buyer terminal 300 receives this notification and returns an instruction to aggregate the payment schedule data 126 to the platform server 100 (s122).
  • This aggregation instruction may be input by a predetermined person in the buyer company using the input device 306 of the buyer terminal 300, and the buyer terminal 300 receiving the instruction may transmit it to the platform server 100.
  • the platform server 100 When the platform server 100 receives the above-described payment schedule information aggregation instruction from the buyer terminal 300, the platform server 100 sets the payment schedule data 126 related to the buyer based on the value of the “company name” indicated by the “payment account information”. Of the payment schedule data 126 read out from the storage device 101, the payment schedule data 126 having a predetermined predetermined item or a predetermined item specified by the buyer terminal 300 is specified, and each payment schedule data specified here is specified. The payment amounts in 126 are added together and merged with the corresponding payment schedule data 126, and the merged payment schedule data is stored in the storage device 101 as the aggregated payment schedule data 132 (s123).
  • predetermined items used when specifying the payment schedule data 126 to be aggregated for example, “payment due date” in “payment schedule information”, “scheduled payment date” in “payment schedule information”, “billing” “Number” in “Document Information”, “Company Name” and “Bank”, “Branch”, “Account Number” in “Deposit Account Information”.
  • FIG. 13 shows an example of post-consolidation payment schedule data 132.
  • the post-consolidation payment schedule data 132 illustrated here has two records because the four records in the payment schedule data 126 are aggregated by two records.
  • the platform server 100 sends an inquiry notification of the aggregated payment schedule data 132 generated as described above to the buyer terminal 300.
  • the buyer terminal 300 obtains the aggregated payment schedule data 132 from the platform server 100 and displays it on the output device 307 (s124), and accepts a payment account selection instruction by a predetermined person in the input device 306. (S125).
  • the buyer terminal 300 reads the buyer account information 133 (see FIG. 13A) from the platform server 100 and displays it on the output device 307 as a payment account selection list. Moreover, the above-mentioned person in charge selects a desired remittance method (for example, individual transfer, general transfer) from various transfer methods provided by the bank in accordance with the payment account selection.
  • a desired remittance method for example, individual transfer, general transfer
  • the buyer terminal 300 receives the selected item by the input device 306 (s126), and notifies the platform server 100 of a payment schedule application including the selected item and the selected item of the payment account obtained in step s125 (step S125). s127).
  • the platform server 100 receives a payment schedule application from the buyer terminal 300, acquires, for example, a value of “total transfer” (total transfer form) as the value of the remittance method included in the application, and collects this value as described above. This is set in the corresponding column “total transfer” of the post-payment schedule data 132. In the example of FIG. 3, what is set in the “total transfer” column is the value of presence / absence of contract in the general transfer format with the bank. Further, the platform server 100 sets the value of the selection item of the payment account included in the above-described payment schedule application in the corresponding column “payment account information” in the aggregated payment schedule data 132.
  • FIG. 7 is a data flow diagram showing a processing procedure example 3 of the settlement service support method in the present embodiment.
  • the platform server 100 detects the arrival of the “scheduled payment date” in the aggregated payment schedule data 132 using its own calendar function and notifies the buyer terminal 300 accordingly (s129). In response to this notification, the buyer terminal 300 transmits an application for payment request to the platform server 100 (s130).
  • a predetermined person in the buyer company may input the application data for the payment request described above using the input device 306 of the buyer terminal 300, and the buyer terminal 300 may transmit it to the platform server 100.
  • the platform server 100 receives the above payment request application from the buyer terminal 300 (s131), and the post-consolidation payment schedule data 132 (eg: “payment account information” column) regarding the buyer (eg, company name AB).
  • the value of “company name” is “company name AB”) is read from the storage device 101 and sent to the buyer terminal 300.
  • the buyer terminal 300 acquires the aggregated payment schedule data 132 from the platform server 100 and displays it on the output device 307 (FIGS. 18 and 18A). In this case, the buyer terminal 300 confirms whether the payment request data 132 can be requested by checking the contents indicated by the aggregated payment schedule data 132 with the contents indicated by the paper invoice sent to the buyer from the supplier, that is, the contents indicated by Phapiao. The result of the determination is received by the input device 306 (s132). Such a decision on whether or not to accept a payment request is performed by a person in charge of the accounting department in the buyer company.
  • the buyer terminal 300 If the result of the above-described admissibility determination received by the input device 306 is that the payment request is not approved (s133: N), the buyer terminal 300 transmits a payment request rejection notice to the platform server 100, and the rejection is confirmed. Is transmitted to a predetermined terminal such as the buyer terminal 300 of the purchasing department in the buyer company (s135).
  • the “payment account information” in the payment schedule data 132 after the aggregation is that the buyer terminal 300 approves the payment request (s133: Y)
  • the “payment account information” in the payment schedule data 132 after the aggregation is that the buyer terminal 300 approves the payment request (s133: Y)
  • the bank system 400 of the bank indicated by e.g .: U-bank
  • makes a balance inquiry of the corresponding account e.g., Shanghai branch, account number 3333333
  • s136 predetermined login authentication process
  • the bank system 400 receives this balance inquiry (s137), and returns the value of the account balance of the corresponding account to the buyer terminal 300 (s138).
  • the buyer terminal 300 determines whether the value of the account balance satisfies the value of “scheduled amount” in the aggregated payment schedule data 132 described above (s139).
  • the buyer terminal 300 transmits an approval registration instruction to the platform server 100 regarding the above-described payment request (s141).
  • the buyer terminal 300 determines that the value of the account balance is insufficient for the “scheduled amount” and there is no necessary balance (s139: N), for example, it corresponds from another bank account held by the buyer company.
  • the deposit process for the shortage amount described above is executed to the account (s140), and the process returns to step s139 described above.
  • the bank of the corresponding buyer's bank (eg, U bank) indicated by the corresponding post-consolidation payment schedule data 132
  • a request is made to the system 400 for a settlement process corresponding to the amount indicated by the “amount information” from the account indicated by the “payment account information” in the aggregated payment schedule data 132 to the bank account indicated by the “payment account information”.
  • Transmit (s142).
  • the bank system 400 receives this settlement processing request (s143), and executes predetermined settlement processing by performing transfer processing from the buyer company account to the supplier company account.
  • the platform server 100 in accordance with the process of transmitting the settlement process request to the bank system 400, accounts payable corresponding to the “number” of “invoice information” in the aggregated payment schedule data 132 included in the settlement process request.
  • the information 130 (see FIG. 14A) is specified in the storage device 101, and an application process related to the payable information is executed (s144).
  • the value of “application category” in the accounts payable information 130 is “completely paid” or “partially paid”. Since the accounts payable information 130 is created based on the invoice data 125, the accounts payable information 130 has the same configuration as the invoice data 125, except for the value of “consumption category” indicating whether or not it is applied.
  • the platform server 100 notifies the buyer terminal 300 of the result of the application process related to the accounts payable information 130.
  • the buyer terminal 300 executes journal creation processing according to the cleared accounts payable information (s145), and updates the general ledger 131.
  • the person in charge of the accounting department in the buyer company can inquire about the general ledger 131 using the buyer terminal 300.
  • the platform server 100 generates a payment notification 134 (see FIG. 14) related to the corresponding invoice data 125 (record thereof) for which the settlement processing request has been made after executing the accounts payable information application processing (s147).
  • the payment notification 134 has the same data structure as the corresponding invoice data 125 (record thereof) for which the settlement process is requested.
  • the value of “status” in the payment notice 134 is “all paid” when the amount settled by the buyer matches the amount charged by the supplier, or is charged by the supplier. "Partially paid” when the amount settled by the buyer is insufficient.
  • FIG. 8 is a data flow diagram showing a processing procedure example 4 of the settlement business support method in the present embodiment
  • FIG. 9 is a data flow diagram showing a processing procedure example 5 of the settlement business support method in the present embodiment.
  • the platform server 100 executes generation of the payment schedule information 135 in response to the generation of the above-described payment notification 134 or in response to a payment notification inquiry or creation instruction (s150, s151) from the supplier terminal 200. This is stored in the storage device 101 (s152).
  • This payment schedule information 135 is generated based on the payment details information to the supplier included in the above-described payment processing request or payment notification 134. As shown in FIG. The date of receipt of the payment notice, which is the date on which the payment notice was received, the deposit account information indicating the supplier company's account received from the buyer company, the amount information indicating the amount paid, and the corresponding invoice data 125 number And invoice information indicating the issue date, product information indicating the product number and name of the product to be paid, payment information indicating the due date, actual payment date and payment status, and the account used by the buyer company for payment Each piece of payment account information is shown. In the example shown in FIG. 15, the “status” in the payment schedule information 135 is “not paid”. This is because, at this time, payment is scheduled and the platform server 100 has not actually received a payment notification from the bank system 400.
  • the platform server 100 notifies the supplier terminal 200 that the payment schedule information 135 is generated. Receiving this, the supplier terminal 200 acquires the deposit schedule information 135 from the platform server 100 (s153), and accepts an instruction from the person in charge of the accounting department who has browsed this information by the input device 206. This instruction is an instruction to create a receivable cancellation schedule. This creation instruction is transmitted from the supplier terminal 200 to the platform server 100 (s154).
  • the platform server 100 receives the above creation instruction from the supplier terminal 200, reads the payment schedule information 135 and the accounts receivable information 127 (see FIG. 15A) stored in the storage device 101, and further receives the payment schedule information 135.
  • the receivable information 127 (record) corresponding to the identification number of the invoice data 125 included in the invoice data 125, that is, the “number” value in the “invoice information” is specified (matched) in the storage device 101 (s155).
  • the accounts receivable information 127 is generated from the invoice data 125, and includes the data such as the book date, the accounts receivable, the merchandise information, the amount information, the invoice information, and the collection schedule information, as described above.
  • the collection schedule information includes each information of the collection date of the corresponding account receivable and the status indicating the collection status.
  • the platform server 100 generates information 136 (see FIG. 15B) of the application receivable schedule specified in step s155 described above.
  • the accounts receivable application schedule information 136 has almost the same data structure as the above-described accounts receivable information 127, and is composed of a scheduled payment date, accounts receivable, bill information, product information, amount information, and collection schedule information. Yes.
  • the supplier terminal 200 obtains the above-mentioned receivables cancellation schedule information 136 and displays it on the output device 207 as shown in FIG. 19 and FIG. 19A (s156), and is used for browsing the person in charge of the accounting department in the supplier company.
  • the bank system 400 of the supplier side bank that has received the payment from the buyer side transmits a payment notification indicating the above-mentioned payment fact to the platform server 100 and the supplier terminal 200.
  • the supplier terminal 200 receives the above-mentioned payment notification and sends an instruction to create the payment information 137 to the platform server 100 (s157).
  • the platform server 100 receives the payment notification related to the above-described supplier's account, and further receives the above-described payment information creation instruction from the supplier terminal 200, and receives the payment information 137 based on the information indicated by the payment notification. It is created and stored in the storage device 101 (s158).
  • the deposit information 137 includes a deposit date that indicates the date when the bank actually received the deposit, a deposit account that indicates the account that received the deposit, a deposit requester, that is, a requester that is a company that performs the transfer, and It consists of data of money amount information indicating the amount of money deposited.
  • the supplier terminal 200 transmits the above-described payment information creation instruction to the platform server 100, and then displays the above-mentioned payment notification on the output device 207, so that the person in charge of the accounting department in the supplier company collates with Far Piao. To serve.
  • the person in charge of the accounting department confirms whether or not the content indicated by the deposit notice is consistent with the content indicated by Phapiao.
  • the input unit 206 of the supplier terminal 200 inputs a request for application processing for the receivable corresponding to the above-described payment notification.
  • the supplier terminal 200 receives the request instruction for the consumption process by the input device 206 and transmits it to the platform server 100 (s159).
  • the platform server 100 receives the account receivable application request, matches the above-mentioned receipt information 137 with the above-described account receivable application schedule information 136, and accounts receivable application of the account receivable corresponding to the contents of the above-mentioned receipt notification.
  • the schedule information 136 is specified, and the application process related to the corresponding accounts receivable is executed in the accounts receivable information 127 (s160). Specifically, in this step, the platform server 100 sets the value of “Accounts receivable” in “Amount information” to “0”, “170”, etc.
  • the value of “Category” in “Included category” is set as “All applied” or “Partially applied”. Further, the platform server 100 sends an execution notification of the receivable application process to the supplier terminal 200.
  • the supplier terminal 200 receives the above-described receivable application process execution notification, executes a journal creation process related to the receivable information 127 (s161), and updates the general ledger 128.
  • the supplier terminal 200 can inquire about the general ledger 131 in response to an instruction from a person in charge of the accounting department in the supplier company. (S162).
  • the receivable information 127 or the receivable application schedule information 136 corresponding to the content of the above-mentioned payment notification is specified, and the excess of the deposit amount for the specified receivable is specified.
  • the shortage is determined (s163).
  • the platform server 100 reads, for example, the value of “Accounts receivable balance” in “Amount information” and the value of “Category” in “Approval category” in the accounts receivable information 127 shown in FIG.
  • the platform server 100 executes the account receivable clearing notification specified above to the supplier terminal 200 (s165).
  • the account receivable application process specified above may be executed. Even if there is an excess or deficiency of the deposit, the accounts receivable application process may be performed. In this case, if there is a shortage, only the deposit will be applied. In addition, both transmission and cancellation of excess / deficiency information may be performed.
  • deposit surplus / deficiency information 139 which is the surplus / deficiency information, is created (s167) and transmitted to the supplier terminal 200 ( s168).
  • FIG. 16B shows the deposit excess / deficiency information 139.
  • This deposit excess / deficiency information 139 includes the receipt date, deposit account information, monetary information, invoice information, payment regarding the record of the accounts receivable information 127 in which the deposit amount was excessive or insufficient (also referred to as the record of the original invoice data 125). It consists of information, product information, payment account information, and remarks information.
  • the platform server 100 sets a predetermined countermeasure plan to be taken by the supplier company or the buyer company.
  • the supplier terminal 200 receives the above-described deposit excess / deficiency information 139 from the platform server 100 (s169), and receives this information and stores it in a shared folder (a folder accessible from the buyer terminal 300) in the platform server 100.
  • An instruction to create the deposit excess / deficiency information 140 is sent to the platform server 100 (s170).
  • the platform server 100 copies the above-described deposit excess / deficiency information 139 as the deposit excess / deficiency information 140 and stores it in the shared folder in the storage device 101 (s171). Further, the platform server 100 sends a notification of excess / deficiency information to the buyer terminal 300 based on the deposit excess / deficiency information 140 (s172).
  • the buyer terminal 300 receives the above-mentioned excess / deficiency information from the platform server 100, displays it on the output device 307, and allows a buyer in charge of the purchasing department in the buyer company to browse (s173).
  • FIG. 10 is a flowchart showing a processing procedure example 6 of the settlement service support method in the present embodiment.
  • a technique will be described in which remittance transactions associated with receivables (receivables) and debts (accounts payable) held by the participants of the electronic commerce in the platform server 100 are offset, and only the difference is settled on a certain date.
  • By performing such processing there is an effect that it is possible to reduce the bank fees and the administrative work as compared with the case where settlement is made for each transaction.
  • a method of performing offset processing between two parties bilateral netting
  • a method of performing offset processing between three or more parties through a management company or the like multilateral netting
  • the platform server 100 bears receivables and payables, that is, the value of “company name” of “payment account information” in the invoice data 125, the payment schedule data 132, or the aggregated payment schedule data 132 is One or more pairs of suppliers and buyers pointing to each other are identified using the value of “company name” in “payment account information” as a key (s180).
  • the platform server 100 reads the above-mentioned aggregated payment schedule data 132 from the storage device 101 for each of the one or more sets of suppliers and buyers identified above (s181), and the payment in the aggregated payment schedule data 132 is performed.
  • the amount value is offset between the supplier and the buyer (s182).
  • the platform server 100 pays the remaining payment amount after aggregation to the bank system 400 of the supplier or buyer's bank indicated by the payment schedule data 132 in which only the content of the remaining bond is left after the offsetting.
  • a payment processing request corresponding to the content indicated by the data 132 is transmitted (s183).
  • the corresponding bank system 400 executes settlement processing in response to this request.
  • step s180 For example, if the supplier / buyer combination identified in step s180 is one, so-called bilateral netting is executed. It is assumed that company A and company B have performed three transactions as illustrated in FIG. 11 before the payment amount is offset, that is, netting. If the above-described step s182 is executed, as shown in the lower part of FIG. 11, the payment plan data 132B in which only the contents of the remaining bonds after the offsetting are left is “obligor” is “Company A”, “creditor” "B Company” and the remaining debt of the settlement amount is "200". Thus, when settlement is made for each transaction as before, the exchange / remittance transaction is required three times as it is for the three transactions, but only once after netting.
  • step s180 when there are two or more pairs of suppliers and buyers identified in the above step s180, so-called multilateral netting is executed. Assume that Company A, Company B, Company C, and Company D were engaged in six transactions as illustrated in FIGS. 11A and 11B before offsetting payment amounts, that is, netting. If step s182 described above is executed, as shown in the lower part of FIG. 11A and FIG. 11C, the payment plan data 132B in which only the contents of the remaining bonds remain after the offsetting, the “obligor” is “Company A”. , “Creditor” is “Company C”, and the remaining debt of the settlement amount is “1846”.
  • the exchange / remittance transaction requires six transactions as it is, but only one transaction after netting. In other words, exchange / remittance transactions can be greatly reduced and commissions can be reduced.
  • inter-business transactions and bank transactions can be linked to improve the efficiency of various settlement operations and reduce costs.
  • the buyer's terminal was sent from the supplier, the process of displaying the invoice data received from the computer on the output device, the contents indicated by the invoice data, and A process in which the input device compares the result of the buyer's collation with the content indicated by the paper medium invoice, and the result received by the input device is the content of the invoice data and the content of the paper medium invoice. Indicates that there is no difference between the billing data, the billing data is generated based on the billing data, and the billing information is transmitted to the computer.
  • the content of the document and the content of the invoice of the paper medium a process of transmitting the information of the difference to the computer is executed, and the computer It receives information of the difference from the buyer terminal, and stores information of the differences in the storage device executes a process to send a confirmation request for the difference in the supplier terminal may be.
  • the aggregated payment schedule data related to the buyer is read from the storage device, and the aggregated payment schedule data indicates , A process of transmitting a settlement process request according to the contents indicated by the aggregated payment schedule data to the buyer's bank system, and a process of transmitting the settlement process request to the buyer's bank system Accordingly, it may be possible to execute a process of generating a payment notification related to the corresponding invoice data for which the settlement process is requested and transmitting the notification to the terminal of the corresponding supplier.
  • the process of acquiring the aggregated payment schedule data from the computer and displaying it on the output device A process in which a buyer collates the content indicated by the aggregated payment schedule data with the content indicated by a paper medium invoice sent from a supplier, and accepts a result of determination on whether or not the payment request is accepted by an input device; And when the result accepted by the input device approves the payment request, the payment request is transmitted to the computer, and the result accepted by the input device is the payment request. If the payment request is rejected, the payment request is not transmitted to the computer, and the rejection is sent to a predetermined terminal. It executes a process signal to may be.
  • the computer receives information on the accounts payable based on the invoice data from the buyer's terminal and stores the information on the accounts payable in a storage device;
  • the billing process identification information included in the settlement process request is specified, and the corresponding accounts payable It is also possible to execute a clearing process related to the information.
  • the computer includes the payment request to the supplier, which is included in the payment processing request or the payment notification in response to the generation of the payment notification or an instruction from the supplier's terminal. Based on the content information, information on the payment schedule of the supplier's bank in the supplier's account is generated and stored in a storage device, and information on accounts receivable based on the invoice data is received from the supplier's terminal.
  • the computer receives a notification from the supplier's bank about the fact of payment to the supplier's account, and the payment contents indicated by the notification and the application of the receivable Matching the information of the schedule, specifying the information about the application plan of the receivables corresponding to the contents of the payment, determining whether the amount of the received money for the specified accounts receivable is excessive or insufficient, and as a result of the determination, If there is no excess or deficiency, the specified receivables application process is executed. If the result of the determination is that there is an excess or deficiency in the deposit amount, information on excess or deficiency is sent to the supplier terminal and the buyer terminal.
  • the computer reads the aggregated payment schedule data from the storage device for each of one or more sets of suppliers and buyers, and calculates the payment amount between the suppliers and buyers. Settlement processing according to the contents indicated by the aggregated payment schedule data for the remaining bonds to the system of the supplier or buyer's bank indicated by the payment schedule data that has been offset and only the contents for the remaining bonds after the offsetting The process of transmitting the request may be executed.
  • Settlement service support system 100 Platform server (computer) 101, 201, 301 Storage device 102, 202, 302 Program 103, 203, 303 Memory 104, 204, 304 Computing device 206, 306 Input device 207, 307 Output device 105, 205, 305 Communication device 110, 210, 310 Data types 120 Network 125 Invoice data 126 Payment schedule data 127 Accounts receivable information 128, 131 General ledger 129 Difference information 130 Accounts payable information 132 Consolidated payment schedule data 133 Buyer account information 134 Payment notification 135 Payment schedule information 136 Accounts receivable cancellation schedule information 137 Deposit information 139, 140 Deposit excess / deficiency information 200 Supplier terminal 300 Buyer terminal 400 Banking system

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減を可能とする。 【解決手段】企業間の電子商取引を仲介するコンピュータ１００が、サプライヤー端末２００より、バイヤーに宛てた請求書データを受信して記憶装置１０１に格納し、バイヤー端末３００からの取得要求に応じて請求書データをバイヤー端末３００に送信する処理を実行し、バイヤー端末３００が、コンピュータ１００から請求書データを受信し、これに決済用の情報を付与して支払予定データを生成しコンピュータ１００に送信する処理を実行し、コンピュータ１００が、バイヤー端末３００から受信した支払予定データのうち所定項目が共通する支払予定データを特定し、特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、集約後支払予定データとして記憶装置１０１に格納する処理を実行する。

Description

決済業務支援システムおよび決済業務支援方法
　本発明は、決済業務支援システムおよび決済業務支援方法に関する。
　昨今、企業間取引の電子化が図られており、債権債務に関する処理が電子的に行われるケースも増えている。例えば、入金と電子債権との対応関係を確実に管理し、効率的な消込管理を可能とする技術として、以下の技術が提案されている。
　すなわち、買掛債務の情報を買掛債務者端末より受信してメモリに格納し当該メモリにおける各買掛債務情報毎に一意の電子債権コードの割り振りを実行し買掛債務情報を電子債権原簿データベースに登録する電子債権管理部と、買掛債務者から電子債権コードを指定してなされた入金の情報を金融機関の端末より取得し入金データベース６に格納する決済管理部と、入金データベースに格納されている入金情報を読み出して電子債権原簿データベースでの電子債権情報の検索を実行しこの検索処理で特定された電子債権情報のレコードを電子債権原簿データベースから削除等の消込処理を実行する消込管理部と、消込処理がなされた電子債権の属性情報を電子債権原簿データベースより抽出し買掛債務者端末等へ通知する消込結果通知部とから構成された、売掛債権消込管理システム（特許文献１参照）などが提案されている。
特開２００７－１０２４５７号公報
　上述した企業間取引の電子化に伴い、複数企業間で情報を共有し、インターネット上での企業間取引の場となる、いわゆるＢｔｏＢプラットフォームのサービスも登場している。こうしたプラットフォームでは、製品の設計、販売、生産、調達、支払といった様々な業務に関して企業間連携を実現している。一方、こうしたプラットフォームにおける取引で、企業間の債権債務は確定するが、その決済方法（例えば、送金、口座振替、手形、小切手等）は該当企業間で個別に取り決められ、プラットフォームを通じて統一されていない。従って、上述のプラットフォームでの企業間取引と、その後の決済に伴う銀行取引との間で有為な連携は図られていない。
　そのため、例えばバイヤーは、サプライヤーから受け取る多数であり、紙で送付されるインボイス（請求書）の内容を請求書データとして記録し、それに従って送金等の買掛金支払業務を逐一実行する必要があり、作業負荷や、送金、決済コストが大きくなりやすい。一方、サプライヤーは、バイヤーからの売掛金の入金情報を銀行システムから得られるものの、この入金情報は必ずしも請求書単位となっていないため、売掛債権との紐付け（消し込み）を行う際に、相応の手間や時間、販売管理費がかかってしまう。
　また、上述した企業間取引と銀行取引との間の連携が無いことで、例えば、企業同士が合意した支払条件が実際には遵守されなかった場合のエビデンスが確保しにくく、不正行為や事務処理ミスが放置される懸念もある。こうした懸念は、公正なビジネス慣習が確立されていない新興国等で特に強い。
　そこで本発明の目的は、企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減を可能とする技術を提供することにある。
　上記課題を解決する本発明の決済業務支援方法は、企業間の電子商取引を仲介するコンピュータが、電子商取引におけるサプライヤーの端末より、バイヤーに宛てた請求書データを受信して記憶装置に格納し、前記バイヤーの端末からの取得要求に応じて前記請求書データを記憶装置から読み出してバイヤーの端末に送信する処理を実行し、前記バイヤーの端末が、当該バイヤー宛ての請求書データの取得要求を前記コンピュータに送り、前記コンピュータから該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して前記サプライヤー宛の支払予定データを生成し、前記コンピュータに送信する処理を実行し、前記コンピュータが、前記バイヤーの端末から受信した支払予定データのうち、予め定めた所定項目ないし前記バイヤー端末から指定を受けた所定項目が共通する支払予定データを特定し、前記特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置に格納する処理を実行する、ことを特徴とする。
　また、本発明の決済業務支援システムは、電子商取引におけるサプライヤーの端末より、バイヤーに宛てた請求書データを受信して記憶装置に格納し、前記バイヤーの端末からの取得要求に応じて前記請求書データを記憶装置から読み出してバイヤーの端末に送信する処理と、前記バイヤーの端末が、前記請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して生成した、前記サプライヤー宛の支払予定データを受信する処理と、前記受信した支払予定データのうち、予め定めた所定項目ないし前記バイヤー端末から指定を受けた所定項目が共通する支払予定データを特定し、前記特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置に格納する処理とを実行する演算装置を備え、企業間の電子商取引を仲介するコンピュータと、前記バイヤー宛ての請求書データの取得要求を前記コンピュータに送り、前記コンピュータから該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して前記サプライヤー宛の支払通知データを生成し、前記コンピュータに送信する処理を実行する演算装置を備えた、バイヤーの端末と、電子商取引におけるバイヤーに宛てた請求書データを、前記コンピュータに送信する処理を実行する演算装置を備えたサプライヤーの端末と、を備えることを特徴とする。
　本発明によれば、企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減が可能となる。
本実施形態の決済業務支援システムを含むネットワーク構成例を示す図である。 本実施形態のプラットフォームサーバの構成例を示す図である。 本実施形態のサプライヤー端末の構成例を示す図である。 本実施形態のバイヤー端末の構成例を示す図である。 本実施形態の決済業務支援方法の処理手順例１を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例２を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例３を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例４を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例５を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例６を示すデータフロー図である。 本実施形態におけるバイラテラル・ネッティング前後の支払予定データの具体的変遷例を示す図である。 本実施形態におけるマルチラテラル・ネッティング前後の支払予定データの具体的変遷例を示す図である。 本実施形態におけるマルチラテラル・ネッティング前の債権・債務関係の具体例を示す図である。 本実施形態におけるマルチラテラル・ネッティング後の債権・債務関係の具体例を示す図である。 本実施形態におけるインボイスデータの具体例を示す図である。 本実施形態における支払予定データの具体例を示す図である。 本実施形態における集約後支払予定データの具体例を示す図である。 本実施形態におけるバイヤー口座情報の具体例を示す図である。 本実施形態におけるステータス値リストの具体例を示す図である。 本実施形態における支払通知の具体例を示す図である。 本実施形態における買掛金情報の具体例を示す図である。 本実施形態における入金予定情報の具体例を示す図である。 本実施形態における売掛金情報の具体例１を示す図である。 本実施形態における売掛金消込予定情報の具体例を示す図である。 本実施形態における入金情報の具体例を示す図である。 本実施形態における売掛金情報の具体例２を示す図である。 本実施形態における入金過不足情報の具体例を示す図である。 本実施形態における出力画面例１を示す図である。 本実施形態における出力画面例２を示す図である。 本実施形態における出力画面例３を示す図である。 本実施形態における出力画面例４を示す図である。 本実施形態における出力画面例５を示す図である。 本実施形態における出力画面例６を示す図である。
　以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態の決済業務支援システムを含むネットワーク構成例を示す図である。図１に示す決済業務支援システム１０は、企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減を可能とするためのコンピュータシステムである。この決済業務支援システム１０は、企業間の電子商取引を仲介するコンピュータであり、ＢｔｏＢプラットフォームを提供するプラットフォームサーバ１００、このプラットフォームサーバ１００にアクセスしてプラットフォームサービスを利用するサプライヤー端末２００およびバイヤー端末３００を含んでいる。これら、プラットフォームサーバ１００、サプライヤー端末２００、バイヤー端末３００は、ネットワーク１２０を介して通信可能に結ばれている。
　なお、上述のサプライヤー端末２００は、電子商取引において、商品を他社に販売するサプライヤー企業が利用する端末である。また、バイヤー端末３００は、電子商取引において、商品を他社から購入するバイヤー企業が利用する端末である。
　また、上述のネットワーク１２０には、電子商取引に伴い決済に利用される銀行システム４００も接続されている。プラットフォームサーバ１００、サプライヤー端末２００、およびバイヤー端末３００らは、ネットワーク１２０を介して、口座開設している取引銀行の銀行システム４００に認証等を経てアクセスし、必要な情報や処理をリクエストすることが出来る。
　また、決済業務支援システム１０を構成する各情報処理装置のハードウェア構成は以下の如くとなる。図２は、本実施形態のプラットフォームサーバ１００の構成例を示す図である。決済業務支援システム１０を構成するコンピュータたる、プラットフォームサーバ１００は、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶装置１０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワークと接続し他装置との通信処理を担う通信装置１０５を備える。なお、記憶装置１０１内には、本実施形態の決済業務支援システム１０を構成する情報処理装置として必要な機能を実装する為のプログラム１０２と、各種処理に必要なデータ類１１０が記憶されている。このデータ類１１０には、後述するインボイスデータ１２５や、このインボイスデータ１２５やその他の情報から生成した各種のデータが含まれる。こうした考えかたは、サプライヤー端末２００やバイヤー端末３００に関しても同様とする。
　なお、図３にて示すように、上述のサプライヤー端末２００は、コンピュータとして一般的なハードウェア構成を備えており、プラットフォームサーバ１００と同様に、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶装置２０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ２０３、記憶装置２０１に保持されるプログラム２０２をメモリ２０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置２０４、ネットワークと接続し他装置との通信処理を担う通信装置２０５、ユーザたるサプライヤー企業の担当者からの入力を受け付けるキーボード、マウスといった入力装置２０６、および、処理結果を出力するディスプレイやスピーカー等の出力装置２０７を備える。記憶装置２０１内には、本実施形態の決済業務支援システム１０を構成する情報処理装置として必要な機能を実装する為のプログラム２０２と、各種処理に必要なデータ類２１０が記憶されている。
　また、図４にて示すように、バイヤー端末３００も上述のサプライヤー端末２００と同様のハードウェア構成を備えており、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶装置３０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ３０３、記憶装置３０１に保持されるプログラム３０２をメモリ３０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置３０４、ネットワークと接続し他装置との通信処理を担う通信装置３０５、ユーザたるバイヤー企業の担当者からの入力を受け付けるキーボード、マウスといった入力装置３０６、および、処理結果を出力するディスプレイやスピーカー等の出力装置３０７を備える。記憶装置３０１内には、本実施形態の決済業務支援システム１０を構成する情報処理装置として必要な機能を実装する為のプログラム３０２と、各種処理に必要なデータ類３１０が記憶されている。
　続いて、本実施形態の決済業務支援システム１０を構成する各情報処理装置、すなわち、プラットフォームサーバ１００、サプライヤー端末２００、およびバイヤー端末３００らがそれぞれ備える機能について説明する。上述したように、以下に説明する機能は、例えば決済業務支援システム１０を構成する、プラットフォームサーバ１００、サプライヤー端末２００、バイヤー端末３００らが備えるプログラムをそれぞれ実行することで実装される機能と言える。
　プラットフォームサーバ１００は、電子商取引におけるサプライヤーの端末、すなわちサプライヤー端末２００より、バイヤーに宛てた請求書データを受信して記憶装置１０１に格納し、バイヤーの端末、すなわちバイヤー端末３００からの取得要求に応じて請求書データを記憶装置１０１から読み出してバイヤー端末３００に送信する機能を有する。
　一方、バイヤー端末３００は、当該バイヤー宛ての請求書データの取得要求をプラットフォームサーバ１００に送り、このプラットフォームサーバ１００から該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置３０１からバイヤーが指定した決済用の情報を付与して、サプライヤー宛の支払予定データを生成し、プラットフォームサーバ１００に送信する機能を有する。
　他方、プラットフォームサーバ１００は、上述のバイヤー端末３００から受信した支払予定データのうち、予め定めた所定項目ないしバイヤー端末３００から指定を受けた所定項目が共通する支払予定データを特定し、ここで特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置１０１に格納する機能を有する。
　こうした機能を備える決済業務支援システム１０は、サプライヤー側から得られる請求書データ（電子データ）に基づいて、バイヤー側で利用価値のある支払予定データを自動生成し、更に、入金先の銀行口座が同一であるなど、互いに支払金額を合算出来る支払予定についてはマージしてデータを集約し、以降に行われる予定の実際の決済処理（サプライヤー指定の銀行口座への振り込み処理）の件数を低減出来る。決済時の処理件数が低減出来ることで、処理効率が向上して、作業の手間や時間は勿論、決済コストも低減出来る。
　なお、上述のバイヤー端末３００は、プラットフォームサーバ１００から受信した請求書データを出力装置３０７に表示させる機能を有している。
　また、このバイヤー端末３００は、出力装置３０７に表示した請求書データが示す内容と、サプライヤーからバイヤー宛てに送付されていた紙媒体の請求書が示す内容とをバイヤーが照合した結果を、入力装置３０６で受け付ける機能を有している。
　この場合、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、請求書データの内容と紙媒体の請求書の内容とに差異が無いことを示す場合、上述の請求書データに基づく買掛金の情報の生成と、この買掛金の情報のプラットフォームサーバ１００への送信とを実行する機能を有している。また、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、請求書データの内容と紙媒体の請求書の内容とに差異があることを示す場合、その差異の情報をプラットフォームサーバ１００に送信する機能を有している。
　このように、実際の紙媒体の請求書と請求書データ（電子データ）との照合結果を、その後の処理に反映させることで、請求書データのデータ品質や、請求書データを用いたその後の処理の正確性を良好に維持できる。
　一方、プラットフォームサーバ１００は、上述の差異の情報をバイヤー端末３００から受信して、当該差異の情報を記憶装置１０１に格納し、サプライヤー端末２００に対し、上述の差異に関する確認要求を送信する機能を有している。なお、上述した紙媒体の請求書としては、例えば、中国で利用されているファーピャオが一例となる。ファーピャオ（発票）は、中国における請求書（Invoice）ないし領収書であり、税務機関が発行した法定の発票用紙が利用されている。
　また、プラットフォームサーバ１００は、バイヤー端末３００より支払依頼を受信した場合、該当バイヤーに関する集約後支払予定データを記憶装置１０１より読み出し、当該集約後支払予定データが示す、バイヤーの利用銀行の銀行システム４００に対し、集約後支払予定データが示す内容に応じた決済処理の依頼を送信する機能を有している。
　また、プラットフォームサーバ１００は、決済処理の依頼をバイヤーの利用銀行の銀行システム４００に送信する処理に伴い、決済処理の依頼がなされた該当請求書データに関する支払通知を生成して、該当サプライヤー端末２００に宛てて送信する機能を有している。
　こうした機能を備える決済業務支援システム１０は、予め集約されている支払予定データに基づいた決済処理の依頼を銀行システム４００に送信することが可能となり、振込件数の低減や、それに伴う振込コスト低減も可能となる。また、上述の支払通知がなされることで、サプライヤー側では、バイヤー側での支払行為が済んだことを、銀行システム４００からの通知前に感知できる。また、決済業務支援システム１０におけるプラットフォームサーバ１００と、銀行システム４００との連携が図られる効果もある。
　また、バイヤー端末３００は、支払依頼をプラットフォームサーバ１００に送信するに伴い、プラットフォームサーバ１００より集約後支払予定データを取得して出力装置３０７に表示させる機能を有している。この場合、バイヤー端末３００は、集約後支払予定データが示す内容と、サプライヤーからバイヤー宛てに送付されていた紙媒体の請求書が示す内容とをバイヤーが照合して、支払依頼の可否について判断した結果を、入力装置３０６で受け付ける機能を有している。
　また、この場合、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、支払依頼を承認するものであった場合、支払依頼のプラットフォームサーバ１００への送信を実行する機能を有している。また、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、支払依頼を否認するものであった場合、支払依頼のプラットフォームサーバ１００への送信を実行せず、当該否認の旨を、予め定めたバイヤー企業内の管理者端末など所定の端末に送信する機能を有している。
　決済業務支援システム１０が、このような機能を備えることで、紙媒体の請求書と集約後支払予定データとの照合結果をその後の処理に反映させ、支払依頼の正確性や、その後の処理の正確性を良好に維持できる。
　また、プラットフォームサーバ１００は、バイヤー端末３００より、請求書データに基づいた買掛金の情報を受信し、当該買掛金の情報を記憶装置１０１に格納する機能を有している。この場合、プラットフォームサーバ１００は、上述の決済処理の依頼を、バイヤーの利用銀行の銀行システム４００に送信する処理に伴い、決済処理の依頼が含む、請求書データの識別情報と対応する買掛金の情報を記憶装置１０１にて特定し、該当買掛金の情報に関する消込処理を実行する機能を有している。決済業務支援システム１０が、このような機能を備えることで、買掛金の消込処理が自動的に実行され、業務効率を向上させることができる。
　また、プラットフォームサーバ１００は、上述の支払通知の生成ないしサプライヤー端末２００からの指示に応じて、決済処理の依頼ないし支払通知が含む、サプライヤーへの支払内容の情報により、サプライヤーの利用銀行における当該サプライヤーの口座への入金予定の情報を生成し、これを記憶装置１０１に格納する機能を有している。
　この場合、プラットフォームサーバ１００は、サプライヤー端末２００より、請求書データに基づいた売掛金の情報を受信し記憶装置１０１に格納する機能を有している。また、プラットフォームサーバ１００は、上述の入金予定の情報と売掛金の情報とをマッチングし、入金予定の情報が含む、請求書データの識別情報と対応する売掛金の情報を記憶装置１０１にて特定し、該当売掛金の消込予定の情報を生成する機能を有している。
　決済業務支援システム１０が、このような機能を備えることで、売掛金の消込予定の情報を自動生成することが可能となり、後に実際の入金が確認された際の売掛金の消込処理の効率を良好なものとできる。
　また、プラットフォームサーバ１００は、上述のサプライヤーの口座への入金事実について、サプライヤーの利用銀行の銀行システム４００より通知を受信し、当該通知が示す入金内容と、上述の売掛金の消込予定の情報とをマッチングし、上述の入金内容と対応する売掛金の消込予定の情報を特定し、当該特定した売掛金に対する入金額の過不足を判定する機能を有している。
　この場合、プラットフォームサーバ１００は、上述の判定の結果、入金額の過不足が無かった場合、上記で特定した売掛金の消込処理を実行し、一方、上述の判定の結果、入金額の過不足があった場合、過不足額の情報をサプライヤー端末２００およびバイヤー端末３００に送信する機能を有している。なお、入金の過不足があった場合でも、売掛金の消込処理を行ってもよい。この場合、不足の場合は入金分のみの消し込みになる。また、過不足額の情報の送信と消し込みの両方を行ってもよい。
　決済業務支援システム１０が、このような機能を備えることで、決済業務支援システム１０におけるプラットフォームサーバ１００と銀行システム４００との連携が図られる上、売掛金の消込業務を効率的なものと出来る。また、バイヤーからの入金額に過不足が生じてしまっている状況にも対応できる。
　また、こうした入金額の過不足の発生原因として、例えば、サプライヤーとバイヤーとで取り決めた支払条件が遵守されずに一部入金のみされた状況が想定される。そうした状況であっても、本実施形態の決済業務支援システム１０であれば、入金額の過不足が生じている請求書データや売掛金の情報を特定し、その内容を追跡することもできる。当然、入金額の過不足発生時におけるエビデンスの確認などの事務が省力化され、事務処理ミスや不正を防ぐことができる。
　また、プラットフォームサーバ１００は、１組以上のサプライヤーとバイヤーのそれぞれについて、上述の集約後支払予定データを記憶装置１０１から読み出して、サプライヤーとバイヤーとの間の支払金額を相殺し、当該相殺後に残債分の内容のみとなった支払予定データが示す、サプライヤーないしバイヤーの利用銀行の銀行システム４００に対し、上述した残債分の集約後支払予定データが示す内容に応じた決済処理の依頼を送信する機能を有している。
　決済業務支援システム１０が、このような機能を備えることで、電子商取引の参加者が保有する債権(売掛金)と債務(買掛金)に紐付く送金取引を相殺し、例えば、ある一定の期日に差額分だけを決済することが可能となる。そのため、取引のたびに決済を行う場合に比べ、銀行手数料や事務処理の手間を削減できる。
　以下、本実施形態における決済業務支援方法の実際手順について図に基づき説明する。以下で説明する決済業務支援方法に対応する各種動作は、決済業務支援システム１０を構成する、上述のプラットフォームサーバ１００、サプライヤー端末２００、およびバイヤー端末３００らがそれぞれメモリ等に読み出して実行するプログラムによって実現される。また、処理の一部には、決済業務支援システム１０と銀行システム４００とのやりとりも含まれている。そして、これらのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
　図５は、本実施形態における決済業務支援方法の処理手順例１を示すデータフロー図である。ここでまず、サプライヤー端末２００が、サプライヤー企業における販売部門の担当者が入力した請求書データたるインボイスデータを、プラットフォームサーバ１００に送信する（ｓ１００）。この時、プラットフォームサーバ１００では、サプライヤー端末２００から送信されてきたインボイスデータ１２５を受信し、これを記憶装置１０１における共有データフォルダに格納する。
　一方、上述のインボイスデータ１２５の宛先となる、バイヤーの購買部門におけるバイヤー端末３００は、プラットフォームサーバ１００に対して、インボイス照会指示を出して（ｓ１０１）、プラットフォームサーバ１００よりインボイスデータ１２５を取得する（ｓ１０２）。この時、バイヤー端末３００は、プラットフォームサーバ１００より取得したインボイスデータ１２５を自身の記憶装置３０１に格納する。
　図１２にインボイスデータ１２５の例を示す。このインボイスデータ１２５は、請求書情報をキーとして、商品情報、金額情報、およびサプライヤー情報が紐付けされたレコードの集合体となっている。このうち、請求書情報は、該当インボイスを一意に識別するための番号と、該当インボイスの発行日からなっている。また、商品情報は、代金請求の対象となる商品の識別情報である商品番号、および商品名の各情報からなっている。また、金額情報は、前述の商品情報が含む各商品に関する、数量、単価、金額（数量×単価の値）、税率、合計の各値の情報からなっている。また、サプライヤー情報は、商品販売者たるサプライヤー企業の企業名、その納税人番号、および、前述の商品情報が含む各商品の代金入金先となる銀行口座情報からなっている。
　また、バイヤー端末３００は、記憶装置３０１に格納したインボイスデータ１２５に、予め定めた決済用の情報、ないし入力装置３０１からバイヤー企業の所定担当者が指定した決済用の情報を付与して、サプライヤー宛の支払予定データ１２６を生成し、プラットフォームサーバ１００に送信する（ｓ１０３）。なお、インボイスデータ１２５に付与する、上述の決済用の情報は、例えば、インボイスデータ１２５が含んでいた、インボイス支払期日の情報や、バイヤーが決定する支払予定日の情報、決済資金の振り込みにバイヤー企業が使用している銀行口座の情報である支払口座情報、などを想定できる。なお、支払予定日に関しては、インボイス発行日の値から一定日数を減算して算出してもよい。
　図１２Ａに支払予定データ１２６の例を示す。この支払予定データ１２６は、支払予定情報、請求書情報、商品情報、金額情報、支払予定額、入金口座情報、および支払口座情報が互いに紐付けされたレコードの集合体となっている。これらの情報のうち、上述したインボイスデータ１２５と異なる情報は、支払予定情報、支払予定金額、および支払口座情報の各情報となる。
　支払予定情報は、インボイスデータ１２５が含んでいた、支払期日の情報、インボイスデータ１２５が含んでいたバイヤーが決定する支払予定日の情報、および、ステータスの各情報となる。なお、支払予定日に関しては、インボイス発行日の値から一定日数を減算して算出してもよい。このステータスの情報は、当該支払予定データ１２６における該当レコードについてなされた処理の段階を示すものとなる。図１２Ａに示す例では、インボイスデータ１２５（における該当レコード）が示す内容と、バイヤーが所持している紙媒体の請求書が示す内容とをバイヤーが照合（リコンサイル）したか否かを示す値が設定されている。ステータスの値のリスト１３２Ａについては、図１３Ｂに例示する。以降、各処理に伴ってステータスの値が更新される場合、この図１３Ｂに示すリスト１３２Ａに基づいて、プラットフォームサーバ１００が更新を実行するものとする。
　また、支払予定金額は、当該支払予定データ１２６における該当レコードに関し、バイヤーがサプライヤー宛てに入金予定である金額の値が設定されている。通常は、金額情報における合計の値と同額となる。ただし、預金残高不足、契約内容変更等の状況を踏まえたバイヤー側の判断で、金額情報における合計の値と同額でない値が設定される場合もありうる。これらの値は、バイヤー企業における所定の担当者が、バイヤー端末３００の入力装置３０６にて入力することとなる。
　また、支払口座情報は、決済資金の振り込みにバイヤー企業が使用している銀行口座の情報であり、バイヤー企業の企業名、商品代金の出金元となる銀行口座情報からなっている。
　なお、上述のインボイスデータ１２５に含まれる一部の情報が記載された紙媒体の請求書が、電子データのインボイスデータ１２５とは別に、サプライヤー企業からバイヤー企業に宛てて郵送されている。この紙媒体の請求書としては、例えば、中国で利用されているファーピャオが一例となる。図５以降の各図においても、「ファーピャオ」と記している。ファーピャオ（発票）は、中国における請求書（Invoice）ないし領収書であり、税務機関が発行した法定の発票用紙が利用されている。バイヤー企業では、サプライヤー企業からこのファーピャオを受領し、保管しているものとする。
　一方、サプライヤー端末２００においては、インボイスデータ１２５やファーピャオなどに基づいて通常の仕訳作成処理（ｓ１０４）が実行され、それにより生成した売掛金情報１２７をプラットフォームサーバ１００にアップロードする。また、仕訳作成処理（ｓ１０４）に伴って総勘定元帳１２８（図中では“ＧＬ”と記す）の生成も通常通り行われ、この総勘定元帳１２８はサプライヤー端末２００の記憶装置２０１に保持される。
　他方、プラットフォームサーバ１００は、サプライヤー端末２００より売掛金情報１２７を受信し、これを記憶装置１０１に格納する。売掛金情報１２７の例は図１５Ａに示す。売掛金情報１２７は、記帳日、販売先企業を示す売掛先、販売した商品の商品番号や商品名を示す商品情報、その金額情報、インボイスデータ１２５の識別情報や発行日を示す請求書情報、回収予定情報といったデータを含んでいる。回収予定情報は、該当売掛金の回収日、とその回収状況を示すステータスの各情報を含む。
　なお、上述のファーピャオの郵送に伴い、バイヤー企業の所定の担当者が、取引の正確性を維持するためにも、このファーピャオと、上述したインボイスデータ１２５との整合性について照合する必要がある。そこで、バイヤー端末３００は、プラットフォームサーバ１００から受信したインボイスデータ１２５を出力装置３０７に表示させ、上述の担当者による照合に供するものとする。
　この担当者は、紙媒体のファーピャオの記載内容と、出力装置３０７に表示されたインボイスデータ１２５とを見比べ、対応項目の各値が互いに一致するか照合作業（リコンサイル）を行う。
　この時、バイヤー端末３００は、こうして、出力装置３０７に表示したインボイスデータ１２５が示す内容と、紙媒体のファーピャオが示す内容とをバイヤーが照合した結果を、入力装置３０６で受け付ける（ｓ１０５）。リコンサイル画面の例としては、図１７、図１７Ａにて示すとおりである。図１７には、処理対象となるインボイスデータ１２５のリストが表示され、図１７Ａには、そのうちの１つのインボイスデータ１２５の詳細情報が表示されている。
　バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、インボイスデータ１２５の内容と紙媒体のファーピャオの内容とに差異が無いことを示す場合（ｓ１０６：Ｙ）、上述のインボイスデータ１２５に基づく仕訳作成（ｓ１０９）および買掛金情報１３０（図１４Ａ参照）の生成と、この買掛金情報１３０のプラットフォームサーバ１００への送信とを実行する。また、バイヤー端末３００は、この処理に伴って、支払予定データ１２６において、該当レコードのステータスを「リコンサイル済」と更新する。なお、上述のステップｓ１０９で仕訳作成を行うことで、通常の総勘定元帳１３１（図中では、“ＧＬ”と記す）が生成される。
　なお、上述の買掛金情報１３０は、図１４Ａに例示するように、記帳日、購入先企業を示す仕入れ先、購入した商品の商品番号や商品名を示す商品情報、その金額情報、インボイスデータ１２５の識別情報を示す請求書情報、および、買掛に対する支払状況を示す消込区分、といったデータを含んでいる。図１４Ａの例では、「消込区分」の値が、「全部支払済」、または「一部支払済」となっている。買掛金情報１３０は、インボイスデータ１２５に基づいて作成されているため、消込有無を示す「消込区分」の値の他は、インボイスデータ１２５と同様の構成となる。
　一方、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、インボイスデータ１２５の内容と紙媒体のファーピャオの内容とに差異があることを示す場合（ｓ１０６：Ｎ）、その差異の情報、すなわち差分情報１２９を、プラットフォームサーバ１００に送信する（ｓ１０７）。上述の差分情報１２９は、例えば、上述の差異が生じている項目名と、該当項目に関する、インボイスデータ１２５と紙媒体のファーピャオでの各値とが含まれたデータとなる。
　他方、プラットフォームサーバ１００は、上述の差分情報１２９をバイヤー端末３００から受信して記憶装置１０１に格納する。また、プラットフォームサーバ１００は、サプライヤー端末２００に対し、この差分情報１２９に関する確認要求を送信する（ｓ１０８）。サプライヤー側では、この差分情報１２９をサプライヤー端末２００にて確認し、所定の担当者が、ファーピャオの修正と再発行、或いはインボイスデータ１２５の修正と再度のアップロードといった以後の対応を決め、必要な措置をとることとなる。
　続いて、上述した支払予定データ１２６の集約処理について図に基づき説明する。図６は、本実施形態における決済業務支援方法の処理手順例２を示すデータフロー図である。この場合、プラットフォームサーバ１００は、図６に示すように、例えばインボイス発行日の夜間まで、サプライヤー端末２００から受信した最新の各インボイスデータ１２５について、上述した支払予定データ１２６に関する処理を繰り返し、記憶装置１０１に複数の支払予定データ１２６のレコードを蓄積しているものとする（ｓ１２０）。
　ここでプラットフォームサーバ１００は、例えば、記憶装置１０１に一定数以上の支払予定データ１２６のレコードが蓄積されたことを検知するなどし、支払予定集約提案をバイヤー端末３００に通知する（ｓ１２１）。この時、バイヤー端末３００では、この通知を受けて、支払予定データ１２６の集約指示をプラットフォームサーバ１００に返す（ｓ１２２）。この集約指示は、バイヤー企業における所定の担当者がバイヤー端末３００の入力装置３０６にて入力し、これを受けたバイヤー端末３００がプラットフォームサーバ１００に送信するものとしてもよい。
　プラットフォームサーバ１００は、バイヤー端末３００より上述の支払予定情報の集約指示を受信した場合、該当バイヤーに関する支払予定データ１２６を、上述の「支払口座情報」が示す「企業名」の値等に基づいて記憶装置１０１より読み出し、読み出した支払予定データ１２６のうち、予め定めた所定項目ないしバイヤー端末３００から指定を受けた所定項目が共通する支払予定データ１２６を特定し、ここで特定した各支払予定データ１２６における支払金額を合算して該当支払予定データ１２６らマージし、当該マージ後の支払予定データを集約後支払予定データ１３２として記憶装置１０１に格納する（ｓ１２３）。
　集約対象となる支払予定データ１２６を特定する際に利用する、上述の所定項目としては、例えば、「支払予定情報」における「支払期日」、「支払予定情報」における「支払予定日」、「請求書情報」における「番号」、「入金口座情報」における「企業名」と「銀行」、「支店」、「口座番号」、といったものがあげられる。
　こうした所定項目が、「銀行」：あ銀行、かつ「口座番号」：６６６６６６６６、および、「銀行」：い銀行、かつ「口座番号」：６６６６６６６７、であったとする。その場合、プラットフォームサーバ１００は、図１２Ａに例示した支払予定データ１２６のうち、上から２つのレコード同士、および下から２つのレコード同士をそれぞれ集約対象として特定することとなる。また、各レコード同士において、「支払予定情報」の「予定金額」を合算し、集約後支払予定データ１３２における「金額情報」の「金額」値を算定する。図１３に集約後支払予定データ１３２の例を示す。ここで例示した集約後支払予定データ１３２は、上述したように、支払予定データ１２６における４レコードを２レコードずつ集約したものであるから、２レコードを有している。
　また、プラットフォームサーバ１００は、バイヤー端末３００に対し、上述の如く生成した集約後支払予定データ１３２の照会通知を送る。バイヤー端末３００ではこの通知を受けて、集約後支払予定データ１３２をプラットフォームサーバ１００より得て出力装置３０７に表示し（ｓ１２４）、所定担当者による、支払口座の選択指示を入力装置３０６にて受け付ける（ｓ１２５）。
　この時、バイヤー端末３００は、プラットフォームサーバ１００からバイヤー口座情報１３３（図１３Ａ参照）を読み出して、支払口座の選択用リストとして出力装置３０７にて表示することとなる。また、上述の担当者は、支払口座選択に伴って、該当銀行が提供する種々の振込方式中より所望の送金方式（例：個別振込、総合振込）を選択する。
　バイヤー端末３００は、その選択事項を入力装置３０６で受け（ｓ１２６）、この選択事項と、上述のステップｓ１２５で得ている支払口座の選択事項とを含む支払予定申請をプラットフォームサーバ１００に通知する（ｓ１２７）。
　プラットフォームサーバ１００では、バイヤー端末３００から、支払予定申請を受信し、当該申請が含む送金方式の値として、例えば「総振」（総合振込形式）の値を取得し、この値を、上述の集約後支払予定データ１３２の該当欄「総振」にて設定する。図３の例では、「総振」欄にて設定されるのは、該当銀行との総合振込形式の契約有無の値となる。また、プラットフォームサーバ１００は、上述の支払予定申請が含む支払口座の選択事項の値を、集約後支払予定データ１３２における該当欄「支払口座情報」に設定する。
　次に、バイヤー側で実際に支払を行う日、集約後支払予定データ１３２における「支払予定日」が到来した場合の処理について図に基づき説明する。図７は、本実施形態における決済業務支援方法の処理手順例３を示すデータフロー図である。
　この場合、例えば、プラットフォームサーバ１００が集約後支払予定データ１３２における「支払予定日」の到来を、自身の備えるカレンダー機能にて検知し、その旨をバイヤー端末３００に通知するとする（ｓ１２９）。バイヤー端末３００では、この通知を受けて、支払依頼の申請をプラットフォームサーバ１００に送信する（ｓ１３０）。勿論、バイヤー企業における所定の担当者が、バイヤー端末３００の入力装置３０６にて上述の支払依頼の申請データを入力し、バイヤー端末３００がプラットフォームサーバ１００に送信するとしてもよい。
　一方、プラットフォームサーバ１００は、バイヤー端末３００より上述の支払依頼の申請を受信し（ｓ１３１）、該当バイヤー（例：企業名ＡＢ）に関する集約後支払予定データ１３２（例：「支払口座情報」欄の「企業名」の値が、“企業名ＡＢ”）を記憶装置１０１より読み出し、バイヤー端末３００に送る。
　バイヤー端末３００は、プラットフォームサーバ１００より集約後支払予定データ１３２を取得して出力装置３０７に表示させる（図１８、図１８Ａ）。この場合、バイヤー端末３００は、集約後支払予定データ１３２が示す内容と、サプライヤーからバイヤー宛てに送付されていた紙媒体の請求書すなわちファーピャオが示す内容とをバイヤーが照合して、支払依頼の可否について判断した結果を、入力装置３０６で受け付ける（ｓ１３２）。こうした支払依頼の可否判断は、バイヤー企業における経理部門の担当者が実行することになる。
　バイヤー端末３００は、入力装置３０６で受け付けた上述の可否判断の結果が、支払依頼を承認しないものであった場合（ｓ１３３：Ｎ）、支払依頼の否認通知をプラットフォームサーバ１００へ送信し、当該否認の旨を、バイヤー企業における購買部門のバイヤー端末３００など所定の端末に送信する（ｓ１３５）。
　他方、バイヤー端末３００は、入力装置３０６で受け付けた上述の可否判断の結果が、支払依頼を承認するものであった場合（ｓ１３３：Ｙ）、該当集約後支払予定データ１３２における「支払口座情報」が示す銀行（例：う銀行）の銀行システム４００に対し、所定のログイン認証処理を経て、該当口座（例：上海支店、口座番号３３３３３３３）の残高照会を行う（ｓ１３６）。
　銀行システム４００では、この残高照会を受けて（ｓ１３７）、該当口座の口座残高の値をバイヤー端末３００に返す（ｓ１３８）。バイヤー端末３００は、この口座残高の値が、上述の集約後支払予定データ１３２における「予定金額」の値を満たすか判定する（ｓ１３９）。バイヤー端末３００は、必要な残高があると判断した場合（ｓ１３９：Ｙ）、上述の支払依頼に関して承認登録指示をプラットフォームサーバ１００に送信する（ｓ１４１）。他方、バイヤー端末３００は、口座残高の値が「予定金額」に不足しており、必要な残高が無いと判断した場合（ｓ１３９：Ｎ）、例えば、バイヤー企業が保有する他の銀行口座から該当口座へ、上述の不足分の金額の入金処理を実行し（ｓ１４０）、処理を上述のステップｓ１３９に戻す。
　一方、ステップｓ１４１にてバイヤー端末３００から承認登録指示が送信されたプラットフォームサーバ１００では、これを受けて、該当集約後支払予定データ１３２が示す、該当バイヤーの利用銀行（例：う銀行）の銀行システム４００に対し、集約後支払予定データ１３２における「支払口座情報」が示す口座から、「入金口座情報」が示す銀行口座への、「金額情報」が示す金額に応じた、決済処理の依頼を送信する（ｓ１４２）。銀行システム４００では、この決済処理の依頼を受け付けて（ｓ１４３）、バイヤー企業の口座からサプライヤー企業の口座への振込処理を行うなどして、所定の決済処理を実行する。
　また、プラットフォームサーバ１００は、決済処理の依頼を銀行システム４００に送信する処理に伴い、決済処理の依頼が含む、集約後支払予定データ１３２における「請求書情報」の「番号」と対応する買掛金情報１３０（図１４Ａ参照）を、記憶装置１０１にて特定し、該当買掛金情報に関する消込処理を実行する（ｓ１４４）。図１４Ａの例においては、買掛金情報１３０における「消込区分」の値が、「全部支払済」、または「一部支払済」となっている。買掛金情報１３０は、インボイスデータ１２５に基づいて作成されているため、消込有無を示す「消込区分」の値の他は、インボイスデータ１２５と同様の構成となる。
　なお、プラットフォームサーバ１００は、この買掛金情報１３０に関する消込処理の結果を、バイヤー端末３００に通知する。バイヤー端末３００では、この通知を受けて、消し込まれた買掛金情報に応じて仕訳作成処理を実行し（ｓ１４５）、総勘定元帳１３１を更新することになる。バイヤー企業における経理部門の担当者は、バイヤー端末３００を用いて、この総勘定元帳１３１の照会を行える。
　また、プラットフォームサーバ１００は、買掛金情報の消込処理を実行後、決済処理の依頼がなされた該当インボイスデータ１２５（のレコード）に関する支払通知１３４（図１４参照）を生成して（ｓ１４７）、該当サプライヤー端末２００に宛てて送信する。支払通知１３４は、決済処理の依頼がなされた該当インボイスデータ１２５（のレコード）とデータ構成は同様である。但し、図１４の例では、支払通知１３４における「ステータス」の値は、サプライヤーから請求された金額に対してバイヤーの決済した額が一致する場合の「全部支払済」、または、サプライヤーから請求された金額に対してバイヤーの決済した額が不足する場合の「一部支払済」となっている。
　次に、売掛金情報の消込処理について図に基づき説明する。図８は、本実施形態における決済業務支援方法の処理手順例４を示すデータフロー図であり、図９は、本実施形態における決済業務支援方法の処理手順例５を示すデータフロー図である。この場合、プラットフォームサーバ１００は、上述の支払通知１３４の生成を契機に、或いは、サプライヤー端末２００からの支払通知の照会や作成指示（ｓ１５０，ｓ１５１）に応じて、入金予定情報１３５の生成を実行し（ｓ１５２）、これを記憶装置１０１に格納する。
　この入金予定情報１３５は、上述の決済処理の依頼ないし支払通知１３４が含む、サプライヤーへの支払内容の情報に基づいて生成するものであり、図１５に示すように、バイヤー端末３００から決済依頼を受けて支払通知を作成した日である支払通知受領日、バイヤー企業から入金がなされたサプライヤー企業の口座を示す入金口座情報、支払がなされた金額を示す金額情報、対応するインボイスデータ１２５の番号とその発行日を示す請求書情報、支払対象の商品の商品番号と商品名を示す商品情報、支払期日と実際の支払日と支払ステータスを示す支払情報、およびバイヤー企業が支払に用いた口座を示す支払口座情報の各データからなっている。図１５に示す例の場合、入金予定情報１３５における「ステータス」が、「支払未済」となっている。現時点では、入金の予定であって、プラットフォームサーバ１００が実際に銀行システム４００から入金通知を受信していない状態のためである。
　また、プラットフォームサーバ１００は、入金予定情報１３５の生成の旨を、サプライヤー端末２００に通知する。これを受けたサプライヤー端末２００は、入金予定情報１３５をプラットフォームサーバ１００より取得し（ｓ１５３）、これを閲覧した経理部門の担当者からの指示を入力装置２０６にて受け付ける。この指示は、売掛金の消込予定の作成指示となる。この作成指示はサプライヤー端末２００からプラットフォームサーバ１００に送信される（ｓ１５４）。
　この場合、プラットフォームサーバ１００は、サプライヤー端末２００より上述の作成指示を受けて、記憶装置１０１に格納している入金予定情報１３５および売掛金情報１２７（図１５Ａ参照）を読み出し、更に、入金予定情報１３５が含む、インボイスデータ１２５の識別情報すなわち「請求書情報」における「番号」の値と対応する、売掛金情報１２７（のレコード）を記憶装置１０１にて特定（マッチング）する（ｓ１５５）。なお、売掛金情報１２７は、インボイスデータ１２５から生成されるもので、既に述べたように、記帳日、売掛先、商品情報、金額情報、請求書情報、回収予定情報といったデータを含んでいる。回収予定情報は、該当売掛金の回収日、とその回収状況を示すステータスの各情報を含む。
　この時、プラットフォームサーバ１００は、上述のステップｓ１５５で特定した、該当売掛金の消込予定の情報１３６（図１５Ｂ参照）を生成する。売掛金消込予定情報１３６は、上述した売掛金情報１２７とほぼ同様のデータ構成となっており、入金予定日、売掛先、請求書情報、商品情報、金額情報、および回収予定情報から構成されている。なお、サプライヤー端末２００では、上述の売掛金消込予定情報１３６を取得して出力装置２０７に図１９、図１９Ａのごとく表示し（ｓ１５６）、サプライヤー企業における経理部門の担当者の閲覧に供する。
　上述のごとく、バイヤー企業からサプライヤー企業に対する支払行為が実行された後、実際に、「支払口座情報」で指定されたバイヤーの銀行口座から、「入金口座情報」で指定されたサプライヤーの銀行口座への振込が実行された際の処理について、続いて説明する。
　この場合、バイヤー側からの入金を受けたサプライヤー側の銀行の銀行システム４００は、上述の入金事実を示す入金通知を、プラットフォームサーバ１００およびサプライヤー端末２００に送信するものとする。
　サプライヤー端末２００は上述の入金通知を受けて、入金情報１３７の作成指示をプラットフォームサーバ１００に送る（ｓ１５７）。
　一方、プラットフォームサーバ１００は、上述のサプライヤーの口座に関する入金通知を受信し、更には、サプライヤー端末２００から上述の入金情報作成指示を受けて、前記入金通知が示す情報に基づいて、入金情報１３７を作成し、記憶装置１０１に格納する（ｓ１５８）。入金情報１３７は、図１６に示すように、銀行に実際に入金があった日付を示す入金日、入金があった口座を示す入金口座、入金の依頼人すなわち振込の実行企業たる依頼人、および入金された金額を示す金額情報の各データから構成されている。
　他方、サプライヤー端末２００は、上述の入金情報作成指示をプラットフォームサーバ１００に送信した後、上述の入金通知を出力装置２０７に表示させて、サプライヤー企業における経理部門の担当者による、ファーピャオとの照合作業に供する。この経理部門の担当者は、入金通知の示す内容がファーピャオの示す内容と整合性がとれているか確認することになる。経理部門の担当者は、両者の整合性がとれていると判断した場合、サプライヤー端末２００の入力装置２０６において、上述の入金通知に対応した売掛金に関する消込処理の依頼指示を入力する。
　サプライヤー端末２００は、この消込処理の依頼指示を入力装置２０６にて受けて、これをプラットフォームサーバ１００に送信する（ｓ１５９）。一方、プラットフォームサーバ１００は、この売掛金消込依頼を受けて、上述の入金情報１３７と、上述の売掛金消込予定情報１３６とをマッチングし、上述の入金通知の内容と対応する売掛金の売掛金消込予定情報１３６を特定し、該当売掛金に関する消込処理を売掛金情報１２７にて実行する（ｓ１６０）。このステップにて具体的には、プラットフォームサーバ１００は、図１６Ａに示す売掛金情報１２７にて、「金額情報」における「売掛金残高」の値を「０」、「１７０」などと設定し、「消込区分」における「区分」の値を、「全部消込済」、「一部消込済」と設定している。また、プラットフォームサーバ１００は、この売掛金の消込処理の実行通知をサプライヤー端末２００に送る。
　サプライヤー端末２００は、上述の売掛金の消込処理の実行通知を受信し、売掛先情報１２７に関する仕訳作成処理を実行し（ｓ１６１）、総勘定元帳１２８を更新する。サプライヤー端末２００は、サプライヤー企業における経理部門の担当者からの指示を受け、この総勘定元帳１３１の照会を行える。（ｓ１６２）。
　一方、上述のステップｓ１６０にて売掛金の消込処理を実行した後、上述の入金通知の内容と対応する売掛金情報１２７ないし売掛金消込予定情報１３６を特定し、当該特定した売掛金に対する入金額の過不足を判定する（ｓ１６３）。この場合、プラットフォームサーバ１００は、例えば、上述の図１６Ａに示す売掛金情報１２７にて、「金額情報」における「売掛金残高」の値と、「消込区分」における「区分」の値とを読み取り、「売掛金残高」の値が「０」以外であるレコード、或いは、「消込区分」における「区分」の値が「全部消込済」以外であるレコードを検索し、該当レコードを検索できた場合、売掛金に対する入金額の過不足が生じていると判定することとなる。
　プラットフォームサーバ１００は、上述の判定の結果、入金額の過不足が無かった場合（ｓ１６４：Ｙ）、上記で特定した売掛金消込の連絡をサプライヤー端末２００に実行する（ｓ１６５）。或いは、入金額の過不足が無かった場合（ｓ１６４：Ｙ）に、上記で特定した売掛金消込の処理を実行するとしてもよい。なお、入金の過不足があった場合でも、売掛金の消込処理を行ってもよい。この場合、不足の場合は入金分のみの消し込みになる。また、過不足額の情報の送信と消し込みの両方を行ってもよい。
　一方、上述の判定の結果、入金額の過不足があった場合（ｓ１６４：Ｎ）、過不足額の情報たる入金過不足情報１３９を作成し（ｓ１６７）、これをサプライヤー端末２００に送信する（ｓ１６８）。図１６Ｂに入金過不足情報１３９を示している。この入金過不足情報１３９は、入金額の過不足があった売掛金情報１２７のレコード（元のインボイスデータ１２５のレコードとも言える）に関する、入金日、入金口座情報、金額情報、請求書情報、支払情報、商品情報、支払口座情報、および備考の各情報からなっている。「備考」の情報には、サプライヤー企業やバイヤー企業にてとられるべき所定の対応策案がプラットフォームサーバ１００にて設定される。
　サプライヤー端末２００では、上述の入金過不足情報１３９をプラットフォームサーバ１００より受信し（ｓ１６９）、これを受けて、プラットフォームサーバ１００における共有フォルダ（バイヤー端末３００からもアクセス可能なフォルダ）に格納される、入金過不足情報１４０の作成指示を、プラットフォームサーバ１００に送る（ｓ１７０）。プラットフォームサーバ１００ではこの作成指示を受け、上述の入金過不足情報１３９をコピーして入金過不足情報１４０とし、記憶装置１０１における共有フォルダに格納する（ｓ１７１）。また、プラットフォームサーバ１００は、この入金過不足情報１４０に基づいて、過不足情報の連絡をバイヤー端末３００に送る（ｓ１７２）。
　バイヤー端末３００では、上述の過不足情報の連絡をプラットフォームサーバ１００より受信し、これを出力装置３０７にて表示、バイヤー企業における購買部門の担当者に閲覧させる（ｓ１７３）。入金額に過不足があった事実を感知したサプライヤー企業およびバイヤー企業では、例えば、連絡を取り合って契約内容の再確認や修正、過不足分の金額の決済などの後処理を実行することとなる。
　次に、決済金額の相殺処理について図に基づき説明する。図１０は、本実施形態における決済業務支援方法の処理手順例６を示すフロー図である。ここでは、プラットフォームサーバ１００における電子商取引の参加者が保有する債権(売掛金)と債務(買掛金)に紐付く送金取引を相殺し、ある一定の期日に差額分だけを決済する手法について示す。こうした処理を行うことで、取引のたびに決済を行う場合と比較して、銀行手数料や事務処理の手間を削減できる効果がある。なお、２者間について相殺処理を行う方式（バイラテラルネッティング）、統括会社などが仲介して３者以上で相殺処理を行う方式（マルチラテラルネッティング）のいずれかを状況に応じて採用できる。
　この場合、プラットフォームサーバ１００は、互いに債権、債務を負っている、すなわち、インボイスデータ１２５や支払予定データ１３２、或いは集約後支払予定データ１３２における「支払口座情報」の「企業名」の値がお互いを指し合っている、１組以上のサプライヤーとバイヤーを、「支払口座情報」の「企業名」の値をキーに特定する（ｓ１８０）。
　次にプラットフォームサーバ１００は、上記で特定した１組以上のサプライヤーとバイヤーのそれぞれについて、上述の集約後支払予定データ１３２を記憶装置１０１から読み出して（ｓ１８１）、それら集約後支払予定データ１３２における支払金額の値を、該当サプライヤーと該当バイヤーとの間で相殺する（ｓ１８２）。
　また、プラットフォームサーバ１００は、当該相殺後に残債分の内容のみが残された支払予定データ１３２が示す、サプライヤーないしバイヤーの利用銀行の銀行システム４００に対し、上述した残債分の集約後支払予定データ１３２が示す内容に応じた決済処理の依頼を送信する（ｓ１８３）。該当銀行システム４００ではこの依頼に応じて決済処理を実行することとなる。
　例えば、上述のステップｓ１８０で特定できたサプライヤーとバイヤーの組みが１組であった場合、いわゆるバイラテラル・ネッティングが実行されることになる。支払金額の相殺すなわちネッティング前、図１１に例示するような３つの取引をＡ社とＢ社が行っていたとする。上述のステップｓ１８２を実行すれば、図１１の下段にて示すように、相殺後に残債分の内容のみが残された支払予定データ１３２Ｂは、「債務者」が「Ａ社」、「債権者」が「Ｂ社」、決済金額の残債は「２００」となる。このように、従来どおり１取引ごとに決済した場合、為替／送金取引は、３取引分そのままの３回分必要となるが、ネッティング後は１回分のみとなる。
　また、上述のステップｓ１８０で特定できたサプライヤーとバイヤーの組みが２組以上であった場合、いわゆるマルチラテラル・ネッティングが実行されることになる。支払金額の相殺すなわちネッティング前、図１１Ａ、図１１Ｂに例示するような６つの取引を、Ａ社、Ｂ社、Ｃ社、Ｄ社が行っていたとする。上述のステップｓ１８２を実行すれば、図１１Ａの下段、および図１１Ｃにて示すように、相殺後に残債分の内容のみが残された支払予定データ１３２Ｂは、「債務者」が「Ａ社」、「債権者」が「Ｃ社」、決済金額の残債は「１８４６」となる。このように、従来どおり１取引ごとに決済した場合、為替／送金取引は、６取引分そのままの６回分必要となるが、ネッティング後は１回分のみとなった。つまり、為替／送金取引を大幅に減らし、手数料を削減できる。
　以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
　こうした本実施形態によれば、企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減が可能となる。
　本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の決済業務支援方法において、前記バイヤーの端末が、前記コンピュータから受信した請求書データを出力装置に表示させる処理と、前記請求書データが示す内容と、サプライヤーから送付されていた紙媒体の請求書が示す内容とをバイヤーが照合した結果を、入力装置で受け付ける処理とを実行し、前記入力装置で受け付けた結果が、請求書データの内容と紙媒体の請求書の内容とに差異が無いことを示す場合、前記請求書データに基づく買掛金の情報の生成と、この買掛金の情報の前記コンピュータへの送信を実行し、前記入力装置で受け付けた結果が、請求書データの内容と紙媒体の請求書の内容とに差異があることを示す場合、その差異の情報を前記コンピュータに送信する処理を実行し、前記コンピュータが、前記差異の情報を前記バイヤーの端末から受信して、当該差異の情報を記憶装置に格納し、前記サプライヤーの端末に前記差異に関する確認要求を送信する処理を実行する、としてもよい。
　また、本実施形態の決済業務支援方法において、前記コンピュータが、前記バイヤーの端末より支払依頼を受信した場合、前記バイヤーに関する集約後支払予定データを記憶装置より読み出し、当該集約後支払予定データが示す、前記バイヤーの利用銀行のシステムに対し、前記集約後支払予定データが示す内容に応じた決済処理の依頼を送信する処理と、前記決済処理の依頼を前記バイヤーの利用銀行のシステムに送信する処理に伴い、前記決済処理の依頼がなされた該当請求書データに関する支払通知を生成して、該当サプライヤーの端末に宛てて送信する処理と、を実行するとしてもよい。
　また、本実施形態の決済業務支援方法において、前記バイヤーの端末が、前記支払依頼をコンピュータに送信するに伴い、前記コンピュータより前記集約後支払予定データを取得して出力装置に表示させる処理と、前記集約後支払予定データが示す内容と、サプライヤーから送付されていた紙媒体の請求書が示す内容とをバイヤーが照合して、前記支払依頼の可否について判断した結果を、入力装置で受け付ける処理とを実行し、前記入力装置で受け付けた結果が、前記支払依頼を承認するものであった場合、前記支払依頼の前記コンピュータへの送信を実行し、前記入力装置で受け付けた結果が、前記支払依頼を否認するものであった場合、前記支払依頼の前記コンピュータへの送信を実行せず、当該否認の旨を予め定めた所定の端末に送信する処理を実行する、としてもよい。
　また、本実施形態の決済業務支援方法において、前記コンピュータが、前記バイヤーの端末より、前記請求書データに基づいた買掛金の情報を受信し、当該買掛金の情報を記憶装置に格納する処理と、前記決済処理の依頼を前記バイヤーの利用銀行のシステムに送信する処理に伴い、前記決済処理の依頼が含む、請求書データの識別情報と対応する前記買掛金の情報を特定し、該当買掛金の情報に関する消込処理と、を実行するとしてもよい。
　また、本実施形態の決済業務支援方法において、前記コンピュータが、前記支払通知の生成ないし前記サプライヤーの端末からの指示に応じて、前記決済処理の依頼ないし前記支払通知が含む、前記サプライヤーへの支払内容の情報により、前記サプライヤーの利用銀行における当該サプライヤーの口座への入金予定の情報を生成し、記憶装置に格納する処理と、前記サプライヤーの端末より、前記請求書データに基づいた売掛金の情報を受信し記憶装置に格納する処理と、前記入金予定の情報と前記売掛金の情報とをマッチングし、前記入金予定の情報が含む、請求書データの識別情報と対応する前記売掛金の情報を特定し、該当売掛金の消込予定の情報を生成する処理と、を実行するとしてもよい。
　また、本実施形態の決済業務支援方法において、前記コンピュータが、前記サプライヤーの口座への入金事実について、前記サプライヤーの利用銀行より通知を受信し、当該通知が示す入金内容と、前記売掛金の消込予定の情報とをマッチングし、前記入金内容と対応する前記売掛金の消込予定の情報を特定し、当該特定した売掛金に対する入金額の過不足を判定する処理と、前記判定の結果、入金額の過不足が無かった場合、前記特定した売掛金の消込処理を実行し、前記判定の結果、入金額の過不足があった場合、過不足額の情報を前記サプライヤーの端末および前記バイヤーの端末に送信し、前記特定した売掛金の消込処理を、前記過不足額分について実行する、としてもよい。　また、本実施形態の決済業務支援方法において、前記コンピュータが、１組以上のサプライヤーとバイヤーのそれぞれについて、前記集約後支払予定データを記憶装置から読み出して、サプライヤーとバイヤーとの間の支払金額を相殺し、当該相殺後に残債分の内容のみとなった支払予定データが示す、サプライヤーないしバイヤーの利用銀行のシステムに対し、前記残債分の集約後支払予定データが示す内容に応じた決済処理の依頼を送信する処理を実行する、としてもよい。
１０　　決済業務支援システム
１００　プラットフォームサーバ（コンピュータ）
１０１、２０１、３０１　記憶装置
１０２、２０２、３０２　プログラム
１０３、２０３、３０３　メモリ
１０４、２０４、３０４　演算装置
２０６、３０６　入力装置
２０７、３０７　出力装置
１０５、２０５、３０５　通信装置
１１０、２１０、３１０　データ類
１２０　ネットワーク
１２５　インボイスデータ
１２６　支払予定データ
１２７　売掛金情報
１２８、１３１　総勘定元帳
１２９　差分情報
１３０　買掛金情報
１３２　集約後支払予定データ
１３３　バイヤー口座情報
１３４　支払通知
１３５　入金予定情報
１３６　売掛金消込予定情報
１３７　入金情報
１３９、１４０　入金過不足情報
２００　サプライヤー端末
３００　バイヤー端末
４００　銀行システム

Claims (9)

  1. 　企業間の電子商取引を仲介するコンピュータが、
    　電子商取引におけるサプライヤーの端末より、バイヤーに宛てた請求書データを受信して記憶装置に格納し、前記バイヤーの端末からの取得要求に応じて前記請求書データを記憶装置から読み出してバイヤーの端末に送信する処理を実行し、
    　前記バイヤーの端末が、
    　当該バイヤー宛ての請求書データの取得要求を前記コンピュータに送り、前記コンピュータから該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して前記サプライヤー宛の支払予定データを生成し、前記コンピュータに送信する処理を実行し、
    　前記コンピュータが、
    　前記バイヤーの端末から受信した支払予定データのうち、予め定めた所定項目ないし前記バイヤー端末から指定を受けた所定項目が共通する支払予定データを特定し、前記特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置に格納する処理を実行する、
    　ことを特徴とする決済業務支援方法。
  2. 　前記バイヤーの端末が、
    　前記コンピュータから受信した請求書データを出力装置に表示させる処理と、
    　前記請求書データが示す内容と、サプライヤーから送付されていた紙媒体の請求書が示す内容とをバイヤーが照合した結果を、入力装置で受け付ける処理とを実行し、
    　前記入力装置で受け付けた結果が、請求書データの内容と紙媒体の請求書の内容とに差異が無いことを示す場合、前記請求書データに基づく買掛金の情報の生成と、この買掛金の情報の前記コンピュータへの送信を実行し、
    　前記入力装置で受け付けた結果が、請求書データの内容と紙媒体の請求書の内容とに差異があることを示す場合、その差異の情報を前記コンピュータに送信する処理を実行し、
    　前記コンピュータが、
    　前記差異の情報を前記バイヤーの端末から受信して、当該差異の情報を記憶装置に格納し、前記サプライヤーの端末に前記差異に関する確認要求を送信する処理を実行する、
    　ことを特徴とする請求項１に記載の決済業務支援方法。
  3. 　前記コンピュータが、
    　前記バイヤーの端末より支払依頼を受信した場合、前記バイヤーに関する集約後支払予定データを記憶装置より読み出し、当該集約後支払予定データが示す、前記バイヤーの利用銀行のシステムに対し、前記集約後支払予定データが示す内容に応じた決済処理の依頼を送信する処理と、
    　前記決済処理の依頼を前記バイヤーの利用銀行のシステムに送信する処理に伴い、前記決済処理の依頼がなされた該当請求書データに関する支払通知を生成して、該当サプライヤーの端末に宛てて送信する処理と、
    　を実行することを特徴とする請求項１に記載の決済業務支援方法。
  4. 　前記バイヤーの端末が、
    　前記支払依頼をコンピュータに送信するに伴い、前記コンピュータより前記集約後支払予定データを取得して出力装置に表示させる処理と、
    　前記集約後支払予定データが示す内容と、サプライヤーから送付されていた紙媒体の請求書が示す内容とをバイヤーが照合して、前記支払依頼の可否について判断した結果を、入力装置で受け付ける処理とを実行し、
    　前記入力装置で受け付けた結果が、前記支払依頼を承認するものであった場合、前記支払依頼の前記コンピュータへの送信を実行し、
    　前記入力装置で受け付けた結果が、前記支払依頼を否認するものであった場合、前記支払依頼の前記コンピュータへの送信を実行せず、当該否認の旨を予め定めた所定の端末に送信する処理を実行する、
    　ことを特徴とする請求項３に記載の決済業務支援方法。
  5. 　前記コンピュータが、
    　前記バイヤーの端末より、前記請求書データに基づいた買掛金の情報を受信し、当該買掛金の情報を記憶装置に格納する処理と、
    　前記決済処理の依頼を前記バイヤーの利用銀行のシステムに送信する処理に伴い、前記決済処理の依頼が含む、請求書データの識別情報と対応する前記買掛金の情報を特定し、該当買掛金の情報に関する消込処理と、
    　を実行することを特徴とする請求項３に記載の決済業務支援方法。
  6. 　前記コンピュータが、
    　前記支払通知の生成ないし前記サプライヤーの端末からの指示に応じて、前記決済処理の依頼ないし前記支払通知が含む、前記サプライヤーへの支払内容の情報により、前記サプライヤーの利用銀行における当該サプライヤーの口座への入金予定の情報を生成し、記憶装置に格納する処理と、
    　前記サプライヤーの端末より、前記請求書データに基づいた売掛金の情報を受信し記憶装置に格納する処理と、
    　前記入金予定の情報と前記売掛金の情報とをマッチングし、前記入金予定の情報が含む、請求書データの識別情報と対応する前記売掛金の情報を特定し、該当売掛金の消込予定の情報を生成する処理と、
    　を実行することを特徴とする請求項３に記載の決済業務支援方法。
  7. 　前記コンピュータが、
    　前記サプライヤーの口座への入金事実について、前記サプライヤーの利用銀行より通知を受信し、当該通知が示す入金内容と、前記売掛金の消込予定の情報とをマッチングし、前記入金内容と対応する前記売掛金の消込予定の情報を特定し、当該特定した売掛金に対する入金額の過不足を判定する処理と、
    　前記判定の結果、入金額の過不足が無かった場合、前記特定した売掛金の消込処理を実行し、
    　前記判定の結果、入金額の過不足があった場合、過不足額の情報を前記サプライヤーの端末および前記バイヤーの端末に送信し、前記特定した売掛金の消込処理を、前記過不足額分について実行する、
    　ことを特徴とする請求項６に記載の決済業務支援方法。
  8. 　前記コンピュータが、
    　１組以上のサプライヤーとバイヤーのそれぞれについて、前記集約後支払予定データを記憶装置から読み出して、サプライヤーとバイヤーとの間の支払金額を相殺し、当該相殺後に残債分の内容のみとなった支払予定データが示す、サプライヤーないしバイヤーの利用銀行のシステムに対し、前記残債分の集約後支払予定データが示す内容に応じた決済処理の依頼を送信する処理を実行する、
    　ことを特徴とする請求項１に記載の決済業務支援方法。
  9. 　電子商取引におけるサプライヤーの端末より、バイヤーに宛てた請求書データを受信して記憶装置に格納し、前記バイヤーの端末からの取得要求に応じて前記請求書データを記憶装置から読み出してバイヤーの端末に送信する処理と、
    　前記バイヤーの端末が、前記請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して生成した、前記サプライヤー宛の支払予定データを受信する処理と、
    　前記受信した支払予定データのうち、予め定めた所定項目ないし前記バイヤー端末から指定を受けた所定項目が共通する支払予定データを特定し、前記特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置に格納する処理とを実行する演算装置を備え、企業間の電子商取引を仲介するコンピュータと、
    　前記バイヤー宛ての請求書データの取得要求を前記コンピュータに送り、前記コンピュータから該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して前記サプライヤー宛の支払予定データを生成し、前記コンピュータに送信する処理を実行する演算装置を備えた、バイヤーの端末と、
    　電子商取引におけるバイヤーに宛てた請求書データを、前記コンピュータに送信する処理を実行する演算装置を備えたサプライヤーの端末と、
    　を備える決済業務支援システム。
PCT/JP2012/073362 2012-09-12 2012-09-12 決済業務支援システムおよび決済業務支援方法 WO2014041642A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
IN1841DEN2015 IN2015DN01841A (ja) 2012-09-12 2012-09-12
SG11201501757SA SG11201501757SA (en) 2012-09-12 2012-09-12 Settlement operations support system and settlement operations support method
PCT/JP2012/073362 WO2014041642A1 (ja) 2012-09-12 2012-09-12 決済業務支援システムおよび決済業務支援方法
US14/427,729 US20160125486A1 (en) 2012-09-12 2012-09-12 Settlement operations support system and settlement operations support method
CN201280075756.1A CN104641390B (zh) 2012-09-12 2012-09-12 结算操作支持系统和结算操作支持方法
JP2014535288A JP5927304B2 (ja) 2012-09-12 2012-09-12 決済業務支援システムおよび決済業務支援方法
TW102124734A TWI522947B (zh) 2012-09-12 2013-07-10 結算業務支援系統及結算業務支援方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/073362 WO2014041642A1 (ja) 2012-09-12 2012-09-12 決済業務支援システムおよび決済業務支援方法

Publications (1)

Publication Number Publication Date
WO2014041642A1 true WO2014041642A1 (ja) 2014-03-20

Family

ID=50277796

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/073362 WO2014041642A1 (ja) 2012-09-12 2012-09-12 決済業務支援システムおよび決済業務支援方法

Country Status (7)

Country Link
US (1) US20160125486A1 (ja)
JP (1) JP5927304B2 (ja)
CN (1) CN104641390B (ja)
IN (1) IN2015DN01841A (ja)
SG (1) SG11201501757SA (ja)
TW (1) TWI522947B (ja)
WO (1) WO2014041642A1 (ja)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6298516B1 (ja) * 2016-11-16 2018-03-20 ＰｗＣあらた有限責任監査法人 データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム
JP6298517B1 (ja) * 2016-11-16 2018-03-20 ＰｗＣあらた有限責任監査法人 データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム
JP2019091129A (ja) * 2017-11-13 2019-06-13 株式会社日立製作所 端末およびブロックチェーンシステム
JP2019207487A (ja) * 2018-05-28 2019-12-05 株式会社オービック 違算確認業務支援装置、違算確認業務支援方法および違算確認業務支援プログラム
US20200098026A1 (en) * 2017-05-08 2020-03-26 Keren HUMMEL ALON Method and system for third party purchases
JP2021064040A (ja) * 2019-10-10 2021-04-22 株式会社マネーフォワード 情報処理装置、情報処理方法及びプログラム
JP2021093220A (ja) * 2021-03-16 2021-06-17 株式会社マネーフォワード 情報処理装置、情報処理方法及びプログラム
JP2022027139A (ja) * 2020-07-31 2022-02-10 株式会社オービック 債権・債務計上部門特定装置、債権・債務計上部門特定方法および債権・債務計上部門特定プログラム
US20220148079A1 (en) * 2019-03-05 2022-05-12 Hitachi, Ltd. Settlement system and settlement method
JP2022101638A (ja) * 2018-05-28 2022-07-06 株式会社オービック 違算確認業務支援装置、違算確認業務支援方法および違算確認業務支援プログラム
JP2023044263A (ja) * 2021-09-17 2023-03-30 株式会社アジェンダ 旅行業務支援システム
JP7470850B1 (ja) 2023-07-31 2024-04-18 株式会社シディ 情報処理方法、情報処理装置および情報処理プログラム

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101754759B1 (ko) * 2015-11-04 2017-07-06 김재영 송수금을 중개하는 메신저 서버
CN106875162B (zh) * 2016-12-30 2020-12-04 朗新科技集团股份有限公司 数据抓取方法、数据抓取装置、软收银对接接口及终端
US20180330412A1 (en) * 2017-05-11 2018-11-15 Amadeus S.A.S. Systems and methods for processing and reconciling an invoice data file
US11276117B2 (en) * 2017-07-31 2022-03-15 Oracle International Corporation Generating payables and receivables netting proposals based on historical information
US20190080302A1 (en) * 2017-09-08 2019-03-14 Mastercard International Incorporated Payment system for facilitating delivery transactions
TWI670664B (zh) * 2018-02-21 2019-09-01 合作金庫商業銀行股份有限公司 採購平台控管系統及方法
CN109345322A (zh) * 2018-08-06 2019-02-15 阿里巴巴集团控股有限公司 资金结算方法、装置、及计算机设备
CN109255604A (zh) * 2018-08-08 2019-01-22 北京京东尚科信息技术有限公司 基于电子商务平台的支付和开票的方法、装置和系统
CN109801150A (zh) * 2018-12-20 2019-05-24 航天信息股份有限公司 一种酒店行业的税控方法及系统
JP6860027B2 (ja) * 2019-03-08 2021-04-14 日本電気株式会社 処理装置、処理方法、決済システム及びプログラム
CN110378760A (zh) * 2019-06-17 2019-10-25 平安银行股份有限公司 数据处理方法及终端设备
CN112150289A (zh) * 2019-06-28 2020-12-29 财付通支付科技有限公司 数据清算方法、装置、系统及存储介质
CN114971528B (zh) * 2022-04-26 2024-06-07 江苏康众汽配有限公司 一种财务应收应付及发票核销方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002023420A1 (fr) * 2000-09-14 2002-03-21 Kabushiki Kaisha Toshiba Systeme de transaction
JP2002312597A (ja) * 2002-02-22 2002-10-25 Mizuho Corporate Bank Ltd 電子取引方法、電子取引センター、電子取引端末、および電子取引システム
JP2004310729A (ja) * 2003-03-25 2004-11-04 Bank Of Tokyo-Mitsubishi Ltd 貿易取引の決済支援装置及びプログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101206739A (zh) * 2006-12-19 2008-06-25 黄金富 用手机作为付款器件的收银机收付款系统和相应方法
CN101436279A (zh) * 2008-12-19 2009-05-20 福建今日特价网络有限公司 一种网上交易支付系统及方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002023420A1 (fr) * 2000-09-14 2002-03-21 Kabushiki Kaisha Toshiba Systeme de transaction
JP2002312597A (ja) * 2002-02-22 2002-10-25 Mizuho Corporate Bank Ltd 電子取引方法、電子取引センター、電子取引端末、および電子取引システム
JP2004310729A (ja) * 2003-03-25 2004-11-04 Bank Of Tokyo-Mitsubishi Ltd 貿易取引の決済支援装置及びプログラム

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6298517B1 (ja) * 2016-11-16 2018-03-20 ＰｗＣあらた有限責任監査法人 データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム
JP2018081501A (ja) * 2016-11-16 2018-05-24 ＰｗＣあらた有限責任監査法人 データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム
WO2018092770A1 (ja) * 2016-11-16 2018-05-24 ＰｗＣあらた有限責任監査法人 データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム
JP2018081502A (ja) * 2016-11-16 2018-05-24 ＰｗＣあらた有限責任監査法人 データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム
JP6298516B1 (ja) * 2016-11-16 2018-03-20 ＰｗＣあらた有限責任監査法人 データ構造、情報処理装置、プログラム、情報処理方法及びトランザクションシステム
US20200098026A1 (en) * 2017-05-08 2020-03-26 Keren HUMMEL ALON Method and system for third party purchases
JP2019091129A (ja) * 2017-11-13 2019-06-13 株式会社日立製作所 端末およびブロックチェーンシステム
JP7064381B2 (ja) 2018-05-28 2022-05-10 株式会社オービック 違算確認業務支援装置、違算確認業務支援方法および違算確認業務支援プログラム
JP2019207487A (ja) * 2018-05-28 2019-12-05 株式会社オービック 違算確認業務支援装置、違算確認業務支援方法および違算確認業務支援プログラム
JP7250979B2 (ja) 2018-05-28 2023-04-03 株式会社オービック 違算確認業務支援装置、違算確認業務支援方法および違算確認業務支援プログラム
JP2022101638A (ja) * 2018-05-28 2022-07-06 株式会社オービック 違算確認業務支援装置、違算確認業務支援方法および違算確認業務支援プログラム
US20220148079A1 (en) * 2019-03-05 2022-05-12 Hitachi, Ltd. Settlement system and settlement method
JP2021064040A (ja) * 2019-10-10 2021-04-22 株式会社マネーフォワード 情報処理装置、情報処理方法及びプログラム
JP2022027139A (ja) * 2020-07-31 2022-02-10 株式会社オービック 債権・債務計上部門特定装置、債権・債務計上部門特定方法および債権・債務計上部門特定プログラム
JP7411517B2 (ja) 2020-07-31 2024-01-11 株式会社オービック 債権・債務計上部門特定装置、債権・債務計上部門特定方法および債権・債務計上部門特定プログラム
JP2021093220A (ja) * 2021-03-16 2021-06-17 株式会社マネーフォワード 情報処理装置、情報処理方法及びプログラム
JP2023044263A (ja) * 2021-09-17 2023-03-30 株式会社アジェンダ 旅行業務支援システム
JP7388663B2 (ja) 2021-09-17 2023-11-29 株式会社アジェンダ 旅行業務支援システム
JP7470850B1 (ja) 2023-07-31 2024-04-18 株式会社シディ 情報処理方法、情報処理装置および情報処理プログラム

Also Published As

Publication number Publication date
JPWO2014041642A1 (ja) 2016-08-12
SG11201501757SA (en) 2015-04-29
CN104641390B (zh) 2017-10-20
CN104641390A (zh) 2015-05-20
IN2015DN01841A (ja) 2015-05-29
TW201423642A (zh) 2014-06-16
TWI522947B (zh) 2016-02-21
JP5927304B2 (ja) 2016-06-01
US20160125486A1 (en) 2016-05-05

Similar Documents

Publication Publication Date Title
JP5927304B2 (ja) 決済業務支援システムおよび決済業務支援方法
US11741513B2 (en) Supply chain finance system
US12100042B2 (en) Supply chain finance system
CA2483348C (en) System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US7437327B2 (en) Method and system for buyer centric dispute resolution in electronic payment system
JP2007507800A (ja) 販売者支援自動支払処理と例外管理のためのシステムおよび方法
US10643275B2 (en) Methods and systems for managing consumer savings with credit card transactions
US20180330351A1 (en) System and method for allocating charges away from a tax account
JP2015524125A (ja) 担保取引サービス方法
JP7092740B2 (ja) トークン発行・流通方法
US8112355B1 (en) Method and system for buyer centric dispute resolution in electronic payment system
JP2019032765A (ja) 補助簿管理装置、補助簿管理方法および補助簿管理プログラム
JP2004318768A (ja) 債務引受を伴うファクタリングシステム
JP2003296648A (ja) 資金移動処理方法、コンピュータプログラム、買手国側金融機関システム、売手国側金融機関システムおよび仲介者システム
JP2016071899A (ja) 決済滞納業務管理システム、決済滞納業務管理システムの制御方法、決済滞納業務管理システムプログラム及び記録媒体
WO2001098957A2 (en) Financial transaction processing method and system
JP4728763B2 (ja) 送金依頼データ作成装置
Coven Moving to e-payments: Best practices for US middle-market companies

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: 12884484

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: IDP00201501338

Country of ref document: ID

ENP Entry into the national phase

Ref document number: 2014535288

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14427729

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 12884484

Country of ref document: EP

Kind code of ref document: A1