Project Fraud Starts Where Governance Stops: A Lifecycle View of Fraud Risk on Capital Projects

Fraud on a capital project rarely needs a criminal mastermind. It needs a decision nobody has to justify, a transaction nobody has to evidence, and an approval nobody can trace. When the owner leaves those gaps open, the owner is, in effect, inviting fraud.

Capital projects carry more fraud risk than day-to-day corporate operations. Corporate finance runs on enforced policies, a general ledger and an audit calendar. A project, by contrast, is a temporary organisation of owner staff, consultants, contractors and suppliers, assembled under time pressure, spending large sums through hundreds of contracts and thousands of transactions. Each estimate, bid evaluation, change order, payment certificate and inspection is a decision point. Each decision point is a place where someone can favour a party, hide a delay or move money for personal gain.

Is this article for you?

This series is written for capital project owners, PMOs and project management consultants who believe their projects are digitally controlled, and for those who know they are not. In particular, it is for organisations that:

• Run delivery through Aconex or another document management system, where RFIs, variations and payment certificates move as correspondence and attachments.
• Use a CDE whose workflows review documents but cannot route a transaction by its value, category and contract impact under a Delegation of Authority matrix.
• Use a PMIS that cannot integrate with the ERP, so approved figures are re-keyed into finance and two versions of the truth exist.
• Use a PMIS without comprehensive cost and contract management, so estimate, budget, bids, commitments, changes, invoices and payments are not one connected chain.
• Fund or invest in capital projects as a ministry of finance or sovereign fund, and need assurance that the capital provided is spent on verified delivery.
• Advise clients on project governance as management consultants, and want recommendations that are enforced by a system rather than bypassed in practice.
• Use no system at all, relying on email, paper and spreadsheets.

Each part shows, process by process, where these set-ups leave the fraud risk open, how PMWEB closes it, and why organisations on the wrong platform have no excuse left for not migrating.

The Association of Certified Fraud Examiners estimates in its Occupational Fraud 2024: A Report to the Nations that organisations lose about 5% of revenue to fraud each year, that a typical scheme runs for a year before it is detected, and that more than half of cases trace back to missing internal controls or managers overriding the controls that exist. Construction ranks among the sectors with the highest median loss per case. On a giga-project portfolio, 5% of annual capital spend is not a rounding error. It is a hospital, a school cluster or a road network that never gets built.

This series rewrites and expands my earlier articles on how a Project Management Information System (PMIS) like PMWEB prevents and detects fraud on capital construction projects. Part 1 sets out the fraud risk across the project lifecycle and the governance model that deters it. Parts 2 to 6 take each high-risk area in turn: approval authority, procurement, change and claims, payments, and forensic audit. Part 7 shows how PMWEB 2026 AI and analytics built on PMWEB data move the owner from finding fraud after the money has gone to flagging it while the transaction is still open. A thread runs through every part: platforms that were never designed as a PMIS, such as document management systems, ERPs, e-tendering portals and generic workflow tools, give owners the false assurance that their projects are digitally controlled when the controls that deter and detect fraud are not there.

Fraud is deceiving someone to obtain an unfair or unlawful gain. On a capital project it takes two forms. The first is the act itself: a kickback, a fake invoice, an inflated change order. The second, far more common, is the decision or report that hides the truth from the owner: an estimate understated to get a project approved, a schedule overstated to hide a delay, a deliverable accepted that was never fit for purpose. Both cost the owner money, time, quality or reputation.

The twenty actions below come from my original article. Grouped by where they happen, they show that fraud is not confined to procurement or payments. It runs from the business case to the final account.

The Risk Everyone Knows and Nobody Names

Every experienced owner, consultant and contractor knows that fraud happens on capital projects. Ask privately and most can describe a case. Yet project fraud rarely appears in a risk register, a board paper or a project review. It is spoken about as something that happens on other projects, in other organisations, in other countries.

