Information processing device, information processing system, information processing method and program

Abstract

To specify a statement to be settled.SOLUTION: An information processing apparatus which can communicate with an information processing terminal used by a user over a network, includes: a receiving unit which receives, from the information processing terminal, a payment request with a statement to be settled which is specified from invoice information issued to the user; and a storage control unit which stores, in a storage unit, payment information that associates the statement with identification information identifying the payment request.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present invention relates to an information processing device. , love The present invention relates to an information processing system, an information processing method, and a program. [Background technology]

[0002] Conventionally, in the clearing process in commercial transactions, the seller clears the accounts receivable related to the invoice by checking the information such as the amount of the deposit and the date of the deposit contained in the deposit information sent from the purchaser with the information such as the amount of the invoice and the payment due date. In this case, the seller checks whether the accounts receivable has been collected according to the invoice, whether there is a delay in collection, etc. (See Patent Document 1). Summary of the Invention [Problem to be solved by the invention]

[0003] However, there is a problem in that it is difficult to identify the itemized payment from the payment information. For example, if the buyer remits the amount related to some of the items included in the invoice, the amount claimed and the amount received may not match. In this case, the seller and buyer must confirm the itemized payment, which is a burden for both parties.

[0004] In view of the above technical problems, one embodiment of the present invention is to make it possible to identify the details to be paid. [Means for solving the problem]

[0005] In order to solve the above problems, an information processing device that is one embodiment of the present invention is an information processing device that can communicate with an information processing terminal used by a user via a network, and is equipped with a receiving unit that receives from the information processing terminal a payment request that identifies the details to be paid from the invoice information issued to the user, and a memory control unit that stores payment information in a memory unit that associates identification information that identifies the payment request with the details. [Effects of the Invention]

[0006] According to one embodiment of the present invention, it is possible to identify the details to be paid. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 2 is a conceptual diagram illustrating the relationships between companies in one embodiment. [Figure 2] 1 is a diagram illustrating an example of an overall configuration of an information processing system according to an embodiment. [Figure 3] FIG. 1 illustrates an example of a hardware configuration of an information processing apparatus according to an embodiment. [Figure 4] FIG. 1 illustrates an example of a functional configuration of an information processing system according to an embodiment. [Figure 5] FIG. 4 is a diagram showing an example of an invoice creation and sending process in the first embodiment. [Figure 6] FIG. 2 is a diagram illustrating an example of a tenant information management table according to the first embodiment. [Figure 7] FIG. 2 is a diagram showing an example of an accounts receivable information management table in the first embodiment. [Figure 8] FIG. 10 is a diagram showing an example of an invoice creation screen in the first embodiment. [Figure 9] FIG. 2 is a diagram showing an example of an invoice image in the first embodiment. [Figure 10] FIG. 3 is a diagram showing an example of an issued invoice information management table in the first embodiment. [Figure 11] FIG. 2 is a diagram showing an example of an accounts receivable information management table in the first embodiment. [Figure 12] FIG. 10 is a diagram showing an example of an invoice delivery screen in the first embodiment. [Figure 13] FIG. 4 is a diagram showing an example of a receipt information management table in the first embodiment. [Figure 14] FIG. 10 is a diagram showing an example of an invoice receiving process in the first embodiment. [Figure 15] FIG. 10 is a diagram showing an example of an invoice receipt screen in the first embodiment. [Figure 16] FIG. 2 is a diagram showing an example of a received invoice information management table in the first embodiment. [Figure 17] FIG. 4 is a diagram showing an example of remittance data creation processing in the first embodiment. [Figure 18] FIG. 10 is a diagram showing an example of a received invoice list screen in the first embodiment. [Figure 19] FIG. 2 is a diagram showing an example of an accounts payable information management table in the first embodiment. [Figure 20] FIG. 10 is a diagram showing an example of a payment processing screen in the first embodiment. [Figure 21] FIG. 10 is a diagram showing an example of a payment processing screen in Modification 1. [Figure 22] FIG. 10 is a diagram showing an example of an accounts payable information management table in Modification 1. [Figure 23] FIG. 11 is a diagram showing an example of a payment processing screen in Modification 2. [Figure 24] FIG. 11 is a diagram showing an example of a chat history management table in Modification 2. [Figure 25] FIG. 4 is a diagram showing an example of a payment information management table in the first embodiment. [Figure 26] FIG. 2 is a diagram showing an example of an accounts payable information management table in the first embodiment. [Figure 27] FIG. 10 is a diagram showing an example of deposit information acquisition and automatic clearing processing in the first embodiment. [Figure 28] FIG. 3 is a diagram showing an example of a deposit information management table in the first embodiment. [Figure 29] FIG. 10 is a diagram illustrating an example of an automatic clearing process in the first embodiment. [Figure 30] FIG. 2 is a diagram showing an example of an accounts receivable information management table in the first embodiment. [Figure 31] FIG. 2 is a diagram showing an example of an accounts payable information management table in the first embodiment. [Figure 32] FIG. 10 is a diagram showing an example of a deposit management screen creation process in the first embodiment. [Figure 33]FIG. 10 is a diagram showing an example of a deposit management screen in the first embodiment. [Figure 34] FIG. 10 is a diagram showing an example of a deposit management screen in the first embodiment. [Figure 35] FIG. 13 is a diagram showing an example of a deposit management screen in Modification 3. [Figure 36] FIG. 11 is a diagram showing an example of an accounts receivable information management table in the second embodiment. [Figure 37] FIG. 11 is a diagram showing an example of an invoice creation screen in the second embodiment. [Figure 38] FIG. 10 is a diagram showing an example of an invoice image in the second embodiment. [Figure 39] FIG. 11 is a diagram showing an example of an issued invoice information management table in the second embodiment. [Figure 40] FIG. 11 is a diagram showing an example of a received invoice information management table in the second embodiment. [Figure 41] FIG. 11 is a diagram illustrating an example of an accounts payable information management table in the second embodiment. [Figure 42] FIG. 11 is a diagram showing an example of a payment processing screen in the second embodiment. [Figure 43] FIG. 11 is a diagram illustrating an example of a payment information management table in the second embodiment. [Figure 44] FIG. 11 is a diagram showing an example of a deposit management screen in the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the drawings, components having the same functions are designated by the same reference numerals, and duplicated explanations will be omitted.

[0009] [First embodiment] [Inter-company relationships] The relationships between the companies in this embodiment will be described with reference to Fig. 1. Fig. 1 is a conceptual diagram showing the relationships between the companies in this embodiment.

[0010] As shown in Figure 1, service user company A is a company that provides goods or services to its business partner, service user company B, in exchange for receiving payment from service user company B. In this case, service user company A, the seller, is the creditor, and service user company B, the purchaser, is the debtor.

[0011] Service provider company C is a company that provides a service of creating an invoice (generating invoice information) on behalf of service user company A at the request of service user company A to be sent to service user company B. In this embodiment, an entity that uses a service provided by a service provider company may be referred to as a tenant. In other words, in this embodiment, a tenant is a business, organization, individual, etc.

[0012] Financial institution D1 is a financial institution that manages the bank account of service user company B. Financial institution D2 is a financial institution that manages the bank account of service user company A. Note that financial institutions are not limited to financial institutions, and may also be collection agents or the like that manage accounts through account transfer services.

[0013] Here, an outline of the processing in this embodiment will be explained. Note that each ID described below is an example of identification information.

[0014] First, service using company A requests service providing company C to create and send an invoice (generate invoice information) to be issued to service using company B (step S1). As a result, service using company B receives the invoice from service using company A via service providing company C (step S2).

[0015] Service using company B sends a payment request specifying the details to be paid to service providing company C (step S3-1). In response, service providing company C creates remittance data including a payment ID that identifies the payment request and sends it to service using company B (step S3-2). This remittance data is data used to transfer money based on an invoice from the bank account of the purchaser (service using company B) to the bank account of the seller (service using company A). In other words, service providing company C creates remittance data that service using company B will use when transferring money, and also performs a process to include the payment ID in the remittance data when creating it.

[0016] Next, service user company B sends remittance data including the payment ID to financial institution D1 (step S4-1). As a result, financial institution D1 remits the amount according to the remittance data to financial institution D2, which manages service user company A's bank account (step S4-2). At this time, financial institution D1 sends the payment ID along with the remittance data to financial institution D2.

[0017] Next, after financial institution D2 confirms the deposit into the bank account of service using company A, it sends deposit information (information on deposit source, deposit amount, deposit date, etc.) including the deposit details and payment ID to service providing company C. In this way, service providing company C obtains the deposit information (step S5).

[0018] Next, service provider C identifies the details of the invoice to be paid based on the payment ID included in the deposit information and performs a settlement process for those details (step S6). Even if a remittance is made based on only part of the details included in the invoice, the details to be paid can be identified using the payment ID, and it is possible to confirm whether the invoice amount and the deposit amount for that detail match. Therefore, even if payment is made on an item-by-item basis included in the invoice, settlement can be performed automatically.

[0019] [Overall configuration of information processing system] The overall configuration of the information processing system according to this embodiment will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the overall configuration of the information processing system according to this embodiment.

