In this 2026 digital transformation series for Irish Building, we’ll explore why the next productivity leap in AEC won’t come only from better models, data, or dashboards – but from upgrading the agreement layer: contract administration across the full business lifecycle.

In Part 1, we make visible the hidden “trust tax” that accumulates at contract boundaries in a fragmented sector – from tender clarifications and negotiated terms through design acceptance, change control, certification, payment, commissioning, and dispute avoidance. In Part 2, we introduce a practical architecture: Law → Protocol → Code – that separates human judgement from automated record-keeping and settlement. In Part 3, we show how “dead” PDFs can become computable promises, and how BIM/CDE workflows – supported by AI and DLT tamper-evident audit trails – can generate verifiable proof, not just stored files. In Part 4, we map an adoption path that works incrementally without a platform reset.

Understanding the “Trust Tax”  

To put a real number on this, research on transaction costs in construction has reported post-contract transaction costs – administration, monitoring, claims management, and dispute handling – reaching into the low-to-mid teens as a share of contract value in some contexts (reported ranges around 8.9%-14.7%, average ~12.6% in certain design-bid-build cases, e.g., Vilnius Tech and related studies). On a EUR 50m project, that is roughly EUR 4.5m to EUR 7.4m of coordination overhead before you count delay impacts. And when disputes do escalate, industry reporting shows how high the stakes can run: Arcadis’ 2023 Global Construction Disputes reporting cited an average dispute value of about USD 42.8m and an average resolution time around 13.6 months in major markets.

Contract administration is often treated as the slow, bureaucratic tail of AEC delivery – forms, notices, certificates, and endless email threads. In reality, it’s the project’s operating system: the machinery that turns intent into authorised commitments, into accepted outcomes, and outcomes into certification and payment. And it doesn’t start on site. It starts in tendering and negotiation, where clarifications, exclusions, assumptions, programme promises, and risk trade-offs become the commitments that govern everything downstream for designers, contractors, and clients. In this first article, we’ll name the trust tax that appears when authority and acceptance are unclear, explain why fragmentation is rational (and why coordination is costly), and pinpoint where friction concentrates – change, payment, and handover – so the real problem is visible.

1) Contract administration is the operating system of delivery  

Not paperwork: the project’s operating system

When people say “contract administration,” they often mean paperwork. But paperwork is the symptom, not the system. Contract administration is the operating system that converts ambition into authorised action – and action into defensible outcomes. If that operating system is clunky, everything runs slow – no matter how advanced your digital toolchain is. You can have excellent BIM models and still have a project that can’t decide, can’t certify, can’t pay, and can’t close, because the agreement machinery isn’t working at the speed of reality.

The chain that runs every project

Across the lifecycle, the chain is consistent – and it starts pre-contract. A tender query, a clarification response, a qualification, a Value Engineering proposal: each is a commitment moving toward binding terms. Post-award, the chain continues: decisions are recorded, evidence is gathered, acceptance is granted (or withheld), change is controlled, certification is issued, payment is released, and disputes are avoided or escalated. This is the real business production line of AEC. Delivery depends less on “having the information” than on converting information into obligations and into settleable outcomes.

Agreement pain disguised as “project management issues”

This is why so much “project management pain” is actually “agreement pain”. The decisive questions are basic: Who is authorised to decide? What evidence is required? What is the acceptance test? What happens if we disagree? When those are fuzzy, every step becomes negotiable and every decision becomes vulnerable. Teams don’t just manage work – they manage exposure. Much of what we call bureaucracy is an improvised defence mechanism for commitments that aren’t legible enough to rely on later.

2) Fragmentation is rational, coordination is costly

Fragmentation as competence, not dysfunction

Nobel economist, Ronald Coase, explained the real question isn’t “why are we fragmented?” but “what does it cost to coordinate across boundaries?” – and AEC pays that cost every day in contract administration. AEC leaders often talk about fragmentation as a defect: too many parties, too many interfaces, not enough “integration.” But fragmentation is also the price of competence. We deliver complex assets by assembling specialist capability in temporary coalitions – without carrying every capability in-house at full utilisation. This is true commercially too: tendering and negotiation exist because projects are not “one firm deciding internally.” They are many firms aligning expectations across boundaries on every project.