It takes courage for a board or a PMO head to say openly: fraud is a risk on our projects, as it is on every capital programme, and we will manage it like any other risk, with an owner, controls, indicators and reporting. Saying so is not an accusation against anyone. It protects honest people, because it replaces suspicion with evidence.

Audit Finds Fraud; Controls Prevent It

Where fraud is addressed, the main tool is usually audit: internal audit reviews, external audits, state audit bureau inspections, and forensic audits when something has clearly gone wrong. These are essential, but they share one limitation. They look backwards. Audits are periodic, they test samples, and they usually start after the estimate was approved, the contract awarded, the change order signed and the payment made. Their question is "was there fraud?", and if the answer is yes, the money is already gone and recovery is slow, costly and partial.

The ACFE figures above show the cost of that delay: a typical scheme runs for about a year before it is detected. Prevention asks a different and more valuable question: "can this transaction be approved without the evidence, the authority and the checks it needs?" If the system makes the answer no, the fraud never happens.

This series is built on that shift. Audit remains necessary, and Part 6 shows how PMWEB strengthens it. But the controls in Parts 2 to 5 act at the moment of the transaction, and the analytics in Part 7 act continuously, so the auditor's job changes from finding fraud after the fact to confirming that the controls work.

In most fraud investigations I have seen, the policies existed. The procedures manual existed. What did not exist was a way to make every person follow them every time and to prove afterwards who did what. The conditions that encourage fraud are predictable:

• No stated policy. Without an explicit zero-tolerance policy, fraud is treated as a disciplinary matter for individuals rather than a risk the organisation manages.
• Procedures on paper only. The standard operating procedures manual defines forms, workflows and authority levels, but nothing stops a transaction from skipping them.
• Data silos. Estimates sit in spreadsheets, contracts in a shared drive, invoices in finance, correspondence in email. Each reconciliation is manual, and every manual step is a place where numbers can be adjusted.
• Financial ambiguity. Budget, commitments, pending and approved changes, invoices and payments are never seen together, so an over-commitment or a duplicated payment is invisible.
• No record of decisions. When decisions are made in meetings and emails, nobody can later show who decided, on what evidence and under which authority.
• Resistance dressed as practicality. "The contractor will not enter data" and "the system slows us down" are common objections. Sometimes they are genuine. Sometimes the objection is to transparency itself.
• Digitalisation in name only. Documents, payments and tenders run on platforms that were never designed as a PMIS, so management believes controls exist that do not.

The Most Dangerous Control Is the One You Think You Have

Many owners will read the section above and conclude that the problem is solved, because their projects are already "digital". Drawings and correspondence go through a document management system or common data environment. Purchase orders and payments go through the ERP. Tenders are issued on an e-tendering portal. Approvals are routed through a generic workflow or low-code tool. Monthly reports are built from spreadsheets with a business intelligence layer on top.

Each of these tools is good at the job it was designed for. None of them was designed to manage the business processes of capital project delivery. The same applies to some products sold as a PMIS: if the system cannot be integrated with the ERP, or does not cover cost and contract management from estimate to payment, the most fraud-exposed transactions still sit outside it. Used in place of a PMIS, they do something worse than leave a gap: they create false assurance. The board, the auditors and the regulators are told that the projects are digitalised, so they assume that the controls a digital system should provide are in place. They are not. Fraud then runs through the gap between what the organisation believes is controlled and what is actually controlled.

The pattern is the same in every case. The tool records that a document was uploaded, viewed, stamped or sent. A PMIS records that a transaction was submitted, checked, approved within authority and posted to the cost ledger, with every value held as data. Fraud is committed in the transaction, not in the file name. A system that cannot read the transaction cannot test it.

Six questions to test whether your digitalisation deters fraud

• Can the system tell you the approved budget, committed value, pending changes, approved changes, work in place, invoiced and paid for any contract, today, without a spreadsheet?
• Does the system decide who approves a change order or invoice from its value and contract impact, or does a person choose the reviewers?
• Can the system compare every bid line item with the approved estimate, and every change order rate with the contract rate?
• If a change order is approved in a document platform, can anyone prove the figure paid in the ERP is the figure that was approved?
• Could an auditor run the red-flag rules in this article on your data, or would they first have to rebuild it from PDFs?