[0020] As shown in Figure 2, the information processing system 1 in this embodiment includes a transaction management server 10, a seller terminal 20, a purchaser terminal 30, and two account management servers 40. The transaction management server 10, the seller terminal 20, the purchaser terminal 30, and the account management server 40 are each connected to a communication network N1.

[0021] The communication network N1 is configured so that the devices connected thereto can communicate with each other. The communication network N1 is constructed by a wired communication network such as the Internet, a LAN (Local Area Network), or a WAN (Wide Area Network).

[0022] The communication network N1 may include not only wired communication, but also wireless communication networks such as wireless LAN or short-range wireless communication, or mobile communication networks such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution), or 5G (5th Generation).

[0023] The seller terminal 20 is installed at service using company A (seller). The purchaser terminal 30 is installed at service using company B (purchaser). The transaction management server 10 is installed at service providing company C. The purchaser's account management server 40-1 is installed at financial institution D1. The seller's account management server 40-2 is installed at financial institution D2.

[0024] The seller terminal 20 and the purchaser terminal 30 may be, for example, an output device such as a PJ (Projector), an IWB (Interactive White Board: an electronic white board with a blackboard function that allows mutual communication), digital signage, a HUD (Head Up Display) device, industrial machinery, an imaging device, a sound collection device, medical equipment, network home appliances, automobiles (Connected Cars), notebook PCs (Personal Computers), mobile phones, smartphones, tablet terminals, game consoles, PDAs (Personal Digital Assistants), digital cameras, wearable PCs or desktop PCs.

[0025] [Hardware configuration of information processing system] The hardware configuration of the information processing system in this embodiment will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of the hardware configuration when the transaction management server 10, seller terminal 20, purchaser terminal 30, and account management server 40 are realized by a computer.

[0026] As shown in FIG. 3, the computer in this embodiment includes a CPU (Central Processing Unit) 501, a ROM (Read Only Memory) 502, a RAM (Random Access Memory) 503, a HD (Hard Disk) 504, an HDD (Hard Disk Drive) controller 505, a display 506, an external device connection I / F (Interface) 508, a network I / F 509, a bus line 510, a keyboard 511, a pointing device 512, a DVD-RW (Digital Versatile Disk Rewritable) drive 514, and a media I / F 516.

[0027] Of these, the CPU 501 controls the operation of the entire computer. The ROM 502 stores programs used to drive the CPU 501, such as the IPL. The RAM 503 is used as a work area for the CPU 501. The HD 504 stores various data such as programs. The HDD controller 505 controls the reading and writing of various data from and to the HD 504 under the control of the CPU 501.

[0028] The display 506 displays various types of information such as a cursor, menus, windows, characters, or images. The external device connection I / F 508 is an interface for connecting various types of external devices. In this case, the external devices are, for example, USB (Universal Serial Bus) memories, printers, etc. The network I / F 509 is an interface for data communication using the communication network N1. The bus line 510 is an address bus, data bus, etc. for electrically connecting the components such as the CPU 501 shown in FIG. 3.

[0029] The keyboard 511 is a type of input means having multiple keys for inputting characters, numbers, various instructions, etc. The pointing device 512 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, etc. The DVD-RW drive 514 controls reading and writing of various data from a DVD-RW 513, which is an example of a removable recording medium. Note that this is not limited to a DVD-RW, and may be a DVD-R, etc. The media I / F 516 controls reading and writing (storing) of data from a recording medium 515, such as a flash memory.

[0030] [Functional configuration of information processing system] The functional configuration of the information processing system in this embodiment will be described with reference to Fig. 4. Fig. 4 is a block diagram showing an example of the functional configuration of the information processing system in this embodiment.

[0031] <Functional configuration of the transaction management server> As shown in Fig. 4, the transaction management server 10 in this embodiment comprises a transmitter / receiver 11, a generator 14, a judgement unit 15, a creator 16, a memory controller 19, and a memory unit 100. Each of these units is a function or a means for performing a function that is realized when any of the components shown in Fig. 3 operates in response to an instruction from the CPU 501 in accordance with a program loaded from the HD 504 onto the RAM 503. The memory unit 100 is constructed by the RAM 503 and HD 504 shown in Fig. 3.

[0032] The transmitting / receiving unit 11 is realized by commands from the CPU 501 and the network I / F 509 shown in FIG. 3, and transmits and receives various data (or information) to and from other terminals, devices, or systems via the communication network N1.

[0033] The generating unit 14 is realized by an instruction from the CPU 501 shown in Fig. 3, and generates predetermined data (information). The generated contents will be described later.

[0034] The determination unit 15 is realized by an instruction from the CPU 501 shown in Fig. 3, and makes a predetermined determination, the contents of which will be described later.

[0035] The creation unit 16 is realized by commands from the CPU 501 shown in FIG. 3, and creates each screen, which will be described later, and creates a URL for each screen.

[0036] The storage control unit 19 is realized by instructions from the CPU 501 and the HDD controller 505 shown in FIG. 3, and performs processes such as storing various data in the storage unit 100 and reading out various data stored in the storage unit 100.

[0037] The memory unit 100 contains a tenant information management DB, an accounts receivable information management DB, an accounts payable information management DB, an issued invoice information management DB, a receipt information management DB, a received invoice information management DB, a payment information management DB, and a deposit information management DB.

[0038] The tenant information management DB is configured by a tenant information management table. The tenant information management table stores information about service using company A and service using company B, which are tenants of the transaction management server 10. Details of the tenant information management table will be described later.

[0039] The accounts receivable ledger information management DB is composed of an accounts receivable ledger information management table for each tenant. The accounts receivable ledger information management table stores accounts receivable ledger information based on sales information from the seller (service using company A) to the purchaser (service using company B). The accounts receivable ledger information may be imported from an external system that has an accounts receivable ledger, such as an accounting system. If the transaction management server 10 also has accounting functions, the accounts receivable ledger that the transaction management server 10 has may be used. Details of the accounts receivable ledger information management table will be described later.

[0040] The accounts payable information management DB is composed of an accounts payable information management table for each tenant. The accounts payable information management table stores accounts payable information based on delivery information from the seller (service using company A) to the purchaser (service using company B). The accounts payable information may be imported from an external system that has an accounts payable ledger, such as an accounting system. If the transaction management server 10 also has accounting functions, the accounts payable ledger that the transaction management server 10 has may be used. Details of the accounts payable information management table will be described later.

[0041] The issued invoice information management DB is composed of an issued invoice information management table for each tenant. The issued invoice information management table stores invoice information related to invoices issued by a seller (service using company A) to a purchaser (service using company B). Details of the issued invoice information management table will be described later.

[0042] The receipt information management DB is made up of a receipt information management table for each tenant. The receipt information management table stores receipt information for the purchaser (service using company B) to receive the invoice. Details of the receipt information management table will be described later.

[0043] The received invoice information management DB is composed of a received invoice information management table for each tenant. The issued invoice information management table stores invoice information related to invoices received by the purchaser (service using company B) from the seller (service using company A). Details of the received invoice information management table will be described later.

[0044] The payment information management DB is composed of a payment information management table for each tenant. The payment information management table stores payment information sent by the purchaser (service using company B) to the seller (service using company A). Details of the payment information management table will be described later.

[0045] The deposit information management DB is made up of a deposit information management table for each tenant. The deposit information management table stores information on deposits sent to the account of the seller (service using company A). Details of the deposit information management table will be described later.

[0046] <Seller terminal functional configuration> As shown in Fig. 4, the seller terminal 20 in this embodiment includes a transmission / reception unit 21, a reception unit 22, a display control unit 24, a determination unit 25, a storage control unit 29, and a storage unit 200. Each of these units is a function or a means for performing a function that is realized when any of the components shown in Fig. 3 operates in response to an instruction from the CPU 501 in accordance with a program loaded from the HD 504 onto the RAM 503. The storage unit 200 is constructed by the RAM 503 and HD 504 shown in Fig. 3.

[0047] The transmission / reception unit 21 is realized by instructions from the CPU 501 shown in Figure 3, as well as the external device connection I / F 508 and the network I / F 509, and transmits and receives various data (or information) with other terminals, devices or systems via the communication network N1.

[0048] The reception unit 22 is realized mainly by commands from the CPU 501 shown in FIG. 3, as well as by the keyboard 511 and pointing device 512, and receives various inputs from the user.

[0049] 3, and displays images by outputting image data to the display 506 or an external display connected to the external device connection I / F 508. The display control unit 24 has a web browser function.

[0050] The determination unit 25 is mainly realized by instructions from the CPU 501 shown in FIG. 3, and performs various determinations.

[0051] The memory control unit 29 is mainly realized by instructions from the CPU 501 and the HDD controller 505 shown in Figure 3, and performs processes such as storing various data in the memory unit 200 and reading out various data stored in the memory unit 200.

[0052] <Functional configuration of the purchaser's terminal> As shown in FIG. 4, the purchaser terminal 30 in this embodiment includes a transmitting / receiving unit 31, a receiving unit 32, a display control unit 34, a determining unit 35, a memory control unit 39, and a memory unit 300.

[0053] The transmission / reception unit 31, reception unit 32, display control unit 34, judgment unit 35, memory control unit 39 and memory unit 300 provided in the purchaser terminal 30 have the same functions as the transmission / reception unit 21, reception unit 22, display control unit 24, judgment unit 25, memory control unit 29 and memory unit 200 provided in the seller terminal 20, respectively, and therefore their explanations will be omitted.

