In the SOKA notification for scaffolding work, the most common weak point is not the construction site itself, but the handoff between site, office, and payroll provider. The foreman reports the weather-related stoppage, the office reviews and supplements the information, and only then can downtime hours be processed properly. If these roles are not clearly separated, follow-up questions, retrospective documentation, and in the worst case incomplete records are the result.

In 2026 especially, current signals point to a practical problem becoming more common: notifications are being returned because weather data and labor hours are not cleanly assigned to a specific downtime event. At the same time, foremen say they do not have time for lengthy rework, while payroll needs reliable records instead of loose screenshots. This is exactly where a simple role-based logic helps: who provides which data, and at what stage?

* * *

The basic rule: capture on site, complete in the office, hand over consistently to payroll

For a clean summer downtime compensation documentation chain, three levels should be distinguished. First: data that can only be captured reliably on the construction site. Second: data that the office adds based on internal master data and review. Third: data that must be available in a format payroll or downstream processing can use without media breaks.

The foreman documents the event. The office turns it into an auditable case. Payroll needs a consistent handoff, not a reconstruction.

Practical role logic for 2026

Role matrix: who provides what for the SOKA notification for downtime compensation?

The order matters. The foreman should not have to reconstruct detailed hour models afterward when the real task is simply to report the weather-related stoppage properly. Conversely, the office must not invent the actual on-site facts. It can review, structure, and supplement the report, but it cannot replace the event itself.

This data must come from the foreman or site management

The construction site provides the raw event data. These details are especially critical because they can rarely be added later in a reliable way. Anyone reporting on site should therefore capture a few key fields immediately.

• Which construction site is affected
• When the weather-related stoppage began and when it ended
• What weather reason applied, for example rain, storm, or a comparable weather impact
• Whether work stopped completely or only partially
• A traceable location reference, for example via a location-based or weather-related snapshot
• Optional supporting photos if they meaningfully document the conditions on site

This logic also fits the existing content on weather documentation for foremen and auditable weather logs. The closer the capture is to the actual event, the lower the risk of later follow-up questions.

This data is added and checked by the office

The office does not take over the role of the reporting foreman, but it does turn the report into a processable case. This is where the site report, employee data, and internal review come together. At this point, it is often decided whether the case later qualifies as a clean SAG file or needs to be reopened.

• Check whether the construction site, date, and weather report are complete
• Assign the correct employees to the reported event
• Record or verify downtime hours for each employee
• Check consistency between the report, hours, and internal site organization
• Prepare the documents as a PDF record file and CSV for payroll

Employee assignment is especially sensitive. Current research signals clearly show that incomplete or inaccurate assignments to specific weather events are a frequent reason cases are returned. That is why the office should not just collect hours, but always verify that every hour is assigned to a specific downtime case and a specific construction site.

What must reach payroll in a consistent form

Payroll does not need a loose collection of chat messages, individual images, and separate spreadsheets. It needs a handoff that can be processed clearly, uniformly, and without renewed interpretation. Three points are especially important here.

1. A clearly identifiable downtime case with construction site, date, and time period
2. A clean employee and hour assignment to exactly that case
3. A document structure in which evidence and payroll-relevant data match

The details of this handoff are already covered in posts such as handoff to payroll without gaps and CSV export for payroll. For this article, the key point is: payroll should not have to reconstruct missing construction site or weather data. If that happens, the role allocation upstream was not clean.

Practical example: how a clean report works without responsibility chaos

Take a scaffolding site where work cannot continue during the morning because of weather conditions. The foreman reports the construction site, the period of the stoppage, the weather reason, and adds a location-based weather snapshot while still on site. Optionally, one or two photos are added as well.

In the office, this report is reviewed. After that, the affected employees and downtime hours are assigned to the reported period. Only once this assignment is complete are the documents assembled as a PDF record file and CSV. This means payroll does not receive a vague weather note, but a structured case.

Not every role has to do everything. What matters is that each role delivers its part on time and in full.

Why simple processes work better than retrospective documentation

What if several foremen report from the same construction site?

Here too, a clear logic helps. Not every person should create a separate, disconnected case if the same weather event affects the same construction site. A clean event-based assignment is the sensible approach, and the office can then build the employee and hour logic on top of it. This avoids duplicates, conflicting times, and later questions during review.

Technically, this does not have to be complicated. For many companies, a simple site process with standardized capture is enough. That is also the idea behind lean summer downtime compensation software: on-site reporting without a complex ERP, followed by office review and structured output for PDF and CSV.

2026 checklist: who needs to check off what?

• Foreman or site management: capture the construction site, date, time period, weather reason, and evidence directly at the event
• Office: check the report for completeness and clarify missing points immediately
• Office: assign employees and downtime hours to the specific case
• Office: combine the documents into one consistent file
• Payroll: process the case only, not reconstruct the facts

If these five points are followed, the risk of follow-up questions drops noticeably. At the same time, the basis for auditable summer downtime compensation records becomes much more stable. The SOKA notification for downtime compensation is then no longer treated as a one-off action, but as a clear process with defined responsibilities.

Conclusion: the best SOKA notification is the one with clear role allocation

For scaffolding companies in 2026, the key question is less whether weather-related stoppages are documented and more whether everyone in the process knows exactly what they must provide. The foreman provides the real event. The office provides the auditable structure. Payroll receives a consistent handoff. Companies that implement this split cleanly reduce follow-up questions, save rework, and create a reliable basis for summer downtime compensation in scaffolding.