Potential Bug: Rule-Set Applied as Inverse on API Listing

[Kevin3794]

Hi everyone,

I’m a Superhost using Cloudbeds as my PMS, and I’ve run into a pricing issue that looks a lot like an Airbnb rule-set bug. Support has closed my case saying there’s nothing wrong with the system, but the numbers and the UI don’t line up, so I was encouraged to post here so the forums/product team can take a look.

The listing in question is La Finca Guest Apartment (Miami), connected to Airbnb via API through Cloudbeds. 

Here’s how my listing setup works: Cloudbeds sends only the base nightly rates to Airbnb. For this stay, those base rates add up to $823. On the Airbnb host payout screen, the “7 nights room fee” is also $823, so it’s clear the PMS is sending the correct base number and the API sync is fine.

On top of those base rates, I use Airbnb rule-sets I pre-built in the multicalendar (In this case “Bump +55%”). In Airbnb’s own interface, this rule-set is clearly labeled as a “55% nightly price increase.” On the calendar for those dates, the cell even shows something like “$119 → $184 after nightly price adjustment,” which is exactly what I’d expect from a +55% markup. There’s also a small 4% weekly discount applied in Airbnb, which behaves exactly as expected and isn’t part of the problem.

The problem appears in the host payout breakdown for that same reservation. Instead of seeing a positive adjustment from the rule-set, Airbnb is applying a separate line item called “Seasonal adjustment” that behaves like a big discount. For example, I see entries like “Seasonal adjustment –$29.75,” “Seasonal adjustment –$64.50,” etc., being subtracted from the base rate each night. In other words, instead of increasing the rate by around 55%, the system is subtracting something close to 55% as a negative seasonal adjustment.

What’s important is that this “Seasonal adjustment” line exists only inside Airbnb. There is no seasonal discount or promotion configured in Cloudbeds for these dates, and Cloudbeds support has confirmed that. They re-synced the calendar to Airbnb, the base “room fee” stayed correct at $823, and the negative “Seasonal adjustment” in the Airbnb payout didn’t change at all. Cloudbeds also cannot see or control that adjustment line in Airbnb, which makes sense because it’s Airbnb’s internal calculation.

From my side, it looks like this:

• Cloudbeds sends the correct base rate.

• Airbnb’s calendar tells me the rule-set will increase the price by 55%.

• Airbnb’s payout then quietly applies a negative “Seasonal adjustment” that reduces the rate instead of increasing it.

I’ve already provided support with screenshots showing: the Cloudbeds rate grid matching Airbnb’s “room fee,” the Airbnb multicalendar showing the +55% nightly increase, and the host payout showing those negative “Seasonal adjustment” lines. Despite that, the final response I received was that there is “no problem with our system” and that, because it’s an API listing, it must be an issue with the PMS. That doesn’t really line up with what I’m seeing or what Cloudbeds confirmed.

I’m posting here for two reasons. First, to see if any other hosts using rule-sets on API-connected listings have run into something similar, where an “increase” rule behaves like a discount in the payout. Second, in the hope that someone from Airbnb’s product or technical team can take a closer look at how rule-sets are applied on API listings, especially when they show up as “Seasonal adjustment” in the payout.

Right now, this makes me very hesitant to use Airbnb rule-sets on any API-connected listing, because a single miscalculation can underprice a long stay by a huge amount, and hosts are then told the system is working as intended.

I’ll attach the screenshots that show:
– the correct base rates in Cloudbeds,
– the Airbnb calendar with the +55% rule-set, and
– the Airbnb payout with the negative “Seasonal adjustment.”

If anyone has insights, has seen something similar, or knows a reliable workaround, I’d really appreciate hearing from you.

Thanks for reading,
Kevin

[Emiel1]

@Kevin3794 

It is interesting to notice:

On wednessday (the ruleset is not applied on that date) the weekly discount is 9,81, which is exactly 9% (You mentioned 4% !) of 109,-. And no "seasonal adjustment".

On thursday the seasonal adjustment is only 29,75, which is exactly 25% of 119,-

And the weekly discount is 9% of (119,- minus 29,75): 8,03

On the following days de seasonal adjustment is exactly 50% of the base-price.

The  weekly discount remains 9% and is calculated after the 50% reduction,

for example on friday 9% of 64,50 = 5,80

So more questions (besides: why is the 55% price increase not showing up) are:

Is the weekly discount set to 4% or 9% ?

Where is the "seasonal adjustment" coming from and why is it 25% on thursday and 50% on the following days ?

[Kevin3794]

Sorry, I mis-typed earlier – the weekly discount is set at 9% (see screenshot). Your math is exactly right, and Wednesday is the perfect “clean” example: no rule-set, no seasonal adjustment, just the 9% weekly discount off the full base rate. That part all lines up with my settings.

Where it gets weird is the Seasonal adjustment that suddenly shows up from Thursday onward. I don’t have any seasonal or promotional discounts set in Cloudbeds (see screenshot), and the base rates there match Airbnb’s “room fee – $823,” so the PMS is only sending the plain nightly prices. The extra “Seasonal adjustment” line only appears on Airbnb’s side in the payout, and for some reason it’s 25% of the base on Thursday and 50% on the following days, with the 9% weekly discount then calculated after that.

The only extra thing I’ve told Airbnb to do is the rule-set in the multicalendar: “Bump +55% – 55% nightly price increase.” The calendar even shows an example like $119 going up to $184 after the adjustment, so it’s clearly presented as a markup. But instead of increasing the price, the payout is showing those 25%/50% reductions as a “Seasonal adjustment.” That’s why I’m convinced this part is being generated on Airbnb’s side, not by Cloudbeds.

 

[Kevin3794]

So what do you think @Emiel1 ? I have not heard back from you.