CN101044477A - Construction payment management system and method - Google Patents

Abstract

A system and methods are provided, which are used for managing a construction payment process. The first method for realizing the invention can comprises that a participator is allowed to receive a payment in relation to the engineering through an access logon message; the second method can comprise an automatic invoice, which consists of a or a plurality of payout items; the third method can consist of an automatically generated pledge, which comprises a sum from the automatic invoice; and the fourth method can comprise the confirmation that the receiving participator has received the fund and the abandon of a lien is released at the same time. Moreover, another method consists of a coordination of the main budget and the auxiliary budget, which comprises the payout items, before the fund drawing management.

Description

Construction payment management system and method

related application

Priority is claimed to US Patent Application Serial No. 60/583,782, filed June 29, 2004, under 35 U.S.C. §119.

Background technique

Residential and commercial construction projects require several organizations to communicate with each other in order to distribute payments. The traditional method of construction payment management is firstly to notify through verbal notice that it can be withdrawn from the project loan or the owner's account. The general contractor (GC) of the construction works notifies the subcontractors (or any other person, firm or company engaged by the GC, such as material suppliers) of such withdrawal by telephone, fax or at a meeting. Subcontractors are to prepare invoices and send them to GC by mail, fax, direct delivery or at a meeting with GC. The GC and the various subcontractors usually have to negotiate the final invoice amount over the phone or in a meeting. The GC validates these invoices, writes the details to the GC engineering billing system, and prepares its own invoices.

As soon as these invoices are completed, the GC also prepares the sworn statement by hand. In this affidavit, the GC affirms that subcontractors hired by the GC have performed specific services in the construction or repair of the property. In this affidavit, GC also confirms the amount given to each subcontractor.

GC forwards effective affidavit to title company and project loan lender and/or owner. The lender, landlord, or title insurance company notifies the superintendent that an inspection of the property must be performed and an affidavit sent to the superintendent. The supervisor compiles previous inspection reports for the real estate project. Supervisors perform new inspections and manually customize inspection reports. The inspector distributes the inspection report to lenders, homeowners, and/or title insurance companies by fax, mail, or direct delivery.

The lender, homeowner, and/or title insurance company receives the affidavit and inspection report by mail, fax, direct delivery, or at a meeting with the GC and/or superintendent. Lenders, homeowners and/or title insurance companies must retrieve prior drawdown and engineering documents. Lenders, homeowners, and/or title insurance companies must usually negotiate payments and project details with the GC by phone, fax, or in a meeting. The lender, homeowner, and/or title insurance company approves the affidavit and transmits the approval by phone, fax, or at a meeting. The lender or property owner then approves the disbursement of the amount specified in the affidavit.

The construction loan lender or the owner's bank usually transfers the funds required to pay all subcontractors into an escrow account. Typically the title insurance company thereby pays the GC funds from the escrow account. GC and/or title insurance company prepare checks for subcontractors. At this point, the subcontractor typically closes a lien waiver for previous drawdowns of project loan funds or for work completed during the preceding month. Thus, the lien for the current drawdown or current month is waived until a subsequent drawdown from the project loan or until during the next month. In addition, subcontractors may have their own subcontractors, and after receiving payment from GC, they must pay their subcontractors.

Traditional engineering payment methods can take 90 days or more from the date of the verbal withdrawal notice to the date the subcontractor actually receives the payment. Traditional engineering payment methods often involve unreliable verbal notification of events upon which the method operates. For example, if one subcontractor has difficulty obtaining a custom invoice or submitting a lien waiver, it will delay the payment process to all other subcontractors.

The traditional engineering payment process also involves a huge amount of data entry. For example, for a single large construction project, GC usually has to enter hundreds of invoices into its accounting system every month. At the same time, the GC must collect hundreds of lien waivers every month. In addition, GC must customize, approve, sign and distribute hundreds of checks to subcontractors every month. Additionally, the GC must maintain all paper documentation collected during each extraction process. The period of withdrawal notices, approvals, and lien waivers for payment requires hundreds of faxes, phone calls, and meetings each month.

Contents of the invention

Embodiments of the present invention provide systems and methods for managing the project payment process. A method of implementing the invention can include receiving registration information for a party, storing the registration information, and by accessing the registration information, transferring payment related to construction work to the party.

A project payment management system embodying the present invention can include an application server storing an organization module that receives organization registration information for a participant and a database management system. The system also includes a database server connected to the database management system, the database server storing the organization registration information, the database management system accessing the organization registration information to transfer payment related to the construction work to the party.

Another project payment management system embodying the present invention can include an application server storing an organization module and a database management system, the organization module receiving organization registration information from a participant. The system can also include a database server connected to the database management system, the database server storing the organization registration information, the database management system accessing the organization registration information in order to transfer payment related to the construction work to the party.

A method of implementing the invention can include establishing communications with multiple parties involved in a construction project, generating a notice of withdrawal, and electronically transmitting the notice to the multiple parties in real time.

Another system embodying the invention can include an application server storing a notification manager and a withdrawal module that generate withdrawal notifications that the notification manager electronically communicates in real time to a plurality of participants.

Some embodiments of the invention include generating a budget for construction work, and based on the budget, generating at least one automatic invoice, automatic affidavit, and at least one automatic lien release.

One embodiment of the invention includes receiving at least one invoice from at least one subcontractor, and automatically generating, from each of the at least one invoice, the general contractor's affidavit including the amount.

Another system embodying the invention can include an application server storing a budget module that generates a budget for a construction project and a withdrawal module that generates at least one automatic invoice, automatic affidavit, and at least one automatic lien based on the budget give up.

Another method of the invention includes receiving a lien waiver from a party in the construction work, storing the lien waiver, transmitting an instruction to pay the party to a payment system, and receiving from the payment system that the party has received Confirmation of funds and substantially simultaneous release of this lien waiver.

Another method of the present invention receives a lien waiver from a party in the construction work, and transmits an instruction to pay the party to the payment system, and releases the lien waiver substantially simultaneously.

Another system embodying the invention includes an application server that stores an electronic safe deposit box that receives and stores a lien waiver from a party in a construction project, and a withdrawal module that transmits instructions to pay the party to the payment system, the withdrawal module receives confirmation from the payment system that the participant has received funds, and substantially simultaneously releases the lien waiver.

Another method of the present invention includes creating a preliminary budget for the construction work, including at least one auxiliary budget from at least one of the general contractor, at least one subcontractor, and at least one material supplier, the at least one auxiliary budget each including at least one a line item, and identifying that the preliminary budget and the at least one auxiliary budget include at least one line item prior to administrative drawdowns.

Software implementing the invention can include a project module for creating and managing a project, a budget module for creating and maintaining a budget for the project, and a draw module for creating, scheduling and managing budgets for the project based on the budget. withdrawal.

A graphical user interface embodying the invention can include at least one of a project timeline progress bar representing progress relative to a date, a capital expenditure progress bar representing progress relative to a budgeted amount, and a percentage completion progress bar progress, and percent complete The progress bar represents the percentage of work that is done relative to the construction work.

Description of drawings

Fig. 1 is a schematic diagram of a construction payment management system according to an embodiment of the present invention.

FIG. 2 is a schematic diagram of a construction payment management process that can be performed using the system of FIG. 1 .

Figure 3 is a schematic diagram of the management engineering process.

Figure 4 is a schematic diagram of the management organization process.

Fig. 5 is a schematic diagram of the management withdrawal process.

Figure 6 is a schematic diagram of the process of managing change orders.

Fig. 7 is a schematic diagram of managing system environment tasks.

Figure 8 is a schematic diagram of the process of creating an organization.

Fig. 9 is an illustration of creating an organization form (form).

Figure 10 is an illustration of an update user system notification.

Fig. 11 is an illustration of a system notification.

Figure 12 is an illustration of the edit organization form.

Figure 13 is an illustration of an activation organization notification.

Figure 14 is an illustration of the start organization form.

Figure 15 is an illustration of an organization initiated notification.

Figure 16 is an illustration of an organization deactivation notification.

Figure 17 is a schematic diagram of the maintenance organization process.

Figure 18 is an illustration of the view organization screen.

Figure 19 is an illustration of the browse organization screen.

Figure 20 is an illustration of the edit organization form.

Figure 21 is an illustration of an organization profile update notification.

FIG. 22 is a schematic diagram of the create user process 172 .

Figure 23 is an example of creating a user form.

Figure 24 is an illustration of an update user profile notification.

Figure 25 is a schematic diagram of the maintenance user process.

Figure 26 is an illustration of the view user screen.

Figure 27 is an illustration of the browse user screen.

Figure 28 is an illustration of an edit user form.

Figure 29 is an illustration of a user profile update notification.

Fig. 30 is a schematic diagram of the process of creating a project.

Figures 31 and 32 are examples of creating project forms.

Fig. 33 is an illustration of a project creation notification.

Figure 34 is an illustration of an engineering user access screen.

Figure 35 is an illustration of an Engineering Responsibility Notice.

Figure 36 is a schematic diagram of the maintenance budget process.

Figure 37 is an example of entering the top-level budget form.

Figure 38 is an illustration of the Enter Withdrawal Date form.

Figure 39 is an illustration of the invoice code creation form.

Figure 40 is an illustration of the Assign Invoice Code form.

Fig. 41 is an illustration of receiving engineering notices.

Fig. 42 is an illustration of a receiving engineering form.

Figure 43 is an illustration of a project rejection notice.

Fig. 44 is an illustration of an engineering acceptance notice.

Fig. 45 is an illustration of the project home page.

Figure 46 is an illustration of adding a user notification.

Figure 47 is an illustration of an engineering user access form.

Figure 48 is an illustration of an Engineering Responsibility Notice.

Figure 49 is an illustration of a project budget viewing screen.

Fig. 50 is an illustration of an input budget form.

Figure 51 is a schematic diagram of the process of terminating a budget line.

Figure 52 is an illustration of entering the top-level budget form.

Figure 53 is an illustration of the Termination Budget screen.

Figure 54 is a schematic diagram of the withdrawal process.

Figure 55 is an illustration of creating a plan withdrawal notification.

Figure 56 is an illustration of an initial withdrawal form.

Figure 57 is an illustration of entering an invoice notification.

Figure 58 is an illustration of the input invoice form.

Figure 59 is an illustration of a signed invoice notification.

Figure 60 is an illustration of a signed invoice form.

Fig. 61 is an illustration of an invoice detail update notification.

Figure 62 is an illustration of the View Pending Withdrawal Requests screen.

Figure 63 is an illustration of an invoice line rejection notification.

Figure 64 is an illustration of an invoice not included in a withdrawal notice.

Figure 65 is an illustration of an automatically generated invoice form.

Figure 66 is an illustration of an affidavit form.

Figure 67 is an illustration of a Make Funds Available Notification.

Figure 68 is an illustration of the view withdrawal request screen.

Figure 69 is an illustration of a signature lien waiver notice.

Figure 70 is an illustration of a lien waiver form.

Figure 71 is an illustration of a signed notice of lien waiver.

Figure 72 is an illustration of the view withdrawal request screen.

Figure 73 is an illustration of all lien waiver signed notices.

Figure 74 is an illustration of viewing a withdrawal request form.

Figure 75 is an illustration of a payment disbursement notification.

Figure 76 is a schematic diagram of maintenance system screen tasks.

Figure 77 is an illustration of a maintenance stage code form.

Fig. 78 is an illustration of the management usage registration screen.

Figure 79 is an illustration of the Add/Edit Picklist form.

Figure 80 is an illustration of the Add/Edit Organization Role form.

Figure 81 is an illustration of the Default/Configuration Settings form.

Fig. 82 is an illustration of the edit notification form.

Figure 83 is an illustration of the Default/Configuration Process Form.

Figure 84 is an illustration of the Add/Edit User Task form.

Fig. 85 is a schematic diagram of performing an inspection process and related tasks.

Fig. 86 is an illustration of a notification of preparation for inspection.

Fig. 87 is an illustration of checking required notification.

Figure 88 is an illustration of the required inspection screen.

Fig. 89 is an illustration of input inspection report notification.

Fig. 90 is an illustration of an input inspection report form.

Fig. 91 is an illustration of an inspection report form screen.

Figure 92 is an illustration of an inspection report failure notification.

Figure 93 is an illustration of the view previous check screen.

Fig. 94 is a schematic diagram of a process for approving a withdrawal request.

Figure 95 is an illustration of a form authorizing a withdrawal request.

Figure 96 is an illustration of an authorized withdrawal request-rejection notification.

Fig. 97 is an example of a check confirmation notification.

Figure 98 is an illustration of a withdrawal detail modification notice.

Fig. 99 is an illustration of an inspection approval notification.

Figure 100 is an illustration of an authorized withdrawal request two notification.

Figure 101 is an illustration of the second form of authorization withdrawal request.

Fig. 102 is an illustration of the rejection notification of the authorized withdrawal request 2.

Fig. 103 is an illustration of authorization notification of withdrawal request 2.

Figure 104 is an illustration of issuing a lien waiver notice.

Figure 105 is a schematic diagram of a change request process.

Figure 106 is an illustration of a change request form.

Figure 107 is an illustration of change request notification.

Figure 108 is an illustration of an authorization change request notification.

Fig. 109 is a schematic diagram of a process change request process.

Figure 110 is an illustration of the View Pending Change Requests screen.

Figure 111 is an illustration of an authorization change request form.

