Part 4 — The interfaces

13. The project modules

The same project modules run in Legacy KI on this instance, with three differences in the set: there is no Design section, Purchase Orders are replaced by Commitments, and RFIs, Submittals, Transmittals and the Punch List are modules of their own rather than folded into Issues.

Group	Modules
Project	Project Home · Contracts · Team Members
Financials	Change Estimates · Change Orders · Budget Adjustments · Cost Control · Billing Items · Pay Applications · Commitments
Construction	Issues · RFIs · Submittals · Transmittals · Schedule · Safety · Daily Logs · Punch List

The sections below describe each module. Where one behaves differently here, the page says so.

13.2 Financials

Change Orders. Add change orders and publish them for signature. This screen also shows a summary of the current contract amount. A change order needs someone to sign it: a client contact must be identified as the change order approver on the project before a change order can be created.

A change is worked up as a Change Estimate first — priced, and where a subcontractor is involved priced against their number — and only becomes a Change Order once it is agreed. Change Estimates sit with Issues on the Legacy KI menu. Pricing before commitment is the point: a change is negotiable while it is an estimate, and binding once it is an order.

Budget Adjustments. Adjust the budgets held in each Cost Code. Two types, governed by the rules in section 5.2: internal, which must net to zero once the Fee is included, and change order, which must total the amount of the selected Change Order.

Cost Control. The central hub for project financials, showing budgets, costs, and commitments side by side. This is also where margin analysis is done to project the final cost of the job. That analysis is the Forecast: forecast and margin are the same thing under two names, and it is stored under Cost Control rather than as a separate record elsewhere.

Against every Cost Code a project therefore carries four numbers — the budget it was planned at, the actual invoiced against it so far, what is committed but not yet invoiced, and the forecast it is now expected to finish at. Forecast is a judgment rather than arithmetic, and the gap between it and the budget is where a problem shows up first, usually well before it reaches an invoice.

Commitments are the figure worth understanding. Material ordered but not yet invoiced is spent in every practical sense, and counting it the day the purchase order goes out is what makes a problem visible while there is still time to act on it. Costs shown here are the job costs KI owns, and they are expected to match cost per job in QuickBooks; if a Cost Control figure and the general ledger disagree, treat the number on screen as unproven until the two are reconciled.

Billing Items. Adjust the billing schedule — the contract broken into billable line items, which progress billing is measured against. As with budget adjustments there are two types, governed by section 5.3: internal, where the net change must equal zero, and change order, where the net change must equal the change order amount. Commercial contracting calls the same thing a schedule of values; in KI it is Billing Items.

Pay Applications. Create project invoices on a periodic basis by entering the percent complete on each Billing Item. Because a billing is measured line by line, it can be read against the scope it belongs to. The question a pay application answers is not “what is owed this month” but “which parts of this job progressed, and by how much.” Payments are recorded against the pay application they settle, so each billing carries its own history: what was claimed, what was agreed, what has been received, and what is still outstanding.

Retention is used here: a percentage is withheld from each billing until the work is accepted, carried against the lines it applies to rather than as one number at the foot of the invoice.

Subcontractor pay applications are a manual exchange today — the sub sends theirs, and it is keyed in. Bringing that into a portal is a stated goal rather than something that exists.

Commitments. There is no Purchase Orders screen here. A subcontractor is committed through a Commitment, which carries the signed subcontract behind it rather than standing alone as an order.

That difference is the point. A purchase order is an instruction to supply at a price; a commitment is a contract with a party who will be on site, which is why it sits alongside the compliance the subcontract depends on — a current certificate of insurance, a W-9, and a signed Master Agreement, all held at company level in Companies rather than per project.

Every line is coded to the project and to a Cost Code, so the obligation lands on the job’s books the day it is signed and appears as committed cost in Cost Control. When the subcontractor invoices, the invoice carries the same job and cost coding, so the two describe the same work in the same terms. Subcontract reconciliation compares what was committed against what has been billed and paid, which is the check that a subcontract is running to its number.

