It's All About the Appraisal

Your appraisal is the original. Everything else is a copy.

Start with a small test

Think about a scheme mid-build and try run the outturn against the appraisal your board originally approved: committed costs, approved variations, actual grant drawn, an auditable variance at the end. Notice how long it takes, and where the work actually takes place.

This briefing is about what that exercise reveals. 

Gateway 3

Month fourteen on a 142-unit scheme. Tenders came in 6% above the cost plan, two variations have been approved, grant was confirmed at a different rate to the bid, and shared ownership sales are running two months behind assumption.

Your board wants the outturn position against the appraisal it approved at Gateway 1.

Where does that recalculation happen?

If the answer involves exporting actuals, re-keying them into the appraisal and reconciling in a spreadsheet, that is two systems and a manual bridge, and the bridge is carrying your governance.

Bridges like that fail quietly. A stale peak-debt figure survives the reconciliation, the board signs off an outturn that no longer describes the scheme, and the covenant headroom nobody recalculated surfaces at year end, in front of your stakeholders.

The appraisal creates the data

Every figure in a development programme traces back to one model: unit mix and tenure, grant, rents and sales values, build cost and contingency, Section 106 and abnormals, phasing, interest and inflation, through to NPV, IRR and payback. Your milestone dates, peak funding requirement, board KPIs and funder returns are all calculated output from that model.

A delivery system receiving those figures holds a snapshot taken on a particular day. When an assumption moves, the snapshot is wrong, nothing downstream knows it, and the dashboard still shows green. Better dashboards don't fix that, because the problem is where the calculation lives.

And assumptions won't sit still. We watch them move through the appraisals our customers run: build costs and new levies, borrowing costs eating into interest cover and covenant headroom, grant confirmed at different rates to the bid, rent policy revised, the Building Safety Levy arriving mid-programme, the GLA relaxing affordable housing requirements as an emergency measure, all of it inside the length of a single build programme. Every one of those changes lands on an appraisal assumption, and every copy goes stale the moment it does.

An outturn is a round trip

The appraisal produces a scheme, the delivery platform imports it and tracks it against milestones. An outturn has to run backwards first.

Committed costs, tender returns, approved variations, actual grant drawn, sales completions and revised programme dates all travel back into the appraisal engine, which recalculates against the original assumptions. Only then does the new position, with its variance, come forward as an approved figure.

That is a two-way sync of financially material data, at the precise moment your governance depends on the answer being right. Three things go wrong with it.

1. Field mapping degrades. Every change to grant rules, rent policy, the Building Safety Levy or funder requirements moves what a field means, or adds one that doesn't exist on the other side.

2. Nobody funds the remap. Read the contracts. The appraisal vendor maintains its engine. The delivery vendor maintains its platform. The mapping between them sits in neither scope, so it degrades quietly until someone notices the numbers have stopped agreeing.

3. The fallback is always Excel. When the sync can't handle a scenario, the outturn gets done in a spreadsheet by whoever understands the model best, which is what the platform was bought to stop.

Most teams run an outturn at every gateway and some run them quarterly. Re-keying and reconciling one takes 2-3 days of a development accountant's time, and that cost repeats at every gateway on every live scheme. If the architecture only works in one direction, it fails at the most important recurring task in the cycle.

Which number did the board approve?

Ask your internal auditor what they need and they will describe a chain of custody rather than a dashboard.

If the appraisal is calculated in one system and the approval report is produced in another, then evidencing any decision means showing that the figure in the board pack matched the appraisal version that existed on the approval date: two systems, two version histories, and a mapping running through the gap between them.

This becomes real in a audit, where Homes England, GLA and Welsh Government requirements ask for the approved appraisal and its supporting trail. A PDF of appraisal outputs is not the appraisal. Numbers without the calculation behind them can't be re-run, interrogated or defended when someone asks how cost per unit moved between Gateway 2 and Gateway 4.

Three consequences that surface

Who holds the master?

If your delivery platform holds imported appraisal figures rather than calculating them, then on exit you get outputs, not models. You can't re-run them, sensitivity test them, or explain them to a new finance director.

Who fixes a wrong cashflow?

With one supplier you raise one ticket. With two you get a diagnosis argument. The appraisal vendor says the export was correct, the delivery vendor says the import matched the specification, both are usually telling the truth, and the scheme is still wrong while they work it out.

Who owns the security boundary?

Encryption is cheap, standard and not where the risk sits. Every integration adds a data processor, a DPA, a sub-processor chain, a ROPA entry, and machine credentials to issue, rotate and monitor. Compromised service accounts between trusted systems are a live breach path across the sector, and fewer boundaries mean fewer controls to own, evidence and fund at every renewal.

Appraisal-first architecture

SDS has built development software for this sector since 1994, and more than 300 housing associations, local authorities, private developers and consultants use our products. The design principle has never changed: the appraisal is the origin, and everything downstream reads from it.

• SDS ProVal calculates scheme viability: mixed tenure, any size, NPV, IRR, payback, sensitivity analysis, auditable outputs.

• SDS Landval appraises residual land value and risk before you commit to an offer.

• SDS Sequel manages programme and cashflow, running on the appraisal model rather than a copy of its outputs.

So when you produce an outturn at any gateway, actuals recalculate through the same engine that produced the originally approved position, and the variance is auditable end to end because there is one calculation and one trail. You get one supplier, one model, and one support desk when something is wrong.

It's also why ProVal and Sequel are moving onto one shared data layer. The appraisal is entered once, viability and delivery work on the same records, and there is nothing to export, no sync to maintain and no mapping for anyone to fund. Anything added later joins that layer rather than arriving as one more integration to own.