EA014891B1 - Construction payment management systems and methods with specified billing features - Google Patents

Abstract

Systems and methods for managing payments. One construction of the system includes a software enabled user interface accessible by a first party and a second party, at least one computer readable memory, and a processor. The processor is configured to selectively operate in a specified billing mode in response to an input received from the first party. The processor is configured to receiving invoice details from the first party when operating in the specified billing mode and from the second party when not operating in the specified billing mode. The processor is further configured to generate an invoice based on the invoice details, display the invoice to the first party and the second party, and request an approval or a rejection of the invoice from the first party or the second party.

Description

General contractors at both large and small construction sites may put forward requirements for detailed invoicing / billing for selected subcontractors. According to this practice, known as detailed invoicing, the general contractor accurately indicates the amount of work performed by the subcontractor, directly without input from the subcontractor. Other situations also require the party (e.g., general contractor, parent subcontractor, construction engineer or owner) to accurately determine the amount of work performed by one or all of the contractors working on site (e.g. payees). For example, at some construction sites (such as projects with the same total price), the payer may hire and / or hire an inspector who measures or supervises the individual structures completed for the project and calculates how much must be paid. In these and other situations, payees and / or the payer may, by agreement or in practice, be limited or not be able to determine how much to pay.

SUMMARY OF THE INVENTION

Some embodiments of the invention provide a payment management system that includes a software user interface that the payer and the payee have access to. The system also includes at least one computer readable storage device and a processor. The processor is configured to selectively operate in the detailed billing mode in response to a command received from the payer. When working in the detailed billing mode, invoice details are entered by the payer, and the generated invoice is submitted to the payee for approval. At the same time, when they do not work in the detailed billing mode, the payee has the opportunity to enter invoice details, and the payer has the opportunity to approve or reject the invoice. In some embodiments, the processor is configured to notify the payee when billing is turned on or off. In some embodiments, the first and second parties are able to create and transmit additional information, such as comments, photographs, video or audio, related to the confirmation of the details of the invoice. In some embodiments, comments and previous bill details are stored in a computer readable storage device.

Some embodiments of the invention provide a payment management system that includes a software user interface that three parties have access to. The system also includes at least one computer readable storage device and a processor. The processor is configured to generate two linked accounts - the first account between the first and second parties and the second account between the second and third parties. The processor is configured to selectively operate in the detailed billing mode for the first invoice and for the second invoice. When operating in the billing mode for a detailed invoice for the first invoice, the invoice details are entered by the first party. When they do not work in the detailed billing mode for the first invoice, the invoice details are entered by the second party. Similarly, for a second invoice, invoice details are entered by the second party when detailed billing is enabled, and by a third party when detailed billing is turned off.

In some embodiments, the processor is configured to initiate a second invoice using the detailed billing mode enabled and create invoice details for the second invoice based on invoice details for the first invoice. In some embodiments, the processor is configured to initiate a first invoice using the off detailed billing mode and create invoice details for the first invoice based on invoice details for the second invoice.

- 1 014891

Brief Description of the Drawings

FIG. 1 is a schematic illustration of a construction payment management system according to the invention.

FIG. 2 is a flowchart showing invoicing with the detailed billing mode turned off, according to the invention.

FIG. 3 is a flowchart showing creation of an invoice with a detailed billing mode enabled according to the invention.

FIG. 4a is a graphical user interface for entering invoice details according to one embodiment of the invention.

FIG. 4b is the graphical user interface of FIG. 4a with an active comment window.

FIG. 5 is a graphical user interface for approving or rejecting a detailed bill.

FIG. 6 is a flowchart showing the creation of an invoice initiated by a payer according to one embodiment of the invention, where detailed invoicing can be selectively turned on or off.

FIG. 7 is a flowchart showing the creation of an invoice initiated by the payee according to one embodiment of the invention, where the billing of the detailed invoice can be selectively turned on or off.

FIG. 8 is a graphical user interface showing pending tasks for a participant.