Figure 112 is an illustration of a change request rejection notification.

Fig. 113 is an illustration of change request permission notification.

Figure 114 is a schematic diagram of the process of changing project participants.

Figure 115 is an illustration of the Change Party screen.

Figure 116 is an illustration of a withdrawal participant deletion screen.

Figure 117 is an illustration of the Change Affidavit screen.

Figure 118 is a schematic diagram of maintenance engineering screen tasks.

Figure 119 is an illustration of the project configuration file form.

Fig. 120 is an illustration of an engineering contract information screen.

Fig. 121 is an illustration of a project information screen.

Figure 122 is an example of closing the engineering screen.

Figure 123 is a schematic diagram of a task in the management access screen.

Fig. 124 is an illustration of a registration screen.

Figure 125 is an illustration of a logout screen.

Figure 126 is an illustration of the Project home screen.

Figure 127 is an illustration of the reset password screen.

Figure 128 is an illustration of a home screen for a specific user.

Figure 129 is an example of the browse project screen.

Figure 130 is an illustration of the Forgot Password screen.

Figure 131 is an example of your password notification.

Fig. 132 is a schematic diagram of the process of managing a message screen.

Fig. 133 is an illustration of the view message screen.

Figure 134 is an illustration of a particular message viewed by a user.

Figure 135 is an illustration of the Create/Send Message screen.

Figure 136 is an illustration of a status message screen.

137-153 are flowcharts illustrating a method of managing a project payment process according to another embodiment of the present invention.

154-179 are input/output diagrams illustrating a method of managing a project payment process according to another embodiment of the present invention.

Detailed ways

Before any embodiment of the invention is described in detail, it is to be understood that the invention is not limited in application to the details of construction and arrangement of parts set forth in the following description or illustrated in the drawings. The invention is still capable of other embodiments and of being practiced or carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of "comprising", "consisting of" or "having" and variations thereof is meant to encompass the items listed thereafter and equivalents thereof, as well as additional items. The terms "mounted", "connected" and "coupled" are used broadly and include direct and indirect mounting, connection and coupling. Additionally, "connected" and "coupled" are not limited to physical or organizational connections or couplings, and may include electrical connections or couplings, whether direct or indirect. Meanwhile, electronic communication and notification may be performed using any known means including direct connection, wireless connection, and the like.

It should be noted that the present invention can be implemented using a variety of hardware and software based devices, as well as a number of different structural components. Furthermore, and as described in subsequent paragraphs, the specific structures illustrated in the drawings are intended to illustrate embodiments of the invention, and other additional structures are possible.

Figure 1 illustrates a project payment management system (CPMS) 10 according to one embodiment of the present invention. The CPMS 10 can include an application server 12, a database server 14, an application logic module 16, a web server 18, a network 20 (such as the Internet or other networks alone or in combination with the Internet), an authentication service 22, participating organizations or individuals 24 (hereinafter , "participant" or "organization") and payment system 26. Payment system 26 can include an automated clearing house (ACH) system, a wire transfer system, a debit card system, a credit card system, or any other suitable electronic funds transfer (EFT) system.

The application server 12 can store and provide access to the engineering module 28, the form processing module 30, the permission and authorization engine 32, the database management system 34, the budget module 36, the access manager 38, the notification manager 40, the organization module 42, the withdrawal module 44, Access to Contracting Module 46 , Change Order Module 48 , User Module 50 , System Environment Manager 52 , and E-Deposit Box/Escrow 54 . The withdrawal module 44 can include a core module 56 , a check module 58 and a withdrawal authorization module 60 , and the system environment manager 52 can include a report generator 62 , a help module 65 and a system maintenance module 66 . Electronic safe deposit box/escrow 54 can store one or more lien waivers 68 . It should be understood that components of the application server 12 may be combined in different ways relative to those shown and described in FIG. 1 . The software encoding the various modules, managers and engines of application server 12 can be combined or separated and stored and accessed in any suitable manner.

Application server 12 can connect to database server 14 , application logic module 16 and authentication service 22 . However, in some embodiments, authentication service 22 may only be connected to network 20 . Application logic module 16 can be connected to web server 18 or, in some embodiments, directly to network 20 . Web server 18 is connectable to network 20 .

The parties 24 can include the owner 70 (and/or the owner's representative 72), a general contractor (GC) 74, a supervisor 76, one or more subcontractors (Subcontractor A 78, Subcontractor B 80, etc.), One or more material suppliers 82 , one or more lenders 84 (and/or one or more loan officers 86 ), one or more title insurance companies 86 , and one or more architects 88 . The parties 24 can also include one or more interior designers (and/or furniture manufacturers) and one or more real estate owners (ie, land owners who sell the site to the owner 70). Parties 24 can include organizations and/or individuals considered "online" (ie, above the GC during construction) or "offline" (ie, employed by the GC). Online parties 24 can include lenders, architects, interior designers, homeowners, homeowner representatives, title insurance companies, and real estate owners. Offline parties 24 can include subcontractors and material suppliers. The CPMS 10 can be used to facilitate the project payment process between any of these types of parties, whether online or offline for the GC. CPMS 10 is generally described herein as being used to facilitate payments between GCs and subcontractors. However, it should be understood that the CPMS 10 can be used to facilitate payments between any type of parties, not just between GCs and subcontractors.

In addition to dividing the parties into GC's online or offline, the costs related to the construction process can be divided into "soft" costs or "hard" costs. Soft costs can include superintendent fees, architect fees, interior design fees, title insurance company fees, permit fees, utility bills for the property during the construction process, furniture costs, audio/video equipment, computers, and the like. Hard costs can include all costs incurred by organizations or individuals employed by the GC, including all costs for subcontractors and material suppliers employed by the GC. Each construction project can include an overall budget (from the owner's point of view), including all soft and hard costs. Each construction project can also include a GC budget. CPMS 10 can be used to facilitate all payments made within the overall budget and GC budget. However, in some embodiments of the invention, the CPMS 10 may only be used to facilitate payment of hard costs managed by the GC (i.e., GC budget only). Those of ordinary skill in the art will appreciate that the CPMS 10 can be used to measure only the hard costs of the GC, only the soft costs of the GC's online parties, or both the hard and soft costs of the GC's online and offline parties. Combination to facilitate payment. Here, CPMS 10 is generally described with respect to hard costs, but can also be used for soft costs or a combination of hard and soft costs.

Each of the parties 24 can be connected to a payment system 26 . However, some participants 24 may not be connected to the payment system 26 in some embodiments of the invention. In some embodiments, payment system 26 can include one or more originating trusted financial institutions (ODFIs) and one or more receiving trusted financial institutions (RDFIs).

The parties 24 have access to the application server 12 in order to use the various modules, managers and engines to execute the project payment management method according to several embodiments of the present invention.

In some embodiments, the CPMS 10 can connect all project participants to a substantially unified, real-time, web-based system, can organize budgets for the construction project, can facilitate electronic submission and approval of invoices, and can and matching electronic lien waiver release products that automate and simplify the payment and lien waiver release process.

While variations in details are possible (eg, in a public finance project, the project is initiated and supervised by the security issuer, rather than the bank), one embodiment of the CPMS 10 can be used as follows. Loan officers can log on to the Internet and access the CPMS website. After security clearance, the loan officer can access the lender's portfolio and access a series of screens to create a new project by entering all project details. The loan officer can include details of the parties involved for each project, such as the owner, architect, general contractor, and title insurance company. Each party can receive email notifications of inclusion in the project and can verify their profile details. GC can add subcontractors and material suppliers. Subcontractors and material suppliers can receive notification of their addition to the project and can go through the safety and verification process. The GC can choose the withdrawal amount and withdrawal date for the project. CPMS 10 can notify participants of the pending withdrawal date in real time. Each party can complete their withdrawal request by entering their bill of materials and labor details. The GC can review and authorize withdrawal requests, and the CPMS 10 can generate pledges. A series of engineering site inspections, approvals, completion of lien waivers, generation of statements, etc. follow, all prompted by the CPMS 10 via real-time email notifications. CPMS 10 facilitates payments as long as all forms are completed and verified. The payment can be directly deposited into the bank account of the participant through the electronic payment system. Repeat the process for all withdrawals. Balance the project budget through the completion of payments, lien waiver collection, and approval checks. Project progress can be tracked through CPMS 10 using the graphical progress indicator.

CPMS 10 can include the following features: one-time registration of organizations joining CPMS 10, real-time notification of disbursements, automatic invoice generation, automatic affidavits, automatic lien waiver generation, coordinated payment/lien waiver release, and direct distribution of funds to participating organizations .

One-time registration of participating organizations to CPMS 10 can reduce the cost of participating services, because participants must only register once. One-time registration also reduces the number of potential errors because the entry must be done in one go. This makes it more likely that potential parties will actually participate, and when they do, they will have good (error-free) outcomes. The one-time registration helps to ensure that counterparties wishing to participate in the process and online groups using the process only need to register once to participate in any project for which payment is performed through CPMS 10 . CPMS 10 can create a stable group that can participate in the process of multiple projects over time by capturing organizational and personal information at one time, and improve the efficiency of registration for organizations to participate in the project payment process. This approach allows organizations to use the CPMS 10 to register as potential participants in any project initiated by members of the business community. In addition to the value of participating in multiple projects, a single registration is useful for participants to access information about multiple GCs, owners, lenders, subcontractors, and so on. For example, a one-time registration provides owners, lenders, and GCs the opportunity to learn about new subcontractors through CPMS 10. Also, an owner with several projects pending through different GCs can access information about each GC.

Real-time notification of withdrawals helps to ensure that all parties involved in a withdrawal 1) are notified in a timely and consistent manner, and 2) have a template to provide the information required for payment. CPMS 10 helps eliminate errors that delay the payment process (not being notified or mistaking which project the request came from). CPMS 10 by providing the GC with the option to maintain a withdrawal schedule on CPMS 10, by reducing the effort of notifying parties involved in withdrawals, by automating the process of building a list of parties for withdrawals, by automatically notifying withdrawals of withdrawals once announced Participant, to improve the efficiency of real-time notification of the withdrawal process by providing an easily accessible link to enable subcontractors to access the CPMS 10 to submit the documents required for the withdrawal.

CPMS 10 can be used by owners, owner representatives, lenders, GCs or title insurance companies to create and maintain project budgets. As noted above, the project budget can include soft costs for the GC online, hard costs for the GC offline, or a combination of hard and soft costs. Some embodiments of the CPMS 10 can also be used to create and manage change orders that modify budgets (usually by augmenting the budget) and approval of the modified budgets by the appropriate parties. The budget can include the total cost for the construction project, as well as project costs for each phase or activity that must be performed to complete the construction project. CPMS 10 can structure budgets to facilitate payment of subcontractors, allow efficient progress tracking, and allow automatic invoicing.

CPMS 10 can create automated invoices that correspond precisely to project budgets and also to lien waivers and affidavits. CPMS 10 can create automatic invoices as snapshots at the time of activity that has occurred relative to the overall project budget. CPMS 10 can be used to create automated invoices that correspond exactly to expenditure items in the overall budget. This results in invoices and reports consistent with the way construction work is broken down for financial purposes, tracking purposes, and the like. With CPMS 10, the invoice screens can be used to capture the information needed to create an invoice, however not all the information needed to create an invoice has to be re-entered as the information can be gathered by referencing the overall project budget. This also ensures that the invoice (and G702/703 document) will be consistent with the overall project budget, and will be consistent during drawdown, or any other time period (unless a party, such as the owner, wishes to modify the invoice). CPMS 10 can also be used to customize automated invoices (or G702/703 documents) according to the needs of lenders, owners, owners' representatives, GCs, etc.

Estimates and automated invoicing can be used to centrally collect and continuously reference information that will be used throughout the project payment management process. The information collected does not have to be re-entered again during the payment process, helping to ensure that errors are not introduced (keystrokes or due to misinterpretation of data). Typically, participating parties have visibility into the payment process implemented using the CPMS 10. This helps reduce the effort required to determine the status of the project and understand what work each party must do, facilitating the payment process. It is also helpful to highlight organizations or individuals that may habitually cause delays or errors in the process, making it easier to correct that behavior or weed out that party. Accurate Invoices minimizes invoice review and problem-solving labor, facilitates complete and accurate affidavits, minimizes discrepancies between affidavits and inspections, and enables timely payments. CPMS 10 can improve the efficiency of several activities later in the project payment process by capturing complete and consistent invoice information in a timely manner.

CPMS 10 can be used to generate automatic affidavits and automatic lien releases. Using CPMS 10, the GC knows who to notify for withdrawal and who responds by providing an invoice. As long as the invoice is approved by the GC (and any other party on the GC's line that must approve the invoice, such as the owner, owner's representative, lender, title insurance company, etc.), CPMS 10 can use the approved invoice to automatically generate affidavits and liens Right to waive. CPMS 10 can automatically generate affidavits and lien waivers for invoices submitted by subcontractors and material suppliers, helping to ensure that typographical errors are not introduced, and that affidavits and lien waivers will only include invoices that have been submitted by subcontractors and material suppliers Expenditure items submitted by vendors. CPMS 10 can help reduce the risk of inaccuracy in affidavits and lien waivers by overwriting invoices with details already stored in the system to automatically create affidavits and lien waivers. This process helps eliminate non-standard, incompatible and inappropriate invoicing and typographical errors that may occur during transcription. Collectively, this reduces risk indicators for the project payment process in a timely manner by increasing the accuracy of key construction project information. CPMS 10 can create automatic lien releases based on statutory criteria for the state of the construction site.

