CN101042759B - Construction payment management system and method with document tracking feature - Google Patents

Abstract

A system and method of managing a construction payment process involving a plurality of participants associated with a construction project and at least one file transferred between at least two of the plurality of participants over at least one computer network during the construction project. A method includes specifying at least one enforcement action for the at least one file, wherein the enforcement action occurs automatically if the at least one file is not electronically transferred between the at least two participants.

Description

Construction payment management system and method with document tracking feature

related application

This patent application is a continuation-in-part of co-pending U.S. Patent Application Serial No. 11/032,699, filed January 10, 2005, claiming priority over U.S. Patent Application Serial No. 60/583,782, filed June 29, 2004 rights, the entire contents of which are hereby incorporated by reference. This patent application also claims priority to US Provisional Patent Application Serial No. 60/785,411, filed March 23, 2006, the entire contents of which are hereby incorporated by reference.

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 withdrawals 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 affidavit and inspection report is received by the lender, homeowner and/or title insurance company 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. In addition, if a subcontractor fails to provide the correct documentation required by the GC, the GC (or other upline and/or downline parties) often threatens to rescind payment to the subcontractor to make the subcontractor comply with legal standards. For example, the GC can notify subcontractors that they will not pay if they do not return the signed subcontract.

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 engineering payment process. The process involves a plurality of parties associated with the engineering project and at least one document passed between at least two of the plurality of parties during the course of the engineering project. A method of implementing the project payment management of the present invention may include a document tracking module for assigning at least one enforcement action to said at least one document, wherein when said document is not in said at least two parties The coercion action happens automatically when teleporting between.

A method of implementing the project payment management of the present invention may comprise a document tracking module for assigning at least one mandatory action to said at least one document, wherein when said document is not transferred between said at least two parties Said mandatory action occurs automatically.

The graphical user interface of the project payment management system embodying the present invention includes: a file status individual page, accessible by said at least two parties; a file status summary page, displaying at least one mandatory action assigned to said at least one file, when the Said mandatory action occurs automatically if said at least one file is not transferred between said at least two parties.

Description of drawings

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

FIG. 2 is a schematic diagram of a project payment management process performed by using the system in 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 a management 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 enabling organizational notifications.

Figure 14 is an illustration of the Enable Organization form.

Figure 15 is an illustration of notifications enabled by an organization.

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.

Figure 22 is a schematic diagram of the process of creating a user.

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 a schematic diagram 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 Specify Invoice Code form.

Fig. 41 is an illustration of receiving engineering notices.

Fig. 42 is an illustration of an acceptance project 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.

Figure 50 is an illustration of entering the budget form.

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

Figure 52A is an illustration of the entry to top-level budget form.

52B-C are illustrations of the edit budget form.

Figure 52D is an illustration of the project home page.

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.

56A-C are illustrations of initial withdrawal forms.

Figure 56D is an illustration of the project home page.

Figure 56E is an illustration of the parties involved in a withdrawal notification.

57A-B are illustrations of inputting invoice notifications.

Figure 57C is an illustration of the View All Information screen.

58A-B are illustrations of an input invoice form.

Figure 58C is an illustration of an invoice submission notification.

Figure 59 is an illustration of a signed invoice notification.

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

Figure 60B is an illustration of the Signature Documents screen.

60C-D are illustrations of automatically generated invoice forms.

Figure 60E is an illustration of a signed invoice.

Figure 60F is an illustration of a signed audit report.

Figure 60G is an illustration of a file signature notification.

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 64A is an illustration of an invoice not included in a withdrawal notice.

Figure 64B is an illustration of an input invoice form.

Figure 64C is an illustration of the project home page.

Figure 64D is an illustration of an invoice submission notification.

Figure 64E is an illustration of an Approve Invoice form.

Figure 64F is an illustration of the view invoice screen.

Figure 64G is an illustration of an invoice approval notification.

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

Figure 66A is an illustration of an automatically generated affidavit form.

Figure 66B is an illustration of the Send to Signer screen.

Figure 66C is an illustration of an Invoice Sent to Signer Notification.

Figure 66D is an illustration of the project home page.

Figure 66E is an illustration of the Sign Files screen.

Figure 66F is an illustration of an automatically generated lien waiver form.

Figures 66G-H are illustrations of signed lien waivers.

Figure 66I is an illustration of an invoice signature notification.

Figure 66J is an illustration of the Sign Files screen.

Figure 66K is an illustration of an automatically generated lien waiver form.

Figure 66L is an illustration of a signature lien waiver.

Figure 66M is an illustration of the Signature Files screen.

Figure 66N is an illustration of an impartial signature lien waiver form.

Figure 66O is an illustration of a justified lien release.

Figure 66P is an illustration of a file signature notification.

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

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

Figure 68B is an illustration of the Request Lien Waiver screen.

Figure 68C is an illustration of the project home page.

Figure 68D is an illustration of a notice of lien waiver requirement.

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

Fig. 69B is an illustration of the project home page.

Figure 69C is an illustration of the Sign Files screen.

70A and 70B are illustrations of automatically generated lien waiver forms.

Figure 70C is an illustration of a signature lien.

Figure 70D is an illustration of the Signature Documents screen.

Figure 70E is an illustration of an impartial signature lien waiver form.

Figure 70F is an illustration of a justified lien release.

Figure 70G is an illustration of a file signature notification.

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

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

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

Figure 73B is an illustration of the view all information screen.

74A and 74B are illustrations of viewing withdrawal request forms.

75A and 75B are illustrations of payment placement notifications.

Figure 75C is an illustration of the project home page.

Figure 75D is an illustration of a withdrawal payment acceptance page.

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 notice.

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 viewing a specific message 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 implementation of the present invention.

Fig. 180 is a schematic diagram of a construction project payment system according to another embodiment of the present invention.

Fig. 181 is a schematic diagram of data managed by the construction project payment management system shown in Fig. 180 according to another embodiment of the present invention.

Figure 182A is an illustration of a file request page.

Figure 182B is an illustration of a document request notification.

Figure 182C is an illustration of a file request modification notification.

Figure 183 is an illustration of the project home page.

Figure 184 is an illustration of the File Status Summary page.

Figure 185A is an illustration of a file status individual page.

Figure 185B is an illustration of a view-only version of the Document Status individual page.

Figure 185C is an illustration of the project home page.

186A-B are illustrations of submission documents pages.

Figure 187 is an illustration of a file submission notification.

Figure 188 is an illustration of the home page.

Figure 189 is an illustration of receiving a file notification.

Fig. 190 is an illustration of a file information update notification.

FIG. 191 is a flowchart of a method for identifying outdated files according to an embodiment of the present invention.

Figure 192 is an illustration of an overdue warning notification.

Figure 193 is an illustration of an overdue notification.

Figure 194 is an illustration of a notification required to update a file.

Figure 195A is an illustration of a payment hold notice.

Figure 195B is an illustration of the View All Messages screen.

Figure 196 is an illustration of payment accounts for hold notifications.

197A-B are illustrations of the Manage Payments page.

198A-B are illustrations of the Manage Payments page.

Figure 198C is an illustration of a payment page.

Figure 199 is an illustration of the project home page.

Figure 200 is an illustration of the Manage Payments page.

