Payment processing device, payment processing method, and program

Abstract

To generate data for requesting another system to perform predetermined processing at a predetermined timing in accordance with registered settlement conditions.SOLUTION: A settlement processing apparatus stores billing data and billing statement data indicating results of transactions between a first user and a second user, and contract and settlement information related to the transactions between the first user and the second user. The settlement processing apparatus calculates, on receipt of sales data from a first user terminal, the number of pieces of data and the total amount to be billed, based on the received sales data, and generates and stores billing data and billing statement data on the basis of the contract and settlement information, a result of the calculation, and the sales data. The settlement processing apparatus generates account transfer request data based on the billing statement data approved by the first user and the second user, and generates, in response to receiving a result of account transfer processing, deposit request data corresponding to the account transfer request data.SELECTED DRAWING: Figure 8

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 to 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 a combination of 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 have been used in combination. Patent Document 1 discloses a factoring system that receives invoices created by accounting software from an external vendor, purchases the accounts receivable related to selected invoices, and remits the receivables.

[0004] Traditionally, payments for business-to-business transactions were made by direct debit from the supplier (collection agency service) and bank transfer from the buyer. For direct debit, the necessary data for the direct debit was sent to the collection agency service company, and the money was debited from the buyer's bank account, and then deposited into the supplier's bank account a set number of days later. The transfer was made on the set payment date in accordance with the contract for the business-to-business transaction. [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 no choice but to use multiple systems to handle payment-related tasks. For example, when a supplier issues an invoice, they need to enter transaction data into an accounting system. When billing for that transaction via direct debit, they need to register the data in a specified format in the direct debit acceptance system provided by the financial institution. And when they wanted to quickly convert their accounts receivable into cash, they had to apply to a factoring company. This meant that each company had to register data in the specified format required by each system, and it was extremely inconvenient to format the same data to suit each system and send it to each system.

[0007] Previously, suppliers allowed different payment terms for each buyer, which meant that they had to calculate the invoice amount based on the sales date and the payment due date based on the payment terms for each buyer, and then list these on the invoice. They also had to constantly check, by referring to account statements, whether the payment had been received by the payment due date, which varied for each buyer, making due date management a hassle.

[0008] With traditional direct debit, payments are automatically debited from a buyer's account when the supplier makes a collection request with the buyer's prior consent. In B2B payments, buyers often confirm the amount and details of the supplier's invoice in advance and obtain internal approval before proceeding with payment procedures, so direct debit, where payments are debited from an account at the supplier's direction alone, was difficult for buyers to accept. Suppliers also had to register direct debit requests during a specific period several business days before the debit date, making due date management difficult and difficult to use for suppliers who allow different payment conditions for each customer.

[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] The present invention also aims to provide a payment processing device, a payment processing method, and a program that generate data to request a specified process 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 the supplier and 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 supplier and Buyer User information and supplier and Buyer billing statement data showing the results of transactions between supplier and Buyer It stores contract and settlement information regarding transactions between The control unit The aforementioned supplier Used by supplier When sales data is received from the terminal, the received sales data includes supplier ID and Buyer The user information and the contract and payment information are acquired from the storage unit based on the ID, and the acquired user information is Information on the payment account, approver, and payment route of the supplier and the buyer included in and the contract and payment information Payment date information included in and generating billing statement data whose status indicates "awaiting supplier approval" based on the sales data and storing the data in the storage unit; The invoice detail data whose status indicates that it is waiting for supplier approval is supplier providing the terminal with the supplierIn response to receiving approval from the buyer, updating the status of the invoice detail data to waiting for buyer approval and storing the updated status in the storage unit; The invoice detail data whose status indicates that it is waiting for buyer approval Buyer providing the terminal with the Buyer In response to receiving the approval from the customer, updating the status of the billing statement data to waiting for a request for account transfer and storing the updated status in the storage unit; The billing statement data whose status indicates that an account transfer request is waiting is read, and based on the read billing statement data, Buyer generating account transfer request data from the account of the payment agent to the account of the payment agent, updating the status of the read-out billing statement data to waiting for payment, and storing the updated status in the storage unit; In response to the result of the account transfer process performed based on the account transfer request data, supplier generating a deposit request data for the account, updating the status of the billing statement data associated with the account transfer request data to "deposited" and storing the updated status in the storage unit; Execute. [Effects of the Invention]

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

[0014] According to the present invention, suppliers can reduce the amount of work required to manage invoice amounts and payment 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 of unauthorized withdrawal even in the case of direct debit, and suppliers can also be more efficient as they no longer need to worry about managing the deadline for registering data for collection agency execution. [Brief explanation 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. [Figure 2] 1 is a system configuration diagram of a payment processing device 10. FIG. [Figure 3] FIG. 2 is a diagram showing an example of the data structure of a user master 106. [Figure 4] 10 is a diagram showing an example of the data structure of contract / payment information 107. FIG. [Figure 5] FIG. 2 is a diagram showing an example of the data structure of billing data 108. [Figure 6] FIG. 2 is a diagram showing an example of the data structure of billing detail data 109. [Figure 7] FIG. 10 is a flow diagram illustrating the process from uploading a sales file to providing an electronic invoice. [Figure 8] FIG. 10 is a flow diagram illustrating a fund transfer process between a supplier and a buyer by account transfer. [Figure 9] 1A is a flow diagram illustrating the financing process for the supplier, and FIG. 1B is a flow diagram illustrating the financing process for the buyer. [Figure 10] FIG. 10 is a diagram showing an example of a contract / payment information registration screen 1000. DETAILED DESCRIPTION OF THE INVENTION

[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 according to 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 a single system or device, but the various processes executed by the payment processing device 10 may be configured to be executed in a distributed manner across 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 business-to-business transactions. 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 and 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 business-to-business transactions. The buyer terminal 12 can be a computer such as a personal computer (PC) or a tablet terminal equipped with communication functions and data editing and viewing functions 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 performing specified processing, and may be external systems or subsystems of the financial institution, and provide the functions described below.

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

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

[0025] (Basic data registration processing) 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 the supplier terminal 11.

[0026] The payment processor 10 generates unauthorized 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 data to the supplier terminal 11. In response to the supplier terminal 11 approving the unauthorized billing data, the payment processor 10 provides the unauthorized billing data to the buyer terminal 12. When the buyer confirms the content of the unauthorized billing data and approves it via the buyer terminal 12, the data is treated by the payment processor 10 as approved billing data. Approved billing data includes information such as the supplier and buyer settlement accounts and the payment date based on the contract information between the supplier and buyer. This allows the buyer to confirm the payment amount and payment date in advance before actually making payment. In the following description, approved billing data will simply be referred to as "billing data" or "billing detail data," and unapproved billing data will be referred to as "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 sends the account transfer request data to the account transfer system 14 so that processing will be carried out on the debit date indicated in 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 debit date is set to the same day or the next business day), the account transfer system 14 immediately generates an account transfer message and sends it to the second bank system 18.

[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. Based on the supplier account information in the account transfer request data, 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, and sends it to the first bank system 17. The first bank system 17 then executes the deposit process to 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 financing, 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 estimate request data based on the billing detail data and sends it to the finance system 15. The finance system 15 performs an estimate for early financing based on the contents of the billing detail data and sends the estimate results to the payment processing device 10. The payment processing device 10 provides the estimate results to the supplier terminal 11 on a separate screen interface.

[0032] When the payment processing device 10 receives 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 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. The payment processing device 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 will be 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, no deposit process is performed to the supplier account.

[0033] With regard to payment deferral, which is another form of financing, the payment processing device 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 processing device 10. When the payment processing device 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 estimate request data based on the billing detail data and desired payment date and sends it to the finance system 15. The finance system 15 performs an estimate for payment deferral based on the contents of the billing detail data and information on the desired payment date, and sends the estimate result to the payment processing device 10. The payment processing device 10 provides the estimate result to the buyer terminal 12 on a separate screen interface.

[0034] When the payment processing device 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 processes the deposit into the supplier's account based on the transfer message. This deposit is made on the originally scheduled payment date. The payment processing device 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 processing will be made 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 processing is made to the supplier's account.

[0035] In addition, the transfer source account of the transfer message in the finance processing is the bank account of the business 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 processes 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 via account transfer processing, the payment processing device 10 stores the status of the billing detail data as "deposited" and provides the payment reconciliation result to the supplier terminal. When the buyer makes a transfer without using 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 sends it to the billing processing system 13. The billing processing system 13 obtains payment detail data from each financial institution system, performs the payment reconciliation process, and sends 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 "deposited," 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 the buyer's notification information from the payment processing device 10, and issues an electronic bill based on the received data. The billing processing system 13 provides the electronic bill to the buyer terminal 12 based on the buyer's notification information or in response to a request from the buyer terminal 12.

[0039] After receiving the billing detail data for which the deposit reconciliation process is desired from the payment processing device 10, the billing processing system 13 receives the deposit detail data from each financial institution system, executes the deposit reconciliation process, and provides the deposit reconciliation process results 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 an account transfer process to debit the funds from the buyer's account, and the second bank system 18 transfers the debited funds to a specified account. The received account transfer request data may indicate that the account transfer will be executed 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 on the desired payment date specified when the buyer requested financing (advance payment).

[0041] The finance system 15 performs an estimate based on the billing statement data and guarantee information for which financing is requested, and provides the estimated results for early financing to the payment processing device 10. The finance system 15 performs an estimate based on the billing statement data and guarantee information for which financing is requested, and the desired payment date specified by the buyer, and provides the estimated results for payment deferral to the payment processing device 10. The finance system 15 processes 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 executes the deposit process by sending the transfer message to the financial institution system corresponding to the transfer destination account included in the deposit request data, for example, the first bank system 17 that has the supplier account.

[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 an embodiment of the present invention. As shown in FIG. 2, the payment processing device 10, like a general computer, includes a control unit 101, a main memory unit 102, an auxiliary memory unit 103, an IF unit 104, and an output unit 105, all interconnected by a bus 120 or the like. 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 also includes a user master 106, contract / payment information 107, billing data 108, and billing detail data 109 in the form of a file or database. The payment processing device 10 can read, edit, or update the information stored in the user master 106, contract / payment information 107, billing data 108, and billing detail data 109. The 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 those instructions. The auxiliary storage unit 103 is a storage device such as a hard disk drive (HDD), and is used for long-term storage of data and programs.

[0045] The embodiment in Figure 2 describes an embodiment in which the control unit 101, main memory unit 102, and auxiliary memory unit 103 are provided inside the same computer, but in another embodiment, the payment processing device 10 can be configured to achieve 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 the payment processing device 10, and have the multiple servers share a single auxiliary memory unit 103.

[0046] The IF unit 104 serves as an interface (IF) when sending and receiving data to and from other systems and devices, and also provides an interface for accepting 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 printing means for printing the data.

[0047] The user master 106 stores information about users such as suppliers and buyers who use the payment processing device 10 according to the present invention. Figure 3 is a diagram showing an example of the data structure of the user master 106 according to the embodiment of the present invention. The user master 106 may 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 may also include other data items.

[0048] User ID 301 is an identifier that identifies a user (such as a company) who uses the payment processing device 10 according to 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 user information such as the user's contact information (email address, telephone number, address, etc.), settlement account, approver, and settlement route. The settlement account indicates information about the bank account used for deposit and withdrawal processing. The approver indicates the person at the supplier or buyer who approves the unapproved invoice data, and the approver may be a department within the user. The settlement route indicates the route of approval order when there are multiple approvers, and the approval order may be set by assigning an order to the user department ID. Note that the settlement route may be configured so that it is 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 on various menus can be performed in accordance with the operation authority registered for each user department ID 303. For example, if three departments of a user company are registered, department A can register sales data, approve billing data for all departments, apply for early funding, and view data, while the other departments B and C cannot register sales data, but can approve billing data for their own department only, apply for early funding, and view data.

[0051] Returning to FIG. 2, the contract / payment information 107 stores contract information and payment information related to transactions between suppliers and buyers 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 that indicates a supplier in a business-to-business transaction. Buyer ID 402 is an identifier that indicates 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. Payment terms may include the closing date, sales data registration deadline, and payment date (e.g., the end of the month). Credit status 404 indicates the credit limit (upper limit) and current balance that the supplier has set for the buyer.

[0053] 10 is a diagram showing an example of a contract / payment information registration screen 1000. A supplier can register each piece of 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 suppliers. 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. However, the billing data 108 may include other data items as well.

[0055] Supplier ID 401 is an identifier that indicates the supplier in the billing data. Buyer ID 402 is an identifier that indicates the buyer in the billing data. File ID 501 is an identifier that identifies the sales data file uploaded by the 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 payment date when the payment date has been changed. Payment method 508 indicates the method by which payment from the buyer to the supplier will be made (e.g., direct debit, bank transfer, etc.). Status 509 indicates the status of the unapproved billing data or billing data. This status 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 statement data 109 stores unapproved billing statement data associated with unapproved billing data or billing statement data associated with billing data. FIG. 6 is a diagram showing an example of the data structure of the billing statement data 109 according to an embodiment of the present invention. The billing statement data 109 may include a supplier ID 401, a buyer ID 402, a file ID 501, a payment date 506, an invoice number 601, billing details 602, an invoice amount 603, a scheduled payment date 604, a status 605, a financing flag 606, a guarantee flag 607, a deposit account 608, and a withdrawal account 609, but is not limited to these data items and may also include other data items.

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

[0059] Status 605 indicates the status of the billing statement data. Examples of the status of the billing statement data include awaiting supplier approval, awaiting buyer approval, awaiting account transfer request, awaiting payment, and payment completed. Financing flag 606 is a flag that indicates whether there is a desire to receive funds earlier than the payment term previously agreed upon between the supplier and buyer, or whether the buyer wishes to postpone payment. Guarantee flag 607 indicates whether a bank guarantee or in-house guarantee has been selected. Receiving account 608 indicates a receiving account, for example, a supplier account. Withdrawal account 609 indicates a withdrawing account, for example, a buyer account.

[0060] (Explanation of various flows) 7 to 9, we will explain the various processes executed by the payment processing device 10, namely, the process flow from uploading sales files to providing electronic invoices, transferring funds by account transfer and bank transfer, and financing and guarantee arrangements. As a premise for explaining these process flows, we will assume that users who can become suppliers and buyers have been assigned user IDs by the payment processing device 10, and that various user-related information is registered in the user master 106. We will also assume that contract information and settlement information related 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) Figure 7 is a flow diagram that explains the process from uploading a sales file to providing an electronic invoice. More specifically, the process flow explains how the payment processing device 10 generates unapproved invoice data based on the data in the sales data file uploaded by the supplier, and after receiving approval from one or more approvers at the supplier and buyer, sends the original data for invoice issuance to the invoice processing system 13, which then 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 content of the sales data may be the same or different. The method by which the payment processing device 10 receives sales data is not limited to file upload 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 contained in the received sales data file to obtain information such as the supplier's and buyer's payment accounts, payment date, settler, and payment route, and calculates the number of data items and total invoice amount based on the contents of the sales data file. Based on this information, the payment processor 10 generates summary information for the unapproved invoice data and stores it in the invoice data 108, and generates unapproved invoice detail data and stores it in the invoice detail data 109. The status 509 of the stored unapproved invoice data and the status 605 of the unapproved invoice detail data become "waiting for supplier approval," and the supplier's account is set in the deposit account 608 of each unapproved invoice detail data, and the buyer's account is set in the withdrawal account 609.

[0064] In S703, the payment processing device 10 reads the unapproved billing data and unapproved billing detail data from the billing data 108 and billing detail data 109, and provides them to the supplier terminal 11 via the 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 make changes. 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 early payment is specified.

[0065] The payment processing device 10 may notify the supplier's first approver that the unapproved claim data and unapproved claim detail data have been generated. The supplier's approver 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 approver at the supplier, the payment processing device 10 notifies the next approver that there is unapproved data that they need to confirm. This approval process is repeated as many times as there are approvers at the supplier. Once the approval process by all approvers set by the supplier is complete, 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."

[0066] In addition, if any approver at the supplier finds any deficiency in the data, they can register a rejection notice with a comment, and 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 payment processor 10 reads the unapproved billing data and 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 the buyer approval screen (not shown). The buyer approval screen displays a list of unapproved billing detail data associated with the unapproved billing data "Waiting for Buyer Approval." The buyer approver can register whether to approve or change each data item. The buyer approval screen allows the buyer to confirm the payment amount and payment date in advance, and if the content is approved, the buyer can rest assured that payment will be made by direct debit. The buyer approver can also register a desired payment date if they wish to postpone the scheduled payment date. In the present invention, since billing data represents summary information and billing detail data represents individual details, 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 for a transaction between a supplier and a buyer with payments due at the end of April, 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] Once approval by the supplier is complete, the payment processing device 10 may notify the first authorizer of the buyer that there is data awaiting buyer approval. After receiving the notification, the buyer's authorizer checks the content of the data displayed on the buyer approval screen, and in some cases changes the information on the scheduled payment date, before pressing the approve 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 that needs to be confirmed. This approval process is repeated as many times as there are authorizers for the buyer. Once approval processing by all authorizers set by the buyer is complete, the payment processing device 10 changes the status 509 of the unapproved claim data and the status 605 of the unapproved claim detail data to "Account Transfer". requestThe unapproved invoice data and unapproved invoice detail data that have been approved by the supplier and buyer will be referred to as invoice data and invoice detail data, respectively.

[0069] Furthermore, if any buyer's approver finds any defect in the data (for example, if the scheduled payment date is undesirable), 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 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 determines that the status 509 is “Account Transfer request "Waiting" billing data and status 605 is "Account Transfer request The invoice 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, they simply need to check the billing details on various screens, amend them as necessary, and approve them, and an electronic invoice will be provided to the buyer. After the billing data is approved, the account transfer process will be executed, as explained with reference to Figure 8, or the buyer will carry out 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 even send the electronic invoice, significantly reducing the amount of work that the supplier previously had to do.

[0072] (Processing flow: Fund transfer by account transfer and bank transfer) Figure 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 explains how the payment processor 10 generates account transfer request data based on billing statement data for which the scheduled payment date has arrived, and transmits the account transfer request data to the account transfer system 14 to transfer the 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. In other words, the payment processing device 10 reads data for which the scheduled payment date is the current day of processing.

[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 the supplier's account or the account of the 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 in 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 data on the result 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 the bank that holds the payment agent's account. The bank then performs a deposit process into the payment agent's account.

[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 payment agent's account 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, and the account transfer system 14 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, based on the result data of the account transfer process, the payment processing device 10 updates the status 605 of the billing detail data associated with the account transfer process to "Payment completed", 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 perform 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] (Processing flow: Financing and guarantee arrangements) Financing is an advance payment made by a financial institution, and the types of financing include early cashing 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 processing flow will be explained in which the payment processing device 10 provides the supplier with the results of an estimate in response to receiving a financing request (early funding 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 processor 10 provides the supplier terminal 11 with billing detail data for which no account transfer request data has been generated, i.e., billing detail data for which the status 605 is "waiting for account transfer request," in units of associated sales data files. The supplier selects the billing detail data displayed on the display for which they wish to be funded early and presses the early funding request button (not shown). The payment processor 10 receives the early funding request for the selected billing detail data. The financing flag 606 of the received billing detail data is set to a predetermined value indicating a desire for early funding (e.g., a value indicating a bank guarantee, a value indicating their own guarantee).

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

[0083] In 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 processing device 10 queries the user master 106 to obtain information on the supplier's payment account, generates deposit request data for processing a deposit into the supplier's account, and sends it to the deposit processing system 16. The deposit processing system 16 sends a transfer message to the first bank system 17 based on the deposit request data, and the first bank system 17 processes a deposit 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 processes the guarantee arrangement based on the guarantee application data.

[0086] The above process allows the supplier to cash out receivables earlier than the scheduled payment date. The payment processor 10 performs an account transfer process on the scheduled payment date for the invoice detail data for which early cashing has been performed. 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 indicated in the transfer message.

[0087] Next, referring to Figure 9(b), we will explain the processing flow in which the payment processing device 10 provides the buyer with the results of an estimate in response to receiving a financing request (payment deferral request) from the buyer, generates deposit request data in response to receiving a financing application from the buyer, generates guarantee application data, 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 buyer terminal 12 with the billing statement data for which no account transfer request data has been generated, i.e., the billing statement data for which the status 605 is "waiting for account transfer request," in units of the associated sales data file. The buyer selects the billing statement data displayed on the display for which they wish to postpone payment, enters 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 statement data. The payment postponement request includes information about the entered desired payment date. The finance flag 606 of the received billing statement data is set to a predetermined value indicating a request for payment postponement.

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

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

[0091] At S914, upon receiving the payment postponement request, the payment processor 10 generates deposit request data for processing the deposit on the scheduled payment date originally registered in the billing detail data and sends it to the deposit processing system 16. The deposit processing system 16 sends a transfer message to the first bank system 17 based on the deposit request data, and the first bank system 17 processes the deposit into the supplier account.

[0092] At S915, upon receiving the payment deferral 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 the guarantee arrangement processing 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 statement data for which the payment postponement request has been made, and the specified account of the financial institution that is providing the guarantee arrangement in the deposit account 608. An account transfer process is performed based on the updated billing statement data, and funds (the amount originally set in the billing statement data) are debited from the buyer's account on the desired payment date, and the debited 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 providing the guarantee will make an advance payment to the supplier, allowing the supplier to 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 modifications in configuration and detail can be made without departing from the spirit 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. Financial Systems 16 Deposit Processing System 17 First Banking System 18 Second Banking System 19 First Network 20 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 statement 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 user information of the supplier and the buyer, billing statement data showing the results of the transaction between the supplier and the buyer, and contract and settlement information relating to the transaction between the supplier and the buyer; The control unit When sales data is received from the supplier terminal used by the supplier, the user information and the contract and payment information are obtained from the storage unit based on the supplier ID and buyer ID included in the received sales data, and billing statement data whose status indicates "waiting for supplier approval" is generated based on the information on the payment accounts, approver, and payment route of the supplier and the buyer included in the obtained user information, the payment date information included in the contract and payment information, and the sales data, and the billing statement data is stored in the storage unit; providing the invoice detail data whose status indicates "awaiting supplier approval" to the supplier terminal, and in response to receiving approval from the supplier, updating the status of the invoice detail data to "awaiting buyer approval" and storing the updated status in the storage unit; providing the billing statement data whose status indicates that it is waiting for buyer approval to the buyer terminal, and in response to receiving approval from the buyer, updating the status of the billing statement data to waiting for account transfer request and storing the updated status in the storage unit; reading out the billing statement data whose status indicates that the account transfer request is pending, generating account transfer request data from the buyer's account to the settlement agent's account based on the read out billing statement data, updating the status of the read out billing statement data to waiting for payment, and storing the updated status in the storage unit; In response to the result of the account transfer process performed based on the account transfer request data, generate deposit request data from the account of the settlement agent to the account of the supplier, update the status of the billing statement data associated with the account transfer request data to "deposited" and store the updated status in the storage unit; A payment processor that performs the above.

2. The payment processing device according to claim 1 , wherein the control unit further reads out the billing statement data whose status indicates that payment has been made from the storage unit, and displays the read out billing statement data on the supplier terminal.

3. 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 user information of the supplier and the buyer, billing statement data showing the results of the transaction between the supplier and the buyer, and contract and settlement information relating to the transaction between the supplier and the buyer; The method comprises: When sales data is received from the supplier terminal used by the supplier, the user information and the contract and payment information are obtained from the storage unit based on the supplier ID and buyer ID included in the received sales data, and billing statement data whose status indicates "waiting for supplier approval" is generated based on the information on the payment accounts, approver, and payment route of the supplier and the buyer included in the obtained user information, the payment date information included in the contract and payment information, and the sales data, and the billing statement data is stored in the storage unit; providing the invoice detail data whose status indicates "awaiting supplier approval" to the supplier terminal, and in response to receiving approval from the supplier, updating the status of the invoice detail data to "awaiting buyer approval" and storing the updated status in the storage unit; providing the billing statement data whose status indicates that it is waiting for buyer approval to the buyer terminal, and in response to receiving approval from the buyer, updating the status of the billing statement data to waiting for account transfer request and storing the updated status in the storage unit; reading out the billing statement data whose status indicates that the account transfer request is pending, generating account transfer request data from the buyer's account to the settlement agent's account based on the read out billing statement data, updating the status of the read out billing statement data to waiting for payment, and storing the updated status in the storage unit; In response to the result of the account transfer process performed based on the account transfer request data, generate deposit request data from the account of the settlement agent to the account of the supplier, update the status of the billing statement data associated with the account transfer request data to "deposited" and store the updated status in the storage unit; A method for providing

4. A program for causing a computer to execute the method according to claim 3.

Images