Settlement processing apparatus, settlement processing method, and program

Abstract

To automatically generate data for executing a receiving service through approvals of a supplier and a buyer on unapproved billing data based on sales data registered by the supplier, and generate data for requesting another system to perform receiving service processing.SOLUTION: A settlement processing apparatus executes the steps of: notifying an approver of a second user about the presence of unapproved billing data to be approved by the second user, the unapproved billing data to be associated with transactions between a first user and the second user being stored, in response to receiving a first approval on the unapproved billing data from a first user terminal; storing, in response to receiving a second approval on the unapproved billing data from a second user terminal, the unapproved billing data, as approved billing data, in a storage unit: and generating account transfer request data on the basis of approved billing data with a status indicating a pending account transfer request.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] The present invention relates to a payment processing device, a payment processing method, and a program. [Background technology]

[0002] In the field of business-to-business (BtoB) transactions, financial institutions have supported BtoB transactions by providing one or more of a variety of systems that support various operations such as billing, settlement, financing, guarantees, and procurement, tailored to the needs of each individual company. Each company carried out its own settlement-related operations using various systems provided by financial institutions and external systems provided by other system vendors. Some of these systems required that business partners use the same system.

[0003] There have been cases in the past where multiple systems were used in combination. Patent Document 1 discloses a factoring mechanism that receives invoices created by accounting software from an external vendor, purchases accounts receivable related to selected invoices, and remits them.

[0004] Traditionally, payments for B2B transactions were made by direct debit from the supplier (collection agency service) and bank transfer from the buyer. Direct debit involves sending the necessary data for direct debit to a collection agency service company, debiting the buyer's bank account, and depositing the amount into the supplier's bank account a set number of days later. Transfers were made on the set payment date in accordance with the terms of the B2B contract. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent No. 7033644 Summary of the Invention [Problem to be solved by the invention]

[0006] Previously, companies had to use multiple systems to handle payment-related tasks. For example, when a supplier issues an invoice, the transaction data must be entered into the accounting system, and when the transaction is billed by direct debit, the data must be registered in a specified format in the direct debit acceptance system provided by the financial institution, and when accounts receivable need to be converted into cash quickly, the company must apply to a factoring company. This meant that each company had to register data in a specified format required by each system, and it was very inconvenient to format the same data for each system and send it to each system.

[0007] Previously, suppliers were allowed to have different payment terms for each buyer, so they had to calculate the billing amount based on the sales date and the payment due date according to the payment terms for each buyer, and list these on the invoice. They also had to continually check by account statements, etc. whether payment had been received by the payment due dates, which varied from buyer to buyer, making due date management a hassle.

[0008] In conventional direct debit, the buyer's account is automatically debited when the supplier makes a collection request with the buyer's prior consent. In inter-company settlements, the buyer often checks the amount and content of the supplier's invoice in advance and makes payment procedures after obtaining internal approval, so direct debit, which is debited from the account at the supplier's instruction alone, is difficult for buyers to accept. Suppliers also need to register direct debit requests during a specific period several business days before the debit date, making due date management difficult for suppliers who accept different payment conditions for each sales destination, making it difficult to use.

[0009] The present invention has been made to solve such problems, and aims to provide a payment processing device, a payment processing method, and a program that automatically generates billing data based on sales data registered by suppliers, and generates data to request specified processing from other systems.

[0010] Another object of the present invention is to provide a payment processing device, a payment processing method, and a program that generate data for requesting specified processing from another system at a predetermined timing in accordance with registered payment conditions.

[0011] Another object of the present invention is to provide a payment processing device, a payment processing method, and a program that automatically generates data for executing collection agency by having a supplier and a buyer mutually approve unapproved invoice data based on sales data registered by the supplier, and generates data for requesting collection agency processing to another system. [Means for solving the problem]

[0012] In order to solve the above problems, the present invention provides a payment processing device including a memory unit and a control unit, the storage unit stores unauthorized invoice data associated with a transaction between a first user and a second user; The control unit is In response to receiving a first approval for the unapproved request data from the first user terminal, notifying a decision maker of a second user that there is unapproved request data waiting for approval by the second user; storing the unapproved request data in the storage unit as approved request data in response to receiving a second approval for the unapproved request data from a second user terminal; generating account transfer request data based on the billing data whose status indicates that the account transfer request is waiting; Execute. Effect of the Invention

[0013] According to the present invention, a supplier can apply for various services by simply registering data once and then operating the system.

[0014] According to the present invention, the supplier can reduce the administrative work of managing invoice amounts and payment due dates, and can grasp the collection status without having to compare payment details with invoices, etc.

[0015] According to the present invention, buyers can confirm the payment amount and payment date in advance, eliminating the anxiety that funds will be automatically debited even if the payment is made by direct debit, and suppliers can also be more efficient by not having to worry about managing the deadlines for registering data for collection agency execution. [Brief description of the drawings]

