When a Channel Flags a Property-Type Mismatch

A property-type flag rarely means your listing is wrong. It usually means one category field is answering a question a different channel asked.

Last updated: October 14, 2026

A property-type flag doesn't mean you picked the wrong category. It means the channel read one field on your listing, compared it with another, and found the two disagreeing. The flag is a question about consistency, not a verdict on your unit. Answer the question and it usually clears.

Key Takeaways

• The flag compares two fields, not one. A channel reads your property type against a second field on the same listing, and the flag fires when they disagree.
• The conflict is between channels, not inside one. A value that answers one channel's question can read as the answer to a different question on the next.
• Amenities can trigger the same flag. Some units get flagged on an amenity even when the property type reads correctly on its own.
• Fix the field, then re-send. Nothing clears by itself; the flag goes when the corrected listing reaches the channel again.
• Don't over-correct. Rewriting several fields at once hides which one actually cleared the flag.

What the flag is actually asking

A property-type flag reads like a judgment on your listing. It isn't. It's a comparison, and the comparison failed at one point. The channel took the type you declared, read a second field on the same listing, and found the two disagreeing.

Think of it as the channel asking a narrower question than the one you answered. You filled in what the unit is. The channel wanted to know how it should file it. Those aren't the same question, and a single value can answer one while blocking the other.

That's why the flag so often lands on a listing that looks complete. Every field is filled. The unit publishes elsewhere without complaint. It matches your own description of it. The flag isn't about the unit. It's about two answers that can't both be true at once for that channel.

New hosts meet the flag most often right after an import, when a batch of listing data arrives at once and each channel files it against its own list in turn.

The useful move is to stop defending the field you filled and start reading the pair. Which two fields is this channel putting side by side? One of them came from you. The other usually did too, but weeks earlier, from a different form, or during an import.

Name the pair and the flag stops being a rejection. It becomes a specific question with a short answer.

The category fields behind it

Start with the fields that describe what the unit is, because those are the ones a property-type flag compares. There's the property type itself, the unit or room type, and the question of whether guests rent the whole place or a portion of it.

Each channel keeps its own list of options for those fields. Your listing travels to four of them on a direct connection: Airbnb, Booking.com, Agoda and Trip.com. That's four taxonomies, and they're rarely the same shape.

This is the ordinary source of a mismatch. A value that fits one channel's list cleanly has to be mapped onto another's, and the mapping isn't always one to one. What reads as one kind of unit on one channel can sit between two categories on the next.

The fields also age. You set the property type when you built the listing. Later you changed how you describe the unit, or renamed it, or split a large property into separate listings. The type field doesn't always follow. A flag is often the first sign that it stayed behind.

A quick way to test which field is out of step is to read the listing the way a guest sees it. The page shows one description of the unit. The type field holds another. Where the guest-facing page and the type field describe different places, you've probably found the pair.

Read the pair in order: the type you declared, then the field the channel compares it against. Correct the one that's actually stale, and leave the other one alone.

Amenity fields that trigger the same flag

Not every property-type flag starts at the type field. Amenities carry their own expectations, and some of them imply a kind of property. When an amenity tells the channel one story and the type tells another, the same flag can fire.

The usual suspects are amenities tied to a whole unit rather than a room. A private entrance, a full kitchen, a washer inside the unit, a parking spot of your own. Each of those reads as a claim about the kind of space a guest gets.

Others come from the features guests filter on. A pool, a hot tub, a garden, a balcony, a desk. Guests use those to narrow a search, so a channel treats them as facts about the unit rather than as preferences.

Two patterns create most of the noise. The first is an amenity you ticked once and later lost, when the unit changed. The second is an amenity that's true for part of the property but not for the unit being sold. Either way, the amenity and the type end up describing different places.

Before you edit, read the two together. Ask which one a guest would rely on more. Then correct the weaker claim and leave the stronger one as it stands, because flipping both hides the field that caused the flag.

Channels also group amenities differently. A feature you record once can count as a whole-property amenity on one channel and a room-level extra on another, which is enough to make the type and the amenity disagree without either field changing.

Expect the flag to name an amenity rather than the type. It's rarely where the problem started, and it's almost always where the comparison failed.

Re-sending after the fix

Nothing clears by itself. The corrected value sits on your side until the listing reaches the channel again, so the last step is always a re-send.

Do it in one direction first. Correct the field on your side, save it, and push the listing to the channel. Editing on the channel by hand and leaving your own copy stale just moves the mismatch onto a new pair.

Then watch for the re-send landing instead of assuming it did. LOCALSBNB's calendar shows each connected channel's source rate and source status, so you can read whether the channel you re-sent to is carrying the updated listing or still holding the old one.

Give it a beat. A re-send isn't instant on every channel, and a flag that hasn't cleared yet looks identical to one that never will. Note the time you pushed it, then read the source status again before you start a second round of edits.

If the flag survives, return to the pair rather than widening the fix. Re-read the type and the field it's compared against, and confirm they now agree. A flag that persists after a clean re-send usually means the correction landed on the wrong side or on the wrong record.

Keep a short note of what you changed and when. A property-type flag on the same unit twice is far easier to diagnose if you can see which correction cleared it the first time.

If you'd rather watch four channels pick up one corrected listing at the same time, localsbnb.com shows each connection's source status on a single calendar.

FAQ

Does a property-type flag mean my listing is wrong?

No. It means one field on your listing disagrees with another. The unit itself is usually fine; a single value is answering a question that channel didn't ask.

Which field should I change first?

Change the one that's genuinely stale. Read the declared type against the field the channel compares it with, and correct whichever no longer describes the unit.

Why does the flag name an amenity instead of the type?

Because that's where the comparison failed, not necessarily where it began. An amenity can imply a kind of property, and when the two disagree the channel surfaces the mismatch wherever it found it.

None of this needs a rebuild or a new listing. Read the pair, correct the stale field, re-send once, and confirm the source status before you touch anything else. If keeping four channels in view is the hard part, localsbnb.com is a sensible place to line them up.

---

This is general advice for hosts, and it isn't legal, tax or insurance advice. Rules and platform terms vary by place and change over time; check the current requirements of your local authority and the current terms of each platform you use.