Ome Dezin: an AI-assisted controller setup for real estate development

Los Angeles-based Ome Dezin restores character-driven sanctuaries with thoughtful design and contemporary livability. After years in real estate development, the team began professionalizing its operations in 2025 as it took on larger, lender-financed projects with more co-investors, lenders, and contractors. Clear legal structures, owner protection, and project-level accountability became top priorities.

Ome Dezin was already using QuickBooks. What it needed next was help managing financial data across multiple LLCs, including the holding company, and bringing their results together. The owners wanted a clear answer to two questions: what has each project contributed individually, and what are the company results? They needed one project overview that made sense from purchase through development and sale, without having to understand how the accountant recorded each cost.

As Ome Dezin attracted co-investor capital, the team needed financial results it could explain with confidence. Funding, reimbursements, and loans between the LLCs repeatedly reopened reconciliation questions, leaving the owners without a clear explanation of what each project had earned or where the money belonged.

The team invested in a shared financial data warehouse, combined reporting across the LLCs, and AI-assisted controller review. The goal was a consistent view of project and company results, with accounting differences that could be traced back to the records and resolved.

Every Ome Dezin project reports through the same template. The Finance Catalog groups the chart of accounts into four Catalog Categories shared by all projects: Revenue, Acquisition Cost, Development Cost, and Financing Cost. Development Cost is split further into Catalog Subcategories for hard costs, soft costs, carrying costs, and closing costs. These groupings are defined once and applied to every project, so a completed sale, an active renovation, and a newly acquired property can be read through the same lines.

Ome Dezin’s earlier spreadsheet template carried rising admin costs and could not keep up once several projects ran at the same time with different funding arrangements and cost treatments. Investing in a data warehouse and PipeLedger made sense. The replacement lives in the Finance Catalog rather than in the books. QuickBooks keeps its own account hierarchy; the controller assigns each account a Catalog Category and Catalog Subcategory that say what the cost means to the business. A property tax bill and an architect’s invoice both land in Development Cost, one under carrying costs and the other under soft costs, without renaming anything in QuickBooks. The amounts below are illustrative; the structure is the real template.

Two cost definitions follow from the template. Development Cost is everything in the Development Cost category across both expense and asset accounts, so development spending can be compared across projects whichever treatment applied; Acquisition Cost and Financing Cost stay outside it. Total Project Cost is broader: recorded project expenses plus the capitalized costs still held as assets, including acquisition. When a capitalized cost is released to cost of goods sold at sale, the asset falls and the expense rises by the same amount, so the total counts that cost once. The implementation guide includes a worked cost-release example.

The definitions behind the project results

We publish how customers use PipeLedger so that other teams can reuse the same approach. The definitions below are the ones Ome Dezin runs.

A property can take more than a year to develop. Real estate developers therefore capitalize eligible project costs: they hold those costs as assets during development and recognize them as expense when the property is sold. Other costs may be expensed as incurred. The controller needs to follow both treatments across the full project lifecycle.

PipeLedger’s Finance Catalog turns the controller’s definitions into reusable measures. Each measure specifies the accounts to include, the period to cover, and how to calculate the result. Ome Dezin can apply those definitions across its projects without maintaining a separate spreadsheet formula for each one.

For Ome Dezin, three definitions mattered most. Development Cost had to be measured from the template’s catalog categories, whether a cost was expensed or capitalized. Total Project Cost had to hold across costing methods, combining expensed costs with the capitalized costs still on the balance sheet. And because co-investors fund projects alongside the owners, contributed capital had to be selected account by account, so that Project ROE uses only the approved contribution accounts. The Finance Catalog handles all three:

The formula column mirrors the workspace Metrics tab. Lowercase identifiers are Finance Catalog metric IDs: canonical metrics such as net_income and total_equity, and the ome_ definitions Ome Dezin authored for its own business, which another developer can adapt to their own accounts. Uppercase functions are PipeLedger metric calculation types, and the detail lines carry each metric’s window, annualization, and membership settings. This is a readable rendering of the catalog configuration, not a free-form formula to paste into a derived metric. The returns are accounting returns on recorded balances, not investor cash-flow IRRs.

Each project report rolls up into one Project Overview across all LLCs. Every row is a project. Every column is a definition from section 2: revenue, cost of goods sold, expenses, profit, Total Project Cost, Development Cost, Project ROE, and Return on Project Cost. The chart above the table plots each project’s total cost against its operating profit, so the portfolio can be read at a glance before anyone opens a row.