[0016] A more detailed understanding of the embodiments disclosed herein can be had from the following description, taken in conjunction with the accompanying drawings, in which: [Figure 1] 1 is a configuration diagram of an entire system including a payment processing device 10. FIG. [Diagram 2] 1 is a system configuration diagram of a payment processing device 10. FIG. [Diagram 3] 3 shows an example of a data structure of a user master 106. FIG. [Figure 4] 13 is a diagram showing an example of a data structure of contract / payment information 107. FIG. [Diagram 5] FIG. 2 is a diagram showing an example of a data structure of billing data 108. [Figure 6] 13 is a diagram showing an example of a data structure of billing details data 109. FIG. [Figure 7] FIG. 13 is a flow diagram illustrating the process from uploading a sales file to providing an electronic invoice. [Figure 8] FIG. 11 is a flow diagram illustrating a process of transferring funds between a supplier and a buyer by account transfer. [Figure 9] 1A is a flow diagram illustrating the financing process for a supplier, and FIG. 1B is a flow diagram illustrating the financing process for a buyer. [Figure 10] FIG. 10 is a diagram showing an example of a contract / payment information registration screen 1000. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] (Overall composition) Figure 1 is a configuration diagram of the entire system including a payment processing device 10, a supplier terminal 11, a buyer terminal 12, a billing processing system 13, an account transfer system 14, a finance system 15, a deposit processing system 16, a first bank system 17, and a second bank system 18 in an embodiment of the present invention.

[0018] The payment processing device 10 is connected to a supplier terminal 11 and a buyer terminal 12 so that they can communicate with each other via a first network 19 such as the Internet. The payment processing device 10 is connected to a billing processing system 13, an account transfer system 14, a finance system 15, a deposit processing system 16, a first bank system 17, and a second bank system 18 so that they can communicate with each other via a second network 20 such as the Internet or a LAN or WAN.

[0019] In this specification, the payment processing device 10 is described as one system or device, but various processes executed by the payment processing device 10 may be configured to be distributed and executed by multiple systems or devices. For ease of explanation, only one supplier terminal 11 and one buyer terminal 12 are shown in Figure 1, but there may be multiple supplier terminals 11 and one buyer terminal 12.

[0020] The supplier terminal 11 is a terminal used by a supplier in a business-to-business transaction. The supplier terminal 11 can be a computer such as a personal computer (PC) or a tablet terminal equipped with a communication function and a data editing / viewing function using a web browser, but is not limited to a specific apparatus or device.

[0021] The buyer terminal 12 is a terminal used by a buyer in a business-to-business transaction. The buyer terminal 12 can be a computer such as a personal computer (PC) or a tablet terminal equipped with a communication function and a data editing / viewing function using a web browser, but is not limited to a specific apparatus or device.

[0022] The billing processing system 13, the account transfer system 14, the finance system 15, and the deposit processing system 16 are systems for executing specified processes, may be external systems or subsystems of the financial institution, and provide functions as described below.

[0023] The first bank system 17 and the second bank system 18 are bank systems such as accounting systems controlled by financial institutions. The first bank system 17 is a system of a supplier bank, and the second bank system 18 is a system of a buyer bank. When the supplier bank and the buyer bank are the same financial institution, the first bank system 17 and the second bank system 18 are the same system.

[0024] The payment processing device 10 is a device used for processing related to payment in transactions between companies, and provides various functions supporting basic data registration processing, billing processing, payment processing, finance processing, guarantee processing, deposit processing, deposit reconciliation processing, etc., as described in this specification, to the supplier terminal 11 and the buyer terminal 12 via a unified web-based interface. The various functions provided by the payment processing device 10 are described below.

[0025] (Basic data registration process) In this specification, "basic data" refers to user information related to suppliers and buyers, contract information for business-to-business transactions, and information showing the actual state of business-to-business transactions (e.g., sales data). The payment processing device 10 issues IDs to each supplier and buyer, receives information related to the supplier and buyer, and stores it as user information. The payment processing device 10 receives and stores payment-related contract information such as closing date, sales data registration date, and payment date from supplier terminal 11.

[0026] The settlement processing device 10 generates unapproved billing data at a predetermined timing based on the sales data, user information, and contract information received from the supplier terminal 11, and provides the unapproved billing data to the supplier terminal 11. In response to the unapproved billing data being approved by the supplier terminal 11, the settlement processing device 10 provides the unapproved billing data to the buyer terminal 12. When the buyer confirms the content of the unapproved billing data and approves it via the buyer terminal 12, the data is treated as approved billing data by the settlement processing device 10. The approved billing data includes information such as the payment date based on the payment accounts of the supplier and the buyer, and the contract information between the supplier and the buyer. Therefore, the buyer can confirm the payment amount and payment date in advance before actually making the payment. In the following description, approved billing data will be simply called "billing data" or "billing detail data", and unapproved billing data will be called "unapproved billing data" or "unapproved billing detail data".

[0027] (Billing Processing) The payment processing device 10 transmits the billing data, billing detail data, and the buyer's notification information to the billing processing system 13 , and causes the billing processing system 13 to issue an electronic bill to be provided to the buyer terminal 12 .

[0028] (Payment processing) The payment processing device 10 generates account transfer request data based on the amount information in the billing data and billing detail data and the account information of the supplier and buyer. The payment processing device 10 transmits the account transfer request data to the account transfer system 14 so that the processing will be performed on the debit date indicated by the account transfer request data. The account transfer request data includes information such as the debit date, debit account, deposit account, and debit amount, and upon receiving the account transfer request data, the account transfer system 14 immediately generates an account transfer message and transmits it to the second bank system 18 (the debit date is set to the same day or the next business day).

[0029] The second bank system 18 executes the account transfer process, and the funds are transferred to the account of the payment agent that manages the account transfer system 14. The payment processing device 10 generates a transfer message indicating the transfer of funds from the account of the payment agent to the supplier account based on the supplier account information in the account transfer request data, and transmits it to the first bank system 17. The first bank system 17 then executes the deposit process for the supplier account.

