Reconcile the contract, the budget and the actuals — to the krona.
Construction questions answered across disconnected systems — with the numbers, the method it used, and the honest caveats. Figures are illustrative (synthetic data).
One question. The AI reads three systems and finds 569 200 kr you can claim back.
A controller asks a plain-language question. The gateway autonomously pulls the time log, opens the signed contract, and reads a year of invoices — then reconciles all three and shows its work.
No dashboard, no analyst, no SQL. From that one sentence, the AI decided which systems to open — and did this on its own:
The hours actually worked
Read every time entry logged against this subsupplier for the last 12 months.
Time-management systemThe signed contract
Opened the framework agreement and found the agreed rate — 685 kr/h, § 4.2.
Contract on SharePointEvery invoice they sent
Parsed all 12 invoices for billed rate, hours and amounts — line by line.
Invoice archiveOvercharged on both
Billed rate and billed hours both exceed what was agreed and worked.
Cross-referenced569 200kr recoverable
You were billed 3 199 600 kr. The contract & time log support 2 630 400 kr.
That is 17.8% of everything they billed this year — split cleanly into a rate error and an hours error, each independently evidenced below.
Dimension 1 · The rate they billed vs the rate you signed
Average billed rate is 75 kr/h above the contracted ceiling.
Dimension 2 · Hours invoiced vs hours actually reported
Every single month, the invoice claims more hours than the time system holds — the lime band is the gap. 370 phantom h over the year.
The money, reconciled · total invoiced → what's correct → what's recoverable
Start from everything they billed, subtract the rate error and the hours error, and you reach the amount the evidence actually supports.
The evidence, line by line
Every row links back to the exact source the AI read — nothing is asserted without a citation.| What the AI compared | Agreed / reported | Invoiced | Difference | Source cited |
|---|---|---|---|---|
| Hourly rate | 685 kr/h | 760 kr/h | +75 kr/h | Contract § 4.2 |
| Hours billed (year) | 3 840 h | 4 210 h | +370 h | Time system · 12 mo |
| Inv. 2025-0412 (Mar) | 375 h · 685 | 410 h · 760 | +54 725 kr | Invoice PDF |
| Inv. 2025-0631 (Jun) | 330 h · 685 | 360 h · 760 | +47 550 kr | Invoice PDF |
| Inv. 2025-1127 (Nov) | 350 h · 685 | 385 h · 760 | +52 850 kr | Invoice PDF |
| + 9 further invoices | 2 785 h | 3 055 h | +414 075 kr | Invoice archive |
| Total recoverable (rate + hours) | 569 200 kr | |||
Recommended action — ready to send
Generate a dispute / credit-note request pack: the reconciliation, the 12 cited invoices, and the contract clause, addressed to Nordbygg Montage AB.
Honest by design: the AI surfaces and quantifies the discrepancy with sources attached — it does not accuse. A person reviews the pack before anything is sent. Approved time-corrections and contract addenda are reconciled in, not assumed away.
One question paid for itself. What would you ask first?
Illustrative example Sample data, kept internally consistent (totals reconcile to the kr). No real client figures are shown.
Are we going to come in over budget on the Göteborg renovation — and if so, on what?
A live forecast-at-completion, six weeks before close — then the same question, one chair up: is this one job, or the same estimating mistake on every renovation we tender?
Will the Göteborg office renovation land on budget?
14.2 MSEK budget, 67% elapsed. The AI matches the structured kalkyl to live actuals, projects every cost line forward at its current burn, and attributes the variance to named drivers — before the job closes.
-
1
Match budget to actuals
Joins each structured kalkyl (budget) line to live actuals by cost type, through the semantic layer.
Kalkyl × actuals -
2
Check coverage
Flags unmapped lines and reports how much of the picture is actually available — no silent gaps.
Mapping confidence -
3
Project forward
Extends each line to completion at its current burn rate — a forecast, not a booked figure.
Run-rate model -
4
Attribute the variance
Keeps tidtyp (normal/OB/övertid) and yrkeskategori as separate dimensions.
Driver split -
5
Cite every row
Each number traces to its source booking — permission-aware and logged, in your tenant.
Source citation
Coverage, stated up front: OB-mix is available for 8 of 11 active projects; 3 lack tidtyp granularity and are forecast on labour totals only. Where the data isn't there, the AI says so — it doesn't guess.
Projected +345 000 kr over budget at completion — surfaced 6 weeks before close. Yet total labour hours run only ~4% over. This isn't a volume problem; it's a mix problem — the wrong hours at the wrong rate, and scaffolding standing too long.
Forecast at completion, by cost type
· where the +345k comes fromWalk from on-budget (0) to the projected overrun. Two drivers push it over; a favourable material & machine burn pulls it back. Figures are projections at current burn.
The drivers, named
· associated with, at current burnLanguage stays "contributing driver" / "projected at current burn" — never "caused by", never a booked loss.
| Contributing driver | Contribution |
|---|---|
| Ställning running ~15 days beyond planned dismantlescaffolding hire, calendar-driven | +210 000 |
| Snickare labour: OB / övertid tidtyp share 11% → 18%same hours, wrong rate mix | +275 000 |
| Material + maskiner, favourable at current burnrunning under estimate | −140 000 |
| Projected total FAC | +345 000 |
Chase the scaffolding contractor on the dismantle date
The +210k is calendar-driven — every extra day of standing scaffold is recoverable by closing it out on schedule.
Re-sequence the snickare shifts off OB / övertid
The hours aren't the problem — the rate mix is. Moving work back to normal tidtyp closes most of the +275k.
One job is over. Three show the exact same pattern.
11 active projects × cost type — forecast risk
Hot = projected over budget at current burn. Three projects light up on the same two cost types as Göteborg: ställning duration and OB-mix.
Any single project dashboard can show one job is over. Only a portfolio view over a shared semantic layer can tell you it's the same mistake on every renovation.
Because "transport cost" has to mean the same thing across all 23 jobs before you can compare them. No per-project dashboard can do this.
One job → a patternIs our renovation kalkyl systematically wrong?
Now put on the commercial-director hat. The AI pulls 23 completed renovations against 18 new-builds as a control, normalizes every cost ratio to a common denominator, and asks whether the estimate — not the luck — is biased.
-
1
Pull the control group
23 completed renovations vs 18 new-builds — same semantic layer, comparable structure.
Closed projects -
2
Normalize the ratios
To common denominators: kr/m² (area, from the quantity take-off) and kr/leverans (deliveries, from goods receipts).
Semantic layer -
3
Show the exclusions
Drops non-comparable jobs and PDF-only kalkyler — flagged, never silently guessed.
Exclusion list -
4
Reno vs new-build
Separates estimating bias from bad luck — the control should sit on budget if the estimate is sound.
Compare -
5
Quantify, conservatively
One scoped figure — under-estimation per 100 MSEK of renovation revenue.
Scoped value
Budgeted vs actual cost ratio — every closed job
· on the diagonal = on budgetEach dot is one project's cost ratio: budgeted (x) against actual (y). On the diagonal means the estimate held. Renovations sit above the line — actual beats budget again and again. New-builds sit on it. That gap is bias, not luck.
Estimating bias by cost type — renovations, normalized
· denominators namedEstimated vs actual ratio across the 23 renovations. The new-build transport control shows no bias — proof it's the renovation estimate that's off, not the world.
| Cost type | Estimated | Actual | Δ | Projects |
|---|---|---|---|---|
| Transport per delivery (kr/leverans) | 4 820 kr | 5 700 kr | +18.3% | 19 / 23 |
| Ställning per m² (kr/m², from take-off) | 187 kr | 209 kr | +11.7% | 17 / 23 |
| OB-share of labour % of labour hours | 14.2% | 15.8% | mild | — |
| Material per m² | — | — | noise | — |
| New-build transport control · per delivery | — | — | +3.1% · no bias | 18 |
Renovation vs new-build — and the one-time fix
· the payoffThe same cost types, side by side. Renovations over-run their estimate; new-builds don't. Correcting the kalkyl template once pays back on every future renovation tender.
Fix the kalkyl template — once
Re-base the renovation denominators to the actuals the portfolio already proves. One change, every future tender.
of renovation work under-estimated per 100 MSEK of renovation revenue — a conservative, scoped figure, recoverable on every future tender by fixing the template, not the job.
What was excluded — and why
Cross-project comparison is valid only where cost-type structure and denominators are consistent. Structured enough for most projects, not all.
The same mistake on every renovation — because "transport cost" finally means the same thing across all 23 jobs. That's only possible over a shared semantic layer. No per-project dashboard can tell you this.
Honest by design: figures are synthetic but internally consistent — the Göteborg overruns are drawn from the same distribution Act 2 surfaces as systematic, so the live finding and the portfolio finding reconcile. Forecasts are projections at current burn, not realized losses; drivers are "associated with," not causal. Sources — the structured kalkyl (budget), the actuals ledger and the project register — are all pulled into AccuraSee and read in your tenant, permission-aware and logged per user. The AI quantifies and proposes; a person reviews and decides.
From "is this job over?" to "fix it on every future tender."
Have a question in construction your systems can't answer today?
Bring us a real one. We'll scope a low-risk pre-study and show you exactly what's answerable on your data.
Ask your business data anything. Get an answer in seconds.
Start with a discovery call — we'll scope a low-risk pre-study and show you what's answerable on your data.
What to expect: a 30-minute call · we map your data sources · a live answer on your data — no pressure.