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

Abstract

This makes it possible to identify the items that were subject to payment. [Solution] An information processing device that can communicate with an information processing terminal used by a user via a network includes a receiving unit that receives a payment request from the information processing terminal that identifies the details to be paid from the invoice information issued to the user, and a storage control unit that stores payment information in a storage unit that associates identification information that identifies the payment request with the details.

Description

Technical Field

[0001] This invention relates to an information processing apparatus, an information processing terminal, an information processing system, an information processing method, and a program.

Background Art

[0002] Conventionally, in the settlement process in commercial transactions, a seller collates information such as the amount of payment and the payment date included in the payment information sent from a purchaser with information such as the amount billed and the payment due date described in an invoice, and settles the accounts receivable related to the invoice. In this case, the seller checks whether the accounts receivable are collected as per the invoice and whether there is any delay in collection (see Patent Document 1).

Summary of the Invention

Problems to be Solved by the Invention

[0003] However, there is a problem that it is difficult to identify the details targeted for payment from the payment information. For example, on the purchaser's side, when paying an amount related to some of the multiple details included in an invoice, the billed amount described in the invoice and the payment amount do not match. In this case, it is necessary to confirm the details targeted for payment between the seller and the purchaser, which is a burden for both parties.

[0004] One embodiment of this invention is to enable identification of the details targeted for payment in view of the above technical problems.

Means for Solving the Problems

[0005] In order to solve the above problems, an information processing apparatus according to an embodiment of this invention is an information processing apparatus capable of communicating with an information processing terminal used by a user via a network, and includes a receiving unit that receives a payment request identifying details targeted for payment from the information processing terminal from the invoice information issued to the user, and a storage control unit that stores payment information associating identification information for identifying the payment request with the details in a storage unit.

Effects of the Invention

[0006] According to one embodiment of this invention, it becomes possible to identify the details of the payment subject to the item. [Brief explanation of the drawing]

[0007] [Figure 1] This is a conceptual diagram illustrating the relationships between the companies in one embodiment of the system. [Figure 2] This figure shows an example of the overall configuration of an information processing system in one embodiment. [Figure 3] This figure shows an example of the hardware configuration of an information processing device in one embodiment. [Figure 4] This figure shows an example of the functional configuration of an information processing system in one embodiment. [Figure 5] This figure shows an example of the invoice creation and sending process in the first embodiment. [Figure 6] This figure shows an example of a tenant information management table in the first embodiment. [Figure 7] This figure shows an example of an accounts receivable ledger information management table in the first embodiment. [Figure 8] This figure shows an example of the invoice creation screen in the first embodiment. [Figure 9] This figure shows an example of an invoice image in the first embodiment. [Figure 10] This figure shows an example of an invoice information management table in the first embodiment. [Figure 11] This figure shows an example of an accounts receivable ledger information management table in the first embodiment. [Figure 12] This figure shows an example of an invoice sending screen in the first embodiment. [Figure 13] This figure shows an example of a receipt information management table in the first embodiment. [Figure 14] This figure shows an example of the invoice receipt process in the first embodiment. [Figure 15] This figure shows an example of an invoice receipt screen in the first embodiment. [Figure 16] It is a diagram showing an example of a received invoice information management table in the first embodiment. [Figure 17] It is a diagram showing an example of a remittance data creation process in the first embodiment. [Figure 18] It is a diagram showing an example of a received invoice list screen in the first embodiment. [Figure 19] It is a diagram showing an example of an accounts payable information management table in the first embodiment. [Figure 20] It is a diagram showing an example of a payment processing screen in the first embodiment. [Figure 21] It is a diagram showing an example of a payment processing screen in Modification 1. [Figure 22] It is a diagram showing an example of an accounts payable information management table in Modification 1. [Figure 23] It is a diagram showing an example of a payment processing screen in Modification 2. [Figure 24] It is a diagram showing an example of a chat history management table in Modification 2. [Figure 25] It is a diagram showing an example of a payment information management table in the first embodiment. [Figure 26] It is a diagram showing an example of an accounts payable information management table in the first embodiment. [Figure 27] It is a diagram showing an example of a deposit information acquisition and automatic write-off process in the first embodiment. [Figure 28] It is a diagram showing an example of a deposit information management table in the first embodiment. [Figure 29] It is a diagram showing an example of an automatic write-off process in the first embodiment. [Figure 30] It is a diagram showing an example of an accounts receivable information management table in the first embodiment. [Figure 31] It is a diagram showing an example of an accounts payable information management table in the first embodiment. [Figure 32] It is a diagram showing an example of a deposit management screen creation process in the first embodiment. [Figure 33] It is a diagram showing an example of a deposit management screen in the first embodiment. [Figure 34] This figure shows an example of a deposit management screen in the first embodiment. [Figure 35] This figure shows an example of the deposit management screen in Modification Example 3. [Figure 36] This figure shows an example of an accounts receivable ledger information management table in the second embodiment. [Figure 37] This figure shows an example of the invoice creation screen in the second embodiment. [Figure 38] This figure shows an example of an invoice image in the second embodiment. [Figure 39] This figure shows an example of an invoice information management table in the second embodiment. [Figure 40] This figure shows an example of a receipt invoice information management table in the second embodiment. [Figure 41] This figure shows an example of an accounts payable ledger information management table in the second embodiment. [Figure 42] This figure shows an example of a payment processing screen in the second embodiment. [Figure 43] This figure shows an example of a payment information management table in the second embodiment. [Figure 44] This figure shows an example of a deposit management screen in the second embodiment. [Modes for carrying out the invention]

[0008] The embodiments of this invention will be described in detail below with reference to the drawings. Note that components having the same function are numbered the same in the drawings, and redundant explanations are omitted.

[0009] [First Embodiment] [Relationships between companies] The relationships between the companies in this embodiment will be explained with reference to Figure 1. Figure 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 trading partner, service user company B, and receives consideration from service user company B. In this case, service user company A, as the seller, is the creditor, and service user company B, as the buyer, is the debtor.

[0011] Service provider C is a company that, at the request of service user A, provides a service to create invoices (generate invoice information) that service user A sends to service user B. In this embodiment, the entity that uses the services provided by the service provider may be referred to as the tenant. In other words, in this embodiment, the tenant is a business, organization, or individual.

[0012] Financial institution D1 is the financial institution that manages the bank account of service user company B. Financial institution D2 is the financial institution that manages the bank account of service user company A. Note that it is not limited to financial institutions; it may also be a payment collection agency that manages accounts through a direct debit service.

[0013] Here, we will briefly describe the processing in this embodiment. Note that the IDs described later are examples of identification information.

