Real Estate Development Accounting That Survives the Draw Request

Three facts drive everything about development accounting. First, nearly every dollar you spend is not an expense; it is the cost of an asset you are building. The tax rules require it, lenders demand it, and per-unit profit math is impossible without it. Second, your primary financial statement is the balance sheet, because until units close, the project only exists there. Third, three outside parties read your books every month: the construction lender, your equity investors, and eventually the IRS, and all three expect the same numbers to tie.

This is a different problem than rental bookkeeping, where the job is a clean monthly P&L per property. Our real estate bookkeeping page covers the portfolio-level system for holds; this page covers the build. Plenty of clients do both, and the books have to keep them separate, because a rental expense and a development cost that look identical on a credit card statement get opposite treatment.

The practical consequence: when a developer brings us books where rehab labor, permit fees, and loan interest were all expensed to keep the bookkeeper's life simple, the cleanup is not cosmetic. Every misposted cost understates the project's basis, overstates old losses, and sets up a gross profit number at closing that is wrong in the direction the IRS cares about. If your books are in that state, our catch-up bookkeeping service rebuilds the cost records before the next return, not after.

A developer's chart of accounts looks nothing like the default template in any accounting software. The spine of it is a set of WIP asset accounts, sub-coded by project, plus the liabilities that construction lending creates. Here is the core structure we set up, and the reason each account earns its place:

Below these accounts sits a cost-code layer: sitework, foundation, framing, mechanical, finishes, and so on, matched to your construction budget divisions. The chart of accounts stays lean; the cost codes carry the detail. That separation is what lets one system produce a two-page financial statement for the investor and a forty-line budget-versus-actual for the site meeting. The general logic of building account structures that match how you actually operate is covered in our chart of accounts guide; development is simply the most demanding version of it.

Development reporting has three audiences, and a good monthly package serves all of them from one set of books. Ours contains, per project:

• Budget versus actual by cost division, with committed costs (signed contracts not yet billed) shown next to incurred costs, because the overrun you can still prevent lives in the committed column.
• WIP summary: total budget, cost to date, percent complete on a cost basis, and estimated cost to complete.
• Draw and loan reconciliation: draws to date, retainage held, loan balance per the lender, and remaining loan availability against remaining budget.
• Cash position and 60-day need: what is in the project account and what the next two months of the schedule will consume, so capital calls never arrive as surprises.

At the company level, the package adds a balance sheet for each entity, the intercompany reconciliation, and the development company's own P&L showing fee income against overhead. When a project sells, the package closes the loop with a per-unit gross margin report: sale price, released WIP cost, selling costs, and actual margin against the pro forma. Sponsors raising money for the next deal find that report is worth more than any pitch deck chart, because it is real.

Developers drown in numbers during a build. These are the six we compute monthly because each one changes a decision:

The pattern across all six: they compare the books to the plan, not just to last month. A development project rarely fails in one bad month. It fails by drifting 2% a month for a year while nobody reconciled committed costs. The KPI page in the monthly package exists to make drift visible at month two instead of month twelve.

The standard development structure is one LLC per project, a development company that earns fees for running the deals, and often a holding company above both. The books have to mirror that structure exactly: each entity gets its own complete set of books, its own bank account, and its own balance sheet. The moment two projects share a checking account, every lender draw, investor report, and tax return downstream inherits the mess.

Two flows deserve special care. First, equity tracking: each investor's contributions, preferred return accruals, and distributions get tracked by member from day one, so the waterfall at exit is arithmetic instead of archaeology. If your capital comes from outside investors, this is the same member-ledger discipline we describe in our syndication tax guide, applied at the project level. Second, intercompany transfers: when the dev company covers a project invoice, or a project reimburses shared payroll, the transfer hits the due-to/due-from accounts both ways, every time. Those accounts must net to zero across the group monthly.

Our development close runs the same sequence every month, per project:

1. Reconcile every bank and loan account, including the construction loan balance to the lender statement.
2. Post all invoices and pay applications to WIP by cost code, with committed-cost updates from new contracts and change orders.
3. Record retainage payable on every pay application that withheld it.
4. Compute and post capitalized interest, property taxes, and insurance for the production period.
5. Reconcile draws: WIP additions vs draw requests vs loan advances, investigating any gap over a set threshold.
6. Post intercompany activity both directions and confirm due-to/due-from accounts net to zero across the group.
7. Update the WIP schedule: percent complete, cost to complete, and budget variance by division.
8. Issue the reporting package, with a short narrative on anything that moved more than the threshold.

In a sale month, the close adds the closing-statement entries: revenue by unit, WIP released to cost of units sold, loan payoff, deposit application, and commission and closing costs. The closing statement from the title company is booked line by line, never as one lump deposit, because that one lazy entry is the difference between books that prove your gain and books that just assert it.

For developers up to roughly a half-dozen concurrent projects, QuickBooks Online run correctly beats a heavyweight construction ERP. The configuration that makes it work: one QBO file per entity, projects or classes for each development, and the item list doubling as the cost-code layer so every transaction lands in a budget division. Budgets load per project, which turns budget-versus-actual into a built-in report instead of a monthly spreadsheet.

Around QBO we run a document workflow, because development accounting is evidence management: every pay application, invoice, change order, and conditional lien waiver gets captured digitally and attached to its transaction. When the lender's inspector or a future auditor asks what is in draw seven, the answer is an attachment, not a filing cabinet. Bill-pay tooling adds approval routing, so a superintendent can approve a sub's invoice from the site before it ever hits the books.

What we deliberately do not do is run project management costs in one system and accounting in another without a reconciliation. If you use construction management software for scheduling and budgets, fine; its cost data and the books get tied monthly, or the two systems will confidently tell you two different numbers by spring.

The whole point of the structure above is that tax season becomes an export, not an excavation. Clean development books hand the tax side four things:

• Per-project cost basis, fully documented, including the capitalized interest and carry the uniform capitalization rules require.
• Method-of-accounting inputs: contract-by-contract detail that lets your CPA apply the right method, since long-term construction contracts generally require percentage-of-completion while home construction contracts are exempt from it.
• Entity-by-entity financials with intercompany accounts at zero, ready for each partnership return and K-1 package.
• Dead-deal documentation: capitalized pursuit costs of abandoned projects, segregated and supportable, for the year they become deductible.

What the books do not decide is strategy: dealer versus investor status, entity segregation between flip and hold activity, and how sale profits get taxed are planning questions with real dollars attached. That side of the ledger lives on our tax planning for real estate developers page, and, for exit-side rate questions, our capital gains tax guide. The books' job is to make every one of those strategies executable with numbers you can defend.

Our development accounting engagements fit builders and sponsors with one to roughly six concurrent projects: spec builders, small subdivision developers, build-to-rent operators, and value-add sponsors whose renovations are heavy enough to need real WIP tracking. The engagement is monthly and includes the close, the reporting package, draw support, and a CPA on the other end of the phone when the lender asks a question the bookkeeper cannot answer.

It is probably not a fit if you are a general contractor building on other people's land (that is contractor accounting, a cousin but not the same animal), or if the project is a single personal build with no investors and no construction loan. And if your situation is rentals plus one flip, start with real estate bookkeeping and our fix and flip accounting page instead; the development machinery above would be overkill.

For pricing intuition before you talk to anyone, the bookkeeping cost calculator gives a range based on entities, transaction volume, and cleanup needs. Then the free initial consultation puts a real quote on your actual structure. We serve 1,000+ clients nationwide, and developer books are a core part of the real estate practice, not a sideline.