Bulk import historical hours

3 min read · Updated 3 Jun 2026

Going live mid-project? Back-fill the hours you've already worked from a spreadsheet so your dashboards start warm, not empty. One row per operative, per activity, per day.

Why back-fill

Earned value only tells a story once there's history behind it. If you adopt WBSync three months into a job, bulk import lets you load those three months in one pass — so your S-curve, S/E and SPI reflect the whole project from day one rather than starting flat.

operative · activity · date · hours P. Murphy · Pull cable · 04 Mar · 8 A. Doyle · Terminate · 04 Mar · 8 Labour ledger queued for foreman approval

Step by step

1
Open Labour → Bulk import

From inside the project you're back-filling.

2
Lay out one row per operative-activity-day

Use the same column shape as the WBS template's worked examples: who, which L4 activity, the date, and the hours. Spreading a day across two activities is just two rows.

3
Upload and review

WBSync matches activities and operatives, shows you what it parsed, and flags anything it couldn't place before you commit.

Imported rows still pass through the normal approval gate — and the same clash checks. If your back-fill overlaps a clock-in feed for the same day, you'll get a duplicate-submitter clash to resolve, exactly as you would live.

What next?

Resolving those overlaps is quick once you know the pattern: Clashes & approvals →

Frequently asked

What's the row format for the import?

One row per operative, per activity, per day: who worked, which L4 activity, the date, and the hours. Splitting a day across two activities is just two rows.

Do imported hours still need approving?

Yes — they pass through the normal foreman approval gate and the same clash checks, so back-filled data is held to the same standard as live entries.

What if my back-fill overlaps a clock-in feed?

You'll get a duplicate-submitter clash for the overlapping day, which you resolve the usual way by choosing which entry wins.

Related