Figure 201 is an illustration of a funds disbursement notification.

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 (land owners who sell the site to the owner 70), or one or more engineers. 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 understand that CPMS 10 can be used for the hard costs of the GC only, the soft costs of the on-line participants of the GC only, or a combination of hard and soft costs of the on-line and off-line participants of the GC 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 project details can include details of the parties involved in each project, such as the owner, architect, general contractor, and title insurer. 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. This is followed by a series of engineering site inspections, approvals, completion of lien waivers, generation of statements, etc., 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 designation 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. In some embodiments, a user of the CPMS 10 can use the CPMS 10 to find organizations that can contract projects. For example, CPMS 10 can generate reports listing organizations associated with a particular engineering task, a particular geographic area, and so on. CPMS 10 can also provide information (such as degree of trust, qualifications, contact information, etc.) of organizations registered in the system. This information can be used when the user chooses to organize the contracting project after mastering the information. The CPMS 10 may also provide a list of "preferred" or "recommended" organizations based on the organization's history managed by the CPMS 10 and/or evaluations provided to the CPMS 10 by other organizations. In some embodiments, participants may also generate their own "preferred" organizational lists that can only be accessed by the participant that created the list or by other participants of the CPMS 10 and/or by the CPMS 10 when creating a level of trust or for Used when registering organization rankings. 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 notifies participants in real time, and its punctuality has become an intrinsic aspect of the system under normal circumstances. Therefore, CPMS 10 operates in real time to meet its time (eg, bottom line) requirements. In other words, CPMS 10 will notify all parties at the fastest speed when the withdrawal is generated. Although the parties may not have the fastest access to notifications (eg, the CPMS 10 may not be accessed), the CPMS 10 will make the withdrawal information reach all parties. Real-time notifications to all parties provide fair access to withdrawal information as long as the information is available. Real-time operation cannot be understood as "online" operation, "visible through a web page" or "very fast" operation. Including time questions with baseline requirements, response times, time patterns or time limits typically rely on a single application. They're not just bureaucratic snubs, network bandwidth, processor speed or the capabilities of browsers, servers or human-machine or user interfaces that someone creates by using a web programming language. (While these aspects can affect processing speed, they do not provide a way to actually manage resources to meet timing requirements.)

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. In some embodiments, parties may also use the CPMS 10 to approve budgets. For example, an owner can approve budgets created by a GC, a GC can approve budgets created by subcontractors, and/or a subcontractor can approve budgets created by subcontractors it has contracted, and so on. 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 Waiver of rights, and other documents with other names that provide the same function (such as statutory declarations). 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 invoices, affidavits and lien releases based on the needs of lenders, owners, owners' representatives, GCs, etc. In some embodiments, a party may use CPMS 10 to add text to a lien release. For example, a GC may add "protective" language to lien waivers for certain projects. In these works, specific laws (such as regional or national laws relating to the work) make the lien waiver unfettered by law. In some embodiments, parties may also use CPMS 10 to define and/or manage additional types of documents or information, such as tables containing suppliers and other parties related to the project. In addition, parties can enter or define owner forms in CPMS 10 that parties can use for specific projects, organizations, 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. In some embodiments, participants may be paid directly by the property owner, property owner's representative, lender, title insurance company, or GC. In other embodiments, participants may be paid indirectly by the participants who directly employ each participant. For example, if GC contracts the project to the first-level subcontractor, and the first-level subcontractor contracts the project to the second-level subcontractor, GC can pay for the completion of the project by the first-level subcontractor and the second-level subcontractor work, and the first-tier subcontractor can pay the second-tier subcontractor.

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 may suspend a lien waiver even upon receipt of acceptance from the payment system 26 by which the party collects the payment. For example, CPMS 10 may suspend lien waivers until after 31 days, or until a second withdrawal occurs.

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 report task 140 is performed by any party on or off the GC in order 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, submissions by parties files etc.

8-136 and 182A-201 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. In some embodiments, an organization profile update notification may be sent to all organizations associated with the organization whose profile was updated. For example, if an organization updates its address or Federal Employer Identification Number (Federal Employer Identification Number), CPMS 10 can support the transmission of organizational engineering update notifications to other organizations related to the system 10. In some embodiments, the CPMS 10 transmits only to organizations related to or working with the organization whose information it updates. CPMS can deliver notifications in almost real time.

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. In some embodiments, the GC, lender, owner, or owner's representative may also use the Create Project form to establish other project options, such as specifying whether subcontractors can view project information and specifying document settings (such as lien waiver text, lien right to waive settings, payment methods, etc.). For example, a GC, lender, owner, or owner's representative can use the Create Profile form to define the liens used to define each type of lien waiver that will be administered in a particular project (such as partial lien waiver and final lien waiver) Waiver settings, such as when the lien waiver is released. For example, the system 10 may release the lien disclaimer at the time of signing, when the funds are disbursed, when a subsequent withdrawal occurs, and the like. Additionally, the GC can use the Create Project form or other setup form provided by CPMS 10 to set the path for approving the different project phases. For example, the GC may set invoice limits and/or signature requirements for a particular project.

In addition, the GC, lender, owner, or owner's representative may use the create project form or other form provided by CPMS 10 to designate whether the project is an "open book" or "closed book" project. In an open-book project, the GC, lender, owner, or owner's representative (such as an online party) can view the portion of the project that is managed by subcontractors and material suppliers (such as an offline party) included in the project. detail. For example, in an open-book project, if a subcontractor to the GC creates a secondary budget for one or more lien items assigned to the subcontractor, the GC can view the breakdown of the secondary budget, such as quantity, contract Secondary subcontractors to subcontractors, etc. In some embodiments, a GC, lender, owner, or owner's representative may request contracts and documents (such as lien waivers, contractors, affidavits, etc.) ).

In a closed-book project, the GC, lender, owner or owner's representative can only be checked down step by step by the first-level subcontractors and material suppliers of the project. For example, during the closing process, the GC, lender, owner or owner's representative can only enter their own budget, subcontractors, material suppliers, etc., and the first-level subcontractors and material suppliers can only provide a lump sum to the GC Funding amount and information, because GC is not authorized to view details of subcontractors, material suppliers' contracts, budgets, invoices, etc.

In some embodiments, participants at each level of the project can specify whether the portion of the project they manage is an open-book project or a closed-book project. In this way, if each level is set as an open-book project, the participants of each level of the project can view the details of the lower levels of the participant. However, if the first level of the project is set as a closed-book project, the participants can only view the details of the closed-book project, but not the details of other levels. Based on the project settings set by the user, CPMS 10 can manage and standardize the entry of information in a project.

In some embodiments, in addition to creating a project, a GC, lender, owner, owner's representative, subcontractor, or material supplier may create one or more sub-projects within a project. For example, in a multi-story complex construction project, GC can create sub-projects for each building. Each subproject can contain independent budgets; independent invoices, affidavits and lien waivers; independent project settings; independent parties, etc.

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. In some embodiments, the CPMS 10 allows users to assign payout items to one or more parties or contracts. For example, if a GC contracts a budget item to three organizations, the GC can assign portions of that item to each organization. In addition, the GC or subcontractor can use CPMS 10 to split an expense item into multiple expense items if the GC or subcontractor requires additional details or subtasks within a particular expense item. A GC or subcontractor can use the CPMS 10 to assign portions of budgeted amounts, encumbrances, work complete parts or percentages, payment amounts, etc. from the original expense item to the new expense item.

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 . In some embodiments, a participant may create or enter a budget template by using the CPMS 10. CPMS 10 can be used when users create budgets for projects.

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. In some embodiments, a GC or subcontractor may also use CPMS 10 to provide an open invoicing environment for a particular project allowing project participants to submit invoices at any point during the project.

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 the Specify Invoice Code form that can be associated with the Specify Invoice Code 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 Specify Invoice Code form can include the project name, project address, phase code, phase code description, the organization contracting the job, and the budgeted amount. The Specify 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. 52A 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.

Figures 52B-C illustrate the Edit Budget or Value Plan form. GCs and/or subcontractors or material suppliers can use the Edit Budget form to edit budget information for a project. In some embodiments, the user can enter the edit budget form from the home page, as shown in Figure 52D.

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 enabling any outstanding balance to be reassigned.

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.

56A-C illustrate 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. In some embodiments, the GC can access the initial withdrawal form through a link on the project home page. 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. The GC may select a subset of potential participants (eg, at least one potential participant) for the withdrawal, or may select all potential participants for the withdrawal. In some embodiments, the initial withdrawal form includes a selection mechanism that selects all potential parties at once. In other embodiments, the CPMS 10 may automatically select all potential parties, or a subset thereof, for drawouts that do not require a GC to select individual parties.

In some embodiments, the GC may also use the initial withdrawal form to close pending withdrawals. Alternatively, the GC can use the initial withdrawal form or other forms provided by CPMS 10 to open overlapping withdrawals. However, CPMS 10 may add rules or criteria for opening overlapping draws to manage multiple draws at once, such as preventing new draws from being signed before previous draws are signed (eg, authorizing payouts), or preventing draws from being spent out of sequence.

57A-B illustrate the input invoice notifications that can be transmitted during the input invoice task 238. The notification can include a statement that debits have been planned for the work and that subcontractors or material suppliers have entered details of payments due. 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. In some embodiments, a subcontractor or material supplier may enter an input invoice notification from the View All Information screen, as shown in Figure 57C.

58A-B illustrate an input invoice form that can be associated with the input invoice form task 240 . Subcontractors or material suppliers can use the Enter Invoice form to provide invoice amounts for billing. 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. After the subcontractor or material supplier submits the invoice information, the CPMS 10 can generate an invoice notification, as shown in Figure 58C, and can display the invoice submission notification for the subcontractor and material supplier.