[0054] <Functional configuration of account management server> As shown in Fig. 4, account management server 40 in this embodiment has a transmission / reception unit 41, a judgment unit 45, a creation unit 46, a storage control unit 49, and a storage unit 400. Each of these units is a function or a means of functioning that is realized when any of the components shown in Fig. 3 operates in response to instructions from CPU 501 in accordance with a program loaded from HD 504 onto RAM 503. Furthermore, storage unit 400 is constructed from RAM 503 and HD 504 shown in Fig. 3.

[0055] The transmitting / receiving unit 41 is realized by commands from the CPU 501 and the network I / F 509 shown in FIG. 3, and transmits and receives various data (or information) to and from other terminals, devices, or systems via the communication network N1.

[0056] The determination unit 45 is realized by an instruction from the CPU 501 shown in Fig. 3, and makes a predetermined determination, the contents of which will be described later.

[0057] The creation unit 46 is realized by commands from the CPU 501 shown in FIG. 3, and creates screens and the like.

[0058] The storage control unit 49 is realized by instructions from the CPU 501 and the HDD controller 505 shown in FIG. 3, and performs processes such as storing various data in the storage unit 400 and reading out various data stored in the storage unit 400.

[0059] The account management server 40 may be a server device provided by a financial institution, or may be a server device provided by a predetermined service linked to a financial institution system.

[0060] [Information processing system processing procedure] The processing procedure of the information processing method executed by the information processing system in this embodiment will be described with reference to FIGS.

[0061] <Invoice creation and sending> First, the invoice creation and delivery process (step S1 in FIG. 1) in this embodiment will be described with reference to Fig. 5. Fig. 5 is a sequence diagram showing an example of the invoice creation and delivery process in this embodiment.

[0062] In step S11, the reception unit 22 included in the seller terminal 20 receives a display operation of the invoice creation screen by the seller. The seller is, for example, a person in charge of carrying out the business of the service using company A.

[0063] Before accepting the display operation of the invoice creation screen, the reception unit 22 accepts authentication information, such as a tenant ID, which is identification information of the tenant, entered by the seller. Then, the transmission / reception unit 21 transmits the authentication information to the transaction management server 10, which then performs a predetermined authentication process. The transaction management server 10 authenticates the seller using a tenant information management DB. Therefore, the reception unit 22 can accept the display operation of the invoice creation screen by the seller only if the seller has been authenticated by the transaction management server 10.

[0064] (Tenant information management table) Here, details of the tenant information management table will be described with reference to Fig. 6. Fig. 6 is a conceptual diagram showing an example of the tenant information management table in this embodiment.

[0065] As shown in Figure 6, the tenant information management table 1000 in this embodiment associates and manages information representing the tenant (company name, etc.), authentication information (user ID and password, etc.), contact information (email address, address, etc.), and transfer account information.

[0066] In this embodiment, a tenant can use the service both as a seller and as a buyer. However, by registering a user role representing a seller, a buyer, or the like as tenant information, a specific tenant may be restricted to using the service only as a seller or only as a buyer.

[0067] Returning to Figure 5, in step S12, the transmitter / receiver 21 included in the seller terminal 20 transmits a request to acquire an invoice creation screen to the transaction management server 10. In the transaction management server 10, the transmitter / receiver 11 receives the request to acquire an invoice creation screen from the seller terminal 20.

[0068] In step S13, the memory control unit 19 included in the transaction management server 10 reads out the accounts receivable information from the accounts receivable information management DB. Next, the creation unit 16 creates screen data for an invoice creation screen based on the accounts receivable information read out by the memory control unit 19.

[0069] (Accounts receivable information management table) Here, details of the accounts receivable book information management table will be described with reference to Fig. 7. Fig. 7 is a conceptual diagram showing an example of the accounts receivable book information management table in this embodiment.

[0070] As shown in Figure 7, in the accounts receivable ledger information management table 1100 of this embodiment, the date on which the accounts receivable occurred (hereinafter also referred to as the "accounts receivable date"), identification information for identifying the invoice (common invoice ID and invoice ID, etc.), information regarding the details in the invoice (detail ID, product code, unit price, quantity, amount, etc.), and information regarding the deposit (deposit quantity and deposit amount) are managed in association with each other.

[0071] The example of accounts receivable ledger information shown in Figure 7 is in its initial state after being imported from the accounts receivable ledger. In the initial state, each piece of identification information (common invoice ID, invoice ID, and detail ID) and information about deposits (deposit quantity and deposit amount) are left blank.

[0072] Returning to Figure 5, in step S14, the transmitting / receiving unit 11 included in the transaction management server 10 transmits the screen data of the invoice creation screen created by the creation unit 16 to the seller terminal 20. In the seller terminal 20, the transmitting / receiving unit 21 receives the screen data of the invoice creation screen from the transaction management server 10.

[0073] In step S15, the display control unit 24 included in the seller terminal 20 displays the invoice creation screen on the display 506 based on the screen data for the invoice creation screen.

[0074] (Invoice creation screen) The invoice creation screen in this embodiment will now be described with reference to Fig. 8. Fig. 8 is a conceptual diagram showing an example of the invoice creation screen in this embodiment.

[0075] As shown in FIG. 8, the invoice creation screen 2000 in this embodiment has a condition setting area 2010, an accounts receivable display area 2020, a create button 2008, and a cancel button 2009.

[0076] When conditions such as billing destination, billing closing date, and billing period are entered in the condition setting area 2010, accounts receivable information that matches the conditions is displayed in the accounts receivable display area 2020. Each condition value displayed in the condition setting area 2010 may be set in advance. For example, the billing period may be set from the day after the billing closing date of the previous month to the billing closing date of the current month.

[0077] The accounts receivable ledger display area 2020 displays the contents of the accounts receivable ledger information in a form in which each detail can be selected. For example, by displaying one check box for each detail, the detail can be displayed in a selectable manner. In the initial state, all details are selected.

[0078] When the seller presses the create button 2008, the acceptance unit 22 accepts the operation to create an invoice (generate invoice information). When the seller presses the cancel button 2009, the display control unit 24 closes the invoice creation screen 2000.

[0079] Returning to Figure 5, in step S16, the acceptance unit 22 included in the seller terminal 20 accepts an operation to create an invoice (generate invoice information) by the seller. Specifically, on the invoice creation screen 2000, the seller selects the details to be included in the invoice and presses the create button 2008.

[0080] In step S17, the transmitter / receiver 21 included in the seller terminal 20 transmits a request to register invoice information to the transaction management server 10. The registration request includes the accounts receivable ledger information selected in the accounts receivable ledger display area 2020. In the transaction management server 10, the transmitter / receiver 11 receives the request to register invoice information from the seller terminal 20.

[0081] In step S18, the creation unit 16 included in the transaction management server 10 creates an invoice image as shown in Fig. 9 based on the request to register the invoice information, and stores it in a predetermined storage location. At this time, the creation unit 16 creates a receipt screen URL, which is a URL (Uniform Resource Locator) for accessing a receipt screen for receiving the invoice.

[0082] Next, the memory control unit 19 generates invoice information that represents the contents of the invoice and registers it in the issued invoice information management DB. The memory control unit 19 also updates the accounts receivable information management DB based on the generated invoice information. At this time, the memory control unit 19 issues a common invoice ID and invoice ID that identify the invoice, as well as a detail ID that identifies each detail.

[0083] The common invoice ID is identification information that the transaction management server 10 sets for each invoice information so that it can be managed in common by each tenant. The invoice ID is identification information that a tenant arbitrarily sets for invoice information. Therefore, in subsequent processing, the identification information that the transaction management server 10 uses to identify invoice information is the common invoice ID. However, if it is possible to control invoice IDs so that they do not overlap among tenants, invoice IDs may be used instead of the common invoice ID.

[0084] (Issued invoice information management table) Details of the issuance invoice information management table will now be described with reference to Fig. 10. Fig. 10 is a conceptual diagram showing an example of the issuance invoice information management table 1300 in this embodiment.

[0085] As shown in Figure 10, in the issued invoice information management table in this embodiment, identification information that identifies the invoice (common invoice ID and invoice ID, etc.), information that represents the invoice recipient (company name of the invoice recipient, etc.), invoice amount, invoice date, payment due date, invoice status, invoice image storage location, information regarding details (detail ID, product code, product name, unit price, quantity, amount, etc.), and transfer destination information are managed in association with each other.

[0086] Of these, the invoice amount is set to the total amount of the selected accounts receivable information. The payment due date is automatically set based on the payment date corresponding to the purchaser. For example, if the purchaser's payment date is 30 days, the payment due date will be the end of the following month. Also, for example, if the purchaser's payment date is 60 days, the payment due date will be the end of the month after next. The invoice status is set to "Created." The transfer destination information is obtained from the tenant information management table.

[0087] An example of the accounts receivable ledger information management table after an invoice has been created is shown in Figure 11. As shown in Figure 11, in the accounts receivable ledger information management table after an invoice has been created, the common invoice ID, invoice ID, and detail ID are registered in the accounts receivable ledger information for which an invoice has been issued.