FIG. 9 is a graphical user interface for managing subcontractor accounts.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Prior to a detailed description of various embodiments, it should be understood that the invention is not limited in its application to the details of the structure and placement of components set forth in the following description or illustrated in the accompanying drawings. The invention admits other embodiments and can be practiced or carried out in various ways. In addition, it should be understood that the language and terminology used in this document are for description only and should not be construed as limiting. Use including, containing or having and their variants is intended to indicate the content of the elements listed below and their equivalents, as well as additional elements. The expressions set, connected, and connected are used widely and encompass both direct and indirect installation, connection, and connection. Additionally, the phrases connected and connected are not limited to physical or mechanical connections or connections, and may include electrical connections or connections, direct or indirect. Also, electronic messages and notifications can be performed using any known means, including direct connections, wireless connections, etc.

Payment management systems in construction provide visual access to the facility for interested parties. Payment management systems in construction are described in pending US applications Nos. 12/061805 and 11/032699. The embodiments of a construction payment management system described herein may combine some or all of the features described in the aforementioned US patent applications pending.

Some of the embodiments described below provide greater flexibility in creating and approving accounts. In some embodiments, invoice details may be entered directly by the payer, payee, intermediary contractor, or third party, depending on the requirements of the situation. In addition, some embodiments allow multiple parties to enter details of one invoice, while at the same time providing a structured and secure way to approve and record changes made to the invoice.

In FIG. 1 shows a payment management system 100 according to an embodiment of the invention. The server 101 is connected to the payer terminal 103 and the payee terminal 105. Server 101 comprises a computer readable storage device 101A (e.g., a hard disk) and a processor 101B. The server also includes hardware for connecting to a local area network (LAB) and the Internet. Computer readable storage device 101A includes stored data related to construction sites managed by the payment management system 100, and program instructions for communicating with other computers via b-ΛΝ or the Internet. The web user interface is also stored on the computer readable storage device 101A and is executed by the processor 101B, so that the user web interface can be accessed by other computers.

- 2 014891

In some embodiments, the payer and payee terminals 103 are general purpose personal computers, while in other cases they are specialized computers specifically designed for use in the payment management system 100. In this embodiment, the payer terminal 103 is a personal computer comprising a hard disk and an SRI. It is connected directly to the server via a local area network (ΕΆΝ). The terminal 105 of the payee is a personal computer with a hard disk and SRI. It is connected to the server via the Internet connection 107. The user web interface is stored on a computer readable storage device 101A on the server 101 and is displayed on the terminals 103, 105 of the payer and the payee. In other embodiments, payer and payee terminals 103, 105 may be connected to server 101 in other ways. For example, both terminals 103, 105 may be connected to the server via the Internet 107.

Additional terminals may also access server 101. For example, a third party estimator or government inspector may access server 101 through terminal 109. In some embodiments, access to server 101 is provided through a web user interface. An authorized user can access the server 101 and the payment management system 100 from any computer with Internet access.

In FIG. 2 shows an example of creating an invoice using the payment management system 100. In this example, the payee, such as a subcontractor or general contractor, is able to create an invoice based on the total amount that it requires to pay. This process is usually referred to as billing by the payee or standard billing.

The payer requests an invoice (step 201). The payee creates an invoice (step 203) and enters the account details (step 205). The system generates an invoice based on invoice details, placing the details in a formatted template. The invoice is then ready for internal review and signature by the payee (step 207). The payee can either view the details of the invoice in a table format in the terminal user interface, or view / print a formatted invoice. If the payee is not satisfied with the invoice, the payee does not sign the invoice (step 209) and makes additional changes (step 205). In some embodiments, a time limit or time limit is defined for the payee to propose changes and approve the invoice. Alternatively, if the specified account is not signed and returned to the payer before the date of withdrawal of funds, the payee will not be paid during this debit.

When the payee is satisfied with the contents of the invoice, an electronic signature is provided (step 209), and the invoice is sent to the payer for viewing. The payer then either approves or rejects the account (step 211). If the payer is not satisfied with the contents of the account, the account is rejected and returned to the payee for further editing (step 205). Otherwise, the account is now ready to continue the payment process (step 213). Once the invoice is ready for payment, the payer can make and deliver the payment manually (for example, using a check) or the payment management system can be used to make an electronic payment (for example, through an automated clearing house or electronic payment transfer system).

