How we calculate our market data

1. Data sources

The data comes from publicly available Bulgarian property listings published on the major property portals. We do not use Registry Agency records, notarial deeds or any other register of completed transactions — see “Limitations”.

Crawling is automated and repeats every hour. A listing not seen for 24 hours is marked inactive and leaves every statistic. So a listing pulled from its portal last night may still count as active for part of today.

Active listings are the only basis for the market figures. Inactive ones are kept for price history but take no part in the medians.

imotesa.bg statistics (typical prices, percentiles, indices and scores) are published under CC BY 4.0 — free to reuse with attribution. The licence does not cover source listings, photos or descriptions.

Current coverage

• 210,000+Active Listings
• 20,000+Merged Duplicate Listings
• 470+Neighbourhoods with AI Score
• 250+Cities & Regions

2. Duplicate detection

The same apartment is often published by several agencies across several portals at once. Counted as separate properties, they skew every statistic towards whatever is advertised most aggressively.

Listings are therefore grouped into a single canonical property on two independent signals:

• Perceptual image hashing — each photo is reduced to a short fingerprint that survives resizing, cropping and watermarking. Two listings showing the same home are recognised even when the image files differ.
• Attribute matching — location, floor area, storey, year built and price. An image match without an attribute match is not enough — that is what stops a developer's stock photography from merging different apartments in one building.

The merged property keeps all of its listings, so its page shows which agency offers it at which price. Where the prices differ, one listing per property feeds the market calculations — not the average of the duplicate postings.

Detection is not infallible. A listing with no photos and sparse attributes may survive as a separate property; the opposite error — merging two near-identical neighbouring apartments — is rarer but possible.

3. Median, not mean

The published figures are medians: the value with an equal number of listings above and below it. A mean is dragged upward by a small number of very expensive properties and would describe a market most buyers would not recognise. The median describes the typical listing.

Page headings say “average prices” because that is how people ask the question. The figures themselves are labelled as medians everywhere a specific value is asserted.

A segment is published only when it holds enough listings for the median to be stable. The thresholds differ by property type:

A segment below its threshold is not published at all — no page, no number, no estimate. That is why some neighbourhoods have apartment statistics but no house statistics.

Segments are calculated at four levels: neighbourhood and room count, neighbourhood overall, city and room count, city overall. Each level must clear the threshold on its own.

4. The “% below market” signal

The badge on a listing compares its price per square metre against the median price per square metre for the segment the property falls into:

deviation = (segment median €/m² − listing €/m²) ÷ segment median €/m²

The most specific segment with sufficient data is used, in this order: neighbourhood and room count → neighbourhood (all rooms) → the city as a whole. That last step is why properties in towns with no named neighbourhoods, and types with no room count (houses, parking), still receive a signal.

The badge's thresholds are deliberately asymmetric: below −8% the property reads as cheaper than the market, above +10% as more expensive, and a gap of more than 40% below market is shown as a warning rather than a better deal. A gap that large usually means a data error or a defect the listing does not mention.

This is not a valuation. The signal accounts for none of condition, aspect, storey, noise, view, build quality or legal status — the things that explain much of the price difference. It shows where the asking price sits relative to neighbouring listings, and nothing more.

How we measure price reductions

The “Price cuts” series reports one thing only: how many sellers reduced the ADVERTISED price of a live listing during the month. These are the exact rules.

• Asking prices, not deal prices — we measure changes to published prices on live listings. These are not discounts agreed at a deal, so our figure is not comparable with the percentages from broker surveys — the two describe different quantities.
• What counts as a reduction — any recorded price lower than the one before it. A listing's first recorded price is its opening offer and is never counted as a reduction. Moves under 1% are ignored as rounding — in practice they are about 14% of all reductions and would distort every figure.
• Which figure can be compared across months — the share of reductions among ALL price changes. Reductions and increases are both observed the same way — when we re-crawl a listing we already know — so their ratio does not depend on how many listings we happened to check that month. The count of sellers who reduced, and their share of active listings, do depend on it, and are therefore published for the current month only, never as a trend.
• The denominator — the share of active listings is measured against the count of active apartment sale listings for the same city and month in our monthly statistics — the same series the imotesa index is built on, so the two instruments cannot contradict each other. When that count is missing for a month, the share is simply not published.
• Neighbourhoods cover three months — the neighbourhood table covers the last three months, while every headline figure in the article is monthly. On a monthly basis the per-neighbourhood sample is too small to name places honestly. A neighbourhood's share is measured against the AVERAGE number of active listings across the three months — a property active in all three counts once. If monthly data is missing for any of the three, only the count is shown, without a share.
• Publication thresholds — a city edition appears only with at least 50 reducers in the month; a typical reduction is quoted with at least 20 reductions and the size distribution with at least 50; a neighbourhood is named with at least 10 reducers and at least 30 active listings over the period. That is why one of the four cities sometimes skips a month — it is the threshold working, not an omission.
• From which month onward — our crawl coverage grew substantially through the first half of 2026, so counts from before March 2026 are limited by it rather than by the market, and are not published. For the same reason counts and shares from the start of the series should not be compared month to month — that is what the share of reductions among all changes is for.
• Method version — every record carries the version number of the definition it was computed with. If we ever change the definition, existing records keep their version and the change is announced here — a published figure stays checkable against the method that produced it.

