Educational overview only. Prudent Guardian (www.inspirecodingedu.com) is not an insurance company, broker, law firm, or registered investment adviser, and does not provide personalized insurance, investment, tax, medical, or legal advice. Verify details with licensed professionals and official issuers.
The log has a total. The pay application has a change column. You spread both documents side by side on your desk, coffee ring still fading on the corner of the printed pay app you pulled off the printer ten minutes ago. You cross-reference the line item for concrete formwork first, since that’s the line that shifted 12% from last month’s submission. The change column entries don’t immediately line up with the running total you’ve tracked in your log since the start of the phase.
What the paper says
The pay app’s change column documents every deviation from the original schedule of values tied to this pay period, from material price escalations to scope adjustments requested by the project management team. Entries may also reflect credits for work pushed to a later phase, or partial payments for work that is partially complete but falls outside the original scope outlined in your contract. Your log total tracks the cumulative value of all approved work, signed change orders, and verified adjustments submitted across every pay app for this project to date, so you always have a clear record of what you have billed for so far. Illustrative example: $14,827 listed in the change column for this period is tied to the steel price escalation you documented in approved change request 7-2, which you added to your log total as soon as the change request received sign-off last week. Each entry in the change column includes a short code that links to a supporting change request, so you can quickly verify that the adjustment aligns with work you have already completed or materials you have already purchased for the site.
What you leave alone
You leave all change column entries that have already been cross-referenced to signed change requests and matched to your log in prior pay periods untouched, no edits needed to confirm their validity. You do not alter line items for standard, pre-approved scope that is marked 100% complete in both documents, as these entries are already aligned and do not require additional review. You leave handwritten notes from the project coordinator that flag which change orders are pending final approval intact, as these notes offer critical context for anyone else who reviews the documents later in the process. You also leave your log total unchanged unless you find a verified discrepancy backed by signed, written documentation, as adjusting the total to surface-match the pay app without proof creates gaps that are hard to resolve later. You only add notes to the margins of the pay app page, never crossing out or modifying original entries, so you keep a full record of the submission as it was originally drafted.
The ten-minute check
You run this quick, structured check to confirm alignment between the change column and your log total before you submit the pay app for review, to avoid unnecessary back and forth with the review team. The steps follow a consistent order every time, so you don’t miss any key details even if you are crunched for time before the submission deadline:
- Pull every change column entry for the current pay period and match each to a corresponding change request, signed site directive, or dated email chain that documents the reason for the adjustment, flagging any entry without supporting documentation to follow up on before submission.
- Add the sum of all valid current change column entries to the log total from the end of the last pay period, to calculate the expected cumulative total for this submission.
- Cross-reference that expected cumulative total to the total listed on the first page of the pay app, to confirm the line items add up correctly across every section of the document.
- Mark any gaps between the adjusted log total and the pay app total with a small, color-coded sticky note, so you can circle back to resolve mismatches before you send the pay app to the review team.
You move through each step methodically even if the numbers look like they align at a glance, as small arithmetic errors in individual line items can add up to significant mismatches over the course of the project.
Where the page goes
Once you complete the check and resolve any mismatches, you clip the annotated pay app page to your printed log, so every adjustment is tied directly to the running total you have tracked for the project from day one. You scan a digital copy of the annotated pay app and log page to the shared project folder, labeled with the pay period number and the date you completed the cross-reference, so everyone on the project team can access the records if they have questions. If the change order is fully approved, you add the relevant entry to Draw Jacket to keep all project payment documentation aligned in one accessible spot. You also file a physical copy in the project file drawer, right behind the prior month’s pay app and supporting change order documents, so you can pull the full history quickly if anyone asks questions about the adjustment later on. You save all supporting documentation for change column entries in a subfolder linked to the pay period, so you don’t have to dig through unrelated files to find proof of an adjustment later.
What you do not assume
You do not assume that a number in the change column is valid just because it is typed into the pay app, as administrative errors sometimes lead to entries being added without corresponding signed change requests. You do not assume your log total is fully accurate if you haven’t updated it with approved change orders from the last two weeks, so you double-check that you added every signed request before you start cross-referencing the two documents. You do not assume a pending change order counts toward the log total until you have written sign-off from both the project owner’s representative and your internal foreman, even if you have already completed the work tied to the request. You do not assume the pay app total matches the log total just because the high-level numbers look similar, as small adjustments to individual line items can cancel each other out on the surface but lead to mismatches in future pay periods. You also do not assume the review team will catch errors in the change column, as they process dozens of pay apps a week and rely on your documentation to confirm entries are valid.
The next time you open it
You open this same annotated pay app page when you receive the preliminary approval notification for this pay period, to cross-reference any adjustments the reviewer made to the change column entries against your annotated copy. You pull the corresponding pages from your log to check if any of the reviewer’s adjustments require you to update your running total for the next pay period, so your log stays aligned with approved amounts. You match any approved change entries to the work you schedule for the next phase, to make sure you don’t double-count adjustments in future submissions to the review team. If the reviewer flagged any change column entries for additional information, you pull the supporting documentation you saved when you first completed the ten-minute check, so you can respond to the request quickly without digging through old files. You also jot a quick note on the top of the page if you need to adjust how you track change order entries in your log for the next pay period, to make the cross-reference process even faster when you work on the next month’s pay app. You file the page back in the project drawer once you resolve all reviewer questions, so it is easy to access if you need to reference it for final project reconciliation at the end of the job.