If the honest answer to any of these is no, the organisation has digitalised its documents, not its controls. The rest of this series shows, process by process, where that difference lets fraud through.

Time to Move: Migrating to a PMIS Like PMWEB

If the six questions above show that an organisation's fraud-exposed processes run on the wrong platform, the recommendation is direct: it should migrate them to a PMIS like PMWEB. Today there is no credible excuse for continuing to run them where they are. Adding another policy, another review step or another spreadsheet to a platform that cannot read the transaction will not close the gap. It will only deepen the false assurance.

Organisations often delay migration because the current platform is familiar, contracts with suppliers are in place, and moving project information feels risky. Those concerns are real, but they need to be weighed against the cost of staying. Every year on a platform that cannot enforce the DoA, compare bids with the estimate, link change to its cause or reconcile certificates to payments is a year of exposure to the leakage priced in the ROI section below. On a large capital programme, the cost of staying usually exceeds the cost of moving within the first year.

A low-risk migration path

• Assess. Map which processes run where, and how legacy data is held: its structure, media, size and consistency across projects. That assessment decides what is migrated and what is archived.
• Start where risk is highest. Move procurement, change and payment processes first, because that is where fraud exposure and value are concentrated.
• Start on a new programme. A PMIS is programme-scoped, so PMWEB can go live on a new programme while existing projects continue on the current platform, avoiding a big-bang cut-over.
• Configure, do not code. PMWEB is configured to the organisation's procedures, DoA matrix and forms, which keeps the implementation fast and the system owned by the client.
• Integrate rather than duplicate. Connect the ERP and any document platform that remains, so each transaction is entered once.
• Migrate live projects in waves. Bring the cost and contract records of ongoing projects into PMWEB in planned waves; PMWEB's Microsoft SQL Server database makes structured data loading and validation straightforward.
• Close the back door. Once a process runs in PMWEB, stop accepting off-system approvals for it.

The reasons given for staying on the wrong platform are familiar. None of them survives contact with the facts, and every month of delay is paid for in exposure.

The Governance Model That Deters Fraud

My original article set out four pillars. They remain valid, with one change: the enabler is no longer optional. Without a system that enforces the method, the objective stays a statement on the wall.

Organisation, lifecycle and stage gates

The procedures manual starts with the organisation that manages the portfolio, whether a projects department, project management unit or PMO, with its roles and responsibilities. It then defines the lifecycle from planning and concept design through detailed design, procurement, construction and defects liability, with a stage gate between each stage at which the owner decides whether the project proceeds. In PMWEB each gate is a record with its own checklist, evidence and approval workflow, so no project can pass a gate on a verbal assurance.

The processes that need the tightest control

The manual typically covers twenty or more procedures. The ones with the highest fraud exposure, and the PMWEB modules that hold them, are:

How PMWEB Turns Procedures Into Controls

Every business process in PMWEB follows the same pattern. Each element closes a specific fraud opportunity.

One Version of the Truth Removes Financial Ambiguity

Financial ambiguity is one of the most common enablers of project fraud. When the estimate, budget, bids, awarded contracts, pending and approved changes, invoices, payments and funding releases sit in separate silos, nobody can see that a contract has been over-committed, that the same work has been paid twice or that contingency has been quietly spent. In PMWEB, every one of those transactions posts to the same cost ledger the moment it is approved. The cost worksheet shows them side by side for each cost code, contract and project, and the same data rolls up to programme and portfolio.

The same principle applies beyond cost. Schedule, deliverables, quality, safety and document approvals are captured in the same database, so the executive view of the project is calculated from the transactions rather than reported about them.

From Controls to Red Flags

Controls prevent most fraud. They do not prevent all of it, because people with legitimate access can still misuse it. The second line of defence is a set of red-flag rules that run on PMWEB data every period. A red flag is a question, not a verdict. It tells the integrity or audit team where to look; the investigation decides whether there was wrongdoing.

