What breaks when you sync Vista and Procore

Note: this piece will be rewritten from real deployments once there are real deployments. Until then it describes how we intend the integration layer to behave, so you can judge the approach before there is a track record to judge.

Every integration demo shows the happy path: two systems, one record, a green check. Production is a vendor entered four different ways across six years, and a controller who is right not to trust a sync until she sees what it does when the two sides disagree. Here is what we expect to break, in roughly the order a firm would meet it.

1. Cost-code drift

Somebody adds a cost code in Procore mid-job because the crew needed somewhere to put hours on Thursday. It does not exist in the ERP. By the time accounting notices, weeks of labor have landed in a code the ERP has never heard of.

The wrong fix is to let the sync create the code in the ERP automatically — that turns the chart of accounts into whatever the field typed at 4pm. The intended behavior is to hold those hours in a staging bucket, flag them to the controller with the crew and the amount, and let a person decide whether the code is legitimate.

2. Duplicate vendors

The same supplier exists as three records because someone typed the name with a comma, then without, then with “Inc.” on the end. Neither system has a shared key, so a naive match on name creates a fourth.

The intended approach is a crosswalk table built during onboarding — tax ID first, then fuzzy name match proposed for human confirmation. It is unglamorous work, and it is most of why an onboarding period exists at all.

3. Retainage mismatch

One system holds retainage at the contract level; the other may hold it per line. Both are defensible. Sync the invoice amount without reconciling how retainage was computed and you get a number that is off by a few percent — worse than an obviously wrong number, because nobody catches it until closeout.

The intended behavior is to calculate retainage on both sides independently and compare. If they differ by more than a cent, the record does not post — it goes to a conflict log with both figures and the rule each side applied.

4. Change-order timing

A change order is approved in the field platform on the 29th and entered in the ERP on the 3rd. Whichever system you ask, the month is wrong. This is a period problem, not a data problem, and it is a common reason a PM says the numbers are lying.

The intended behavior is to track the approval date separately from the posting date. The cost-to-complete projection uses the approval date; accounting still closes on the posting date. Both are right for their own purpose.

5. Period dates and payroll weeks

Payroll runs Monday to Sunday. Accounting closes on the calendar month. The last week of most months is split across two periods, and a sync that does not know that will drop labor into the wrong month a meaningful share of the time.

Every engagement should start by writing down the payroll calendar. It takes ten minutes and it prevents an argument in month two.

6. Silent failure

The worst one. A sync stops running — a credential expires, an API deprecates — and nothing tells anyone. Numbers stop updating but the screen still shows numbers, so everybody keeps trusting them. Two weeks later a PM makes a call on data from before the outage.

The intended answer is a freshness stamp on every screen and a dead-man alert: if a sync has not completed in its expected window, the layer says so loudly, on the page, before it says anything else. A view that admits it is stale is worth more than one that quietly is.

What this adds up to

None of these are exotic. They are the ordinary friction of two systems built by different people for different jobs. Integrations fail not because of the API but because nobody planned for disagreement. Plan for disagreement and the rest is plumbing.