CPMS 10 can generate affidavits that correspond exactly to invoices. Certain types of workers performing the work (such as electricians, plumbers, etc.) often corrupt invoices, while parties performing the work (such as GCs, subcontractors, and material suppliers) often corrupt pledges. CPMS 10 can be used to ensure that the invoice total equals the affidavit total. Also, CPMS 10 can be used to ensure that the lien waiver amount is equal to the invoice amount since the information for automatic lien waiver is gathered from the approved invoice already stored in CPMS 10. Additionally, the lien waiver will be consistent with the affidavit, as the affidavit is generated by the CPMS 10 using information from the approved invoice. This is especially useful when the GC and subcontractor (or owner, lender and GC) have been arguing over the invoice amount and negotiating the final amount for some time. In automatic and approved invoices stored in CPMS 10, final amounts are reflected and used to generate lien waivers and affidavits. CPMS 10 ensures that only approved invoices are reflected in lien waiver and affidavit documents. Also by using the stored budget as the framework for all automated documentation, CPMS 10 further ensures that invoices, lien waivers and affidavits will be accurate and consistent. CPMS 10 can also be used to customize affidavits and lien releases based on the needs of lenders, owners, owners' representatives, GCs, etc.

CPMS 10 also helps increase the efficiency of generating affidavits and lien waivers, reducing the time and effort required to store and access them by offloading the storage of invoices, affidavits, and lien waivers to dielectric. Improve the overall efficiency of the project payment process by making these documents available to authorized parties required to perform their responsibilities. The database of CPMS 10 can store electronically signed invoices, affidavits and libraries of lien waivers. The participating parties can use the CPMS 10 to generate hard copies of any of the electronically signed documents, if desired.

In one embodiment, the CPMS 10 can create automatic invoices, affidavits and lien waivers as long as all information is entered and all issues resolved. In other embodiments, the CPMS 10 can first create an automatic invoice, ensure approval of the invoice, second create an automatic affidavit, ensure a signature affidavit, and third create an automatic lien release.

Once all information has been entered (invoices, inspection reports, bank details, etc.) and all issues have been resolved, the owner, owner's representative, lender, title insurance company, or GC can pay the drawing party. Subcontractors, material suppliers, or any other parties involved can offer their lien waiver in exchange for payment. The CPMS 10 can organize this process and can carry out the exchange automatically without the risk of one party being responsible and the other not. CPMS 10 also helps eliminate the need for costly and time-consuming in-person meetings to effect lien waivers for payment. CPMS 10 (Strong Tracking Documentation) also helps ensure that all lien waivers are collected. This reduces the risk of a lien waiver not being released at the conclusion of construction work due to poor record keeping. CPMS 10 can improve the efficiency of the payment/lien release release process by implementing the method in a network-enabled computer system. This allows all parties to securely customize payments and lien waivers in a trusted environment. CPMS 10 facilitates the efficient exchange of payments for lien waivers because CPMS 10 allows for tiered payments and lien waivers in preparation for an automatic exchange, reducing project-related risks. Can ensure that GC will receive an appropriate lien waiver consistent with payment and that subcontractors will not bear the risks associated with excessive delays in payment.

CPMS 10 can facilitate the exchange of lien releases and payment instructions. In some embodiments, the CPMS 10 can release the lien waiver substantially simultaneously with confirmation from the payment system 26 that the participant has received payment. As used herein and in the claims, the term "substantially simultaneously" includes any period of time (which would take up to about 72 hours) that is less than the time required to request, process and pay, transfer funds through an Automated Clearinghouse (ACH). For example, "substantially simultaneous" release of lien waivers may include immediate release of lien waivers, batch release of lien waivers at the end of the business day, or release of lien waivers after the usual period of time it takes for funds to be transferred through the ACH system. In one embodiment, the CPMS 10 can receive and store lien waivers in electronic safe deposit box/escrow 54 until all lien waivers have been received from all parties involved in the draw. Once all lien waivers have been received, CPMS 10 can send instructions for payment system 26 to transfer funds to each of the parties involved in the draw. For example, CPMS 10 can instruct payment system 26 to pay each subcontractor as long as all subcontractors electronically sign and submit their lien waivers to CPMS 10 . The CPMS 10 can release the lien waiver when payment instructions are communicated to the payment system 26 or only upon receipt of confirmation that the funds have actually been received by the participant.

If payment system 26 includes an ACH system, payment instructions are typically batched so that participants will not receive funds immediately. In an ACH system, payment instructions can usually be returned by the RDFI during a 48 hour period. During this 48-hour period, the RDFI can notify the CPMS 10 and the ODFI of the failure to transfer funds (eg, due to insufficient funds, invalid amount, etc.). After this 48 hour period, if the CPMS 10 has not been notified, the CPMS 10 can assume that the RDFI has processed the payment instruction. ODFI usually has a 24-hour front-end window to collect payment instructions from RDFI and the payment amount of the participating parties who release the withdrawal. Therefore, it takes approximately 72 hours from the time the CPMS 10 transmits the payment instruction until the ODFI transfers the funds to the participant's account.

In some embodiments, the CPMS 10 can flag certain parties for removal from the ACH system's batch, and can by another method, such as by direct wire transfer of funds or another instant type of electronic funds transfer, These parties are paid individually. In other embodiments, most parties can be paid by an instant type of electronic funds transfer, such as a direct wire transfer, but some parties can be combined with one or more ACH bulk transfers. In other embodiments, as CPMS 10 receives each lien waiver from each party, CPMS 10 can communicate each payment instruction to payment system 26 and can transfer funds directly to the party from which the waiver of lien was received. participants. In general, the CPMS 10 can control payment instructions in any suitable manner, and can use any suitable type of payment method.

In each embodiment of the present invention, CPMS 10 can establish a link between the current lien waiver and the current payment based on the current drawdown, rather than exchanging the previous lien waiver for the current payment of the current drawdown. For example, CPMS 10 can release the current month's lien waiver for the current drawdown, but not the prior month's lien waiver for the current drawdown. In this way, if CPMS 10 releases its lien waiver before making the payment, the subcontractor debt is not exposed, and if CPMS 10 makes the payment before the lien waiver is released, the owner (or GC, title insurance company) is not exposed. , lenders, etc.) debt.

Instead of paying the GC first, who in turn pays its subcontractors, who then pay their own subcontractors, use electronic distribution of funds (e.g. any appropriate type of EFT, ACH or wire transfer of funds ), which can directly pay each participant in CPMS 10. This speeds up the payment process (reduces costs) and reduces the risk of not paying the counterparty (in the system). Direct disbursement of funds is made possible by the CPMS 10 used to collect all the information required to make payments. Information collected using CPMS 10 can be trusted because of the accuracy of the method achieved through the software. Thus, direct disbursement of funds can be efficient (no duplication of effort or re-entry of information necessary) and error-free. CPMS 10 can improve the efficiency of the subcontractor/material supplier payment process by reducing the time taken to complete the payment process. CPMS 10 can reduce transaction costs by replacing direct payments with a tiered payment process while improving fiscal and managerial control. CPMS 10 can replace the use of checks with the electronic transfer of funds, reduce communication costs and improve the visibility of payment status and reduce the risk of improper or incomplete payment of all parties involved in the construction process (especially in the supply chain). low level).

2-7 illustrate an overview of the project payment management process that may be performed by the parties 24 using the various modules, managers, and engines stored in the application server 12 . FIG. 2 illustrates the Manage Engineering Process 94 (which can be performed by the Engineering Module 28 and/or the Budget Module 36), the Manage Drawout Process 96 (which can be performed by the Drawout Module 44), the Manage Change Order Process 98, Admin Initialization Process 100 (executable by Organization Module 42 and/or User Module 50), Admin System (executable by Access Manager 38, Notification Manager 40, and/or System Environment Manager 52) Environment process 102.

FIG. 3 illustrates the manage engineering process 94 , which can include create engineering tasks 104 , maintain engineering tasks 106 , and create budget tasks 108 . FIG. 4 illustrates a manage organization process 100 , which can include create organization tasks 112 , maintain organization tasks 114 , create user tasks 116 , and maintain user tasks 118 . FIG. 5 illustrates the manage drawout process 96, which can include an initialize drawout task 120, create drawout request task 122, pay funds task 124, execute check task 126, and approve drawout request task 128. FIG. 6 illustrates the manage change order process 98 , which can include a create change request task 130 , a process change request task 132 , and a change party task 134 . Figure 7 illustrates Manage System Environment tasks 102, which can include Manage Access task 136, Manage Messages task 138, Create Reports task 140, Provide Help task 142, and Maintain System tasks. Create reports task 140 is performed by any party on or off the GC to create custom reports related to the progress of the construction work, including the ability to monitor parts of the construction work, specific parties, the overall project, and so on.

8-136 illustrate project payment management methods according to several embodiments of the invention. FIG. 8 illustrates a create organization process 146 that can be included in the manage organization process 100 . Using the organization module 42 , a create organization process 146 is performed by any party 24 . Create Organization process 146 can include Create Organization Task 148 , Update Organization Profile Task 150 , Edit Organization Task 152 , Validate Organization Notification 154 , Validate Organization Task 156 , and Organization Rejection Task 158 or Organization Initiation Task 160 . An update user profile task 162 can also be performed, as described with reference to FIG. 22 .

FIG. 9 illustrates a create organization form that can be associated with create organization task 148 . Through the organization module 42, each participant 24 has access to create an organization form. Participant 24 can enter requested information, such as company information, primary contact information, tax information, and bank account information. In some embodiments, the first user of a participating organization 24 who enters his or her information as primary contact information is considered an administrator for that party 24 and has more access than subsequent users to the Information about the parties. CPMS 10 can use comprehensive role-based security so that project participants see only the information in the project that is relevant to their specific needs. As long as an organization is registered in CPMS 10, that organization can receive payment for any project managed by CPMS 10.

FIG. 10 illustrates notifications that can be transmitted during the update user profile task 162 . As used herein and in the appended claims, the term "system notification" or "notification" or "system message" refers to any form of communication with a party, such as email messages, screen notifications, text messages, voice messages, etc. wait. The system notification of FIG. 10 can include a username and temporary password for the first user of party 24 .

FIG. 11 illustrates notifications communicated during an update organization profile task 150 . The notification of FIG. 11 can be sent to the administrator for that party 24 . The notification can include a statement indicating the recipient to update the organization profile and add the user prior to participating in the project, as well as provide bank details.

FIG. 12 illustrates an edit organization form that can be associated with an edit organization task 152 . Each participant 24 can modify existing information such as company information, primary contact information, tax information, and bank account information. In some embodiments, the first user of participating organization 24 who enters his or her information as primary source information is the only user with access to the edit organization form.

FIG. 13 illustrates an effective organization notification communicated during the effective organization notification task 156 . The notification of Figure 13 can include a statement that the organization's details have been updated and a request to verify and activate the organization.

FIG. 14 illustrates an active organization form that can be associated with an active organizational task 156 . The form of FIG. 14 can include a list of parties 24 (including, for example, organization name, role in the construction process, ability to select parties 24, and ability to view party 24 information). The form of FIG. 14 could also include a "lookup" feature, the ability to specify the type of party 24, and the ability to reject/deactivate a selected organization and provide a reason for the denial/deactivation.

FIG. 15 illustrates an organization-initiated notification that can be communicated during an organization-initiated task 160 . Similarly, FIG. 16 illustrates an organization rejection notification that can be communicated during an organization rejection task 158 .

FIG. 17 illustrates a maintain organization process 162 that can be included in the manage organization process 100 . The maintain organization process 162 can be used by the organization itself or other parties in order to maintain the accuracy of contact information, bank account information, or other types of information required for the project payment process. Using the organization module 42, the maintain organization process 162 can be performed by any party. The maintain organization process 162 can include browse organization tasks 164 , edit organization tasks 166 , organize update tasks 168 , and view organization tasks 170 .

FIG. 18 illustrates a view organization screen that can be associated with view organization tasks 170 . The View Organization screen can include company information and primary contact information for the organization.

FIG. 19 illustrates a browse organization screen that can be associated with a browse organization task 164 . The Browse Organization screen can include a list of parties involved, including the organization's name, the organization's role in the construction process, key contacts, and phone numbers. The browse organization screen can include a "look up" feature and links for browsing additional information about each party. In one embodiment, the browse organization screen can be used by the GC to view its best subcontractors or material suppliers.

FIG. 20 illustrates an edit organization form that can be associated with an edit organization task 166 . Participants can edit existing information, including company information, primary contact information, tax information, and bank account information. In some embodiments, the first user of the organization who entered his or her information as primary contact information is the only user with access to the edit organization form.

FIG. 21 illustrates an organization profile update notification that can be communicated during an organization update task 168 . The notification of FIG. 21 can include information about the updated configuration file for the party as well as the name of the primary user or administrator of the party.

FIG. 22 illustrates a create user process 172 that can be included in the manage organization process 100 . The Create User process 172 can be used each time a new user of an existing organization is created in order to allow the new user proper access to the CPMS 10 (e.g., with an appropriate level of security for a user ID and password). The create user process 172 can also be used to update user profiles. Using the organization module 42 , the create user process 172 can be performed by any party 24 . Create User process 172 can include Create User task 174 and Update User Profile task 176 .