[0088] Returning to Figure 5, in step S19, the reception unit 22 included in the seller terminal 20 receives an invoice sending operation from the seller. The invoice sending operation is performed on an invoice sending screen. The invoice sending screen is displayed, for example, by selecting the invoice to be sent on a screen displaying a list of created invoices.

[0089] (Invoice sending screen) The bill delivery screen in this embodiment will now be described with reference to Fig. 12. Fig. 12 is a conceptual diagram showing an example of the bill delivery screen in this embodiment.

[0090] As shown in FIG. 12, the invoice delivery screen 2100 in this embodiment has a delivery destination selection field 2101 , an invoice image display field 2102 , a transmittal input field 2103 , a send button 2108 , and a cancel button 2109 .

[0091] Among these, the delivery destination selection field 2101 displays selectable email addresses associated with the purchaser in the tenant information management table. The invoice image display field 2102 displays the invoice image indicated by the invoice image storage destination in the issued invoice information management table.

[0092] The subject and text to be written when sending the invoice are entered in the cover letter input field 2103. It is preferable that a predetermined template be initially displayed for the subject and text. A link to the receipt screen URL is embedded in the cover letter input field 2103.

[0093] When the seller presses the send button 2108, the reception unit 22 receives the invoice sending operation. When the seller presses the cancel button 2109, the display control unit 24 closes the invoice sending screen 2100.

[0094] Returning to Figure 5, in step S20, the transmitter / receiver 21 included in the seller terminal 20 sends an invoice sending request to the transaction management server 10. The sending request includes a common invoice ID. In the transaction management server 10, the transmitter / receiver 11 receives the invoice sending request from the seller terminal 20.

[0095] In step S21, the memory control unit 19 of the transaction management server 10 identifies invoice information in the issued invoice information management table based on the common invoice ID included in the invoice sending request. Next, the memory control unit 19 updates the invoice status of the identified invoice information to "Sent."

[0096] In step S22, the storage control unit 19 provided in the transaction management server 10 generates receipt information based on the request to send the invoice, and registers it in the receipt information management DB.

[0097] (Receipt information management table) Here, details of the receipt information management table will be described with reference to Fig. 13. Fig. 13 is a conceptual diagram showing an example of the receipt information management table in this embodiment.

[0098] As shown in Figure 13, in the receipt information management table 1400 of this embodiment, identification information for identifying the invoice (common invoice ID and invoice ID, etc.), information representing the issuer of the invoice (issuer company name, etc.), issue date, receipt screen URL, etc. are associated and managed.

[0099] Returning to Figure 5, in step S23, the transmitting / receiving unit 11 provided in the transaction management server 10 sends an email containing a receipt screen URL to the purchaser terminal 30. Note that the transmitting / receiving unit 11 does not have to send the email containing the receipt screen URL directly to the purchaser terminal 30. For example, the transmitting / receiving unit 11 may send the email to a specified email address on the purchaser's side, and the purchaser terminal 30 may receive the email from a mail server.

[0100] The method of sending the receipt screen URL is not limited to email. For example, a message including the receipt screen URL may be sent to the purchaser terminal 30 via a messenger app. Furthermore, the creation unit 16 may create a two-dimensional code indicating the receipt screen URL and embed the two-dimensional code in an invoice image, and the transmission / reception unit 11 may send the invoice image with the embedded two-dimensional code to a printing device, print out the invoice image on recording paper, and send the printed paper invoice to the purchaser by mail.

[0101] <Invoice Receipt Processing> Next, the invoice receiving process (step S2 in FIG. 1) in this embodiment will be described with reference to Fig. 14. Fig. 14 is a sequence diagram showing an example of the invoice receiving process in this embodiment.

[0102] In step S31, the transmitting / receiving unit 31 provided in the purchaser terminal 30 receives an e-mail or the like including a receipt screen URL. Next, the receiving unit 32 receives an operation to display the invoice receipt screen by the purchaser. The purchaser is, for example, a person in charge of carrying out business at service using company B. The operation to display the invoice receipt screen is, for example, an operation to open the receipt screen URL included in the e-mail (i.e., an operation to click on the link of the receipt screen URL in the e-mail).

[0103] In step S32, the transmitting / receiving unit 31 provided in the purchaser terminal 30 sends a request to acquire the invoice receipt screen to the transaction management server 10. The acquisition request includes the receipt screen URL. In the transaction management server 10, the transmitting / receiving unit 11 receives the request to acquire the invoice receipt screen from the purchaser terminal 30.

[0104] In step S33, the memory control unit 19 provided in the transaction management server 10 reads out receipt information from the receipt information management DB using the receipt information management table 1400, based on the receipt screen URL included in the request to obtain the invoice receipt screen. Next, the memory control unit 19 reads out invoice information from the issuance invoice information management DB using the issuance invoice information management table 1300, based on the common invoice ID included in the read out receipt information. Next, the creation unit 16 creates screen data for the invoice receipt screen based on the receipt information and invoice information read out by the memory control unit 19.

[0105] In step S34, the transmitting / receiving unit 11 provided in the transaction management server 10 transmits the screen data of the invoice receipt screen created by the creation unit 16 to the purchaser terminal 30. In the purchaser terminal 30, the transmitting / receiving unit 31 receives the screen data of the invoice receipt screen from the transaction management server 10.

[0106] In step S35, the display control unit 34 included in the purchaser terminal 30 displays the invoice receipt screen on the display 506 based on the screen data for the invoice receipt screen.

[0107] (Invoice receipt screen) The invoice receipt screen in this embodiment will now be described with reference to Fig. 15. Fig. 15 is a conceptual diagram showing an example of the invoice receipt screen in this embodiment.

[0108] As shown in FIG. 15, the invoice receipt screen 2200 in this embodiment has an invoice image display field 2201 , a download button 2202 , and a receipt button 2203 .

[0109] Of these, the invoice image display field 2201 displays the invoice image indicated by the invoice image storage location in the issued invoice information management table.

[0110] When the purchaser presses the download button 2202, the transmission / reception unit 31 downloads the invoice image, and the storage control unit 39 stores the downloaded invoice image in a predetermined storage location in the storage unit 300. When the purchaser presses the receive button 2203, the reception unit 32 receives the operation to receive the invoice.

[0111] Returning to Figure 14, in step S36, the reception unit 32 of the purchaser terminal 30 receives an invoice reception operation by the purchaser. Specifically, the purchaser presses the Receive button 2203 on the invoice reception screen 2200.

[0112] In step S37, the transmitting / receiving unit 31 provided in the purchaser terminal 30 sends an invoice receipt request to the transaction management server 10. The receipt request includes a common invoice ID. In the transaction management server 10, the transmitting / receiving unit 11 receives the invoice receipt request from the purchaser terminal 30.

[0113] In step S38, the memory control unit 19 of the transaction management server 10 identifies invoice information in the issued invoice information management table based on the common invoice ID included in the invoice receipt request. Next, the memory control unit 19 updates the invoice status of the identified invoice information to "Received."

[0114] In step S39, the storage control unit 19 provided in the transaction management server 10 registers the invoice information identified in the issued invoice information management table in the received invoice information management DB.

[0115] (Received invoice information management table) Details of the received invoice information management table will now be described with reference to Fig. 16. Fig. 16 is a conceptual diagram showing an example of the received invoice information management table in this embodiment.

[0116] 16, in the received invoice information management table 1500 of this embodiment, identification information for identifying an invoice (common invoice ID, invoice ID, etc.), information representing the invoice recipient (name of the invoice recipient company, etc.), invoice amount, invoice date, payment due date, invoice image storage location, information regarding details (detail ID, product code, product name, unit price, quantity, amount, etc.), and transfer destination information are managed in association with each other. In other words, the received invoice information management table differs from the issued invoice information management table only in that it does not have an invoice status.

[0117] <Remittance data creation process> Next, the remittance data creation process (step S3 in Fig. 1) in this embodiment will be described with reference to Fig. 17. Fig. 17 is a sequence diagram showing an example of the remittance data creation process in this embodiment.

[0118] In step S41, the reception unit 32 of the purchaser terminal 30 receives an operation to display the payment processing screen by the purchaser. The operation to display the payment processing screen is performed on the received invoice list screen.

[0119] (Received invoice list screen) The received invoice list screen in this embodiment will now be described with reference to Fig. 18. Fig. 18 is a conceptual diagram showing an example of the received invoice list screen in this embodiment.

[0120] As shown in Figure 18, the received invoice list screen 2300 in this embodiment has an invoice list display field 2301. The invoice list display field 2301 displays a list of information about received invoices (such as biller, invoice number, total amount, and issue date). Each invoice displayed in the invoice list display field 2301 displays a display button 2302, a download button 2303, and a payment process button 2304.

[0121] When the purchaser presses the display button 2302, an invoice image corresponding to the invoice is displayed on the display 506. When the purchaser presses the download button 2303, the transmission / reception unit 31 downloads the invoice image, and the storage control unit 39 stores the downloaded invoice image in a predetermined storage location in the storage unit 300. When the purchaser presses the payment processing button 2304, the reception unit 32 receives an operation to display the payment processing screen.

[0122] Returning to Figure 17, in step S42, the transmitter / receiver 31 of the purchaser terminal 30 sends a request to acquire the payment processing screen to the transaction management server 10. The request includes a common invoice ID. In the transaction management server 10, the transmitter / receiver 11 receives the request to acquire the payment processing screen from the purchaser terminal 30.