Why coordination costs dominate

Construction lives on the boundary by necessity (just in time delivery). But every interface has coordination cost: scope must be agreed, quality verified, time managed, price adjusted when reality changes. And because incentives and liabilities diverge, each interface needs a trust mechanism – not trust as a “feeling of goodwill”, but trust as a provable arrangement that can stand up when pressure arrives.

What digital transformation often missed

This reframes digital transformation. If we only digitise artefacts – drawings, models, documents – without reducing coordination cost, we haven’t transformed the business; we’ve modernised the filing cabinet. AEC doesn’t slow down because it lacks information. It slows down because it lacks agreement clarity at the points where information becomes obligation: approval, acceptance, certification, payment. That’s why we can have better collaboration yet still see the same commercial friction: submissions become contested, variations disputed, payment certs delayed. The tools make work more visible; they didn’t make commitments more settleable.

3) The trust tax: why admin effort grows faster than complexity  

Defensive behaviour is rational

The trust tax shows up in behaviours that feel normal: copying extra people “just in case,” requesting another meeting “to be safe,” duplicating checks, running shadow trackers, re-issuing the same information in multiple formats. People don’t do this because they enjoy bureaucracy. They do it because uncertainty makes exposure real.

When authority thresholds and acceptance rules aren’t explicit, the safest move is to build your own CYA “paper trail”. Multiply that across all parties and the project carries an invisible surcharge on every decision – long before anyone calls it a dispute.

Evidence inflation: data ≠ proof

The trust tax also inflates evidence. Teams collect not only what’s needed, but what might be needed if a future dispute rewrites the rules. The paradox is that we have more data than ever and still can’t settle basic questions quickly, because evidence isn’t the same thing as proof. Proof is evidence recognised by the agreement and attested by legitimate authority. Without that recognition layer, you can store the whole project history and still argue about meaning.

Decision latency becomes a first-order cost

Decision latency is where the trust tax becomes visible. A delayed decision isn’t just a delayed instruction – it delays procurement, mobilisation, sequencing, payment, and certainty. It triggers rework, misalignment, and “proceed at risk” behaviour. And latency compounds: slow tender clarification → weak agreement basis → contested design acceptance → procurement uncertainty → site changes → payment disputes.

4) Where friction concentrates: the hotspots

Change is where reality collides with the contract

If you want to see the agreement layer at work, don’t look at the BIM execution plan – look at the change register. Variations test authority (who can instruct?), entitlement (is it in scope?), measurement (what is it worth?), and proof (what confirms it happened?). The slow part is rarely the calculation. The slow part is agreeing what the change is in contractual terms, and whether it is recognised as a change at all. And it starts upstream: late clarifications, Value Engineering proposals, “we’ll make it work” design decisions – changes in everything but name.

Payment is where agreement becomes money

Payment and certification sit at the point where agreement becomes money. Most payment friction isn’t arithmetic; it’s disagreement about completion, acceptance, and proof. What counts as complete? Is a deliverable issued or accepted? Are snags grounds to withhold certification, or simply to record deductions? When those rules aren’t operational, payment becomes a battlefield for mistrust. Cashflow predictability collapses and everyone responds rationally: tighter controls, more scrutiny, slower approvals.

Handover is the final settlement of trust

Handover and commissioning are the final hotspot because stakes spike. Late-stage delivery is where narratives harden: who did what, who caused what, who accepted what. It’s also where the gap between “information delivered” and “outcome achieved” becomes obvious. A folder of O&M manuals isn’t commissioning; a completed BIM model isn’t an operable asset. The agreement layer should manage this transition through clear acceptance tests and evidence requirements. When it doesn’t, ambiguity is deferred into defects, disputes, and strained client relationships – even if the building is occupied.

5) The evidence problem: email archaeology and competing truths

  