Each flag raised becomes an Integrity Red Flag record in PMWEB, created as an adaptive form linked to the source transaction, with a severity, an owner, a due date, the evidence attached and a workflow that routes it to the integrity or internal audit function. The flag itself is then auditable: who reviewed it, what they found and how it was closed.

Project Integrity Overview — a Power BI report on the PMWEB database, embedded in PMWEB. Illustrative data for a five-programme

giga-developer portfolio.

The integrity overview shows open red flags by lifecycle stage and by programme, and a heatmap of programme against business process. In the illustrative data, the portfolio total of 47 open flags looks manageable until the heatmap shows that 21 of them sit in one programme, concentrated in change orders and payments. That is where the integrity team starts. Every number opens to the flags behind it, and every flag opens to the PMWEB record that triggered it.

Where PMWEB 2026 AI Helps

Part 7 covers AI in depth. Even at this stage, the PMWEB 2026 AI Assistant changes how a reviewer works with the data. It can find records in plain language ("show me change orders over SAR 1 million on the Mountain Destination programme approved in under three days"), open them, create records such as a red flag with the user's approval, and help users understand a process or a screen. It acts only with the user's approval and honours PMWEB security settings, so a reviewer sees only what their role allows. The value of any AI rests on the same foundation as the controls in this article: complete, structured, approved transaction data in one database.

The ROI of a PMIS When Fraud Is Priced In

Business cases for a PMIS are usually built on productivity: fewer manual reports, faster approvals, less time reconciling spreadsheets. Those benefits are real, but they are the smaller part of the return. The larger part is the loss that does not happen. Because fraud is rarely named as a risk, it is rarely counted as a benefit, and the business case understates the value of the system by an order of magnitude.

The arithmetic is simple. The ACFE's cross-industry estimate is that organisations lose about 5% of revenue to fraud. Capital programmes are not the same as corporate revenue, so assume something far more conservative: that a PMIS which enforces the controls in this series reduces fraud-related leakage by only a fraction of one percent of annual capital spend. The table shows what that is worth each year.

Illustrative arithmetic, not a forecast. Each owner should apply its own capital spend and its own view of exposure.

Set any of those figures against the full cost of owning and implementing a PMIS across the same portfolio, and the return is measured in multiples, not percentages. On a giga-project portfolio, avoiding a quarter of one percent of leakage alone can repay the system many times over every year, before a single productivity benefit is counted.

Fraud prevention also carries returns that never appear as a line item:

• Claims avoided. Fair, fast and evidenced payment and change decisions remove the grievances that turn into claims and disputes.
• Lower audit and investigation cost. Auditors test controls and evidence already in the system instead of rebuilding records.
• Faster recovery when something does go wrong. The evidence chain exists from the first transaction.
• Confidence of funders and stakeholders. Boards, ministries of finance, lenders and investors rely on figures that can be traced to approved transactions.
• Deterrence. The most valuable control is the one that stops an attempt before it is made. Its return is real even though no report will ever show the fraud that never happened.

For Ministries of Finance and Sovereign Funds: Protecting the Capital You Provide

Ministries of finance appropriate and release the capital that government entities spend on projects. Sovereign funds invest it, as equity in giga developers, project companies and public-private partnerships, and expect it to be preserved and to earn a return. Both are the parties most exposed to project fraud and the furthest from where it happens. They do not approve change orders or certify payments. They see what the implementing entity or portfolio company reports, usually as periodic summaries assembled from the very tools this series has shown to be fragile.

Every riyal or dirham lost to fraud is capital the ministry must find again, or a return the fund will never earn. Under the illustrative arithmetic in this article, avoiding even a quarter of one percent of leakage across a national capital programme or an investment portfolio is worth tens or hundreds of millions each year. Funders are therefore not only beneficiaries of fraud controls; they are in the strongest position to require them.

Conditions funders can attach