FIG. 23 illustrates a create user form that can be associated with a create user task 174 . In some embodiments, a create user form may be used to add users after a first user or administrator has been created for the party. New users can enter personal information, security information (such as username and password), email notification preferences, and security clearance level (such as whether the user is allowed to manage projects and/or sign documents).

FIG. 24 illustrates an update user profile notification that can be transmitted during the update user profile task 176 . The notification of FIG. 24 can include a statement that the user has been added as a member of the organization, as well as the user's security information (eg, username and temporary password).

FIG. 25 illustrates a maintenance user process 178 that can be included in the message organization process 100 and continues from FIG. 22 . The maintain users process 178 can be used to browse and view, edit and update users in each organization. Using the organization module 42, the maintain user process 178 can be performed by any party. The maintain user process 178 can include browse user tasks 180 and edit user tasks 182 , user profile update tasks 184 and view user tasks 186 .

FIG. 26 illustrates a view user screen that can be associated with view user tasks 186 . The View User screen of Figure 26 can include the user's personal information, email notification preferences, and security clearance level.

FIG. 27 illustrates a browse user screen that can be associated with a browse user task 180 . The Browse Users screen of FIG. 27 may include a list of one or more users for each party, and may include usernames, email addresses, and phone numbers. Browsing the user screen can also include links to edit information for each user.

FIG. 28 illustrates an edit user form that can be associated with an edit user task 182 . Users can provide personal information, email notification preferences, and security clearance levels.

FIG. 29 illustrates user profile update notifications that can be communicated during a user profile update task 184 .

FIG. 30 illustrates a create engineering process 188 that can be included in the manage engineering process 94 . The create project process 188 can be performed by the GC, lender, owner, or owner's representative using the engineering module 28 to start a new project in the CPMS 10. Create engineering process 188 can include create engineering task 190 , engineering setup task 192 , engineering user access task 194 , and engineering responsibility task 196 .

31 and 32 illustrate create engineering forms that can be associated with create engineering tasks 190 . The GC, lender, owner or owner's representative can provide project identification information, project financing information, project owner information, project architect information, and site information.

FIG. 33 illustrates project creation notifications that can be communicated during a project creation task 192 . The notification of Figure 33 can include a statement that the GC, lender, owner, or owner's representative has created a new project, and a link to a screen that allows users from parties to be assigned to the project.

FIG. 34 illustrates an engineering user access screen that can be combined with the engineering user access task 194. The project user access screen can include project name, project number, GC name, and a list of project-specific and/or organization-specific users. Users are identified by name and username, and can be considered project administrators or signers.

FIG. 35 illustrates an engineering responsibility notification that can be communicated during an engineering responsibility task 196. The notification of Figure 35 can include a statement that the user's responsibilities with respect to the project have been modified.

FIG. 36 illustrates a Maintenance Budget process 198 that can be included in the Manage Engineering process 94. The maintenance budget process 198 can be used to create and view top level budgets for construction projects, assign expenditure items to parties, and assign responsibilities to parties. Using the budget module 36, the maintenance budget process 198 may be performed by the GC on the subcontractor or by the subcontractor on the secondary subcontractor or material supplier. Maintain Budget Process 198 can include Enter Top Level Budget Task 200, Receive Project Task 202, Receive Project Forms Task 204, Project Reject Task 206, Add User Task 208, Project Receive Task 210, Project Home Page Task 211, Project User Access Task 212, Project Responsibility task 214 and project budget review task 216 . If the project is rejected, the maintenance budget process 198 can include an input budget task 218 and can return to the receive project task 202 . After entering the top-level budget task 200 , the maintain budget process 198 can include an invoice code setup task 220 , an enter draw date task 222 , and an assign invoice code task 224 .

FIG. 37 illustrates the Enter Top-Level Budget form that can be associated with the Enter Top-Level Budget task 200 . Entering the top-level budget form can include project name, project number, and contract value. GC or subcontractor can provide reserve percentage value, stage code, stage code description, organization name, budget amount and account code. The GC or subcontractor can specify whether the organization is providing the material. Access to the top-level budget form may also include links to the Set Draw Date and Set Invoice Code screens/forms. Phase codes and phase code descriptions can be used to define contractual requirements for each specific activity that must be completed in order to complete the project. For example, phase codes and phase descriptions can be provided through the American Institute of Architects (AIA), through the Building Specification Agreement (CSI), or through custom AIA or CSI phase codes and phase descriptions. In some embodiments, the phase codes and phase descriptions can be fully customized by the parties. Top-level budgets may also be referred to as price plans, agreed costs (after the GC has received bids from subcontractors), or engineering estimates. In some embodiments, the stage codes included in the top-level budget provide the basis for drawdown requests, since each drawdown request includes a specific expenditure item associated with a particular stage code. In some embodiments, the GC can use an external software program to generate the budget and the budget module 36 can interact with the external software program to enter the budget into the application server 12 or the database server 14 .

FIG. 38 illustrates an Enter Withdrawal Dates form that can be associated with the Enter Withdrawal Dates task 222 . The GC or subcontractor can enter the days of the month when the payout will be made, as well as a specific date for the payout (eg, on a specific day of the month). The input withdrawal date form can also include a withdrawal date calculation button for automatic calculation of the withdrawal date and/or a withdrawal date addition button for manual entry of the withdrawal date.

Figure 39 illustrates an invoice code setup form that can be associated with the invoice code setup task 220. GC or Subcontractor can select invoice codes (e.g. codes by building - building 1, 2 or 3), enter new invoice codes, create invoice codes, enter budget line display preferences (e.g. by phase code) , and enter preferences for printing selections. With CPMS 10, the invoice code setup form facilitates the automatic generation of invoices and affidavits. Invoice codes can be used for custom reporting or to interface with other types of existing software. Invoice codes can allow parties to categorize budget expenditure items based on the needs of architects, owners, and the like. Account codes can be used to maintain budgets, record withdrawals, or facilitate invoicing and payments.

FIG. 40 illustrates an Assign Invoice Codes form that can be associated with the Assign Invoice Codes task 224. The GC or subcontractor can provide an invoice code (eg Construction 1, 2 or 3) and can use links to access subbudgets for each phase code. The Assign Invoice Code form can include the project name, project address, stage code, stage code description, organization contracting the job, and budgeted amount. The Assign Invoice Code form also facilitates the automatic generation of invoices and affidavits through CPMS 10.

FIG. 41 illustrates a receipt engineering notification that can be related to a receipt engineering task 202 . The notification of Figure 41 can include a statement that the subcontractor or material supplier has been added as a party to the project, a description of the project and details of the subcontractor or material supplier's participation. The subcontractor or material supplier can accept or reject the project using the link to access the accept project form shown in FIG. 42 .

FIG. 42 illustrates a receiving engineering form that can be associated with the receiving engineering form task 204 . The receiving project form can include GC project number, system project number, GC name, project name, project address and budget expenditure items. The receiving engineering form can provide subcontractors or material suppliers with engineering information and budget expenditure items. Subcontractors or material suppliers can use the Accept or Decline buttons to accept or reject works related to budget expenditure items. Subcontractors or material suppliers can also provide reasons for rejecting the work. Expenditure items from receiving engineering forms can also be used through CPMS 10 to facilitate automatic generation of invoices and affidavits.

FIG. 43 illustrates an engineering rejection notification communicated during the engineering rejection task 206 . The notification of Figure 43 can include the name of the subcontractor or material supplier who has rejected the project, the budget item rejected and the reason for the rejection. The notification of Figure 43 may provide the ability to assign an organizational role to another party.

FIG. 44 illustrates engineering receipt notifications that can be communicated during the engineering receipt task 210 . The notification of Figure 44 can include the name of the subcontractor or material supplier who has accepted the work and the budget line received. The notification of Figure 43 can provide the ability to access project details.

FIG. 45 illustrates an engineering home page that can be associated with the engineering home page task 211 . The project home page can include the project name, completed withdrawal information, and pending withdrawal information. The project home page can include a project overview with a project timeline progress bar, a funding progress bar, and a percent complete progress bar. The project home page can include one or more links to specific actions performed with respect to the project (eg, project configuration file, project budget, view project parties, set invoice codes, manage project users, initiate unplanned withdrawals, etc.).

FIG. 46 illustrates an add user notification communicated during the add user task 208 . The notification of Figure 46 can include a statement confirming that a subcontractor or material supplier has joined the project. The notification of Figure 46 can include a request for a subcontractor or material supplier to add a user (eg, a member of an organization) to the system.

FIG. 47 illustrates an engineering user access form that can be associated with an engineering user access task 212. Subcontractors or material suppliers can select security permissions for each user (eg, project administrator or signer). The project user access form can include project name, GC name and user list for subcontractor or material supplier organization.

FIG. 48 illustrates an engineering responsibility notification that can be related to an engineering responsibility task 214 . The notification of Figure 48 can include a statement that the user's responsibilities have been modified, as well as new security approvals. The notification of Figure 48 can include a link to access the project budget.

FIG. 49 illustrates a project budget review screen that can be associated with the project budget review task 216 . The GC or subcontractor can access the project budget viewing screen through the budget module 36 . The project budget view screen can include project name, GC name, project address, and a list of budget items. A list of budget items can include a phase code, a description of the phase code, subcontractors or material suppliers contracting for the budget item, budget amounts, payments, encumbrances, balances, and links to any sub-budgets.

FIG. 50 illustrates an input budget form that can be associated with the input budget task 218 . The GC or subcontractor can access the input budget form through the budget module 36 . The GC or subcontractor can enter requested information such as stage codes, stage code descriptions, and budget amounts. A GC or subcontractor can change the organization associated with a particular budget expenditure item. The GC or subcontractor can choose whether the organization will only provide the material.

FIG. 51 illustrates the End Budget Lines process 226 that can be included in the Manage Engineering process 94. The terminate budget line process 226 can be performed by a GC or a subcontractor. Terminate budget line process 226 can include entering top-level budget task 228 and finalizing budget task 230 .

FIG. 52 illustrates the Enter Top-Level Budget form that can be associated with the Enter Top-Level Budget task 228. The GC or subcontractor can access the top-level budget form through the budget module 36 . Entry into the top-level budget form may include project name, project number, contract value, and organization listing. The GC or subcontractor can enter requested information such as retention percentage, stage code, stage code description, account number, and whether the organization is only supplying material. The GC or subcontractor can also choose to add new expenditure items or terminate specific expenditure items. Access to the top-level budget form may include links to a Set Draw Date form and/or a Set Invoice Code form.

FIG. 53 illustrates a termination budget screen that can be associated with the termination budget task 226. FIG. After the GC or subcontractor selects a finalized expense line, the finalized budget screen provides confirmation and statement that enables any unpaid balances to be available for reallocation.

FIG. 54 illustrates a withdrawal process 232 that can be included in the manage withdrawal process 96. Withdrawal process 232 can be used to create a schedule for project withdrawals, initiate each withdrawal, enter and sign invoices, view pending withdrawals, generate invoices, affidavit and lien releases, determine availability of funds, and disburse funds. The payout process 232 may be performed by several parties using the payout module 44 . Withdrawal process 232 can include create withdrawal time form task 234, initialize withdrawal task 236, enter invoice task 238, enter invoice form task 240, sign invoice task 242, update invoice detail task 244, view pending withdrawal request task 246, generate invoice Task 248, Affidavit Form Task 250, Funds Available Task 252, View Withdrawal Request Task 254, Signature Lien Waiver Task 256, Lien Waiver Form Task 258, All Lien Waiver Signature Task 260, View Withdrawal Request via Pay Funds Button Task 262 , Paid Payment Amount task 264 , Signed Lien Waiver task 266 , View Drawout Request task 268 . The debit process 232 may also include received payment detail tasks 270 , invoices not included in the debit task 272 , and unreceived payment detail tasks 274 . The withdrawal process 232 may be performed to release the lien waiver for the current withdrawal but not for the previous withdrawal.

FIG. 55 illustrates a create plan payout notification that can be communicated during the create drawdown schedule task 234. The notification of FIG. 55 can be communicated in real time to all drawout participants and can include a statement that a planned payout is pending and parties that have not yet been selected for the drawout.

FIG. 56 illustrates an initialization payout form that can be associated with the initialization payout task 236. The GC can access the initial withdrawal form through the withdrawal module 44. The initial withdrawal form can include project name, project number, project address, withdrawal amount, withdrawal date, and a list of potential parties for the withdrawal. The list of potential parties can include stage codes, stage code descriptions, organization names, budget amounts, payment amounts, accrued deductions, and balances. GC can choose each participant to withdraw.

FIG. 57 illustrates the input invoice notifications that can be transmitted during the input invoice task 238. The notification of Figure 57 can include a statement that a drawdown has been planned for the work and that the subcontractor or material supplier has entered details of the amount payable. The notification can include organizational roles and specific budget items for subcontractors or material suppliers. The notification can be transmitted to all withdrawal participants in real time.

FIG. 58 illustrates an Enter Invoice Form that can be associated with the Enter Invoice Form task 240 . Subcontractors or material suppliers can use the Enter Invoice form to provide invoice amounts for this debit. The input invoice form can also include project name, project number, project address, billed amount, billed date, and specific expense items for that subcontractor or material supplier.