The overview is refreshed automatically every week, and on request from the controller, who works mostly during account closing. The controller reviews it first, looking for projects whose numbers do not match their stage: a development asset still open after a sale, a cost booked to the wrong project, an equity balance that does not reflect a co-investor contribution. The owners then review the same page. Because every project uses the same template, the questions are the same each month: what has this project cost, what has it earned, and what is still on the balance sheet.

Connected AI models do the retrieval work during that review. When a number on the overview looks wrong, the controller or an owner asks the question directly in ChatGPT, Codex or Claude: which entries make up Development Cost on this project, what is making contributions between the partners uneven, which contractor was paid for the landscaping. The assistant resolves the project, retrieves the supporting records within its permitted scope, and explains the difference in plain language, much quicker than a human. PipeLedger’s AI works at the journal-entry level, helping classify debits and credits correctly so real estate books stay GAAP-compliant, all the way from project accounting to the cash flow statement.

Behind the question, the assistant uses pl_resolve to identify the project or counterparty and pl_query to retrieve records within its permitted scope.

Section 3 answers what each project has earned. This view answers what is still invested in each project at a month-end, and how that investment is funded. The Project Financing Overview shows, per project, the capitalized project cost still on the balance sheet, the financing equity and financing debt behind it, total financing, and loan-to-cost.

The controller uses this view to follow each project through its lifecycle. During development, capitalized cost and financing grow together. After a sale, cost release, debt repayment, and equity distributions can happen at different times, so the view shows what is still on the books: a capitalized balance not yet released, debt not yet repaid, equity not yet distributed. Each is a prompt to investigate rather than an error by default. The supporting General Ledger records show whether a booking or a classification needs correction, and the next refresh confirms the fix.

Borrowing and owner contributions explain funding; they are not additional project costs. Loan-to-cost compares financing debt with capitalized project cost at the same date. For Ome Dezin, the same figures support the co-investor conversation: each project shows its equity, the debt alongside it, and what remains invested, without anyone reconstructing the numbers from the books.

The five balance metrics behind this view, in the same notation as the project result metrics in section 2:

For a developer seeking additional funding, a banker or co-investor needs an understandable account of the business behind the next project. Cash, debt, equity, and returns become more useful when the controller can explain their definitions and connect them to reviewed books. That reporting gives lenders and co-investors a clearer basis for discussing the next project.

Thoughtful development takes time. A property may be acquired in one year, restored in the next, and sold later. Sales can therefore make a single year's income change sharply even while the team continues its work. Ome Dezin added a trailing 24-month view to give those longer project cycles more context and smooth some of the timing effects of individual sales.

Ome Dezin added five trailing 24-month metrics: 24-month Net Income, Average Book Equity, Average Assets, and annualized returns on those two average balances. Each return uses the full 24-month income divided by the average of 24 month-end balances, then multiplied by one-half for linear annualization.

The company view also shows bank cash, Total Assets at book value, and Financing Debt before netting cash. Together they explain liquidity, the recorded asset base, and borrowing. Financing Debt selects borrowing accounts; it is not a synonym for all liabilities.

The company page presents month-end figures in three layers: four headline figures with their change against twelve months earlier, a trend for each over the past year, and monthly tables of the amounts and the returns. Two rows are operational measures. Projects completed and Projects in progress come from PipeLedger’s Unit Register, so the owners see the number of projects next to the capital behind them.

The result is a way of working rather than a report. Seven things are different.

• No spreadsheets. The project template, the overviews, and the company metrics come from the QuickBooks books through PipeLedger. Nothing is re-keyed, and there is no workbook to reconcile against the ledger.
• Reporting that co-investors and lenders can rely on. Each project shows its cost, its funding, and its return with the definitions written down, which is the basis for bringing outside capital into the next project.
• Room for more projects and more LLCs. A new entity or project is a connection and a set of tags, not a new template. The warehouse and the definitions scale with the business.
• Scoped access for partners, project managers, and contractors. PipeLedger’s credential system shares each LLC’s reporting with the partner in that LLC, and gives project managers and contractors a scoped view of their project’s actual costs as they are published.
• Owner controlling across every project. The owners review all projects on one page, ask the same questions each month, and follow any number back to its entries.
• A faster close. With AI-assisted reconciliation, the hourly-paid controller spends significantly less time on the close than before, and a refresh on request shows a correction the same day.
• A clean handover to the CPA. Year-end numbers arrive separated by LLC, with each project’s history and supporting entries attached.

For Ome Dezin, the change is a working financial review process: project tracking in QuickBooks, corrected classifications, shared definitions, and AI assistance for monthly reconciliation. The dashboard makes the results accessible; the supporting records let owners and the controller follow the explanation back to the books.