• Funding release against evidence. Release tranches against certified progress and approved commitments in a PMIS, not against requests supported by spreadsheets.
• Funder dashboards from the source. Receive portfolio dashboards calculated from transaction data, with drill-down rights, instead of periodic reports.
• Integrity reporting. Require red-flag indicators and their dispositions to be reported each period, alongside cost and schedule.
• Consistency across entities. Apply the same process templates and KPI definitions across all funded entities, so performance and risk can be compared like for like.

For Management Consultants Advising on Project Governance

Management consultants are often the people who define a client's project governance: the PMO operating model, the lifecycle and stage gates, the Delegation of Authority matrix, the policies and procedures, the KPIs. The quality of that work is rarely the problem. The problem is what happens after the report is accepted. If the recommendations are implemented on email, on a document platform such as Aconex, on a CDE with document-review workflows, or on a PMIS that cannot carry cost and contract processes or connect to the ERP, the governance exists on paper and is bypassed in practice. When a fraud case later surfaces, the question asked is whether the governance was adequate, and the adviser's name is on it.

Governance advice is only as strong as its enforcement. The most valuable thing an adviser can add to a governance recommendation is the specification of the system capabilities that make it enforceable, and a way to test that they are in place.

A five-level maturity model for fraud-resistant project governance

Level 3 is where many clients sit, and it is the most dangerous level for an adviser to leave them at, because it looks like progress. Moving a client from level 3 to level 4 is usually the single highest-value recommendation in a governance engagement.

The funder's lens — ministries of finance and sovereign funds

• Treat fraud prevention as capital preservation: every loss avoided is capital the ministry does not have to re-appropriate, or a return the fund does not lose.
• Use the maturity model to assess each implementing entity or portfolio company, and set a target level as a condition of funding or investment.
• Ask for dashboards calculated from transactions, not summaries assembled from documents.

Adviser's checklist — for consultants recommending project governance

Questions to ask in the diagnostic

• Is project fraud named in the client's risk register, with an owner, controls and indicators?
• Which of the eight set-ups in this article does the client actually run on, process by process?
• Which governance recommendations from previous reviews are enforced by a system, and which rely on people?
• Where on the five-level maturity model is the client today?

Recommendations to put in the governance report

• Name project fraud as a managed enterprise risk and assign it an owner.
• Move the most fraud-exposed processes (procurement, change, payment) to an integrated PMIS before refining policy further.
• Report fraud-control effectiveness to the board using the indicators at the end of this article.

Evidence That the Governance Model Is Working

• Process coverage. The share of in-scope delivery processes run end to end in PMWEB, with no off-system approvals.
• Evidence completeness. The share of records with all mandatory attachments and linked records.
• Exception rate. Transactions approved outside workflow or outside the DoA, trending to zero.
• Red-flag closure. Flags closed with a documented disposition within the target period.
• Recurrence. Repeat flags on the same party or process falling after corrective action.

Key takeaway

Fraud thrives where decisions are undocumented, data is fragmented and approvals are untraceable. A zero- tolerance policy and a procedures manual define what should happen. PMWEB makes it happen, every time, and records who did what, when and on what evidence.

Digitalising documents is not digitalising controls. A platform that was never designed as a PMIS gives the board the comfort of a digital system without the controls of one, and that false assurance is itself a fraud risk.

With every transaction in one database, the owner can move from reacting to fraud after the money has gone to flagging the patterns that precede it.

Project fraud is a known risk that too few organisations have the courage to name. Audit will always find some of it after the money has gone; controls in PMWEB prevent it at the transaction, which is where the real value lies.

Priced against the fraud risk it removes, a PMIS is not a cost to be justified; it is one of the highest-return investments a capital programme can make.

Organisations running their fraud-exposed processes on the wrong platform have no excuse left. They should migrate to a PMIS like PMWEB; the cost of staying is the leakage, every year.

Next in the series: Part 2 looks at approval authority: how PMWEB workflows enforce the Delegation of Authority matrix, handle delegation during absences, and produce output forms that show exactly who reviewed and approved each transaction.