[0030] (Finance processing, deposit processing, guarantee processing) Financing is a payment made in advance by a financial institution, and types of financing include early cash for the supplier (creditor) and deferred payment for the buyer (debtor).

[0031] With regard to early cashing, which is a form of financing, the payment processing device 10 provides the supplier terminal 11 with billing data and billing detail data for which the payment date has not yet arrived on a screen interface provided by the payment processing device 10. When the payment processing device 10 receives from the supplier terminal 11 a request for financing for the billing detail data selected by the supplier terminal 11, it generates trial calculation request data based on the billing detail data and transmits it to the finance system 15. The finance system 15 performs trial calculations for early cashing based on the contents of the billing detail data and transmits the trial calculation results to the payment processing device 10. The payment processing device 10 provides the trial calculation results to the supplier terminal 11 on a separate screen interface.

[0032] When the payment processing device 10 receives the early financing application data from the supplier terminal 11 after providing the trial calculation results, it generates deposit request data based on the application data and transmits it to the deposit processing system 16. The deposit processing system 16 generates a transfer message based on the deposit request data and transmits it to the first bank system 17. The first bank system 17 performs a deposit process to the supplier account based on the transfer message. The payment processing device 10 also generates account transfer request data based on the billing detail data associated with the application data, and transmits it to the account transfer system 14 so that the process is performed on the deduction date indicated by the account transfer request data. Thereafter, as described above, the account transfer process is performed on the original scheduled payment date. After the account transfer process, the deposit process to the supplier account is not performed.

[0033] With regard to payment deferral, which is another form of financing, the payment processor 10 provides the buyer terminal 12 with billing data and billing detail data for which the payment date has not yet arrived on a screen interface provided by the payment processor 10. When the payment processor 10 receives from the buyer terminal 12 a request for financing for the billing detail data and desired payment date selected by the buyer terminal 12, it generates trial calculation request data based on the billing detail data and desired payment date and transmits it to the finance system 15. The finance system 15 performs trial calculation for payment deferral based on the contents of the billing detail data and information on the desired payment date, and transmits the trial calculation result to the payment processor 10. The payment processor 10 provides the trial calculation result to the buyer terminal 12 on a separate screen interface.

[0034] When the payment processor 10 receives payment deferral application data from the buyer terminal 12 after providing the trial calculation results, it generates deposit request data based on the application data and sends it to the deposit processing system 16. The deposit processing system 16 generates a transfer message based on the deposit request data and sends it to the first bank system 17. The first bank system 17 performs a deposit process to the supplier account based on the transfer message. This deposit is made on the originally scheduled payment date. The payment processor 10 also generates account transfer request data based on the billing detail data associated with the application data, and sends it to the account transfer system 14 so that the process is performed on the deduction date indicated by the account transfer request data. This deduction date is the desired payment date set by the buyer. After the account transfer process, no deposit process is performed to the supplier account.

[0035] In addition, the source account of the transfer message in the finance processing is the bank account of the business entity that manages the deposit processing system 16, and the deposit account in the account transfer processing is the account of the payment agent.

[0036] Furthermore, when the payment processing device 10 receives the early financing application data or the payment deferral application data, it generates guarantee application data corresponding to each application and transmits it to the finance system 15. The finance system 15 executes processing of the guarantee arrangement for early financing or payment deferral based on the guarantee application data.

[0037] (Payment reconciliation process) The payment processing device 10 can centrally manage payment reconciliation information linked to billing detail data. When payment is made by account transfer processing, the payment processing device 10 stores the status of the billing detail data as "paid" and provides the payment reconciliation result to the supplier terminal. When the buyer makes a transfer without account transfer processing, the payment processing device 10 receives the billing detail data for which payment reconciliation is desired from the supplier terminal 11 and transmits it to the billing processing system 13. The billing processing system 13 acquires the payment detail data from each financial institution system, performs the payment reconciliation process, and transmits the processing result to the payment processing device 10. The payment processing device 10 stores the payment reconciliation process result received from the billing processing system 13 in the status of the billing detail data as "paid" and provides the payment reconciliation result to the supplier terminal.

[0038] (Functionality of external systems or subsystems of financial institutions) The billing processing system 13 receives billing data, billing detail data, and buyer notification information from the payment processing device 10, and issues an electronic invoice based on the received data. The billing processing system 13 provides an electronic invoice to the buyer terminal 12 based on the buyer notification information or in response to a request from the buyer terminal 12.

[0039] The billing processing system 13 receives billing detail data for which a deposit reconciliation process is desired from the payment processing device 10, then receives deposit detail data from each financial institution system, executes the deposit reconciliation process, and provides the results of the deposit reconciliation process to the payment processing device 10.

[0040] Based on the received account transfer request data, the account transfer system 14 requests the second bank system 18 of the financial institution holding the buyer's account to perform account transfer processing to withdraw funds from the buyer's account, and the second bank system 18 transfers the withdrawn funds to a specified account. The received account transfer request data may indicate that the account transfer will be performed on the scheduled payment date included in the contract information, i.e., the day (or the next business day) on which the account transfer request data is received, or the desired payment date specified when the buyer requested financing (advance payment).

[0041] The finance system 15 performs trial calculations based on the billing detail data and guarantee information for which financing is requested, and provides the trial calculation results for early financing to the payment processing device 10. The finance system 15 performs trial calculations based on the billing detail data and guarantee information for which financing is requested, and the desired payment date specified by the buyer, and provides the trial calculation results for payment deferral to the payment processing device 10. The finance system 15 executes processing of the guarantee arrangement based on the guarantee application data.

