Scan-to-BIM for surveyors: deliver the facade model with the scan

A facade survey has two halves. The first half, the fieldwork and the registration, is what the client sees and what the day rate is for. The second half, turning the registered cloud into a model, is where the margin goes: a technician at a screen for a day or two per building, on work the client assumes was done by the scanner. This article is about what changes in that second half when a pipeline produces the model’s first draft in minutes, and what does not change at all.

Where the time goes today

Ask a surveying office what a facade model costs them and the answer is a technician-day, sometimes two, per facade of a few hundred square metres. The time is not in the walls; a wall is a plane and every tool finds planes. It is in the openings: placing eighty or a hundred windows one by one, reading each reveal off the cloud, matching widths across a storey, deciding whether the bay behind the tree is glazed or panelled. It is careful, repetitive work, and it is the kind that a model of the same building type has already been done a hundred times before.

It is also the part of the survey that is hardest to sell. The client pays for the scan; the model is either a line item they argue about or a cost you absorb. Either way, the day at the screen is the day you would rather spend on the next site.

What the pipeline does with your scan

You upload the registered cloud in E57, LAS, LAZ or PLY. The pipeline fits the facade plane, measures the facade’s extent, reads the openings from it. Each proposed opening is then measured against the points themselves. What comes out is a proposed IFC with one wall, the windows, doors and vents, and a per-element record of its confidence and whether it could be measured.

On the reference building, a 150-million-point terrestrial scan of a four-storey block, that took: 98 seconds to ingest, four model calls of about 90 seconds each, seconds for the fit and the emission. The proposal had 77 of the 96 windows, 3 of the 4 doors, almost no false positives, and placed the windows it measured within 0.6 cm along the facade and 2.0 cm in height on median. It did not model the railings, the canopy or the cornice, and it emitted every opening at a placeholder depth, both of which the review has to cover. The figures, including the unflattering ones, are on the Accuracy page and they are the same table the platform prints for your own buildings.

What stays the surveyor’s job

Everything that requires a decision. Concretely, on that facade:

• The 19 windows AutoIFC did not find, mostly behind loggia screens. The reviewer draws those, in the viewer, with the cloud underneath.
• The 18 windows could not be measured and left as drawn, flagged with the reason. The reviewer checks each against the cloud and adjusts the height or leaves it.
• Depth, until the engine fits it: the reveal depth of the windows that matter for the client’s purpose.
• Classes the pipeline does not attempt: railings, cornices, canopies.
• The one false positive, which is one keystroke.

That is a review of 96 elements plus the drawing of the missing ones. On a facade of this regularity it is an hour or two, against the day or two of modelling from nothing. On a facade where half the bays are screened, it is longer, and the pipeline tells you so before you start: the share of unfitted elements is on the run’s report.

Check it against your own model first

The pipeline’s published accuracy is measured on one reference dataset. Your buildings are different, and the only test that should decide whether you adopt the tool is a test on them. The platform is built to make that test cheap:

1. Pick a facade you have already modelled by hand.
2. Run the scan through the pipeline with your IFC attached as the reference (through the API today, or ask us to attach it).
3. Read the table: recall, precision and correctness at 5 and 10 cm per class, and the median error on each axis.

If the table says the proposal finds 80 % of your openings within 2 cm in the plane, the arithmetic of the previous section applies to you. If it says 50 %, it does not, and you have spent the welcome credits finding that out.

Fitting it into a surveying workflow

Three things about the platform were designed for a surveying office rather than an architect:

The frame is yours. The model comes out in the coordinate frame the scan was in: local, or georeferenced if the scan was. There is no re-projection and no origin shift to explain to the client.

The evidence ships with the model. The deliverables include the IFC, a PDF report, the evidence images per facade, and the run’s ledger. When a client asks why a window is where it is, the evidence that shipped with the model answers.

Batches go through the API. For a campaign of buildings, the REST API creates the projects, pulls the scans from your storage, launches the runs and pushes the deliverables back, with a signed webhook on every state change. The review is still done by a person in the viewer; everything around it is automated.

How the model fits your existing deliverables

A surveying office already delivers a registered cloud, a report and, often, 2D elevations. The facade IFC slots in beside them without changing the others.

• Same frame as the cloud. The IFC is in the scan’s coordinate system, so it overlays the cloud in any viewer the client already uses, and it overlays your 2D elevation if that was cut from the same cloud.
• Elevations from the model. Every opening is a box in the facade plane with a width and a height in metres. A 2D elevation drawing is the projection of those boxes; if you produce elevations today by tracing, the model is the tracing done.
• Schedules. The element list exports as JSON: one row per opening with class, position, size, confidence and verdict. A window schedule is a filter and a sort on that file.
• The report. The run’s PDF report states the facade dimensions, the counts per class, the share of fitted elements and the run’s cost, which is what a client asks about the model when they ask anything.

Pricing the model to the client

Because the platform bills per square metre of facade, you can quote the same way, and the arithmetic is transparent to both sides. A 600 m² facade costs you six dollars of credits at the launch price plus an hour or two of review; quote it as a line item per square metre with a margin, or fold it into the scan price as “delivered with facade model”. Either way the model stops being a cost you absorb and becomes a deliverable with a price, which on a housing campaign of thirty buildings is the difference between declining the modelling and winning it.

For an office that wants to test that before committing, launching a run and reviewing it in the viewer cost nothing: you are charged only when you download the IFC. Run one on a building you have already modelled by hand, and compare the two

The client-facing side

A model most clients cannot open is a model they do not value. Each project has a viewer link: the cloud and the model in a browser, read-only, with the classes you choose visible, optionally behind a password or with an expiry. Your logo sits in the header. The client sees the facade, clicks a window, and sees the same box you reviewed; the IFC download stays with you.

What this is not

It is not an interiors tool. The pipeline is built around a facade plane, and an interior scan has six. It is not a replacement for a modeller on a heritage facade with a hundred mouldings; AutoIFC finds openings, not ornament. And it is not a way to skip the review: the reviewed IFC is generated from decisions a person made, and a run nobody reviewed is a proposal, labelled as such.

Figures are from the AutoIFC engine’s scoring of 10 September 2026 on the reference building, a reference dataset modelled by a surveying company; it is not a customer building. See the Accuracy page and the Industries page.