Construction Handover and Asset Data Software: Why the Owner Keeps Rejecting Your O and M Package

Practical completion, and the package that came back

The building is finished. The retention is worth more than the profit on the job. Sixteen weeks ago the digital delivery lead started collecting the handover package: an asset register of about 12,000 records, test and commissioning certificates, O and M manuals, warranties, as built drawings and the federated model. Forty three subcontractors contributed. The mechanical contractor named their air handling units by their own works order numbers. The electrical contractor used the drawing reference. The BMS commissioning engineer used the panel schedule. The architect's model uses the type mark.

The owner's facilities team ran the import into their maintenance system and rejected the package. Not because the building is wrong, but because 2,100 asset tags do not reconcile with anything, 400 assets have a classification code that does not exist in their standard, and the serial numbers for a third of the plant are missing entirely because nobody asked for them until the day the O and M binder was compiled. Retention stays where it is. A quantity surveyor is now in a meeting about a payment milestone that is really a data quality problem.

Handover data is a contractual deliverable that nobody owns until it is late

The uncomfortable truth about handover is that it is generated during construction and collected at the end. Every asset installed in month four carried its serial number on a label that was photographed by somebody, or not. The commissioning certificate existed as a PDF in a commissioning engineer's laptop. By the time the digital delivery lead goes looking, the subcontractor's site team has demobilised and the person who knew is on another job in another city.

In the UK there is a further edge to this. The Building Safety Act 2022 created a golden thread duty for higher risk buildings, meaning the information about the building has to be accurate, current, accessible and handed to the accountable person in a structured form. That converts what used to be a commercial argument about retention into a regulatory obligation with a named gateway. Even outside that regime, owners with real estate portfolios now specify asset information requirements in the contract, and they mean them, because their maintenance system is what the specification is for.

Problem one: the asset register is defined by the owner, not by a standard

People say COBie as if it settles the question. It does not. COBie is a structured schema for handing over facility data, and it tells you there should be a facility, floors, spaces, types, components, systems, jobs, spares and documents. It does not tell you which of your 12,000 installed items count as maintainable assets for this owner, which classification system to use, what naming convention the tags follow, or which attributes are mandatory for a chilled beam versus a fire damper.

That answer lives in the owner's asset information requirements, and every owner writes theirs differently. One uses Uniclass, another uses a classification of their own that predates the standard. One wants space referenced to their room numbering, another to the architect's. One requires a manufacturer, model, serial, install date, warranty start and expiry on every item, another requires nineteen attributes on mechanical plant and four on everything else. A packaged handover platform gives you a configurable template, which is fine right up to the point where the owner's rules contain conditional logic that a template cannot express.

Problem two: validation is where handover actually dies

Zutec, Operance and Bentley AssetWise all exist because this problem is real, and all three are legitimate products. Zutec and Bentley are strong on structured handover for large asset owners. Operance is well pitched at the residential and golden thread end. Where a platform strains is when your validation rules have to be the owner's rules rather than the product's, and when you deliver to several owners a year who each want something different.

What a build gives you is a rules engine you control. Every asset record is validated on submission: does the tag match the owner's pattern, is the classification code in their allowed set, is the space reference resolvable against the room schedule, is the serial number present and unique, does the warranty start date fall inside the construction period, is there a commissioning certificate linked, and does the document naming match the required convention. A subcontractor uploading 300 records finds out in ninety seconds that 41 of them fail and exactly why, while they are still on site. That is the whole game. Validation at the end is an argument. Validation at submission is a workflow.

Problem three: subcontractors will not use your beautiful interface

Every handover system fails in the same way, which is that the people who hold the data are subcontractor site managers and commissioning engineers who have no interest in learning your platform. They have a spreadsheet, a camera roll and an email account.

The build that works meets them there. Accept the spreadsheet, in their column order, and map it. Accept a folder of PDFs and photographs. Then do the reconciliation work in software rather than demanding it from a human. This is the place where document extraction genuinely earns its cost: a commissioning certificate PDF contains the asset reference, the date, the engineer and the result, and reading a thousand of them into structured records against your asset register is a job a model does well and a graduate does badly at three in the morning before a handover deadline. Data plate photographs are the same story, with manufacturer, model and serial legible in most cases and queued for a human when they are not. Nobody types a serial number twice.

Problem four: the real acceptance test is the CMMS import, not the COBie file

You can produce a technically valid handover file and still be rejected, because the owner's maintenance system has its own import format, its own required fields, its own hierarchy of location, system and asset, and its own view of what a maintenance regime is. Maximo, Planon, Archibus and the rest each expect something different. Owners who use standard maintenance task libraries expect asset types mapped to their maintenance schedules so the planned preventive work generates on day one.

A build treats the export as a first class mapping layer with a target profile per owner, and it proves the import before handover instead of discovering the failure after. The single most valuable feature we build in this category is a dry run: generate the owner's import file, run it against a copy of their target structure, and report the rejections while there is still time to fix them. Contractors who do that stop losing weeks at the end of every job.

Problem five: the warranty nobody can find in month fourteen

Fourteen months after handover a rooftop unit fails. Is it in warranty, whose warranty, what are the notification conditions, and was it commissioned correctly, because the manufacturer will ask. The answer is somewhere in a 900 page O and M PDF that was assembled by a document controller under time pressure.

Warranty is asset level data with a start date, a duration, a warrantor, conditions and a claim process, and it should be attached to the asset record rather than compiled into a binder. Once it is, defects during the liability period route to the responsible subcontractor automatically, and the contractor stops absorbing costs that belonged to someone else. This is the part of handover software that pays back to the contractor rather than the owner, which is why it is worth building even when the owner's specification does not ask for it.

What it costs and how long it takes

A focused first release covering the asset register with the owner's requirement model, subcontractor submission through spreadsheet and document upload, automated validation and the owner specific export mapping runs $50,000 to $110,000 and ships in 10 to 16 weeks. A full platform adding warranty and defects tracking, model federation and linkage, maintenance regime authoring, an owner and facilities portal and multi project rollout runs $130,000 to $300,000 phased over 6 to 10 months.

What drives cost up specifically: the number of distinct owner profiles you deliver to, because each one is a mapping and rules configuration. Model integration, if you need asset records linked to model objects rather than living beside them, because that means handling exchange formats and the fact that models are updated after the data was extracted. Direct write into the owner's maintenance system rather than file export. And on golden thread projects, the evidence and version control expectations, which are stricter than commercial handover and should be scoped explicitly.

What keeps cost down: starting with one live project and its actual owner requirement rather than trying to build a generic engine on day one. The generic engine emerges from the second and third project, and it emerges correctly because it was extracted from real cases.

How to choose a developer for handover and asset data

Ask them to model the difference between a type and a component before you sign anything, and to explain how a maintainable asset relates to a space, a system and a document. That distinction is the spine of structured handover, and a developer who has not met it will build a document library with a spreadsheet attached.

Ask how a subcontractor submits data. If the answer requires the subcontractor to log in and complete a form for each asset, the system will not be used and your data will still arrive by email at the end.

Ask specifically about validation rules: can your digital delivery team author and version them without a code release, and can rules differ per project and per owner. If rules are hard coded, every new client is a development ticket.

Ask who owns the code and get it written down before kickoff. You should own the repository, the cloud accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. In a sector where handover systems outlive the projects that funded them, that ownership is worth arguing for.