[0042] The deposit processing system 16 generates a transfer message based on the deposit request data received from the payment processing device 10, and sends the transfer message to a financial institution system corresponding to the transfer destination account included in the deposit request data, for example, a first bank system 17 having a supplier account, to execute the deposit processing.

[0043] (System configuration of payment processing device 10) Next, the system configuration of the payment processing device 10 will be described. FIG. 2 is a system configuration diagram of the payment processing device 10 according to the embodiment of the present invention. As shown in FIG. 2, the payment processing device 10 includes a control unit 101, a main memory unit 102, an auxiliary memory unit 103, an IF unit 104, and an output unit 105, which are interconnected by a bus 120 or the like, like a general computer. The auxiliary memory unit 103 stores programs that implement the functions of the payment processing device 10 and data handled by the programs. The auxiliary memory unit 103 includes a user master 106, contract / payment information 107, billing data 108, and billing detail data 109 in the form of a file / database or the like. The payment processing device 10 can read, edit, or update information stored in the user master 106, contract / payment information 107, billing data 108, and billing detail data 109. Various programs stored in the auxiliary memory unit 103 are executed by the payment processing device 10.

[0044] The control unit 101, also called a central processing unit (CPU), controls each component of the payment processing device 10 and performs data calculations, and also reads out and executes various programs stored in the auxiliary storage unit 103 into the main storage unit 102. The main storage unit 102, also called a main memory, stores various received data, computer-executable instructions, and data after calculation processing based on the instructions. The auxiliary storage unit 103 is a storage device typified by a hard disk drive (HDD) and is used for long-term storage of data and programs.

[0045] The embodiment in Fig. 2 describes an embodiment in which control unit 101, main memory unit 102, and auxiliary memory unit 103 are provided inside the same computer, but in another embodiment, payment processing device 10 can be configured to realize parallel distributed processing by multiple computers by using multiple control units 101, main memory units 102, and auxiliary memory units 103. In another embodiment, it is also possible to install multiple servers for payment processing device 10, and have the multiple servers share one auxiliary memory unit 103.

[0046] The IF unit 104 plays the role of an interface (IF) when transmitting and receiving data to and from other systems and devices, and also provides an interface for receiving various commands and input data (various masters, tables, etc.) from a system operator. The output unit 105 provides a display screen for displaying processed data and a printing means for printing the data.

[0047] The user master 106 stores information on users such as suppliers and buyers who use the payment processing device 10 according to the present invention. Fig. 3 is a diagram showing an example of a data structure of the user master 106 according to the embodiment of the present invention. The user master 106 can include a user ID 301, a user name 302, a user department ID 303, a user department name 304, and user information 305, but is not limited to these data items and can also include other data items.

[0048] User ID 301 is an identifier that identifies a user (such as a company) that uses the payment processing device 10 of the present invention. A user can be a supplier or a buyer in a business-to-business transaction. User name 302 indicates the name of the user (such as a company name). User department ID 303 is an identifier that identifies a department within the user's organization. A user can register organizations that may be parties to a business-to-business transaction or management departments within a company. User department name 304 indicates the name of a department within the user's organization (for example, XX Sales Department, △△ Planning Department, etc.).

[0049] User information 305 indicates various information about the user, such as the user's contact information (email address, telephone number, address, etc.), settlement account, authorizer, and settlement route. The settlement account indicates information about a bank account used for deposit and withdrawal processing. The authorizer indicates the person at the supplier or buyer who approves unapproved invoice data, and the person who approves may be a department within the user. The settlement route indicates the route of the decision order when there are multiple authorizers, and the decision order may be set by assigning an order to the user department ID. The settlement route may be configured to be selected each time on the approval screen without being registered in advance.

[0050] In one embodiment of the present invention, the payment processing device 10 can be configured to provide a user with an authority registration screen (not shown) and control whether or not operations of various menus can be performed according to the operation authority registered for each user department ID 303. For example, three departments of a user company may be registered, and department A may be controlled so that it can register sales data, approve billing data for all departments, apply for early funds, and view data, while the other departments B and C cannot register sales data and can only approve billing data for their own departments, apply for early funds, and view data.

[0051] Returning to FIG. 2, the contract / payment information 107 stores contract information and payment information relating to transactions between a supplier and a buyer in business-to-business transactions. The supplier registers the contract information and payment information via a contract / payment information registration screen 1000 provided by the payment processing device 10. FIG. 4 is a diagram showing an example of the data structure of the contract / payment information 107 according to an embodiment of the present invention. The contract / payment information 107 may include a supplier ID 401, a buyer ID 402, payment terms 403, and a credit status 404, but is not limited to these data items and may also include other data items.

[0052] Supplier ID 401 is an identifier indicating a supplier in a business-to-business transaction. Buyer ID 402 is an identifier indicating a buyer in a business-to-business transaction. The identifiers set as supplier ID 401 and buyer ID 402 may be user ID 301 or user department ID 303. Payment terms 403 indicate payment terms agreed upon in advance between the supplier and buyer. The payment terms may be a closing date, a deadline for registering sales data, and a payment date (e.g., the end of the month). Credit status 404 indicates the credit limit (upper limit) and current balance set by the supplier against the buyer.

