Financial Project Planning Checklist

Capture the NPV, IRR, and payback period assumptions on a one-page business case. Reference the discount rate the CFO has approved for capital projects this fiscal year — using a stale WACC is a common reason finance committee sends the request back.

For software builds, walk ASC 350-40 stages — preliminary project, application development (capitalize), post-implementation (expense). For R&D, default to ASC 730 expense unless the project meets the narrow capitalization criteria. Confirm the company's capitalization threshold (commonly $5K or $10K) applies.

Pick 3-5 KPIs the steering committee will see every month: cost variance, schedule variance, percent complete, and one or two business-outcome metrics tied to the ROI case. If you're using earned value management, define the planned-value curve up front rather than back-fitting it later.

Build the bottom-up estimate from the work-breakdown structure. Loaded labor rates should include benefits and payroll taxes, not just gross pay. Separate one-time CapEx (hardware, license fees, implementation services) from recurring OpEx (subscriptions, support contracts) so the post-go-live run-rate is visible.

Map each cost line to a GL account, cost center, and project code so actuals will tie back without manual reclasses at month-end. Hold a 10-15% contingency in a clearly labeled line — burying contingency inside category estimates is what causes the budget to silently overrun.

Send the budget package — business case, WBS estimate, contingency, monthly cash-flow profile — to the steering committee 5 business days before the review meeting. Pre-brief the CFO so the meeting surfaces real questions, not first-read reactions.

Track every committee request as a numbered change in the budget version log so the audit trail is preserved. Resubmit only after the controller and project sponsor have signed off on the revised numbers.

Cover the named categories: vendor payment risk (FX exposure if foreign-denominated), scope-creep risk, resource-availability risk, and tax/regulatory risk (sales-tax nexus on new SaaS, payroll tax on contractor reclassification). FX and contractor classification are the two most commonly missed at this stage.

For each risk, estimate probability and dollar impact. Sum the expected value (probability × impact) and compare to the contingency line. If expected risk exceeds contingency, surface that gap to the steering committee rather than burying it.

Each top-five risk gets a named owner, mitigation action, and trigger threshold. Vague "monitor closely" assignments tend to be no one's job by month two.

Map each WBS line to its owning department's cost center so chargebacks, intercompany allocations, and capitalization entries flow correctly at close. Cross-departmental projects without a clear allocation key turn into month-end reclass exercises.

Get written confirmation of named staff and committed hours per month from each department lead. Verbal commitments at planning evaporate when busy season hits and the controller pulls the senior accountant back to close.

Create the project class, dimension, or job code in QuickBooks Online, NetSuite, or Sage Intacct. Configure AP automation (Bill.com, Ramp) to require the project code on every related bill so coding doesn't fall to month-end cleanup.

Pull a weekly project-cost report from the GL on Monday for the prior week. Include committed-but-unbilled (open POs) so the burn rate isn't understated by AP timing.

Standard layout: budget, actual, variance ($ and %), forecast-at-completion, and commentary on any line over the 5% threshold. Use Fathom, Spotlight Reporting, or a Vena/Cube model — not a hand-rolled spreadsheet that breaks when the COA changes.

Send the report within 5 business days of month-end close. Pair the numbers with a 3-paragraph narrative covering top variances, cash flow status, and any risks that have materialized since the last report.

Project sponsor, controller, and project manager meet within 3 business days of close. Walk every line over the 5% threshold and tag each variance as timing, scope, rate, or estimate-error so the pattern is visible by month three.

Pull the supporting AP detail, timesheets, and PO commitments for each flagged line. A variance that can't be explained by a named transaction is usually a coding error, not a real overrun — fix the JE before escalating.

Document the cause, dollar impact, and remaining contingency. Route to the steering committee on the standard change-request form — informal email approvals will not survive an internal audit.