[0123] In step S43, the memory control unit 19 provided in the transaction management server 10 reads invoice information from the received invoice information management DB based on the common invoice ID included in the request to obtain the payment processing screen. Next, the memory control unit 19 reads accounts payable information from the accounts payable information management DB based on the common invoice ID included in the read invoice information. Next, the creation unit 16 creates screen data for the payment processing screen based on the invoice information and accounts payable information read by the memory control unit 19.

[0124] (Accounts payable information management table) Here, details of the accounts payable information management table will be described with reference to Fig. 19. Fig. 19 is a conceptual diagram showing an example of the accounts payable information management table in this embodiment.

[0125] As shown in Figure 19, the accounts payable ledger information management table in this embodiment associates and manages the date on which the account payable occurred (hereinafter also referred to as the "accounts payable date"), identification information that identifies the invoice (common invoice ID and invoice ID, etc.), information regarding the details in the invoice (detail ID, product code, unit price, quantity, amount, etc.), and information regarding payment (payment quantity and payment amount), etc.

[0126] The example of accounts payable ledger information shown in Figure 19 is in its initial state after being imported from the accounts payable ledger. In the initial state, each piece of identification information (common invoice ID, invoice ID, and statement ID) and information related to payment (payment quantity and payment amount) are left blank.

[0127] Returning to Figure 17, in step S44, the transmitting / receiving unit 11 included in the transaction management server 10 transmits the screen data of the payment processing screen created by the creation unit 16 to the purchaser terminal 30. In the purchaser terminal 30, the transmitting / receiving unit 31 receives the screen data of the payment processing screen from the transaction management server 10.

[0128] In step S45, the display control unit 34 included in the purchaser terminal 30 displays the payment processing screen on the display 506 based on the screen data of the payment processing screen.

[0129] (Payment processing screen) Here, the payment processing screen in this embodiment will be described with reference to Fig. 20. Fig. 20 is a conceptual diagram showing an example of the payment processing screen in this embodiment.

[0130] As shown in Figure 20, the payment processing screen 2400 in this embodiment has a condition setting area 2410, an accounts payable information display field 2420, an invoice information display field 2430, a statement information display field 2440, a quantity input button 2441, a payment information display field 2450, a create button 2408, and a cancel button 2409.

[0131] When conditions such as the payment closing date and payment period are entered in the condition setting area 2410, accounts payable information that matches the conditions is displayed in the accounts payable information display field 2420. Each condition value displayed in the condition setting area 2410 may be set in advance. For example, the payment period may be set from the day after the payment closing date of the previous month to the payment closing date of the current month.

[0132] The invoice information display field 2430 displays the contents of the invoice information (invoice ID, invoice amount, invoice date, payment due date, etc.). The detail information display field 2440 displays information about the details included in the invoice information (product name, quantity, unit price, amount, etc.) in a selectable format for each detail.

[0133] In the detail information display field 2440, details contained in the accounts payable information and invoice information are compared. Details contained in both the accounts payable information and invoice information are automatically selected. At this time, if the quantity in the accounts payable information and the quantity in the invoice information do not match, the quantity in both will be displayed so that it can be understood. For example, it may be displayed in a format such as "quantity in accounts payable information / quantity in invoice information."

[0134] One quantity input button 2441 is displayed for each detail displayed in the detail information display field 2440. When the quantity input button 2441 is pressed, a dialogue screen for inputting the quantity is displayed, and the quantity to be paid for the detail can be input.

[0135] The quantity input button 2441 corresponding to the details not selected in the detail information display field 2440 may be controlled so that it cannot be pressed.

[0136] The payment information display field 2450 displays the transfer destination information included in the invoice information. The payment date in the payment information display field 2450 is automatically entered based on a preset rule (for example, the 25th of the following month). However, the purchaser can also manually correct it.

[0137] When the purchaser presses the create button 2408, the reception unit 32 receives the operation to create remittance data. When the purchaser presses the cancel button 2409, the display control unit 34 closes the payment processing screen 2400.

[0138] [Variation 1: Payment processing screen reflecting return information] The payment processing screen 2400 may further display return information if a return from the buyer to the seller occurs.

[0139] Figure 21 is a conceptual diagram showing an example of a payment processing screen 2400 that displays returned goods information. The payment processing screen 2400 shown in Figure 21 further has a returned goods information display field 2460. The returned goods information displayed in the returned goods information display field 2460 is stored in the accounts payable information management table.

[0140] Figure 22 is a conceptual diagram showing an example of an accounts payable information management table in which returned goods information is stored. The accounts payable information management table shown in Figure 22 includes accounts payable information representing returned goods. In accounts payable information representing returned goods, the quantity and amount are set to negative (△), and the remarks are set to "returned goods."

[0141] While the example above shows how to display returned goods information on the payment processing screen, other information may be displayed if the item has a negative invoice amount. For example, accounts payable information may be displayed with negative quantities and amounts due to discounts or defective products.

[0142] [Variation 2: Payment Processing Screen with Chat Function] There are cases where the buyer may wish to inquire about the details of the payment to the seller on the payment processing screen 2400. Specifically, this may occur when, for example, it is discovered that there are items or quantities not delivered among the details listed on the invoice, or when the buyer wishes to confirm who will bear the bank transfer fee.

[0143] For such cases, the payment processing screen 2400 may have a chat function that allows the buyer to inquire about the details of the billing request with the seller. Figure 23 is a conceptual diagram showing an example of the payment processing screen 2400 with a chat function.

[0144] As shown in FIG. 23, the payment transaction screen 2400 with chat functionality further includes a contact us button 2442 and a chat area 2470.

[0145] One inquiry button 2442 is displayed for each detail displayed in the detail information display field 2440. When the inquiry button 2442 is pressed, a message for making an inquiry about the detail is entered in the chat area 2470. Information shared between the seller and the buyer, such as an invoice ID, is automatically embedded in the message.

[0146] (Chat history management table) If the payment processing screen 2400 has a chat function, a chat history management DB is created in the storage unit 100 of the transaction management server 10.

[0147] The chat history management DB is composed of a chat history management table, which stores historical information on inquiries made between a seller (service using company A) and a purchaser (service using company B).

[0148] Fig. 24 is a conceptual diagram showing an example of a chat history management table in this embodiment. As shown in Fig. 24, in the chat history management table 1800 in this embodiment, the chat date and time, identification information for identifying the inquiry target (payment ID, common invoice ID, invoice ID, and statement ID), information indicating the sender (biller or invoice recipient), and the contents of the message are managed in association with each other.

[0149] Here, an example of an inquiry between a seller and a buyer via chat has been described, but the means of making an inquiry between a seller and a buyer is not limited to chat. Any means that allows a conversation between a seller and a buyer may be used, such as a function that allows a voice call or a video call via the Internet.

[0150] Returning to Figure 17, in step S46, the reception unit 32 of the purchaser terminal 30 receives an operation by the purchaser to create remittance data. Specifically, on the payment processing screen 2400, the purchaser selects details to be included in the remittance data and presses the Create button 2408.

[0151] In step S47, the transmitter / receiver unit 31 provided in the purchaser terminal 30 sends a request to create remittance data (hereinafter also referred to as a "payment request") to the transaction management server 10. The creation request includes the invoice ID, detail ID, and the quantity entered for each detail. The detail ID included in the creation request is the detail ID of the detail selected in the detail information display field 2440. In the transaction management server 10, the transmitter / receiver unit 11 receives the request to create remittance data from the purchaser terminal 30.

[0152] In step S48, the creation unit 16 issues a payment ID for identifying the payment based on the request for creating remittance data. Next, the creation unit 16 creates remittance data with the payment ID embedded. The payment ID can be embedded in the remittance data as EDI (Electronic Data Interchange) information. It may also be embedded in a specific item (e.g., notes) of the transaction details in the Zengin EDI system.

[0153] The payment ID does not have to be issued by the transaction management server 10. For example, the payment information ID issued by the financial institution D1 when the remittance data is created may be used as the payment ID.

[0154] In step S49, the memory control unit 19 of the transaction management server 10 generates payment information representing the contents of the remittance data and registers it in the payment information management DB. The memory control unit 19 also updates the accounts payable information management DB based on the request to create remittance data.

[0155] (Payment information management table) Details of the payment information management table will now be described with reference to Fig. 25. Fig. 25 is a conceptual diagram showing an example of the payment information management table in this embodiment.

[0156] As shown in Figure 25, the payment information management table 1600 in this embodiment associates and manages information representing the contents of the remittance data (payment ID, payment amount, scheduled payment date, etc.), identification information identifying the invoice (common invoice ID, invoice ID, etc.), and information regarding details (detail ID, quantity, amount, etc.).

[0157] An example of the accounts payable information management table after the remittance data has been created is shown in Figure 26. As shown in Figure 26, in the accounts payable information management table after the remittance data has been created, the common invoice ID, invoice ID, and statement ID are registered in the accounts payable information for which the remittance data was created.

[0158] Returning to Figure 17, in step S50, the transmitter / receiver 11 of the transaction management server 10 transmits to the purchaser terminal 30 the remittance data in which the payment ID is embedded.