[0053] 10 is a diagram showing an example of a contract / payment information registration screen 1000. A supplier can register each data on the contract / payment information registration screen 1000 via the supplier terminal 11.

[0054] Returning to FIG. 2, the billing data 108 stores summary information of sales data uploaded by the supplier. The summary information indicates unapproved billing data or billing data. FIG. 5 is a diagram showing an example of the data structure of the billing data 108 according to an embodiment of the present invention. The billing data 108 may include, but is not limited to, a supplier ID 401, a buyer ID 402, a file ID 501, a file name 502, a creation date 503, a number of data items 504, a total amount 505, a payment date 506, a payment date before change 507, a payment method 508, a status 509, and an approval deadline 510, and may include other data items.

[0055] Supplier ID 401 is an identifier indicating the supplier in the billing data. Buyer ID 402 is an identifier indicating the buyer in the billing data. File ID 501 is an identifier that identifies a sales data file uploaded by a supplier. The sales data file contains one or more unapproved billing detail data. File name 502 is the name given to the uploaded sales data file. Creation date 503 is the creation date of the sales data file. Data count 504 is the number of data items in the detail data included in the sales data file. Total amount 505 indicates the total billing amount of the billing details included in the sales data file.

[0056] Payment date 506 indicates the scheduled date for payment. Pre-change payment date 507 indicates the previous scheduled date for payment when the payment date has been changed. Payment method 508 indicates the method by which payment is made from the buyer to the supplier (e.g., direct debit, bank transfer, etc.). Status 509 indicates the state of the unapproved billing data or billing data. This state indicates, for example, awaiting supplier approval, awaiting buyer approval, awaiting direct debit request, awaiting payment, paid, etc., and is usually synchronized with the status of the corresponding data group in billing detail data 109. Approval deadline 510 indicates the approval deadline for the supplier and buyer for the unapproved billing data.

[0057] Returning to FIG. 2, the billing detail data 109 stores unapproved billing detail data associated with unapproved billing data or billing detail data associated with billing data. FIG. 6 is a diagram showing an example of the data structure of the billing detail data 109 according to an embodiment of the present invention. The billing detail data 109 can include a supplier ID 401, a buyer ID 402, a file ID 501, a payment date 506, a billing number 601, a billing content 602, a billing amount 603, a scheduled payment date 604, a status 605, a finance flag 606, a guarantee flag 607, a deposit account 608, and a withdrawal account 609, but is not limited to these data items and can also include other data items.

[0058] Supplier ID 401 is an identifier indicating the supplier in the billing detail data. Buyer ID 402 is an identifier indicating the buyer in the billing detail data. File ID 501 is an identifier of the sales file associated with each billing detail data. Payment date 506 indicates the payment date of the billing data associated with the billing detail data, and serves as a unit for consolidating one or more detail data between a supplier and a buyer. Billing number 601 is an identifier that identifies the billing detail data. Billing content 602 indicates the content of the bill (e.g., price of goods, price of services). Billing amount 603 indicates the billing amount indicated by the billing detail data. Scheduled payment date 604 indicates the date on which payment is scheduled for each bill.

[0059] Status 605 indicates the state of the billing detail data. The state of the billing detail data indicates, for example, awaiting supplier approval, awaiting buyer approval, awaiting account transfer request, awaiting payment, or payment completed. Financing flag 606 is a flag indicating whether there is a desire to obtain funds earlier than the payment term previously agreed upon between the supplier and the buyer, or whether the buyer wishes to postpone payment. Guarantee flag 607 indicates whether a bank guarantee or a company guarantee has been selected. Receiving account 608 indicates a receiving account, for example, a supplier account. Withdrawal account 609 indicates a withdrawal account, for example, a buyer account.

[0060] (Explanation of various flows) 7 to 9, the various processes executed by the payment processing device 10, namely, the process flows from uploading sales files to providing electronic invoices, transferring funds by account transfer and bank transfer, and financing and guarantee arrangements, will be described. As a premise for explaining these process flows, it is assumed that users who can become suppliers and buyers have been assigned user IDs by the payment processing device 10, and various user-related information is registered in the user master 106. It is assumed that contract information and settlement information relating to transactions between suppliers and buyers in business-to-business transactions is registered in the contract / settlement information 107.

[0061] (Process flow: From uploading sales files to providing electronic invoices) 7 is a flow diagram explaining the process from uploading a sales file to providing an electronic invoice. More specifically, the process flow is explained in which the payment processing device 10 generates unapproved invoice data based on the data in the sales data file uploaded by the supplier, and after approval by one or more approvers at the supplier and the buyer, transmits the original data for invoice issuance to the invoice processing system 13, and the invoice processing system 13 generates an electronic invoice and provides it to the buyer.

[0062] In S701, the payment processing device 10 receives a sales data file indicating the results of a transaction between the supplier and the buyer from the supplier terminal 11. The sales data file is generated based on a predetermined format, and the payment processing device 10 receives the sales data file, for example, via an arbitrary upload screen (not shown). The sales data file is uploaded after the closing date agreed upon between the supplier and the buyer and before the sales data registration deadline. In an embodiment of the present invention, the department that uploads the sales data file and the department that approves the contents of the sales data may be the same or different. The method by which the payment processing device 10 receives the sales data is not limited to file uploading and may be executed by any method, and is not particularly limited.

