Cost ledger → project master reconciliation + Ind AS 115 revenue recognition — project job cost tracking software that closes the WIP schedule in under 60 seconds per period.
| Project Code | Project Name | Cost Category | Budget (Rs) | Cost to Date (Rs) | % Complete |
|---|---|---|---|---|---|
| PRJ-2025-018 | Bengaluru Metro Phase 2 | Labour | 75,00,000 | 45,00,000 | 60 |
| PRJ-2025-018 | Bengaluru Metro Phase 2 | Subcontractor | 50,00,000 | 30,00,000 | 60 |
| PRJ-2025-022 | Hyderabad Tower Fit-Out | Materials | 80,00,000 | 98,00,000 | 95 |
| PRJ-2025-031 | Pune ERP Rollout | Design & Engg. | 30,00,000 | 18,00,000 | 115 |
For engineering, construction, and professional services firms, month-end project job cost tracking is a multi-day manual exercise that compounds in complexity with every active job added to the portfolio.
A finance team managing 50–200 active jobs must pull cost postings from the ERP by project code, reconcile them against approved budgets, estimate percentage-of-completion, and compute WIP balances — all before the ledger closes. Without a dedicated project accounting module, this work runs in spreadsheets and routinely consumes three to five working days per month.
The project cost ledger (labour, material, subcontractor, overhead by project code) and the project master (contract value, billing milestones, billed-to-date, status) are maintained by different teams. A project code present in the cost ledger but absent from the project master means the WIP schedule is understated — and the error may not surface until a statutory auditor reviews workpapers months later.
Percentage-of-completion values originate with project managers and are entered into spreadsheets without any cross-check against the underlying cost-to-budget ratio. A project manager who reports 95% completion while costs have already exceeded the budget by 22% will have overstated recognised revenue under Ind AS 115, paragraph B19 — a misstatement that compounds if the pattern repeats across multiple jobs.
An active project with no cost posting in 75 days likely reflects a stalled job that should be placed on hold. Positive WIP balances not invoiced within 90 days expose the firm to collection risk and may require provisioning under the firm's credit policy. Manual reviews catch these exceptions inconsistently — if at all — when working across 100–200 active project codes in a spreadsheet each period.
The typical manual close cycle for a mid-market engineering firm managing 80–150 active project codes without a dedicated project job cost tracking module. Per-period cost: 60–90 controller hours, plus the audit remediation time when misstatements surface. Under SA 240 (Auditor's Responsibilities Relating to Fraud), a material WIP overstatement that traces to undetected input errors in the completion-estimate process creates a finding the statutory auditor must report.
Project WIP accounting sits at the intersection of revenue recognition, audit documentation, and fraud-risk standards. Four regulatory anchors govern the minimum obligations for Indian entities managing long-duration contracts.
For contracts where the customer simultaneously receives and consumes the benefit of performance, revenue must be recognised over time using the input method — costs incurred to date as a proportion of total estimated costs. Recognised revenue = percent-complete × contract value, and the WIP balance equals cost-to-date + recognised profit − billings to date. A positive WIP balance is a contract asset (Ind AS 115, para 107); a negative balance is a contract liability. Every active project requires a fresh computation at each reporting date.
SA 240 (The Auditor’s Responsibilities Relating to Fraud) identifies management’s override of internal controls in revenue recognition as a significant fraud risk area. Completion-estimate manipulation — entering a percent-complete figure that overstates progress relative to cost data — is the most common mechanism for inflating revenue on long-duration contracts. Auditors are required to treat revenue recognition as a presumed fraud risk area and to design procedures specifically to test the reasonableness of completion estimates.
SA 705 (Modifications to the Opinion in the Independent Auditor’s Report) requires a qualified or adverse opinion where a material misstatement exists and management has not corrected it. A WIP schedule where percent-complete values are unvalidated against cost data, or where orphaned project codes create an incomplete schedule, constitutes a material misstatement risk. For listed entities or those subject to bank covenant reporting, a qualified audit opinion triggers immediate downstream consequences with lenders and regulators.
SA 230 (Audit Documentation) requires audit working papers to be sufficiently detailed to enable an experienced auditor to understand the work performed, the evidence obtained, and the conclusions reached. For WIP schedules, this means documenting the source data (cost ledger, project master), the reconciliation rules applied, and the specific values that triggered or passed each validation check. An undocumented manual spreadsheet process typically cannot satisfy this standard without significant supplemental explanation.
For US GAAP reporters, the same input-method logic under ASC 606-10-55-20 applies to long-duration service and construction contracts, with contract assets (unbilled receivables) and contract liabilities (deferred revenue) reported on the balance sheet per ASC 606-10-45-3. The 15-percentage-point consistency tolerance embedded in this workflow reflects the common internal control checkpoint cited by construction sector auditors in both Indian and US audit guidance.
Seven deterministic passes from raw Cost Ledger and Project Master uploads to a complete WIP schedule, P&L roll-up, and exception queue — in under 60 seconds per reporting period, with every figure traceable to the source row.
Accepts Excel uploads for the Cost Ledger (columns: project code, project name, cost category, budget amount, cost-to-date, last posting date, % complete) and the Project Master (columns: project code, contract value, billed-to-date, last invoice date, status). Cadel identifies each file type automatically — no manual tagging or template reformatting required — and validates that both carry at least one data row before any computation begins.
For each project code in the Cost Ledger, Cadel performs a lookup against the Project Master. Any code present in only one file is flagged immediately as an orphaned record and surfaced in the exception queue. Orphaned codes are excluded from the WIP schedule until a matching entry is supplied — preventing a silent understatement of the project portfolio in the P&L roll-up.
Cadel validates that every percent_complete value in the Cost Ledger falls within the valid range of 0–100. Any value outside this range — such as 115% for a data-entry error — triggers a hard Percent Complete Range exception that blocks revenue recognition for that project and routes it to the exception queue pending manual correction before WIP is posted to the general ledger.
For all clean-matched projects, Cadel computes recognised revenue using the Ind AS 115 input method: recognised_revenue = percent_complete × contract_value, and the WIP balance: wip = cost_to_date + recognised_profit − billed_to_date. Positive balances are classified as contract assets (under-billed); negative balances as contract liabilities (over-billed). Both positions are reported separately in the WIP schedule output.
Cadel checks whether cost_to_date exceeds budget_amount for each project across all cost categories. Any overrun is quantified in rupees and flagged with a Budget Not Breached exception. For example, a project with Rs 98 lakh cost against an Rs 80 lakh budget surfaces a Rs 18 lakh overrun flag in the exception queue before any recognition is computed, giving the controller specific evidence for a revised cost-to-complete estimate.
Where the absolute difference between the reported percent_complete and the implied cost-to-budget ratio exceeds 15 percentage points, Cadel flags the project for an unreliable completion estimate and surfaces it in the exception queue. This is the standard internal control checkpoint used by construction sector auditors under SA 240 to identify manager-reported completion values that do not track the underlying cost data.
Cadel applies two aging checks on every run: a stale-posting flag for any ACTIVE project whose last posting date is more than 60 days prior to the run date (signalling a stalled job that may need status change), and an unbilled WIP aging flag for any project whose last invoice date is more than 90 days prior to the run date and which carries a positive WIP balance. Both flags include the rupee exposure quantified, giving the controller a prioritised collection list alongside the WIP schedule.
A battery of synthetic test scenarios that exercise every exception class seen in real-world project accounting data. Each scenario is seeded in the sample files and produces a deterministic outcome an auditor or controller can verify in seconds.
The workflow ships with two seeded files for Feb-2026 — 231 cost ledger rows across 55 projects and a matching project master with 55 records. The majority of projects reconcile cleanly end-to-end; a planted minority exercises every exception class so every check fires at least once.
One ledger for Feb-2026 with one row per project code + cost category (Labour, Materials, Subcontractor, Plant & Equipment, Site Overheads, Design & Engineering). Seeded exceptions include budget overruns, out-of-range percent-complete (e.g. 115%), percent-complete vs cost gaps beyond 15pp, stale postings, and ledger-only project codes absent from the master.
One master for Feb-2026 with contract value, billed-to-date, last invoice date, and status. Shares project codes with the cost ledger so most projects reconcile end-to-end; planted breaks include master-only codes with no ledger postings and unbilled-WIP jobs whose last invoice is more than 90 days old against a positive WIP balance.
For the clean majority: primary record matching confirmed on project code, budget not breached, percent-complete inside 0–100, recognised revenue computed under the Ind AS 115 input method, and WIP balance classified as asset or liability. The WIP schedule exports to Excel with one row per project code.
Each exception surfaces in the queue with the rule name, the specific field values that triggered it, and the quantified rupee impact. The most operationally significant is the percent-complete vs. cost consistency mismatch — it catches manager-reported completion values that overstate progress relative to cost data before any number reaches the general ledger.
Before automation, a controller managing 80–150 active projects would spend three to five working days each close cycle extracting cost data, building WIP schedules in Excel, and manually hunting for budget overruns and stale jobs. This workflow reduces that cycle to under 60 seconds of compute time after file upload — and catches four distinct exception classes deterministically on every run.
The percent-complete vs. cost consistency check catches manager-reported completion values that overstate progress relative to cost data — the most common mechanism for inflating WIP revenue on long-duration contracts. Surfacing this as a named, quantified flag before any journal entry is posted removes the largest source of last-minute reversals at period close and directly addresses the SA 240 presumed fraud risk area in revenue recognition.
The WIP schedule exports to Excel with one row per project code showing cost-to-date, percent-complete, recognised revenue, WIP balance, and over/under-billing classification — format-compatible with the standard WIP schedule format referenced in ICAI guidance on construction contracts and acceptable as a supporting schedule in statutory audit workpapers under SA 230 documentation standards.
The unbilled WIP aging check identifies receivable balances that have not been invoiced within the standard 90-day credit cycle, giving the billing team a prioritised collection list before the close. Stale-posting flags prompt immediate follow-up on dormant jobs whose continued ACTIVE status inflates the reported project portfolio and may mask cost deferrals that should have been recognised in an earlier period.
The questions project accountants, finance controllers, and statutory auditors ask before deploying automated WIP tracking.
Two files for the same period — the Cost Ledger (project code, cost category, budget, cost-to-date, last posting, % complete) and the Project Master (project code, contract value, billed-to-date, last invoice, status). Cadel classifies each automatically and reconciles them on Project Code, so you can drop both together.
The workflow applies the input method under Ind AS 115, Revenue from Contracts with Customers (paragraphs 39–45), using costs incurred to date as a proportion of total estimated contract costs to measure progress toward complete satisfaction of a performance obligation. For entities reporting under US GAAP, the same input-method logic maps directly to ASC 606-10-55-20. The workflow does not use the output method (milestones, surveys of performance) unless the project master is configured with milestone-based billing schedules.
The WIP balance for each project is computed as: WIP = Cost Incurred + Recognised Profit − Billings to Date. A positive WIP balance represents an asset (unbilled receivable / contract asset under Ind AS 115 paragraph 107); a negative balance represents a liability (excess billings / contract liability). Both positions are reported separately in the WIP schedule output — over-billed jobs are never netted against under-billed ones — and the over-billing amount is flagged in the exception queue when the negative balance exceeds a configurable threshold.
Each project runs through the workflow’s own checks. Budget Not Breached and Percent Complete Range are hard FAILs that block recognition; Project Code Match flags orphaned codes present in only one file; Stale Posting (active job, no posting > 60 days), Unbilled WIP Aging (unbilled > 90 days), and Percent-Complete vs Cost Consistency (> 15pp gap) are WARNINGs. Open the Exceptions tab and click any row to drill into the source document and see the specific field values that triggered the flag.
The workflow ingests data through two standard Excel templates — the Project Cost Ledger and the Project Master — which can be exported from any ERP or project management system, including Tally Prime, SAP Business One, Oracle NetSuite, Zoho Projects, and Microsoft Project. No API connector is required at the ingestion stage; the column mapping is validated on upload, and mismatched headers are surfaced before processing begins.
Yes. The Cost Ledger carries one row per cost category, and the workflow aggregates budget_amount and cost_to_date at the Project Code level for the WIP and P&L roll-up purposes, while also preserving the category breakdown in the detailed output. That lets a project manager see exactly which cost type — Labour, Subcontractor, Materials, or Site Overheads — is driving a budget overrun. There is no limit on the number of cost categories per project code.
Every reconciliation run generates an immutable, timestamped record of the input files (hash-verified), the rule set applied, and each check result — including the specific field values that triggered a mismatch. The WIP schedule and exception queue are exportable to Excel for attachment to month-end workpapers. This trail supports compliance with ICAI SA 230 (Audit Documentation) requirements that working papers be sufficiently detailed to enable an experienced auditor to understand the work performed, evidence obtained, and conclusions reached.
The current workflow processes all amounts in a single functional currency (Indian Rupees by default). For projects with foreign-currency cost components, the expectation is that FX translation to the functional currency is completed in the source ERP before the cost ledger is exported — consistent with Ind AS 21, The Effects of Changes in Foreign Exchange Rates, which requires transaction-date rates for cost recognition. Multi-currency cost ledger support with embedded spot-rate translation is on the product roadmap. For US GAAP reporters, the equivalent standard is ASC 830, Foreign Currency Matters.