In some embodiments, the GC or project manager may specify the invoice or bill amount entered by the subcontractor. For example, using CPMS 10, a GC can specify an invoiced amount (such as a percentage full amount) for a particular subcontractor. Subcontractors can review and submit specified invoice amounts by using the CPMS 10, but in some embodiments, subcontractors cannot modify the amounts.

FIG. 59 illustrates a signed invoice notification that can be communicated to a subcontractor or material supplier during the signed invoice task 242. The notification of Figure 59 can include a statement that the GC or project manager has approved the invoice for the particular payout and the affidavit must be signed. CPMS 10 can be used to assign security/authorization roles to each user, such as administrative, 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).

60A-B illustrate the Sign Documents screen or the Sign Invoice form that can be associated with the Sign Invoice task 242 . Subcontractors or material suppliers can access signed invoices through the withdrawal module 44 . By using the signed invoice form, subcontractors or material suppliers can view invoice details such as specific organization, request amount, budget amount, payment amount, deduction and balance. Subcontractors or material suppliers can then choose to sign the invoice statement. A signed invoice form can include a link to view the auto-generated invoice form or the auto-generated affidavit form.

In some embodiments, to electronically sign an invoice, a subcontractor or material supplier may choose to include a signature invoice statement selection mechanism in front of the signature document screen or signature invoice form, as shown in Figures 60A-B. After a subcontractor or material supplier selects a signature invoice statement selection agency, the CPMS 10 can generate and display an auto-generated invoice form, as shown in Figures 60C-D. To sign the invoice form, subcontractors or material suppliers may choose to include the signed document selection agency on the form. After the subcontractor or material supplier electronically signs the automatically generated invoice form, the system 10 can create and display a legally bound invoice form, as shown in Figure 60E. In some embodiments, CPMS 10 may generate an audit report each time a user electronically signs a document through use of CPMS 10, such as the signature audit report screen shown by FIG. 60F.

After the subcontractor or material supplier signs the automatically generated invoice form, the CPMS 10 can generate a document signature notification, as shown in Figure 60G, and can display the document signature notification to the subcontractor or material supplier. In some embodiments, when a subcontractor or material supplier provides a signed invoice, the CPMS 10 may also require the subcontractor or material supplier to file a signed pre-lien notice.

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. In some embodiments, the View Pending Withdrawal Requests screen (or project home page) may also provide one or more graphical reminders of the progress of a particular withdrawal, such as a progress bar. Project managers can specify which parties can view progress notifications. Additionally, in some embodiments, the CPMS 10 may automatically transmit notifications (eg, in near real time) to participants informing them of a particular withdrawal status.

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. 64A illustrates an invoice not included in a withdrawal notification that can be transmitted during an invoice 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.

When a subcontractor or material supplier submits an invoice for a particular charge, CPMS 10 can generate a joint invoice based on the invoice received. The CPMS 10 can also contain invoice details provided by the GC, Figure 64B shows an input invoice form which the GC can use to enter invoice details for a particular draw. In some embodiments, the GC can access the input invoice form from the engineering home page, as shown in Figure 64C. As shown in Figure 64B, the GC can enter invoiced amounts for work it has performed. The Enter Invoice form can also display invoiced amounts received by subcontractors or material suppliers included in the draw. In some embodiments, the GC's or project manager may initiate billing for subcontractors or material suppliers. For example, a GC may bill for one or more projects or work periods for which the GC has not received invoices from subcontractors or material suppliers. By submitting a bill, the GC can receive the reserved amount for the project or work period.

When the GC enters the invoice details by using the input invoice form shown in FIG. 64B, the CPMS 10 may generate an invoice submission notification, as shown in FIG. 64D, and may display the invoice submission notification to the GC.

The GC may approve or reject invoices from subcontractors and material suppliers to the GC by using the Approve Invoice form shown in Figure 64E. Using the Approve Invoices form, GC can select one or more invoices to reject and/or one or more invoices to object to. In some embodiments, if the GC rejects the invoice, the GC can use the Approve Invoice form to provide the GC's reasons for rejecting the invoice or comments.

As shown in Figure 64E, for each invoice received, the Approve Invoice form may contain a View Invoice link. The GC may select the View Invoices link associated with a particular subcontractor or material supplier to view invoices received from the subcontractor or material supplier. For example, if the GC selects the View Published link associated with a particular subcontractor or material supplier, the CPMS 10 may display the View Invoice screen shown in Figure 64F, which shows the invoices submitted by the subcontractor or material supplier. bill. After the GC approves one or more invoices, the CPMS 10 can generate an invoice approval notification, as shown in Figure 64G, and can display the invoice approval notification to the GC.

After the GC approves one or more invoices sent by subcontractors or material suppliers and/or by entering invoice details using the Enter Invoice form shown in Figure 64B, CPMS 10 can generate GC's invoice information for the invoice. 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. 66A 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 electronically sign the affidavit form (eg, using a product from an electronic signature software provider such as AlphaTrust Corporation).

After CPMS 10 generates invoices and/or affidavits based on approved invoices from subcontractors and material suppliers and invoice details entered by the GC, the GC can review the electronic documents by using the Send to Signer screen, as shown in Figure 66B . After the GC has reviewed the automatically generated document, the GC can use the Send to Signer screen to submit invoices and/or affidavits to users associated with the GC authorized by the CPMS 10 to sign the document (hereinafter referred to as "signers"). After the GC submits the files for signature, the CPMS 10 can generate an invoice sent to the signer notification, as shown in Figure 66C, and can display the invoice to the signer notification to the GC.

When one or more files are submitted by GC for signature, CPMS 10 can notify the signer that one or more files need to be signed. For example, when the CPMS 10 can display a notification on the signer's home page, as shown in Figure 66D. To sign the document, the signer can enter the signature document screen, as shown in Figure 66E. By using the Sign Document screen shown in FIG. 66, the signer can also reject the document and can enter a reason or comment for rejecting the document.

The signer may sign the document by selecting the agency selected from the signature invoice (eg, "Signature G702") included in the Sign Document screen. If the signer selects the signature invoice selection agency, CPMS 10 may display an automatically generated invoice form, as shown in Figure 66F. To electronically sign the displayed invoice form, the signer can select the signature file selection mechanism for inclusion in the invoice form as shown in Figure 66F. After the signer selects the signature document selection authority, the CPMS 10 generates and displays the signed invoice, as shown in Figures 66G-H. After the signer finishes signing the invoice, the CPMS 10 can generate an invoice signature notification, as shown in Figure 66I, and can display the invoice signature notification to the signer.

After the signer signs the invoice and/or affidavit, the CPMS 10 can remind the signer (either the same user who signed the invoice and/or affidavit or a different user associated with the GC who is authorized to sign the document) by using the Signed Documents screen to sign the lien waiver associated with the invoice and/or affidavit, as shown in Figure 66J. To sign a lien waiver, the signer may select the agency included in the signature lien waiver selection in the Signed Documents screen. If the signer selected the signature invoice selection agency, CPMS 10 displays the automatically generated lien waiver form, as shown in Figure 66K. By electronically signing the displayed lien waiver form, the signer may select a signature document selection agency included in the lien waiver form, as shown in Figure 66K. After the signer selects the signature document selection agency, CPMS 10 generates and displays the signed lien waiver, as shown in Figure 66L.

Likewise, the CPMS 10 can ask the notary associated with the GC to notarize the signed lien release by using the Signed Documents screen, as shown in Figure 66M. In some embodiments, each organization registered with the system 10 may designate at least one user as the organization's notary. Notaries can use CPMS 10 to create a Notary Password or a Personal Number (PIN). The notary may be prompted to enter the certifier PIN when logging into the system 10 and/or when signing a particular document. To prevent unauthorized use of the notary PIN, the notary portion of the CPMS 10 may time out and the CPMS 10 may require the notary to re-enter the notary PIN. Additionally, in some embodiments, CPMS 10 may create an audit trail each time a notary notarizes a document. To access an audit trail for a particular impartiality, a user may enter a notarized document through CPMS 10 and select or click on an electronic notarization displayed on the document. The CPMS 10 can then display the audit trail associated with the selected notarization. The CPMS 10 can provide the same audit trail functionality for all forms of electronic signatures and authorizations recorded in the system 10.

For notarized signed lien waivers, the notary may select the notarial lien waiver selection agency included in the signed document screen shown in Figure 66M. If the notary selects the notary lien waiver selection agency, CPMS 10 may display the notarized signed lien waiver form, as shown in Figure 66N. By electronically notarizing the displayed signed lien waiver form, the notary may select the notary or signature document selection agency included in the notarized signed lien waiver form, as shown in Figure 66N. After the notary selects the signature file selection authority, the CPMS 10 may generate and display the notarized signed lien waiver, as shown in Figure 66O. CPMS 10 can also generate a notification of document signature, as shown in Figure 66P, and can display the notification of document signature to the signer.

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. 68A 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 or other kinds of submissions (eg, invoices, affidavits, contracts, etc.).