[0159] The purchaser then instructs the execution of a remittance using the downloaded remittance data according to a predetermined procedure. For example, the purchaser instructs the execution of a remittance by uploading the remittance data via a predetermined screen provided by financial institution D1, such as firm banking or internet banking, which manages the account of service-using company B. Then, financial institution D1, which manages the account of service-using company B, remits the amount according to the remittance data to financial institution D2, which manages the account of service-using company A, and information such as the payment ID included in the remittance data is also sent to financial institution D2. This allows the seller to obtain deposit information, including information such as the payment ID, from financial institution D2.

[0160] It should be noted that remittance based on remittance data is not limited to being made via a financial institution. For example, remittance may be made via a service such as an online payment service. In this case, for example, service provider C sends a two-dimensional code indicating the remittance data to the purchaser, and the purchaser can make the remittance by having the two-dimensional code read via an application for the online payment service or other service installed on the purchaser terminal 30.

[0161] <Acquisition of deposit information and automatic reconciliation processing> Next, the deposit information acquisition process (step S5 in FIG. 1) and the automatic clearing process (step S6 in FIG. 1) in this embodiment will be described with reference to Fig. 27. Fig. 27 is a sequence diagram showing an example of the deposit information acquisition process and the automatic clearing process in this embodiment.

[0162] In step S61, the transmitter / receiver 11 included in the transaction management server 10 transmits a request to acquire deposit information to the account management server 40-2. The account management server 40-2 is the account management server 40 that manages the account of the service using company A.

[0163] The trigger for the transaction management server 10 to send a request to acquire deposit information may be a request from the seller terminal 20 in response to an operation by the seller, or may be every predetermined time interval (for example, 30 minutes).

[0164] In step S62, the transmitter / receiver 41 provided in the account management server 40-2 transmits the deposit information related to the account of the service using company A to the transaction management server 10. The deposit information includes a payment ID. In the transaction management server 10, the transmitter / receiver 11 receives the deposit information from the account management server 40-2.

[0165] The account management server 40-2 performs a predetermined authentication process when transmitting deposit information related to the account of the service using company A to the transaction management server 10. For example, the authentication information for the account of the service using company A is registered in the tenant information management DB, and the transmitter / receiver unit 11 of the transaction management server 10 transmits the authentication information identified based on the tenant ID to the account management server 40-2 along with a request to obtain the deposit information.

[0166] In account management server 40-2, memory control unit 49 executes authentication processing based on the transmitted authentication information. If authentication is successful, memory control unit 49 reads out the deposit information corresponding to the authentication information from the deposit information stored in memory unit 400. Finally, transmission / reception unit 41 transmits the read deposit information to transaction management server 10.

[0167] In step S62, the storage control unit 19 included in the transaction management server 10 registers the deposit information received from the account management server 40-2 in the deposit information management DB.

[0168] (Deposit information management table) Here, the details of the deposit information management table will be described with reference to Fig. 28. Fig. 28 is a conceptual diagram showing an example of the deposit information management table in this embodiment.

[0169] 28, in the deposit information management table 1700 of this embodiment, the transaction date, withdrawal amount (payment amount), information indicating the payee, deposit amount (deposit amount), information indicating the remittance source, balance, payment ID, reconciliation status, etc. are managed in association with each other. In the initial state, the reconciliation status is left blank.

[0170] Returning to Figure 27, in step S64, the transaction management server 10 executes an automatic clearing process based on the deposit information and payment information.

[0171] <Automatic Clearing Process> Here, the automatic clearing process (step S64 in Fig. 27) in this embodiment will be described in detail with reference to Fig. 29. Fig. 29 is a flowchart showing an example of the automatic clearing process in this embodiment.

[0172] In step S64-1, the storage control unit 19 acquires unprocessed deposit information from the deposit information management DB. Unprocessed deposit information is deposit information for which the reconciliation status in the deposit information management table is blank.

[0173] Steps S64-2 to S64-8 are executed for each unprocessed deposit information acquired in step S64-1.

[0174] In step S64-2, the judgment unit 15 judges whether or not a payment ID is set in the acquired deposit information. If a payment ID is set (YES), the judgment unit 15 acquires the payment ID and proceeds to step S64-3. If a payment ID is not set (NO), the judgment unit 15 proceeds to step S64-8.

[0175] In step S64-3, the storage control unit 19 acquires payment information from the payment information management DB based on the payment ID acquired in step S64-2.

[0176] In step S64-4, the judgment unit 15 determines whether the payment amount in the payment information matches the deposit amount in the deposit information. If the payment amount matches the deposit amount (YES), the judgment unit 15 proceeds to step S64-5. If the payment amount does not match the deposit amount (NO), the judgment unit 15 proceeds to step S64-7.

[0177] In step S64-5, the memory control unit 19 generates accounts receivable ledger information based on the deposit information and payment information and registers it in the accounts receivable ledger information management table. In the generated accounts receivable ledger information, the accounts receivable date is set to the transaction date of the deposit information, and the common invoice ID, invoice ID, detail ID, deposit quantity, and deposit amount are set to the common invoice ID, invoice ID, detail ID, quantity, and amount of the payment information.

[0178] In step S64-6, the storage control unit 19 updates the reconciliation status in the deposit information management table to reconciled. Thereafter, the storage control unit 19 ends the processing for the deposit information and returns the processing to step S64-2.

[0179] In step S64-7, the storage control unit 19 updates the reconciliation status in the deposit information management table to "amount mismatch." Thereafter, the storage control unit 19 ends the processing for the deposit information and returns the processing to step S64-2.

[0180] In step S64-8, the storage control unit 19 updates the clearing status in the deposit information management table to manual clearing. Thereafter, the storage control unit 19 ends the processing for the deposit information and returns the processing to step S64-2.

[0181] An example of the accounts receivable ledger information management table after automatic clearing is shown in Figure 30. As shown in Figure 30, in the accounts receivable ledger information management table after automatic clearing, a record has been added in which the common invoice ID, invoice ID, and detail ID match, and the deposited quantity and deposited amount are set.

[0182] An example of the accounts payable information management table after automatic clearing is shown in Figure 31. As shown in Figure 31, in the accounts payable information management table after automatic clearing, a record has been added in which the common invoice ID, invoice ID, and detail ID match, and the deposited quantity and deposited amount are set.

[0183] The registration of the deposit quantity and amount in the accounts payable information management table is not performed by the automatic clearing process. The purchaser manually registers the accounts payable information with the deposit quantity and amount set by operating the purchaser terminal 30, etc.

[0184] However, the transaction management server 10 may be configured to refer to the payment information management table on the scheduled payment date, and automatically register the payment in the accounts payable information management table once the payment has been confirmed. Specifically, the payment information for which the scheduled payment date is the current day can be obtained from the payment information management table, and the accounts payable information with the common invoice ID, detail ID, quantity, and amount set can be registered in the accounts payable information management table.

[0185] Returning to Figure 27, in step S65, the reception unit 22 of the seller terminal 20 receives an operation by the seller to display the deposit management screen. The operation to display the deposit management screen is performed, for example, on a main menu screen provided by the transaction management server 10.

[0186] In step S66, the transceiver unit 21 provided in the seller terminal 20 sends a request to acquire the deposit management screen to the transaction management server 10. The request includes the billing period. The billing period may be from the day after the previous month's billing closing date to the current month's billing closing date, or may be specified during the display operation of the deposit management screen. In the transaction management server 10, the transceiver unit 11 receives the request to acquire the deposit management screen from the seller terminal 20.

[0187] In step S67, the memory control unit 19 of the transaction management server 10 reads out the accounts receivable ledger information from the accounts receivable ledger information management DB based on the billing period included in the request to acquire the deposit management screen. Next, the memory control unit 19 reads out the invoice information from the issued invoice information management DB based on the common invoice ID included in the read out accounts receivable ledger information.

[0188] Next, the memory control unit 19 reads out payment information from the payment information management DB based on the common invoice ID included in the read accounts receivable ledger information. Next, the creation unit 16 creates screen data for the deposit management screen based on the accounts receivable ledger information, invoice information, and payment information read out by the memory control unit 19.

[0189] <<Deposit management screen creation process>> Here, the details of the deposit management screen creation process (step S67 in Fig. 27) in this embodiment will be described with reference to Fig. 32. Fig. 32 is a flowchart showing an example of the deposit management screen creation process in this embodiment.

[0190] In step S67-1, the memory control unit 19 acquires the first accounts receivable information from the accounts receivable information management DB. The first accounts receivable information is accounts receivable information in which the accounts receivable date is within the billing period and the deposited quantity and amount are blank.

[0191] Steps S67-2 to S67-15 are executed for each of the first accounts receivable information acquired in step S67-1.

[0192] In step S67-2, the judgment unit 15 determines whether a common invoice ID and a detail ID are set in the acquired first accounts receivable information. If a common invoice ID and a detail ID are set (YES), the judgment unit 15 acquires the common invoice ID and the detail ID and proceeds to step S67-3. If a common invoice ID and a detail ID are not set (NO), the judgment unit 15 proceeds to step S67-8.

[0193] In step S67-3, the memory control unit 19 acquires second accounts receivable information from the accounts receivable information management DB based on the common invoice ID and detail ID acquired in step S67-2. The second accounts receivable information is accounts receivable information that has the same common invoice ID and detail ID as the first accounts receivable information and in which the deposited quantity and amount are set.

