Child rates or occupancy pricing set in the Booking.com extranet aren't landing correctly in your PMS, and this explains the mapping problem and how to correct it.
You set a child rate or age-based occupancy pricing in the Booking.com extranet, and when the booking arrives, your PMS either charges the wrong amount or doesn't reflect the child occupancy at all. This is a mapping problem specific to how occupancy-based pricing is structured, and it's worth understanding the mechanism before trying to fix it by trial and error.
Booking.com lets you configure pricing that varies by the number and age of children in a reservation, often layered on top of your base adult rate. When that structure doesn't map cleanly to your PMS, one of two things typically happens: the reservation comes through at the adult-only rate with the child occupancy missing from the booking details, or it comes through at a flat total that doesn't break down into the components your PMS expects.
Front desk staff usually notice this first, when a guest arrives with a family booking and the amount on the confirmation doesn't match what the system is showing as owed.
A simple adult rate maps one rate plan ID to one price, which is straightforward for most channel managers. Child and occupancy-based pricing instead sends a structure — age bands, per-person surcharges or discounts, sometimes tied to specific room types — and your PMS needs to understand that structure the same way Booking.com does, not just receive a single number. If your PMS's rate plan setup doesn't have an equivalent occupancy structure configured, or if the mapping was built before child rates were added on the Booking.com side, the extra detail has nowhere correct to go and either gets dropped or flattened into the base price.
In the Booking.com extranet, open the exact rate plan and check how child pricing is configured — the age bands, whether it's a surcharge or included in a package rate, and which room types it applies to. Then open a recent affected reservation in your PMS and compare its occupancy and price breakdown against that configuration line by line. If the PMS shows the right total but the wrong breakdown, the issue is how the structure is being interpreted; if the total itself is wrong, the mapping is likely missing the child pricing component entirely.
Read-back verification applies to rate and mapping changes as much as it does to availability — when a rate plan, including its occupancy structure, is pushed to Booking.com's extranet, the system reads back what Booking.com actually stored and compares it against what was intended, field by field. That catches a mapping gap before it reaches a guest's reservation rather than after. If occupancy pricing keeps causing mismatches, that verification step is the structural fix — the public demo at try.primehostpartners.com is open to try without signing up.