Figure 68B illustrates a claim lien waiver screen accessible through the View Drawout Claims screen, as shown in Figure 68A, or the Engineering Home page, as shown in Figure 68C. By using the Request Lien Waiver screen, the GC can view a list of subcontractors and material suppliers associated with the draw, from which to request a lien waiver, the GC can choose to include in the request lien waiver Request a Lien Waiver in the Select Agency screen. After the GC elects to require a lien waiver to select an agency, the CPMS 10 may generate a lien waiver demand notice, as shown in Figure 68D, and may display the lien waiver demand notice to the GC.

FIG. 69A illustrates a signature lien waiver notification that can be communicated during the signature lien waiver task 256. The notification of FIG. 69A can be transmitted in real time to all drawing participants and can include a statement that has authorized the drawing of the project plan and requested the subcontractor or material supplier to sign its lien waiver to accept the drawing request. In some embodiments, subcontractors and material suppliers may access the Signature Lien Waiver Notice through the Engineering Home Page, as shown in Figure 69B.

In some embodiments, to sign a lien waiver, subcontractors and material suppliers may choose to include a link in the signed lien waiver notice. If the subcontractor or material supplier chooses to include a link in the signature lien waiver notice, the CPMS 10 may generate and display the signature file screen, as shown in Figure 96C. To sign a lien waiver, a subcontractor or material supplier may choose to include a signature lien selection agency in the Signature Documents screen. If the subcontractor or material supplier selects the signature lien selection agency, CPMS 10 displays an automatically generated lien waiver form. 70A-B illustrate 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 the lien waiver form (eg, using AlphaTrust Corporation's electronic signature product) by selecting the signature selection agency included in the lien waiver as shown in Figure 70B. Lien release 68 can be stored in electronic safe deposit box/escrow 54 as long as it is signed. As long as the subcontractor or material supplier signs the lien waiver, the CPMS 10 may display a signed or electronically executed lien waiver, as shown in Figure 70C.

In some embodiments, in addition to signing the lien release, the subcontractor or material supplier may notarize the lien release. For example, the CPMS 10 may ask a notary associated with a subcontractor or material supplier to notarize a signed lien release by using the Signed Documents screen, as shown in Figure 70D. For notarized signed lien waivers, the notary may select the notarial lien waiver selection agency included in the signed document screen shown in Figure 70D. If the notary selects the notary lien waiver selection agency, CPMS 10 may display a notarized signed lien waiver form, as shown in Figure 70E. Electronically notarizing the displayed signed lien waiver form, the notary may select the notary or signature document selection agency included in the notarized signed lien waiver form as shown in Figure 70E. After the notary selects the signature file selection authority, the CPMS 10 generates and displays the notarized signed lien waiver, as shown in Figure 70F. The CPMS 10 can also generate document signature notifications, as shown in Figure 70G, and can display the document signature notifications to subcontractors or material suppliers.

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. 73A illustrates all lien waiver signature notifications that can be transmitted during the sign all lien waiver task 260. The notice of FIG. 73A can include a statement of waiver of all liens that have been signed for disbursement of the works. Notifications can include links to view withdrawal details and disburse funds. In some embodiments, the GC can access all lien waiver signed notifications through the View All Messages screen, as shown in Figure 73B.

74A-B illustrate a view withdrawal request form that can be associated with a view withdrawal request task 363 with a pay funds task. 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. Viewing the withdrawal request form 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.

As shown in Figure 74B, viewing the withdrawal request form may prompt payment amounts for specific subcontractors or material suppliers. Viewing the Withdrawal Request Form may also prompt payment holdback amounts for specific subcontractors or material suppliers. In some embodiments, the CPMS 10 may automatically withhold payments to subcontractors or material suppliers. As described below, the CPMS 10 may automatically withhold payment to subcontractors or material suppliers who do not provide one or more required documents (eg, contracts, licenses, insurance documents, etc.). The GC can also manually withhold payment to specific subcontractors or material suppliers by using the CPMS 10 for various other reasons.

As shown in Figure 74B, the view withdrawal request form may also contain a link. By using these links, a GC may review a lien waiver filed for a drawout or review the status of a document requested by a drawout party.

75A-B illustrate payment notifications transmitted during a payment payment task 264. The notifications of Figures 75A-B can be communicated in real time to all drawout parties and can include a statement that planned drawdowns for a specific date for the project have been paid. In some embodiments, GCs can access payment disbursement notifications through the project home page.

In addition to, or instead of, notifying the GC of payment for a GC disbursement, the CPMS 10 may notify subcontractors or material suppliers who received payment for debit by using the Withdrawal Payment Received screen, as shown in Figure 75D.

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 modify the overall project budget (generally expanding the budget) by adding new expense lines, separating expense lines, by changing existing expense lines, 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 pending authorizations

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 during 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, a Create Drawout Time Sheet task, and an 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 Specify 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 facility 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 authority can include any engineering party 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.

In some embodiments, CPMS 10 can help users (such as general contractors) track compliance (compliance) of project-related parties (such as subcontractors) with certain statutory standards, such as various required documents . These statutory standards may vary from project to project depending on location, owner, title insurer, general contractor or subcontractor. In some embodiments, the CPMS 10 may track a party's required documentation (e.g., legal documents) due to the relationship between a particular party's compliance and payments owed to the party, provide assistance in managing that document, Provide warnings about incompleteness and, in some cases, withhold payment if documents are not ready.

As shown in FIG. 180, in some embodiments, the CPMS 10 may include a file tracking module 400. The document tracking module 400 can specify and track documents such as contracts, requisitions for payment, affidavits, insurance documents, prior liens received from parties related to the project, such as subcontractors and/or subcontractors Notices, Lien Waivers, etc., and can provide warnings and give enforced compliance options for the entire payment process, up to and including an automatic withholding of payments. A document can be associated with a specific project, a specific budget item within a project, a specific party or organization. It should be understood that documents may include paper documents and electronic documents.

In order to define, specify and track files for a project, CPMS 10 may, through a file tracking module 400, support defining data entities of one or more tracked files. The file type data entity may define standard file types and characteristics of standard file types tracked by CPMS 10. CPMS 10 may use the file type data entity to identify standard differences between tracked files in each project, and to identify the nature of warnings and options for each file type to enforce compliance. For example, each file type data entity may contain a file name and a valid status (such as "incomplete", "unsigned", "signed", "not received", "received", "active", "expired", etc.) list. While other legal document types apply in different situations and in different legal jurisdictions, three typical legal document types can include agreements with valid statuses "incomplete," "unsigned," and "signed"; Forms with valid statuses "Not Received" and "Received"; and certificates with valid statuses "Not Received", "Current", and "Expired".

CPMS 10 can also provide a project document request form, on which the project manager can create a list of required documents from various subcontractors for a particular project. For ease of explanation, "subcontractor" is used to refer to traditional subcontractors, subcontractors under subcontractors, and material suppliers. Additionally, in some embodiments, legal document tracking functionality may apply to subcontractors and material suppliers both on and off the system.

The project document requirements form identifies the project identifier, legal document type, and document name. The file name can be entered by the project manager and can include values such as "Subcontract", "Certificate of Insurance", "City License", etc. For ease of explanation, "project manager" is used to refer to online participants (such as general contractors, project owners, title insurance companies, etc.) Each subcontractor defines the document requirements).

The CPMS 10 may also use other data entities to track the status of each subcontractor's compliance with engineering document requirements. For example, CPMS 10 may use a subcontractor project document table that includes project identifier, document name, subcontractor identifier, document status, document identifier (if optional), and document expiration date (if optional). Figure 181 shows a conceptual data model of data entities related to file tracking.

In some embodiments, the system 10 may also allow project managers or subcontractors to create new file types to address legal requirements of the project manager or subcontractor, the nature of the project, or the jurisdiction or participant or country where the project is located special needs. Optionally, the system may provide project managers or subcontractors with screen displays or other mechanisms to assist users in creating new document types.

In some embodiments, rather than defining a specific file type, system 10 defines a single file type for all types of files with a single set of states. A single document type may specify one or more data elements, such as the document identifier, document date, expiration date, etc., of a particular document required by a party (such as a subcontractor). In some embodiments, each data element is optional. If the project manager enters an expiration date, the file tracking module considers that the file will expire on that expiration date, and tracks the expiration time. Each document defined in terms of a single document type is also associated with various states (eg "not received", "received", "unavailable"). In some embodiments, the default status of each file may be designated as "not received."