[0194] In step S67-4, the judgment unit 15 determines whether or not the second accounts receivable ledger information was acquired in step S67-3. If the second accounts receivable ledger information was acquired (YES), the judgment unit 15 proceeds to step S67-5. If the second accounts receivable ledger information was not acquired (NO), the judgment unit 15 proceeds to step S67-10.

[0195] In step S67-5, the creation unit 16 acquires the account receivable date, the amount of money received, and the amount of money received from the second accounts receivable ledger information acquired in step S67-3. The acquired account receivable date is displayed on the money receipt management screen as the money receipt date.

[0196] In step S67-6, the judgment unit 15 determines whether the quantity and amount in the first accounts receivable ledger information match the deposited quantity and amount in the second accounts receivable ledger information. If the quantity and amount match the deposited quantity and amount (YES), the judgment unit 15 ends processing for the first accounts receivable ledger information and returns the process to step S67-2. If the quantity and amount do not match the deposited quantity and amount (NO), the judgment unit 15 proceeds to step S67-7.

[0197] In step S67-7, the creation unit 16 determines to highlight the first accounts receivable ledger information as requiring attention. Any method of highlighting may be used, for example, changing the background color, changing the text color, displaying in bold, etc. Thereafter, the creation unit 16 ends the processing for the first accounts receivable ledger information and returns the processing to step S67-2.

[0198] In step S67-8, the creation unit 16 sets the invoice status to be displayed on the deposit management screen to "unissued."

[0199] In step S67-9, the creation unit 16 sets the expected deposit quantity and expected deposit amount to be displayed on the deposit management screen to blank. After that, the creation unit 16 ends the processing for the first accounts receivable ledger information and returns the processing to step S67-2.

[0200] In step S67-10, the storage control unit 19 acquires invoice information from the issuance invoice information management DB based on the common invoice ID acquired in step S67-2. Next, the storage control unit 19 acquires payment information from the payment information management DB based on the common invoice ID.

[0201] In step S67-11, the creation unit 16 acquires the invoice status of the invoice information acquired in step S67-10. The acquired invoice status is used as the invoice status to be displayed on the payment management screen.

[0202] In step S67-12, the judgment unit 15 judges whether or not the payment information was acquired in step S67-10. If the payment information was acquired (YES), the judgment unit 15 proceeds to step S67-13. If the payment information was not acquired (NO), the judgment unit 15 proceeds to step S67-9.

[0203] In step S67-13, the creation unit 16 acquires the scheduled payment date from the payment information acquired in step S67-10. The acquired scheduled payment date is displayed on the deposit management screen as the scheduled deposit date.

[0204] In step S67-14, the creation unit 16 acquires the quantity and amount of the payment information acquired in step S67-10 based on the detail ID of the first accounts receivable information acquired in step S67-1. The acquired quantity and amount are used as the expected deposit quantity and expected deposit amount to be displayed on the deposit management screen.

[0205] In step S67-15, the judgment unit 15 determines whether the quantity and amount in the first accounts receivable information match the quantity and amount in the payment information. If the quantity and amount match (YES), the judgment unit 15 ends processing for the first accounts receivable information and returns the process to step S67-2. If the quantity and amount do not match (NO), the judgment unit 15 proceeds to step S67-7.

[0206] In step S67-16, the creation unit 16 creates screen data for the deposit management screen based on the information acquired in steps S67-1 to S67-15.

[0207] Returning to Figure 27, in step S68, the transmitter / receiver 11 included in the transaction management server 10 transmits the screen data of the deposit management screen created by the creation unit 16 to the seller terminal 20. In the seller terminal 20, the transmitter / receiver 21 receives the screen data of the deposit management screen from the transaction management server 10.

[0208] In step S69, the display control unit 24 included in the seller terminal 20 displays the deposit management screen on the display 506 based on the screen data of the deposit management screen.

[0209] (Deposit management screen) Here, the deposit management screen in this embodiment will be described with reference to Fig. 33. Fig. 33 is a conceptual diagram showing an example of the deposit management screen in this embodiment.

[0210] As shown in FIG. 33, the deposit management screen 2500 in this embodiment has a condition setting area 2510, a deposit information display field 2520, and a details confirmation button 2521.

[0211] When conditions such as the billing period are entered in the condition setting area 2510, the deposit information that matches the conditions is displayed in the deposit information display field 2520. The condition values ​​displayed in the condition setting area 2510 may be set in advance. For example, the billing period may be set from the day after the billing closing date of the previous month to the billing closing date of the current month.

[0212] One confirmation details button 2521 is displayed for each piece of deposit information displayed in the deposit information display field 2520. When the confirmation details button 2521 is pressed, a screen showing details of the deposit information is displayed. The confirmation details button 2521 can be used to check the details when the amount on the statement does not match the expected deposit amount or the deposited amount, for example.

[0213] In addition, the details confirmation button 2521 corresponding to the deposit information that does not display information about the expected deposit (expected deposit date, expected deposit quantity, and expected deposit amount) or information about the deposit (deposit date and deposit amount) may be controlled to be hidden.

[0214] An example of a deposit management screen 2500 when a deposit has been made is shown in Figure 34. As shown in Figure 34, on the deposit management screen 2500 when a deposit has been made, the deposit date and the deposit amount are displayed in the deposit information display field 2520.

[0215] [Variation 3: Deposit management screen with chat function] There are cases where the seller wants to inquire about the details of the payment to the buyer on the payment management screen 2500. Specifically, this may occur when the amount billed on the invoice differs from the expected or actual payment amount, or when the transfer fee should have been paid by the buyer but was deducted and the amount paid was the seller's responsibility.

[0216] For the above-mentioned cases, the deposit management screen 2500 may have a chat function that allows the seller to inquire about the details of the deposit from the buyer, similar to the payment processing screen 2400. Figure 35 is a conceptual diagram showing an example of the deposit management screen 2500 with a chat function.

[0217] As shown in FIG. 35, the deposit management screen 2500 with the chat function further includes an inquiry button 2522 and a chat area 2530.

[0218] One inquiry button 2522 is displayed for each piece of deposit information displayed in the deposit information display field 2520. When the inquiry button 2522 is pressed, a message for making an inquiry about the deposit is entered in the chat area 2530. Information shared between the seller and the buyer, such as a payment ID, is automatically embedded in the message.

[0219] [Major Effects of the First Embodiment] In this embodiment, when the transaction management server 10 receives a payment request specifying details from the purchaser terminal 30, it stores payment information that associates the payment ID that identifies the payment request with the details to be paid. Therefore, the transaction management server 10 in this embodiment can specify the details to be paid.

[0220] In particular, the transaction management server 10 in this embodiment transmits remittance data with an embedded payment ID to the purchaser terminal 30. When the purchaser makes a remittance using the remittance data, the transaction management server 10 can obtain deposit information with an embedded payment ID from the account management server 40. Therefore, the transaction management server 10 in this embodiment can identify the details to be paid based on the deposit information. As a result, the transaction management server 10 in this embodiment can achieve automatic clearing on a detail-by-detail basis by comparing the deposit information with the payment information.

[0221] Furthermore, the transaction management server 10 in this embodiment provides a chat function that allows sellers and buyers to make inquiries on the payment processing screen for creating remittance data and the deposit management screen for checking the deposit status. The chat function allows information necessary for inquiries to be embedded in messages. Therefore, the transaction management server 10 in this embodiment allows sellers or buyers to efficiently make inquiries to the other party when they have questions about billing details or deposit details.

[0222] [Second embodiment] In the first embodiment, an example was described in which automatic settlement was performed on an item-by-item basis for the current month's invoice. In the second embodiment, an example is described in which automatic settlement is performed on an item-by-item basis for an invoice for the previous month in which unbilled items remain and which includes amounts carried over from the previous month.

[0223] The information processing system according to the second embodiment will be described below with reference to FIGS. 36 to 44, focusing on the differences from the first embodiment.

[0224] (Accounts receivable information management table) Figure 36 is a conceptual diagram showing an example of an accounts receivable ledger information management table in this embodiment. As shown in Figure 36, the accounts receivable ledger information management table in this embodiment stores accounts receivable ledger information carried over from the previous month and accounts receivable ledger information for the current month. The accounts receivable ledger information carried over from the previous month has an accounts receivable date of the previous month (here, September 1 to September 30, 2020), and there is no accounts receivable ledger information in which the deposited quantity and deposited amount are set.

[0225] For example, the accounts receivable ledger information for September 29, 2020, with a common invoice ID of abcd1235, is a carryover from the previous month because there is no accounts receivable ledger information with the deposit quantity and amount set. On the other hand, the accounts receivable ledger information for September 10, 2020, with a common invoice ID of abcd1235, is not a carryover from the previous month because there is accounts receivable ledger information for October 25, 2020, with the deposit quantity and amount set.

[0226] Additionally, the accounts receivable information with the common invoice ID abcd1321 for October 15, 2020 and October 30, 2020 is for the current month. Therefore, the invoice amount for this month is 1,210,000 yen, which is the sum of the total amount carried over from the previous month (880,000 yen) and the total amount for this month (330,000 yen).

