How to build reliable financial reporting for real estate development

Carrying cost is a business category, not an instruction to expense. Under US GAAP, eligibility for capitalization depends on the cost, the property’s intended use, and whether qualifying preparation or development is in progress. Interest has its own capitalization criteria. The expense treatment above is an explicit assumption for the completed property, not a rule for every development project. The relevant guidance includes ASC 970-340 and ASC 835-20; SEC staff correspondence on development-cost capitalization illustrates the need to explain that judgment.

The $100,000 of capitalized development in this example includes eligible construction-period interest. Owners contribute $150,000 at acquisition and a further $140,000 before the sale. The cost comparison assumes matching project and entity attribution, complete history, and no other movements. Monthly ending balances must not be added together.

At the sale, costs move from the Balance Sheet into expense. The report needs to retain their history so the same investment is counted once and its contribution to profit stays understandable. The intended reading order is simple: recorded sale revenue, acquisition cost released to cost of goods sold, other recognized project costs, and the resulting profit. PipeLedger uses recorded revenue, not a sale price inferred from a closing document; a ledger that records only a net gain needs review before the report can show gross proceeds and acquisition cost separately.

These simplified entry patterns explain the reporting relationship. The accountant determines recognition dates, eligible costs, and any impairment or other adjustments. PipeLedger reads the resulting entries; its agent tools do not post them to the ERP.

A property-secured loan may be repaid directly by escrow; a corporate facility may be drawn and repaid outside the closing. If another group entity provides the funds, record the corresponding intercompany or equity relationship according to the agreement. If the company finances the buyer, distinguish the note receivable from cash collected. None of these arrangements can be established from the net bank deposit alone. The CFPB’s consumer Closing Disclosure guidance illustrates separate buyer, seller, and payoff amounts; commercial transactions may use different settlement forms.

In PipeLedger, review the project’s acquisition, sale, and funding entries alongside Project Financial Position. Match those entries to the closing documents retained by the controller; the reporting pipeline reads the ERP entries and does not infer the journal from an uploaded escrow statement.

Use Development Cost as Catalog Category (L4), with Hard costs — materials and supplies and Hard costs — general contractor and trades as separate Catalog Subcategories (L5). This preserves one Development Cost total while exposing the two construction comparisons. Soft costs, carrying costs, and other approved components can be sibling subcategories. Reporting levels 1–3 continue to express the accounting classification; L4–L5 express the controller’s business grouping across asset and expense accounts.

In PipeLedger’s account classification editor, assign the L4/L5 values to the supporting accounts and record the rationale. A Finance Catalog metric can select all of L4 Development Cost or a specific L5 group; the published report can show both the total and its breakdown after refresh. Separate L4 categories are possible if your reporting structure requires them, but the total metric must then explicitly include both categories. L5 is sufficient for the split described here.

The available detail limits the comparison. A single contractor invoice covering labor and materials cannot become a reliable labor-only figure through relabeling. Keep the package in its contractor group unless the source records support a split. Products, quantities, and hours provide supporting detail where recorded; an account classification does not manufacture that detail.

The real decision is what Development Cost includes. The table below is one reasonable set of answers; the last column is where developers legitimately differ. Write the membership down and apply it to every project.

The formulas use the metric IDs documented in the Ome Dezin story. The ome_ prefix identifies its company-specific definitions. When adapting them, replace it with your own company prefix, such as yourcompany_, in the metric IDs and every dependent formula, filter, and chart field. Keep canonical inputs such as net_income unchanged. Ome Dezin’s development_cost is an organization-authored metric without that prefix; give your equivalent definition your own company prefix if creating it anew.

Scroll horizontally to read the full formulas.

These company metrics use the IDs documented for Ome Dezin. Replace ome_ with your own company prefix throughout the configuration, and reuse equivalent existing definitions where available. Canonical inputs such as total_equity keep their existing IDs.

Scroll horizontally to read the full formulas.

Return on average assets follows the same two patterns with total_assets as the denominator. Show the supporting net income, average capital, cash, and debt amounts alongside the percentages so readers can explain a change.

A worked annualization: $120,000 of income over 24 months divided by $600,000 of average book equity gives a 20% two-year accounting return. Linear annualization divides that return by two, giving 10% per year. The income covers the full two years; the denominator is the agreed average, not the sum of monthly balances. Show the income and capital amounts behind each return so a reader can see which one moved. Missing history or a nonpositive required denominator stays unavailable, and project or LLC percentages must not be summed into a group return.

Four decisions precede any formula:

• Profit. Governed Net Income is the numerator in every return here. Keep the overview’s Operating Profit distinct from it.
• Capital. For a project, contributed capital on the approved contribution accounts, so the return is measured against everything the owners put in. For the company, average book equity or average assets. A peak month-end balance is a different measure and answers a different question.
• Window. Lifetime for a project. Trailing twelve or twenty-four months for the company, chosen to fit the development cycle. A rolling window drops months, not whole projects: a profitable sale leaving the window lowers the rolling return while staying in the project’s lifetime history.
• Annualization. A two-year return can be divided by two for a linear annual figure. Label it whenever you do. The lifetime project returns illustrated here are not annualized.