By using the single document type described above, after the project manager selects one or more documents that need to be obtained from subcontractors related to a particular construction project, the system 10 can automatically check the status of the documents and can dynamically determine the status of the documents. Still expired. For example, if a file has a status of "not received" or "unavailable," system 10 may determine that the file is neither current nor expired. Likewise, documents with a status of "Received" but no expiration date are considered active by the system 10. Additionally, documents with a status of "Received" and an expiration date are considered active by the system 10 when the system or current date is less than the document expiration date, and are considered active by the system 10 when the system or current date is greater than the document expiration date. considered expired. The system 10 can dynamically evaluate whether a file is current or expired when such information is necessary for processing or display.

FIG. 182A shows the file requirements page 450. The project manager can use the document requirements page 450 to select the documents that are required or obtained from subcontractors associated with a particular construction project. The project manager can enter the file selection page 450 from the link 452 of the project home page 454, as shown in FIG. 183 . In some embodiments, the CPMS 10 only allows project managers to access the document requirements page 450.

The Documentation Requirements page 450 allows the project manager to create a list of required legal documents for a project. The table supports any number of rows (from zero to infinity) and may allow a project manager to add files, select files for deletion and/or select files for editing. In some embodiments, the table contained in the file requirements page 450 displays a file type column, which includes a drop-down menu providing system-predefined file types, and a file name column, which includes a list for user input and/or Edit the alpha-numeric field.

As shown in FIG. 182A, the document requirements page 450 may display a project number, a project identifier, and a list of documents requested from one or more subcontractors associated with the project. For each listed file, the project manager can use a selection mechanism (eg, radio buttons) 456 to select at least one mandatory action. A mandatory action specifies at least one action to be automatically performed by the system 10 when the subcontractor fails to provide the required documentation. For example, mandatory actions may include a "suggest only" action that includes automatically notifying project managers of missing files. Mandatory actions may also include "Hold Payment" actions, which include automatic hold payments to subcontractors who do not provide the required documentation.

As shown in Figure 182A, project managers can optionally track expiration of required files. For example, a project manager may use a track expiration selection mechanism 458 (eg, a check box) associated with a particular file to indicate whether the track file expires. In some embodiments, if the project manager selects the track expiration mechanism 458 for a particular file, the project manager can specify one or more notification dates by using the one or more notification date selection or input mechanism 460 . The system 10 can determine the number of days of advance notice of expired documents that the system 10 needs to warn the project manager and/or subcontractors that the documents are about to expire by using a notification date mechanism. In some embodiments, a project manager may specify multiple notification dates for a particular document. For example, as shown in FIG. 182A, the project manager may designate a first notification date and a second notification date. In some embodiments, if the project manager specifies a zero notification date, the system 10 will not send any expiration warnings before the file is due. Even if the project manager specifies a zero notification date, the system 10 can notify the project manager when the file is due. The default value for notification date can be set to zero.

The file requirements page 450 may include an add requirement selection mechanism 462 that a project manager may select to add a file to the list of required files. Additionally, the file request page 450 may include one or more delete file selection mechanisms 464 by which the project manager may delete one or more files from the selected files. As shown in FIG. 182A , the project manager can save and submit changes to the project's required files by selecting the save settings option 466 included in the file requirements page 450 . Additionally, the project manager may cancel any modifications to the documents listed on the document requirements page 450 by selecting the deselect mechanism 468 .

In some embodiments, system 10 may automatically select and specify one or more files and/or file options for a particular project. For example, the system 10 may automatically select a lien release to track and assign a payment hold enforcement action to the requested lien release. CPMS 10 can also provide one or more document requirements pages similar to document requirements page 450, which are used to enable project managers to specify document requirements at other levels than project levels, such as organizational level, budget level, and budget expenditure item level , contract level, etc. For example, CPMS 10 may provide a Documentation Requirements page that enables project managers to specify organizational level documentation requirements. Organization-level documentation requirements specify the required documentation for each organization with which the project manager is contracted, regardless of the specific project associated with that organization.

After the project manager specifies file options and/or requirements for a specific project, the CPMS 10 may generate a file request notification 469a, as shown in Figure 128B. The CPMS 10 may display a document requirement notice 469a to subcontractors associated with the project, either before or after the subcontractor accepts responsibility for the assigned tasks for the project. As shown in FIG. 182B, a file requirement notification 469a may list each file required by a party, along with mandatory actions associated with the file. If the project manager modifies the documentation requirements for the project (eg, using the documentation requirements page 450), the system 10 may generate a documentation requirements modification notification 469b, as shown in Figure 182C. System 10 may display notification 469B to each party involved in the project, such as subcontractors or material suppliers. In some embodiments, as shown in FIG. 182C, the file requirement modification notification 469b may include a link 469C that each participant may select to view the file status individual page 490, as described below in FIG. The state of the file obtained by this party.

Figure 184 illustrates a file status summary page 470 according to one embodiment of the invention. The project manager may use the document status page 470 to enter information regarding a particular subcontractor's compliance with project document requirements. In some embodiments, the project manager can reach the file status summary page 470 by selecting a link 472 included in the project manager's project home page 454, as shown in FIG. 183 .

As shown in FIG. 184, the document status summary page 470 can display the status of one or more documents that need to be obtained from all subcontractors associated with a project in a single view or page. Document status summary page 470 may display the project name, project number, a list of all subcontractors associated with the project (one or more layers only) and a column for each tracked document for the project, indicating the required The name of the file (as defined by the project manager). For each document contained in the document status summary page 470, the document status summary page may display the status value, expiration date (if available), on hold placement status, and on hold payment information for each subcontractor.

In some embodiments, as shown in FIG. 184, the status of each file may be indicated by a different color or other visual representation. For example, if a document has a status of "Not Received", the cell associated with that document may be colored orange, indicating that the document is missing. If the status of the file is "Received", the file is current, and the expiration date of the file is 60 days or more from the system or the current date, the box related to the file is green, indicating that the file is considered the current document. If the status of the file is "Received", the file is current, and the expiration date of the file is within 60 days from the system or the current date, and the box related to the file is yellow, indicating that the file is less than 60 days from the expiration date . If the status of the file is "Received" and the file is expired, the box related to the file will be red, indicating that the file has expired. Similarly, if the status of the file is "unavailable", the grid related to the file is grayed out, indicating that the file is not available to the current subcontractor.

As shown in Figure 184, if the status of the file indicates that the file is less than 60 days from the expiration date or has expired, the file status summary page 470 may display the expiration date of the file. Additionally, if the status of the file indicates that the file has not been received or has expired, and the file is assigned a "Payment Withhold" mandatory value, the file status summary page 470 may indicate that payment is on hold because the file has not been received or has expired. Additionally, if a payment is on hold, the document status summary page 470 may show that previous payments were also on hold due to missing or expired documents. If more than one payment for a single SCE has been placed on hold in a particular payout, the file status summary page 470 may also display a list of each payout on hold. As shown in FIG. 184, the file status summary page 470 may also include a withdrawal link 471 that includes withdrawals that are on hold. In some embodiments, the Project Manager can use the Payout link 471 to view the Manage Payouts page 585, as depicted in Figures 197A-B below.

In some embodiments, the document status summary page 470 may also contain links associated with each specific SCE listed that the project manager may select to view document information for that particular SCE. For example, each subcontractor listed in the document summary page 470 may contain a link 472 by selecting which the project manager may view the document status individual page 480, as shown in Figure 185A.

As shown in FIG. 184, the document status summary page 470 may also contain an Edit Document Requirements link or other selection mechanism 474 by which the project manager may select to enter the document requirements page 450 and view and/or edit the project's documents Require.

As shown in FIG. 184 , document status summary page 470 may include a document report via SCE link 473 and a document report via document link 475 . The project manager may select Documentation Report via subcontractor link 473 to view a report indicating the status of all documentation required from subcontractors for one or more projects. Likewise, a project manager can select a file report via file link 475 to view a report indicating the status of all files that need to be obtained from subcontractors for one or more projects.

