Construction procurement log template: need-by dates and supplier commitments

A procurement log is more than an order list

A purchase-order list can tell the project team what it bought. A procurement log needs to show whether the item will be available for the work that depends on it. That requires dates, dependencies and source-backed commitments as well as a vendor name. A row marked “ordered” can still conceal an unapproved submittal, an incomplete release or an unconfirmed balance.

Procore's procurement-log guidance distinguishes a procurement log from a simple purchase log and identifies a range of planning and delivery fields. The operational approach here adds explicit status boundaries: required, planned, committed, received and accepted. These labels are a suggested way to organize decisions, not a universal contractual vocabulary or a replacement for your project's required system.

Begin with the actual question the field needs answered. “Will the complete valve package be available for installation on November 20?” is more useful than “Has purchasing emailed the vendor?” The first question identifies an item, quantity, need and decision. Design the row so another team member can see which part of that answer remains unverified.

Sources: Procore: construction procurement log guidance and template

Choose a package size that exposes the blocker

Use an identifiable item or package with a defined quantity, unit and installation destination. A mechanical package can be one row if all its components have the same readiness and delivery state. Split it when different components have different release conditions or dates. Otherwise one confirmed shipment can make an incomplete package appear ready.

Keep the purchase-order and line references, supplier contact, responsible buyer and field receiver with the record. Add the associated submittal, approved revision and installation area where relevant. Avoid relying only on a free-text item name; similar components can serve different areas or follow different drawings. A coordinator should not have to guess which pump or panel a supplier means.

For an illustrative 12-valve order, eight valves may have a confirmed shipment while four do not. Either maintain line-level balances or create linked rows that make the split visible. Do not mark all 12 delivered when the first pallet arrives. The appropriate record boundary is the one that preserves the decisions the team still needs to make.

Keep required, forecast and committed dates separate

The required-on-site date comes from the work plan and its responsible scheduler or project team. The forecast is the team's current expectation. A supplier commitment is a specific external response with a source and date. Those values can agree, but one should not silently overwrite another. The gap between them is often the information a manager needs.

Also identify what the lead time starts from. It might follow an approved submittal, a complete commercial release, a deposit or another agreed prerequisite. “Four weeks” is incomplete until the starting event and calendar basis are known. Shipping time, site delivery arrangements and unloading readiness may add separate dependencies.

When a forecast moves, preserve the prior basis and show the next action. Updating the site need date to the latest delivery estimate can hide an installation problem. The responsible project team should decide whether to change sequencing, investigate an alternative or take another action. The procurement log should support that decision, not make it disappear through a revised spreadsheet cell.

Work backward using an explicit calendar

Suppose an illustrative air-handling unit is needed on site November 30. The team uses a simplified assumption of 28 calendar days from complete release to arrival. Under that assumption, November 2 is the calculated release target. This is a planning calculation, not evidence that the supplier accepted the order or committed to November 30.

Now suppose the actual complete release is not verified until November 6. The same simplified 28-day assumption points to December 4. The log should show the four-day difference and the unresolved effect on the work plan. It should not state that December 4 is confirmed delivery unless the supplier has explicitly confirmed that date and its conditions.

Use the real project's calendars, lead-time definition and dependencies in live planning. Working days, holidays, fabrication milestones, transit and delivery windows can change the calculation. Preserve the calculation inputs with the row so someone can reproduce the forecast. If the supplier gives a different basis, record it and have the responsible team review the effect rather than choosing whichever date looks better.

A completed log that makes uncertainty visible

The following three rows describe an invented job. Their purpose is to show why the status column should explain the next decision. None of the dates, quantities or commitments is an industry benchmark or a supplier promise. A live register should link to the actual order, source response and responsible people.

Notice the differences between the rows. AHU-2 has a release question before the team can rely on the lead-time forecast. Panel P-4 has a dated commitment, so the next action is to confirm the site's receiving arrangements. The valve package is partially committed, so the missing four valves remain an explicit constraint even though the first eight have a date.

A simple red-yellow-green summary can help direct attention, but keep the underlying explanation accessible. A green row without a quantity or source is difficult to audit. A red row with a named owner and an agreed next decision time is actionable. Define what each status means for this project before using it in management reporting.

Do not treat an approved submittal as a released order

