Capturing extra work in Procore without Project Financials

What still works#

The daily log tools take a record of extra work with no budget code and nothing financial in the payload at all. Posted and confirmed:

Readable alongside them: daily_construction_report_logs and work_logs. The vendor id has to come from the project vendor list at /rest/v1.0/projects/{id}/vendors, not the company one.

What Fieldstub does with it#

Approving a ticket on a project with no Change Events tool writes a manpower log carrying the description, why the work was out of scope, who directed it, the crew size and hours, an itemised summary of equipment and materials, who signed and when, and a link back to the full record.

The destination is never chosen for you. Over the API and over MCP, approving such a ticket returns 409 no_change_events until you pass destination: "daily_log" explicitly. In the review queue the button reads Approve and file to the daily log, and the screen says what that means before you press it.

Two Procore behaviors we had to design around, both verified:

• There is no idempotency key on a daily log. Posting the same log twice creates two rows; Procore does not dedupe. Fieldstub writes a marker into the notes and looks for it before writing, so a retry is not a duplicate.
• Attachments are silently discarded. A multipart create or PATCH returns 200 with attachments: [] and the file is gone. So the photos and the signature image stay in Fieldstub, and the note says where they are rather than implying they came along.

What it is worth, honestly#

A manpower log is a diary entry, not money. Nothing bills from it. It does not roll into a change order, it does not touch a budget line, and no one reconciling a job at closeout is going to find it on their own.

So this is not Procore without Financials working the same way. It is:

• A real destination for a ticket on a project that cannot take a Change Event, where previously the honest answer was that there was none.
• The evidence half of the claim. Signed, timestamped, photographed, filed in the owner's own system on the day it happened. That is the artifact that is missing when a paper ticket does not survive the week.
• A degraded mode, and anyone telling you otherwise is selling.

If the money side matters, and it usually does, the answer is Project Financials or a different system of record. There is no clever way around a module you did not buy.

Timecards: unproven, and not for the reason you would guess#

Field Productivity timecards look like the better fit for labour on a T&M ticket, because they carry an employee and hours and can be costed. We could not confirm them.

POST /rest/v1.0/projects/{id}/timecard_entries returned 422:

{"errors":"You have assigned an invalid person for your permission level"}

A party_id variant returned login_information_id: 9335 not found and ancestry does not match.

Neither error mentions a cost code, and that distinction is the whole finding. An error naming a budget field would have meant timecards are gated by Project Financials too. These name the person, which is a service account permission gap and an empty sandbox, and says nothing either way about the money question.

Settling it needs Field Productivity tool permissions on the service account and at least one crew or worker on the project. Both /crews and /timecard_entries returned empty on ours.

The thing we cannot tell you#

We do not know what share of Procore customers have Project Financials. Nobody has published it and we are not going to guess at it here.

It is worth knowing that this constraint is not unique to us. Every one of Procore's own ERP connector listings names Project Financials as a requirement, and so does the marketplace listing for Clearstory, the established product in this category. Whatever the number is, it is the number the whole category works inside.

One consequence worth stating plainly: a general contractor not running Project Financials is probably not managing change events in Procore at all. The extra work is already living in a spreadsheet or an email thread. That may mean the module is qualifying the buyer rather than shrinking the market, but that is a hypothesis and we will say so until somebody answers it properly.

How to check what you have#

Open a project and look for Change Events in the tool list. If it is not there, Project Financials is not on that project.

By API, try reading change events for the project:

GET /rest/v1.0/change_events?project_id={project_id}

A 403 or a 404 where other tools answer normally is the tool being absent rather than a permission problem with your token. Worth confirming against a project you know is configured before concluding anything.