13.3 Construction

Issues. Any project issue that needs tracking. Internal issues include construction administration questions and quality issues raised by the design or field teams. Client-facing issues and questions are also logged here. Issues are typed by what they concern — design, construction, quality, project controls, or client request — so the log stays readable as it grows and the right person picks up the right question.

Issues, RFIs and Submittals are three separate modules here, and the Issues screen is shared with Change Estimates. An RFI — a request for information — is still a formal question in one direction, from the contractor to the architect or owner, as it always was. The Punch List is its own module too, rather than a type of Issue.

Schedule. The list of project milestones — permit issued, demolition complete, rough-in done, substantial completion. Milestones carry both a target and an actual date, changes are recorded as they happen, and snapshots preserve what the dates looked like at points in time, so “has this date moved, and when” has an answer on the record. Movement in a schedule is normal; movement nobody can trace is the problem.

Alongside milestones, this instance runs a CPM (critical path method) schedule and a four-week look-ahead, with the float and legal-compliance calculations that go with them. Neither runs in KI: the CPM schedule is maintained in Primavera Cloud and the look-ahead goes out by email. The upload section on the Legacy KI schedule screen is not used.

Safety. Monthly jobsite safety inspections, run as a checklist. Every item answered unsafe becomes a Safety Concern on completion, and concerns stay outstanding against the project until somebody resolves one with a note and a photo of the correction. These are not the Issues above — they come only from an inspection and are tracked only here. The jobsite safety plan lives in this section as well.

Legacy KI carries a Safety module, and Job Hazard Analyses are used here. In practice much of the day-to-day safety record is captured in Autodesk alongside the rest of the field work.

Daily Logs. The dated record of one day on one project — weather, who was on site, conditions, issues, and quality observations. Legacy KI carries the module, but in practice the day is recorded in Autodesk alongside the rest of the field work. Bringing it back into KI is a stated goal, not something you can do today.

14–16. The client, vendor and field surfaces

None of the three portals Story runs are set up on this instance.

There is no Client Portal. Contracts, change orders and invoices reach the client outside KI, and there is nothing for a client to log in to.

There is no Vendor Portal. Commitments, changes to them, and requests for pricing all reach the subcontractor by email. Putting that exchange in a portal — where a sub signs their contract, uploads a job hazard analysis, fills in their own pay application, and sees the issues assigned to them — is a stated goal. None of it exists today.

There is no Field App. Field management, submittals and daily logs run in Autodesk, which is not part of KI. Bringing that work back into KI is a stated goal, and it depends on KI covering what Autodesk covers now.

17. Company-wide tools

Outside of any single project, KI gives every employee a set of company-wide modules. These are the screens you will use daily regardless of which projects you are on.

Module	What it is
Dashboard	Covers the projects you are on or following: a snapshot of each project’s next milestone with links, an activity board of what is happening, any issues you have been tagged in, and your time card entry.
Time Entry	Where employees enter their time and assign it to the correct codes and classifications, including hourly billings.
Forms	Where company forms are built and managed.
Reports	Company-level reporting.
Settings	Your personal KI settings.
Contacts	Individual people we work with. Recording a person once means an updated phone number or address updates everywhere it appears.
Companies	The companies we work with, along with their compliance tracking — insurance certificates, W-9s, signed Master Agreements, and similar items. This is where subcontractor compliance is held, at company level rather than per project.

These modules are in Legacy KI on this instance. Roles and permissions — around ninety granular permissions — are administered there too.

Hours are recorded against a project and a Cost Code, which is the part that does the work: it is the same classification the Estimate and the budget use, so labour lands in the category the work was priced under. Hours recorded without it would tell you what a job cost in total but not where it went.

18. Legacy KI

Legacy KI points at the same database as the rest of this instance, so work done in these modules is live data, not a separate copy and not an archive.

Legacy KI is the admin portal on this instance. Everything runs there — projects, estimating, contracts, commitments, cost control, pay applications, scheduling, issues, and accounting — and nothing has been ported to the new Admin Portal yet. Calling it “legacy” says where it is headed, not that it is switched off.

