Definition The distinction between a system of prevention and a system of record represents two fundamentally different philosophies of enterprise system design, distinguished by when and how they enable organisational action. A system of record is designed to capture, store, and report transactions accurately after they occur. Its primary purpose is documentation: creating an authoritative historical record that supports financial reporting, audit compliance, legal requirements, and analytical review. The system answers the question: What happened? A system of prevention is designed to enable control and intervention before adverse outcomes occur. Its primary purpose is operational: providing forward visibility, enforcing controls at decision points, and enabling corrective action while outcomes remain changeable. The system answers the question: What should we do—and what should we not do? In project-based industries, this distinction is critical because project economics are determined by decisions made during execution—not by reports produced afterward. A post-factum accounting system that records cost overruns after they occur provides documentary evidence of failure; it does not prevent the failure. A system of prevention enforces budget controls at commitment, validates progress against scope, and alerts to deviation while intervention is possible. The terminology reflects purpose: systems of record are designed to remember; systems of prevention are designed to act. Project-based organisations need both capabilities—accurate historical records for compliance and learning, and preventive controls for operational effectiveness. The question is which purpose drives system design. Context in Project-Based Industries The system of prevention versus system of record distinction manifests in daily operations across project-based industries. In construction, a system of record captures costs when invoices are processed and produces variance reports at period end. A project manager reviewing the report sees that concrete costs exceeded budget by 15%—but the concrete is poured, the subcontractor is paid, and the margin is lost. A system of prevention would have flagged the exposure when the subcontract was let, validated quantities against BoQ during progress certification, and alerted to unit cost deviation while corrective action was possible. In marine and offshore, a system of record documents fabrication and installation costs after completion. An offshore platform delivered over budget becomes a case study for lessons learned. A system of prevention would have tracked commitments across fabrication yards, validated weight and dimensional compliance before loadout, and escalated cost trajectory concerns while the project was still in execution. In shipbuilding, a system of record captures production costs by vessel and produces post-delivery cost analysis. A shipyard learns that a vessel lost margin—after the vessel has sailed. A system of prevention would have controlled material issues against production requirements, validated labour hours against block completion, and forecast margin erosion while production sequencing could still be adjusted. In mining, a system of record documents development costs over multi-year programmes and produces completion reports for stakeholders. A mine that cost 30% more than budget becomes a cautionary tale. A system of prevention would have tracked commitments from early works, monitored productivity against benchmarks, and escalated cost-to-complete concerns while scope and schedule adjustments remained possible. In project-based manufacturing, a system of record captures production costs for each engineered-to-order contract. A contract delivered at a loss provides margin analysis for future estimating. A system of prevention would have validated material consumption against bill of materials, tracked labour efficiency against cost recipe, and alerted to margin erosion while production methods could be adjusted. The Fundamental Tension Project-based organisations face a tension between record-keeping requirements and control requirements: External stakeholders (auditors, regulators, shareholders) need accurate historical records Internal stakeholders (project managers, executives) need forward-looking control Systems designed primarily as systems of record serve external requirements but fail internal needs. Systems designed as systems of prevention can satisfy both—providing accurate records while enabling operational control. The architecture determines which purpose is primary. Why This Concept Exists The system of prevention versus system of record distinction exists because enterprise systems must make architectural choices that favour one purpose over the other—and because project-based industries have specific requirements that record-oriented systems cannot satisfy. Different purposes require different architectures. Systems designed for record-keeping optimise for: Accuracy: Verified transactions with audit trails Completeness: All relevant transactions captured Immutability: Historical records unchanged after closing Compliance: Adherence to accounting standards and regulations Systems designed for prevention optimise for: Timeliness: Information available at decision points Forward visibility: Exposure and forecast, not just history Control enforcement: Validation before commitment Actionability: Insight that enables intervention These optimisation targets conflict. Waiting for verification ensures accuracy but delays visibility. Enforcing immutability preserves records but prevents correction. Prioritising compliance serves external requirements but may not serve operational needs. Generic ERPs prioritise record-keeping. Generic ERP systems evolved from financial accounting platforms where record-keeping is the primary purpose. The general ledger—the core of generic ERPs—is fundamentally a system of record: it captures transactions after they occur and produces reports that document history. Project modules added to generic ERPs inherit this orientation; they may provide project-coded records, but they remain record-oriented in design. Project economics require prevention. In project-based businesses, margins are determined by decisions made during execution: Which subcontractors to engage and at what price When to commit to equipment and materials How to sequence work to optimise productivity Whether to accept or challenge scope changes How to allocate resources across competing projects These decisions have economic consequences that cannot be reversed after the fact. A subcontract signed at an unfavourable rate will generate costs regardless of subsequent reporting. A scope change accepted without commercial recognition will erode margin regardless of documentation. Prevention—control at the decision point—is the only mechanism that protects project economics. Records cannot undo outcomes. The fundamental limitation of systems of record is that records cannot change what happened. A detailed cost report documenting a $2 million overrun does not recover the $2 million. A comprehensive variance analysis explaining why productivity fell short does not restore the lost labour hours. Records support learning and accountability, but they do not prevent the outcomes they document. Systems of prevention address this limitation by intervening before outcomes are determined—enforcing controls at commitment, validating progress against plan, and escalating deviation while corrective action remains possible. The audit paradox. Organisations sometimes resist systems of prevention because they fear audit implications: if the system prevents transactions, won’t auditors question what was blocked? In practice, the opposite is true. Auditors prefer organisations with effective controls because: Preventive controls reduce errors and irregularities Documented control enforcement provides audit evidence Exception handling creates clear approval trails Proactive management reduces audit findings Systems of prevention actually strengthen audit position by demonstrating effective governance. How It Works Conceptually Systems of record and systems of prevention operate through fundamentally different control mechanisms and information flows. System of Record: Capture-Store-Report A system of record follows a capture-store-report pattern: ECONOMIC EVENT │ ▼ TRANSACTION CAPTURE │ ▼ VALIDATION (format, completeness) │ ▼ STORAGE (database, ledger) │ ▼ PERIOD-END PROCESSING │ ▼ REPORT GENERATION │ ▼ REVIEW AND ANALYSIS │ ▼ (LEARNING FOR FUTURE) Characteristics: Capture occurs after the event Validation checks data quality, not business rules Storage preserves the historical record Reporting is periodic, not real-time Analysis is retrospective Action is limited to future improvements Limitations for project control: No intervention point before commitment No enforcement of budget or scope limits No forward visibility into exposure Deviation detected after cost incurred Corrective action limited to damage control System of Prevention: Validate-Control-Enable A system of prevention follows a validate-control-enable pattern: INTENTION (requisition, request, proposal) │ ▼ BUSINESS RULE VALIDATION ├── Budget availability ├── Scope alignment ├── Authority limits └── Policy compliance │ ▼ CONTROL DECISION ├── Approve → Enable transaction ├── Refer → Escalate for decision └── Reject → Block with explanation │ ▼ EXECUTION (if approved) │ ▼ COMMITMENT RECORDING │ ▼ ONGOING MONITORING │ ▼ EXCEPTION ALERTING │ ▼ FORECAST UPDATING Characteristics: Validation occurs before commitment Business rules enforce project constraints Control decisions enable or prevent transactions Commitment creates immediate visibility Monitoring is continuous Alerts enable timely intervention Advantages for project control: Intervention at decision point Budget and scope limits enforced Forward visibility from commitment Deviation detected early Corrective action while outcome is changeable The Control Point Difference The critical difference is where control is exercised: Scenario System of Record System of Prevention Over-budget purchase Recorded when invoiced; variance reported at period end Blocked at requisition; requires budget adjustment or approval Scope creep Costs accumulated; overrun documented Scope change process triggered; commercial impact assessed Productivity decline Variance calculated after fact Progress vs. plan flagged; causes investigated Subcontractor overcharge Paid and recorded; dispute initiated later Validated against contract rates; discrepancy resolved before payment Resource overallocation Costs captured across projects Availability checked at assignment; conflicts visible In each scenario, the system of record documents the problem; the system of prevention enables action to avoid or mitigate it. Enforcement Mechanisms Systems of prevention employ multiple enforcement mechanisms: Hard controls prevent transactions that violate rules: Budget exceeded: PO cannot be created Authority exceeded: Approval routed to higher level Scope undefined: Cost cannot be assigned to non-existent work package Progress exceeded: Quantities cannot exceed BoQ Soft controls alert to conditions requiring attention: Budget nearly exhausted: Warning displayed, transaction allowed Unit cost above benchmark: Alert generated, approval required Progress behind schedule: Escalation to project manager Forecast exceeds budget: Dashboard indicator, review triggered Workflow controls ensure proper process: Variations require commercial assessment before execution Progress certification requires verification before payment Budget transfers require approval before effect Change orders require scope definition before commitment Audit controls document decision-making: All control decisions logged Override reasons captured Approval chains documented Exception handling traceable The Integration with Project Control Structures Systems of prevention achieve their effectiveness through integration with project control structures: the BoQ, WBS, and cost codes. BoQ-Based Prevention The Bill of Quantities enables scope-based prevention: Quantity control: Progress cannot exceed BoQ quantities without variation Rate control: Costs can be validated against BoQ rates Scope control: Work outside BoQ triggers change management Valuation control: Payment applications validated against measured progress WBS-Based Prevention The Work Breakdown Structure enables work package-based prevention: Budget control: Commitments checked against work package budgets Assignment control: Resources assigned to defined work packages Progress control: Completion assessed at work package level Accountability: Work package owners responsible for performance Cost Code-Based Prevention Cost codes enable classification-based prevention: Rate benchmarking: Unit costs compared to cost code standards Productivity monitoring: Output rates compared to cost code templates Resource validation: Appropriate cost types charged to appropriate codes Cross-project comparison: Performance compared across projects by cost code Integrated Prevention The BoQ-WBS-Cost Code relationship enables integrated prevention: A purchase requisition is validated against BoQ scope, WBS budget, and cost code classification simultaneously Progress is measured against BoQ quantities, updated in WBS, and analysed by cost code Variations are assessed for BoQ impact, WBS budget effect, and cost code implications Forecasts integrate BoQ remaining scope, WBS work package status, and cost code performance This integration is native to project-centric ERP architecture; it cannot be achieved through post-hoc integration of record-oriented systems. Why Generic Approaches Fail Generic enterprise systems fail to provide preventive control because they are designed as systems of record with prevention features added as afterthoughts. Financial controls are not project controls. Generic ERPs provide financial controls: approval limits by amount, segregation of duties, account validity. These controls protect financial integrity but do not enforce project constraints: Budget control by account/period, not by project/work package No BoQ validation for scope control No progress-to-cost linkage No forward exposure visibility Project control requires project-specific prevention that finance-oriented controls cannot provide. Workflow is not prevention. Generic ERPs may provide workflow capability: routing transactions for approval, managing document review, tracking process status. Workflow manages process but does not enforce project constraints: Approver sees transaction but may lack project context Approval is based on amount, not project budget status Workflow does not validate against BoQ or WBS Approved transactions may still violate project constraints Workflow without project-integrated validation is process management, not prevention. Alerts are not controls. Generic ERPs may provide alerting: notifications when thresholds are exceeded, warnings when conditions occur. Alerts inform but do not prevent: Alert arrives after transaction is committed User must take separate action to respond Alert fatigue leads to ignored warnings No enforcement if alert is not actioned Prevention requires controls that enforce constraints at the transaction, not alerts that notify after the fact. Customisation cannot create architectural capability. Organisations sometimes attempt to create preventive controls in generic ERPs through customisation: Custom validation rules Custom approval workflows Custom budget checking logic Custom integration with external systems This approach fails because: Customisation is fragile and breaks with upgrades Custom controls lack integration with core system Maintenance burden grows over time Architectural limitations persist regardless of customisation Preventive control requires systems designed for prevention—not record systems customised to approximate it. Bolt-on solutions create gaps. Organisations may deploy specialised project control tools alongside generic ERPs: Estimating system for bid development Scheduling system for planning Cost control system for project tracking BoQ system for quantity management This approach creates integration challenges: Data duplication and synchronisation Reconciliation effort between systems Control gaps at system boundaries Multiple versions of truth Prevention requires integrated control across the full transaction lifecycle—difficult to achieve across system boundaries. Where It Applies ERP Evaluation and Selection. Assessing whether systems are designed for prevention or primarily for record-keeping—a fundamental architectural criterion. Process Design. Designing procurement, cost control, and change management processes that embed preventive controls at decision points. Control Framework Development. Establishing control frameworks that balance prevention (blocking/escalating) with enablement (supporting legitimate activity). Risk Management. Implementing preventive controls as risk mitigation for project cost and schedule exposure. Governance Design. Creating governance structures that use system-enforced controls rather than relying solely on manual oversight. Change Management. Transitioning organisations from record-oriented to prevention-oriented operating models. Balancing Prevention and Enablement Effective systems of prevention balance control with operational enablement. Excessive control creates friction that impedes legitimate work; insufficient control fails to prevent problems. Principles for Effective Prevention Prevention should be proportionate to risk. High-value commitments warrant more control than low-value High-risk activities warrant more control than routine Early project stages may warrant tighter control than steady-state Prevention should inform, not just block. When preventing a transaction, explain why Provide the path to legitimate completion Enable escalation for exceptions Prevention should be automated, not manual. System-enforced controls are consistent Manual controls depend on individual diligence Automation reduces burden while maintaining control Prevention should be visible and transparent. Users understand what controls apply Control logic is documented Audit trails show control decisions Prevention should support, not obstruct, legitimate work. Valid transactions should flow without unnecessary friction Control burden should not exceed control value User experience matters for adoption and compliance Control Calibration Systems of prevention can be calibrated to organisational needs: Control Level Characteristics Appropriate When Hard block Transaction prevented; no override Legal/compliance requirements; critical project constraints Soft block with override Transaction prevented; authorised override possible Important controls with legitimate exceptions Warning with continuation Alert displayed; transaction allowed Guidance; early warning; user awareness Logging only Transaction allowed; event recorded Monitoring; trend analysis; audit trail Effective systems provide flexibility to calibrate controls by transaction type, project phase, risk level, and organisational maturity. Exception Management No control system can anticipate every legitimate scenario. Systems of prevention must include exception management: Documented override capability for authorised users Escalation paths for transactions requiring higher approval Temporary relaxation for defined circumstances Post-hoc review of exception patterns Exception management enables operational flexibility while maintaining control integrity. Common Misconceptions Misconception: Systems of prevention slow down operations. Reality: Well-designed systems of prevention speed operations by eliminating rework, reducing errors, and avoiding the disruption of problems discovered late. The friction of prevention is far less than the friction of correction. Organisations that resist prevention often spend more effort managing problems than they would have spent preventing them. Misconception: Prevention systems are inflexible. Reality: Effective systems of prevention include calibrated controls, exception handling, and escalation paths. They prevent inappropriate transactions, not all transactions. The goal is intelligent control that blocks problems while enabling legitimate work. Misconception: Record-keeping systems can be made preventive through reporting. Reality: Reports inform about past events; they cannot prevent future events. A report showing yesterday’s budget overrun does not prevent tomorrow’s. Prevention requires controls embedded in transaction processing, not reports generated afterward. Misconception: Prevention is the responsibility of management, not systems. Reality: Management sets policy; systems enforce it. Relying on management attention for every transaction is unsustainable and unreliable. Systems of prevention automate policy enforcement, ensuring consistent application regardless of management bandwidth. Misconception: Prevention systems create audit issues by blocking transactions. Reality: Prevention systems strengthen audit position by demonstrating effective internal controls. Auditors prefer organisations with documented, enforced controls over those relying on manual oversight. Exception handling provides clear audit trails for non-standard transactions. Misconception: Small projects do not need systems of prevention. Reality: Small projects have less margin for error; a single over-commitment can erase project profit. Prevention is proportionately more valuable for small projects where problems cannot be absorbed. The controls may be simpler, but the principle applies equally. Misconception: Prevention is about saying “no.” Reality: Prevention is about saying “yes” to the right things and “stop and think” to questionable things. The goal is not to block activity but to ensure activity aligns with project constraints. Well-designed prevention enables good decisions, not obstruction. Related Topics What Is an Industry-Specific ERP? — Systems designed with preventive control capability. What Is Project-Centric ERP Architecture? — Architecture that enables integrated prevention. What Is Finance-Led vs. Project-Led ERP? — The architectural distinction affecting prevention capability. What Is Post-Factum Accounting? — The record-oriented approach that systems of prevention overcome. What Is Project Cost Control? — The discipline that preventive systems enable. What Is the BoQ-WBS-Cost Code Relationship? — The structural integration underlying effective prevention. What Is Risk Management in Capital Projects? — Prevention as a risk mitigation strategy. RELATED ASSETS Related Industries Construction Project-based Manufacturing Marine and Offshore Construction Mining and Quarrying Shipbuilding and Repairs RELATED ASSETS Related Stakeholders Owner/Developer E&P Owners Mine & Quarry Owner Consultants General Contractors Marine Contractor Shipbuilders Mining Contractor RELATED ASSETS Related Roles C-level Executives Project Manager Bidding Manager Cost Estimator Cost Controller Go to Previous Topic Previous Topic Return to What is? Go to Hub Go to Next Topic Next Topic