A room type shows sold out on Agoda while your PMS still has it open, or the reverse — here is why the two disagree and how to find the source of truth.
Your PMS says a room type still has availability, but Agoda's extranet shows it sold out — or the other way around, and a guest books a room that's already gone. An inventory mismatch like this is one of the few OTA problems that can genuinely cost you a double booking, so it is worth tracing properly rather than just closing the gap and hoping it doesn't happen again.
There are two versions of this problem, and they feel very different. In the first, Agoda shows a room type as sold out while your PMS still has rooms open — you lose a sale you should have had. In the second, Agoda shows availability that doesn't exist, a guest books it, and you now owe a room you don't have — the far more expensive version, because it risks an overbooking the day the guest arrives.
Either way, the root cause is the same: your channel manager's count of available rooms and Agoda's count of available rooms have drifted apart, and neither system is automatically aware that they disagree.
Inventory counts move from several sources at once — a direct booking entered in your PMS, a block for maintenance, a stop-sell applied by someone on your team, and bookings or cancellations coming from every connected OTA. Each of those changes should be pushed out to Agoda as an update, but if one push fails silently, is delayed, or arrives out of order with another change, the number Agoda is holding stops matching the number your PMS thinks is correct. A stop-sell is a common trigger: if it's applied in your PMS but the message to Agoda never lands, Agoda keeps selling a room type you believe is closed.
Start from the Agoda extranet's own inventory view for that room type and date, and compare it line by line against your PMS calendar for the same dates. Then check whether a stop-sell, block or manual change was made around the time the mismatch started — your channel manager's activity log, if it keeps one, is the fastest way to see what change was supposed to go out and whether it actually reached Agoda. If you find a booking on Agoda for a room that shouldn't exist, that is now an overbooking to resolve with the guest and with Agoda support directly, not just an inventory number to correct.
Two features work together on this specific problem. Read-back verification means every stop-sell, block or inventory change is read back from the channel after it's sent and compared to what was intended, so a failed push shows up as failed instead of looking successful. And at the database level, reservations are protected by a physical no-double-booking guarantee — the system cannot save two overlapping bookings for the same room, by construction, not by a check that runs later and might be skipped. You can see both in action in the public demo at try.primehostpartners.com, including the 500-room sample property, without signing up.