[0014] First, service user company A requests service provider company C to create (generate) and send an invoice to service user company B (Step S1). As a result, service user company B receives the invoice from service user company A via service provider company C (Step S2).

[0015] Service user B sends a payment request to service provider C specifying the items to be paid (Step 3-1). Service provider C then creates remittance data including a payment ID that identifies the payment request and sends it to service user B (Step S3-2). This remittance data is used for remittances based on invoices from the buyer's (service user B's) bank account to the seller's (service user A's) bank account. In other words, service provider C creates the remittance data that service user B will use when making a remittance, and furthermore, it includes a payment ID in the remittance data during its creation.

[0016] Next, service user company B sends remittance data, which includes the payment ID, to financial institution D1 (step S4-1). As a result, financial institution D1 sends the amount specified in the remittance data to financial institution D2, where service user company A's bank account is managed (step S4-2). At this time, the payment ID is also sent from financial institution D1 to financial institution D2 along with the remittance data.

[0017] Next, after financial institution D2 confirms the deposit into service user company A's bank account, it sends deposit information (information such as deposit source, deposit amount, deposit date, etc.), including the deposit details and payment ID, to service provider company C. As a result, service provider company C obtains the deposit information (step S5).

[0018] Next, service provider C identifies the details of the invoice that were paid based on the payment ID included in the payment information and performs reconciliation processing for those details (step S6). Even if a remittance is made based on only a portion of the details included in the invoice, the details that were paid can be identified by the payment ID, and it is possible to verify whether the invoiced amount and the received amount for those details match. Therefore, even if payments are made on an item-by-item basis within the invoice, reconciliation can be performed automatically.

[0019] [Overall configuration of the information processing system] The overall configuration of the information processing system in this embodiment will be described with reference to Figure 2. Figure 2 is a block diagram showing an example of the overall configuration of the information processing system in 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 buyer terminal 30, and two account management servers 40. The transaction management server 10, seller terminal 20, buyer terminal 30, and account management servers 40 are each connected to a communication network N1.

[0021] The communication network N1 is configured so that each connected device can communicate with one another. The communication network N1 is constructed using wired communication networks 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 such as Wi-Fi 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 user company A (seller). The buyer terminal 30 is installed at service user company B (buyer). The transaction management server 10 is installed at service provider company C. The buyer'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 buyer terminal 30 may be, for example, output devices such as PJ (Projector), IWB (Interactive White Board), digital signage, HUD (Head Up Display) devices, industrial machinery, imaging devices, sound collection devices, medical equipment, networked home appliances, automobiles (Connected Car), notebook PCs (Personal Computers), mobile phones, smartphones, tablet devices, game consoles, PDAs (Personal Digital Assistants), digital cameras, wearable PCs, or desktop PCs.

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

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

[0027] Of these components, 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 the work area for the CPU 501. The HD 504 stores various data, such as programs. The HDD controller 505 controls the reading or writing of various data to the HD 504 according to the control of the CPU 501.

[0028] Display 506 displays various information such as cursors, menus, windows, characters, or images. External device connection I / F 508 is an interface for connecting various external devices. In this case, external devices include, for example, USB (Universal Serial Bus) memory and printers. Network I / F 509 is an interface for data communication using the communication network N1. Bus line 510 is an address bus, data bus, etc., for electrically connecting various components such as the CPU 501 shown in Figure 3.

[0029] The keyboard 511 is a type of input means equipped with multiple keys for inputting characters, numbers, and various instructions. The pointing device 512 is a type of input means for selecting and executing various instructions, selecting processing targets, and moving the cursor. The DVD-RW drive 514 controls the reading or writing of various data to the DVD-RW 513, which is an example of a removable recording medium. Note that it is not limited to DVD-RW, but may also be DVD-R, etc. The media interface 516 controls the reading or writing (storage) of data to the recording medium 515, such as flash memory.

[0030] [Functional Configuration of Information Processing Systems] The functional configuration of the information processing system in this embodiment will be described with reference to Figure 4. Figure 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 Figure 4, the transaction management server 10 in this embodiment comprises a transmission / reception unit 11, a generation unit 14, a determination unit 15, a creation unit 16, a memory control unit 19, and a memory unit 100. Each of these units is a function or means of functioning, realized by any of the components shown in Figure 3 operating according to instructions from the CPU 501 following a program deployed from the HD 504 onto the RAM 503. The memory unit 100 is constructed from the RAM 503 and HD 504 shown in Figure 3.

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

[0033] The generation unit 14 is implemented by instructions from the CPU 501 shown in Figure 3, and generates predetermined data (information). The details of the generated data will be described later.

[0034] The decision unit 15 is implemented by instructions from the CPU 501 shown in Figure 3 and performs a predetermined decision. The details of the decision will be described later.

[0035] The creation unit 16 is implemented by instructions from the CPU 501 shown in Figure 3, and performs tasks such as creating the various screens and URLs for each screen, as described later.

[0036] The memory control unit 19 is implemented by instructions from the CPU 501 shown in Figure 3 and the HDD controller 505, and performs processing such as storing various data in the memory unit 100 and reading various data stored in the memory unit 100.

[0037] The storage unit 100 contains a tenant information management database, an accounts receivable ledger information management database, an accounts payable ledger information management database, an issued invoice information management database, a received information management database, a received invoice information management database, a payment information management database, and a deposit information management database.

[0038] The tenant information management database consists of tenant information management tables. These tables store information about service user companies A and B, which are tenants of the transaction management server 10. Details of the tenant information management tables will be described later.

[0039] The accounts receivable information management database consists of accounts receivable information management tables for each tenant. These tables store accounts receivable information based on sales information from the seller (service user company A) to the buyer (service user company B). Accounts receivable information can 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 on the transaction management server 10 may be used. Details of the accounts receivable information management tables will be described later.

[0040] The accounts payable information management database consists of accounts payable information management tables for each tenant. These tables store accounts payable information based on delivery information from the seller (service user company A) to the buyer (service user company B). Accounts payable information can 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 on the transaction management server 10 may be used. Details of the accounts payable information management tables will be described later.

[0041] The invoice information management database consists of invoice information management tables for each tenant. These tables store invoice information related to invoices issued by the seller (service user company A) to the buyer (service user company B). Details of the invoice information management tables will be described later.

[0042] The receipt information management database consists of receipt information management tables for each tenant. These tables store receipt information for the purchaser (service user company B) to receive invoices. Details of the receipt information management tables will be described later.

[0043] The received invoice information management database consists of a separate invoice information management table for each tenant. The issued invoice information management table stores invoice information related to invoices received by the buyer (service user company B) from the seller (service user company A). Details of the received invoice information management table will be described later.

