A BLM feed can contain every property in your CRM and still fail at the last hurdle if the fields do not line up with the portal’s rules. Knowing how to map BLM fields properly is what turns raw property data into live, accurate adverts - without staff having to correct the same issues across several portal accounts.
For an estate or letting agency, this is not just a technical exercise. A poor field map can mean missing photographs, incorrect tenure, blank descriptions, properties appearing in the wrong location, or listings rejected before they reach the market. A clear map keeps your feed moving, protects the quality of your advertising, and cuts down on repetitive portal administration.
What BLM field mapping actually means
BLM stands for the British Listed Market data format. It is a structured text-file format used to transfer property listings between a source system, such as a CRM or website platform, and a destination such as a property portal or feed provider.
Field mapping is the process of telling the receiving system where each piece of information belongs. Your source system might call a field `property_type`, while the BLM specification or portal expects `PROP_TYPE`. The value might be `Detached House`, while the portal only accepts `Detached`. Mapping connects those fields and, where needed, translates the value into an accepted format.
A BLM file normally includes a header section, field definitions, property records and an end marker. The records are structured around numbered or named fields. Your job is to make sure the correct source value reaches the correct BLM field, in the correct format, every time the feed is exported.
Start with the destination, not your CRM
The quickest way to create problems is to map fields based only on the labels in your own software. Portals do not all interpret property data in the same way. One may require a council tax band for a rental listing, while another makes it optional. One may accept a broad property type, while another has a strict list of allowed values.
Begin with the destination specification. Confirm which BLM version and field set the portal or middleware service requires, then identify the required fields for sales, lettings, commercial stock or new homes. Keep the mapping document separate for each destination if their requirements differ.
This matters particularly when one agency advertises through several channels. A field that works perfectly for a UK portal may need a different treatment for an overseas portal, a social advertising feed or a developer website. One source of property data is ideal, but it does not mean every channel uses the same language.
Separate required fields from useful fields
Required fields keep the feed valid. These often include a unique agent reference, address details, postcode, price, transaction type, property type, description, status and media references. Missing one can stop a listing from importing or leave it incomplete.
Useful fields improve the advert and search visibility. Think bedrooms, bathrooms, floor area, tenure, council tax band, EPC details, key features, virtual tours, latitude and longitude, and parking or garden information. They may not always block an upload, but leaving them blank can make a property harder to find and less persuasive when it is found.
Treat both groups seriously. The first gets properties live; the second helps them perform.
Build a practical BLM mapping sheet
Before configuring software, create a mapping sheet that people can understand without opening a feed file. This is your reference point when a portal changes a requirement, a new branch joins the account or a member of staff asks why a field is appearing differently online.
For each BLM field, record the source field, a plain-English description, whether it is mandatory, the accepted format, the default value where applicable, and any transformation rule. For example, a source field called `asking_price` may map to the BLM price field as a whole number with no currency symbol or commas. A source field containing `To Let` may need to map to a portal-approved transaction value such as `Lettings`.
Do not rely on a field name alone. Two systems can use the word “price” while meaning different things: a monthly rent, a weekly rent, a guide price, a price qualifier or a display string such as “Offers over £300,000”. Map the underlying numerical value and the qualifier separately whenever the destination supports that distinction.
How to map BLM fields that commonly cause errors
Some data points create more upload failures than others because the value looks reasonable to a person but does not meet the receiving system’s rules.
Property reference and update status
Every listing needs a stable, unique reference. It should not change because an agent edits the description, adjusts the price or refreshes the photos. If the reference changes, the portal may treat the property as a new listing and leave the old version live, creating duplicate adverts.
The update status is equally important. Your feed must clearly tell the destination whether a property is new, changed or deleted. Deletion handling is often overlooked. A property marked as withdrawn in the CRM should not remain advertised weeks later because its record was simply omitted from an export.
Address, display address and geolocation
Map the postal address accurately, including postcode, but keep an eye on what is displayed publicly. Many agents need a broad display address such as “Near Richmond, North Yorkshire” while still providing enough structured address data for portal validation and map placement.
Geolocation is a useful safeguard, especially for new-build sites, rural homes and properties with partial postcodes. Latitude and longitude should come from a reliable source and be checked when a pin appears in an unexpected place. An inaccurate map pin can generate the wrong enquiries and damage confidence before a viewer has read the details.
Property type, tenure and letting terms
Controlled values are where manual habits often clash with portal rules. Your negotiator may select “Character cottage” or “Luxury family home” as a local property type, but a portal may only accept `Cottage`, `House` or another value from a fixed list. Keep the marketing language in the description and map the classification to the closest approved category.
The same applies to tenure, furnishing, availability date and rental frequency. A lettings field must distinguish monthly rent from weekly rent. A `PCM` label embedded in a text price is not as dependable as a separate rent frequency field. For sales stock, ensure freehold, leasehold and shared ownership data is mapped consistently, particularly where the portal requires additional lease or service-charge information.
Descriptions, features and media
Descriptions should map as clean text, with formatting that the receiving platform can safely interpret. Avoid copying hidden code, unusual characters or CRM-only placeholders into the feed. If paragraphs, headings or basic formatting are supported, test how they appear in the live advert rather than assuming the portal will display them as expected.
Photographs need more than a valid image URL. The order, caption, primary image flag and availability of each file affect how the listing looks to buyers and tenants. Make sure the first image is genuinely the strongest approved property image, not a floorplan or an internal placeholder.
Floorplans, EPC documents, brochures, video and virtual-tour URLs should each map to their correct media type. A virtual tour sent as a standard external link may not receive the same placement as a properly identified tour field.
Apply transformations carefully
A transformation changes data as it moves from the source into the BLM feed. Common examples include converting text to a fixed portal value, removing currency symbols, formatting dates, joining several CRM fields into one display field, or assigning a default branch identifier.
Transformations are useful, but they should not hide poor source data. If every listing needs a rule to repair malformed postcodes or fill in an unknown property type, the real fix belongs in the CRM process. Clean data at source gives you fewer exceptions, more reliable reporting and a faster response when a portal changes its specification.
Be cautious with defaults. A default furnishing value or tenure can prevent a technical rejection, but it can also create misleading advertising. Use defaults only where they are commercially safe and clearly agreed by the agency.
Test the feed with real property scenarios
Do not test a new BLM map using a single standard three-bed semi-detached house. Use a small set of realistic edge cases: a sale property with a price reduction, a furnished rental with a monthly rent, a new-build plot, a commercial unit if you advertise them, and a withdrawn property.
Check the exported BLM file first, then check the imported record in the receiving dashboard, and finally inspect the live portal advert. These are three different stages. A feed can be technically valid yet still show a missing floorplan, a poor display address or an incorrect price qualifier on the public listing.
After launch, review import reports regularly. Failed records and warnings are useful operational information, not background noise. A 15-minute import check can spot a broken image path, a CRM field change or a new mandatory portal requirement before it affects an entire branch portfolio.
Keep ownership clear as your agency grows
BLM mapping works best when one person or team owns the rules, even if several branches enter property data. That owner does not need to be a developer. They do need authority to define source-data standards, approve changes and ask questions when an upload looks wrong.
For multi-branch agencies, use branch identifiers and agent references consistently from the outset. This makes it easier to separate stock, report accurately and avoid one office accidentally overwriting another office’s listing. If you run different brands or divisions, agree which fields are shared and which need distinct values before the feed goes live.
Estate Agent Feeds can help agencies convert and distribute BLM alongside XML, API and other feed formats, with practical support when source fields and portal requirements do not naturally match. The goal is quick and simple: enter or import property data once, then keep it accurate everywhere it needs to appear.
A well-mapped BLM feed should become invisible in the best sense. Listings publish promptly, changes follow through, withdrawn properties disappear when they should, and your team can spend its time winning instructions and arranging viewings rather than logging into a dozen websites.