In FIG. 3 shows another example of creating an account using the payment management system 100. In this example, the payer, such as a general contractor or property owner, is able to create an account based on the total amount that the payer intends to pay to the payee. This process is usually referred to as issuing a detailed invoice or issuing a detailed invoice by a payer.

In this example, when the payer wishes to receive the account being created (step 301), the payer creates an account (303) and enters the account details (step 305). If the payer is satisfied with the contents of the account, it is sent to the payee (step 307) for viewing (step 309). However, if the payer is not satisfied with the contents of the account, the payer may continue to edit the contents (step 305). After the invoice has been transmitted and viewed by the payee (step 309), the payee decides whether to approve or reject the invoice (step 311). If the payee is satisfied, an electronic signature is provided and the invoice is returned to the payer (step 313). If the payee is not satisfied, the payee rejects the invoice and returns it to the payer for further editing (step 305). In this example, the payee is not able to make any changes to the account - he can only approve or reject it. When the payee approves and electronically signs the invoice, it is returned to the payer. The payer may still decline the invoice and make further changes to the content (step 305). Otherwise, the account is ready to continue the payment process (step 315).

- 3 014891

Embodiments of the payment management system 100 may be configured to conform to payer preferred practices or the geographic region of the project. For example, in some regions, it is common practice not to return signed documents (such as invoices or non-deduction documents) to the payer. The total amount for the detailed invoice is the total amount that will be paid to the payee, and the recipients are not able to discuss or decline the invoice. Therefore, some embodiments of the system may also be configured to prohibit the payee from rejecting the detailed bill.

In other situations, the payer delegates the opportunity to assign the amount of payment in the invoice to a third party (for example, an estimate engineer). Therefore, some embodiments of the system may be configured to provide a third party with the ability to control the billing process. Unless explicitly stated otherwise, the term billing is detailed, as a rule, covers all situations where someone other than the payee enters the details of the invoice (for example, billing a detailed invoice compared to issuing a detailed invoice by the payee).

In some embodiments, detailed billing attributes may be included for all subcontractors included in the project, or individual subcontractors included in the project. When a subcontractor with detailed billing enabled is included in a new withdrawal, the system continues to operate as shown in the method of FIG. 3. When billing is turned off for a project or for a separate subcontractor, the system continues to operate as shown in the method of FIG. 2. As discussed below, the detailed billing functionality in some embodiments may be turned on and off during the creation of a single invoice to allow parties to enter invoice details together.

The default billing status can be set at the project level. Enabling detailed billing sets the default settings for all new subcontractors assigned to this project. When first-level subcontractors are created, the general contractor can choose to turn off detailed billing for a specific subcontractor. In some embodiments, enabling detailed billing for a project does not necessarily mean a common setting for all subcontractors, but only that setting a detailed billing is the default setting for the project. This functionality may also be provided for sub-subcontractors, and the default setting will be guided by the setting of detailed invoicing of a higher subcontractor.

