On what grounds can you reject an IFC delivery?

On any ground agreed in advance and testable on the file: structural findings at severity error, a Health Score below the agreed threshold, incomplete check coverage, GUID turnover above an agreed percentage, wrong units, wrong coordinate reference, or a filename that breaks the project convention. Rejecting on grounds that were never agreed is how quality reviews turn into disputes.

Who decides whether an IFC model is acceptable?

The information manager applies criteria that the whole delivery team agreed before the first delivery — usually recorded in a table appended to the BEP. The point of agreeing first is that acceptance becomes an application of a rule rather than a judgement about somebody's work.

What should you do when a model fails acceptance?

Return it with the specific findings, the rule identifiers, the element counts and a plain statement of what is blocked until it is fixed — and hold coordination on that container rather than working around it. Working around a failed delivery teaches the project that the gate is optional.

Back to the BIM & IFC blog

Delivery & ISO 19650 · 2026-08-07 · 10 min

IFC Acceptance Criteria: How to Accept or Reject a Model Without an Argument

"This model is unusable" versus "the model is fine" is an argument with no ending. A one-page acceptance table, agreed before the first delivery, turns it into a five-minute check with a documented outcome.

IFC Acceptance Criteria: How to Accept or Reject a Model Without an Argument — IFC Viewer Online article cover

Somewhere on every project there is a moment where a coordinator opens a delivered model, spends twenty minutes discovering it cannot be used, and writes an email that begins "unfortunately". What happens next depends almost entirely on one thing: whether anybody wrote down, in advance, what an acceptable delivery looks like.

If they did, the email is short, factual and uncontroversial. If they did not, the email is the opening move in a negotiation about whose standards apply, and it will be re-litigated at every gateway for the rest of the project.

Acceptance is a checklist, not an opinion

The mental shift is small and it changes everything. Reviewing a delivery is not assessing quality — it is applying agreed criteria to a file. That has three consequences worth stating explicitly:

The reviewer needs no authority beyond the agreed table. They are not judging the model author's competence; they are reporting a result.
The author can predict the outcome before they issue. Anything predictable can be prevented, which is the entire point.
The disagreement, when it happens, is about the criteria — a conversation that can be held once, calmly, rather than every month in the middle of a delivery.

You cannot reject a delivery for failing a standard the sender never agreed to. You can only reject it for failing the one you both did.

The acceptance criteria table

This is the artefact. Ten rows, one page, appended to the BEP or the EIR. The third column is empty on purpose — the project fills it in before the first delivery, and that act of filling it in is where the real agreement happens.

Criterion	Reject if…	Project position
Structural integrity	Any schema or spatial finding at severity error	Reject / accept with note
Health Score	Below the agreed threshold	Threshold: __ /100
Check coverage	Any check reported as not-run or failed	Reject / re-run required
Identifier stability	GUID turnover above an agreed percentage between revisions	Max turnover: __ %
Naming	Filename does not follow the agreed convention	Reject / rename and log
Georeferencing	Model not on the project shared reference point	Reject
Units	Non-metric length units	Reject
Classification	Elements without a classification reference	Applies from stage: __
Property sets	Required psets missing for the declared level of information need	Pset schedule: __
Spaces	Spaces without name, long name or floor area	Applies from stage: __

Its purpose is not to be strict — it is to be decided. A lenient table that everybody agreed beats a strict one that arrived with the rejection email.

The first three rows are the ones that carry the weight, and they are also the ones most often left out. The clauses that put them into the BEP in the first place are covered in BEP clauses that actually prevent bad IFC deliveries.

Row 3 deserves its own section: check coverage

Most acceptance tables check the results of a validation run. Almost none check whether the run actually happened, and that is a hole big enough to drive a delivery through.

A check that did not run looks exactly like a check that passed: both produce zero findings. A large file times out, a worker crashes, a geometry-dependent check quietly gives up — and the report comes back clean with a perfect score. The delivery is accepted, having been checked in name only.

Coverage state	What it means	Acceptance action
Ran	The check completed. Zero findings means zero findings.	Trust the result.
Not run	Attempted but produced no outcome — usually a timeout or a cancelled run.	Re-run before accepting. Never read as a pass.
Failed	The check errored.	Report it. A score computed over failed checks is not comparable to a clean run.

Reviewing a delivery in five minutes

Open the container and run the project rule set. Under a minute for most discipline models.
Check coverage first, results second. If anything did not run, stop — you do not have a review yet.
Read the score against the threshold, then the findings at severity error. Everything else is a note, not a gate.
Compare against the previous revision. New findings are the story; resolved ones are the receipt that the last review was acted on.
Record the outcome in the transmittal or the CDE comment — score, rule set, coverage, and any finding accepted by agreement.

Step 1 is the same routine the sender should have run before issuing; how to check an IFC model before delivery walks through it from the sending side. When both ends run the same checks, the review stops being an inspection and becomes a confirmation.

How to write the rejection

The register matters as much as the content, because the person receiving it is usually behind schedule and rarely at fault personally. Three rules: name the criterion, not the model. Give the cause, not just the symptom. Say what is blocked and for how long.

Hi {name},

We've run the agreed pre-acceptance check on {filename} (rev {n}) and it
comes back at {score}/100, below the {threshold} we set in clause {x} of
the BEP.

The two findings driving that are:
  - {rule id} — {plain description} ({n} elements)
  - {rule id} — {plain description} ({n} elements)

Both look like export settings rather than modelling, so they should be
quick — the report is attached with the element references.

We'll hold coordination on this container until the next issue.

Notice what is absent: any adjective about the model, and any speculation about why it happened. A number, two rule identifiers, a likely cause and a consequence. That is a message nobody has to defend themselves against, which is why it gets acted on instead of escalated.

When to accept a model that failed

Sometimes the right answer is yes anyway — the missing information is outside the level of information need for the stage, or a supplier has not delivered yet, or the alternative is stopping the project. Accepting a failed delivery is a legitimate decision. Accepting it silently is not.

A waived finding needs three things attached: a reason, a person who agreed, and a date. That is the whole difference between a finding accepted and a finding ignored, and it is what stops the same issue being rediscovered as a crisis two stages later.

Those waivers belong in the transmittal, alongside the report and everything else that travels with the container — see what to hand over with an IFC model.

IFC Acceptance Criteria: How to Accept or Reject a Model Without an Argument