[0044] The payment information management database consists of payment information management tables for each tenant. These tables store payment information sent by the buyer (service user company B) to the seller (service user company A). Details of the payment information management tables will be described later.

[0045] The payment information management database consists of payment information management tables for each tenant. These tables store payment information transferred to the seller's (service user company A) account. Details of the payment information management tables will be described later.

[0046] <Functional Configuration of the Seller's Terminal> As shown in Figure 4, the seller terminal 20 in this embodiment comprises a transmitting / receiving unit 21, a receiving unit 22, a display control unit 24, a determination unit 25, a memory control unit 29, and a memory unit 200. Each of these units is a function or means of functioning, realized by any of the components shown in Figure 3 operating according to instructions from the CPU 501 in accordance with a program deployed from the HD 504 onto the RAM 503. The memory unit 200 is constructed from the RAM 503 and HD 504 shown in Figure 3.

[0047] The transmitting / receiving unit 21 is implemented by commands from the CPU 501 shown in Figure 3, as well as the external device connection I / F 508 and 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 mainly implemented by commands from the CPU 501 shown in Figure 3, as well as the keyboard 511 and pointing device 512, and accepts various inputs from the user.

[0049] The display control unit 24 is primarily implemented by instructions from the CPU 501 shown in Figure 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 also has a web browser function.

[0050] The decision unit 25 is mainly implemented by instructions from the CPU 501 shown in Figure 3, and performs various decisions.

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

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

[0053] The transceiver unit 31, reception unit 32, display control unit 34, determination unit 35, memory control unit 39, and memory unit 300 of the purchaser terminal 30 have the same functions as the transceiver unit 21, reception unit 22, display control unit 24, determination unit 25, memory control unit 29, and memory unit 200 of the seller terminal 20, so their explanation is omitted.

[0054] <Functional Configuration of Account Management Server> As shown in Figure 4, the account management server 40 in this embodiment includes a transmitting / receiving unit 41, a determination unit 45, a creation unit 46, a memory control unit 49, and a memory unit 400. Each of these units is a function or means of functioning, realized by any of the components shown in Figure 3 operating according to instructions from the CPU 501 following a program deployed from the HD 504 onto the RAM 503. The memory unit 400 is constructed from the RAM 503 and HD 504 shown in Figure 3.

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

[0056] The decision unit 45 is implemented by instructions from the CPU 501 shown in Figure 3 and performs a predetermined decision. The details of the decision will be described later.

[0057] The creation unit 46 is implemented by instructions from the CPU 501 shown in Figure 3, and performs tasks such as creating the screen.

[0058] The memory control unit 49 is implemented by instructions from the CPU 501 shown in Figure 3 and the HDD controller 505, and performs processing such as storing various data in the memory unit 400 and reading various data stored in the memory unit 400.

[0059] The account management server 40 may be a server device provided by a financial institution, or a server device provided by a predetermined service that cooperates with a financial institution's system.

[0060] [Processing procedures for information processing systems] The processing procedure of the information processing method executed by the information processing system in this embodiment will be described with reference to Figures 5 to 35.

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

[0062] In step S11, the reception unit 22 of the seller terminal 20 receives an operation from the seller to display the invoice creation screen. The seller is, for example, a person in charge of performing duties for service user company A.

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

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

[0065] As shown in Figure 6, in this embodiment, the tenant information management table 1000 manages tenant information (company name, etc.), authentication information (user ID and password, etc.), contact information (email address and address, etc.), and bank account information for transfers in an associated manner.

[0066] In this embodiment, tenants can use the service as both sellers and buyers. However, by registering user roles representing sellers or buyers as tenant information, it is possible to restrict specific tenants to using the service as either sellers or buyers only.

[0067] Let's return to Figure 5 for explanation. In step S12, the transmitting / receiving unit 21 of the seller terminal 20 sends a request to the transaction management server 10 to retrieve the invoice creation screen. The transaction management server 10 receives the request to retrieve the invoice creation screen from the seller terminal 20 via its transmitting / receiving unit 11.

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

[0069] (Accounts Receivable Ledger Information Management Table) Here, the details of the accounts receivable ledger information management table will be explained with reference to Figure 7. Figure 7 is a conceptual diagram showing an example of the accounts receivable ledger 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 accounts receivable were incurred (hereinafter also referred to as "accounts receivable 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) are managed in association with each other.

[0071] The example of accounts receivable ledger information shown in Figure 7 represents the initial state after importing from the accounts receivable ledger. In the initial state, each identification information (common invoice ID, invoice ID, and item ID) and payment information (payment quantity and payment amount) are blank.

[0072] Let's return to Figure 5 for explanation. In step S14, the transmit / receive unit 11 of 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. On the seller terminal 20, the transmit / receive 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 of the seller terminal 20 displays the invoice creation screen on the display 506 based on the screen data of the invoice creation screen.

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

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

[0076] In the Condition Setting Area 2010, entering conditions such as the billing recipient, billing closing date, and billing period will display accounts receivable ledger information that matches those conditions in the Accounts Receivable Ledger Display Area 2020. The condition values ​​displayed in the Condition Setting Area 2010 can be set in advance. For example, the billing period can 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 in a format where each item can be selected. For example, by displaying a checkbox for each item, that item can be made selectable. In the initial state, all items are selected.

[0078] When the seller presses the Create button 2008, the Reception 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] Let's return to Figure 5 for explanation. In step S16, the reception unit 22 of the seller terminal 20 receives the seller's operation to create an invoice (generate invoice information). Specifically, the seller selects the items to be included in the invoice on the invoice creation screen 2000 and presses the create button 2008.

[0080] In step S17, the transmitting / receiving unit 21 of the seller terminal 20 sends a request to register invoice information to the transaction management server 10. This registration request includes the accounts receivable information selected in the accounts receivable display area 2020. The transmitting / receiving unit 11 of the transaction management server 10 receives the request to register invoice information from the seller terminal 20.

[0081] In step S18, the creation unit 16 of the transaction management server 10 generates an invoice image as shown in Figure 9 based on the request to register 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 the receipt screen for receiving the invoice.

[0082] Next, the memory control unit 19 generates invoice information representing 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 ledger information management DB based on the generated invoice information. At this time, the memory control unit 19 issues a common invoice ID and an invoice ID to identify the invoice, as well as a detail ID to identify each detail.

[0083] The common invoice ID is identification information that the transaction management server 10 sets for each invoice information for common management across all tenants. The invoice ID is identification information that tenants arbitrarily set for their 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 the invoice ID so that it does not overlap between tenants, the invoice ID may be used instead of the common invoice ID.

[0084] (Invoice Information Management Table) Here, the details of the invoice information management table will be explained with reference to Figure 10. Figure 10 is a conceptual diagram showing an example of the invoice information management table 1300 in this embodiment.