Figure 59 illustrates a signed invoice notification that can be sent to the GC during the signed invoice task 242. The notification of Figure 59 can include a statement that the subcontractor or material supplier has approved the invoice for a particular payout and an affidavit must be signed. The CPMS 10 can be used to assign security/authorization roles to each user, such as administration, accounting or authorized signatures. The CPMS 10 can notify the user of the authorization to sign an affidavit, so that an affidavit can be signed by a member of the organization if necessary. CPMS 10 can be used to change the security/authorization roles required for signing affidavits (eg lenders can require signing affidavits, not administrators of the organization).

FIG. 60 illustrates a Sign Invoice form that can be associated with the Sign Invoice task 242. The GC has access to signed invoices through the withdrawal module 44 . GC can view the details of the invoice, such as specific organization, request amount, budget amount, payment amount, deduction and balance. The GC can then choose to sign the invoice statement. A signed invoice form can include a link to an automated affidavit form.

Figure 61 illustrates an invoice detail update notification that can be sent to the GC during the invoice detail update task 244. The notification of FIG. 61 can include a statement that the subcontractor or material supplier has updated the payment details for payment on a specific date for a specific project. The notification can include a link to view invoice details.

FIG. 62 illustrates the View Pending Withdrawal Requests screen that can be associated with the View Pending Withdrawal Requests task 246. FIG. The GC can access the View Pending Withdrawal Requests screen through the Withdrawal Module 44 . The GC can select each party to be included in the withdrawal, confirm the withdrawal, and send notifications to each organization's signers in real time. However, the GC can also reject pending withdrawal requests, notify selected parties to re-enter the invoice and provide reasons for rejecting the withdrawal request. View pending withdrawal requests screen can include project name, project number, project address, withdrawal amount, withdrawal date, a list of parties that have submitted invoices, and a list of parties that have not yet mentioned invoices. Participants can be organized by phase code. For each stage code, the View Pending Withdrawal Requests screen can include requested amounts, budgeted amounts, paid amounts, debits, and balances.

FIG. 63 illustrates an invoice line rejection notification that can be transmitted during the Unreceived Payment Amount task 274. The notification of FIG. 63 can include a statement that payment and invoice details to be entered by the particular user of the draw were not received on the date for the particular project and the reason for the rejection. Notifications can include requests by subcontractors or material suppliers to re-enter payment details before drawouts are closed.

FIG. 64 illustrates an invoice not included in a withdrawal notification that can be transmitted during the Invoices not included in withdrawal task 272. The notice of Figure 64 can include an affidavit of approval that the parties have not submitted a payment for the Works, and a statement that the parties and all their subcontractors will not be included in the payment. The notice can state that all affidavits and invoices submitted have been revoked.

Figure 65 illustrates an automatically generated invoice form (eg, a form consistent with industry practice, such as a G702/703 form) that can be associated with the Generate Invoice task 248 (labeled G702/703 in Figure 54). GCs, subcontractors and material suppliers can access the invoice form through the withdrawal module 44. Subcontractors, material suppliers, and/or architects can sign invoice forms electronically (eg, using products from electronic signature software providers such as AlphaTrust Corporation).

FIG. 66 illustrates an automatically generated affidavit form that can be associated with the affidavit form task 250. The GC can access the affidavit form through the withdrawal module 44. The GC can sign the affidavit form electronically (for example using a product from an electronic signature software provider such as AlphaTrust Corporation).

FIG. 67 illustrates a funds available notification that can be sent during the funds available task 252. The notice of FIG. 67 includes instructions, a link to follow to request a lien waiver and to release the funds when they are available to release the drawdown on the works.

FIG. 68 illustrates a View Payout Requests screen that can be associated with the View Payout Requests task 254. The GC can access a view withdrawal request screen through the withdrawal module 44 . GCs can view details of withdrawals, authorize funds, and request lien releases. View withdrawal request can include project name, project number, project address, withdrawal amount, withdrawal date and withdrawal party list. The party list can include party name, phase code, whether a lien waiver has been received, requested amount, budgeted amount, paid amount, chargeback, and balance. The party list can also include any subcontractors and their lien waivers.

FIG. 69 illustrates a signature lien waiver notification that can be communicated during the signature lien waiver task 256. The notification of FIG. 69 can be transmitted in real time to all drawing participants and can include a statement that has authorized drawing of the project plan and requested that the subcontractor or material supplier sign its lien waiver to accept the drawing request.