In PipeLedger’s Finance Metrics builder, choose the metric type, select its source accounts or input metrics, and set the period, sign, and result unit. For example, Return on Project Cost divides Net Income by Total Project Cost over the project’s lifetime, without annualization. The technical column describes those settings; it is not a free-form formula to paste into the editor.

A metric’s display name is the label readers see; its ID is the stable reference other metrics and tools use. Here, ome_project_return_on_cost is the name used in the Ome Dezin story. Create your own company-prefixed equivalent and update its input references consistently. Discover and select your own approved accounts; copying a metric name does not copy Ome Dezin’s account mapping or data.

Save and review a draft, then activate the approved revision. Where compatible, choose delivery in Project Overview or Reporting Entity Metrics. Confirm the revision has been published before expecting it in a dashboard; saving a draft does not change the live figures.

For a targeted measure, select exact account IDs rather than a broad category. Choose debit-positive or credit-positive presentation to match the intended meaning: debit-positive activity is debits less credits, so refunds and releases reduce the result. It is not a filter that discards every credit. Contribution accounts use credit-positive presentation, so contributions count positive and any return of capital booked there reduces the result.

A contributed-capital denominator accumulates contributions and is not reduced when capital is repaid, provided repayments and distributions are booked to separate accounts. This example sums signed activity in the selected accounts, so both contributions and reversals posted there affect the result. An explicit posting-direction filter is a different definition and must be reviewed separately.

Confirm that the relevant budget lines are available to the connector and attributed to the project. Select the intended budget category with the implementation team; do not combine original and revised budgets. Project Overview carries the selected budget source and availability with its amounts. A headline project estimate alone is not a phased monthly budget.

Align the selected budget’s periods and accounts with the actual-cost measure. Project Overview’s standard actual cost is COGS plus expenses; a development budget that includes capitalized work needs a comparison that includes those costs too.

Where the controller adopts a purchase-order workaround, assign every line to the correct project and use a consistent product or service item for the planned work or material. Agree the item’s accounting setup and budget coverage with the controller. PipeLedger retains the source project and item detail and brings eligible PO amounts into Project Overview as committed cost. Label a comparison based on those records “PO-based plan versus actuals” so its basis is clear.

The current PO measure follows eligible order amounts in the order month. Closed, canceled, rejected, or fully billed orders are excluded when that status is supplied. It is not a locked original budget or an automatically calculated unbilled balance. Preserve the approved baseline separately when it must survive those changes, avoid counting both a planning PO and the corresponding supplier order, and do not add commitments to posted actuals without reconciling their overlap. This workflow needs an agreed procurement process; entering a planning PO must not unintentionally authorize a supplier purchase.

The framework is ASC 230. FASB’s published Codification amendments reproduce the distinction between productive-asset acquisition, inventory payments, and debt repayment. Its historical real-estate example in Statement 102, paragraph 25 explains why land acquired for subdivision and resale is operating inventory. The older statement is explanatory background; the current Codification governs the accounting.

For financed closings, distinguish cash paid through escrow from assumed debt or other noncash consideration. Do not infer cash inflows and outflows simply from the asset and liability entries. FASB’s historical cash-flow guidance, paragraph 32, explains the separate disclosure of noncash investing and financing; the controller establishes the treatment from the settlement and lending documents.

PipeLedger applies cash-flow classifications separately from the L4/L5 reporting categories. Its real-estate industry default treats eligible current development-cost accounts as operating inventory; non-current development assets do not take that default. The controller reviews the purpose, then uses the account’s Cash flow category, Calculation basis, and Standard detail to record a consistent treatment. A dedicated account normally needs an account override; an exceptional eligible posting in a mixed account can use an exact transaction-line override with supporting evidence and rationale.

The next successful transform and publication applies the approved classification and retains its provenance. Data Review exposes items needing investigation. A saved override awaiting processing has not yet changed the published statement.

1. Create or choose your business’s Google Cloud project, attach its billing account, and enable BigQuery and the required sharing APIs.
2. In PipeLedger’s Data Sharing connections, choose Customer Hosted Google BigQuery and register the approved subscriber and customer project. Follow the private listing link to create the linked dataset in your project.
3. In Data Studio, add the BigQuery connector, select your project and linked dataset, and connect the approved reporting tables. Verify that queries use your customer billing project before distributing the dashboard.

The linked dataset gives access to PipeLedger’s approved shared data; it does not move the extraction pipeline into your project. Google’s BigQuery connection guide explains the connector’s billing requirement.

The source is the General Ledger, organized into reporting datasets called marts with different purposes. A transaction explains what happened; a month-end balance explains what remains.

1. Establish the required history. Check source coverage, opening balances, and the complete project history needed by the calculation. Fetch subsequent source corrections; processing an earlier extraction cannot include an entry that has not been retrieved.
2. Preserve project and LLC attribution. Carry the same identities through purchases, development, transfers, sales, and releases. Investigate missing or inconsistent tags before relying on a project total.
3. Apply agreed definitions. Use approved account classifications and active metrics consistently. A saved classification awaiting processing is different from the classification in the published report.
4. Check the resulting reports. Reconcile representative projects and investigate differences in source coverage, account selection, or balances. A successful data refresh does not itself establish accounting reconciliation.
5. Publish and identify the version being read. Deliver the configured data to authorized tools and, where used, dashboards. Show the reporting date and latest successful refresh; refresh the presentation after delivery so readers see the intended data.