Too much evidence, no agreed proof

Most projects don’t lack evidence; they drown in it. Emails, marked-up PDFs, CDE comments, photos, instructions – each is evidence, but none is decisive unless the agreement says it is. So when something becomes contested, teams reconstruct history instead of consulting a clear chain of accountable decisions. The result is predictable: time is burned finding information, arguing about meaning, and rebuilding a version of “what happened” that each party can live with.

Status is not acceptance

This is where the difference between status and acceptance becomes deadly. A document can be uploaded, shared, even “approved with comments,” but what does that mean in contractual terms? Does it trigger the next stage? Does it close an obligation? Does it permit payment? Tool metadata is useful – but it’s not automatically a legally meaningful trail. Acceptance is not a vibe; it is a governed act. Someone with authority attests that a defined acceptance test has been met, based on defined evidence, under defined terms. Without that act, the project has activity, not settlement.

When the dispute becomes process history

When a proof mechanism is missing, disputes become arguments about process history rather than outcomes. Instead of “did we deliver the agreed thing?” we argue “was the notice correct?” “was the period met?” “was that instruction valid?” These questions matter, but they become weaponised when the system isn’t designed to make them obvious at the time.

That’s what “email archaeology” signals: the project cannot point to a small, authoritative record of what was decided, by whom, under which rules, with which evidence, and what it triggered – so it re-litigates its own history.

6) What good looks like: faster delivery through legitimacy

  

Legibility: make “what counts” explicit

A better agreement system doesn’t eliminate disputes; it changes their physics. Routine matters settle quickly because “what counts” is explicit: the authorised decision-maker is named, the acceptance test is defined, and the minimum evidence is specified. That doesn’t make projects rigid; it makes them legible. It replaces negotiation-by-exhaustion with a clear pathway: propose, evidence, decide, accept, settle.

Auditability: receipts, not institutional memory

Decisions must be defensible to more than the people in the room at the time – auditors, adjudicators, clients, future asset managers. That requires receipts: a small structured record capturing the event, the authority, the evidence, the rule applied, and the outcome. Receipts reduce dependence on memory, survive turnover and tool changes, and prevent retrospective reinterpretation. This is where digital transformation becomes real: not just storing information, but producing durable proof of accountable outcomes.

Legitimacy unlocks velocity

In a legitimate system, parties don’t need to re-check everything because the process for deciding and accepting is reliable. People proceed with confidence because they know how commitments are made and how outcomes are recognised and recorded. That reduces defensive behaviour and frees energy for delivery. The goal is not to turn construction into software. It’s to give a fragmented, high-risk sector a better coordination engine – one that treats agreements as living digital infrastructure, not dead PDFs.

Conclusion and Next Step  

AEC is rich in information but poor in operational proof – across the full lifecycle, from tender clarifications through certification, payment, and handover. When authority is unclear and acceptance rules are ambiguous, everyone behaves rationally: they protect themselves, over-produce evidence, slow decisions, and rebuild history after the fact. That is the trust tax – and it’s why digitising documents and workflows often fails to deliver productivity. The next frontier of digital transformation is not another dashboard or repository; it is a contract administration system that makes commitments legible, evidence verifiable, decisions auditable, and settlement defensible. In Part 2 of our series we’ll move from diagnosis to design: a practical architecture: Law → Protocol → Code – that separates human judgement from automated record-keeping and settlement, and introduces the mechanism that makes speed safe in a fragmented industry: the receipt.

Ralph Montague is an Architect and Director at ArcDox BIM Consultants, a member of the Royal Institute of Architects of Ireland (RIAI), the National Standards Authority of Ireland (NSAI) Technical Mirror Committee for BIM Standards, and co-founder of the international BIM Heroes Community. With over 30 years of industry experience, Ralph specialises in advising individuals, businesses, and project teams on information management practices and implementing BIM standards (ISO19650). www.ArcDox.com www.BIMhero.io

Follow Irish building magazine on LinkedIn for the latest news and updates.