A rental yield calculator should show the scenario that loses money

Dmitrii Kuznetsov — Wed, 28 Oct 2026 05:42:29 +0000

A positive rental yield is easy to demonstrate with a friendly input. The more useful question for a property-data tool is what happens when occupancy falls while fixed costs and loan payments remain due.

We added a browser-based Rental Cashflow Stress Lab to our existing open-source calculator. It compares explicit scenarios instead of replacing uncertain inputs with country presets.

This is a project from NovAsia Estate, where our property research covers Cambodia, Thailand and Bali. All the figures below are synthetic test inputs, not observations about those markets.

Keep capacity rent separate from collected rent

The input we call full-occupancy rent is a capacity assumption:

scenario capacity = full-occupancy annual rent × rent-level multiplier
collected annual rent = scenario capacity × occupancy

For example, 24,000 at 70% occupancy becomes 16,800 of collected annual rent. A downside scenario uses a lower rent level of 85% and occupancy of 35%, giving 7,140.

This simple annual fraction does not model seasonality, cancellation patterns or the difference between asking and achieved rent. Making that limitation explicit is preferable to presenting the result as a forecast.

Fixed costs should survive zero occupancy

Our example has 1,200 of annual common-area charges, 500 of other fixed costs and 6,000 of annual debt service. Management and maintenance-reserve assumptions are 20% and 5% of collected rent.

The core engine calculates operating income and applies the caller's chosen simplified tax base. The stress extension subtracts debt service afterwards. It does not infer tax deductibility of interest, depreciation, a loan balance or an equity-return denominator.

With an illustrative 10% tax on positive operating profit, the three fixture outcomes are:

Scenario	Occupancy	Rent level	Fixed-cost level	Net annual cash flow after debt
Base	70%	100%	100%	3,810
Vacancy shock	35%	85%	125%	-3,093
Stronger demand	90%	110%	100%	8,508

At zero occupancy, those original fixed costs and debt still produce a loss of 7,700. The tool retains that number. A missing cost is an input error; zero must be entered deliberately.

Break-even needs the same assumptions as the comparison

Let F be fixed operating costs, D annual debt service, k the fraction of collected rent remaining after management and reserve, and t the supplied tax rate.

For a gross-rent tax assumption, the continuous threshold is (F + D) / (k - t) when the retained margin is positive.

For tax on positive operating profit, with k > 0 and t < 1, it is (F + D / (1 - t)) / k.

The example's base case needs about 11,155.56 of collected annual rent, or about 46.48% of its stated capacity. A requirement above 100% occupancy means the entered rent capacity cannot cover the costs. Impossible margins and zero capacity have explicit states rather than a misleading percentage. The exact edge cases, including 100% tax and zero costs, are covered by tests.

These thresholds are approximate continuous results before cent rounding. Breaking even is not the same as earning a positive return.

Keep the experiment reproducible

The extension uses the same engine as the original calculator:

const Stress = require('./docs/stress.js');
const input = require('./examples/stress.json');
const report = Stress.compare(
  input.base,
  input.annualDebtService,
  input.scenarios
);
console.log(report.rows.map(row => [row.name, row.netAfterDebt]));

The source repository contains the fixture and 36 passing contracts, including zero rent, retained losses, both tax bases, impossible break-even states, CSV formula protection and browser/Node consistency. JSON exports retain the assumptions and itemized core results. Browser inputs are calculated locally without upload requests.

For the earlier acquisition stage, our Payment Milestone Studio allocates dated installments with exact integer arithmetic. That is a separate problem: a purchase payment schedule does not establish rental income.

The Stress Lab is a repository and browser extension. The published novasia-sea-yield npm package remains version 2.0.1; we are not describing unshipped npm exports. Contributions that make assumptions clearer are welcome.

Why parsing real estate contracts with LLMs is ten times harder than tutorials claim

Dmitrii Kuznetsov — Sun, 18 Oct 2026 04:52:15 +0000

When we started building the data pipeline for NovAsia (a property catalog and market tool for Southeast Asia), the plan looked embarrassingly simple on paper:

Grab property PDFs and developer contracts (SPAs).

Run them through a modern vision LLM.

Dump structured JSON into PostgreSQL.

Call it a day.

Two weeks in, the pipeline was completely broken. Here is why standard tutorial advice fell apart in production, and what we had to change to get reliable data out of scanned documents.

The stuff tutorials don't warn you about
Most LLM document parsing demos use crisp, born-digital PDFs with clean typography. In emerging markets like Cambodia and Thailand, reality looks very different:

Phone scans: Half the documents are multi-generation scans or photos taken with a phone camera under uneven lighting.

Dual-language layout: Khmer or Thai text mixed with English, often in adjacent table columns where line baselines don't match.

Physical stamps: Red rubber stamps, signatures, and notary seals placed directly over critical numbers (payment milestone dates, sinking fund fees, transfer taxes).

The 40-page prompt trap: If you shove a 35-page PDF into a long-context model and ask for "all fees and payment dates", it will extract 80% correctly and quietly hallucinate the rest with total confidence.

Three practical changes that fixed it
Instead of trying to find one magic model that does everything, we broke the pipeline down into smaller, boring steps:

Aggressive image cleanup before text extraction

Before any model sees the page, we run basic OpenCV passes: deskewing, binarization, and contrast normalization. Removing phone-scan shadows did more for extraction accuracy than upgrading to a larger model tier.

Section-level chunking with rigid schema validation

We stopped asking the model to parse whole documents at once. We chunk by specific section (e.g., "Schedule of Payments", "Maintenance Obligations") and enforce strict Pydantic schemas. If a field fails validation or falls outside expected bounds, the pipeline flags it for manual check rather than guessing.

Treating tables and narrative text as separate problems

Vision models are great at answering qualitative questions ("under what conditions is the deposit refundable?"), but notoriously sloppy with columns in financial tables. We split table extraction into dedicated passes with explicit row-by-row checks.

The takeaway
If you're building with LLMs on messy, physical-world paperwork, raw context window size won't save you. Most of the reliability comes from image hygiene and strict schema boundaries.