[0063] In S702, when the payment processor 10 receives the sales data file, it queries the user master 106 and contract / payment information 107 based on the supplier ID and buyer ID included in the received sales data file to obtain information such as the supplier's and buyer's payment accounts, payment date, settler, and settlement route, and calculates the number of data items and total billing amount based on the contents of the sales data file. Based on this information, the payment processor 10 generates summary information of the unapproved billing data and stores it in the billing data 108, and generates unapproved billing detail data and stores it in the billing detail data 109. The status 509 of the stored unapproved billing data and the status 605 of the unapproved billing detail data become "waiting for supplier approval", and the supplier's account is set in the deposit account 608 and the buyer's account is set in the withdrawal account 609 of each unapproved billing detail data.

[0064] In S703, the payment processing device 10 reads out the unapproved billing data and the unapproved billing detail data from the billing data 108 and the billing detail data 109, and provides them to the supplier terminal 11 via a supplier approval screen (not shown). The supplier approval screen displays a list of unapproved billing detail data associated with any unapproved billing data, and the supplier approver can register whether to approve each piece of data as is or to change it. The supplier approver can perform various operations, such as entering comments when making corrections, specifying if early payment is desired, and specifying whether to provide a bank guarantee or a company guarantee when specifying early payment.

[0065] The payment processing device 10 may notify the first authorizer of the supplier that the unapproved claim data and unapproved claim detail data have been generated. The supplier's authorizer checks whether there are any errors in the data displayed on the supplier approval screen and presses the approval button on the screen via the supplier terminal 11. If there is a next authorizer at the supplier, the payment processing device 10 notifies the next authorizer that there is unapproved data that needs to be confirmed. This approval process is repeated for the number of authorizers at the supplier. When approval processes by all authorizers set by the supplier are completed, the payment processing device 10 updates the status 509 of the unapproved claim data and the status 605 of the unapproved claim detail data to "waiting for buyer approval", respectively.

[0066] In addition, if any approver at the supplier finds any error in the data, they can register a rejection notice with a comment. In such a case, the payment processing device 10 can send a rejection notice with a comment to the department that uploaded the sales data file, urging them to correct the data.

[0067] In S704, the settlement processing device 10 reads out the unapproved billing data and the unapproved billing detail data whose statuses 509 and 605 indicate "waiting for buyer approval" from the billing data 108 and the billing detail data 109, respectively, and provides them to the buyer terminal 12 via a buyer approval screen (not shown). The buyer approval screen displays a list of the unapproved billing detail data associated with the unapproved billing data "waiting for buyer approval", and the buyer approver can register whether to approve or change each piece of data. Thanks to the buyer approval screen, the buyer can check the payment amount and payment date in advance, and can feel at ease even if the payment is made by direct debit if the content is approved. If the buyer approver wishes to postpone the scheduled payment date, he or she can also register a desired payment date. In the present invention, the billing data indicates summary information and the billing detail data indicates individual details, so that if the scheduled payment date of any billing detail data is changed, the billing data as summary information is updated and new billing data is generated. For example, if there are three records of payments due at the end of April for a transaction between a supplier and a buyer, and the payment date for one of these is postponed to May, one invoice record for payment in May will be added and the information for the existing invoice record for payment in April will be updated.

[0068] When the approval by the supplier is completed, the payment processing device 10 may notify the first authorizer of the buyer that there is data waiting for the buyer's approval. After receiving the notification, the buyer's authorizer checks the contents of the data displayed on the buyer approval screen, and in some cases changes the information of the scheduled payment date and presses the approval button on the screen via the buyer terminal 12. If there is a next authorizer for the buyer, the payment processing device 10 notifies the next authorizer that there is unapproved data to be confirmed. This approval process is repeated for the number of authorizers for the buyer. When the approval process by all the authorizers set by the buyer is completed, the payment processing device 10 updates the status 509 of the unapproved billing data and the status 605 of the unapproved billing detail data to "waiting for account transfer request". The unapproved billing data and the unapproved billing detail data approved by the supplier and the buyer are referred to as billing data and billing detail data, respectively.

[0069] Furthermore, if any of the buyer's approvers finds any defect in the data (for example, if the scheduled payment date is undesirable), they can register a rejection notice with comments. In such a case, the payment processing device 10 can send a rejection notice with comments to the department that registered the defective data or the department that originally approved it, urging them to correct the data.

[0070] In S705, the payment processing device 10 reads out the billing data whose status 509 is "waiting for direct debit request" and the billing detail data whose status 605 is "waiting for direct debit request", generates invoice data for each set of supplier ID 401, buyer ID 402, and payment date 506, and sends it to the billing processing system 13. The billing processing system 13 generates an electronic invoice based on the received invoice data, and provides the generated electronic invoice to the buyer terminal 12.

[0071] As described above, after the supplier uploads the sales data file, the supplier simply checks the billing details on various screens, amends them as necessary, and approves them, after which an electronic invoice is provided to the buyer. After the billing data is approved, the account transfer process described with reference to Figure 8 is executed, or the buyer performs the transfer process in accordance with the contract. The payment processing device 10 can communicate with the supplier terminal 11 and the buyer terminal 12 via a unified web-based interface and can even send the electronic invoice, significantly reducing the amount of work that the supplier previously had to do.

[0072] (Process flow: Funds transfer by account transfer and bank transfer) 8 is a flow diagram explaining the process of transferring funds between a supplier and a buyer by account transfer. More specifically, the process flow will be explained in which the payment processor 10 generates account transfer request data based on billing detail data for which the payment due date is approaching, and transmits the account transfer request data to the account transfer system 14 to transfer funds.