Figure 70 illustrates an automatically generated lien waiver form that can be associated with the lien waiver form task 258. Subcontractors and material suppliers can access the lien waiver form through the withdrawal module 44 . Lien waiver forms can be automatically generated based on budgets, including expenditure items for each subcontractor or material supplier. Subcontractors and material suppliers can electronically sign lien waiver forms (eg, using AlphaTrust Corporation's electronic signature product). Lien release 68 can be stored in electronic safe deposit box/escrow 54 as long as it is signed.

FIG. 71 illustrates a lien waiver signature notification that can be communicated during the lien waiver signature task 266. The notice of FIG. 71 can include a statement that the subcontractor or material supplier has signed their lien waiver for payment of the works. The notice may include access to a breakdown of the disbursements and lien waivers received to date.

FIG. 72 illustrates a View Payout Requests screen that can be associated with the View Payout Requests task 268. A GC, subcontractor, or material supplier can access a view payout request screen through the payout module 44 . View withdrawal request screen can include project name, project number, project address, withdrawal number, withdrawal date and withdrawal party list. The party list can include party name, phase code, whether a lien waiver has been received, requested amount, budgeted amount, paid amount, chargeback, and balance. The party list can also include any subcontractors and their lien waivers.

FIG. 73 illustrates an all lien waiver signed notice that can be transmitted during a signed all lien waiver 360. The notice of Figure 73 can include a waiver of all liens that have been signed for disbursement of the Works. Notifications can include links to view withdrawal details and disburse funds.

Figure 74 illustrates a View Payout Request form that can be associated with the View Payout Request task 363 with a Pay Funds button. The GC (or architect, owner, owner's representative, lender or title insurer) can access the withdrawal request form and approve the withdrawal through the withdrawal module 44 and/or the withdrawal approval module 60. The view withdrawal request screen can include a project name, project number, project address, withdrawal number, withdrawal date, and a list of withdrawal participants. The list of parties can include party name, phase code, whether to accept lien waiver, requested amount, budgeted amount, paid amount, chargeback, and balance. The party list can also include any subcontractors and their lien waivers. When the GC disburses the funds, the lien waiver is released and payment instructions are sent to the ACH system 26 substantially simultaneously.

FIG. 75 illustrates a payment payment notification transmitted during a payment payment task 264. The notification of FIG. 75 can be transmitted in real time to all drawout parties and can include a statement that a planned drawdown for a specific date for the project has been paid.

FIG. 76 illustrates a Maintain System screen task 276 that can be included in the Manage System Environment process 102. The Maintain System screen task 276 can be used by each user or each organization to customize the software environment to specific needs. For example, organizations can customize phase codes for their projects. The maintain system screen task 276 can be performed by any party using the system environment manager 52 . Maintain system environment task 276 can include maintenance stage code task 278, administrator user login task 280, add/edit parameter selection form task 282, add/edit organization role task 284, default setting task 286, edit notification task 288, default configuration task 290 and Add/Edit User Role Task 292.

FIG. 77 illustrates maintenance phase codes that can be associated with maintenance phase code tasks 278. Each participant can access the maintenance phase code through the system environment manager 52 . Participants can add new or delete selected budget items.

FIG. 78 illustrates an administrative user login screen that can be associated with an administrator user login task 280. Each participant can access the administrator user login screen through the system environment manager 52 . Users of the organization can enter a user name and use this screen to log on to the system as any user in the system.

FIG. 79 illustrates an Add/Edit Pickles form that can be associated with the Add/Edit Pickles task 282. The CPMS 10 administrator can add new or delete selected pickle items (eg, status list, project type, etc.) for the various drop-down menus provided by CPMS 10.

FIG. 80 illustrates an Add/Edit Organization Role form that can be associated with the Add/Edit Organization Role task 284. The GC can access the Add/Edit Organizational Roles form through the System Environment Manager 52 . GCs can choose security clearances for each type of organization (eg bank, title insurance company, GC, subcontractor, or architect).

FIG. 81 illustrates a default/configuration setup form that can be associated with the default setup task 286. The GC can access the default/configuration settings form through the system environment manager 52 . The GC can enter its preferred settings, such as withdrawal close reminder days, withdrawal start reminder days, minimum lead time for withdrawal requests, security flags, whether the supervisor will pay through the ACH system, whether to wait for all liens to be waived, and who will pay the supervisor (e.g. bank, title insurance company, owner, owner's representative or GC).

FIG. 82 illustrates an edit notification form that can be associated with the edit notification task 288. The GC can access the edit notification form through the system environment manager 52 . The GC can modify the notifications sent during various processes. GC can select specific notifications and edit default notifications as needed. The GC can also specify whether certain authorizations are necessary, such as authorization by the bank to change notifications.

FIG. 83 illustrates a default/configuration process form that can be associated with the default configuration task 290. GCs, owners, owners' representatives, lenders, etc. can access default/configured process forms through the system environment manager 52 in order to customize or change the principles used for parts of the construction payment process. For example, the GC can define and store its own phase codes. The GC, owner, owner's representative, lender, etc. can choose whether to initiate specific tasks in each process and can access links for each to edit notifications related to the task.

FIG. 84 illustrates an Add/Edit User Role form that can be associated with the Add/Edit User Role task 292. The GC can access the Add/Edit User Role form through the System Environment Manager 52. GC can select roles for specific users, such as system administrator, system help user, local administrator, regular user, and view-only access. GC can add new roles or remove selected roles.

FIG. 85 illustrates an Execution Check task 294 that can be included in the Manage Drawout process 96. Execute inspection tasks 294 can be used to plan and facilitate inspections of construction work, if necessary, prior to each withdrawal. Perform check task 294 can be performed by check module 58 of GC and supervisor usage drawout module 94 . Perform inspection tasks 294 can include inspection required tasks 296, inspection required forms tasks 298, prepare to perform inspection tasks 300, review previous inspection tasks 302, enter inspection tasks 304, enter inspection report tasks 306, inspection report form tasks 308, and inspect Report failed task 310.

FIG. 86 illustrates a ready to conduct inspection notification that can be transmitted during the ready to conduct inspection notification task 300 . The notice of Figure 86 can include a statement that a project plan has been drawn on a certain date and that the supervisor is required to conduct an inspection of the readiness for the draw. The notification can state that inspections should only be performed after confirmation of receipt.

FIG. 87 illustrates inspection required notifications that can be transmitted during the inspection required notifications task 296. The notification of FIG. 87 can include a statement that the planned withdrawal is pending work and a link specifying whether the withdrawal requires review.

Figure 88 illustrates a required inspection screen that can be associated with the inspection required task 298. The GC (or the owner, owner's representative, lender or title insurance company) can access the required inspection screens through the inspection module 58 of the drawout module 44 . Required check screens can include project name, project number, withdrawal number, owner name, withdrawal date, project address, and a list of parties involved. The party list can include request amount, organization name, organization role, budget item, budget amount, payment amount, chargeback, and balance. Required inspection screens can also include general comments, supervisor's comments, and whether inspections should be scheduled.

FIG. 89 illustrates an input inspection report notification that can be transmitted during an input inspection task 304. The notification of Figure 89 can include a date-by-date drawdown schedule for the work that has been authorized and that the recipient should proceed with inspections. Notifications can include links to view project details and generate checklists.

FIG. 90 illustrates an input check report form that can be associated with the input check report task 306 . Supervisors can enter inspection details on the inspection report form. The inspection report form can include project item, project number, withdrawal number, withdrawal date, owner name, project address, inspection date and general inspection notes.

FIG. 91 illustrates an inspection report form screen that can be associated with the inspection report form task 308. The inspection report form screen can be accessed through the inspection module 58 of the withdrawal module 44 by the GC, the owner, the owner's representative, the title insurance company, or the superintendent.

FIG. 92 illustrates inspection report failure notifications that can be communicated during the inspection report failure task 310 . The notification of Figure 92 can include that there is a high level of concern for the project following inspections performed on a particular date. The notification can include a link to access the inspection report form.

FIG. 93 illustrates the view previous exams screen that can be associated with the view previous exams task 302 . The GC, owner, owner's representative, title insurer, or supervisor can access a previous inspections screen through the inspection module 58 of the withdrawal module 44 and can select inspections to be performed on specific dates.

FIG. 94 illustrates an Approved Withdrawal Request process 312 that can be included in the Manage Withdrawal process 96. The Approve Drawout Request process 312 can be used to confirm that the necessary checks are performed to authorize each drawdown in the construction payment process and to issue a lien release. Using the drawout approval module 60 of the drawout module 44, the approve drawout request process 312 can be performed by the GC and/or any party on the GC line, such as the owner, owner's representative, title insurance company, architect, etc. CPMS 10 can be used to authorize any type of payment related to the construction process as long as work has been initiated. CPMS 10 can provide parallel approval (eg the GC and owner must approve the draw down) or serial approval (eg the architect must approve the draw down, then the owner, then the lender). CPMS 10 can be used to configure the approval process for each project. CPMS 10 can be used to approve change orders for budgeting or specific amounts agreed between parties. For example, the CPMS 10 can be used to obtain approval from the GC and/or any of the GC's on-line participants for change orders above a certain amount or approval of all change orders above that limit. Approval withdrawal request process 312 can include authorization withdrawal request one task 314, authorization withdrawal request one-rejection task 316, check and confirmation task 318, check authorization task 320, payment details modification task 322, authorization withdrawal request two-notification task 324, authorization withdrawal Request Two Task 326 , Authorize Withdrawal Request Two Reject Task 328 , Authorize Withdrawal Request Two Approve Task 330 , and Issue Lien Waiver Task 332 .

FIG. 95 illustrates an Authorization Withdrawal Request-Form or Authorization Affidavit Form that can be associated with the Authorization Withdrawal Request-Task 314. Through the withdrawal module 44, the GC, the owner, the owner's representative, or the title insurance company can access an authorized withdrawal request form. The authorized withdrawal request form can include project name, project number, owner, project address, withdrawal number and withdrawal date. Authorized Withdrawal Requests—a form can include any input for each organization, including request amount, organization name, organization task, budget item, budget amount, payment amount, debit, and balance. Authorization Withdrawal Request - A form can include authorizations that can be received, authorizations that are outstanding, whether a check is required, the ability to enter an authorization password, and the ability to deny an authorization and specify the reason.

FIG. 96 illustrates an Authorized First Withdrawal Denied notification that can be transmitted during the Authorized Withdrawal Request One-Rejected task 316. The notification of FIG. 96 can include a statement that authorization for withdrawal for the project has been denied and a link to view and/or modify the withdrawal details.

FIG. 97 illustrates check confirmation notifications that can be sent during a check confirmation task 318. The notification of Figure 97 can include instructions to have authorized withdrawal of the project plan and proceed to site inspection, as well as a statement to view project details and a link to generate a checklist.

FIG. 98 illustrates a payment detail modification notification that can be transmitted during the payment detail modification task 322. The notification of Figure 98 can include payment details for projects not yet received for payout. Notifications can list the breakdown of project participation along with the payables, organizational roles, budget items and payment amounts for that payment.

FIG. 99 illustrates the inspection authorization notification communicated during the inspection authorization task 320. The notice of Figure 99 can include a statement that an on-site inspection of the works has been authorized.

Diagram 100 illustrates an Authorized Withdrawal Request Two Notification that can be transmitted during the Authorized Withdrawal Request Two - Notify task 324 . The notification of Figure 100 can include requesting the recipient to review the inspection report entered for the project, requesting the recipient's authorization before the withdrawal can proceed to the next stage (e.g., asking the withdrawal recipient about a lien waiver) and reviewing the inspection report and A statement of authorization to grant or deny the withdrawal.

Figure 101 illustrates an Authorized Withdrawal Request Two form that can be associated with the Authorized Withdrawal Request Two task 326. The Authorized Withdrawal Request II form can be accessed by the GC, the owner, the owner's representative, or the title insurance company through the Withdrawal Approval module 60 of the Withdrawal module 44 . The second form of authorized withdrawal request can include project name, project number, owner, project address, withdrawal number and withdrawal date. The authorized withdrawal request two form can include items for each organization, including request amount, organization name, organization role, budget item, budget amount, payment amount, debit, and balance. The Authorization Withdrawal Request Two Form can include authorizations received, outstanding, whether a check is required, the ability to enter an authorization password, and the ability to deny an authorization and indicate a reason.

Figure 102 illustrates an Authorized Withdrawal Request Two Deny notification that can be transmitted during the Authorized Withdrawal Request Two Denied task 328. The notification of FIG. 102 can include a statement that authorization for withdrawal of the project has been denied by the participating party and that withdrawal cannot proceed without such authorization.

FIG. 103 illustrates an Authorized Withdrawal Request Two Grant Notification transmitted during the Authorized Withdrawal Request Two task 330 . The notification of Figure 103 can include a statement that project withdrawal has been authorized by the party.

Figure 104 illustrates the Issue Lien Waiver notification communicated during the Issue Lien Waiver task 332 . The notification of FIG. 104 can include a statement that withdrawal of the project has been authorized by the party and a request to the recipient to issue a lien waiver in order to receive payment for the withdrawal, as well as a link allowing the recipient to issue a lien waiver.

FIG. 105 illustrates a change request process 334 that can be included in manage change order engineering 98 . The change request process 334 can be used to revise the overall project budget (generally expanding the budget) by adding new expense items, by changing existing expense items, or by terminating subcontractors or making remaining funds available to other parties. The change request process 334 can be performed using the change order module 48 by the GC, architect, owner, owner's representative, lender, or subcontractor. Change request process 334 can include change request task 336 , change request issue task 338 , and authorize change request task 340 .

Figure 106 illustrates a change request form that can be associated with a change request task 336. The GC or subcontractor can access the change request form through the change order module 48 . The change request form can include project name, project number, project address, owner name, and a list of change amounts. The change amount list may include change amount, organization name, organization task, budget item, budget amount, payment amount, and balance. A change request form can include a change description field. A change request form can include whether the payment form is a loan or owner payment, and whether the payment method is loan, owner's check, or credit card. A change request form can include the current estimated completion date and a new estimated completion date.

FIG. 107 illustrates a change request issue notification that can be communicated during a change request issue task 338 . The notification of FIG. 107 can include a statement that can be issued on engineering as well as pending authorized change requests. Notifications can include details of the change request, organization name, budget line, current budget amount, and change amount.

FIG. 108 illustrates an authorization change request notification that can be transmitted during an authorization change request task 340 . The notification of FIG. 108 can include a statement that a change request has been engineering made and that the recipient's approval is required for the change request. The notification can include links to view the details of the change request, and to approve or deny the change request.

FIG. 109 illustrates a process change request process 342 that can be included in the manage change order process 98. The process change request process 342 can be used to determine that changes to the budget are authorized by the appropriate parties, such as architects, lenders, title insurers, owners, owners' representatives, or GC. Using the change order module 48, a process change request process 342 is performed by the GC, architect, lender, title insurance company, owner, owner's representative, lender, or subcontractor. Process Change Request Process 342 can include View Pending Change Requests task 344 , Authorize Change Requests task 346 , Change Request Rejection task 348 , and Change Request Approval task 350 .

FIG. 110 illustrates a View Pending Change Requests screen that can be associated with the View Pending Change Requests task 344 . The View Pending Change Requests screen can be accessed by the GC, subcontractor, owner, owner's representative, lender or architect through the change order module 48 . The View Pending Change Requests screen can include a list of project name, project number, project address, owner name and change amount. The change amount list can include change amount, organization name, organization role, budget item, budget amount, payment amount, and balance. The View Pending Change Requests screen can include a change description field. The View Pending Change Requests screen can include whether the method of payment is a loan, owner's check, or credit card. The View Pending Change Requests screen can include new estimated completion dates, authorizations received, and authorizations pending.

Figure 111 illustrates an authorization change request form that can be associated with the authorization change request task 346. The GC, subcontractor, owner, owner's representative, lender, or architect can access the authorized change request form through the change order module 48 . The authorized change request form can include a list of project name, project number, project address, owner name and change amount. The change amount list can include change amount, organization name, organization role, budget item, budget amount, payment amount, and balance. The Authorization Pending Change Request screen can include a change description field. The Authorization Pending Change Request form can include whether the method of payment is a loan, owner's check, or credit card. The Authorization Pending Change Request form can include new estimated completion dates, authorizations received, and pending authorizations. The Pending Change Request form can include the ability to enter a password and authorize a change request and the ability to reject a change request and enter a reason for the rejection.

Figure 112 illustrates a change request rejection notification that can be transmitted during the change request rejection task 348. The notification of FIG. 112 can include a statement that a change request for a project has been rejected by a party by a certain date.

FIG. 113 illustrates a change request approval notification that can be transmitted during the change request approval task 350 . The notification of FIG. 113 can include a change request issued on a certain date that has been approved for engineering by a party involved (eg, leadership). Change requests are used only to modify the overall project budget (often expanding the budget) by adding new expense lines, by modifying existing expense lines, or by terminating subcontractors or making remaining funds available to other parties. The CPMS 10 can be used to determine that changes to the budget are authorized by the appropriate parties, such as the architect, lender, title insurer, owner, owner's representative, or GC. The notification of Figure 113 is transmitted when the change request has been approved by the appropriate parties.

FIG. 114 illustrates a change engineering party process 352 that can be included in the manage change order process 98. For example, the change engineering party process 352 can be used to terminate a subcontractor and make remaining funds available to another party (such as a replacement subcontractor). The change engineering party process 352 can be performed by a GC or a subcontractor using the change order module 48 . Change engineering party process 352 can include change party task 354 , check party deletion task 356 , and change affidavit task 358 .

FIG. 115 illustrates a change party screen that can be related to the change party task 354 . A GC or subcontractor can access the change party screen through the change order module 48 . The change participant screen can include project name, project number, owner name, project address and current status of the project. The Change Party screen can include a list of organizations that can be modified. The organization list can include organization name, organization role, budget item, budget amount, payment amount, chargeback, balance and a link to delete each party.

FIG. 116 illustrates a checkout party deletion screen that can be associated with a checkout party deletion task 356 . The GC or subcontractor can access the reconciliation party deletion screen through the change order module 48. Check party deletion screen can include project name, project number, owner name, project address, and information about the party to be deleted (e.g. organization name, organization role, budget item, budget amount, payment amount, deduction, and balance) . The checkout party deletion screen can include the ability to indicate whether a party has substantially participated in the project.

Figure 117 illustrates the Change Affidavits screen that can be associated with the Change Affidavits task 358. The GC or subcontractor can access the change affidavit screen through the change order module 48. The change oath screen can include the project name, project number, owner name, project address, current status of the project, budgeted amount, previously due and deferred amounts, and remaining budget. The Change Affidavit screen can include fields to enter notes and the ability to enter a password and authorize affidavit modification.

FIG. 118 illustrates maintenance engineering screen tasks 360 that can be included in the manage engineering process 94. The Maintain Project screen task 360 can be used to edit project configuration files, contact information and clear projects. Maintenance engineering screen tasks 360 can be performed by the GC, lender, owner, or owner's representative using the engineering module 28 . Maintain engineering screen tasks 360 can include an engineering configuration file task 362 , an engineering contact information task 364 , an engineering information task 366 , and a close engineering task 368 .

FIG. 119 illustrates a project profile form that can be associated with the project profile task 362. GCs, lenders, owners, owners' representatives can access the engineering configuration file form through the engineering module 28 . GC, lender, owner, owner's representative can enter request information such as project information, project funding information, project owner information, site information, and GC information.

Figure 120 illustrates an engineering contact information screen that can be associated with the engineering contact information task 364. GCs, lenders, owners, owners' representatives can access engineering contact information through the engineering module 28 . The project contact information screen can include project name, project identification, project address and contact information list of project participants. The list of contact information can include a party identification number, organization name, organization role, project management name, contact email address, and contact phone number.

FIG. 121 illustrates a project information screen that can be associated with the create project information task 366. GCs, lenders, owners, owners' representatives can access the engineering information screen through the engineering module 28 . The project information screen can include project information, site information, project owner information and GC information.

FIG. 122 illustrates a close engineering screen that can be associated with a close engineering task 368. GC, lender, owner, owner's representative can access the engineering module 28 to close the engineering screen. The close project screen can include project name, loan account number, owner name and the ability to close the project.

FIG. 123 illustrates an Administration Access Screen task 370 that can be included in the Manage System Environment process 102. The various screens displayed to specific users or organizations can be customized using the Manage Access Screens task 370 through the construction payment process. For example, the Manage Access Screen task 370 may be used to include one or more organization's logos or logos displayed on the screen during the construction payment process (eg, the lender's logo could be included in the upper right corner of each screen). Additionally, the Manage Access Screens task 370 can be used to modify the layout of a particular form or screen according to the preferences or needs of a particular user or organization. The manage access screen task 370 can be performed by any party, using the system environment manager 52 . Administrative access screen tasks 370 can include login tasks 372 , logout tasks 374 , engineering home tasks 376 , reset password tasks 378 , home screen tasks 380 , browse engineering tasks 382 , forgot password tasks 384 , and your password tasks 386 .

FIG. 124 illustrates a login screen associated with a login task 372. Through the access manager 38, each party can access the login screen. Participants can enter a user name and password to log in. If the user forgets his or her password, the login screen can provide a link.

Figure 125 illustrates an exit screen that can be associated with exiting a task 374. Through the access manager 38, each participant can access the exit screen. The logout screen confirms that the user has logged out.

FIG. 126 illustrates an Engineering Home screen that can be associated with the Engineering Home task 376. Each participant can access the project home screen through the access manager 38 . The project home screen can include the project name, the number of new messages, and a link to read new messages. The project home page can include project overview information (including project schedule progress bar and fund payment progress bar), completed withdrawal information (including withdrawal amount, withdrawal date and link to withdrawal information), pending withdrawal information (including withdrawal amount and start date ). The project home page can include links, forms or screens for several actions (including project configuration files, project budgets, view project participants, set invoice codes, manage project users, title insurance company approval tracking, initiate unplanned drawdowns, etc.).

FIG. 127 illustrates a reset password screen that can be associated with the reset password task 378. Each party can access the reset password screen through the access manager 38 . A participant may enter a new password twice to change the password associated with a particular username.

FIG. 128 illustrates a home screen for a particular user related to home screen tasks 380 . Each participant can access the main screen through the access manager 38 . The main screen can list the projects involved by the party, as well as the number of new messages related to each project and the link to read the new messages.

FIG. 129 illustrates a browse engineering screen that can be associated with the browse engineering task 382. Each participant can access through the access manager 38 to browse project screens. The Browse Projects screen can include a project search feature as well as a project list. The project list can include the project name, GC name, a link to edit a project, and the ability to select one or more projects to browse.

Figure 130 illustrates a Forgot Password screen that can be associated with the Forgot Password task 384. Each participant can access the forgotten password screen through the access manager 38 . The user can enter his or her username and email address, and the system can email the password to the user.

Figure 131 illustrates your password that can be transmitted during your password task 386. The notification of FIG. 131 can include a statement that you request that your password be emailed to you, the password, and a request to use that password the next time you log in.

FIG. 132 illustrates an Admin Message Screen process 388 that can be included in the Admin System Environment process 102. The Manage Messages screen process 388 can be used to view messages, create messages, or view system status messages. The manage message screen process 388 can be performed by any party using the system environment manager 52 . Manage message screen process 388 can include view message task 390 , view specific message task 392 , create message task 394 , and status message task 396 .

FIG. 133 illustrates a View Messages screen that can be associated with the View Messages task 390. Each participant can access the view message task 390 through the system environment manager 52 . The View Messages screen can include a user name, the ability to specify the type of message displayed (eg, unread, recent, all, sent message, or archived), and a list of the types of messages specified. The list of messages can include the ability to select a specific message, message date, project name, message subject, and whether action is required. The View Messages screen can also provide the ability to archive selected messages and move to another screen of messages.

Figure 134 illustrates specific messages that can be viewed by the user. Specific messages can include any of the notifications shown and described herein.

FIG. 135 illustrates the Create/Send Message screen that can be associated with the Create Message task 394. Each party can access the create/send message screen through the system context manager 52. User can input project name, whether to send message to organization or user, organization name, user name, message subject and message.

Figure 136 illustrates a status message screen that can be associated with the status message task 396. Each participant can access the status message screen through the system context manager 52 . The status message screen can send messages, such as a statement that the withdrawal for the project has been initiated and that all parties involved have been notified. The status message screen can include links to organization or user home pages.

137-153 illustrate a method of managing the construction payment process according to additional embodiments of the invention. Aspects of the method of Figures 137-153 are used in conjunction with embodiments of the invention shown and described with reference to Figures 1-136 and Figures 154-179.

154-179 are input/output diagrams of a method of managing a construction payment process according to yet another embodiment of the present invention. Aspects of the method of Figures 154-179 are used in conjunction with the embodiments of the invention shown and described with reference to Figures 1-136 and Figures 137-153.

Figure 155 includes a Disclose Engineering Task, Create Drawout Time Sheet task, and Identify and Assign Engineering Role task, each of which is performed by the GC. The task of entering a budget can be performed by the owner, the owner's representative, the GC, the lender, or the title insurance company. The update itemization task can be performed by the GC on subcontractors and/or material suppliers, or by the owner, lender or title insurer on any type of party involved. Closing tasks can be performed by the title insurance company, GC or lender.

Figure 156 includes the Enter Project Details task, where the system assumes that the project already has full permissions from all necessary agencies and participating organizations prior to making the project public. Figure 156 includes entering loan details where the lender may choose to enter only information for legal and business reasons. If no loan exists for this project, enter no information.

Figure 157 includes the Review Proposed Drawout Schedule task, where the system can generate a proposed drawdown schedule by drawing numbers at equal intervals on the estimated project schedule. Figure 157 includes the Accept or Reject Proposed Withdrawal Schedule Task, where the GC can manually announce a drawdown according to a schedule established by the owner, owner's representative, lender, or GC. Ability to reject automatic schedules and maintain schedules manually.

Figure 159 includes input engineering budgets for participating organizations, where a tiered process can be used. At each level, participating organizations can implement the processes they use to support their organization.

Diagram 160 includes authorizing a change order task, where an issue resolution process may require rejecting an initial change order and creating a second change order mutually acceptable to all parties. Only final change orders in the problem resolution process must be approved.

Figure 162 includes the task of adding an organization. Before participating in a project, an organization must be added. Organizations can be added to the system by the system, title insurance companies, lenders or GCs. Although organizations can be added during the Identify and Assign Engineering Role Task for the Maintain Engineering Payments processes, organizations can be added independently through this process. Figure 162 includes the Enter Organization Details task, where an organization's initial contact can be responsible for entering their organization's details and additional contact information. Each organization can identify an internal system administrator who can be responsible for updating their organization details and contact information. Figure 162 includes maintenance organization detail tasks where security can be particularly stringent due to sensitive financial information.

Figure 164 includes verification organizational tasks that can be provided by third parties based on the needs of the participating parties. The system facilitates verification of organizations and collection of service fees.

Figure 166 includes declare drawdown tasks that can be performed by the GC. The draw is the mechanism by which project participants can submit invoices, the owner (usually through the GC) can pay for work done, and the participants receive payment and release their associated lien waivers. Figure 166 includes the Generate Affidavit task, where the GC can review submissions online (referring to backup paper files when needed), and as long as the submission is correct, the system can generate an affidavit based on the information that has been electronically submitted by the counterparty participating in the withdrawal. The GC can reject commits as well as revise them and grant resubmissions. This mechanism can be used to resolve any issues related to invoices. Figure 166 includes request review tasks that can typically be performed by a lender or title insurance company. Figure 166 includes authorized drawdown tasks that can normally be performed by the lender, but may require the inclusion of the owner, the owner's representative, or another designated project participant. A configurable authorization mechanism can include any project participant in the authorization process. Figure 166 includes inputs and graded lien waivers that can require a drawdown to be completed. Funds are not transferred to the invoicing party until their lien waiver is entered and graded. This requirement ensures that payment and lien release are performed substantially simultaneously. Figure 166 includes performing a Simultaneous Payment/Lien Waiver Release task, wherein the substantially simultaneous exchange of a lien waiver for payment is automatic. This automated exchange can eliminate the need for meetings and can eliminate delays in payment and lien release. This automatic exchange can reduce the chance of loss of lien waivers by eliminating intermediaries in the payment process and can speed up payment to all drawing participants.

Fig. 167 includes posting withdrawal tasks that can send electronic messages to all participating and/or related organizations substantially simultaneously.

Figure 168 includes input invoice details that can be performed by any party wishing to pay through the withdrawal process. Electronic filing follows the paperwork supporting the submission. A service can be provided that allows parties to submit supporting information via scanning.

Figure 169 includes the Authorize Invoice task, where a troubleshooting process may require rejection of the initial invoice and creation of a second invoice that is mutually acceptable to all parties. Only final invoices in the resolution process are approved.

Diagram 170 includes select supervision tasks that may have more than one supervision related to the project. In such cases, an appropriate supervisor must be selected to carry out the inspection.

Figure 171 includes the scope of validation for inspection tasks, where the organization requesting the inspection can define the scope of the inspection, for the entire affidavit or a subset of the affidavit. Figure 171 includes the Enter Inspection Results task, where supporting documentation may be necessary depending on the scope and nature of the inspection. Figure 171 includes Forwarding Supporting Documentation tasks, wherein the system can allow documents related to digital photographs or other electronic materials to be attached to the electronic inspection report.

Figure 173 includes the Stage Lien Release task, where an electronically signed lien release can be staged in the system, preventing any alteration. In one embodiment of the invention, the lien release is not released to the title insurer until substantially simultaneous exchange of payment and lien release.

Figure 174 includes the Confirm Drawdown Authorization and Graded Lien Waiver tasks, which may include a review of all lien waivers to ensure they are complete and correct.

Figure 178 includes providing customer support tasks, which may include support for adding or modifying organizations or projects, fixing password issues, fixing projects and transactions. Figure 178 includes system management tasks, which may include security management, financial auditing, and contingency support. Map 178 includes maintenance activity history for system participant tasks, can include vendor history, has history pertaining to vendor and/or vendor's level.

Those of ordinary skill in the art can understand that various computer devices, such as personal computers, servers, and other devices with processors or capable of executing programs or sets of instructions, can be used to implement the embodiments of the present invention. In general, the invention is implemented using existing hardware or hardware that can be easily created by one of ordinary skill in the art. Thus, the architecture of an exemplary device is not always described in detail, just to mention that the device will generally have a processor, memory (of some type), and input and output applications. A processor can be a microprocessor, programmable logic control, application specific integrated circuit, or computing device configured to fetch and execute instructions. In some cases, a device can also have an operating system and applications managed by the operating system. It should also be noted that although control systems 40 and 80 are shown connected in a network, no specific network configuration is implied. One or more networks or communication systems can be used in various combinations, such as the Internet, telephone systems, wireless networks, satellite networks, cable TV networks, and various other private and public networks, as will occur to those of ordinary skill in the art In order to provide the communication links required or needed to create an embodiment of the invention or to implement it. Thus, the invention is not limited to any particular network or combination of networks.

Various features and advantages of the invention are set forth in the claims.

Claims (103)

1. method of managing the construction payment process, this method comprises action:

Reception is used for the log-on message of participant;

Store this log-on message; And

By visiting this log-on message, the geld relevant with construction work transferred to this participant.

2. the method for claim 1, comprise that further action receives the log-on message that is used for participant, this participant comprises at least one of owner, owner's representative, title insurance company, credit side, architect, indoor design person, management, general contractor, subcontractor and material supplier.

3. the method for claim 1 comprises that further action receives the log-on message that is used at least one user of being associated with described participant.

4. the method for claim 1 further comprises first user that registration is associated with this participant and the action that this first user is considered as the keeper of this participant.

5. method as claimed in claim 4 further comprises second user's that registration is associated with this participant action.

6. the method for claim 1 comprises that further this participant provides the action of log-on message.

7. the method for claim 1 further comprises the action of verifying this participant.

8. the method for claim 1 comprises that further transmission registered the action of the notice of this participant.

9. the method for claim 1 further comprises being stored in the database server log-on message and the action of visiting this log-on message by data base management system (DBMS).

10. the method for claim 1 further comprises by visiting this log-on message handle a plurality of gelds relevant with a plurality of engineerings and transferring to the action of this participant.

11. the method for claim 1 further comprises generating automatic payment instruction and using system of automatic settlement center, remittance system, debit card system and access one that geld is transferred to the action of this participant.

12. a construction payment management system comprises:

Application server, storage organization module and data base management system (DBMS), this molded tissue block receives the log-on message of organizing that is used for participant; And

Be connected to the database server of this data base management system (DBMS), this tissue log-on message of this database server stores, this data base management system (DBMS) is visited this tissue log-on message so that the geld relevant with construction work transferred to this participant.

13. construction payment management system as claimed in claim 12, wherein, first participant is organized log-on message for second participant provides.

14. construction payment management system as claimed in claim 12, wherein, this participant comprises at least one of representative, title insurance company, credit side, architect, indoor design person, management, general contractor, subcontractor and material supplier of owner, owner.

15. construction payment management system as claimed in claim 12, wherein, this application server for storage line module, this line module receives the user's registration information that is used at least one user relevant with this participant, and this user's registration information of this database server stores.

16. construction payment management system as claimed in claim 15, wherein, the keeper that this line module receives user's registration information and this first user is considered as being used for this participant from first user relevant with this participant.

17. construction payment management system as claimed in claim 16, wherein, this line module receives user's registration information from second user relevant with this participant.

18. construction payment management system as claimed in claim 12, wherein, this participant provides this log-on message.

19. construction payment management system as claimed in claim 12 further comprises the service for checking credentials that links to each other with this application server, this participant is verified in this service for checking credentials.

20. construction payment management system as claimed in claim 12 further is included in the notification manager of storing in this application server, this notification manager transmits the notice of having registered this participant.

21. construction payment management system as claimed in claim 12 further comprises the database server that is connected to this application server, this database server stores is organized log-on message, and this data base management system (DBMS) is from this database server visit log-on message.

22. construction payment management system as claimed in claim 12, wherein, this data base management system (DBMS) is visited this tissue log-on message so that a plurality of gelds relevant with a plurality of engineerings are transferred to this participant.

23. construction payment management system as claimed in claim 12, further comprise the payment system that links to each other with this application server, and in this application server, store draw module, this is drawn module automatic payment instruction is sent to this payment system, and this payment system comprises system of automatic settlement center, remittance system, debit card system and access one.

24. a method of managing the construction payment process, this method comprises action:

Communicate by letter with a plurality of participants foundation in the construction work;

Notice is drawn in generation; And

Should notify and be transmitted electronically to a plurality of participants in real time.

25. method as claimed in claim 24, further comprise and a plurality of participants, comprise that general contractor, subcontractor, credit side, title insurance company, owner, owner's representative, management, architect, indoor design person and material supplier at least two set up the action of communicating by letter.

26. method as claimed in claim 24 further comprises the action of creating and safeguarding the timetable of drawing that is used for construction work.

27. method as claimed in claim 24, further comprise generate a plurality of participants be used for receiving the geld of drawing each AutoInvoice and the action that transmits the notice that relevant AutoInvoice permits.

28. method as claimed in claim 24 comprises that further each the automatic lien that generates a plurality of participants be used for receiving the geld of drawing abandons and transmit the relevant action of carrying out the notice that automatic lien abandons.

29. method as claimed in claim 24 further comprises the automatic oath of generation, transmits the notice about execution this oath, the allowance of drawing and payment funding, and the action that generates automatic payment instruction.

30. a construction payment management system comprises:

Application server, storage notification manager and draw module, this notification manager and draw module and generate and draw notice, this notification manager was sent to a plurality of participants with should notifying real-time electronic.

31. construction payment management system as claimed in claim 30, wherein, a plurality of participants comprise at least one of general contractor, subcontractor, credit side, title insurance company, owner, owner's representative, management, architect, indoor design person and material supplier.

32. construction payment management system as claimed in claim 30, wherein, this is drawn module and safeguards the timetable of drawing that is used for this construction work.

33. construction payment management system as claimed in claim 30, wherein, this draws each the AutoInvoice that module generates a plurality of participants be used for receiving the geld of drawing, and this notification manager transmits the notice that relevant AutoInvoice is permitted.

34. construction payment management system as claimed in claim 30, wherein, this is drawn each the automatic lien that module generates a plurality of participants be used for receiving the geld of drawing and abandons, and this notification manager transmits the relevant notice that automatic lien is abandoned of carrying out.

35. construction payment management system as claimed in claim 30, wherein, this is drawn module and generates automatic oath and automatic payment instruction, and this notification manager transmits about carrying out the notice of this oath, the allowance of drawing and payment funding.

36. construction payment management system as claimed in claim 30, further comprise the database server that is connected to this application server, this database server stores is organized log-on message, and this notification manager is visited this tissue log-on message so that notice is sent to a plurality of participants.

37. a method of managing the construction payment process, this method comprises action:

Generation is used for the budget of construction work; And

Based on this budget, generate at least one AutoInvoice, automatic oath and at least one automatic lien and abandon.

38. method as claimed in claim 37 comprises that further action is used to generate the budgets that comprise a plurality of expenditure, and generates at least one the AutoInvoice that comprises this a plurality of expenditures.

39. method as claimed in claim 37 comprises that further action is used to generate at least one budget of hard cost under soft cost on the line that comprises the general contractor and general contractor's the line.

40. method as claimed in claim 37 further comprises the action of the notice of the allowance that transmits relevant AutoInvoice.

41. method as claimed in claim 37 further comprises and guarantees that this automatic oath and at least one automatic lien abandon the action in this at least one AutoInvoice.

42. method as claimed in claim 37 comprises that further the summation of guaranteeing invoice amount equals the action of the oath amount of money.

43. method as claimed in claim 37 further comprises and guarantees that invoice amount equals the action that lien is abandoned the amount of money.

44. method as claimed in claim 37 further comprises at least one according to participant demand and state legal requirement, customizes at least one AutoInvoice, automatically at least one the action abandoned of oath and at least one lien.

45. method as claimed in claim 37 further comprises and carries out the action that at least one AutoInvoice, automatic oath and at least one automatic lien are abandoned electronically.

46. method as claimed in claim 37 further comprises at least one AutoInvoice of generation, permits at least one AutoInvoice, generates automatic oath subsequently, permits this automatic oath and generate the action that at least one lien is abandoned subsequently.

47. method as claimed in claim 37 further comprises the action of the electronic copy that invoice, oath and lien that store electrons is carried out are abandoned.

48. method as claimed in claim 37 further comprises the action that generates the hard copy that invoice, oath or lien that electronics carries out abandon.

49. a method of managing the construction payment process, this method comprises action:

Receive at least one invoice from least one subcontractor; And

Automatically generate general contractor's oath, comprise the amount of money from each of at least one invoice.

50. method as claimed in claim 49 further comprises the action of carrying out at least one invoice and oath electronically.

51. a construction payment management system comprises:

Application server, storage budget module and draw module, this budget module generates the budget that is used for construction work, this draw module based on this budget generate at least one AutoInvoice, oath and at least one automatic lien are abandoned automatically.

52. construction payment management system as claimed in claim 51, wherein, this budget module generates the budgets that comprise a plurality of expenditures, and this is drawn module and generates at least one the AutoInvoice that comprises this a plurality of expenditures.

53. construction payment management system as claimed in claim 51, wherein, this budget module generates at least one budget of hard cost under soft cost on the line that comprises the general contractor and general contractor's the line.

54. construction payment management system as claimed in claim 51 further is included in the notification manager of storing in this application server, this notification manager transmits the notice of the allowance of relevant AutoInvoice.

55. construction payment management system as claimed in claim 51, wherein, this is drawn module and guarantees that this automatic oath and at least one automatic lien abandon in this at least one AutoInvoice.

56. construction payment management system as claimed in claim 51, wherein, this is drawn module and guarantees that the summation of invoice amount equals the oath amount of money.

57. construction payment management system as claimed in claim 51, wherein, this is drawn module and guarantees that invoice amount equals lien and abandons the amount of money.

58. construction payment management system as claimed in claim 51, wherein, this draws module according at least one of participant demand and state legal requirement, customize at least one AutoInvoice, automatically oath and at least one lien abandon at least one.

59. construction payment management system as claimed in claim 51, wherein, this is drawn module and generates at least one AutoInvoice, guarantee to permit this at least one AutoInvoice, generate this automatic oath subsequently, guarantee this automatic oath of allowance, and generate at least one lien subsequently and abandon.

60. construction payment management system as claimed in claim 51, further be included in data base management system (DBMS) of storing in this application server and the database server that is connected to this application server, the electronic copy that invoice, oath and the lien that this database server stores electronics is carried out abandoned.

61. construction payment management system as claimed in claim 51, wherein, the hard copy that this invoice, oath or lien of drawing the execution of module generation electronics is abandoned.

62. construction payment management system as claimed in claim 51, wherein, this is drawn, and module is used for carrying out electronically at least one AutoInvoice, automatically oath and at least one automatic lien are abandoned.

63. a method of managing the construction payment process, this method comprises action:

Abandon from the participant reception lien of construction work;

Storing this lien abandons;

Instruction to this participant payment is sent to payment system; And

Receive this participant from this payment system and received that the affirmation of fund also discharges this lien basically simultaneously and abandons.

64., further comprise one the action that generates automatic payment instruction and will this automatic payment instruction be sent to system of automatic settlement center, remittance system, debit card system and access as the described method of claim 63.

65. as the described method of claim 63, further comprise from a plurality of participants receive a plurality of liens abandon, store a plurality of liens abandon each up to receive all a plurality of liens abandon till and when receiving that all a plurality of liens are abandoned, transmit action to the instruction of a plurality of participants payments.

66. as the described method of claim 63, further comprise from a plurality of participants receive a plurality of liens abandon, store a plurality of liens abandon each and when receiving each that a plurality of liens abandon, transmit action to the instruction of each payment of a plurality of participants.

67. as the described method of claim 63, further comprise action from a plurality of participants receive a plurality of liens abandon, store a plurality of liens abandon each, when receiving each that a plurality of liens abandon, transmit to first instruction of each payment of a plurality of participants and when receive that all a plurality of liens are abandoned, transmit to second of at least one other participants payment of a plurality of participants and instruct.

68. as the described method of claim 63, further comprise, receive and discharge the action that lien is abandoned according to drawing performed work to current.

69., further comprise according to work the action that reception and release lien are abandoned to drawing performed this month this month as the described method of claim 63.

70., further comprise at least one the action of carrying out electronically that a plurality of liens abandon as the described method of claim 63.

71. a method of managing the construction payment process, this method comprises action:

Abandon from the participant reception lien of construction work; And

Instruction to the payment of this participant is sent to payment system, and discharges this lien basically simultaneously and abandon.

72., further comprise one the action that generates automatic payment instruction and will this automatic payment instruction be sent to system of automatic settlement center, remittance system, debit card system and access as the described method of claim 71.

73. as the described method of claim 71, further comprise action be used for from a plurality of participants receive a plurality of liens abandon, store a plurality of liens abandon each up to receive all a plurality of liens abandon till and when receive that all a plurality of liens are abandoned, transmit the instruction of paying the bill to a plurality of participants.

74. as the described method of claim 71, further comprise from a plurality of participants receive a plurality of liens abandon, store a plurality of liens abandon each and when receiving each that a plurality of liens abandon, transmit action to the instruction of each payment of a plurality of participants.

75. as the described method of claim 71, further comprise from a plurality of participants receive a plurality of liens abandon, store a plurality of liens abandon each, when receiving each that a plurality of liens abandon, transmit to first instruction of each payment of a plurality of participants and when receive that all a plurality of liens are abandoned, transmit second action of instructing at least one other participants payment of a plurality of participants.

76. as the described method of claim 71, further comprise, receive and discharge the action that lien is abandoned according to drawing performed work to current.

77., further comprise according to work the action that reception and release lien are abandoned to drawing performed this month this month as the described method of claim 71.

78., further comprise and carry out the action that lien is abandoned electronically as the described method of claim 71.

79. a construction payment management system comprises:

Application server, store electrons safe deposit box and draw module, this electronics safe deposit box is abandoned from the participant reception and the storage lien of construction work, this is drawn module and generates to the automatic command of this participant payment and send it to payment system, and this is drawn module and receives this participant from this payment system and received the affirmation of fund and discharged this lien basically simultaneously and abandon.

80. as the described construction work management system of claim 79, further comprise notification manager, automatic command be sent to system of automatic settlement center, remittance system, debit card system and access one.

81. as the described construction work management system of claim 79, wherein, this electronics safe deposit box receives a plurality of liens from a plurality of participants and abandons, each of storing that a plurality of liens abandon and comprises that further notification manager transmits the automatic command to a plurality of participants payments when receiving that all a plurality of liens are abandoned till receiving that all a plurality of liens are abandoned.

82. as the described construction work management system of claim 79, wherein, this electronics safe deposit box receives a plurality of liens from a plurality of participants and abandons and store each that a plurality of liens are abandoned, and further comprise notification manager, be used for when receiving each that a plurality of liens abandon, transmitting automatic command to each payment of a plurality of participants.

83. as the described construction work management system of claim 79, wherein, this electronics safe deposit box receives a plurality of liens from a plurality of participants and abandons and store each that a plurality of liens are abandoned, and further comprise notification manager, be used for when receiving at least one that a plurality of liens abandon, transmitting first instruction, and when receive that all a plurality of liens are abandoned, transmit to second of at least one other participants payment of a plurality of participants and instruct at least one payment of a plurality of participants.

84. as the described construction work management system of claim 79, wherein, this electronics safe deposit box and this are drawn module according to drawing performed work to current, receive and discharge lien and abandon.

85. as the described construction work management system of claim 79, wherein, this electronics safe deposit box and this are drawn module according to drawing performed work in this month this month, receive and discharge lien and abandon.

86., further comprise and carry out the electronic signature service that lien is abandoned electronically as the described construction work management system of claim 79.

87. a method of managing the construction payment process, this method comprises action:

Establishment is used for the main budget of construction work, comprises from least one at least one subsidiary budget in general contractor, at least one subcontractor and at least one material supplier, and this at least one subsidiary budget comprises at least one expenditure respectively; And

Before management is drawn, receive this main budget and comprise at least one the expenditure at least one subsidiary budget.

88. as the described method of claim 87, further comprise action, this action is created at least one that AutoInvoice, automatic oath and automatic lien are abandoned based on main budget, at least one subsidiary budget and at least one expenditure item.

89., further comprise and carry out the action that AutoInvoice, automatic oath and automatic lien are abandoned electronically as the described method of claim 88.

90., further comprise and create at least one the action of main budget comprise hard cost and soft cost as the described method of claim 87.

91., further comprise creating comprising the only action of at least one subsidiary budget of hard cost as the described method of claim 87.

92. a construction payment management software comprises:

The engineering module is used for creating and management engineering;

The budget module is used to create and safeguard the budget that is used for this project; And

Draw module, be used for, create, plan and manage to be used for drawing of this project based on this budget.

93. as the described construction payment management software of claim 92, further comprise molded tissue block, be used for creating information with the participant of safeguarding relevant this project.

94. as the described construction payment management software of claim 92, further comprise the change order module, be used to revise budget and permit revising budget.

95., further comprise electronics lien waiver of premium bobbin carriage as the described construction payment management software of claim 92, be used for from the participant of drawing, receive and store lien and abandon.

96., further comprise the system environments manager as the described construction payment management software of claim 92, be used for configuration access, administrative messag, establishment report, technical support is provided, and the interface of management and other softwares.

97. as the described construction payment management software of claim 92, further comprise line module, be used to create the user relevant with participant with renewal.

98. as the described construction payment management software of claim 92, further comprise the budget module, be used to customize at least one that invoice code, coding of account, Stage code and Stage code are described.

99., further comprise notification manager, be used for creating, edit notice and be sent to participant as the described construction payment management software of claim 92.

100. a graphic user interface that is used for construction payment management system, this graphic user interface comprises:

At least one of works schedule progress bar, payment funding progress bar and number percent schedule bar;

The works schedule progress bar is represented the progress with respect to calendar date;

The payment funding progress bar is represented the progress with respect to budget amount; And

Number percent schedule bar is represented the progress with respect to the number percent of the work of finishing on construction work.

101., further be included as the engineering homepage of participant customization as the described graphic user interface of claim 100.

102. as the described graphic user interface of claim 100, wherein, this project homepage comprises each of works schedule progress bar, payment funding progress bar and number percent schedule bar.

103., further comprise new information indicator, relevant at least one of the information of drawing and the relevant unsettled information of drawing that is used for this participant finished as the described graphic user interface of claim 100.

Images