[0227] (Invoice creation screen) 37 is a conceptual diagram showing an example of an invoice creation screen in this embodiment. As shown in Fig. 37, the invoice creation screen 2000 in this embodiment has a previous month's carryover amount display area 2021 and a current month's amount display area 2022 instead of an accounts receivable ledger display area 2020.

[0228] The previous month's carryover display area 2021 is similar to the accounts receivable display area 2020 in the first embodiment, except that the displayed accounts receivable information is limited to the previous month's carryover information. The current month's display area 2022 is similar to the accounts receivable display area 2020 in the first embodiment, except that the displayed accounts receivable information is limited to the current month's amount.

[0229] (Invoice image) Figure 38 is a conceptual diagram showing an example of an invoice image in this embodiment. As shown in Figure 38, the invoice image in this embodiment lists the amount carried over from the previous month, the amount for the current month, and the amount billed this time. Note that the details listed on the invoice image are only for the amount for the current month.

[0230] (Issued invoice information management table) Fig. 39 is a conceptual diagram showing an example of an issuance invoice information management table in this embodiment. As shown in Fig. 39, a carryover common invoice ID has been added to the issuance invoice information management table in this embodiment.

[0231] The carried-over common invoice ID is a common invoice ID used to identify the invoice issued the previous month for the details of the carried-over amount from the previous month. In the issued invoice information management table, details for which the carried-over common invoice ID is set are those carried over from the previous month.

[0232] (Received invoice information management table) 40 is a conceptual diagram showing an example of a received invoice information management table in this embodiment. As shown in FIG. 40, a carried-over common invoice ID has been added to the received invoice information management table in this embodiment.

[0233] As with the issued invoice information management table, in the received invoice information management table, it can be seen that the details for which the carryover common invoice ID is set are the amount carried over from the previous month.

[0234] (Accounts payable information management table) Fig. 41 is a conceptual diagram showing an example of an accounts payable information management table in this embodiment. As shown in Fig. 41, the accounts payable information management table with the amount carried over from the previous month stores the accounts payable information for the previous month carried over and the accounts payable information for the current month. The contents set in the accounts payable information for the amount carried over from the previous month and the accounts payable information for the current month are the same as those in the accounts receivable information management table.

[0235] (Payment processing screen) Fig. 42 is a conceptual diagram showing an example of an invoice creation screen in this embodiment. As shown in Fig. 42, the payment processing screen 2400 in this embodiment displays a detailed information display field 2440 divided into the amount carried over from the previous month and the amount for the current month.

[0236] (Payment information management table) Fig. 43 is a conceptual diagram showing an example of a payment information management table in this embodiment. As shown in Fig. 43, the payment information management table in this embodiment includes payment information for the amount carried over from the previous month.

[0237] For payment information carried over from the previous month, one payment ID is associated with multiple detail IDs for common invoice IDs. For example, payment information with a payment ID of ADB852841F8B32772 includes detail IDs "0001" and "0003" with a common invoice ID of abcd1235, and detail ID "0001" with a common invoice ID of abcd1321.

[0238] (Deposit management screen) Figure 44 is a conceptual diagram showing an example of a deposit management screen in this embodiment. As shown in Figure 44, the deposit management screen 2500 in this embodiment displays the scheduled payment date, deposit quantity, and scheduled deposit amount for the current month for the details of the amount carried over from the previous month.

[0239] For example, accounts receivable ledger information (carried over from the previous month) with an accounts receivable date of September 29, 2020, displays the expected payment date as November 25, 2020. Also, for example, accounts receivable ledger information (for the current month) with an accounts receivable date of October 15, 2020, displays the expected payment date as November 25, 2020. In other words, it can be seen that payment schedules for the same day are registered for the details of the previous month's carryover amount and the details of the current month.

[0240] [Major Effects of the Second Embodiment] The transaction management server 10 in this embodiment stores payment information that associates a payment ID that identifies a payment request with the details to be paid. Details included in different invoices can be associated with a single payment ID. Therefore, the transaction management server 10 in this embodiment can identify the details to be paid even if the details to be paid are selected from multiple invoices.

[0241] As a result, the transaction management server 10 in this embodiment can realize automatic settlement on a per-item basis even when items to be paid are selected from multiple invoices.

[0242] [supplement] In the above embodiment, the seller's invoice information is stored in the issued invoice information management table, and the buyer's invoice information is stored in the received invoice information management table. However, the transaction management server 10 may be configured to have a common invoice information management table for each tenant, allowing invoice information to be shared. This configuration allows the buyer to refer to the invoice information without having to perform operations such as receiving the invoice.

[0243] In the above embodiment, the transaction management server 10 is an example of an information processing device. The account management server 40-2 is an example of a second information processing device. The purchaser terminal 30 is an example of an information processing terminal. The seller terminal 20 is an example of a second information processing terminal. The transmitter / receiver unit 11 is an example of a transmitter or receiver. The chat area 2470 and the chat area 2530 are examples of a dialogue area.

[0244] Each function of the above-described embodiments can be realized by one or more processing circuits. Here, the term "processing circuit" in this specification includes a processor programmed to perform each function by software, such as a processor implemented by an electronic circuit, as well as devices such as an ASIC (Application Specific Integrated Circuit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), or a conventional circuit module designed to perform each function described above.

[0245] The devices described in the example are merely one of several computing environments for implementing the embodiments disclosed herein. In one embodiment, the transaction management server 10 and the account management server 40 include multiple computing devices, such as a server cluster, configured to communicate with each other via any type of communication link, including a network, shared memory, etc., and to perform the processes disclosed herein.

[0246] Although the embodiments of the present invention have been described in detail above, the present invention is not limited to these embodiments, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims. [Explanation of symbols]

[0247] 1. Information Processing Systems 10. Transaction Management Server 20 Merchant Terminal 30 Purchaser terminal 40 Account Management Server 11, 21, 31, 41 Transmitter / receiver 22,32 Reception 24,34 Display control unit 15,25,35,45 Judgment section 16,46 Creation Department 19, 29, 39, 49 Memory control unit 100,200,300,400 storage section [Prior art documents] [Patent documents]

[0248] [Patent Document 1] Japanese Patent Application Laid-Open No. 2008-9873

Claims

1. An information processing device capable of communicating with an information processing terminal used by a user via a network, a receiving unit that receives from the information processing terminal a payment request that specifies a payment item among a plurality of items included in the invoice information issued to the user; a memory control unit that stores in a memory unit identification information that identifies each payment request and that is assigned to each payment request, and payment information that associates the specified details that are associated with the invoice information; a processing unit that, when receiving payment information including the identification information, identifies the specified details from the payment information stored in the storage unit based on the identification information and performs a clearing process for the specified details; An information processing device comprising:

2. 2. The information processing device according to claim 1, a transmitting unit configured to transmit to the information processing terminal remittance data including the identification information and for remitting an amount based on the details included in the payment information to the account of the customer; Information processing device.

3. 3. The information processing device according to claim 2, the receiving unit receives deposit information including the identification information from a second information processing device that manages the account of the customer; Information processing device.

4. 4. The information processing device according to claim 3, By using the identification information to compare the deposit information with the payment information, the deposit information is cleared. Information processing device.

5. 5. The information processing device according to claim 4, the transmitting unit transmits to the information processing terminal screen data for comparing accounts payable ledger information based on the invoice information with the invoice information; Information processing device.

6. 5. The information processing device according to claim 4, the transmitting unit transmits screen data for comparing the invoice information with the payment status of the statement to a second information processing terminal used by the business partner; Information processing device.

7. 7. The information processing device according to claim 5, the screen data includes a dialogue area for dialogue between the user and the business partner; Information processing device.

8. An information processing system in which an information processing terminal used by a user and an information processing device can communicate with each other via a network, The information processing terminal a transmitting unit that transmits to the information processing device a payment request that specifies a payment target item among a plurality of items included in the invoice information issued to the user; The information processing device includes: a receiving unit that receives the payment request from the information processing terminal; a memory control unit that stores in a memory unit identification information that identifies each payment request and that is assigned to each payment request, and payment information that associates the specified details that are associated with the invoice information; a processing unit that, when receiving payment information including the identification information, identifies the specified details from the payment information stored in the storage unit based on the identification information and performs a clearing process for the specified details; An information processing system comprising:

9. A computer that can communicate with the information processing terminal used by the user via a network, a receiving step of receiving from the information processing terminal a payment request specifying a payment item among a plurality of items included in the invoice information issued to the user; a storage control procedure for storing, in a storage unit, identification information for identifying the payment request, which is assigned to each payment request, and payment information that associates the specified details associated with the invoice information; a processing procedure for, when receiving payment information including the identification information, identifying the specified details from the payment information stored in the storage unit based on the identification information and performing a clearing process for the specified details; An information processing method that performs the above.

10. A computer that can communicate with the information processing terminal used by the user via a network, a receiving step of receiving from the information processing terminal a payment request specifying a payment item among a plurality of items included in the invoice information issued to the user; a storage control procedure for storing, in a storage unit, identification information for identifying the payment request, which is assigned to each payment request, and payment information that associates the specified details associated with the invoice information; a processing procedure for, when receiving payment information including the identification information, identifying the specified details from the payment information stored in the storage unit based on the identification information and performing a clearing process for the specified details; A program to execute.

Images