Beyond is software that writes rates to vacation-rental listings. Its verified pricing uses a percentage of bookings rather than a fixed monthly subscription. That distinction matters more than the property count: an operator with one high-revenue property can pay more than an operator with three lower-revenue properties.
I read the figures used here on 2026-09-11 through a United States connection. I am stating the location because software prices in this category can differ by country. The verified plans were Growth at 1% of bookings and Pro at 1.25% of bookings.
The clearest audience is an operator who wants rates written to a supported booking channel and is comfortable paying in proportion to booking revenue. If Maarten operates three properties in one town, all through the same booking channel, his invoice cannot be calculated from the number three alone. I also need the value of the bookings attributed to those properties.
This makes the product structurally different from tools billed by property, room or account. Those distinctions are easy to miss when a review publishes a starting price without naming the billing basis. For a useful comparison, I separate the questions into three parts: the percentage, the booking revenue to which it applies, and the capabilities verified for the plan.
Readers comparing several billing structures can see how other products define their charge in the rooms-based pricing review, the operations software review, the account pricing review and the website and software review. Those pages should not be treated as interchangeable price cards. A room, a property, an account and a percentage of bookings are different denominators.
I also avoid turning a pricing review into a verdict based on labels. “Growth” and “Pro” are plan names, not evidence that one plan fits a particular portfolio. The useful evidence is narrower: Growth takes 1% of bookings, Pro takes 1.25% of bookings, and the rate-writing workflow verified here uses a browser extension for one booking channel.
The billing basis comes first: the price is a percentage of bookings. Growth is 1% of bookings, while Pro is 1.25% of bookings, according to the vendor pricing page linked above. Property count by itself does not produce a bill.
To make the arithmetic reproducible, I will use a clearly labelled scenario rather than pretend that every property earns the same amount. My worked assumption is that each property produces $2,000 in bookings during the billing period. These revenue figures are illustrative numbers chosen for the calculation; they are not revenue claims from the vendor.
| Portfolio in my example | Illustrative bookings | Growth calculation | Pro calculation |
|---|---|---|---|
| One property | $2,000 | $2,000 × 1% = $20 | $2,000 × 1.25% = $25 |
| Three properties | 3 × $2,000 = $6,000 | $6,000 × 1% = $60 | $6,000 × 1.25% = $75 |
| Ten properties | 10 × $2,000 = $20,000 | $20,000 × 1% = $200 | $20,000 × 1.25% = $250 |
The table does not mean one property always costs $20. It means one property with $2,000 in bookings produces a $20 Growth calculation in my example. If that same property produces $8,000 in bookings, my arithmetic becomes $8,000 × 1% = $80 on Growth and $8,000 × 1.25% = $100 on Pro.
The same caution applies at three properties. Maarten’s three-property portfolio could produce $6,000 in bookings, as assumed above, but the count does not guarantee that amount. If his combined bookings were $15,000, the calculations would be $15,000 × 1% = $150 and $15,000 × 1.25% = $187.50.
This is why I would not publish a statement such as “the product costs a particular amount at ten properties” without also naming booking revenue. Ten properties generating $20,000 create the $200 and $250 results in my table. Ten properties generating $50,000 would instead create calculations of $500 on Growth and $625 on Pro.
Nor should a reader multiply an assumed one-property charge by a property count unless revenue is also being held constant. If one property produces $2,000 and another produces $7,000, they do not contribute equally to a percentage-based bill. The calculation follows bookings, not doors.
That revenue sensitivity is the central answer to the cost question. At one, three and ten properties, I can show the formula. I cannot give a universal invoice for any of those counts. A host evaluating several payment models can compare this structure with the calculations in the portfolio software review, the messaging software review and the property software review, provided the billing basis on each page is kept attached to its number.
Answering guests at 11pm is the part software should do.
Start free — first 500 messagesOr book a demo callThe verified record establishes two plan prices: Growth at 1% of bookings and Pro at 1.25% of bookings. It does not establish a complete feature boundary between those plans, so I will not invent one.
The capability I can report is specific. The product writes rates to VRBO through a Chrome extension using that channel’s credentials. The vendor’s help also instructs users to turn the channel’s own MarketMaker off first.
That gives Maarten a concrete setup question for his three properties. If all three use that channel, he should examine whether the extension-and-credentials workflow fits the way he administers all three listings. He should also treat the instruction about disabling MarketMaker as an operational step, not as a footnote he can postpone until after rates begin changing.
I cannot assign this verified capability exclusively to Growth or exclusively to Pro because the supplied record does not identify that boundary. The difference I can establish between the plans is numerical: 1% versus 1.25% of bookings. A higher percentage does not, by itself, prove that any particular capability is exclusive to the higher plan.
| Verified item | Growth | Pro |
|---|---|---|
| Price basis | 1% of bookings | 1.25% of bookings |
This intentionally short table is more accurate than a long checklist filled with guesses. I have not verified a plan-by-plan assignment for the extension workflow, so I have left that row out rather than placing a checkmark in both columns.
A buyer should ask for the current plan boundary in writing before selecting the higher percentage. For example, the difference on $6,000 of bookings is $15 in my scenario: $75 on Pro minus $60 on Growth. The purchasing question is therefore not merely whether $15 feels small. It is whether the additional plan provisions, as presented to that buyer, justify paying another 0.25% of bookings.
Rate-writing also belongs in a wider operating process. A price change does not answer questions about listing quality, market selection or occupancy measurement. Those are separate jobs covered in the listing improvement checklist, the market-selection framework and the occupancy research process. Keeping those jobs separate prevents a feature table from promising business outcomes that the verified capability does not establish.
I have not established a limitation worth reporting from the verified record. There are 0 verified absences in the supplied competitor facts, and silence on a pricing page is not evidence that a capability is unavailable.
That means I will not create a familiar “does not include” list merely to make this section longer. If a feature was not recorded, the accurate statement is that I have not verified it. That is different from saying the product lacks it.
For Maarten’s three-property evaluation, the distinction is practical. Suppose he has five required capabilities on his purchasing checklist. If the verified material here addresses one of those five, he still has four questions to ask. He does not have four confirmed limitations.
I would use a simple evidence grid:
| Status | Meaning | Action |
|---|---|---|
| Verified capability | The supplied record establishes it | Confirm how it applies to the intended plan |
| Verified absence | The supplied record expressly establishes that it is absent | Decide whether the absence rules out the product |
| Not verified | The supplied record does not answer the question | Ask the vendor before paying |
Only the first status is available for the rate-writing workflow described above. The second status has no entries in the material supplied for this review. The third status must remain a question rather than being converted into a negative claim.
This approach matters when comparing specialised tools with broader operating software. We do not build a channel manager or a pricing tool, and readers who need to define those categories before comparing them can use the channel-management comparison, the task-management comparison and the rate-tool comparison. A category page can explain which job to investigate, but it still cannot prove that an unverified vendor lacks a feature.
Response speed and calendar hygiene, handled for you.
Start free — first 500 messagesOr book a demo callThe best-defined fit is not a particular property count. It is a portfolio shape: booking revenue that the operator is willing to place on a percentage-based fee, combined with a need for the verified rate-writing workflow.
Consider Maarten, who operates three properties in one town through one booking channel. If those properties produce a combined $6,000 in bookings during the period, my example gives him a $60 Growth calculation and a $75 Pro calculation. If the same three properties produce $18,000, the calculations rise to $180 and $225.
Nothing about the count changed between those examples. Maarten still has three properties. Booking revenue tripled, so the percentage-based cost tripled. That is the portfolio shape a buyer must understand before deciding whether the payment model suits the business.
I cannot honestly name a property count at which this becomes the cheap answer, nor a count at which it becomes the obvious answer. A valid threshold would require a verified alternative price and a shared definition of revenue, features and billing period. The evidence supplied for this review does not establish such a threshold, so I give neither number.
A one-property operator should therefore run the same calculation as a ten-property operator. The useful inputs are:
For example, if an operator expects $12,000 in bookings, the arithmetic is $12,000 × 1% = $120 on Growth and $12,000 × 1.25% = $150 on Pro. The difference is $30. That calculation works whether the $12,000 comes from one property, three properties or ten properties.
The model may be easier to budget when revenue is predictable because the formula is known. It may be harder to reduce to a fixed monthly line when bookings vary because the bill varies with them. Neither observation establishes quality; each describes how the verified basis behaves.
Property count still matters operationally, even though it does not set the price by itself. Ten properties can mean more listings to configure and monitor than one property. But I have not verified a count-based fee, a count discount or a count limit, so none belongs in the cost calculation.
Hosts still deciding whether to expand can separate the software question from the business-model question. The rental-arbitrage explanation, the permissions checklist and the profit arithmetic address the underlying model. A percentage-based software fee should be inserted into that arithmetic rather than treated as proof that the model itself works.
We do not collect user reviews of other companies, and I will not summarise ratings that I did not gather. Readers who want user submissions can find them on Capterra; I am not repeating a star rating, review count, quotation, advantage or complaint from that page.
What this review supplies instead is narrower and reproducible: pricing at three example counts, using a stated revenue assumption and the verified percentage basis. For one property producing $2,000 in bookings, my example is $20 on Growth and $25 on Pro. For three properties producing $6,000, it is $60 and $75. For ten producing $20,000, it is $200 and $250.
That does not replace user feedback. It answers a different question. Reviews can describe individual experiences, while the arithmetic shows what the published percentages do when applied to a stated booking total.
I would keep those evidence types separate during a purchase. A report about someone’s experience cannot change 1% into a fixed subscription, and a price formula cannot reveal how every customer experiences the software. Combining them into one score would hide the limits of both.
I would use a ten-minute checklist built around this vendor’s particular pricing structure and verified workflow.
For a final numerical check, take expected bookings and run both formulas. At $24,000, Growth calculates as $24,000 × 1% = $240, while Pro calculates as $24,000 × 1.25% = $300. The $60 difference is the amount that the confirmed plan boundary must justify in that example.
BnBGenius costs $10 per month on Pro, while Voice Concierge adds $30 per month. We are not a pricing tool, channel manager, calendar-sync service or accounting system, so readers weighing the products should compare the verified rate-writing job here with the separate automation functions and prices on our pricing page. For more context on that category boundary, see when property-management software is needed and what hosting automation covers.