[0085] As shown in Figure 10, the invoice information management table in this embodiment manages the following information in association with each other: identification information to identify an invoice (common invoice ID and invoice ID, etc.), information representing the recipient of the invoice (name of the recipient company, etc.), invoice amount, invoice date, payment due date, invoice status, invoice image storage location, details information (details ID, product code, product name, unit price, quantity and amount, etc.), and bank transfer information.

[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 terms corresponding to the buyer. For example, if the buyer has a payment term of 30 days, the payment due date will be the end of the following month. Also, for example, if the buyer has a payment term of 60 days, the payment due date will be the end of the month after next. The invoice status is set to "Created". Bank transfer information is obtained from the tenant information management table.

[0087] Figure 11 shows an example of an accounts receivable ledger information management table after invoice creation. As shown in Figure 11, in the accounts receivable ledger information management table after invoice creation, the common invoice ID, invoice ID, and item ID are registered for the accounts receivable ledger information for which the invoice was issued.

[0088] Let's return to Figure 5 for explanation. In step S19, the reception unit 22 of the seller terminal 20 receives the seller's operation to send an invoice. The operation to send an invoice is performed on the invoice sending screen. The invoice sending screen is displayed, for example, by selecting the invoice to be sent on the screen that displays a list of created invoices.

[0089] (Invoice submission screen) Here, the invoice sending screen in this embodiment will be described with reference to Figure 12. Figure 12 is a conceptual diagram showing an example of the invoice sending screen in this embodiment.

[0090] As shown in Figure 12, the invoice sending screen 2100 in this embodiment includes a recipient selection field 2101, an invoice image display field 2102, a cover letter input field 2103, a send button 2108, and a cancel button 2109.

[0091] Of these, the recipient selection field 2101 displays the email address associated with the purchaser in the tenant information management table, making it selectable. The invoice image display field 2102 displays the invoice image indicated by the invoice image storage location in the issued invoice information management table.

[0092] The cover letter input field 2103 is where you enter the subject and body of the invoice to be sent. Ideally, a predefined template should be displayed initially for the subject and body. The cover letter input field 2103 should also contain an embedded link to the receipt screen URL.

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

[0094] Let's return to Figure 5 for explanation. In step S20, the transmitting / receiving unit 21 of the seller terminal 20 sends an invoice delivery request to the transaction management server 10. This delivery request includes a common invoice ID. The transmitting / receiving unit 11 of the transaction management server 10 receives the invoice delivery request from the seller terminal 20.

[0095] In step S21, the memory control unit 19 of the transaction management server 10 identifies the 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 memory control unit 19 of the transaction management server 10 generates receipt information based on the invoice sending request and registers it in the receipt information management DB.

[0097] (Receipt Information Management Table) Here, the details of the receipt information management table will be explained with reference to Figure 13. Figure 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 that identifies the invoice (common invoice ID and invoice ID, etc.), information representing the issuer of the invoice (issuer company name, etc.), issue date, and receipt screen URL are managed in association with each other.

[0099] Let's return to Figure 5 for explanation. In step S23, the sending / receiving unit 11 of the transaction management server 10 sends an email containing the receipt screen URL to the buyer's terminal 30. Note that the sending / receiving unit 11 does not have to send the email containing the receipt screen URL directly to the buyer's terminal 30. For example, the sending / receiving unit 11 may send an email to a designated email address on the buyer's side, and the buyer's terminal 30 may receive the email from the mail server.

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

[0101] <Invoice receipt processing> Next, the invoice receipt process in this embodiment (step S2 in Figure 1) will be explained with reference to Figure 14. Figure 14 is a sequence diagram showing an example of the invoice receipt process in this embodiment.

[0102] In step S31, the send / receive unit 31 of the purchaser terminal 30 receives an email containing a receipt screen URL. Next, the reception unit 32 receives the purchaser's operation to display the invoice receipt screen. The purchaser is, for example, a person in charge of performing the duties of service user company B. The operation to display the invoice receipt screen is, for example, the operation to open the receipt screen URL included in the email (i.e., the operation to click the receipt screen URL link in the email).

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

[0104] In step S33, the memory control unit 19 of the transaction management server 10 reads 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 acquire the invoice receipt screen. Next, the memory control unit 19 reads invoice information from the issued invoice information management DB using the issued invoice information management table 1300 based on the common invoice ID included in the read receipt information. Subsequently, the creation unit 16 creates screen data for the invoice receipt screen based on the receipt information and invoice information read by the memory control unit 19.

[0105] In step S34, the transmit / receive unit 11 of the transaction management server 10 sends the screen data of the invoice receipt screen created by the creation unit 16 to the buyer terminal 30. The transmit / receive unit 31 of the buyer terminal 30 receives the screen data of the invoice receipt screen from the transaction management server 10.

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

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

[0108] As shown in Figure 15, the invoice receipt screen 2200 in this embodiment has an invoice image display field 2201, a download button 2202, and a receive 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 accepts the invoice receipt operation.

[0111] Let's return to Figure 14 for explanation. In step S36, the reception unit 32 of the purchaser terminal 30 receives the purchaser's request to receive the invoice. Specifically, the purchaser presses the receive button 2203 on the invoice receipt screen 2200.

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

[0113] In step S38, the memory control unit 19 of the transaction management server 10 identifies the 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 memory control unit 19 of the transaction management server 10 registers the invoice information identified in the issued invoice information management table into the received invoice information management DB.

[0115] (Invoice Information Management Table) Here, the details of the invoice information management table will be explained with reference to Figure 16. Figure 16 is a conceptual diagram showing an example of the invoice information management table in this embodiment.

[0116] As shown in Figure 16, the received invoice information management table 1500 in this embodiment manages the following information in association: identification information to identify the invoice (common invoice ID and invoice ID, etc.), information representing the recipient of the invoice (name of the recipient company, etc.), invoice amount, invoice date, payment due date, invoice image storage location, details information (details ID, product code, product name, unit price, quantity, amount, etc.), and bank transfer information. 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 in this embodiment (step S3 in Figure 1) will be described with reference to Figure 17. Figure 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 from the purchaser to display the payment processing screen. The operation to display the payment processing screen is performed on the receipt invoice list screen.

[0119] (List of received invoices screen) Here, the invoice list screen in this embodiment will be described with reference to Figure 18. Figure 18 is a conceptual diagram showing an example of the 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 (billing source, invoice number, total amount, issue date, etc.). Each invoice displayed in the invoice list display field 2301 has a display button 2302, a download button 2303, and a payment processing button 2304.

[0121] When the buyer presses the display button 2302, the invoice image corresponding to the invoice is displayed on the display 506. When the buyer 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 buyer presses the payment processing button 2304, the reception unit 32 accepts the operation to display the payment processing screen.

[0122] Let's return to Figure 17 for explanation. In step S42, the transmitting / receiving unit 31 of the purchaser terminal 30 sends a request to the transaction management server 10 to retrieve the payment processing screen. This request includes a common invoice ID. The transaction management server 10 receives the request to retrieve the payment processing screen from the purchaser terminal 30 via its transmitting / receiving unit 11.

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

[0124] (Accounts Payable Ledger Information Management Table) Here, the details of the accounts payable ledger information management table will be explained with reference to Figure 19. Figure 19 is a conceptual diagram showing an example of the accounts payable ledger information management table in this embodiment.

[0125] As shown in Figure 19, in the accounts payable information management table of this embodiment, the date on which accounts payable were incurred (hereinafter also referred to as "accounts payable date"), identification information for identifying invoices (common invoice ID and invoice ID, etc.), information regarding the details in the invoice (item ID, product code, unit price, quantity, amount, etc.), and information regarding payment (payment quantity and payment amount) are managed in association with each other.

[0126] The example of accounts payable ledger information shown in Figure 19 represents the initial state after importing from the accounts payable ledger. In the initial state, each identification information (common invoice ID, invoice ID, and item ID) and payment information (payment quantity and payment amount) are blank.

[0127] Let's return to Figure 17 for explanation. In step S44, the transmit / receive unit 11 of the transaction management server 10 transmits the payment processing screen data created by the creation unit 16 to the buyer terminal 30. The buyer terminal 30 receives the payment processing screen data from the transaction management server 10 via the transmit / receive unit 31.

[0128] In step S45, the display control unit 34 of 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 Figure 20. Figure 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 includes a condition setting area 2410, an accounts payable information display area 2420, an invoice information display area 2430, a detail information display area 2440, a quantity input button 2441, a payment information display area 2450, a create button 2408, and a cancel button 2409.

[0131] In the condition setting area 2410, when conditions such as the payment closing date and payment period are entered, accounts payable ledger information that matches those conditions is displayed in the accounts payable ledger information display area 2420. The condition values ​​displayed in the condition setting area 2410 may be set in advance. For example, the payment period can 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 area 2430 displays the contents of the invoice (invoice ID, invoice amount, invoice date, and payment due date, etc.). The item information display area 2440 displays information about the item included in the invoice (product name, quantity, unit price, and amount, etc.) in a format that allows users to select each item.

[0133] In the details display section 2440, each item included in the accounts payable ledger information and invoice information is compared. Items included in both the accounts payable ledger information and invoice information are automatically selected. In this case, if the quantity in the accounts payable ledger information and the quantity in the invoice information do not match, both quantities are displayed so that they can be understood. For example, it can be displayed in the format "Quantity in accounts payable ledger information / Quantity in invoice information".

[0134] One quantity input button 2441 is displayed for each item shown in the item information display field 2440. When a quantity input button 2441 is pressed, a dialog box for entering the quantity appears, allowing the user to enter the quantity to be paid for that item.

[0135] Furthermore, the quantity input buttons 2441 corresponding to items not selected in the item details display field 2440 may be disabled.

[0136] The payment information display field 2450 shows the bank transfer details included in the invoice information. The payment date in the payment information display field 2450 is automatically entered based on a pre-set rule (for example, the 25th of the following month). However, the buyer can also manually correct it.

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

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

[0139] Figure 21 is a conceptual diagram showing an example of a payment processing screen 2400 that displays return information. The payment processing screen 2400 shown in Figure 21 further has a return information display field 2460. The return information to be displayed in the return 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 where return information is stored. The accounts payable information management table shown in Figure 22 includes accounts payable information representing returns. In accounts payable information representing returns, the quantity and amount are set to negative (△), and the remarks are set to "Return".

[0141] This example illustrates how to display return information on the payment processing screen. However, other information may be displayed if the invoice amount is negative. For example, accounts payable information where the quantity and amount are set to negative due to discounts or defective products may be displayed.

[0142] [Variation 2: Payment processing screen with chat function] On payment processing screen 2400, there are times when a buyer may want to inquire about the details of a payment from the seller. Specifically, this might occur, for example, if it is discovered that some items or quantities listed on the invoice have not been delivered, or if the buyer wants to confirm who will bear the bank transfer fees.

[0143] For cases like those described above, the payment processing screen 2400 may include a chat function for the buyer to inquire about the billing details with the seller. Figure 23 is a conceptual diagram showing an example of a payment processing screen 2400 with a chat function.

[0144] As shown in Figure 23, the payment processing screen 2400 with chat functionality further includes an inquiry button 2442 and a chat area 2470.

[0145] One inquiry button 2442 is displayed for each item shown in the item information display area 2440. When an inquiry button 2442 is pressed, a message for making an inquiry about that item is entered into the chat area 2470. This message automatically includes information shared between the seller and the buyer, such as the invoice ID.

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

[0147] The chat history management database consists of chat history management tables. These tables store the history of inquiries made between the seller (service user company A) and the buyer (service user company B).

[0148] Figure 24 is a conceptual diagram showing an example of a chat history management table in this embodiment. As shown in Figure 24, the chat history management table 1800 in this embodiment manages the chat date and time, identification information that identifies the subject of the inquiry (payment ID, common invoice ID, invoice ID, and item ID), information representing the sender (billing company or billing recipient), and the content of the message, etc., in association with each other.

[0149] This example illustrates how sellers and buyers can communicate via chat, but the means by which sellers and buyers can communicate are not limited to chat. Any means that allows sellers and buyers to communicate is acceptable, such as a function that enables voice or video calls over the internet.

[0150] Let's return to Figure 17 for explanation. In step S46, the reception unit 32 of the purchaser terminal 30 accepts the purchaser's operation to create remittance data. Specifically, the purchaser selects the details to be included in the remittance data on the payment processing screen 2400 and presses the create button 2408.

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

[0152] In step S48, the creation unit 16 issues a payment ID that identifies the payment based on the request to create 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. Alternatively, it may be embedded in a specific item (e.g., remarks) in the transaction details of the Zengin EDI system.

[0153] The payment ID does not necessarily have to be issued by the transaction management server 10. For example, the payment information ID issued by 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 the remittance data.

[0155] (Payment Information Management Table) Here, the details of the payment information management table will be explained with reference to Figure 25. Figure 25 is a conceptual diagram showing an example of the payment information management table in this embodiment.

[0156] As shown in Figure 25, in the payment information management table 1600 of this embodiment, information representing the content of the remittance data (payment ID, payment amount, and scheduled payment date, etc.), identification information identifying the invoice (common invoice ID and invoice ID, etc.), and information related to the details (details ID, quantity, and amount, etc.) are managed in association with each other.

[0157] Figure 26 shows an example of an accounts payable ledger information management table after the creation of remittance data. As shown in Figure 26, in the accounts payable ledger information management table after the creation of remittance data, the common invoice ID, invoice ID, and item ID are registered in the accounts payable information from which the remittance data was created.

[0158] Let's return to Figure 17 for explanation. In step S50, the transceiver unit 11 of the transaction management server 10 sends the remittance data, which has the payment ID embedded in it, to the buyer terminal 30.

[0159] Subsequently, the buyer instructs the financial institution D1 to execute the transfer using the downloaded transfer data, following the prescribed procedure. For example, the buyer instructs the transfer by uploading the transfer data through a designated screen provided by financial institution D1, such as a corporate banking or internet banking service that manages the account of service user company B. Then, financial institution D1, which manages the account of service user company B, transfers the amount according to the transfer data to financial institution D2, which manages the account of service user company A, and also transmits information such as the payment ID included in the transfer data to financial institution D2. As a result, the seller can obtain the deposit information, including the payment ID, from financial institution D2.

[0160] Furthermore, remittances based on remittance data are not limited to being conducted through financial institutions. For example, remittances may be made through services such as online payment services. In this case, for example, service provider C may send a two-dimensional code indicating the remittance data to the purchaser, and the purchaser can make the remittance by having the purchaser's terminal 30 read the two-dimensional code through the application of the online payment service or similar service installed on the purchaser's terminal 30.

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

[0162] In step S61, the transceiver unit 11 of the transaction management server 10 sends a request to the account management server 40-2 to acquire deposit information. The account management server 40-2 is the account management server 40 that manages the accounts of service user 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's terminal 20 in response to an operation by the seller, or it may be every predetermined time interval (for example, every 30 minutes).

[0164] In step S62, the transmitting / receiving unit 41 of the account management server 40-2 transmits deposit information regarding the account of service user company A to the transaction management server 10. This deposit information includes a payment ID. The transmitting / receiving unit 11 of the transaction management server 10 receives the deposit information from the account management server 40-2.

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

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

[0167] In step S62, the memory control unit 19 of 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 explained with reference to Figure 28. Figure 28 is a conceptual diagram showing an example of a deposit information management table in this embodiment.

[0169] As shown in Figure 28, in this embodiment, the deposit information management table 1700 manages the transaction date, withdrawal amount (payment amount), information representing the payee, deposit amount (amount received), information representing the sender, balance, payment ID, and reconciliation status in an associated manner. In the initial state, the reconciliation status field is blank.

[0170] Let's return to Figure 27 for explanation. In step S64, the transaction management server 10 performs an automatic reconciliation process based on the deposit information and payment information.

[0171] Automatic reconciliation process Here, the details of the automatic reconciliation process in this embodiment (step S64 in Figure 27) will be explained with reference to Figure 29. Figure 29 is a flowchart showing an example of the automatic reconciliation process in this embodiment.

[0172] In step S64-1, the memory control unit 19 retrieves unprocessed payment information from the payment information management DB. Unprocessed payment information refers to payment information for which the reconciliation status in the payment information management table is blank.

[0173] Steps S64-2 through S64-8 are performed for each of the unprocessed deposit information obtained in step S64-1.

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

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

[0176] In step S64-4, the determination unit 15 determines whether the payment amount in the payment information matches the amount received in the deposit information. If the payment amount and the amount received match (YES), the determination unit 15 proceeds to step S64-5. If the payment amount and the amount received do not match (NO), the determination 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. The generated accounts receivable ledger information has the accounts receivable date set to the transaction date of the deposit information, and the common invoice ID, invoice ID, item ID, deposit quantity, and deposit amount are set to the common invoice ID, invoice ID, item ID, quantity, and amount of the payment information.

[0178] In step S64-6, the memory control unit 19 updates the settlement status of the deposit information management table to settled. After that, the memory control unit 19 finishes processing the deposit information and returns to step S64-2.

[0179] In step S64-7, the memory control unit 19 updates the reconciliation status of the deposit information management table to an amount mismatch. After that, the memory control unit 19 terminates processing for the deposit information and returns to step S64-2.

[0180] In step S64-8, the memory control unit 19 updates the settlement status of the deposit information management table to manual settlement. After that, the memory control unit 19 finishes processing the deposit information and returns to step S64-2.

[0181] Figure 30 shows an example of an accounts receivable ledger information management table after automatic reconciliation. As shown in Figure 30, in the accounts receivable ledger information management table after automatic reconciliation, records have been added where the common invoice ID, invoice ID, and item ID match, and where the payment quantity and payment amount have been set.

[0182] Figure 31 shows an example of an accounts payable ledger information management table after automatic reconciliation. As shown in Figure 31, in the accounts payable ledger information management table after automatic reconciliation, records have been added where the common invoice ID, invoice ID, and item ID match, and where the payment quantity and payment amount have been set.

[0183] Note that the registration of payment quantities and amounts in the accounts payable ledger information management table is not performed by the automatic reconciliation process. The purchaser manually registers the accounts payable ledger information with the payment quantities and amounts set by operating the purchaser terminal 30.

[0184] However, the transaction management server 10 may be configured to refer to the payment information management table on the due date and automatically register the information in the accounts payable ledger information management table once payment is confirmed. Specifically, the payment information management table can be used to retrieve payment information for the current due date, and accounts payable ledger information with the common invoice ID, item ID, quantity, and amount set can be registered in the accounts payable ledger information management table.

[0185] Let's return to Figure 27 for explanation. In step S65, the reception unit 22 of the seller terminal 20 receives an operation from the seller to display the deposit management screen. The operation to display the deposit management screen is performed, for example, on the main menu screen provided by the transaction management server 10.

[0186] In step S66, the transmitting / receiving unit 21 of the seller terminal 20 sends a request to the transaction management server 10 to retrieve the payment management screen. This request includes the billing period. The billing period may be from the day after the billing closing date of the previous month to the billing closing date of the current month, or it may be specified in the display operation of the payment management screen. The transaction management server 10 receives the request to retrieve the payment management screen from the seller terminal 20 via the transmitting / receiving unit 11.

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

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

[0189] ≪Process for creating the deposit management screen≫ Here, the details of the process for creating the deposit management screen in this embodiment (step S67 in Figure 27) will be explained with reference to Figure 32. Figure 32 is a flowchart showing an example of the process for creating the deposit management screen in this embodiment.

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

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

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

[0193] In step S67-3, the memory control unit 19 retrieves second accounts receivable ledger information from the accounts receivable ledger information management DB based on the common invoice ID and item ID obtained in step S67-2. The second accounts receivable ledger information is accounts receivable ledger information in which the common invoice ID and item ID are the same as the first accounts receivable ledger information, and in which the payment quantity and payment amount are set.

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

[0195] In step S67-5, the creation unit 16 retrieves the accounts receivable date, payment quantity, and payment amount from the second accounts receivable ledger information obtained in step S67-3. The retrieved accounts receivable date is displayed as the payment date on the payment management screen.

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

[0197] In step S67-7, the creation unit 16 decides to highlight the first accounts receivable ledger information as requiring attention. The highlighting can be done in any way, for example, by changing the background color, changing the text color, or displaying it in bold. After that, the creation unit 16 finishes processing the first accounts receivable ledger information and returns to step S67-2.

[0198] In step S67-8, the creation unit 16 sets the invoice status displayed on the payment management screen to "Not Issued".

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

[0200] In step S67-10, the memory control unit 19 retrieves invoice information from the issued invoice information management DB based on the common invoice ID obtained in step S67-2. Next, the memory control unit 19 retrieves payment information from the payment information management DB based on the common invoice ID.

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

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

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

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

[0205] In step S67-15, the determination unit 15 determines whether the quantity and amount in the first accounts receivable ledger information match the quantity and amount in the payment information. If the quantity and amount match (YES), the determination unit 15 terminates processing for the first accounts receivable ledger information and returns to step S67-2. If the quantity and amount do not match (NO), the determination 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 obtained in steps S67-1 to S67-15.

[0207] Let's return to Figure 27 for explanation. In step S68, the transmitting / receiving unit 11 of 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. The transmitting / receiving unit 21 of the seller terminal 20 receives the screen data of the deposit management screen from the transaction management server 10.

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

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

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

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

[0212] The "Details Confirmation" button 2521 is displayed for each deposit information item shown in the deposit information display field 2520. When the "Details Confirmation" button 2521 is pressed, a screen displaying the details of the deposit information is shown. The "Details Confirmation" button 2521 can be used to check details if the amount in the details does not match the expected deposit amount or the actual deposit amount.

[0213] Furthermore, the detailed confirmation button 2521 corresponding to payment information for which information regarding the expected payment (expected payment date, expected payment quantity, and expected payment amount) or payment information (payment date and payment amount) is not displayed may be controlled to be hidden.

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

[0215] [Variation 3: Deposit management screen with chat function] In the payment management screen 2500, there are times when the seller may want to inquire about the details of a payment from the buyer. Specifically, this may occur, for example, when the amount billed on the invoice differs from the expected payment amount or the actual payment received, or when the transfer fee, which should have been borne by the buyer, was instead paid by the seller and the amount received was the amount minus the transfer fee.

[0216] For cases like those described above, the payment management screen 2500 may include a chat function, similar to the payment processing screen 2400, for the seller to inquire about the payment details from the buyer. Figure 35 is a conceptual diagram showing an example of a payment management screen 2500 with a chat function.

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

[0218] One inquiry button 2522 is displayed for each payment information item shown in the payment information display area 2520. When the inquiry button 2522 is pressed, a message for inquiring about that payment is entered into the chat area 2530. This message automatically includes information shared between the seller and buyer, such as the payment ID.

[0219] [Main effects of the first embodiment] In this embodiment, when the transaction management server 10 receives a payment request specifying the details from the purchaser terminal 30, it stores payment information that associates the payment ID identifying the payment request with the details to be paid for. Therefore, according to the transaction management server 10 in this embodiment, the details to be paid for can be identified.

[0220] In particular, the transaction management server 10 in this embodiment transmits remittance data with an embedded payment ID to the buyer terminal 30. When the buyer 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 that are subject to payment based on the deposit information. As a result, the transaction management server 10 in this embodiment can achieve automatic reconciliation at the detail level by matching deposit information with payment information.

[0221] Furthermore, the transaction management server 10 in this embodiment provides a chat function that allows inquiries between the seller and the buyer on the payment processing screen for creating remittance data and the deposit management screen for checking the deposit status. This chat function allows information necessary for inquiries to be embedded in the message. Therefore, with the transaction management server 10 in this embodiment, the seller or buyer can efficiently inquire with the other party if there are any unclear points regarding the billing details or deposit details.

[0222] [Second Embodiment] In the first embodiment, an example was described in which automatic reconciliation was performed on an item-by-item basis for the invoice for the current month. In the second embodiment, an example was described in which automatic reconciliation was performed on an item-by-item basis for an invoice that includes unbilled items from the previous month and carries over from the previous month.

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

[0224] (Accounts Receivable Ledger 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 for the previous month and accounts receivable ledger information for the current month. Accounts receivable ledger information for the previous month is for accounts receivable dates from the previous month (in this case, from September 1st to September 30th, 2020), and for which no accounts receivable ledger information with set payment quantities and amounts exists.

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

[0226] Furthermore, the accounts receivable ledger information with the common invoice ID abcd1321 for October 15, 2020 and October 30, 2020 is for the current month. Therefore, the total amount due for the current month is 1,210,000 yen, which is the sum of the previous month's balance of 880,000 yen and the current month's balance of 330,000 yen.

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

[0228] The previous month's balance display area 2021 is the same as the accounts receivable ledger display area 2020 in the first embodiment, except that the displayed accounts receivable ledger information is limited to the previous month's balance. Similarly, the current month's balance display area 2022 is the same as the accounts receivable ledger display area 2020 in the first embodiment, except that the displayed accounts receivable ledger information is limited to the current month.

[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 includes the balance carried over from the previous month, the current month's balance, and the current billing amount. However, the details included in the invoice image are only for the current month.

[0230] (Invoice Information Management Table) Figure 39 is a conceptual diagram showing an example of an invoice information management table in this embodiment. As shown in Figure 39, the invoice information management table in this embodiment has a common carryover invoice ID added to it.

[0231] The Carryover Common Invoice ID is a common invoice ID used to identify invoices issued in the previous month for details of items carried over from the previous month. In the issued invoice information management table, details with a Carryover Common Invoice ID set indicate that they are items carried over from the previous month.

[0232] (Invoice Information Management Table) Figure 40 is a conceptual diagram showing an example of a receipt invoice information management table in this embodiment. As shown in Figure 40, the receipt invoice information management table in this embodiment has a common carryover invoice ID added to it.

[0233] Similar to the issued invoice information management table, in the received invoice information management table, items with a common carryover invoice ID set indicate that they are carryovers from the previous month.

[0234] (Accounts Payable Ledger Information Management Table) Figure 41 is a conceptual diagram showing an example of an accounts payable ledger information management table in this embodiment. As shown in Figure 41, the accounts payable ledger information management table, which has a balance carried over from the previous month, stores accounts payable ledger information for the previous month and accounts payable ledger information for the current month. The contents set for the accounts payable ledger information for the previous month and accounts payable ledger information for the current month are the same as those set for the accounts receivable ledger information management table.

[0235] (Payment processing screen) Figure 42 is a conceptual diagram showing an example of the invoice creation screen in this embodiment. As shown in Figure 42, in this embodiment, the payment processing screen 2400 displays the details information field 2440, which is divided into the previous month's balance and the current month's balance.

[0236] (Payment Information Management Table) Figure 43 is a conceptual diagram showing an example of a payment information management table in this embodiment. As shown in Figure 43, the payment information management table in this embodiment includes payment information for the previous month's balance.

[0237] For payment information carried over from the previous month, a single payment ID is associated with multiple line item IDs related to common invoice IDs. For example, payment information with payment ID ADB852841F8B32772 includes line item IDs "0001" and "0003" with common invoice ID abcd1235, and line item ID "0001" with common invoice ID abcd1321.

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

[0239] For example, accounts receivable ledger information with a receivable date of September 29, 2020 (carried over from the previous month) is displayed with a payment due date of November 25, 2020. Similarly, accounts receivable ledger information with a receivable date of October 15, 2020 (for the current month) is displayed with a payment due date of November 25, 2020. This indicates that the same payment due date is registered for both the details carried over from the previous month and the details for the current month.

[0240] [Main effects of the second embodiment] In this embodiment, the transaction management server 10 stores payment information that associates a payment ID, which identifies a payment request, with the details to be paid. In this case, details included in different invoices can be associated with a single payment ID. Therefore, according to the transaction management server 10 in this embodiment, even if details to be paid are selected from multiple invoices, the details to be paid can be identified.

[0241] As a result, the transaction management server 10 in this embodiment makes it possible to perform automatic reconciliation on an item-by-item basis, even when selecting items to be paid 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 and to share invoice information. With this configuration, the buyer can access 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 buyer terminal 30 is an example of an information processing terminal. The seller terminal 20 is an example of a second information processing terminal. The transmitting / receiving unit 11 is an example of a transmitting or receiving unit. The chat area 2470 and chat area 2530 are examples of dialogue areas.

[0244] Each function of the embodiments described above can be realized by one or more processing circuits. Here, the "processing circuit" in this specification refers to a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, an ASIC (Application Specific Integrated Circuit) designed to execute each function described above, a DSP (digital signal processor), an FPGA (field programmable gate array), and devices such as conventional circuit modules.

[0245] The device groups described in the embodiments merely show one of a plurality of computing environments for implementing the embodiments disclosed in this specification. In one embodiment, the transaction management server 10 and the account management server 40 include a plurality of computing devices such as a server cluster. The plurality of computing devices are configured to communicate with each other via any type of communication link including a network and a shared memory, and implement the processes disclosed in this specification.

[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 or changes are possible within the scope of the gist of the present invention described in the claims.

Explanation of Reference Numerals

[0247] 1 Information processing system 10 Transaction management server 20 Seller terminal 30 Purchaser terminal 40 Account management server 11, 21, 31, 41 Transceiver 22, 32 Reception unit 24, 34 Display control unit 15, 25, 35, 45 Judgment unit 16, 46 Creation unit 19, 29, 39, 49 Memory control unit Memory units 100, 200, 300, 400

Prior Art Documents

Patent Documents

[0248]

Patent Document 1

Claims

1. An information processing device that can communicate with an information processing terminal used by a user via a network, A receiving unit receives a payment request from the information processing terminal that identifies the details to be paid from the invoice information issued to the user, A storage control unit stores in a storage unit payment information that associates identification information identifying the payment request with the details, An information processing device equipped with the following features.

2. An information processing apparatus according to claim 1, The system further includes a transmission unit that transmits remittance data, which includes the aforementioned identification information and is used to transfer an amount based on the details included in the payment information, to the customer's account, to the information processing terminal. Information processing device.

3. An information processing apparatus 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 trading partner. Information processing device.

4. An information processing apparatus according to claim 3, By comparing the deposit information and payment information using the aforementioned identification information, the deposit information is reconciled. Information processing device.

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

6. An information processing apparatus according to claim 4, The transmission unit transmits screen data for comparing the payment status of the invoice information and the details to a second information processing terminal used by the business partner. Information processing device.

7. An information processing device according to claim 5 or 6, The aforementioned screen data includes a dialogue area for conducting a conversation between the user and the business partner. Information processing device.

8. An information processing terminal capable of communicating with an information processing device via a network, A display control unit that displays a screen for generating remittance data based on invoice information issued to the user, A transmission unit that transmits a payment request to the information processing device, which identifies the details to be paid from the invoice information, An information processing terminal equipped with the following features.

9. An information processing terminal capable of communicating with an information processing device via a network, A transmission unit that transmits invoice information issued by the user to the information processing device, A display control unit that displays a screen for displaying the payment status of the details, based on identification information that identifies a payment request by specifying the details to be paid from the aforementioned invoice information, An information processing terminal equipped with the following features.

10. An information processing system in which an information processing terminal used by a user and an information processing device can communicate via a network, The aforementioned information processing terminal is The system includes a transmission unit that transmits a payment request to the information processing device, which identifies the details to be paid from the invoice information issued to the user. The aforementioned information processing device is A receiving unit that receives the payment request from the information processing terminal, A storage control unit stores in a storage unit payment information that associates identification information identifying the payment request with the details, An information processing system equipped with the following features.

11. A computer that can communicate with the information processing terminal used by the user via a network, A receiving procedure for receiving a payment request from the information processing terminal that identifies the details to be paid from the invoice information issued to the user, A storage control procedure for storing payment information in a storage unit that associates identification information for identifying the payment request with the details, An information processing method that performs the following.

12. A computer that can communicate with the information processing terminal used by the user via a network, A receiving procedure for receiving a payment request from the information processing terminal that identifies the details to be paid from the invoice information issued to the user, A storage control procedure for storing payment information in a storage unit that associates identification information for identifying the payment request with the details, A program to execute.

13. A computer that can communicate with an information processing device via a network, A display control procedure for displaying a screen for generating remittance data based on invoice information issued to the user, A transmission procedure for sending a payment request to the information processing device, which identifies the details to be paid from the aforementioned invoice information, A program to execute.

14. A computer that can communicate with an information processing device via a network, A transmission procedure for transmitting invoice information issued by a user to the information processing device, A display control procedure that displays a screen for displaying the payment status of the details, based on identification information that identifies a payment request by specifying the details to be paid from the aforementioned invoice information, A program to execute.

Images