Three modules exist in Legacy KI and are off in both instances, because they were built for a customer the business no longer serves: Shipping and containers, Inventory, and a separate Compliance module. They are not gaps and they are not part of the port.

19. Accounting

Accounting runs in Legacy KI and integrates with QuickBooks, which is our general ledger. Each entity has its own QuickBooks company.

The division of responsibility is exact: KI owns job costs and project billing; QuickBooks owns the books; the integration keeps the two tied together. That tie has a hard requirement behind it: cost per job in KI must equal cost per job in QuickBooks, and revenue per job in KI must equal revenue per job in QuickBooks. Where the two disagree, one of them is wrong and neither can be trusted until the difference is explained. There is no automated reconciliation in the system today, so the comparison is done by hand — this is the single biggest pain point in Accounting and the reconciliation the system needs to close.

Accounting has seven sections, all documented here.

19.1 Accounts Payable

AP invoices are uploaded here and the invoice information is keyed in manually by accounting, then assigned to a project or routed to an approver.
The approver codes and approves the invoice. KI runs three checks at this point: that the cost does not exceed the commitment, that it does not exceed the budget, and that the amount entered by the approver ties to the amount accounting entered.
Approved invoices go back to accounting for a final approval and double-check.
They are then pushed to QuickBooks through our QuickBooks integration.

Subcontractor compliance sits alongside these checks as a business rule: a subcontractor providing labour must have a signed Master Agreement and current insurance on file in the Companies module before its invoice is paid.

That coding is what makes the cost side real. The actual-cost figures in Cost Control are built from coded invoices — documents someone actually received — rather than from an estimate of what has probably been spent by now. It is also what lets a single line on a cost summary be opened up into the specific invoices behind it.

19.2 Accounts Receivable

Project invoices created in KI flow to QuickBooks automatically. This section is where you search and review them. Because billing is the revenue side of the same tie, revenue per job in KI must equal revenue per job in QuickBooks; an invoice that exists in one and not the other, or at a different amount, is the first thing to look for when the two disagree.

19.3 Create Journal Entry

Journal entries are posted here against Job Costs and GL (general ledger) Codes to keep QuickBooks and job costs in balance. Entries post to QuickBooks automatically.

19.4 Job Accounting / Costing

This is our WIP — work in progress — reporting. WIPs are run by Division and by grouping of contracts, because that is how they tie to our P&L.

Within a WIP you select a time period, review the jobs in progress, and perform the standard WIP over/under-billing accrual and report. Each Division-and-contract-grouping WIP posts to QuickBooks as the over/under-billing for that grouping, together with a reversing entry dated the first day of the following month. A WIP is only as good as the agreement underneath it: before running one, check that cost per job and revenue per job in KI tie to the same figures in QuickBooks. Any variance has to be found and explained first, because a WIP built on job costs or billings that disagree with the general ledger will accrue the wrong over/under-billing.

19.5 Journal Entries

A read-only history of past journal entries.

19.6 Payroll

An employee subtab holds employee information, wage cost, and the rates at which they hit jobs. Overhead employees who are not charged to jobs get a GL Code here instead.
The payroll process pulls everyone’s time, is run by our payroll administrator, and ultimately produces everyone’s time cards.
When payroll is complete a report is generated for upload to ADP, and it establishes actual cost by job and Cost Code.
KI consumes that report and creates a journal entry to QuickBooks that charges jobs at billable rates, records actuals, and accrues the difference to a labor reconciliation GL Code.
Payroll then pushes to the job costs you see in Cost Control, calculated as hours × the employee’s billable rate, so QuickBooks and our job costs agree.
History can be searched by project, Cost Code, or time period.

19.7 Accounting Admin

The configuration section for Accounting. It holds the payroll import setup and the check setup. Neither is in use today: payroll comes in through the report generated for ADP and journalised from there, and checks are not written out of KI.