In some embodiments, the information displayed on the document status summary page 470 can be updated when the project manager makes changes to the documents required for a particular project (such as making changes to a project's document requirements table). Where this change is made, the legal document tracking table and document status summary table 460 are updated accordingly, or rows are added, or rows are deleted, and the document names are also changed. For example, if the project manager adds a new document to the legal document requirements table for the project, the new table row is added to the legal document tracking table, one row for each subcontractor, and shows the document name (such as from the legal document tracking table ) and the initial state of the file. In some embodiments, the initial state of a new document is automatically set to one of the valid states associated with the document type (eg, a new type protocol document may have an initial default state value of "incomplete"). The project manager can update the tables and/or document status summary pages at any time during the project.

As described above, the project manager may select the link 472 associated with the SCE listed on the document summary page 470 to view the document status individual page 480, as shown in FIG. 185A. As shown in Figure 185A, the Document Status individual page 480 may display a table with columns and one row for each document that needs to be obtained from a particular subcontractor (as identified by the Project Legal Document Requirements table). Subcontractors (and projects) associated with the document status individual page 480 can be identified at the top of the page 480 . These columns may include: a file name column, which in some embodiments is not editable; a file status column, which contains a drop-down menu or other type of selection mechanism Provides a valid status; an optional file identifier column, which can be an alphanumeric field; and an optional file expiration date column, which includes a date field. The file status individual page 480 may also include indications of mandatory actions associated with particular files.

As shown in FIG. 185A, the file status individual page 480 displays the file's identifier. In some embodiments, the system 10 automatically sets the file's identifier upon receipt of the file from the subcontractor. For example, system 10 may randomly assign unique identifiers to documents received from SCEs. A project manager or subcontractor may also assign unique identifiers to documents.

For each document listed on the document status individual page 480, page 480 shows the document date and expiration date. In some embodiments, the project manager sets file dates and expiration dates for specific files. For example, the project manager can set the file date to be the file effective date or the project manager's receipt date. Dates entered by the project manager through use of the document status page 480 can be validated by the system 10 . In some embodiments, system 10 may also automatically set file dates and/or expiration dates for specific files.

As shown in FIG. 185A, the file status individual page 480 may also display mandatory actions assigned to each desired file. As described above, mandatory actions define actions to be automatically performed by the system 10 if the required documentation is not provided by the subcontractor

As shown in FIG. 185A, the document status individual page 480 may include a document action column listing one or more actions that may be performed by the project manager for a particular document. For example, if a subcontractor submits a particular document, the document action column may include viewing the submitted document via view link 483 . Other actions included in the File Actions column may include a download link to download a submitted file, an edit link to edit a submitted file, a submit link to delete a submitted file, and a submit link to submit a file on behalf of a subcontractor .

If the project manager makes any changes to the data displayed on the document status individual page 480, the general contractor can select the save update selection mechanism 484 contained in the page 480 to save this change, or select the deselect contained in the page 480 mechanism 486 to undo the change. In some embodiments, saved modifications from the file status individual page 480 are automatically reflected in the file status summary page 460 .

System 10 may also provide versions of document status individual pages 480 to subcontractors associated with document information contained within particular document status individual pages 480 . The version of page 480 provided to the subcontractor may contain a view-only version of page 480 (as opposed to the editable version provided to the project manager). As shown in FIG. 185B, the view-only file status individual page 490 displays the project (name or identifier) and the party or organization (eg, name or identifier) and party or organization (eg, name or identifier). In some embodiments, the subcontractor can access the view-only file status individual page 490 by using link 491 on the project home page 500, as shown in Figure 185C.

As shown in FIG. 185B , the view-only version of the file status individual page 490 may display the same information as the editable version of the file status individual page 480 displays. For example, the view-only file individual page 490 may display the file name, file status, file identifier, file date, expiration date, and mandatory actions for each SCE required file. In some embodiments, CPMS 10 may prevent subcontractors from modifying the data displayed on page 490 of the view-only version.

The view-only file status individual page 490 may also contain a file action column listing actions one or more SCEs can perform for a given file. For example, a file action column may contain a submit link 492 . The subcontractor may select the link 490 associated with the particular document listed on page 492 to electronically submit the required documents to the system 10 . Other actions included in the file action column may include a view link to view the submitted file, an edit link to edit the submitted file, and a delete link to delete the submitted file.

If the SCE selects the submit link 492 associated with a particular file, the system 10 may display the submit file page 510, as shown in Figures 186A-B. Submit files page 510 may be used by subcontractors to select one or more files for electronic submission to system 10 . In some embodiments, the submit file page 510 may include a browse selection mechanism 512 that the SCE may select to search in one or more storage devices and/or file directories for that particular file. Files found or selected by the subcontractor while browsing the storage device and/or file directory may be displayed on the input mechanism 513 . The subcontractor can also browse the file by directly entering the file name (eg, the full path name) of a particular file by using the input mechanism 513 and/or by using the browse selection mechanism 512 .

Once the SCE locates and selects or enters the specific files for submission, the SCE may select the add attachment selection mechanism 514 included in the submit file page 510 . The subcontractor may also select the clear selection mechanism 516 included in the submit file page 510 to clear the file or file name displayed in the input mechanism if the file has not been submitted to the system 10 .

As shown in FIG. 186B , files added or attached by the subcontractor by using the Add Attachments selection mechanism 514 may be listed on the Submission Files page 510 under the "Attachments" heading. The subcontractor may delete or remove one or more additional files by selecting a deletion option mechanism 518, such as a check box, associated with the particular file. After the SCE selects one or more additional files for deletion, the SCE may select the delete selection mechanism 520 included in the submit file page 510 to delete the selected files from the list of attached files.

Once the SCE attaches one or more files, the SCE may select the submission selection mechanism 522 included in the submit files page 510 to electronically transmit the attached files to the system 10 . After the SCE transfers the attached files to the system 10, the system 10 may generate a file transfer notification, as shown in FIG. 187 . The system 10 displays a file transfer notification 524 to the SCE.

After the subcontractor submits one or more additional documents, the system 10 may also generate a review submitted document project action or notification, and may send the project action to the project manager who received the submitted document. In some embodiments, the system 10 lists the View Submitted Files project action under Project Manager Pending Actions in the Project Manager Project Home Page 526, as shown in FIG. 188 . If the project manager selects a project action or related selection mechanism from the project home page, the system 10 may display a file receipt notification 528, as shown in FIG. 189 . Notification 528 may notify the project manager that the subcontractor has submitted an electronic copy of one or more required documents. Additionally, the document receipt notification 528 may list one or more documents received electronically from the SCE.

Receive file notification 528 may also notify the project manager that he/she should download each submitted file. In some embodiments, as shown in FIG. 189 , to download and view submitted files, the project manager may select the selection mechanism 530 associated with the received files (eg, links associated with listed files) at the received file notification 528 . If the project manager selects the selection mechanism 530, the system 10 can download and display the file submitted to the project manager.

After the project manager reviews the submitted files, the project manager can update the status of the files tracked by the system 10 as needed. For example, as shown in FIG. 189 , receiving file notification 528 may include updating file information selection mechanism 532 . If the project manager chooses to update the file selection mechanism 532, the system 10 may display the file status individual page 480 associated with the submitting file subcontractor, as depicted in FIG. 185A! As described above, the project manager can make changes to the data displayed on the document status individual page 480 and select the save option mechanism 484 included in the page 480 to save the changes. In some embodiments, if the project manager modifies the data displayed in the file status individual page 480, the system 10 may generate a file information update notification 540, as shown in FIG. 190 . The system 10 may display a file information update notification 540 to the project manager.

In some embodiments, only project managers can update file information. In some embodiments, system 10 may automatically update or modify document information in addition to or instead of manual modification by a project manager. For example, the system 10 may automatically change the document status to "received" after the subcontractor submits the document to the system 10.

In some embodiments, the system 10 performs routine or periodic file reviews (eg, every night) to identify expired files. For example, as a batch activity, the system 10 may check for expired files on a regular basis (eg, daily), such as when the system is not busy (eg, before 5 am). As shown in FIG. 191, the system 10 can scan the documents managed by the system, and for each document, can determine whether the document's setting is "received". If the status of a particular document is set to "Received", the system 10 scans or consults other or next documents managed by the system 10.

If the status of a document reviewed by the system 10 is set to "received", the system 10 can determine whether the document is associated with an expiration date (eg, the expiration date attribute associated with the document is set to a specific date). If the document is not associated with an expiration date (eg, the expiry date attribute associated with the document is set to zero), the system 10 may scan or refer to another or next document managed by the system 10 .

If the document that system 10 is reviewing is associated with an expiration date, system 10 may determine that the current or system date is greater than or equal to the document's expiration date minus the number of days set by the project manager for the first notification. If the system date is less than the file expiration date minus the number of days of the first notification, the system 10 determines that the file is not expired and no expiration notification is required, and another or next file managed by the system 10 can be scanned or viewed.

If the system 10 determines that the system date is greater than or equal to the file expiration date minus the number of days of the first notification, the system 10 can determine whether the first notification has been sent for the file. In some embodiments, system 10 may track when and whether overdue notifications are sent. If the first notification has not been sent, system 10 may send a first overdue warning notification. In some embodiments, the system 10 sends the first expiration warning notification to the subcontractor and/or project manager associated with the file. Figure 192 illustrates an overdue warning notification 550 according to one embodiment of the invention.

As shown in Figure 191, the system 10 determines that the first notification for a particular file has been sent, or after the system 10 sends the first notification for a particular file, the system 10 determines whether the current system date is greater than or equal to the file expiration date minus Go to the number of days associated with the second notification set by the project manager. If the system date is less than the file expiration date minus the number of days associated with the second notification set by the project manager, the system 10 may scan or view another or next file managed by the system 10 .

If the system 10 determines that the system date is greater than or equal to the expiration date of the file minus the number of days associated with the second notification, the system 10 may determine whether a second notification has been sent associated with the file. If the second notification has already been sent, system 10 may send a second overdue warning notification (such as overdue warning notification 550 shown in FIG. 192 ).

If system 10 determines that a second notification has been sent for a particular file, or after system 10 sends a second expiration warning notification for a particular file, system 10 may determine whether the current system date is greater than or equal to the file's expiration date. If the system date is less than the file expiration date, the system 10 may scan or view another or next file managed by the system 10 .

As shown in Figure 191, if the system 10 determines that the current system date is greater than or equal to the expiration date for a particular file, the system 10 may determine whether the expiration date for that file has been sent. If an expiration date has been sent, the system 10 can scan or view additional or next documents managed by the system 10 .

If the expiration date has not been sent, the system 10 may send an expiration notification. In some embodiments, system 10 may send expiration notifications to subcontractors associated with expired documents and/or project managers associated with projects. Figure 193 illustrates expiration notifications in accordance with one embodiment of the present invention. After the expiration notification has been sent, the system 10 can scan or view additional or next files managed by the system 10 .

When a draw is initiated (or a subcontractor is added or selected for a certain draw), the system 10 can also check the status of the documents that need to be obtained from each subcontractor included in the draw and, if necessary, generate a commit Document engineering actions or notifications to subcontractors with missing or outdated documents. For example, if the status of a document that needs to be obtained from a subcontractor is set to "Not Received," the system 10 may generate a submit document engineering action that requires the missing document. In addition, if the status of the documents to be obtained from the subcontractor is set to "Received" and the relevant expiry date is within the preset time after the withdrawal date (such as 60 days), or coincides with or precedes the withdrawal date On the draw date, the system 10 may also generate a submit file project action that requires a new file. Figure 194 illustrates an update required file engineering action or notification 560 in accordance with one embodiment of the invention. In some embodiments, the SCE can access the notification 560 through a link or selection mechanism 562 included in the SCE home page 500, as shown in Figure 185C.

As shown in FIG. 194, the notification 560 to update required documents may include a selection mechanism 564 that the SCE may select to view the status of the SCE's required documents and/or submit required documents (e.g. using the document status individual page 490).

In the event that the project manager selects the "hold payment" action as a mandatory value for a particular document, the system 10 (such as after the project manager has signed his invoice) can place a "hold" on any missing or Subcontractors with expired documents are automatically withheld from payment. For example, the system 10 can review the status of required documents for each subcontractor included in the checkout, and can determine whether the documents associated with the subcontractor have a "not received" status, or have expired. If the document has not been received or has expired, the system 10 can determine whether the document is related to a "payment withholding" enforcement action. In some embodiments, the system 10 automatically withholds payment to the subcontractor as soon as one document is out of compliance (eg, the subcontractor is missing one of three required documents). If a subcontractor has missing or outdated documentation, the system 10 can only suspend payments related to that subcontractor for the current drawdown, and not suspend any other outstanding payments related to other drawdowns. In other embodiments, the system 10 may suspend all outstanding payments to a subcontractor if the subcontractor has missing or expired documentation.

When the system 10 holds a payment, the system 10 may record the hold (eg, record indicating the reason for the hold due to missing or expired documents) and generate one or more notifications or messages alerting the individual on which the payment is held. As depicted in FIG. 74B, viewing the withdrawal request form may indicate any payment holds (eg, automatic holds or manual holds) that will not be included in the payment for the pending payment.

If payment to a particular SCE is on hold, the system 10 may generate a payment hold notification 570, as shown in Figure 195A. The system 10 may display a payment hold notification 570 to the subcontractor (eg, via a link included in the view all information screen 572, shown in Figure 195B). Hold payment notification 570 as shown in Figure 195A may notify the SCE that a hold has been placed in payment to the SCE. In some embodiments, the payment hold notice 570 may also contain one or more links or selection mechanisms by which the subcontractor may choose to review the payment hold and/or perform actions to correct the payment hold .

In some embodiments, if a payment to a subcontractor to be withheld is flagged for a particular payment method, the system 10 may simply notify the project manager specific to the payment on hold, rather than automatically hold the payment. For example, if a payment to a subcontractor to be held is flagged as a payment made outside the system 10 (such as by manual check), the system 10 may generate a payment that is in hold engineering action or notice 580, as shown in FIG. 196 . The system 10 may display the payment on hold notice 580 to the project manager. A payment on hold notice 580 may notify the project manager that payment to a particular subcontractor should be held in accordance with missing or expired documentation. Payment for hold notice 580 may also indicate the method associated with the payment. In addition, as shown in Figure 196, the notification 580 can indicate whether the project manager wants to change the payment method related to payment (such as changing the payment method to the method of internal management of the system 10), and the project manager should suspend the payment. Payments on hold notice 580 may also include a link or other selection mechanism 582 by which the project manager may elect to review the status of documents associated with subcontractors whose payments are on hold (e.g., through Supplier-related file status individual screen 480).

As described above in reference to Document Requirements page 480, the project manager can specify a "suggest only" mandatory action on required documents. Same as the "suspension of payment" mandatory action, after the project manager signs his/her payment application, the system 10 can send a file review project action or notification to the project manager for subcontractors with missing or expired documents. For example, the system 10 may review the status of documents that need to be obtained from subcontractors included in the draw, and if the status of the required documents is "not received" or expired, the system 10 may generate a review document engineering action or notification, and Display project actions or notifications to project managers. In some embodiments, the system 10 may generate a review document engineering action or notification for each subcontractor with missing or outdated documents. In other embodiments, the system 10 may generate a single review document engineering action or notification, identifying all subcontractors with outdated or missing documents. View file project actions or notifications may include a link or selection mechanism by which a project manager may select to view a file project action or notification (e.g., file status individual page 480 or file status summary page 470) associated with a review file project action or notification The status of the documents obtained by one or more subcontractors.

In some embodiments, only the Project Manager can release the payment hold by manually releasing the payment using the Manage Payments page 585, as described below with reference to Figures 197A-B. In some other embodiments, the system 10 may automatically release the payment hold. For example, the system 10 may automatically release any payment hold to the subcontractor once the required documentation from the subcontractor is current.

To manually release a payment hold, the Project Manager may use the Manage Payments page 585, as shown in Figures 197A-B. As shown in Figures 197A-B, the Manage Payments page 585 may list each payment hold for a particular drawdown. The Project Payments page may also list each payment for a specific withdrawal.

As shown in Figures 197A-B, the Manage Payments page 585 may include a View Lien Waiver option 586, a Document Tracking option 587, and a View Withdrawal Request option 586 to review the documents filed by each subcontractor associated with the withdrawal. Lien Waiver. The project manager can select the document tracking selection mechanism 587 to view the status of each subcontractor's submitted documents related to the withdrawal (such as by viewing the outstanding withdrawal requirements described by Figures 60A, 62, 68A, 72 or 74A-B Screen).

For each subcontractor (or payer) listed on the Manage Payments page 585, the page 585 may include an edit link or selection mechanism 589 by which the project manager may select for editing and specific Subcontractor-related payment information. In some embodiments, if the project manager selects the edit link 598 associated with a particular SCE, the system 10 may display the manage payments page 590, as shown in Figures 198A-B. Using the manage payments page 590, the project manager can modify information related to payments made to the subcontractor.

As shown in FIGS. 198A-B , the Manage Payments page 590 may include a proceed verification option 591 , a split payment option 592 , and a release hold option 593 . In order to change the payment method related to payment (such as changing the payment method to a method managed outside the system 10), the project manager can select the check selection mechanism 591 . In some embodiments, changing the payment method associated with the payment to a method managed outside of system 10 may automatically release the payment hold. If the project manager chooses to review the selection mechanism 591, the system 10 can automatically update the payment method displayed on the manage payment page 590, can display a separate change payment method page, or can allow the project manager to update the payment method displayed on the manage payment page 590 payment method.

In order to split a payment into multiple sub-payments, the project manager may select split payment selection mechanism 592 . For example, split payment option mechanism 592 may be selected if the project manager wishes to pay subcontractors in multiple sub-payments rather than a single lump sum payment. In some embodiments, if the project manager selects the split payment option 592 , the system 10 may display an individual split payment form or may allow the project manager to edit the payment amount displayed on the manage payments page 590 .

In order to release the suspension of payment, the project manager may release from the selection of the suspension selection mechanism 593 . In some embodiments, the project manager may also provide a reason or comment for releasing the payment hold by using the comment input mechanism 594, as shown in Figures 198A-B. If the project manager chooses to release from the suspension selection mechanism 593, the system 10 can change the payment status, as displayed on the management selection page 590, from "Held" to "Requested", as shown in Figure 198B.

If the project manager changes the payment information displayed in the manage payment page 590 , the project manager can select the save changes option 595 included in the manage payment page 590 . If the project manager saves changes to the payment information, the system 10 can update the manage payment page 590 shown in Figure 198B, and can update the manage payment screen 585 shown in Figure 197B. Additionally, in order to ignore any changes to the payments displayed on the Manage Payments page 590 , the project manager can select a deselect mechanism 596 included in the page 590 .

In some embodiments, manage payments page 590 may include other options. For example, the Manage Payments page 590 may include a payment selection mechanism by which a project manager may manually hold payments if the payment has not been disbursed.

In some embodiments, the Manage Payments page 585, which lists all payouts for a particular payout, may be combined with the Manage Payments page 590, which lists payment information associated with a particular payout and allows the project manager to modify these payouts. information to create a payment page 600, as shown in Figure 198C. In some embodiments, payment page 600 may display all payments for a particular withdrawal. In other embodiments, payment page 600 may only display payment holds for certain withdrawals. As shown in Figure 198C, the project manager can use the payments page 600 to hold or release one or more payments for withdrawal. For example, each payment displayed on payment page 600 may be associated with a selection mechanism 602 (eg, a checkbox) that a project manager may select to select a particular payment. After the project manager has selected one or more payments, the project manager can select the payment selection mechanism 603 included in the payment page 600 to suspend all selected payments. Additionally, the project manager may choose to release selected payment selection mechanism 604 to release all selected payments. In some embodiments, the project manager may also enter a reason or comment for withholding or releasing a particular payment by using the comment entry mechanism 605 included in the payment page 600 . By using the Suspend Selected Payment Option 603 and Release Selected Payment Option 604, the Project Manager may manually suspend or release payments. In some embodiments, as previously described, the project manager may manually hold and release payments for a variety of reasons other than missing or out-of-date required documents.

In some embodiments, if the project manager manually releases the hold, the system 10 will require authorization from an authorized user associated with the project manager. For example, if a specific user related to the project manager is required to release payment authorization, the system 10 can generate special expenditure engineering actions or notifications, and can list the engineering actions or notifications on the authorized user's engineering home page 610, as shown in FIG. 199 . The engineering action or notification may include a link or other selection mechanism 612 by which an authorized user may select to view a manage payment page 620 , as shown in FIG. 200 . The project payment page 620 may include the same information and selection mechanisms as the management payment page 585 , but may include a disbursement funds selection mechanism 622 . After authorizing the user to review the released payment, the user may select the payout funds selection mechanism 622 to authorize the release of the suspended payment. After the authorized user selects the disbursement funds selection mechanism 622, the system 10 may generate a payment disbursement notification 630, as shown in FIG. 201 . System 10 may display payment disbursement notification 630 to the authorized user.

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. Therefore, 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 the components of the CPMS 10 are shown connected in a network, no specific network structure 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 (23)

1. manage a method for construction payment process, this construction payment process relates to the multiple participants that are associated with construction work in network, and the method comprises:

Use computing machine to be defined in the multiple required file that must transmit between at least two participants during the process of described construction work in described multiple participants, wherein said multiple participants comprise the first participant, the second participant and the 3rd participant;

On participant equipment, show that described the first participant must offer the list of described multiple required files of described the 3rd participant;

By described participant equipment, from described the second participant, receive the selection of one of described multiple required files;

By described participant equipment, from described the second participant, receive the selection that the pressure pressure action lists is moved, wherein said pressure action lists comprises cancels payment action;

By described computing machine, selected pressure action is assigned to selected file;

By described computing machine, checked the state of selected file;

If selected file does not offer described the second participant by described the first participant through described computing machine, by described computing machine, described pressure action is occurred automatically, wherein, when selected pressure action comprises cancelling, pay action, make this pressure action automatically comprise and cancel the payment to described first party from described third party.

2. the method for claim 1, further comprises selected file designated state.

3. method as claimed in claim 2, wherein said state comprised, unsigned, signed, do not received, received, existing, expired and can not apply at least one.

4. method as claimed in claim 2, wherein said state is assigned to the file of described selection according at least one selection receiving in electronics mode from described multiple participants.

5. method as claimed in claim 2, wherein said state is specified automatically.

6. method as claimed in claim 2, further comprises automatically by electronics mode described state notifying at least two participants.

7. method as claimed in claim 2, also comprise upgrade described state and automatically in electronics mode the state notifying being upgraded at least two participants.

8. the method for claim 1, also comprises automatically in electronics mode selected pressure action notice at least two participants.

9. the method for claim 1, the list of wherein said pressure action comprises notification action, the pressure action of wherein said selection is described notification action, and wherein automatically make described pressure action comprise: if described at least one file is not transmitted between at least two participants, automatically to notify at least one party in described multiple participant.

10. the method for claim 1, wherein selected pressure action is cancelled described in being and is paid action, and automatically makes described pressure action comprise automatically by electronics mode this postponement advise for payments at least one party in described multiple participants.

11. the method for claim 1, wherein selected file comprises agreement, at least one in list and certificate.

12. the method for claim 1, further comprise at least one file are specified to the expiration day.

13. methods as claimed in claim 12, wherein specify the described expiration day according to the selection that at least one party receives by electronics mode from described multiple participants.

14. methods as claimed in claim 12, wherein specify the described expiration day automatically.

15. methods as claimed in claim 12, wherein make described pressure action automatically be included in the described expiration day and are automatically notified at least one party of described multiple participants this expiration day.

16. methods as claimed in claim 12, also comprised described appointment expiration notice day expiration day.

17. methods as claimed in claim 16, wherein make described pressure action automatically be included in and expiration notice day automatically in electronics mode, notify at least one party to described multiple participants the expiration day.

18. the method for claim 1, also comprise the file that transmits described selection in electronics mode between described the first participant and described the second participant.

19. methods as claimed in claim 18, also comprise and in electronics mode, notify at least one party to described multiple participants the file of the described selection of transmitting in electronics mode between described the first participant and described the second participants.

20. the method for claim 1, the file of described selection is that lien is abandoned.

21. the method for claim 1, the list of wherein said pressure action comprises notification action, the action of file expiration notice and cancels to pay and move, and wherein makes described pressure action automatically comprise:

When selected pressure action is described notification action, if selected file does not transmit between at least two participants, automatically notify at least one party of described multiple participants,

When selected pressure action is that the action of file expiration notice and selected file are the renewal versions of expired file, the expiration day that is assigned to this expired file, notify at least one party to described multiple participants, and

When selected pressure action is to cancel to pay action, if selected file does not transmit between at least two participants, at least one party of described multiple participants is postponed paying.

22. the method for claim 1, also comprise the construction work configuration file of storing in the storer that is accessed in described computing machine, this construction work configuration file identifies each role of multiple participants in multiple participants of being associated with this construction work and this construction work

Wherein, according to described construction work configuration file, described the 3rd participant is the payer of this construction work, described the second participant is the contractor that is subordinated to described the 3rd participant for this construction work with the form of treaty, described the first participant is the contractor that is subordinated to described the second participant for this construction work with the form of treaty, and does not directly sign a contract with described the 3rd participant for the first participant described in this construction work.

23. the method for claim 1, wherein when selected pressure action is to cancel to pay action, make described pressure move automatic generation also comprise response from described the first participant receive invoice and automatically with electronics mode described in cancel and pay at least one party of action notice to described multiple participants.

Images