Definition Post-factum accounting refers to the practice of capturing, recording, and reporting costs after economic events have occurred—typically when invoices are received, payments are made, or period-end journals are posted. In post-factum systems, financial information reflects historical transactions rather than current exposure or future projections. The term “post-factum” (Latin: after the fact) describes the fundamental limitation of traditional financial accounting when applied to project control. Financial accounting is designed to produce accurate historical records for external reporting, tax compliance, and statutory purposes. It answers the question: What did we spend? It cannot answer the questions that project control requires: What are we committed to spend? What will we spend at completion? Where are we trending? In project-based businesses, post-factum accounting creates a dangerous gap between economic reality and system visibility: A purchase order commits the organisation to future payment, but post-factum systems do not recognise the commitment until invoice receipt A subcontract creates liability for work performed, but post-factum systems do not capture exposure until payment certification Productivity problems accumulate cost overruns, but post-factum systems do not reveal the trend until period-end reporting Scope changes affect project economics, but post-factum systems do not quantify impact until costs are incurred This gap between commitment and recognition, between economic event and system capture, makes post-factum accounting fundamentally inadequate for project control. By the time post-factum systems report a problem, the opportunity to prevent it has passed. Context in Project-Based Industries Post-factum accounting pervades project-based industries because most enterprise systems are designed around financial accounting principles that prioritise historical accuracy over operational visibility. In construction, post-factum accounting manifests in monthly cost reports that compare budget to actual costs incurred. A project manager reviewing the May cost report sees costs recorded through April—data that is already four to six weeks old. Purchase orders issued, subcontract work performed, and material delivered but not yet invoiced are invisible. The “actual” cost significantly understates true exposure. In marine and offshore, post-factum accounting obscures the cost position of complex, multi-location projects. Fabrication costs in one yard, installation costs offshore, and engineering costs at headquarters are captured in different periods based on invoice processing, not work performance. Consolidated project visibility lags actual execution by weeks or months. In shipbuilding, post-factum accounting disconnects cost recognition from production progress. Steel may be cut, blocks assembled, and outfitting advanced—but if supplier invoices and subcontractor certifications have not been processed, the cost system shows a misleading picture of project status. In mining, post-factum accounting is particularly damaging for multi-year development projects. Cost reports based on invoiced amounts lag actual project progress by months. Equipment mobilisation, site establishment, and early works may be substantially complete before costs appear in financial systems. In project-based manufacturing, post-factum accounting cannot support production cost control for engineered-to-order contracts. Material consumed, labour expended, and machine time used must be captured as production occurs—not when accounting processes catch up. The Timing Gap The core problem of post-factum accounting is timing. Consider the lifecycle of a typical project cost: Stage Economic Event Post-Factum Recognition Requisition Need identified Not captured Purchase Order Commitment made Not captured (or captured without project integration) Delivery Material received Goods receipt (partial recognition) Work Performed Value created/consumed Not captured until certified Invoice Received Supplier claim AP entry created Invoice Approved Liability confirmed Cost recognised Payment Cash disbursed Payment recorded In this timeline, the economic commitment occurs at purchase order, but post-factum recognition occurs at invoice approval—potentially weeks or months later. The gap between stages 2 and 6 represents exposure that post-factum systems do not see. For project control, this gap is critical. A project may have committed 80% of its budget through purchase orders and subcontracts, but post-factum systems show only 50% spent because invoices are still in process. The project manager believes budget remains available; in reality, the project is nearly fully committed. Why This Concept Exists Post-factum accounting exists because financial accounting systems serve different purposes than project control systems—and confusing these purposes creates the control gap that undermines project performance. Financial accounting serves external stakeholders. Financial accounting produces statements for shareholders, creditors, tax authorities, and regulators. These stakeholders require: Accuracy: Transactions verified and documented Completeness: All relevant transactions included Consistency: Comparable across periods and entities Compliance: Adherence to accounting standards (IFRS, GAAP) Post-factum recognition supports these requirements. Waiting for invoices ensures transactions are verified. Period-end closing ensures completeness. Standard accounting treatments ensure consistency. Audit trails ensure compliance. Project control serves internal stakeholders. Project control provides information for project managers, cost controllers, and executives making operational decisions. These stakeholders require: Timeliness: Information available when decisions must be made Completeness of exposure: All commitments visible, not just processed transactions Forward-looking visibility: Projected outcomes, not just historical results Actionable insight: Understanding of causes and options, not just variances Post-factum accounting cannot satisfy these requirements because it prioritises accuracy over timeliness and historical completeness over forward visibility. Generic ERPs embed financial accounting logic. Generic ERP systems—designed for manufacturing, retail, and service businesses—embed financial accounting logic in their core architecture. The general ledger is the system of record; all modules feed the GL with verified transactions. This finance-led architecture serves financial reporting excellently but cannot provide the forward-looking visibility that project control requires. Project-based industries adopted generic systems. As project-based organisations sought enterprise systems, they adopted generic ERPs—often driven by corporate standardisation mandates or Tier-1 vendor marketing. These systems provided financial accounting capability but forced project control into post-factum frameworks unsuited to project economics. The gap persists despite “project modules.” Generic ERP vendors added project modules to address construction and engineering markets. These modules provide project coding, project budgets, and project reports—but they operate within the post-factum framework of the financial core. Project costs are still recognised when invoices are processed; commitments are still invisible until payment; forecasting is still based on historical trends rather than forward exposure. Post-factum accounting exists because financial accounting and project control have different requirements—and generic enterprise systems prioritised financial accounting. How It Works Conceptually Post-factum accounting operates through transaction recognition rules that delay visibility until after economic events have occurred. The Post-Factum Recognition Process In a post-factum system, project costs follow this recognition path: ECONOMIC EVENT SYSTEM RECOGNITION │ │ ▼ │ Purchase Order Issued ─────────────────► (Not recognised or commitment only) │ │ ▼ │ Material Delivered ────────────────────► Goods Receipt (inventory, not cost) │ │ ▼ │ Work Performed ────────────────────────► (Not recognised) │ │ ▼ │ Invoice Received ──────────────────────► AP Entry (payable, not project cost) │ │ ▼ │ Invoice Matched & Approved ────────────► PROJECT COST RECOGNISED │ │ ▼ │ Payment Made ──────────────────────────► Cash disbursement The critical point is that project cost recognition occurs at invoice match/approval—not at commitment, delivery, or work performance. The time between economic event and system recognition creates the control gap. The Control Gap in Practice Consider a concrete example: Week 1: Project manager issues purchase order for $100,000 of structural steel Economic commitment: $100,000 Post-factum system shows: $0 Week 4: Steel delivered to site Material on site, ready for installation Post-factum system shows: $0 (or goods receipt in inventory, not project cost) Week 6: Fabrication and erection completed Value installed in project Post-factum system shows: $0 Week 8: Supplier invoice received Invoice enters AP processing Post-factum system shows: $0 (invoice in queue, not approved) Week 10: Invoice approved and matched Cost finally recognised Post-factum system shows: $100,000 For ten weeks, the project carried $100,000 of exposure that the cost system did not reflect. A project manager relying on post-factum reports would have seen available budget that was actually committed. Decisions made during this period—additional purchases, resource allocation, forecast adjustments—would have been based on incorrect data. Cumulative Impact The problem compounds across multiple transactions: Transaction Commitment Date Recognition Date Gap Steel PO Week 1 Week 10 9 weeks Concrete subcontract Week 2 Week 14 12 weeks MEP equipment Week 3 Week 16 13 weeks Façade subcontract Week 5 Week 20 15 weeks Electrical materials Week 6 Week 18 12 weeks At any point, the post-factum cost report understates true project exposure by the sum of all unrecognised commitments. For an active project with continuous procurement, this understatement can represent 20-40% of total project value. Period-End Distortions Post-factum accounting creates period-end distortions: Month 1: Few invoices processed; costs appear low Month 2: Invoices from Month 1 arrive; costs spike Month 3: Backlog clears; costs appear to normalise These fluctuations reflect invoice processing timing, not project performance. A project manager seeing Month 1 costs might believe the project is under budget; Month 2 costs might suggest a crisis. Neither reflects actual project trajectory. The Forecast Problem Post-factum systems cannot support reliable forecasting because they lack: Commitment data: What have we contractually agreed to pay? Exposure data: What is our total potential liability? Productivity data: How are we performing against planned rates? Quantity data: How does installed quantity compare to planned? Forecasts based on post-factum data extrapolate historical spend patterns—a method that assumes future costs will follow past patterns. This assumption fails when: Commitments already made will drive costs regardless of past patterns Productivity is changing (improving or deteriorating) Scope changes are in process Market conditions are shifting Post-factum forecasting is inherently unreliable because it lacks the forward-looking data that reliable forecasting requires. The Organisational Impact The choice between finance-led and project-led ERP has profound organisational consequences beyond system functionality. Decision-Making Authority Finance-led organisations centralise control in finance: Finance approves budgets and monitors spending Project managers request funds from finance Financial periods drive planning and reporting cycles Cost centre managers have authority; project managers coordinate Project-led organisations distribute control to projects: Project managers have delegated budget authority Finance provides governance and consolidated reporting Project lifecycle drives planning and reporting Project managers are accountable; finance enables Information Flow Finance-led information flow: Project teams capture data for finance to report Monthly close produces project information Project visibility lags transaction activity Project managers receive information; finance controls it Project-led information flow: Project teams own and use project data Real-time visibility into project status Project activity drives financial reporting Project managers control information; finance consolidates it Performance Culture Finance-led performance culture: Success measured by period financial results Project performance subordinate to financial targets Cost reduction emphasised over value delivery Short-term financial focus may compromise project outcomes Project-led performance culture: Success measured by project outcomes Financial results derive from project performance Value delivery emphasised alongside cost control Project-lifecycle focus aligns with business reality Talent and Career Development Finance-led organisations: Career paths follow functional hierarchies Finance roles have organisational prominence Project management seen as coordination function Technical and project talent may be undervalued Project-led organisations: Career paths include project leadership track Project roles have organisational prominence Project management recognised as core competency Technical and project talent attracted and retained Why Generic Approaches Fail Generic enterprise systems and standard accounting practices fail to address post-factum limitations because they are designed for different purposes. Financial accounting standards require post-factum recognition. Accounting standards (IFRS, GAAP) specify when costs should be recognised for financial reporting. These standards generally require: Invoice or equivalent documentation Verification of receipt/performance Matching of cost to revenue period These requirements exist to ensure financial statement accuracy—a legitimate objective for external reporting. But they make financial accounting systems structurally incapable of providing the forward visibility that project control needs. Generic ERPs enforce financial accounting logic. Generic ERPs are built on financial accounting foundations. The general ledger is the core; all other modules feed verified transactions to the GL. Even when “commitment” features exist, they often: Operate separately from project cost reporting Lack integration with BoQ, WBS, and cost codes Do not support project-specific budget control Cannot drive forecasting calculations The architecture enforces post-factum recognition regardless of project requirements. “Accrual” processes are manual workarounds. Some organisations attempt to address post-factum limitations through month-end accruals: Estimate uninvoiced costs Create manual journal entries Reverse in following period This approach has significant limitations: Estimates may be inaccurate Manual process is labour-intensive Accruals are aggregate, lacking detail No integration with procurement/commitment data Timing still lags (month-end versus real-time) Accruals are accounting adjustments, not project control solutions. Spreadsheet tracking is fragmented. Many project organisations maintain spreadsheet commitment registers outside the ERP: Track POs and subcontracts manually Calculate committed plus actual Reconcile periodically with ERP This approach creates: Dual data entry and maintenance Reconciliation effort and errors Version control challenges Loss of integration and traceability Risk of spreadsheet errors affecting decisions Spreadsheets compensate for ERP limitations but do not solve the underlying architecture problem. Integration cannot bridge the gap. Integrating commitment tracking tools with post-factum ERPs creates: Data synchronisation challenges Multiple versions of truth Reconciliation requirements Audit trail gaps The fundamental problem—financial accounting architecture—persists regardless of integration. The Alternative: Forward-Looking Project Control The alternative to post-factum accounting is forward-looking project control—systems and processes designed to provide visibility into future outcomes, not just historical transactions. Commitment-Based Cost Control Forward-looking systems recognise costs at commitment: Purchase Order Issued ──────────────────► COMMITMENT RECOGNISED │ ├── Project budget charged │ ├── Remaining budget reduced │ └── Forecast updated ▼ Invoice Received ──────────────────────► Commitment converted to actual │ ├── No budget impact (already recognised) │ └── Commitment balance reduced ▼ Payment Made ──────────────────────────► Cash disbursement only In this model, the project cost system reflects economic reality from commitment—not from invoice processing. Components of Forward-Looking Control Component Post-Factum Approach Forward-Looking Approach Budget tracking Budget vs. actual invoiced Budget vs. committed + actual Exposure visibility Costs recorded Committed + actual + pending Remaining budget Budget minus actual Budget minus committed Forecast basis Historical spend trends Committed + ETC for remaining scope Variance timing Detected at period-end Detected at commitment Corrective action After cost incurred Before commitment finalised The Five-Box Model Forward-looking project control uses a five-box cost model: ┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐ │ BUDGET │ COMMITTED │ ACTUAL │ ETC │ EAC │ │ │ │ │ │ │ │ Original │ POs and │ Invoiced │ Estimate │ Forecast │ │ approved │ contracts │ and paid │ to │ at │ │ budget │ issued │ costs │ complete │ completion │ └─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘ Budget: Approved project budget (baseline and current) Committed: Value of issued POs, subcontracts, and commitments Actual: Invoiced and paid costs ETC (Estimate to Complete): Forecast cost to complete remaining scope EAC (Estimate at Completion): Committed + Actual + ETC This model provides complete visibility: what was planned, what is committed, what is spent, what remains, and what the project will cost. Variance Detection Timing Forward-looking control detects variance earlier: Scenario Post-Factum Detection Forward-Looking Detection Over-budget PO Invoice approval (weeks/months later) PO creation (immediately) Productivity decline Period-end cost variance Progress vs. plan comparison (real-time) Scope increase Costs incurred Variation identified (before commitment) Rate increase Invoice processing Commitment comparison to estimate Earlier detection enables earlier intervention—the fundamental advantage of forward-looking control. Integration with Project Structures Forward-looking control integrates with project control structures: BoQ: Commitment and cost by BoQ item WBS: Commitment and cost by work package Cost codes: Commitment and cost by classification Progress: Earned value versus committed and actual This integration, enabled by project-centric architecture, provides the diagnostic capability that post-factum systems lack. Where It Applies Project Cost Control. Understanding post-factum limitations is essential for designing effective cost control processes that provide forward visibility. ERP Evaluation and Selection. Assessing whether systems provide commitment-based control or rely on post-factum recognition is a critical evaluation criterion. Process Design. Designing procurement, subcontract, and cost control processes that capture commitments and provide forward visibility. Reporting and Dashboards. Creating management reports that show committed, actual, and forecast—not just actual versus budget. Forecasting Methodology. Developing forecasting approaches based on commitment and remaining scope rather than historical trend extrapolation. Organisational Capability. Building cost control capability that goes beyond accounting to provide operational project control. Common Misconceptions Misconception: Post-factum accounting is required by accounting standards. Reality: Accounting standards govern external financial reporting, not internal project control. Organisations can maintain compliant financial accounts while operating forward-looking project control systems. The two serve different purposes and can coexist—project-led ERPs produce compliant financial statements while providing forward-looking project visibility. Misconception: Accrual accounting solves the post-factum problem. Reality: Accrual accounting improves matching of costs to revenue periods but does not provide forward-looking visibility. Accruals are still based on historical transactions (what happened); they do not capture commitments or forecast outcomes. Accrual accounting is a financial reporting improvement, not a project control solution. Misconception: Commitment tracking is too much administrative burden. Reality: In modern project-centric ERPs, commitment tracking is automatic—purchase orders and subcontracts create commitments as part of standard workflow. The burden is not in tracking commitments but in failing to track them: manual reconciliation, spreadsheet maintenance, and decision-making without complete information. Misconception: Project managers can estimate commitments without system support. Reality: Project managers may have general awareness of outstanding commitments, but accurate commitment tracking requires systematic capture at transaction level. Mental estimates are incomplete, inconsistent, and unavailable to others who need the information. System-based commitment tracking provides reliable, auditable, shareable data. Misconception: Post-factum reporting is accurate; forward-looking data is just estimates. Reality: Post-factum reporting is accurate about what it captures—invoiced costs—but inaccurate about project exposure because it omits commitments. Forward-looking data includes estimates (ETC), but also includes factual data (commitments) that post-factum reporting ignores. A complete picture requires both historical actuals and forward commitments. Misconception: Small projects do not need forward-looking control. Reality: Small projects may have shorter cycles and fewer transactions, but the post-factum problem persists. A small project can be fully committed (over budget) while post-factum reports show budget remaining. Project size does not eliminate the need for forward visibility—it may simply compress the timeline over which problems emerge. Misconception: Only financial staff care about this distinction. Reality: Post-factum versus forward-looking control directly affects project managers, who make resource and procurement decisions based on available information. If that information is incomplete (missing commitments), decisions will be flawed. Project managers are the primary victims of post-factum limitations—and the primary beneficiaries of forward-looking control. Related Topics What Is an Industry-Specific ERP? — Systems designed to overcome post-factum limitations. What Is Project-Centric ERP Architecture? — Architecture that enables forward-looking control. What Is Finance-Led vs. Project-Led ERP? — The architectural distinction underlying post-factum limitations. What Is a System of Prevention vs. a System of Record? — The control philosophy that forward-looking systems enable. What Is Project Cost Control? — The discipline that requires forward-looking visibility. What Is Earned Value Management? — Performance measurement methodology requiring integrated cost and progress data. What Is the BoQ-WBS-Cost Code Relationship? — The structural integration that enables diagnostic cost analysis. 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