A technical review and a commercial release serve different purposes. An approved submittal can establish the reviewed product or configuration under the project's process, while the order still needs a responsible release action. The supplier may also need a complete selection, manufacturing information or another agreed prerequisite. Record the actual steps rather than assuming that approval triggers every downstream event.

Connect the approved revision to the order and its release record. If a drawing or selection changes after fabrication begins, identify the affected line and route the issue to the responsible people. A procurement register can show which packages use a superseded reference; it should not independently decide the engineering or commercial treatment of the change.

Ask who confirms that the release is complete. An email saying “please proceed” may need to be associated with the correct order, quantities and revision. Preserve the supplier's acknowledgment where it is part of your process. The goal is a clear event that supports the next date calculation, not a general impression that somebody in the office probably sent the paperwork.

Ask the supplier for a usable commitment

Replace “Any update?” with a request tied to the order, line, quantity and required date. Ask for the supplier's current commitment and any unresolved dependency. If a date cannot yet be confirmed, ask who owns the dependency and when a meaningful response can be provided. An honest unresolved status is better than an invented delivery date.

For the illustrative valves, a useful message is: “For PO-204, line 3, please confirm the quantity and site delivery date for the remaining four valves. Our current required-on-site date is November 20. If you cannot commit yet, identify the blocking dependency and when you expect to provide a dated commitment.” Adapt the wording to the actual relationship and project requirements.

Save the response with the row, including what the date means. A ship date and a site arrival date are different. An expected week and a booked delivery appointment are different. If the reply is ambiguous, ask the next focused question rather than translating it into the most optimistic state. Keep the timestamp so the team can distinguish an old promise from a current response.

Keep partial receipts connected to the order balance

When material arrives, record the purchase-order line, quantity and unit, receiving location, receiver, date and observed exceptions. Identify damaged, short or unverified quantities rather than treating the delivery ticket total as automatically accepted. Preserve photographs and the delivery record according to the company's process, with the context needed to understand them later.

If eight of twelve valves are accepted, four remain open. The next delivery may complete the order, arrive with a substitution or introduce another discrepancy. Keep each receipt traceable and reconcile the cumulative accepted quantity. A duplicate photo or a second copy of the same ticket should not become a second delivery.

Receiving also supports the office's later reconciliation. Kojo's invoice-matching description connects purchase orders, delivery receipts and invoices. That is a separate but related workflow: a clear procurement and receiving trail makes the invoice question easier to review. It does not mean the person receiving a pallet has authorized every charge, accepted a commercial substitution or approved the invoice for payment.

Sources: Kojo: purchase-order, delivery-receipt and invoice matching workflow

Review exceptions by next decision, not by reminder count

A short procurement review should focus on the items whose verified state does not support the planned work. Group them by the missing decision: approval, complete release, supplier commitment, balance quantity, delivery appointment or receiving exception. Name the owner and next check time. The number of emails sent is less useful than the number of unresolved decisions with a clear path forward.

Keep the last meaningful response alongside the next action. An automated acknowledgment does not refresh a supplier commitment. If a promised response time passes, show that missed commitment rather than merely resetting the reminder counter. Escalation should follow the company's approved relationship and project process; the log is a coordination record, not an instruction to pressure every supplier in the same way.

Avoid claiming that every late material item changes the project's completion date. The scheduler and responsible project team need to review actual dependencies, available float and possible alternatives. The register supplies timely, source-linked facts for that review. Preserve the resulting decision and the person who made it so the team does not reconstruct the same discussion the following week.

See one supplier response become an owned next action

Buildalytic's delivery follow-up and custom workflows connect calls, texts, records and human review around a defined task. For a procurement demonstration, start with an order line that has a required date but no confirmed balance delivery. Ask to see the responsible supplier contacted, the response captured and the commitment or unresolved dependency reflected in the job record.

Use an imperfect reply. A supplier might say “probably next week” or confirm only eight of twelve items. The useful behavior is to preserve the uncertainty and ask the next relevant question, rather than marking the entire order ready. Inspect who can change the required date, approve an alternative or accept a substitution. Those decisions belong to the designated people and project process.

Bring a redacted procurement log and one delayed order to a demo. Walk through the source commitment, the missing information, the receiving handoff and the next responsible owner. Agree where the authoritative order and schedule remain. The workflow should make the team better informed about the work it must coordinate without asking it to replace every system it already uses.

Sources: Buildalytic: delivery follow-up workflow