imotesa index — how it is computed

"imotesa index" is a monthly measure of typical apartment prices in Bulgaria, built from two separate constituencies — a city basket and a resort sub-index. Here are the exact rules behind the number.

• The basket is fixed, not re-derived every month — the national index covers 16 pre-selected oblast centres. The basket is frozen: a city that later falls below the sample floor stays in, and a new city is added only at an announced rebasing — see "Revision policy" below. The index is never described as covering "the biggest cities" in the country, since membership is selected by tracked inventory, not by population.
• The resort sub-index is separate — 9 coastal and mountain resort locations are reported separately, never merged into the city index — resort markets have a different, strongly seasonal supply pattern, and weighting them into the national figure would distort it. The resort sub-index carries its own typical price and active-property count, but no index level of its own (base = 100), since the index's single base month cannot meaningfully apply to two different constituencies at once.
• Base month: June 2026 = 100 — earlier months in our database (January–May 2026) were computed by a different method — as a range of listing activity across the month, rather than a snapshot as of one specific day — and are therefore not comparable in kind to the current method, regardless of coverage. June 2026 is the first month computed by the current, point-in-time method, which is why it was chosen as the base. Those earlier months do not take part in the index series.
• How the composite price is weighted — the typical price per sqm for each basket is a listing-weighted median composite — each city/resort enters weighted by its own count of active listings. This is the same median logic described above under "Median, not the arithmetic mean", applied in weighted form across several locations at once.
• Active-property counts are a snapshot, not a trend — the active-property figure in each edition is a point-in-time snapshot as of the calculation date, not a comparable month-to-month series — it moves with how much we crawled that month, not necessarily with real supply. That is why we do not publish a month-over-month supply change, only the dated count.
• Revision policy — a published index edition is never recomputed retroactively on new data. Basket membership for either constituency changes only at an announced rebasing, documented on this page — never silently between one edition and the next.

The index does not currently publish a year-on-year comparison — the history since June 2026 is still too short for a defensible annual comparison. This is a deliberate choice, not an oversight, and will be added as soon as the available history allows it.

5. Limitations

Each of these is inherent to the source rather than a defect awaiting a fix:

• Asking prices, not transaction prices — we measure what sellers want, not what deals close at. When the market cools, asking prices lag actual ones by months.
• "Off the market" never means "sold" — when a listing disappears we know only that it is no longer published. It may have sold, been withdrawn, expired, or moved elsewhere. We never call a property "sold" — that is a fact our data cannot establish.
• Coverage is not the whole market — properties sold without a listing — between acquaintances, through a single broker, or before publication — take no part. In new developments a share of sales never reaches a portal at all.
• AI enrichment can be wrong — property type, attributes and summaries are generated automatically from the listing's text and photos. Where the listing is inaccurate or incomplete, the error carries through.
• Period comparisons are sensitive to mix — a quarter-on-quarter change reflects which properties are currently on offer, not only a change in the price of the same property. We therefore show a trend only when the sample is sufficient in both periods.

6. What AI does and does not do here

AI writes text. It summarises the listing description, extracts pros and cons and reads the exposure — all of it carried under an "AI summary" label so you can see what was generated.

AI computes no number. Medians, percentiles, the difference against the neighbourhood, yield and price history are all calculated by code over the collected data, by the rules described above. If a number cannot be defended on this page, it does not ship.

7. Citation and reuse

The data may be freely cited — by journalists, analysts, students and researchers — with attribution and a link to the specific page the figure came from.

Please do not present our figures as completed-transaction prices, and please state the date they were valid on: the market pages are recalculated daily.

Example citation

imotesa.bg, “Average prices for apartments for sale in Sofia”, data as of 1 October 2026, https://www.imotesa.bg/statistics/sale/apartment/sofiya

Questions about the methodology, or a breakdown that is not published: support@imotesa.com

Methodology last revised: August 2026