[0073] In S801, the payment processing device 10 reads billing detail data for which the scheduled payment date has arrived and for which status 605 indicates “waiting for account transfer request” from the billing detail data 109. That is, the payment processing device 10 reads data for which the scheduled payment date is the processing day.

[0074] In S802, the payment processor 10 generates account transfer request data based on the information on the scheduled payment date 604, the billing amount 603, the deposit account 608, and the withdrawal account 609 contained in the read billing detail data, and updates the statuses 509, 605 of the read billing detail data and the billing data associated with the billing detail data to "waiting for payment", respectively. The deposit account for the account transfer request data may be a supplier account or an account of a payment agent that manages the account transfer system 14.

[0075] The payment processing device 10 transmits the account transfer request data to the account transfer system 14. The account transfer system 14 generates an account transfer request message based on a predetermined format based on the account transfer request data, and transmits the account transfer request message to a second bank system 18 of the financial institution corresponding to the buyer account included in the account transfer request data. The second bank system 18 transmits result data of the account transfer process to the payment processing device 10 via the account transfer system 14. The second bank system 18 also withdraws funds from the buyer account and transfers them to a bank that holds the account of the payment agent. The bank performs a deposit process into the account of the payment agent.

[0076] In S803, in response to receiving the result data of the account transfer process from the second bank system 18, the payment processing device 10 generates deposit request data corresponding to the account transfer request data. The deposit request data may be deposit request data with the account of the payment agent as the withdrawal account and the supplier account as the deposit account. The payment processing device 10 transmits the deposit request data to the account transfer system 14, which generates a transfer message based on the deposit request data and transmits it to the first bank system 17. The first bank system 17 executes the deposit process to the supplier account based on the transfer message.

[0077] In S804, the payment processing device 10 updates the status 605 of the billing detail data associated with the account transfer processing to “Payment completed” based on the result data of the account transfer processing, and updates the status 509 of the billing data associated with the billing detail data to “Payment completed”.

[0078] These processes enable suppliers to significantly reduce the administrative work of managing invoice amounts and payment due dates. In addition, the update process in S804 displays the status of the invoice data and invoice detail data as "paid", making it easier than ever to carry out the administrative work of clearing payments for each invoice. Because the supplier terminal 11 can obtain invoice data and invoice detail data with a status of "paid", suppliers can easily check the clearing of payments.

[0079] (Process flow: Financing and guarantee arrangements) Financing is a payment made on behalf of a financial institution, and the types of financing include early financing for the supplier (creditor) and deferred payment for the buyer (debtor). Figure 9(a) is a flow diagram explaining the financing process for the supplier, and Figure 9(b) is a flow diagram explaining the financing process for the buyer.

[0080] Referring to Figure 9(a), the process flow will be described in which the payment processing device 10 provides the supplier with the results of a trial calculation in response to receiving a financing request (early financing request) from the supplier, and generates deposit request data and guarantee application data in response to receiving a financing application from the supplier.

[0081] At S901, in response to a request from the supplier terminal 11, the payment processing device 10 provides billing detail data for which account transfer request data has not been generated, i.e., billing detail data with a status 605 of "waiting for account transfer request", to the supplier terminal 11 in units of associated sales data files. The supplier selects data for which early financing is desired from the billing detail data displayed on the display, and presses an early financing request button (not shown). The payment processing device 10 receives a request for early financing for the selected billing detail data. A predetermined value indicating a desire for early financing (e.g., a value indicating a bank guarantee, a value indicating a company guarantee) is set in the financing flag 606 of the received billing detail data.

[0082] At S902, the payment processing device 10 transmits a request for trial calculation for early financing based on the contents of the billing detail data requested for early financing and the guarantee information (e.g., a predetermined value) to the finance system 15. The finance system 15 performs trial calculation based on the contents of the billing detail data and the guarantee information received, and transmits the trial calculation result to the payment processing device 10. The finance system 15 may indicate that the trial calculation result changes depending on the number of days until the scheduled payment date.

[0083] At S903, in response to receiving the trial calculation results from the finance system 15, the payment processing device 10 provides the trial calculation results to the supplier terminal 11. If the trial calculation results are acceptable, the supplier registers an early financing application via the supplier terminal 11. The payment processing device 10 receives the early financing application based on the trial calculation results from the supplier terminal 11.

[0084] In S904, upon receiving the early financing application, the payment processor 10 queries the user master 106 to obtain information on the supplier's payment account, generates deposit request data for processing the deposit into the supplier's account, and transmits it to the deposit processing system 16. The deposit processing system 16 transmits a transfer message to the first bank system 17 based on the deposit request data, and the first bank system 17 performs the deposit processing into the supplier's account.

[0085] In S905, upon receiving the early financing application, the payment processing device 10 generates guarantee application data for receiving a guarantee from the bank, and transmits the generated guarantee application data to the finance system 15. The finance system 15 executes processing of the guarantee arrangement based on the guarantee application data.

[0086] The above process allows the supplier to monetize the receivable earlier than the scheduled payment date. The payment processing device 10 performs an account transfer process on the scheduled payment date for the billing detail data that has been monetized earlier. As a result of the account transfer, the funds debited from the buyer's account are deposited into the account of the payment agent, and then deposited into the withdrawal account of the transfer message.

[0087] Next, with reference to Figure 9 (b), a process flow will be described in which the payment processing device 10 provides the buyer with the results of a trial calculation in response to receiving a financing request (a request to postpone payment) from the buyer, and generates deposit request data and guarantee application data in response to receiving a financing application from the buyer, and changes the scheduled payment date for the selected billing details.