Both when a detailed invoice is issued by a payee and when a detailed invoice is issued by a payer, the payment management system 100 can be configured to send notifications when certain events occur, such as a newly created invoice, a signed invoice, an initiated payment, etc. When the general contractor has sent a detailed invoice for approval, a notification can be sent to a subcontractor (for example, a subcontractor's project manager), which includes a link to view invoice details. The subcontractor can then schedule the dispatch action to the signatory, and the standard billing process through the payment management process in construction will take place. Assignment of action items is discussed further below.

In FIG. 4a shows a graphical user interface that is presented to a party that enters account details (e.g., to a payee, payer, or third party appraiser). The user interface includes editable text fields for the name 401 of the project, contract number 403 and date 405. An editable text table is also included. 407, containing fields for the position of the account / name of the payee, the percentage of completion, the planned amount of payment and the total amount to be paid on the account. When creating or editing an account, these fields can be changed, and new records can be added to the table. 407. When finished, the user clicks the 409 button to save the changes. Alternatively, the user may click the 411 button to discard any changes and revert to the previous version of the account.

Some embodiments of the payment management system 100 provide interest rate billing at the contract level instead of billing the interest account for the items shown in the table. 407. In order to use the functionality of issuing a percentage invoice at the contract level, the party entering the details of the invoice may enter one percentage value in the table. 407 to be applied to the entire subcontractor. The invoice amount will be equal to the indicated percentage of the total planned amount for the subcontractor.

In the example of FIG. 4a, the general contractor creates an invoice for the supplier of materials (ВшИшд 8ирр1у Со.). Tab. 407 includes three entries: completion of the foundation, glass door - parts and glass door - installation. For each item included in the table. 407, there is a talk button 413. In other embodiments, only one talk button 413 is provided. By pressing

- 4 014891 talk button 413, the user can initiate asynchronous text communication with the other side. FIG. 4b shows a conversation window 421 that opens when one of the conversation buttons 413 is pressed. The conversation window 421 includes a text input field 423, a send button 425, and a display field 427 that shows messages that have been sent or received by the user.

As shown in FIG. 4b, both text comments and numerical values representing changes made to the account are displayed in the display field 427 of the conversation window 421. Next to each entry is an expand / collapse button 429 (for example, + and When the entry is expanded (for example, a button 429 is displayed as a display field 427 includes a table 431 that lists the details of any changes to the account made by the user with a comment Table 431 shows the previous account details, new account details and the difference between them, Table 431 also indicates who entered what details.

As discussed above and with further details below, the detailed billing functionality can be turned on or off during invoice creation. In the example of FIG. 4b the detailed billing functionality is turned off. After user 1 (IBEK. 1) entered the initial details of the account, user 2 (IBEK. 2) changed the details of the glass door entry - setting the account from 0% completion to 80% completion. Since the comment from user 1 is minimized (as indicated by the + sign), tab. 431 is not displayed. Since the comment from user 2 is in expanded form, tab. 431 shows the parts that were originally entered by user 1, the updated parts entered by user 2, and the difference between them.

In some embodiments, photographs are also transmitted using a conversation window 421 to provide visual evidence of work performed or materials delivered. For example, user 2 in FIG. 4b may use the conversation window 421 to send a photograph of a partially completed installation of a glass door to user 1.

In some embodiments, the conversation window 421 also facilitates the transmission and reception of messages or comments recorded in audio (eg, mp3) or visual (eg, mpd) forms. In some embodiments, the conversation window 421 is replaced with a real-time communication form, such as a video or audio conference window.

As described above, the server 101 of the payment management system 100 includes a storage device 101 A that stores invoice details. In some embodiments, the server also stores a history of changes made to the invoice (for example, which side made which changes and when) and also stores the contents of the conversation window 421. In some embodiments, this information is stored in a journal form that allows the user to view changes and comments that have led to the current invoice form.

In FIG. 5 shows a graphical user interface that is presented to the party that views / approves the invoice. In the example of FIG. 3 it can be either the payee at step 309 or the payer at step 313. As in FIG. 4a, the user interface includes fields for naming 501 of the object, contract number 503, and date 505. However, since this screen is for viewing / approval only, these fields are not editable. Similarly, tab. 507 includes information that has been entered in the table. 407 (Fig. 4a), but tab. 507 is uneditable. The user can approve an individual item in the invoice by clicking on the approval button 509 corresponding to an individual item. Alternatively, the user can approve the entire invoice by selecting the approve all button 511.

As noted above, subcontractors may reject a detailed invoice. The user can reject individual items by selecting the corresponding reject button 513, or can reject all of the listed items by selecting the reject 515 button. A subcontractor rejecting a detailed bill can also provide a reason for the rejection using the talk button 517. Although FIG. 5 shows a talk button 517 associated with each listed item, only one talk button 517 is provided in other embodiments.

As discussed above, selecting the conversation button 517 initiates real-time text messaging with the other party (in this case, the party indicating invoice details). If the other side is unavailable for conversation, the payment management system 100 informs the other side of the rejection the next time the other side accesses the system. The indicating party is requested to re-enter the account. Negotiations regarding the rejected position can then be carried out using the conversation button 413 (Fig. 4a) or resolved offline.

In some embodiments, detailed billing functionality can be turned on or off by delaying payment and not completing billing. When the detailed billing setting changes, the system returns to the operations associated with the new installation (either from issuing a detailed invoice to the standard, or vice versa). This change can be applied to a separate account, to a single payee (for example, a subcontractor), or to the entire project.

- 5 014891

The billing setting can be changed at any time during the project, and switching the billing setting changes the setting immediately. When the detailed billing setting is changed for an individual subcontractor, all subcontractor invoices that have not been sent to the signatory can begin the billing process with a new detailed billing setting. Similarly, switching between turning the installation on and off to issue a detailed invoice under a separate agreement can cause all invoices that were not sent to the signatory (or were created) to change the sequence of actions for the new installation.

For example, if a general contractor (payer) begins preparing an invoice for a subcontractor (payee) by issuing a detailed invoice, the subcontractor will not be able to directly modify the invoice. However, if the general contractor disables billing of the detailed invoice (i.e., switches to the issuing of the detailed invoice by the payee) before the invoice has been approved by the subcontractor, the subcontractor then has the ability to add, delete or edit invoice details. A notification of any change in the detailed billing status for the subcontractor will be sent to the subcontractor in the payment management system 100.

In FIG. 6 illustrates a method of using the payment management system 100, where the setting for issuing a detailed invoice changes during invoice creation. The payer requests an invoice from the system (step 601), initiates the creation of an account (step 603), and enters / edits the details of the invoice (step 605). After the payer has entered / edited the details of the invoice, the payer either sends the invoice to the payee (step 607) or saves the invoice without sending it to the payee. If the invoice is not sent, the payer may make further changes to the invoice (step 605).

If the payer is ready to send the invoice to the payee (step 607), the payer makes a determination regarding the setting of issuing a detailed invoice. If the payer wishes to use the issuing of a detailed invoice (i.e., issuing a detailed invoice by the payer), the lock is placed on the account (step 609). The payee then has the opportunity to view invoice details (step 611) and either approve or reject the invoice (step 613). If the payee rejects the invoice, it is sent back to the payer with the instruction to re-enter the account details together with any comments entered by the payee (for example, using the conversation button 517). If the payee approves the invoice, an electronic signature is attached (step 613) and the invoice is sent back to the payer (step 615). The payer may still decline the invoice and make further edits (step 605). Otherwise, the account is ready to continue the payment process (step 617).

If the payer wishes to use the billing by the payee, a block is not put on the account when it is sent to the payee (steps 607 and 609). The payee again looks at the invoice (step 619) and is given the opportunity to attach an electronic signature (step 621). If the payee approves the invoice, it is returned to the payer for final approval (step 615), as discussed above. However, if the payee does not sign the invoice, the payee is now able to make changes, add or delete to the invoice (step 623). When the payee finishes making the changes, the updated invoice is sent to the payer for review (steps 625 and 627). After viewing the invoice (step 627), the payer decides whether to approve or reject the invoice updated by the payee (step 629). If the payer approves the changes to the recipient, the account is ready to continue the payment process (step 617). Otherwise, the payer makes further changes to the invoice (step 605) and sends the invoice back to the payee (step 607).

As discussed above, the payer is able to unblock the account at any time (for example, turn off the issuing of a detailed invoice) (step 631). If, for example, the payee sent a message to the payer when viewing the invoice (step 611) using the talk button 517 (Fig. 5), the payer can choose to remove the lock (step 631) and allow the payee to make changes directly to the account, instead of making the changes themselves payer.

In some embodiments, an unlocked account can only be edited by the payee, or both the payee and the payer. In the case where both the payee and payer have permission to edit, the payer and payee can jointly check the details of the account until the bill is approved and signed by the payee. As described above, the talk function can be used to facilitate such collaboration. Editing permissions associated with an unlocked account are selected by the project manager (e.g., payer or general contractor).

In some embodiments, the payer (eg, general contractor) retains the ability to enter invoice details until a detailed invoice is sent to the payee (eg, subcontractor). However, in some embodiments, after the payer has requested an invoice (for example, step 601), either the payer or the payee may enter account details. In the latter case, if the general contractor (as the payer) does not enter the details

- 6 014891 whether invoices for the subcontractor before the subcontractor (as the payee) enters the details of the invoice, the system may limit or prevent the general contractor from entering the detailed invoice for the subcontractor.

In FIG. Figure 7 shows a scenario where an invoice is initiated with detailed billing turned off (that is, the account lock has been deleted). After the payer requests an invoice (step 701), the invoice is unlocked and the payee has the ability to enter and edit account details (step 703). After the details have been entered, the invoice can be sent to the user associated with the payee, who has the authority to approve and sign, for internal viewing by the payee (step 705). At this time, the payee can either sign the invoice (step 707) or make additional additions, deletions, or changes (step 703). When the payee approves the invoice, an electronic signature is attached (step 707) and the invoice is sent to the payer for review.

If the payer approves the invoice (step 709), another electronic signature is attached (step 711) and the invoice is ready for payment. However, if the payer does not approve the invoice, the payer can either return it to the payee for further editing (step 703), or may choose to make changes directly to the invoice (step 713). If the payer makes the changes directly (step 713), the invoice will be returned to the payee with a lock either turned on or off (i.e., issuing a detailed invoice by the payer or issuing a detailed invoice by the payee) (step 715). If the invoice is returned with the lock disabled, a notification describing the status of the billing setup is sent to the payee (step 717), and the payee can make further changes to the invoice (step 703). The process continues, as discussed above. Notifications (not shown) can also be used in the method of FIG. 6.

However, if an invoice is returned with the lock turned on, the payee is no longer able to make changes directly to the invoice. The system sends a notification to the payee informing the payee that the account lock has been enabled and detailed billing has been activated (step 719). The payee scans the invoice (step 721) and sends it to the party with the authority to sign for final internal viewing by the payee (step 723). If the payee approves the updated invoice, an electronic signature is attached (step 725) and the invoice is returned to the payer for final approval (steps 709 and 711). If the payee does not approve the invoice, it is sent back to the payer for further editing (step 713). As discussed above with reference to FIG. 6, the payer has the ability to unlock the account at any time (step 727).

As discussed above, in some embodiments, notifications and a list of measures are sent to the user when certain events occur. For example, as shown in FIG. 7, a notification is sent when the detailed billing setting has been changed and when the created invoice is being viewed. FIG. 8 shows a graphical user interface for presenting these notifications according to one embodiment. When a user (e.g., payer, payee, general contractor or subcontractor) accesses system 100, the task list page identifies the user (801), contract number (803), and current date (805). In some embodiments, the contract number field (803) is selectable so that the same user can view tasks for different contracts.

Tab. 807 shows upcoming tasks / notifications for the participant. For example, in FIG. 8, company Вш1бшд 8ирр1у Со. you need to look through account number 0001 and enter details for account number 0002. The list of tasks also includes a notification informing the company Вш1бшд 8ирр1у Со. that the detailed billing status has been changed for account number 0002. Tab. 807 also includes the date of receipt and deadlines. The user accesses the individual items from the list by selecting the browse button 809 corresponding to the appropriate item.

In FIG. 9 shows a stage separation page from which a user (e.g., a general contractor) can manage multiple accounts. The stage separation page identifies the user (901), the contract number (903) and the current date (905). In some embodiments, the contract number field 903 is selectable so that the user can view bills for different contracts. Tab. 907 provides information for each invoice, such as the name of the subcontractor, invoice number, current invoice status, total amount to be invoiced, completion percentage, and actual invoiced amount. The user selects an account by ticking block 909 corresponding to the proper account. After selecting one or more of the listed accounts, the user selects one of the buttons 911, 913, 915 to perform the associated operation. For example, a user can send an invoice to a subcontractor (button 911), view the current version of the account (button 913) or view the tasks associated with the account (button 915). In some embodiments, the implementation of the state field in the table. 907 includes a hypertext link to

- 7 014891 interface for the upcoming task (for example, the graphical user interface in Fig. 4 or 5).

In some embodiments, a payment management system 100 is used to manage hierarchical billing for situations involving more than one contract level. For example, a property owner signs a contract with a general contractor to build a building. The general contractor then hires one or more subcontractors to carry out certain types of work (for example, carpentry, plumbing, etc.). In such situations, billing at one level may limit or inform billing at another level.

In some embodiments, the payment management system 100 controls hierarchical billing depending on billing settings for detailed billing at different levels. For example, if standard invoicing (i.e., detailed invoicing by the payee) is enabled at the project level, the subcontractor submits the invoice to the general contractor. If the general contractor approves the invoice, the payment management system 100 uses the details from the subcontractor's account as default details when generating an invoice, which should be submitted by the general contractor to the property owner for consideration. Similarly, if detailed invoicing is enabled at the project level, an invoice detailed by the property owner provides invoice details for the subcontractor's invoice.

The payment management system 100 may also implement various detailed billing settings at different hierarchical levels. For example, a general contractor can create subcontractor invoices using only detailed invoicing, while invoices paid by the property owner to the general contractor are created using the joint invoicing described in FIG. 6 and 7. In some embodiments, the payment management system 100 then uses the details from the property owner’s account as the default details for the subcontractor’s account. Similarly, the property owner can only use detailed billing (either directly or through a third party, such as an estimate engineer) to prepare invoices for the general contractor, while subcontractors submit invoices to the general contractor using standard invoicing. In such cases, the detailed account of the property owner includes the total amount that must be paid to the general contractor, regardless of the accounts submitted to the payment recipient by contractual daughters at lower levels (for example, subcontractors). Such subcontractor accounts do not change the totals for the detailed payer account.

Contract subsidiary payments and the management of such a contract / budget hierarchy are discussed in U.S. Patent Application Pending No. 11/485545, filed July 12, 2006, and 11/485610, filed July 12, 2006, both of which are contained herein. .

The designs and methods described above are illustrative. Other configurations, designs and uses are possible. Embodiments of the invention can be applied to a variety of situations in which one side indicates invoice details and the other approves and signs the invoice. The purpose of the invention is therefore not limited to transactions between the general contractor and the subcontractor, not limited to situations affecting the payer and payee. For example, as discussed above, in certain embodiments, the third party determines the details of the invoice, and neither the payer nor the payee has any control over the process. The terms payer and payee are not limited to general contractors and subcontractors. For example, a payer may be a bank or a property owner, while the payee may be a general contractor. In other examples, the payee may be a subcontractor, a material supplier, or a subcontractor.

Although the payment management system 100 is described above as a web application running on a server and accessible via personal computers via the Internet, other system architectures are possible. For example, in some embodiments, the entire application runs on a single terminal. In other embodiments, the application program runs on two or more personal computers connected directly to each other without a central server. Essentially, the term processor is intended to include a separate SRI / microprocessor or multiple SRi on multiple terminals connected to a payment management system 100. Various features and advantages of the invention are set forth in the following claims.

Claims (31)

CLAIM 1. A payment management system in construction, containing a software user interface available to the first and second parties associated with the construction project; A computer readable memory and a processor configured to selectively operate in the detailed billing mode in response to input data received from the first side, receive billing details from the first side when operating in the detailed billing mode, receive billing details from the second side, when the system does not operate in the detailed billing mode, generate an invoice based on the invoice details, display the invoice to the first and second parties and request approval or rejection account of the first or second party. 2. The payment management system in construction of claim 1, wherein the processor is further configured to notify the second side when the detailed billing mode has been turned on or off. 3. The payment management system in construction of claim 1, wherein the processor is further configured to request approval or rejection of the account from both the first party and the second party. 4. The payment management system in construction according to claim 1, in which the processor is further configured to receive the details of the invoice from the first party when the system is not operating in the detailed invoice mode. 5. The payment management system in construction according to claim 1, in which the processor is additionally configured to prevent the second side from entering billing details when the system is operating in a specified billing mode. 6. The payment management system in construction according to claim 1, in which the processor is further configured to prevent the first party from entering billing details when the system is not operating in the billing mode. 7. A payment management system in construction of claim 1, wherein the processor is further configured to turn on or off the billing mode of the detailed invoice for the account in response to input data from the first party. 8. The payment management system in construction according to claim 1, in which the processor is additionally configured to turn off the detailed billing mode after receiving the deviation from the second side and input data from the first side. 9. The payment management system in construction according to claim 1, in which the processor is further configured to turn on the detailed billing mode after receiving the billing deviation from the first party and input data from the first party. 10. The payment management system in construction of claim 1, in which the processor is additionally configured to enable the provision of detailed billing for new accounts by default. 11. The payment management system in construction of claim 1, wherein the processor is further configured to turn off the detailed billing mode at any time in response to input from the first party. 12. The payment management system in construction according to claim 1, in which the processor is further configured to receive a comment from one of the first side and the second side and display the comment of the other of the first and second sides. 13. The payment management system in construction of clause 12, in which the processor is additionally configured to display a comment and many other comments received from the first and second parties in a chronologically ordered list. 14. The payment management system in construction of clause 12, in which the processor is additionally configured to associate the comment with the change made to the account details. 15. The payment management system in construction of clause 12, in which the processor is additionally configured to associate a comment with approval or rejection of the account. 16. The payment management system in construction of clause 12, in which the processor is additionally configured to store the comment in a computer readable storage device. 17. The payment management system in construction of clause 12, in which the processor is additionally configured to store the comment in a computer readable storage device - 9 014891 stv. 18. The payment management system in construction on 17, in which the processor is additionally configured to store the comment and many other comments received from the first side and the second side, in a computer readable storage device in a chronologically ordered list. 19. The payment management system in construction on item 12, in which the comment includes a text comment. 20. The payment management system in construction according to claim 19, in which the text comment includes a link (communication channel) to the photo. 21. The payment management system in construction on item 12, in which the comment includes a photo. 22. The payment management system in construction on item 12, in which the comment includes at least one of the video and audio recordings. 23. The payment management system in construction according to claim 1, in which the first party is an engineer-estimator. 24. The payment management system in construction of claim 1, in which the first party is the general contractor, and the second party is a subcontractor. 25. The construction payment management system of claim 1, wherein the invoice details include the total cost of the materials and services that the contractor is required to provide for the construction project, and the percentage of completion associated with the materials and services. 26. The payment management system in construction according to claim 1, in which the processor is further configured to initiate an electronic payment of the invoice after receiving the approval of the invoice from the first and second parties. 27. The payment management system in construction of claim 1, in which the processor is additionally configured to receive an electronic signature confirming the approval of the account from the first or second party. 28. A payment management system in construction, containing a software user interface accessible to the first and second parties; a computer readable storage device and a processor configured to receive the details of the invoice from the first party via a software user interface, the invoice details including the amount associated with the work done on the construction project or the amount associated with the materials delivered for use in the construction project, form an account for the construction project based on the details of the account, display the invoice to the second side through the software user interface, request to approve or reject the account from the second party, accept multiple comments from the first and second parties, associate a comment from multiple comments with one of the accepted invoice details, approval and rejection, display multiple comments in a chronologically ordered list and save the chronologically ordered list to a computer readable Memory device. 29. A construction payment management system containing a software user interface accessible to the first party, second party and third party associated with the construction project; computer readable storage device and processor, configured to selectively operate in the detailed billing mode for the first invoice in response to input data received from the first party, the first party is associated with the payer of the first account, and the second party is associated with the payee of the first account to receive invoice information for the first set of invoice details from the first party when operating in the billing mode of the detailed invoice for the first invoice, receive information from eta for the first set of invoice details from the second party, when not working in the detailed invoice mode for the first invoice, generate the first invoice based on the first set of invoice details, selectively work in the detailed invoice mode for the second invoice in response to input data received from the second party, while the second account is associated with the first account, and the second party is associated with the payer of the second account, and the third party is associated with the payee for the second account, to receive information invoice for the second set of invoice details from the second party when it is working in the billing mode of the detailed invoice for the second invoice, - 10 014891 accept invoice information for the second set of invoice details from a third party when it is not operating in the detailed invoice mode for the second invoice, and generate a second invoice based on the second set of invoice details. 30. The payment management system in construction on clause 29, in which the processor is additionally configured to initiate a second account with the detailed billing mode enabled and create a second set of invoice details based on the first set of invoice details. 31. The payment management system in construction on clause 29, in which the processor is additionally configured to initiate the first invoice with the detailed billing mode turned off and create the first set of invoice details based on the second set of invoice details.