How These Systems Integrate (and What Breaks)

Welcome

Hello, and welcome. This is Super Structures General Contractors — a national general contractor headquartered in Powhatan, Virginia — here to help you and your clients build something that lasts. We're glad you're with us, and we look forward to connecting with you.

Alright, How These Systems Integrate (and What Breaks). Don't let the plain title fool you. Here's the part that actually matters on the job: Integration is a decision about which system is the system of record for each kind of data, and a discipline about keeping cost codes, job numbers, and vendors identical across systems; the connector is the easy part. Learn it well and you'll stop re-keying and stop arguing about whose number is right.

A GC connected its PM platform to its accounting system with the vendor's standard connector. Within a month the controller and the PMs were fighting: budgets did not match, change orders posted to the wrong codes, and a subcontract showed up twice. The connector worked exactly as designed. The problem was that the PM platform had 240 cost codes, accounting had 180, nobody had decided which system owned commitments, and two people had created the same vendor with slightly different names. Three weeks of cleanup fixed it; one afternoon of decisions beforehand would have prevented it.

The data that moves between systems

Across the platforms in this course, the same handful of records flow back and forth:

• Estimate to budget: takeoff and estimating (Bluebeam, estimating tools) into the budget in the PM platform and the job cost system, by cost code.
• Commitments and change orders: subcontracts, purchase orders, and change orders created by the PM, posted to accounting as committed cost and contract value.
• Costs back to the project: actual costs, invoices, and payroll from accounting back to the PM platform so the PM sees cost to date and can forecast.
• Time and field data: time cards, daily logs, equipment hours, and production quantities from the field into payroll and job cost.
• Schedule: the P6 or Microsoft Project schedule into the PM platform for look-aheads, and sometimes activity codes back to cost.
• Documents: drawings and models between Autodesk, Bluebeam, and the PM platform, with the current set published to the field.
• Customers and pursuits: leads and owners from the CRM into the job when it is won, and closeout back to the CRM for follow-up.

The four ways systems connect

• Native connectors built by one vendor for another (Procore to Sage, Buildertrend to QuickBooks, Acumatica to Procore). Easiest to set up, limited to what the vendors chose to sync, and dependent on both vendors keeping it maintained.
• Middleware and integration platforms that specialize in construction data, mapping fields between many systems and handling the mismatches. More flexible, a subscription of their own, and the usual answer when you run more than two or three systems.
• APIs and custom integration built by a developer for your exact flow. Most flexible, and you own the maintenance forever, including every time a vendor changes its API.
• File exchange: CSV and Excel exports and imports, XER and XML for schedules. Manual, but universal and often the honest answer for a small company with a weekly rhythm.

System of record

For every kind of data, one system owns it and the others receive copies. Typical choices: the accounting system owns cost and the general ledger; the PM platform owns documents, RFIs, submittals, and often commitments and change orders; the scheduling tool owns the schedule; the CRM owns contacts and pursuits; the design platform owns models. Write it down in a one-page table with the system, the data, the owner, and the direction of flow. Two systems that both allow editing the same record, syncing both ways, will drift, and the drift shows up as an argument between the controller and the PM.

The master data that must match

Integration lives or dies on three lists being identical everywhere: cost codes (and cost types), job numbers, and vendor and customer names and IDs. Standardize them once, give one person authority to add to them, and lock the others out. Most "the integration is broken" calls are a cost code that exists in one system and not the other, or a vendor created twice with a different spelling.

What breaks, and why

• Duplicates: a record created in both systems before the sync ran. Fix with one-way creation rules.
• Wrong posting: a code mismatch or an unmapped cost type. Fix with a matched master list and a mapping table someone owns.
• Timing: the PM sees a commitment the controller has not approved, or the controller posts a cost the PM cannot see for a week. Fix with agreed approval steps and sync frequency.
• Silent failures: the sync log shows errors nobody reads. Fix with a weekly log review by the integration owner.
• Vendor changes: an update on one side breaks the connector. Fix by testing after every major release and keeping the vendor's support contact handy.

Going Deeper (Intermediate)

Integrate one flow at a time and verify it with real data before adding the next. The usual order: commitments and change orders from PM to accounting, then actual costs from accounting back to PM, then time and field data into payroll, then schedule and documents. After each step, run a reconciliation report for a month: budget, committed, and cost to date should match in both systems to the penny. Only when they do, move on. Name an integration owner with the authority to fix master data and the time to check the sync log weekly.

Set a sync frequency that matches how people work. Nightly is fine for costs; the PM does not need invoices in real time. Commitments and change orders should move within the hour, because the PM is waiting on the approval. Real-time everything sounds better and creates more conflicts.

Advanced / Pro-Level

Pros design integration around where each person works: the PM never opens accounting and the controller never opens the field app, yet both see the same numbers. They use middleware when they run more than two or three systems, because point-to-point connectors multiply quickly and nobody can maintain nine of them. They include data portability in every software contract so a future change of vendor does not strand ten years of job history. They document every integration in a one-page runbook: what flows, when, who owns it, what to check when it breaks. And they resist the urge to integrate everything; a small company with four tools and one clean manual export a week is better off than one with six fragile connectors nobody owns.

Practice Challenge

A 50-person GC runs Procore, Sage 300 CRE, Microsoft Project, Bluebeam, and a spreadsheet CRM. Draw the integration plan: which flows, in what order, which system is the system of record for each, how often each syncs, and who owns it. (Answer: Sage owns cost and ledger, Procore owns documents and change management, Microsoft Project owns the schedule, Bluebeam feeds quantities by export, and the CRM owns contacts; first connect Procore commitments and change orders to Sage hourly with a matched cost code list, then Sage actual costs back to Procore nightly, then schedule import to Procore weekly and Bluebeam exports to estimating per bid; a named office person owns master data and reviews the sync log weekly; replace the spreadsheet CRM with a real one and connect it to Procore when a job is won.)

In Practice

The GC that decided system of record and matched cost codes first had a connector that just worked. The GC that turned it on first spent three weeks cleaning up and a year rebuilding trust.

Common Mistakes to Avoid

• Turning on a connector before cost codes, job numbers, and vendors match
• Two-way sync on records both sides can edit
• No named integration owner and no one reading the sync log
• Integrating everything at once instead of one verified flow at a time
• Real-time sync where nightly would do, creating conflicts for no benefit
• Signing software contracts with no data export rights

Takeaway: Integration is a decision about which system is the system of record for each kind of data, and a discipline about keeping cost codes, job numbers, and vendors identical across systems; the connector is the easy part.

Educational content, for learning only. This is a vendor-neutral, high-level overview, not product training, support, or a recommendation. Super Structures General Contractors and Super Structures Learning are not affiliated with, endorsed by, sponsored by, or compensated by any company or product named here, and we receive no money from them. Product names are trademarks of their owners. Features, editions, integrations, and pricing change; verify current details on the vendor's own website before you buy.