[0088] At S911, in response to a request from the buyer terminal 12, the payment processor 10 provides the billing detail data for which no account transfer request data has been generated, i.e., the billing detail data for which the status 605 is "waiting for account transfer request", to the buyer terminal 12 in units of the associated sales data files. The buyer selects the data for which he wishes to postpone payment from the billing detail data displayed on the display, inputs the desired payment date, and presses the payment postponement request button (not shown). The payment processor 10 receives a request to postpone payment for the selected billing detail data. The payment postponement request includes information on the input desired payment date. A predetermined value indicating a desire to postpone payment is set in the finance flag 606 of the received billing detail data.

[0089] At S912, the payment processing device 10 transmits to the finance system 15 a trial calculation request for postponing the scheduled payment date to the desired payment date for the contents of the billing detail data for which payment postponement has been requested. The finance system 15 performs a trial calculation based on the received contents of the billing detail data and the desired payment date, and transmits the result of the trial calculation to the payment processing device 10.

[0090] At S913, in response to receiving the trial calculation result from finance system 15, payment processing device 10 provides the trial calculation result to buyer terminal 12. If the trial calculation result is acceptable, the buyer registers a payment deferral application via buyer terminal 12. Payment processing device 10 receives the payment deferral application based on the trial calculation result from buyer terminal 12.

[0091] In S914, when the payment processor 10 receives the payment postponement application, it generates deposit request data for performing the deposit process on the scheduled payment date originally registered in the billing detail data, and transmits it to the deposit processing system 16. The deposit processing system 16 transmits a transfer message to the first bank system 17 based on the deposit request data, and the first bank system 17 performs the deposit process to the supplier account.

[0092] In S915, upon receiving the application for payment deferral, the payment processing device 10 generates guarantee application data for receiving a guarantee from the bank, and transmits the generated guarantee application data to the finance system 15. The finance system 15 executes processing of the guarantee arrangement based on the guarantee application data.

[0093] In S916, the payment processor 10 performs an update process by setting the desired payment date in the scheduled payment date 604 of the billing detail data for which the payment postponement application was made, and the specified account of the financial institution that is making the guarantee arrangement in the deposit account 608. An account transfer process is performed based on the updated billing detail data, and funds (the amount originally set in the billing detail data) are withdrawn from the buyer account on the desired payment date, and the withdrawn funds are deposited into the account of the business that manages the deposit processing system 16 via the payment agent account.

[0094] Through the above process, the financial institution that is providing the guarantee will make an advance payment to the supplier, so the supplier can receive the funds on the original scheduled payment date, while the buyer can postpone the original scheduled payment date to a desired payment date. The guarantee fee will be charged separately.

[0095] Although the principles of the present invention have been described above with reference to exemplary embodiments, it will be understood by those skilled in the art that various embodiments that change in configuration and details can be realized without departing from the gist of the present invention. That is, the present invention can be embodied as, for example, a system, an apparatus, a method, a program, or a storage medium. [Explanation of symbols]

[0096] 10 Payment processing device 11 Supplier terminal 12 Buyer terminal 13. Billing Processing System 14 Direct Debit System 15. Finance System 16 Deposit Processing System 17 The First Banking System 18 The Second Banking System 19 The First Network 20 The Second Network 101 Control section 102 Main memory 103 Auxiliary storage 104 Interface (IF) section 105 Output section 106 User Master 107 Contract / Payment Information 108 Billing Data 109 Billing details data 1000 Contract / Payment Information Registration Screen

Claims

1. A payment processing device including a storage unit and a control unit, the storage unit stores unauthorized invoice data associated with a transaction between a first user and a second user; The control unit is In response to receiving a first approval for the unapproved request data from the first user terminal, notifying a decision maker of a second user that there is unapproved request data waiting for approval by the second user; storing the unapproved request data in the storage unit as approved request data in response to receiving a second approval for the unapproved request data from a second user terminal; generating account transfer request data based on the billing data whose status indicates that the account transfer request is waiting; A payment processor that executes the above.

2. notifying a decision maker of the second user that there is unapproved request data waiting for second user approval and receiving a second approval for the unapproved request data from a second user terminal; sending a first notification to a first authorizer among the authorizers of the second user; in response to receiving, from the second user terminal, an approval in response to the first notification, a second notification to a second authorizer among the authorizers of the second user; receiving from the second user terminal the second acknowledgment made in response to the second notification; The payment processing device of claim 1 .

3. The payment processing device according to claim 2 , wherein an order of approval of the first authorizer and the second authorizer is stored in advance in the storage unit.

4. The payment processing device of claim 1 , wherein a status of the unapproved request data for which the first approval has been given indicates awaiting second user approval.

5. 1. A method performed by a payment processor, comprising: The payment processing device includes a storage unit and a control unit, the storage unit stores unauthorized invoice data associated with a transaction between a first user and a second user; The method comprises: In response to receiving a first approval for the unapproved request data from the first user terminal, notifying a decision maker of a second user that there is unapproved request data waiting for approval by the second user; storing the unapproved request data in the storage unit as approved request data in response to receiving a second approval for the unapproved request data from a second user terminal; generating account transfer request data based on the billing data whose status indicates that the account transfer request is waiting; A method for providing the above.

6. A program for causing a computer to execute the method according to claim 5.

Images